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

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

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

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

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

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

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

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

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

大致就这些吧。

原有系统能扩展不？新的项目对原系统有没有影响？然后就是项目管理那一套

至始至终没有看到需求人员的影子..... 

问一个问题：你在里面是什么角色？

说一点看法：项目经理干嘛去了？别说没时间、别说人员都是新人。这些问题那个项目都存在。难道项目经理也是新人？项目经理不仅仅是执行者和Coder。

说实话，看到了一些以前看见过的场景：领导要求1个月，项目经理就按照一个月画甘特图；然后按照一个月执行，到一个月发觉又是一个神话。。。。

竞争对手已经出原型，一个月之后可能是一个实现核心功能的真实系统了，而你们只开发出了原型，落后了的可能性很大。明显没意识到风险管理...

领导前期不重视，涉及到签合同问题了，只调4个比较初级的程序员，领导肯定拍脑袋瓜，很多领导如此。

系统粗糙，第一印象没了。呵，前期设计有美工加入很重要，效果明显不同。即使功能不完整，能把核心的界面设计好都不错。

你们的模式似乎可以引入一些敏捷开发的理念，注重个体的能力与沟通，迭代式开发，短周期的计划与成果。由于大部分人业务不太清楚，最好能集中一个办公地方，随时沟通、培训，快速解决问题。

感觉一期的大问题是领导不重视、前期软件设计真没做好，越往后修复所浪费的时间越多。

另外，不是客户说做什么就做什么，项目经理适当与客户沟通沟通，有些功能可以延后。

领导可真是个大问题，我觉得与这个项目相关的领导的责任很大，缺少一个真正能管理项目内部开发的领导。


以上只是个人旁观的观点，也许在当局就很难察觉了。但我还是提几点不太专业的意见：
1、要让领导重视，有一个能够真正管理项目内部开发的经理。
2、防止功能蔓延，非核心的功能放后，客户没让开发的功能千万别做，时间不足只做最基本而能满足需求的功能。
3、加强内部沟通
4、需求、功能开发与客户确认之后再做，防止浪费时间与返工
5、由于客户经常提出新需求，客户很多时候也是拍脑袋说话，需求经常变，所以最好别过早下手

原有系统和项目A，由于系统架构不同，无法在原有系统上扩展。简单点说就是大家共用一个数据库，项目A肯定对原有系统有影响，但比较小，在初期方案讨论时已经规避掉了。

项目A在前期有产品部的同事A到客户现场沟通需求，有提交业务需求说明书。但这份文档侧重大体业务流程，并没有提及需求细节和功能细节。而且在coder加入后，同事A反而撒手不管了，或者说抽调去做其他的事情了。因为他认为他的事情已经完成了。

我在里面做开发，带几个新人coding

项目经理是同事B兼任的，平时不怎么管事，让我向他汇报。他管n个项目，恰恰项目A重要性又不大，处于半撒手状态。

你提到的场景，要是有英雄主义人物在场，运气好的话就是神话；要是都是菜鸟到最后肯定是一个烂摊子。

TO: zhanjia

项目A前期大家都没觉得没啥风险。但当原型系统拿给客户去测试的时候，而且是测试了差不多一个月的时候，才发现问题比较多，这个时候所谓的项目管理CMMI那帮人才介入，但此时进退两难。
因为一方面希望重新梳理软件需求（非业务需求），组织人开始做设计（设计文档+评审）；
但另一方面，客户又在催和加一些紧急需求和缺陷。
此刻领导根本没有充分估计到后续的影响和风险，于是选择了2.

到今天为止，迫于质量和稳定性方面的问题，想重新设计，可已经分身乏术了。

美工一直没有，后来不知道从哪里借了一个美工，但没有起到作用，因为始终没有人拍板说要改界面。

最近比较被动，暂时还没有看到缓解的迹象。

---
个人认为，现在应该隔离一段时间，先把设计重新梳理一遍，写下来，评审。再把代码重构，先把系统调整一下，这样以后要调整功能可控一些，扩展性也好。如果继续这样走下去，后面很难维护很难扩展，风险更大。还有就是要把各自的分工明确一下，现在有点乱，职责不清。

开发流程上不能搞一刀切,这情况还坚持瀑布模式之有死路一条...
赶紧换成敏捷模式可能还有点希望