软件项目开发中的三个“不应做”事项

文化&方法

摘要： 大量的项目经验表明，仓促进入开发阶段的软件项目注定会失败。在不破坏时间表和超出预算的情况下，要交付质量合格的项目，关键在于做好估算和预先计划。

作者： Lawrence Putnam Jr

审校： Shane Hastie

正文：

本文要点

• 项目未按时间表完成，或是项目超出了预算，这是导致很多项目失败的原因。前期对项目做出预测，有助于避免从一开始就做出不切实际的承诺。

• 在做出详细规划前，自上而下、基于范围的估算要比自下而上的规模估计和“猜测”更为有效。

• 当项目处于初始规划阶段和推进阶段时，自上而下的估算工具有助于确立切合实际的项目边界。这对于设定期望和让利益相关者满意是十分关键的。

• 通过过度增加人员实现压缩时间表，在很多情况下实现代价高昂，并且常常是无效的。项目经理可以使用自上而下的估算，对投资组合中的适当人员配置和资源需求做可视化。

• 当项目由于利益相关者的需求或一些不可预见的情况而发生变化时（当然，项目不可避免地会发生变化），项目经理应重新做出预测，进而用于更新计划。

人们通常对“未雨绸缪”一词了然于胸，那么为什么企业却难以遵循这一原则呢？或许是因为人们已习惯于“快速行动起来完成工作”的做事方式。

问题在于，过快的项目推进实际上会导致成事不足，给软件项目带来很大的问题。面对来自于高层的压力，项目经理很可能转而采取仓促行事，跳过项目估算和前期规划。但是从我自身30多年的软件项目管理经验看，一个仓促进入开发阶段的项目很有可能注定会失败。

早在上世纪80年代，柯达曾致力于实现一种由软件驱动的文档成像解决方案，以此实现胶卷业务的多样化。企业在花费了一年半的时间、投入了数百万美元和大量的人力资源建立系统之后，他们找到我来做项目估算。估算结果显示，完成项目还需要两年的时间，并且还要投入更多的资金。如果预先做了项目估算，那么企业就有机会更好地评估项目的上市时间和投资回报率。反之，整个项目偃旗息鼓，浪费了宝贵的时间和资源。

一位同事曾与我分享过一个类似的悲惨故事。据他讲诉，几年前正值圣诞假期，一位顾客要求他在假期前提供一组合计22个估算。他们并不认可他给出的数据驱动估算，因此决定采取自己的方式。正是由于不合理的期望和时间表，他们的项目最终失败了。他们最终还是回头找到我的同事，按他的方式去正确做事。真应该祝圣诞快乐！

当前，一些企业也在犯着同样的错误。最近，一家企业开展了一项大型高强度软件开发项目。尽管他们扩充到100多名开发人员，但是由于内部压力以及一些不切实际的短期疯狂计划，他们决定放弃系统集成测试。由于缺少对质量影响和赶进度开发机制的评估，他们最终遗漏了很多系统缺陷。现在，企业正在重新做评估，一切从头做起。

当然，我们没有理由让历史继续重演。如果项目经理能关注那些“不应做”的事情，是可以避免一些会导致成本和时间超支的缺陷的，并给出创造真正价值的解决方案。

事项一：不应跳过估算匆忙进入详细规划，应采用自上而下的估算方法。

任何形式的计划，都好过完全没有计划。自上而下的估算，为详细计划过程提供了有价值的输入。

根据我的个人经验，设置不切实际的期望是项目失败的主要原因。制定准确的目标是企业的核心竞争力，但不少企业尚做得不尽如人意。

部分原因在于，企业在估算项目规模时，倾向于使用传统的范围界定过程，这往往会给出不准确的预测。项目经理在编制项目范围时，传统做法是采用一种自下而上的方式。管理者要求每个团队成员估算自己在特定活动中的工作时长，并根据这些“假设”确定每个成员的日程安排。不幸的是，这种自下而上的过程中缺少了一个关键的因素，那就是“事实”。一项基于QSM项目完成情况数据库的研究显示，有三分之二的公司未能比较计划的绩效与历史上类似项目的实际绩效。比较工作可让团队更好地了解完成工作所需的时间、精力和资金情况。他们竭力做出的估算，也许会导致错过最后期限、成本超支、客户不满意，以及开发人员被剥夺权利。

如果项目在开始时采用了自上而下的方式，那么一种非常有效的策略是基于范围的估算。借助于类似项目提供的数据，管理者可以准确地给出完成工作和交付完成工作产品所需的工作量。他们从一开始就全面了解项目的各项功能，并相应地分配资源。

当项目处于初始规划阶段和推进阶段时，自上而下的估算工具有助于确立切合实际的项目边界。如下图所示，一位项目经理具有一个由10位开发人员组成的团队，团队正在进行一个为期五个月的发布周期。在整个工作过程中，模拟软件显示了细化的Backlog，其中给出了需要完成的约100个Story点。

