最近有个 Tweet，说项目延误时，如果同时又有很多人插手会使事情变得更糟糕。大多数团队碰上截止期限都会干三件蠢事儿：1、雇佣更多开发人员。2、抄近路。3、工作更长时间——— jasongorman

这自然就产生了个问题：如何拯救即将延误的项目？

其实，首先，最困难的问题，就是我们也许无法拯救即将延误的项目。所以，我不得不重新考虑策略，只有两种方式我们可以考虑：

1. 延期到一切准备妥当
2. 先把做好的展示出来

现在不是讨论团队如何和自己的消费者周旋，当我说 “少提供点儿”，我指的是少做些 “程序”——程序多不代表有价值，多关注用户核心需求才是正事儿，其实就是别把一开始准备的那成堆功能递出来。

这个过程差不多就是：“房子无法按期完成，但是你能如期入住。”

如果你做的是 敏捷软件开发，估计现在已经发生了。如果还没发生，说明你恐怕做的不是 敏捷软件开发。

解决方法就是要求我们知道最终目标也许跟程序无关。你得把关注重点从展示功能转移到解决问题。然后你就能给自己带来设计的空间。在有限时间里更多选择能够成为解决问题的有效方式。

当我临危受任时，我首先做的就是停下手头一切，退一步问自己：“我们走到这儿到底想要什么？有没有更简单的方式？” 所以准备随时去掉设计和计划。在我个人拯救濒死项目的经历中，这是关键。面对客户，准备些充分又坦率的对话。

但是，从 Tweet 的那三项注意事项里，我们能得到什么启发？甚至让项目时间延期。

雇佣开发人员早已被证明只会让事情变得更糟

在 Fred Brook 在图书 The Mythical Man-Month 中对雇佣过多开发人员会加剧问题做了细致的原因阐述。我相信任何软件开发者和软件开发项目经理都该读读。

做着糟糕产品的开发人员现在转变去催促着新的开发人员。这就像让最有效的销售人员充当管理角色，结果就是看着销售量直线下降!

想要指标数值激增，最重要的就是团队内部都知晓每个人正在做什么，可悲的是，这在软件开发中是必要的，因为联系是普遍存在的——最需要进行斗争的就是失去最具生产力身居要职的开发者和大体量团队效益的迅速递减。

因此，最简单的建议是别去做。不管你如何想要，或者承受上级多大的压力，千万不要这样做。

但如果队伍已经很庞大了呢?如果未完成任务的原因是因为团队开销拖你的后腿?在这里，你可能不得不做出非常困难的决定，把相关人员转移到其他项目——或把挡在路中间的无关人等放一边，再不行最后只能辞退一些员工。

如果你有点儿头重脚轻，或有太多实习生，有可能能承受这种打击。另一方面，假设有 3 个建筑师、 2 个项目经理、 6 个技术大神、4 个业务分析师、 30 名开发者和 10 名测试人员——就我个人而言，很多的人正在享受实际工作福利。他们抱着酬劳，很多人很高的酬劳，但只是不为团队带来一点儿价值。你付钱去让他们拖累你。我们都知道，但很少有人敢说出来。

在团队显然太臃肿的情况下，当你想要提供客户需要的有价值的东西，只有精简团队，否则几乎不可能。

雇佣、重新分配或解雇这类有风险的决定通常不是我们这些人能够决定的，不过这种情况还是得有人先打头哨。在这些情况下，默认行为是完全知情还选择失败。其实，这也是为团队好。

抄近路是经典错误，只要我们知道雇佣更多开发人员只会让事情变得更糟，我们更得知道牺牲质量只会拖慢我们未来的发展。

原因很简单，证据确凿如就像活生生的喜马拉雅山脉。解决 Bugs 的时间越长，就会花费成倍的时间和金钱。前期不注重测试和实验，未来修复 bug 就需要 10-100 倍的时间，不如早些解决，免得下游海啸发生为时已晚。

你可以让团队专注”code-and-fix”发展进程，不用在意 bug 列表的大小，而把大量时间和精力用于”稳定”应用软件，做好投放市场的准备。我目睹过圈子里几个月周而复始写代码，只为使其足够好到可以应用。

所以内行都知道当团队或计划延误了，就需要更严格地做更多测试。是的，现在才刚刚开始，但之后你会节省 10-100 倍的精力。

当然，软件开发中没有银弹。但当你想让团队走上正轨时，我见过最管用的方式是创建快速自动运行的测试机制。它可以完全改变前景。

同样讨论到Specification By Example ，我们认为用户需求会产生革命性的影响。你会惊讶当你向别人询问具体例子来阐明他们需求的这种行为会产生多少误解。用可执行验收测试认清用户需求花费几个小时可以防止你接下来一周内不必要的返工。

代码的可维护性也是一样。因为对代码的简易性和容易改变 (不可攻破) 思虑 不周或少了关心，其未来的护理成本比想象中来得快，来得让人心疼。我发现自己早上写的代码阻碍了我下午的进程。

打高尔夫球时，要想更快获取高分关键是不要太在意进了多少杆。

