上世纪 80 年代，许多软件最后都得到了一个悲惨的结局，软件项目开发时间大大超出了规划的时间表。
一些项目导致了财产的流失，甚至某些软件导致了人员伤亡。同时开发人员也发现软件开发的难度越来越大。
在软件工程界被大量引用的案例是 Therac-25 （加拿大原子能有限公司所生产的放射线疗法机器）的意外：
在 1985 年 6 月到 1987 年 1 月之间，6 个已知的医疗事故来自于 Therac-25 错误地超过剂量，导致患者死亡或严重辐射灼伤。
这就是所谓的 “软件危机”，是指在软件开发及维护的过程中所遇到的一系列严重问题，
这些问题皆可能导致软件产品的寿命缩短、甚至夭折。
为了解决问题，1968 年秋季 NATO（北约）的科技委员会召集了近 50 名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱 “软件危机” 的对策。
在那次会议上第一次提出了 “软件工程”（software engineering）这个概念。
应用计算机科学理论和技术、以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科
可以看到，其中提到了软件工程关注的三个关键因素，
预算
进度
满足用户要求
所以说把软件开发出来并不难，难得是按时交付可靠的软件。
在《持续交付 2.0》中写道，
质量与速度根本不存在平衡，只有在产品能够承受的一定质量水准基础上，追求交付的速度才有意义。
持续交付要解决的问题是，如何在满足质量要求的前提下，快速的交付产品价值。
我想每个软件行业的从业者都遭遇过 “延期项目” 的摧残吧，也饱尝过 “工期倒排” 的滋味。
本文就来探讨一下如何对进度落后的项目进行治理。
进度落后是从什么时候开始的
这个问题也许很少有人思考过。
大多数人也清楚的知道，进度落后并不是从 deadline 当天才意识到的。
而是应该是处于项目进行中的某一天，突然发现自己无论如何在 deadline 都不能做完了。
既然这样的话，为什么我们不能提前意识到延期的风险呢？
所以这个问题我可以这样回答，
项目的进度落后，是从我们对项目失去掌控的第一天开始的。
什么是失去控制呢，那就是对交付没有信心。
看到这里我们就明白了，大多数项目其实在启动时就已经注定要延期了。
所以要谨慎，在项目启动的时候，不要做出太过理想化的许诺。
否则就是在开发一个注定无法完成的软件项目，到时逼不得已只能砍需求，或者延期交付。
这种软件项目通常称为 “死亡行军”。
治理进度落后的项目从现在开始
从现在开始治理项目进度，是最合适的时机。
把手头的事情停下来，向外明示项目进度
考虑整块交付功能，而不是遍地开花；功能要一块一块的交付，不要一起交付
列出事项的优先级，排定自己的计划
每天向外披露自己的进展；需要哪些帮助，有哪些卡点
项目进度的 “可见性” 是健康项目的关键特征，
项目的所有关注者，都应该对项目状态了若指掌，这是所有事项优先级排定的基础。
保持项目的 “可见性” 良好，“任务加塞” 就会变得有据可依。
我们不是没时间做事，而是没时间做这件 “低优先级” 的事情。
There's always time, time is priorities.
如果非要做这件事，也行。那么哪件其他事情可以接受延期呢？
为了能理直气壮的说出这句话，项目就必须具备 “可见性”，每个人都知道别人在忙什么。
所以有时候可以这样说，
没时间是好事，可以促使人们想清楚，什么才是最重要的事情。
要看情况加人
向进度落后的项目中增加人手只会使进度更加落后
这是因为在软件开发领域 “没有银弹”，没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
因为软件开发的根本任务是 “打造由抽象软件实体构成的复杂概念结构”，
次要任务才是 “使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言”。
这就好比你有一匹马，可以在 10s 时间内跑完 100 米。
现在给你 10 匹马，也无法在 1s 内跑到终点。
那么项目延期不就无解了么，所有代码干脆一个人来写就好了，
甚至还有极端理想化的 ”外科手术团队“ 的提法。
其实不然。
能不能加人，取决于事项能不能分解成多人并行执行的任务。
比如在 web 开发过程中，在一定程度上，前后端开发任务是具备 “可并行性” 的。
那么加人就能使这段 “可并行” 的任务提前交付。
但是，并行的任务迟早还有 “合并” 的时候，这时又要有沟通成本了。
因此，加不加人，以及加人能否解决延期问题，就要评估并行开发的任务占比。
关注影响价值交付的瓶颈点
代码不断提交没有任何作用，应该向外展现出价值不断的增长
关注那些影响价值交付的点，杜绝浪费不断的做出优化
卡住自己的依赖方，一定要提前催一日三催，不能让别人影响自己的进度
一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。
可是这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。
这种 “无用” 的功能生产得越多，浪费就越大。
避免项目延期，就是要不断的加快速度，没有一劳永逸的办法，因为每个项目都不相同。
但优化思路是相同的。
观察项目成员每一天的工作，识别出造成 “浪费” 的瓶颈点
先消除第一个瓶颈点
接着识别第二个瓶颈点，周而复始
瓶颈点一般是跟 “代码” 无关的，而是跟 “人” 有关。
比如，事先如果没有沟通好具体事项，那么就容易在做完后频繁返工。
或者，在开发过程中遇到不确定性时没有上报，私自做出的决策也有可能在后期被推翻。
又比如，项目需要某个人拍板后决定，但是这个人的回复又比较慢。
这些都是有办法解决的，关键在于没有 “识别” 出来。
小结
对进度落后的项目进行治理，是一件 “技术活”，并不是加人多写点代码就能解决的。
需要考虑：
哪些是当前最重要的事情，优先级的排定如何动态调整
每个人都在忙什么，哪些人处于等待中（卡住别人的人，其实并不清楚现状）
是不是聚焦在功能模块的价值交付上了，还是提前关注了微不足道的细节
如何达成共识，如何避免返工
除了考虑这些还有很多很多，这些也只是我从个人经历的项目中总结出来的几点。
但可以看到的是，项目是可以治理的，
对项目进行治理，可以明显的改善项目的健康状态。
一个健康的项目，会持续不断的向外透出价值，我们应该关注 “价值透出率”，使其最大化。
这离不开孜孜不倦的对项目进行观察，以及顺畅直达人心考虑双赢的沟通技巧。
治大国如烹小鲜。