我们看了太多失败的和即将失败的项目，在IT软件领域更是如此。每天早上醒来在朋友圈里看到半夜更新的，不是身在国外的朋友，就是在办公室为了项目上线而加班的朋友。
Edward Yourdon为那种项目约束与目标之间相差一倍以上的软件项目专门写了一本书，叫《死亡行军（Death march）》。我曾经亲眼见证过几个“死亡行军”项目的立项过程。
其中一个项目，那时候我才工作不久，一个项目从无到有，“大领导”希望在21天之后上线，这个日期包含了周六和周日。但是按我们的预估——当然我们也不会盲目乐观到每天只工作8小时，这个项目按现有资源起码需要3个月到4个月。在产品立项过程中，“大领导”坚决不肯让步，时间、范围均压得死死的。就这样，我们在会议室里博弈了整整两天，最后的结果是我忧心忡忡地走出会议室，问我身边的同事：你觉得咱们能办到吗？同事的表情我至今印象深刻，那是一种释然和轻松——他笑着说：怎么可能嘛。
最后的结果，项目延期了半年。
如何能够让自己的项目稳定运行并得到期望的结果呢，避免死亡行军，打一场胜仗呢？
几千年前的孙子兵法中已经给我们提供了思路：
故知胜有五：知可以战与不可以战者胜，识众寡之用者胜，上下同欲者胜，以虞待不虞者胜，将能而君不御者胜。
分析需求价值，我们只做高价值的事情
价值驱动作为敏捷开发的两根支柱之一，为软件开发行业提供了一种全新的思路。在上世纪八十年代之前，软件开发的时候还有这样的等式：功能=价值。
所以奇怪的一幕出现了：软件开发这个行业一边承受着巨大的进度压力，一边在生产着没有人用的功能。微软曾经发起office 2003用户调查，希望调查用户希望 Office 2007实现哪些新特性，结果收获了让人吃惊的消息。产品总经理 Takeshi Numoto 如是说：“超过90%的特性请求早已存在于 Office 中可供使用”。
更何况对于所有的软件开发组织来讲，资源不足都是常态，识别出来哪些可以不做，我们才知道应该去做什么。
知可以战与不可以战者胜。
通过限制在制品的方式来缩短前置时间
对于缩短产品交付周期，一向是很多客户都会提到的问题，特别是电信级的产品，动辄一年的交付周期。当前市场环境已经变得越来越快，根据波士顿咨询公司的调查，最近的20年已经成为变化最剧烈的20年。
在这样的市场环境下，“响应速度”就被提到越来越高的位置上，而衡量响应速度最直接的指标就是“前置时间”（lead time）。一个需求从产生到变为现实，究竟可以有多短？
利特尔法则是一个神奇的公式，它简单到甚至可以被10岁的孩子所理解：平均吞吐率=在制品数量/平均前置时间。对于一般的组织来讲，平均吞吐率约等于团队的产能，把它视作常量的话，我们想得到更短的平均前置时间，就需要控制在制品数量，小批量地快速流动。要么不做，要么快完。
识众寡之用者胜。
团队所有人目标一致
“我们所处的项目，目标是什么？”有没有保证项目有着一个清晰而具体的目标？有没有保证所有成员都能够理解并执行？
在客户现场的时候，我经常听到的问题是：“作为一个管理者，我如何能够准确看到员工的人员利用率？你有没有办法让团队里所有的人都忙起来？”每听到一次这个问题，我在心里就会默念：“你可以让闲着的人都出去跑圈嘛，这样大家都忙起来了。”
软件开发的项目，绝大多数的目标都不是“所有人都忙起来”，而是“快速交付价值”。也就是说我们做任何的努力，都是为了能够让需求尽快上线。
而敏捷开发中的各种可视化手段，包括故事墙、故事地图，都起到了这样的作用——目标可视化。特别是树立在团队中间的物理看板，我们真正的目标都清晰地挂在上面，所有人的工作和努力，都是在推动着一张张卡片从板子的左边挪向右边，如果你做的事情对于推动卡片没有起到直接或者间接的作用，那就要好好思考一下了：我们的目标究竟是什么？
至于说人员利用率——谁知道一个正在端着咖啡面对窗外发呆的知识工作者（译作Thought Worker）是不是在为接下来消灭更多卡片而在布局呢？
上下同欲者胜。
做好风险管理
在客户现场待了一年，看的项目虽然不多，但也发现了一些共通的问题，其中最大的一个就是风险管理。
有不少项目在前期根本就没有做风险识别，或者识别的风险缺乏跟踪，到项目执行中仍然会像放炮仗一样一个接一个的爆炸（前置时间分布图的长尾全是由这种发生的风险组成的）。其实风险管理作为PMBOK九大知识领域之一，管理和应对手段都很成熟了。
应对的思路就有“转移、接受、缓解、消除”四种，而我看到的情况通常都以“接受”为应对手段，赌这个风险不会发生，或者等一个Risk变成了Issue再去想应对方案。
风险识别不论是在需求优先级排序还是在架构设计上都是非常重要的一环，我们之所以把高价值、高风险的需求视作第一优先级，是因为我们希望尽早释放风险，尽早缓解风险。我们提的“简单设计”简单到什么程度，也是由是否能够涵盖最重大的风险作为边界的。
以虞待不虞者胜。
团队应当自组织，领导者应当负起管理者的责任
客户现场另外经常被提及的问题就是：“如何打造自组织团队？”“团队自组织了，我们经理怎么办？”
我的答案通常是：团队应当自组织，但领导者更应该负起管理者的责任。《管理3.0》中提到，授权有七个级别：从不信任到信任分别是：告知→贩卖→咨询→商定→建议→征询→委托。
作为管理者，打造自组织团队的过程也是逐步团队赋能的过程，团队成熟度不高而采取放任的做法，对于自组织的打造百害而无一利，反之亦然。所以作为管理者，最重要的责任就是在对团队赋能，当上面的四条团队都掌握了玩法，管理者就可以采取更高层次的授权了。
而所谓自由，就是团队的事务管理者不要管，团队外的事务管理者尽量多去做。区分管理者水平高低的点就在于如何判断一件事属于团队“内”还是“外”。
将能而君不御者胜。
《孙子兵法——谋攻第三》
故知胜有五：知可以战与不可以战者胜，识众寡之用者胜，上下同欲者胜，以虞待不虞者胜，将能而君不御者胜。
