效率是输家

专注于效率而忽略有效性是大多数软件项目失败的根本原因。 有效性正在产生预期或预期的 结果 。 效率是实现工作的时间和精力最少 支出的能力。 有效的软件项目可提供最终用户所需的代码； 高效的项目以最少的资源和时间来交付该代码。

有时，我们变得迷恋于我们可以衡量的东西，即项目结束日期，kLOC，以至于我们以某种方式忘记了我们最初构建的东西。 当您仰望鳄鱼时，很难记得您在那里排干沼泽。

效率只有在您保持有效的情况下才重要。

50年后，有关软件的三大最终用户投诉是：

1. 花了太长时间
2. 花费太多了
3. 它不能满足我们的需求

薪水是大多数软件项目中最大的成本，因此，如果花费的时间太长，那么它将花费太多，因此我们可以将投诉减少到：

1. 花了太长时间
2. 它不能满足我们的需求

第一个问题是对我们效率的抱怨，第二个问题是对我们效率的抱怨。 在继续研究效率和有效性之间的相互作用之前，请确保我们对这两个问题具有通用的定义 。

我们到了吗？

如果错过项目结束日期，您会迟到吗？

这取决于您的观点。 考虑一个具有良好工作分解结构的明确指定的项目（即良好要求），主管建筑师估计该结构将使一支由10名开发人员组成的主管团队至少花费15个月来构建。 让我们考虑5种情况，除了以下所述，这是正确的：

项目在什么情况下迟到？

答：高级管理层给团队6个月的时间来构建软件。
B.高级管理人员分配了5名胜任的开发人员团队，而不是10名。
C.高级管理层分配了一个由10名未经训练的开发人员组成的团队 D.您拥有正确的团队，但是，每个开发人员都需要花费20-35％的时间在另一个旧系统上维护代码 E.该项目已按预期配备人员

以下是表格中的上述情形：

＃	球队	资源资源 承诺	给出的月份	结果
一个	10名合格的开发商	100％	6	不切实际的估计
乙	5名合格的开发商	100％	15	人员不足
C	10位未经训练的开发人员	100％	15	未经训练的人员
d	10名合格的开发商	65-80％	15	团队承诺
Ë	10名合格的开发商	100％	15	晚了

仅最后一个项目 （E） 较晚，因为结束日期的估算与可用的项目资源一致。 错过结束日期时不会 迟到的其他众所周知的变体：

• 项目结束日期是宣布的SWAG或管理层
• 项目要求不佳
• 您告诉最终用户10个月的估计时间是15个月。

如果缺少项目E的任何条件，那么您的估计就会有问题。 您可能仍会迟到，但不是基于错误假设计算得出的项目结束日期。

当然，如果你实现预期的系统的一个子集迟到是可以接受的。

它不起作用

“它不能满足我们的需求”是无法满足最终用户的需求。
我们如何确定最终用户的需求 ？

系统的要求来自多种来源：

1. 终端用户
2. 销售和市场营销（包括竞争对手）
3. 产品管理
4. 工程

这些初始要求很少会相互一致。 实际上，这些构成要素中的每一个都会对要求有不同的印象。 您希望原始要求是
地方矛盾 。 信念就像左边的四个圆圈，并且它们的信念的交点将是黑色的区域。

需求的不同来源不同意，因为：

• 每个人都有不同的观点
• 每个人对构建的东西都有不同的看法
• 每个人都有表达自己需求的不同能力
• 产品经理具有综合一致要求的各种能力

产品管理的工作是将不同的观点综合为一组一致的需求。 如果工程在要求一致之前就开始了，那么您将结束许多消防会议并浪费时间。

在需求足够一致之前就开始了许多项目。 我们希望初始需求是需求的一部分。 实际上，我们错过了需求，并包含了不需要的需求（请参阅文章底部，Capers Jones的数据）黄色圆圈代表我们已捕获的内容，黑色圆圈代表实际需求。

当我们开始一个项目时，我们很少有一致的要求，这就是为什么下面的漫画在互联网上存在不同形式的原因。

如果您不执行以下所有操作：

• 面谈所有利益相关者的要求
• 通过产品管理吸引最终用户表达其实际需求
• 综合一致的要求

