在过去的十年中，我一直在倡导软件开发项目的 “80%解决方案”。我经常谈论这个话题，Ricochet团队的任何人都可以证明。我坚信，从整体上看，软件的成本远远超过了它应该有的水平–我相信帕累托原则，或者很多人都知道的80/20法则，是可以大大降低软件开发成本的秘密。
首先，什么是帕累托原则？
帕累托原则起源于意大利工程师、 会学家和经济学家维尔弗雷多-帕累托在19世纪提出的一个概念。帕累托观察到，意大利80%的财产是由20%的公民拥有的。快进到20世纪中期，管理顾问约瑟夫-M-朱兰（Joseph M. Juran）观察到制造业中大约80%的质量问题可归因于20%的原因，于是将其与帕累托的工作联系起来，创造了 “帕累托原则 “这一术语，作为一种几乎可以适用于所有地方的普遍规律。
比如说：
80%的车祸是由20%的司机造成的。
80%的税收是由20%的纳税人支付的。
你花园里80%的蔬菜来自20%的植物（信不信由你）。
许多公司80%的收入来自20%的产品和客户。
这样的例子不胜枚举，我相信，如果你花点心思，你可以在日常生活中找到很多这样的例子。可以肯定的是，这并不总是完全的80/20。有时是90/10。有时是70/30。但是，在大多数情况下，结果往往会落入这个简单的帕累托数据分布原则中。
由于它与软件开发有关，这里有一些我多年来观察到的例子：
软件中80%的错误来自于20%的功能。
在一个特定的应用程序中，80%的复杂性来自于20%的代码库。
在一个应用程序中，只有20%的功能集对80%的用户是重要的。
与前面的观点相反，80%的用户可能并不关心你的应用程序中的80%的功能（他们只关心20%）。
一个特定的工程团队把80%的时间花在20%的应用程序上。
这里是这个想法开始变得**强大的地方：
你80%的应用（如果你能摆脱*只做这80%）可以用20%的时间和预算开发。
这最后一点将是这篇博文的主旨。在允许利用这一概念和原则开发软件方面，有一些注意事项和危险。但我的主要论点是，如果你能解决我下面要讨论的问题，你就能更快、更省钱、更省心地开发软件。
但在进入我的论点之前，我想对软件工程师，以及实际上对一般人做一些大胆的断言。我想说的是，人类是善变的，容易产生认知偏差，产生意想不到的后果。而且，总的来说，利用我所倡导的范式会取得比其他方式更好的结果。
我想和大家分享一下我在领导和管理软件开发人员时观察到的一些事情（我自己作为一个工程师也有个人经验）：
当软件工程师对某件事情真正感到兴奋时，他们会对它的每一个方面都感到好奇。这种流动状态是很好的，但也会导致功能的过度工程化，对工程师来说，某些方面比对客户或业务团队要求的功能更重要。
软件工程师通常会从长远考虑。他们可能会建立一个功能，使其能够持续下去，而不管它是否*需要持续下去。例如，一个概念验证可能会在它被验证后被完全重写。或者，如果一个功能或应用无法获得牵引力，它可能会被完全扔掉。
不是软件工程师的人很难理解一个特定的应用程序或功能中的所有内容。这*可能会导致对软件开发中的成本缺乏责任感。即使是定义最明确的功能，软件工程师也会做出一些假设，而这些假设可能会花费大量的时间和金钱。如果要求该功能的业务团队能够理解其中一些假设的含义，他们往往会选择更简单的方法。但由于软件的开发方式，这些讨论往往不会发生。
一般来说，无论我们如何努力，几乎每个人都很不善于沟通。即使是最有成效的会议，在离开时问五个人同意了什么，你可能会得到五个不同的答案。这种错误的沟通导致了非常真实的成本。这对软件工程师来说也是如此。
过度工程化往往比工程化不足更安全。如果一个关键的错误进入了软件，或者一个应用程序在生产环境的负载下崩溃了，人们会把矛头指向工程团队。
在软件开发过程中，追踪某个特定功能的成本往往相当困难，更不用说某个特定功能的特定元素了。成本通常被看作是一个项目的整体预算都打水漂，或者更糟糕的是，作为一个组织的预算的某种固定成本（即工资）。即使是最好的团队，让工程师对一美元负责也是非常困难的。削减成本到我所倡导的水平需要有一种饥饿感，而不幸的是，大多数组织根本没有允许这样做的工具。
我确信有些人会对上述几点（如果不是全部）持反对意见。它们并不打算成为绝对的陈述。但我们可以说，它们在大约80%的时间里都是真实的；)
那么，让我们回到我的中心观点。如果你能让你的团队在功能层面上负起责任，并且你能激励他们通过明确潜在的权衡来确定降低成本的机会，从而让客户或内部客户决定额外的成本是否值得，你就能以更少的钱更快地开发软件。
此外，如果客户或内部客户能够帮助软件开发人员理解 “80%的解决方案 “可能是什么样子的，那么工程师在软件开发过程中就会成为一个更好的价值和成本的管理者。
如果这些事情是可能的，像下面这样的对话就会更频繁地发生。
“嘿，业务部门，我知道你要求的是X，这当然是我从你提供的设计中看到的暗示，但这导致了侧边栏中一些复杂的功能，这将需要相当多的时间来实现。如果我可以不做这部分，我可以在两个小时内完成，而不是10小时。这额外的一点功能值得花8小时的开发时间吗？”
在许多情况下，额外的一点功能根本不值得。如果明确了这一点，每个人都会同意。在一个软件项目的生命周期中，将其乘以1,000，你就会得到一些重要的节省！但缺点是什么？
但缺点是什么呢？
这种方法的主要挑战是，有时，80%的解决方案根本不够好，这是一个有效的观点。对此，我想回答的是，我并不主张单方面呼吁实施蹩脚的软件，左右逢源。相反，我主张*讨论*应该在哪里进行权衡。也许87%的解决方案是可以的。或者92%的解决方案。也许我们作为一个团队决定，在这种情况下，对于这个特定的功能，需要100%的解决方案。但无论如何，这些决定都可以作为一个团队，在一个业务和工程都能权衡的环境中做出。
公平地说，软件工程师往往不是最有天赋的沟通者，而且工程团队经常与那些必须与之沟通的人隔离，以真正释放这种方法的价值。但如果把沟通作为优先事项，这绝不是一个不可克服的问题。
接下来，我观察到，实现我所倡导的价值的最佳方式是对正在开发的功能有*非常明确的要求。这真的很难，需要在组织的许多层面上进行约束。仅仅提出一个功能的要点，并期望工程师们能够理解并弄清楚，这是非常诱人的。
但是，当项目的成功留给人们 “自己想办法 “的时候，事情总是需要更长的时间，需要重做，而且往往以一种不太理想的方式实施。你永远无法节省成本，因为你必须不断重做工作。而且，每个人（包括工程师）最终都会感到沮丧，这对事情没有帮助。
为了节省软件项目的成本，你需要一个环境，在这个环境中，每个人都真正清楚地了解需要什么，以及功能的价值。当这一点很清楚，并且清楚地传达给大家时，软件工程师就可以帮助大家聚焦瞄准20%的最有价值的东西，并把注意力集中在这上面。他们还可以提供新的替代方案，以进一步节省开支。但是，当环境是这样的，这是不可能的（而且，这需要每个人的大量工作，而不仅仅是软件工程师），使用帕累托原则是很难产生任何节约的。
综上所述，估算是出了名的难。对于任何给定的功能，特别是当它特别前沿和棘手的时候，很难真正看到未来，知道 “洞穴 “会有多深（如果你对洞穴一无所知，你甚至不知道该如何准备？） 每个软件工程师都有过被兔子洞蒙蔽的经历，那些具有欺骗性的复杂功能，在你真正深入到项目中之前，你永远不会怀疑，而且即使是团队花了相当多的时间来澄清的功能，需求有时也会改变，这也是没有用的。
该怎么做呢？
根据我的经验，有四种做法可以抵御商业客户和开发团队之间缺乏沟通的最坏影响：
著名的管理思想家彼得-德鲁克（Peter Drucker）曾说过：”被测量的东西就会被管理。” 在Project Ricochet，我们必须这样做，以便为我们的时间计费，我们使用的软件允许我们以令人难以置信的精细度跟踪我们正在进行的功能。为了设定明确的期望值，我们还为我们所做的每一件事提前做了估算。当我们第一次对我们的系统进行检测，使我们的工程师能够看到他们自己的 “准确度指标 “时，数字都是在地图上。
但一周又一周，在大约一年的时间里，我们能够解开无数的原因（组织、个人、职业、客户和技术因素都在其中起了作用）。今天，团队中的大多数成员在97%的时间里都在他们的估计值的5%以内（即使是在不同的人对有关功能进行估计时）。我也有一个平均调整的指标，考虑到原始估计的差异，这使我能够更好地指导工程师，因为我可以看到他们是否一开始就低估或高估了。
通过将这两个数字与功能 “拒绝率”（客户拒绝票据是因为需要解决的问题）进行三角测量，我可以知道一个软件工程师是真的快，还是仅仅是慢。
老实说，我对这些东西很感兴趣，而且以上这些都是经过多年的艰苦努力悟出来的，所以我的组织可能不能反映一般的组织，但我认为，允许人们进行估算，并让他们对最终的估算负责（超额完成是可以的！你只需要看看时间）。你只需要看一下所涉及的时间，并知道最终的结果是什么），随着时间的推移，将使工程师成为更好的估算者。
接下来，软件工程师需要认识到，他们不是在花自己的钱，因此，一旦*明显地发现某项功能需要的时间超过预期，就需要提醒客户或内部客户–并为剩余的时间提供最新的估计。
事情的简单真相是，在某些时候，该功能甚至可能对组织不值得（换句话说，”它在10小时时值得，但在100小时时不值得，因为我们在这100小时中只有20小时，让我们暂时停止，如果我们在项目结束时有时间，再来讨论这个问题”）。
为了使这一方法奏效，工程师不能因为诚实或低估而受到惩罚。他们需要感觉到作为预算的管理人，能够自如地分享他们的诚实评估。
关于沟通的话题，我发现，强迫团队就超过一定复杂程度的功能进行沟通，会产生很好的效果。并非总是如此，但通常情况下，软件工程师都想直接 “跳进去 “并开始工作。相反，我主张任何需要超过几个小时的工作的功能，都要求开发人员首先为该功能制定一个技术方案，并得到另一个在该领域有经验的工程师的认可。这并不是万无一失的，但它是防止从一开始就做出错误选择的又一层防御措施。
最后，软件工程师需要领导力才能做到最好。一个好的经理可以感觉到，当一个工程师陷入 “自负的陷阱”，并可能太爱他或她的代码，从而导致额外的成本和时间的延误。软件开发人员很聪明，因此评估起来也很棘手，但有经验的人知道这些警告信 。
不过，更重要的是，良好的管理为我上面提倡的开放和诚实的沟通奠定了基础。当有才华的人能够尽力而为，并在一个支持性的环境中取得成功或失败，那么你就能从他们身上得到最好的东西。好的经理人会帮助内部客户或客户顺利解决延迟和超时的问题。
他们帮助软件工程师在一段时间内负责任，提供资源、检查，有时在需要的时候粗暴地唤醒他们（以同情心传递）。如果你可以的话，请多雇用这样的人。他们是罕见的。
结论性的想法
说实话，我可以就这个话题谈上几个小时。我可以举出一个又一个组织利用（或不利用）这一原则取得戏剧性效果的例子。我见过不可能完成的项目在有限的预算下成功交付，也见过相反的情况：相对简单的项目拖拖拉拉。而且是不断的。即使如此，也没有完全达到目标。
现实情况是，软件的无形性使其在软件开发过程中具有某种固有的 “压迫性”。再加上几乎每个人的思维过程中都会出现的认知偏差，你就有了一个功能障碍的秘诀。
要想在预算范围内按时构建真正伟大的软件，你至少需要两件事：
一个真正参与的客户或项目负责人，准备投入工作，以确保需求明确，交付物得到验证，并尽可能快地解决误解。
真正致力于交付特定功能的价值核心的软件工程师，为了商业价值的利益，不怕提供明确要求的明智替代方案。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！