这对团队工作人员和管理人员都是很难的。众所周知的神话定律——用更多时间来做更高质量的应用软件，还是存在的。最需要学习的新技能是学会如何预防缺陷和做”干净代码”。如果团队没有在规则和演习中准备好 “向上加速”，那么，说真的，你可能觉得别扭，因为你已经有几个月 (可能几年) 都不知道如何学习了。

想要知道一个团队是否具备基本技能，扪心自问，为什么这些还没有做？如果答案是”老板不让我们做”,那么另一个隐患的种子就埋下了。我的个人经验，也是从别人的遭遇得到的忠告，最好不要出现上述对话。否则，那意味着团队已经迷失了。想要事事顺心可不容易。然而，如果让管理者和消费者在功能和质量间选择，他们中间 99%的人都会投”功能”否决票。除此之外，选择牺牲质量也会降低功能性。事实上让团队在这两种感知冲突中做出选择本身就意味着失败。

所以当程序发布时间临近，切不可在质量上让步。最好的方式就是不要在团队以外讨论这个问题。举个例子，要是你做驱动开发测试 (TDD)，这就是能起作用的方式。就像用文本编辑器一样。上次你向老大要求使用文本编辑器是什么时候？

当计划出现纰漏时，你更应该在质量上下狠功夫。如果你在初期阶段，尤其是初次尝试；如果你每天都在建设和测试，甚至每小时；如果你平均投入 20 分钟与客户讨论一个用户故事，花一个小时和同意可执行的测试，包括所有您能想到的边缘情况；如果你为了集中做单元测试，10 行代码平均一个单元测试；如果你平均在每个迭代中进行团队代码审查，做每次提交之前进行同行代码审查，等等。

最后，工作更长时间——就我们在上世纪进行的调查显示，这是不稳固的，还会伤害团队和计划，一个错误的经济体。回到亨利福特那个时代，就是他把工厂工人工时从一周 50 个小时降至 40 小时的那时候。我们有更多需要做，我们得让工作有效率，产生有用的输出。

程序开发尤其易受影响，当我们把团队置于”危机模式”。程序开发需要注意力和清晰度，而注意力、清晰度是需要经常补充的易腐货物。从我自己的团队实验中，发现开发人员平均一天 4 小时就是极致，8 小时算多的，要是比 12 小时还多会怎样？

有些人会说”在短期内是可行的”,但我至今没发现任何有力证据可以证明这是可行的。也许装配线工人可以为了多轮几班，但软件开发不是这样的。

我们非常容易被生产力的错觉影响，我觉得这解释了 “短期内是有用的” 的说法。当然，感觉好像什么都没完成。那时我们不知道在前进道路上犯下的错误产生了多么严重的下游后果。一天八小时工作时我才意识到，越是客观地管控，越是犯更多错。所以，我提前学到一招能给同样境遇团队带来好处的方法。在你从 “流动区” 去往 “责任” 区的路上，学会认知。

所以，我对团队超时工作处于零容忍，甚至短期之计也不行。

是的，对管理层来说这是很难的。并且许多开发者还因为自己生产力的错觉眉飞色舞呢。现在真是箭在弦上，每个人都疯狂地火力全开，晚上 5、6 点安静地从工作桌前站起来，回家。确实，这是目前我发现唯一你能做的。

同样，最重要的是更加集中注意力，并随时保持最近更新状态。学会休息，学会来顿轻食午餐（最好不要有太多让你昏昏欲睡的碳水化合物）。要把格外勤奋放在合理的时间，找到工作与生活的平衡点。

然后在别人才会注意到你在办公桌前的成绩而不是花费多少时间在公司。有件事一直很讨厌，就是很多组织都在倡导长时间的工时。然后在会议和非正常工作环境，如开放的办公室等无意义干扰下欢快地燃烧。我企图在两者之间发现强烈的关联性。想做更多？注重工作环境而不是工作时长。

所以接下来给了你一个总结，用来提升你在发布日期推出产品的成功率：

1. 管理好你的产品预期和什么时候推出。简化产品，简化方案。专注最终目标，而不是赚多少。
2. 抵制住雇佣更多开发者的诱惑。如果你的团队已经很庞大了，这将是个艰难的转变。
3. 拨通质量专线，专注不可攻破的质量。
4. 工作时间少些，多休息。不要把注意力放在花费多少时间，而要注重效率，把前进路上的障碍都移除，比如不利的工作氛围。当然，为了安全起见，大多数团队不敢去尝试。说起来容易，做起来难。现实中，要想实现这一切需要有股坚定的领导力形成具有凝聚力的团队来促成这一切发生。
5. 有力且有技巧的领导力

这并不一定意味着其他人都跟我一样有自信这样与团队斗争（虽然我已经做了很多次）。但不知何故，从内部深处，团队需要在关键问题上找到这个实力和自信，如范围、期限、团队规模、工作时间、办公环境等。这让你对发布产品产生责任感：如果这必须奏效，想要成为巨擘就必须谨记伴随而来的责任。

祝你好运！

作者@孙应然    文章来源@36氪

本文编译自：codemanship.co.uk