多方协作研发项目管理实践经验谈.docVIP

多方协作研发项目管理实践经验谈　　最近应领导要求加入到一个进行中的多方合作研发项目，项目涉及到公司标准产品、技术平台框架、二次开发以及客户外包开发业务四方的合作研发的项目，且技术平台框架提供的WEB业务还处于新产品阶段。整个项目面临多方合作，技术攻坚等困难。项目进展一个月，开发进度严重滞后，甚至连标准的测试和开发环境都没有搭建成功。由于业务依赖复杂，二次开发和外包开发必须依赖标准产品和技术平台框架来进行，技术平台框架又处于新产品阶段，不够稳定，在开发和测试环境中，即有标准产品出具的更新补丁，又有技术平台开发人员手工替换的jar包文件，脚本有的执行，有的没有执行。安装的补丁和替换的内容缺乏明细记录，一旦发现问题也很难确定是标准产品问题、技术平台问题还是二次开发或者外包开发的代码问题，分析效率较为低下……。，开发和测试人员甚至连一个稳定的环境都没有，工作陷入困境。各方领导在人员上都给予了大力支持，但效果并不理想。抱怨的邮件一封接一封，但却没有有效的解决办法。我参加了一次项目例会，并深入跟进了项目一周的时间，大体上了解了项目存在的根结问题，并采取了一系列的措施，经过一个月的改变，项目终于走上正规，各项工作能够有序有效的开展。针对多方协作的研发项目总结了一些经验，在此分享。 　　多方协作研发项目存在的问题： 　　1. 项目初期大多是人员的整合，却不是项目的整合。牵扯的团队多了，管理变得复杂，各团队都注重各自任务的完成，而忽略了团队间必要的协作，多一事不如少一事的心态较重。但当项目过程中各方工作产品相互交织和相互牵制的时侯就会暴露出严重的问题。 　　2. 缺乏严谨的项目计划和全面的风险分析。多方协作研发的时侯，需要有经验的项目人员参与计划的制定和风险的分析，要考虑每个团队的特点，并且结合项目可能存在的协作风险。特别是在风险暴露的时侯需要有效的风险应对计划和明细的解决策略。任何一个项目都具有不确定性，提前预知所有的问题很难，但在项目过程中，需要有效的机制来保证项目的风险的及时处理 　　3. 没有规矩无以成方园，每个团队有每个团队的风格，但同属一个项目的时侯，必须有统一的游戏规则，项目管理就显得尤为重要了，一份完善的《项目公约》是必不可少的，而且在前期对于规则的认识一致性非常重要，多在这方面花一些时间，在后期工作开展的时侯就会少一些麻烦。 　　4. 多方协作的项目责任的划分非常的重要，说白了就是明确每个团队要做哪些事，最后秋后算帐的时侯要找的到对应的责任人。多方协作常出现的一种现象就是踢皮球，不明确责任和义务，到时候就会陷入到混乱。责任和义务都明确清楚了，扯皮的事情也就少了，皮球也没办法踢了，工作才能顺利的开展。 　　5. 项目经理，这个太重要了。在这里无法说的很细节。项目管理的理论已经很丰富了，关键是细节。项目经理对于项目的了解和熟悉至关重要，不一定要是技术专家，但对基本的项目背景和业务复杂度有深入的认识，知道怎么去做才能改善。 　　6. 最后想说的，就是遇到问题要思路清晰，找到解决问题的方法和方案。大喊问题很多没用，大喊需要支持也没用。 　　针对这个项目我采取的措施是(以下是我回复给项目组的邮件)： 　　从前期我们的过程来看，在测试环境以及产品质量这两块存在较大的问题，后续我们将严格规范相关工作，一切按照项目管理规范来做，对相关工作做重点说明： 　　环境管理以及测试依据： 　　1. 从今天开始，XX项目测试负责人为张小静，测试服务器密码将修改，补丁更新统一由张小静负责处理 　　2. 开发和测试环境明确规则，重新搭建标准的开发和测试环境，环境部署为 标准产品+技术平台框架+二次开发业务+外包开发业务 　　3. 日后所有的开发内容(技术平台补丁、标准产品补丁、外包开发团队的功能内容)必须以标准补丁的形式更新测试环境，进行测试。不允许在测试服务器上进行手工操作，包括脚本的执行。 　　4. 原则上每日更新补丁测试，开发人员对于bug的修改每日构建，第二天更新补丁进行测试。如有紧急需求，张小静可以增加补丁更新的频度，但不允许替换jar的形式更新。 　　5. 测试环境保持唯一性和准确性，所有的内容都以补丁形式进行验证 　　6. 每条项目任务的通过以项目管理工具中项目任务通过为标准，项目进度以及项目质量全部以项目管理工具数据为准。在开发机上测试结果不能作为任务通过标准。 　　质量保障缺陷处理机制： 　　1. 测试中发现的所有问题都必须以bug的形式在项目管理工具中更新，无论是环境问题、标准产品问题、技术平台问题、二次开发内容还是外包开发内容 　　2. 所有的任务和缺陷修复开发人员必须做好单元测试，单元测试必须执行测试用例的1级用例或执行30%的核心用例，减少中断等影响测试开展的重大错误。测试人员保障业务流程的有效测试。 　　3. 项目问题分析和处理