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

1、在项目经理不重视的情况下，系统架构要搭得比较灵活。
2、明显这个项目中，项目经理没做到位，只做到一半。
3、领导不重视的项目，最好按敏捷开发方式 。

另外一般领导不重视的项目原因有几个：1、项目的钱比较少 2、有更重要的项目

所以一般这个项目做到基本满足客户就可以了，不要过度的设计。

敏捷模式，之前公司有组织过Scrum的培训，坦白讲，我也非常支持这种比较流行的开发模式。但这个事情决定权根本不在我这里，而且实施敏捷开发，对团队成员的要求比较高，现在这几条木杆枪未必能开展起来。

现在不是过度设计，而是没有设计。

由于客户的需求常常调整，而我们又没有专门的人做需求管理。再加上之前的框架设计和基础模式设计比较乱，后期扩展太差了，满意度很低。

-----


上面有2位都提到敏捷开发，虽然未必能开展起来，但可以按照敏捷开发的思路去推进；常见的做法就是把紧急又重要的需求和功能（包括要改进要重构的模块）先排成列表，按2周左右一个迭代周期，确定工作目标和人员分工。加强内部沟通，先把这几条枪都用起来并用好了。循序渐进。

另外就是设计文档，在敏捷开发模式中，其实并不像瀑布那样有那么多大文档要求，敏捷开发讲只写必要的文档。只是这个尺度也很难把握。从现在开发目标和进度来讲，肯定是先优先解决眼前问题并把问题一一解决。但是从远期来看，后面这个项目肯定会持续维护，如果文档比较粗很难维护，那后面还是麻烦。

把你的问题提交给项目经理。剩下的他来解决，项目经理不是顶个职位时完事的。
不在其位不谋其政，虽然有些的推脱，也是一种处理问题的方式。
至于你个人，你应该向清楚两个问题：（1）你自己的极限在哪里？遇到一个不管事的项目经理，靠你个人能撑多久；（2）明确你自己该做的事情？巧妇难为无米之炊其实他们比你更懂。只是现在很多时候大家的心思都歪了。

任何方法学都不是银弹。每一个方法都有其适用场景的。

你领悟了 。。早怎么干就对了

非常感谢楼主分享这个案例，应该说很多公司很多项目都存在这个情况的。
先说一下问题：
1、公司管理问题：从这个项目可以看出公司存在管理混乱。公司领导、业务部、产品部、开发部之间的需求传导差。按道理上层决定做这个项目，而且业务部已经在做概念推销的时候产品部和开发部就应该整理出业务需求，把控需求的范围了。
2、开发经理问题：就算项目还没有真正要做，开发部也应该准备人力资源做前期需求了解和业务学习了。你们公司显然是有优势的，项目是在前期已运行的项目上再做扩展的。而且已经有维护人员做二次开发的，他们肯定对业务熟悉。。那么即使新进来的人不懂，项目开始阶段有没有安排培训和业务引导？
3、流程性问题：这是很多公司的通病，开发项目没有完整的流程。各阶段产品的交付没有明确、没有评审机制。产品人员给你们的业务需求有经过评审吗？软件需求有经过评审吗？有没有业务部、开发部、测试部、产品部的人参与评审很重要。
4、项目经理问题：这个项目应该说项目经理问题最大。
项目前期不重视，既然知道新人不懂业务就更应该向开发经理要资源。。公司有现成的维护系统二次开发的人最适合做这个项目。。为什么不调配一两个过来呢？
项目计划制定盲目性：项目难道是按照领导的意思做吗？领导说一个月，就得一个月做完吗？项目计划仍然要按正常的时间来做，可以通过加班来解决时间问题，如果加班仍然解决不了就要尽早抛出问题。做不完就是做不完。。领导说一个月的时候，实际上他又不懂这个，他说一个月，你屁都不放一个，他就认为可以做完啦。
需求调研不彻底：项目中没有人负责专门的需求调研，你们的业务需求出来了，有做过详细的需求调研吗？有没有经过调研形成的软件需求规格还是个问题吧。
软件架构问题：没做架构设计，没做概要设计、开发人员的设计能力不足导致软件无扩展性
阶段性开发问题：虽然开发人员水平不够，不能进行敏捷开发，当时间不够的时候，项目经理就要拿出方案，区分核心功能与次要功能，分阶段开发，核心功能先做。并通知业务与客户。
项目风险分析：项目经理没有进行项目风险分析与跟踪管理

怎么使项目尽早结项呢？
1、明确现在系统的问题，尽快重构与架构调整
2、明确现有用户需求，与业务和客户开需求协调会。哪些要做哪些不要做，这个一定要定下来。否则项目是无休止的。
3、与业务和产品确认本期要做的需求，如果要增加新需求，到下一阶段
4、积极引导项目经理和开发经理与管理层沟通，指出问题关键所在。。这些问题不止关乎这一个项目的。
5、建议公司做CMMI的评估，非常有利于改变管理层和流程混乱的情况。

