“赶工状态”与明星平庸化

在最近的一系列贴子中，James Golick 和 Reg Braithwaite 讨论了这样一个经常被置之高阁的事实，即陷入“赶工状态”的团队是如何导致不良结果的。讨论中提到了将压力施加于团队后产生的各种各样的情况，这些情况经常将项目推向更糟的境地；同时还讨论了团队和管理者如何使用不同的方法改变类似糟糕的处境。

James Golick 最初的假定条件是：通过将“全明星”程序员变成平庸之辈，开始采取“赶工”的方式，最后反而会导致整体生产率下降，这看起来极俱讽刺意味。Golick 的基本主张是：当开始加班“赶工”时，使得最佳程序员具备高生产力的习惯会首先被屏蔽掉。

在超级程序员与你千挑万选尽可能不雇佣的普通程序员之间可能存在一个巨大的差别：超级明星程序员以代码为先，而普通程序员最先考虑的是如何每天按时下班回家。当转向“赶工模式”后，他们的优先级就发生变化了。当每个人都为了在某个日期之前完成某些任务而加班加点、每天刚踏进办公室就开始想如何在这么短的时间里交付更多的特性时，压力就来啦。大家开始偷工减料，打破正常做事的步骤，写的测试越来越少，重构也越来越少。这时你的全明星团队就已经被你成功转变成一群平庸的程序员了。

Golick 进一步阐述了为什么对团队施加压力很可能产生负面后果：

当你将团队送上死亡之旅后，会很快让程序员感到疲惫，进而导致出现质量低劣的代码。而且，开发人员很可能变得士气低落，精疲力尽，对所做的东西根本提不起兴趣来。也许最糟糕的是你，因为他们开始对你的领导忿恨不已。在这种情形下，很多项目因为那些低级缺陷而令项目后期的修改和维护困难、更有甚者，会导致重新开发工作，这会使得赶工状态下的实际总产出反而更少。

为了避免“赶工模式”的缺陷，这个贴子还为程序员提供了以下两点建议：

1. 忘记压力。千万别指望通过放弃生产率为先的那些实践来节省时间。
2. 勇于说“不”。 你所能做的最负责任的做法，就是让利益相关者充分理解“赶工模式”要比保证质量前提下的正常开发付出更多的代价。

当“赶工”结束后，你就是那个收拾烂摊子的人，而且大家都知道根本没时间能收拾干净。公司也不得不处理这个低质量的软件，最终它很可能是被修修补补地发布了。给果，各方都是输家。

Reg Braithwaite 之前发布过一个贴子，其中也提到第二点建议，即“勇于说‘不’”。Braithwaite 认为，作为软件专业人才的你，有责任为完成你的工作而坚持使用某种方法。但在很多情况下，你最好还是调整一下来满足老板的需求：

如果承担决策后果的人坚持要我遵循他们的判断，我可以违背直觉做出让步……（另一方面）如果让我开发一个不可靠、并有可能泄漏私人数据的软件，我宁可说“不”。

为了响应 Golick，Braithwaite 提出：虽然很多经理认为“仅此一次而已”，但许多“赶工状态”的出现并非例外情况。Braithwaite 强调：如果“赶工”状况频繁发生，或者本可以通过事先计划而避免，那么发生“赶工”就不是例外。许多管理层和开发人员将“赶工”的发生或者项目的失败归咎于“未列入计划之事”而一笔带过，Braithwaite 亦对此提出了严重质疑。

我也许无法确切知道会有什么缺陷，但是从统计学上来看，我知道一定会有缺陷，需求会成为焦点，而估算仅仅是估算。我无法对我的老板说：“我不知道他们 这么做是想要那样的结果，我也不知道这事儿会没按我们预期的方式发生，因此，我们得在没有测试的情况下赶紧把活干完。”我可以——而且确实——预见到这些事情会发生，所以我可以——而且必须——为这些事情做计划。

关于在敏捷项目中如何避免“短路”，请查看 InfoQ 的这篇文章以了解更多观点。

查看英文原文： Crunch Mode And Making Superstars Average