作为软件行业从业者，你必须有必要知道这样一个事实的严峻性，并需要时常刻在心坎里：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 推荐文献
- 软件项目失败的五大原因 - 博客园
- 一个失败软件项目的思考 - 博客园
- 中国的软件项目为什么失败率这么高？ - Zhihu
- 如何写一份敏捷的文档 - 简书
- 《人月神话》
- 《人件》
- 《最后期限》