To:luweifeng1983
这位仁兄说的在理，
#2. 开发经理的问题，前期有安排业务培训，其内容仅限于业务流程，而多数业务细节是在遗留系统的代码中的，这些细节目前为止没有文档，公司也没有几个人能说的清楚这些细节。当然这些不能成其为项目做乱的理由。
#3. 流程性问题，公司已经CMMI-N都过了，但有认证并不代表公司管理流程就规范了，仍然是那就好，还是人的问题。
#4. 项目经理的问题，在项目启动之前，就申请过人，但公司是一个萝卜一个坑，关键先生都在关键岗位看着关键客户。之前我也提过此项目的优先级并不高，根本不大可能把关键先生拉过来。所以本来业务很有优势到后来却丢失了。

后面你说的一些话都很尖锐但都说到点上了。后面我再细读你的话再想想。

我再展开把这个项目最新的情况说一下：
到今天又过了快半年了，这个项目目前已经签了近10个客户了，大部分已经上生产了，销售可谓是高歌猛进，但开发这边就比较惨了，几乎快撑不住了。到现在为止，系统仍然很不成熟，每天都从客户现场反抗不少问题，每个客户每天都至少反馈几个问题，加起来就是几十个，每天能处理的只有一部分，这样累计到现在未处理的问题就有几百个。

需求管理：依照客户现场反抗的问题，确认后都录入到公司的需求管理系统中（开始走公司规范流程），对这些需求做分类管理，把重要的紧急的都做了时间表，这些汇总出来就是项目的版本发布计划，现在每个月做一个版本，项目经理月底把计划排好，月初开始，开发三周编码，测试工程师测试一周，月底发布。

开发方面，现在补充了1名开发人员，人手方面有所改善（招聘出了些问题，公司找10k的工程师却只出8k的薪水，造成候选人反水的比较多，上半年已经出现了2起[现在的人也比较实在都是找好2个，谁钱多就去哪]）。早期的压根也什么框架代码，工程的代码写的比较乱，这半年天天都在还债，因为需求变更或扩展，要改代码非常痛苦，重构起来很花时间也不敢轻易去谈重构，不得已就小范围修改或者是重写某个小功能的代码。代码这块成了无尽的痛。
开发方面还有个很大的问题，就是版本的问题，近10个客户，大部分客户都是用同一套代码，但有那么2个客户（金牌客户）早期非要定制化n多需求，当时迫于领导压力就分了版本，现在维护起来非常麻烦也非常耗时好利，每次都要代码同步合并，测试也要多测试2个版本。现在有计划要把这2个客户的代码合并到主干上去，通过一些功能配置做到版本统一，但现在一是没有人手而是时间紧。因为还有几百个问题要处理呢。

测试换了2个经验比较丰富的工程师进来。她们一上来就严格走公司流程，要求开发人员在需求管理系统里面把问题和修改过程测试要点写清楚，虽然早期开发人员不太适应，但后来都很乐意配合按规范来做。以前做版本都是开发人员，最近都是测试工程师，包含编写发布记录也都由测试工程师做。效果还是非常好的。

实施方面，每个客户现场都有一名实施人员在场，配合客户做UAT和上线；这实施工程师大致分2类，一类是菜鸟，客户说什么就是什么，完全不分析直接往公司报且这些问题描述不清楚；不仅如此有什么问题总喜欢打电话回公司问东问西全然一副传话筒的模样。第二类是比较有经验，反馈上来的问题基本上都是确认是缺陷或者是比较合理的新需求且遇到问题大部分都能够自行解决。后来项目经理就找实施部门的老大投诉，让他们加强人员的管理和现场沟通技巧。不管是缺陷还是需求都需要把问题描述请求，尤其是新需求要把需求的目的和流程即细节描述清楚，否则拒绝受理。后面收到了比较好的效果。但有一点对开发影响较大，就是每天都有至少10通电话打到开发这边来，每个问题都要耗几分钟长的半小时多，很影响开发效率（因为普通开发人员回答不了这些问题，而主力又没有时间，这个问题处理不好对实施人员的积极性有影响。后面就转给测试工程师了，但也有问题，这里不细说）。
实施还有一个问题，就是客户的环境比较复杂，公司基本上较难模拟这个环境。造成版本发出去后，大部分都正常，但总有那么1-2个客户现场掉链子，折腾很久，客户意见很大因为他们总认为是软件的兼容性问题。




  

忘记说了，还有个淡疼的问题：项目的合同我还没有资格看，但从流传出来的信息看，这些合同全都是半吊子合同即都没有把需求范围列出来，而仅仅笼统地说要做一个什么系统。这样就造成客户理所当然地提很多扩展性需求，而这些需做起来成本也不小。这个问题现在领导开始关注了但还没有结论，这个死盆子还不知道要扣到水头上。
现在仍然还不能启动二期开发，因为没有一个界定标准什么才算是一期完成。

结项看起来会遥遥无期，这个项目今年都要耗进去了。