公司内部的X项目即将收官，从结果看，X项目还不算是一个失败的项目，但也存在着非常多问题，值得复盘反思。


合同签署过长
一次性签署了一个大额的、长期的总包合同，让甲乙双方都受到了较大束缚。大合同让甲方难于掉头调整，风险难于把控；另一方面，因为合同已签，对于乙方未来的一个预期吸引就会降低，卖力程度、服务质量难免会打折扣。对于乙方来说，为保证项目阶段上线，额外投入了资源，但因为是大的总包合同，这些资源是无法和甲方谈判，投入就投入了，只能认亏。
复盘：分期签订合同对甲乙双方来说都是一种保护。甲方：风险可控，船小好调头；乙方：项目过程中的一些诉求也可以阶段性得到满足。


顶层设计缺失
顶层规划缺失，没有一个对系统自顶向下的系统性设计，任由下级单位提报个性化需求，业务部门对于差异化需求又没有一个明确的态度，致使系统庞大、复杂。
复盘：项目之初，如确实难于考虑周全，也应该借着每一次差异化需求的机会，梳理业务规范，一步步形成一个清晰的体系。


核心需求投入不足
想要在这个项目期间做的功能过多，核心需求的资源投入又不足。现在看，很多功能都没人用，或者用的很少。
复盘：还是和合同签署有关系，如果分期签订合同，在每一期分重点的来做，小步快跑，效果会好很多。


瀑布式开发方式
对于这种需求分析前期不清楚的项目，你很难去套传统项目管理的瀑布式开发方法论（需求分析->设计->编码->测试->交付）。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
复盘：对需求不明确的项目，敏捷开发更为适合。敏捷开发的核心是迭代，最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。当然，对于甲方来说，敏捷开发也有不足，因为难于预估未来的工作量，合同也就难于签署



开发时间过短
经历了漫长的产品选型、招投标、需求分析，最终却只给了三个月的开发时间，死命令的压榨开发人员赶进度，这其中必然是有不少坑，只能在上线后用户的抱怨声中一点点修复。
复盘：项目三要素：时间、质量、成本。成本一定的情况下，过于看重上线时间，就只能牺牲质量了，还是需要在两者间尽可能找到一个平衡。


技术参与度不足
如此庞大、复杂的项目，但限于部门人数，投入的技术人员非常不足，也造成了后续的很多被动。
复盘：大型项目一定要投技术人员全程参与，避免后期被供应商绑架。另外，源代码能买断尽量买断，哪怕多花点钱。