我做的一个的项目，如何才能顺利的交付

先把项目背景简单说一下，项目A可以认为是在原有业务系统的基础上衍生出来的新需求（派生的新业务），原有业务系统是一个比较大的系统，在公司也是一个拳头产品，卖了几十套，目前也有好几个人在上面维护+二次开发+缺陷修复等（人力资源紧张）。早期公司高层只是说肯定要做这个项目，但由于人力资源的问题迟迟没有决定要开工（还有一个重要原因是领导希望能够签下1-2个典型客户再启动项目A的开发），而仅仅是上销售去那几十家客户那里兜售新业务，吹的天花乱坠的，比较市场有些竞争，需要先拉单子。这些事情是年中的事情。

等到下半年的时候，市场对这个新的业务反应比较强烈，已经有客户说要看原型再签合同，原因是竞争对手已经出原型了。而此刻，公司以为高层决定要即刻启动项目开发，说先把原型做出来，限期一个月。而中层领导还是由于人手紧张，就随便抽调了4个开发人员，一半是1年工作经验以内的新手，就这样匆忙上阵。由于人手有限、时间紧迫、业务需求虽然已经明确，但很多业务细节这4个开发人员都不清楚，只有一个懂业务的但也谈不上精通。

项目计划就定了一个月，基本上按天把计划排好了，1个月后系统原型出来了。但比较粗糙，缺陷也比较多，设计基本没有做，代码质量也比较差。拿去客户那里安装后，客户认为这个系统太粗糙了，【到客户那里，客户就不会认为这是个原型系统了】

至此，按常规项目管理的做法，应该重新梳理真实的客户需求、业务流程和功能设计、架构设计、概要设计。。。。
但事情的发展却不是这样进行的。由于客户迫切系统以周为单位看到项目的进展，于是领导决定就在原型系统上扩展和修改，其结果就是计划制定后很难执行，变成了按周来排计划，主要就是按客户的需求来改。

好不容易在年底前把版本基本上稳定了，但只是业务流程和功能比较温度，缺陷开始收敛了。

但元旦后到客户现场安装测试版本，客户对此版本又提了很多需求变更和新模块。此刻麻烦就比较大了，因为系统的架构灵活性比较差，改起来对原有代码影响比较大，改动范围大。于是又是时间紧张，又是工作量，刚把功能实现，客户就开始催啥时候测试。缺陷一直居高不小，于是决定花2周时间专门修改缺陷。

到现在为止，开发基本完成了。但问题也比较突出：
系统的性能存在问题（有些模块客户的意见很大，但这个从技术上讲，改动会比较大，不是1周能解决的）
系统的稳定性（与1相关）
功能的可用性（有些功能早期按照开发人员的思维来设计的，到客户那里客户提出新的想法，开发时把这种体验需求压住了，但在后续还是要改）
马上要启动二期的需求开发，这个更麻烦

---------------------
至此，整个项目风险还是比较大的，我总结有以下几个原因：
1. 项目的目标、业务流程、大体需求是很明确的，但细节需求在项目中前期，整个项目组都是一知半解的，造成后续返工较大，客户和开发人员包括公司领导对质量的意见都较大；
2. 项目从开始到现在领导和项目经理的分工不明确；由于人是凑起来的，大家之前没有合作过不了解；
3. 原型系统出来后，项目经理大部分时间都去解决客户的需求沟通和售前支持了，少部分时间在真正项目开发上；
4. 一直对项目的总体计划和推进情况估计不足，造成项目计划形同虚设，完全是开发人员做到哪算哪；
5. 中前期领导对这个项目不重视，等到元旦后发现问题比较严重，就临时抽调人手进来协助，而刚进来的人一方面不是项目经理想要的人（仍然是新手），另外一方面由于系统的业务性比较强，新手加进来后1-2周内根本不起作用；
6. 测试工程师，派过来的2名测试工程师是后期加进来的，业务都不熟悉，培养的2周后才慢慢熟悉，而且在客户现场，测试工程师根本应付不了客户的问题，即客户讲的需求测试工程师根本不懂或不熟悉；

大致就这些吧。