进一步分析表明，尽管项目经理对团队生产力和劳动力成本的初步估计是有效的，但他可能无法将新的功能添加到建议的时间表中。由于计划是固定的，为了满足利益相关者的期望，项目经理需要聚集于如何调整产品功能和能力。团队可以使用模拟软件衡量实现所有100个Story点的概率。也许实现80个Story更现实，也许可以实现70个Story。无论实现的Story数量多少，至少这是利益相关者可以预期的。

其中并不存在任何主观猜测，一切估算都是基于经过验证的数据点。因此，自顶向下的估算方法可比传统的估算方法给出更准确的估算。团队可以设定准确的期望，在难以管理的时间期限内达到客户满意，降低开发团队交付解决方案的压力。

事项二：不应因为最后期限迫近，而做出增加员工的决策。

“厨子过多，反而做不出好的肉汤”，这是另一件人们常说的事情。然而，在面对日渐积压的最后期限时，许多项目经理的第一反应是为项目配备更多的人员。他们秉持的理念是，做事的人越多，事情完成得越快。

当然，这种做法几乎不会很好地发挥作用。为项目添加更多的资源，通常提高了项目的复杂性，并增大了出错的机会。更多的人员会导致沟通的不畅，这可能会增加缺陷，并导致返工。实际上，更多的人员通常会导致项目耗费更多的时间，而非节省时间。

项目经理可以使用自上而下的估算，对投资组合中的适当人员配置和资源需求做可视化展示。估算可在一段特定的时间内按计划和月份进行细分。他们甚至可以将员工按支出率划分，并与预算限额做比较，确保员工适合于特定项目，或是匹配组织当前的和未来的容量需求。下图可视化展示了估算随时间变化的情况。

事项三：不应为计划所奴役。

事先做好计划，并不意味着团队在整个开发过程中都无法改变方向。即便给出了最好的计划，但是大多数项目在其生命周期中，不可避免地会遇上一些未知因素，或是需要重新确定优先事项。或许管理层会要求添加一些新功能，或许一些团队成员将被转到其它更为关键的任务上。

不确定性虽然随时可能出现，但是它可以纳入到自上而下的计划过程中，从而降低其潜在的影响。本文前面给出的项目例子就是一个很好的证明。不确定性在于团队可能无法达成100个Story点。在计划中预先纳入这些不确定性，有助于规避项目早期的突发变化。

在整个开发过程中仍然可能存在一些波动，其中的大部分是由于利益相关者的需求的不断变化所导致的。例如，客户可能需要一些新的功能，以满足不断变化的市场动态。这些需求将不可避免地对开发产生直接的影响。团队需要在尽可能维持最初共识的情况下，做好调整的准备。

不幸的是，当前进的道路上蹦出这些意外障碍物时，许多组织不知道如何做出调整。估算是易于上下微调的（因此称之为“估算”），并且可以通过重新预测去适应不断变化的需求和动态。优先事项也是可以完全改变或移除的，以适应新的工作需求。项目范围也可以做改进，为利益相关者提供切实可用的更新后时间表，使项目保持正常进度。调整是一个动态的过程，可与组织推动敏捷开发的过程紧密结合。

做任何事情都一样，沟通在整个调整过程中至关重要。显示在屏幕上的数字在利益相关者的眼里无疑是福音，即使这些数字在开发过程中会发生波动。项目经理必须能够在项目一开始就有效地让利益相关者明白，他们的开发估算可能会根据许多因素而发生变化（具有讽刺意味的是，大部分因素都是由利益相关者的需求驱动的）。

此外，项目经理还必须表明，估算是在给定时间点（即项目开始时）对项目范围的一个最佳表示。团队将会努力按时、按预算，最重要的是按预期设计，交付所需的功能。

最后一点，也是最重要的，是我们应从以往的错误中吸取教训。这并非仅是将当前的项目与过去的一些努力做比较，而是应从柯达以及其它一些采取了错误步骤的组织中学习。一开始就做好计划，而不是遵循传统规范。这样，项目经理和开发团队才更有可能在不破坏时间表或超出预算的情况下，以客户期望的质量交付满足客户价值的软件。

作者简介

Lawrence H. Putnam,Jr.是QSM的联合首席执行官。QSM是一家软件过程改进和系统开发评估领域的引领企业。Larry的主要职责范围是监督QSM产品业务的战略方向，包括实现收入目标、战略产品方向、客户关怀和研究。Larry在软件测量、估算和项目控制方面具有25年以上的经验。他于1987年加入QSM，历经企业业务的各个方面，包括业务开发、客户支持、专业服务，已经当前的执行管理。

查看英文原文： Three Things to NOT Do with Your Software Development Projects