[项目管理]失败的软件项目所具备的特点【待续】

作为软件行业从业者，你必须有必要知道这样一个事实的严峻性，并需要时常刻在心坎里：70%以上的软件项目都是失败的。

据国外某权威机构调查，全世界所有软件项目里，只有30%成功。当然剩下的70%也不是完全不能用，而是没有达到设计的目标，很多也能凑合着用。

1 变更控制失败

1.1 人员变更管理失败

1 没有贯彻的项目经理统管制，要么没有项目经理、要么频繁变更项目经理
  项目经理是项目存亡、生死优劣的最核心人员。

2 人员变更时，未能做好干系人（新进人员、团队成员、上级领导等）工作交接

3 没有尽可能少地减少人员变更

1.2 配置变更管理失败

1 没有统一的配置管理员，配置信息的有效性难以保证：每个人都有一份同一项目的配置文档，且五花八门，详略不同。

2 配置变更后，未及时告知配置管理员。

1.3 破坏性的【需求变更】 / 失败的需求变更控制

软件的设计和实现每被改动一次，这是需要时间和金钱代价的；且随着项目的开展，越往后期，变更的成本越高
需求不是不能更改，是不要随意更改，要在控制下更改，或者是有一个良好的变更程序(流程制度保证)，来保证需求的变化不会对项目造成破坏性的影响

0 客户不知情的情况下，实际工作内容与标书的技术参数完全不符。
1 客户反馈的口头需求反馈繁多，无专门的需求工程师及时、完备地记录、梳理、确认。（导致客户反复提、建设方反复忘记或需求管理混乱）
2 客户无限制地频繁变更需求，并可能不停地推翻已有的、已确认的建设内容成果
3 无边界的需求变更和需求新增，时常超出招标范围
4 客户需求模糊不清，迟迟不确认现已的系统设计

2 质量保证失败

1 没有保证项目完整的测试流程，项目组(实施、研发)人员可随意地修改配置、源代码后，不经相对充分的测试便进入生产环境

3 系统设计与软件过程管理失败

0 妄图以【敏捷】为口头目标、验收款为目标，欺骗、无视对【系统建模与设计】和【文档】缺乏的极端严峻性
  系统开发就要有文档。
  “工作的软件高于详细的文档”这一敏捷宣言，并不是告诉人们，敏捷过程没有文档的必要

4 不切实际的时间安排

1 为了赶验收，在压力之下，项目经理或项目负责人定了一个不切实际的进度安排。最终陷入这样一个死循环：赶进度→加班→低效率、低质量→进度延期→赶进度

5 不恰当的人员配置

如果你还没有找对人，最好不要轻易动手，否则，掉进泥潭，十之八九有可能。

1 新进人员，并未掌握项目的基本前置技能

2 项目组人手配备不足或不完备    
:项目组的人员基本配置: 
  ①项目经理
    系统架构师
    系统分析师/需求分析师
  ②研发经理
    服务端研发工程师
    前端研发工程师
    UI工程师
  ③测试经理
    测试工程师
  ④实施工程师：系统建设阶段的实施工作
  ⑤运维工程师：系统运维阶段的实施工作
  ⑥配置管理员：统一管理项目配置、项目资料
  —————————
  ⑦商务经理
  ⑧项目财务专员（成本核算与预警控制）

3 人员分工不明，职责边界混乱
  例如: 研发要干实施、测试的活儿

X 成功的项目

完备的成员角色

项目经理: 统筹推进项目工作、进展，协调资源、识别并化解风险；主导、并与系统工程师共同制订【项目章程与制度】、【项目实施规范】

系统架构师/系统工程师：解决项目内的系统需求、系统风险设计、系统架构；

配置管理工程师: 统一管理项目和软件的配置；

研发工程师

实施工程师

尽可能少的人员变更
人员分工明确：让专业的人，做专业的事。

才能物尽其用，人尽其材。

Y 推荐文献

本文作者：千千寰宇
本文链接： https://www.cnblogs.com/johnnyzen
关于博文：评论和私信会在第一时间回复，或直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：若本文对您有帮助，可点击右下角【推荐】一下。您的鼓励、【赞赏】（左侧赞赏支付码）是博主技术写作的重要动力！