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