第一章 项目管理失当

    作者注：这是常被人们忽略的最关键的一点。自愿的长时间工作跟死亡行军绝对是不同的。

    信心在进程中消失。稍微有点智商的人就能意识到，死亡行军是对出现的问题的一种补救。这样做对于我们的员工、客户及合作伙伴来说不是奉献，是个人能力出了问题。只是埋头工作，回避真正的问题，只会更有损于他人对我们合作能力的评价。

    不妥善解决问题。工作更长时间不能解决那个真正导致“在太少的时间内要做太多事”的问题。除非这个问题根除了，否则别指望项目除了变得更坏之外能有其他进展。

    降低你的标准。当你已经走了捷径，引入了糟糕的设计和计划，产生了大量的返工和缺陷，打乱了你的信息沟通，怂恿大家相互挑刺，挫伤了员工的士气，摧毁了我们对交付能力的信心，结果还是无法达到质量目标和按期交付（以前遗留下来的任何问题都没有得到解决）时，你就别无选择了。通常这会导致降低质量门槛，将计划延后，然后继续死亡行军。“干得好啊！”

    转折点

    那么，如果你发现自己正面临着“在太少的时间内要做太多事”的情况，你应该怎么办呢？从务实的角度出发，答案非常简单，就是要搞清楚，为什么你会要做这么多的事情，而你却只剩下这么少的时间了。

    答案不是“因为那是管理层设定的日期和需求”。为什么管理层设定那些日期和需求呢？如果你完不成某个需求，或者不能在某个日期按时交付，管理层会做什么？他们会将计划延后吗？延后多少？他们会减少功能需求吗？哪些功能会被减掉？你是否还能在过程或方法上做更多的根本性改变，以求力挽狂澜？告诉管理层，你的目标是达到所有的需求并按期交付，但你必须为最坏的情况做好打算。

    然后为最坏的情况做打算。按可接受的最迟交付日期及最少功能制定一个计划。如果在有效时间内还是因为任务太多不能完成，就全面拉响警报！你的项目已胎死腹中。如果你为最坏情况所做的计划是完全可行的，那就要全力以赴。告诫你的员工，勤勉者可以在考核时得到3.5以上的分数，但偷懒者的分数必定在3.0以下。

    作者注：这些数字源自于微软老一代的评分系统，分数取值范围为2.5~4.5（分数越高，奖励越丰厚）。分数3.0是可接受的，不过大部分人都想追求得到3.5或者更高的分数。

    不寻常之路

    你所做的努力使得项目避免了死亡行军，并且赢得了宽松的时间来改善。你的团队很可能比最低要求走得更远，但他们做到这些并没有走捷径，也没有做糟糕的决定或自相残杀。你将按时交付当初承诺的东西，并且使你的合作伙伴和客户建立起信心。

    这听起来倒是合情合理，但其实在情感上很难接受。为最坏的情况做打算感觉像要放弃一样。你像是在示弱，好像你无力应对挑战似的。多么具有讽刺意味啊！事实上，情况恰恰相反。

    不面对危机是懦弱的表现。假装最坏的情况不会发生，也只是自欺欺人和不负责任。拿出你的勇气来，面对现实！做事机灵一点，别在最后还要把痛苦留给你的合作伙伴、客户和员工。相反，这样体现了你的价值，你的团队、你的生活、你的自尊毫发无损。

    作者注：在最近长达9个月的项目中，我的团队在关键的依赖性服务上拖延了3个月时间才完成整个项目，同时我的团队将原本要4个月时间才能完成的主体功能模块缩减为1个月来完成。我们不能延迟时间表也不能削减软件功能模块（我们已将这两者向客户做出承诺）。我们并没有经历死亡行军，相反，我们直接投入到一个与依赖性服务相关的开发环境中同步进行工作，就像这些服务已经完工一样。这种策略不仅补回了之前过多消耗的时间，而且减少了返工次数，因为我们可以在工程创建的早期就将回馈反应给依赖性服务开发团队。在客户相当满意的情况下我们及时发布了软件。事情很艰难而我的伙伴们工作很努力，但是他们同样有宽余的时间并感到快乐，他们只是出于对发布高质量产品的渴望及为他们的同事提供帮助的心愿。在产品发布后，我们没有一个人离开团队。