最漫长的一次交付项目复盘

最近经历了入职公司最长的一个项目，前后跨度3年，更换3任PM,SE等关键角色；本次项目周期长，有美国的助攻（中间暂停3个月左右），有需求范围持续变更等客观因素造成，也有项目管理中人为原因造成；现将项目的过程几个典型的片段进行回顾，最后做下项目管理的心得小结。

第一个TR5交付时整体需求大概有5000+，组织SE,开发等澄清保留3000+；设计是项目的源头，建议定期和开发，测试澄清一次，尤其人员变更，项目范围变更等时需要主动组织开展；

一到版本转测试管理软件的同事就通宵达旦合入代码和验证，转测试后经常测试出低级问题（配套表不正确，不能升级，升级后启动异常等）造成版本反复被打回，如果一个事件反复出现，背后一定有更深层次的原因（组织，流程，代码架构等深层次原因）。

人一生少犯同样的错误，能够大大的提升个人的成功率，组织如果能够积累，少犯相同的错误，尤其是低级错误，那么这个组织就能不断高效高质交付。

一直没有的系统测试看护，项目组从立项开始就没有系统测试人员，每次测试是都是测试经理多方求助才有人力完成相关测试。初期还有一个独立小组，负责产品的交付，还容易协调到人力；后期组织解散，人力不断升级，一会软件人员测试下，一会硬件测试测试下……总之系统测试能力一直没有建设起来。

几乎没有按时达成的月度计划：版本从转测试初期，月度计划基本没有按时，往往因为人力原因延期3~5周后转测试，转测试后低级问题多，又反复需要出版本，版本就陷入的循环：延期，出问题，延期转测试……最终版本火车也没法保证，版本多次进行PR延期交付时间点。

心得

1. 交付项目最好在6~8个月结项，长时间不结项的项目是很可能出问题的；增量版本单独立项，单独分配人力；
2. 项目立项只谈了立项的进度和费用情况，但时间人力投入太少；
3. PM很关键，要持续跟踪，交付计划按月度达成，就是平时少量延期也不至于3年才出来；
4. 每个版本交付件要齐全，能够验证，减少反复；
5. 尽快进行生产装备的试制，打通生产制造流程；
6. 从开始就要全系统配合的测试，支持的单板，部件，场景覆盖；
7. 人员流动做好工作交接，形成组织资产；
8. 配套产品一起转测试，一起管理起来，作为整体进行系统测试；
9. 拉通下游一起开展联调和测试，尤其是满框业务的压力测试；
10. 需求进行定时澄清；