这样您将无法构建正确的软件。 因此，如果您跳过任何一项工作，那么您一定会得到答复，“它不能满足我们的需求”。

有效性与效率

因此，让我们重复一下用户的抱怨：

1. 花了太长时间
2. 它不能满足我们的需求

可以延迟交付正确的软件。 如果该软件无法正常工作，则无法按时交付 。 如果要成功交付软件项目，那么关注效率比效率更重要。

效率低下源自无效

大多数组织在开始软件项目之前不会测试其要求的有效性或完整性 。 需求被转换为项目计划，然后项目经理将尝试执行项目计划。 项目计划成为圣经 ，每个人都朝着它前进。 只要任务按时完成，每个人都认为您是有效的，即做正确的事。 直到几乎所有任务都以95％的速度完成，而项目远未完成。

在某些时候，有人会注意到一些事情，然后说：“ 我认为此功能不应该这样工作 ”。 这将引起开发人员，质量保证和产品管理人员之间有关正确程序行为的讨论。 这将引发一系列消防会议，以解决不一致问题，发出缺陷并解决问题。 所有额外的会议将开始导致项目计划中的任务延误。

我们在上一篇博客文章中讨论了消防的根本原因。 当灭火开始时， 生产力将停顿下来。 开发人员将因最终陷入无休止的会议而失去生产力。 此时时间表开始打滑 ，我们成为重点项目计划和最后期限。 范围缩小以帮助项目截止日期； 不幸的是，在这一点上，我们倾向于将有效性抛诸脑后。

幸运的是，项目和产品经理可以找到一种方法来缩小范围 ，以在错过原始期限后宣布胜利。

有趣的是，项目在启动之前就失败 了 。 失败的真正原因可能是需求不一致。 但是，在混乱的消防和无休止的会议中，没有人会记住要求是问题的根本原因。 需求不佳的代价是什么？ 幸运的是， WWMCCS有一个答案。 作为军事组织，他们必须详细跟踪所有内容，并对每个缺陷（图表）进行根本原因分析。 该图显示了我们所知道的真实情况。
– 发现需求问题所需的时间越长，修复起来就越困难且成本更高！
– 如果需要修正到系统测试，则需要花费1个小时来解决的需求将花费900个小时来解决。

结论

在项目过程中关注效率比效率要重要得多。 当很明显您不会确定项目的结束日期时，您需要专注于构建正确的软件。

您是否厌倦了以下循环：

• 收集不一致的要求？
• 根据不一致的要求制定项目计划？
• 估算项目并让高级管理层不相信它？
• 关注项目结束日期而不关注最终用户需求？
• 消防要求不一致吗？
• 从无休止的会议中失去开发人员的生产力？
• 不仅错过了结束日期，而且没有满足最终用户的需求？

组织在期望成功项目的过程中不断经历这个循环的事实是精神错乱-现实世界中的迪尔伯特卡通。

您要漂洗几次并重复此过程，直到尝试其他方法？ 如果要中断此周期，则需要开始收集一致的需求。 考虑以下情况对您的职业的影响：

1. 您错过了截止日期，但建立了最终用户需求的一部分
2. 您错过了截止日期，而没有最终用户的需求

您至少可以在情况1中宣布某种胜利 ，并且简历不会受到太大影响。 无论如何分割，都很难弥补方案2。 另外，您可以通过在开始开发之前确保需求一致来节省浪费的时间。 不一致的要求将导致项目后期的灭火。

作为开发人员，当您处理需求时，团队应着眼于寻找不一致的需求。 整个团队应仔细研究需求并寻找不一致之处，并在开始开发之前强制产品管理人员对其进行修复。 这听起来像是在浪费时间，但是它将把需求不佳的问题推回到产品管理中，从而使您不必参加无休止的会议。 培养耐心坚持良好的要求会降低血压并帮助您晚上入睡。 当然，一旦获得良好的需求，就应该坚持进行适当的项目估算。

没错，我是所有人中最大的“失败者”。 我相信我在书中至少犯了一次错误：-)

参考： 《 加速发展》博客上的JCG合作伙伴达利普·玛哈尔（Dalip Mahal）指出， 效率代表失败者 。

翻译自: https://www.javacodegeeks.com/2013/05/efficiency-is-for-losers.html