有幸在2020年从事软件工作，我经常听到以下想法的变种：
- '你的工作和客户价值之间必须有某种直接关系！
- ''你的行动结果必须是可衡量的！'
这些想法体现在这样的陈述中，听起来非常合理和有道理：
- '这对客户没有好处。这对客户来说不是一个特点。所以我们不应该这样做。
- ""我们的业务不在做X，所以不应该关注它。
- 业务是为客户提供服务
- ''这并不能改善我们确定的任何关键指标'
我想挑战这些想法。事实上，我想颠覆他们的想法：
- 许多人的工作通过关注那些看起来没有可衡量的或明显合理的客户利益的事情来产生价值。
- 此外，对这些问题的判断是人们被（而且应该）支付的工作。
亚历克斯-弗格森和食堂设计
为了概括这些想法，我想用体育界的一个轶事，这个成功和失败的残酷实验室。在这个领域，曼联（英国足球队）的经理亚历克斯-弗格森在1986年至2013年的 "黄金时代 "的记录是无可指责的。在这27年里，他把他们从1986年的英国超级联赛积分榜倒数第二名带到1998-1999年的欧洲三冠王。
幸运的是，他在各种书中记录了他的回忆和教训，这些书提供了一个伟大的洞察力，让我们了解这样一个领导者如何思考，以及他们的报酬是什么。
现在，在外人看来，他应该努力的'商业价值'是显而易见的。赚取利润"，或 "赢得奖杯"，或 "每场比赛进球多于失球 "的某种变体，是我们大多数人都会想到的表述。显然，这些目标细分为一些子目标，如：
- 廉价购买球员，并从他们身上获取比你所支付的更多价值
- 针对你的对手优化你的战术
- 让球员努力工作以保持体能和技能
同样，我们这些凡人可以猜到这些。弗格森的回忆录真正吸引人的是他所关注的其他事情，对于我们这些不是精英级足球专家的人来说，这些事情不太明显。
有时，如果我看到一个年轻球员，一个学院里的小伙子，自己在吃饭，我会去坐在他旁边。你必须让每个人都有家的感觉。这并不意味着你要对他们心慈手软，而是你要让他们感觉到自己的归属。我从马莎百货公司学到的东西对我产生了影响。几十年前，在困难时期，马莎百货公司给他们的员工提供免费午餐，因为他们中的许多人不吃午餐，这样他们就可以节省每一分钱来帮助他们的家庭。对于一个经理来说，这可能是一件奇怪的事情--在一个新的训练场上布置一个食堂--但是当我想到它在俱乐部内部定下的基调，以及它鼓励员工和球员互动的方式，我怎么强调这个微小变化的重要性都不过分。
亚历克斯-弗格森，领导
现在，我请你想象一下，曼联的产品经理，或者scrum master和他一起研究这个 "更新"：
- 把你的时间花在小球员身上，如何帮助我们在周六取得更多的进球？
- 我们的业务是食堂建筑还是足球比赛？
- 你如何衡量这些外围活动的好处？
- 我们有付费的专业人员来做建筑设计，你为什么还要进行微观管理？
- 我们应该在每个冲刺阶段为你的初级1-1球员和建筑监督分配多少故事点？
很容易想象这种对话会如何进行，特别是考虑到弗格森以健谈平实著称。(链接的文章也是一个隐藏在看似粗暴的外表下的精英人才管理的小型金矿。)
软件和决策的视野
看起来管理足球队和从事软件工程工作是天壤之别，但有很大的共同点。
首先，让我们看看我们想象中的体育界的Scrum大师和Alex Ferguson之间的视野差异。
Scrum大师的思维方式是：
- 非常短的时间段（几周或几个月）
- 具体和可衡量的目标（进更多球！
相比之下，亚历克斯-弗格森的思维方式是几十年的时间，以及（实际上）无法衡量的目标：
- 如果我现在和这个球员简短地谈一谈，他们可能会被激励在他们的职业生涯中为我们工作
- ，我可能会鼓励其他人帮助他们的同伴，被认为是在灌输一种相互支持的文化
。
20年前，我在一家公司工作，那里有一个 "内部维基"--当时是一种新事物。
这篇文章的许多读者会知道"维基熵 "的现象（这个词是我编的，但我现在要一直用下去），即一个内部文档系统由于被未维护的信息所淹没，不管上面的一些内容有多大价值，都会逐渐退化成无用。
好吧，二十年前我们没有这个问题。我们决定雇用一个有学术倾向的年轻毕业生来维护我们的维基。
这样做的结果是一个非常有用的维基，它是最新的，内容很容易找到，而且在获取信息方面浪费的时间最少
。
工程师们很喜欢它，并不遗余力地赞扬他为把他们从自己的坏习惯中拯救出来所做的努力。
当然，当下一个机会出现时，这位维基馆长首先被解雇
了。虽然现场的每个人都知道这样做的价值很高，可以节省成百上千的工程师追寻不良信息所损失的时间和精力，但其影响却很难或从未衡量过，而且无论如何，工程师们不是应该自己做吗？
此后多年，每当我们这些工程师对维基感到沮丧时，我们总是诅咒那些做出短视决定让他离开的人。
所谓的 "业务人员"，如股东、高管、项目经理和产品所有者都被强烈地激励着去完成短期任务，这往往意味着优先考虑短期目标（完成任务）而不是长期价值。那些不考虑短期的人往往有很强的工程背景，尽管有这个障碍，他们还是成功地保住了自己的位置。
该怎么做？A计划--Scrum法庭
所以你的上级往往不会对你被分配的工作进行长期思考，但你对自己的工作感到自豪，并希望你的工作的价值能在更长的时间内被感受到，而不仅仅是一个冲刺或一个项目的增量。
幸运的是，已经出现了一种解决方案，可以处理这种不同的视野：Scrum。这种方法（在理论上，但这是另一个故事）严格定义了项目工作要在一个固定的时间段内完成（例如两周）。
在这个周期（冲刺）的开始，团队一起决定哪些项目应该在其中进行。
因此，在每个周期的开始，你有机会论证你想在你正在工作的系统中进行的改进或投资是否包括在工作周期中。
问题是，这些论证大多是失败的，因为牌还是对你不利的，表现在以下几个方面：
- 工作进度限制
- 效益的不确定性
- 完成
- 不确定性 价值的不确定性
计划A的缓解措施 - 工作进度限制
首先，Scrum工作进度的短期性质对更大规模和更多投机/创新的想法有一种内在的偏见。如果你不能在周期内完成你的工作，那么它就很容易被认为是不切实际或没有价值的。
通常的反驳是，工作应该被提前 "分解 "成更小的块，以便在冲刺期间完成。这通常会使工作看起来非常无关紧要（"和食堂里的年轻球员谈话"），并且会使人忽视所提出的工作的整体情况（改变/保持组织的文化）。
A计划的缓解措施--收益的不确定性
scrum方法试图在每个冲刺阶段增加 "商业价值"。由于大规模和投机/创新的工作通常风险较高，所以很难提前 "证明 "你所做的工作的好处，特别是在冲刺周期内。
结果是这种风险较高的工作不太可能被scrum "法庭 "批准。
A计划缓解措施--完成的不确定性
同样，工作是否能在冲刺周期内完成也是不确定的。同样，这也使得你的论证成功的可能性降低了。
A计划缓解措施--价值的不确定性
"商业价值 "是一个非常滑稽的概念，你越是仔细看它就越是如此。马克-施瓦茨写了一本书，我告诉每个人都要读一读，解构这个术语，并说明没有人真正知道它的含义。或者，至少，它对不同的人意味着非常不同的东西。
事实是，几乎任何东西都可以用商业价值来证明。
- 花一周时间学习AWS课程
- 作为一个架构师，我需要确保我不会做出会减少产品功能流量的错误决定
- 花一周时间优化我的dotfiles
- 作为一个开发人员，我需要确保我尽可能多地花时间高效编码，这样我才能为产品生产更多的功能
- 整理办公室
- 作为一个开发人员。我希望办公室更整洁，这样我就能更有效地专注于产品功能的编写
- 请米其林星级厨师做午餐
- 作为一名开发人员，我需要优化我的注意力和营养，这样我就能为产品编写更多的功能，而不会因为要吃午餐而分心
。 所有这些事情的问题是，它们实际上是无法衡量的。
一般来说，没有客观的方法来证明客户价值（即使我们可以确定它是什么）。
如果你试图在一些商业框架内证明它们的合理性（比如改善一个已定义的和预先批准的指标），你就会陷入你实际上无法赢得的讨论中。
- 这需要多长时间？
- "我不知道，我以前从来没有做过这个。"
- 指标是什么？
- "嗯，文化点？我们能不能衡量一下我们花了多长时间在维基上搜索，然后追寻从维基上收集到的信息？
-
- 不，这样做太贵了]
"'A计划'缓解器确实有价值
所有这些并不是说这些缓解器应该被删除，或者没有任何作用。正如任何工程师都知道的那样，工程师有一种倾向，就是低估某件事情的难度，低估它能带来多少价值，甚至做 "简历驱动的开发"，而不是为企业的需求服务。
足球经理也可以这么说。但我们仍然让足球经理决定如何花费他们的时间，而且他们越是有经验，越是成功。
但是...
...无论如何，我已经在许多组织中参与了这样的讨论，最终花费的时间比实际工作要长，或者至少要做必要的工作来证明概念形式的价值。
所以我主要转向B计划
--做什么？
计划B - Skunkworks
计划B是跳过法庭，只做必要的工作，以便能够说服别人，让他们相信你的方法是正确的，而不告诉其他人。
对这种方法的第一个明显的反对意见是这样的：
"这怎么可能做到？当然
，
你的冲刺阶段的工作时间已经被严格定义和估计，因此你没有多余的时间？
对于那些没有强大领域知识的领导者来说，他们的无知很容易被他们所领导的人所操纵。因此，工人们只是简单地膨胀他们的估计，告诉他们，他们所拥有的容易的官方任务将比实际所需的时间更长，留下的时间让他们去做他们认为对企业真正重要或有价值的事情。
是的，这是正确的：工程师实际上花了他们可以什么都不做的时间，试图为企业秘密地改善事情，只是因为他们想以最好的方式做正确的事情。就像亚历克斯-弗格森（Alex Ferguson）花时间和年轻人聊天，对食堂的设计进行微观管理，而他本可以独自或和朋友一起享受更长时间的午餐。
这不是一个秘密
好的领导知道这种情况的发生，甚至明确地鼓励它。一位C级领导（他自己曾是一名工程师）曾对我说："我喜欢你对我隐瞒事情。如果我不知道，我就不会被迫向我的同僚解释为什么你要花时间去改进，而只是免费得到一个解决方案。"
论点
当你拿钱做决定时，你被付钱行使你的判断力，而这些判断力无法在容易衡量和定义明确的价值指标中得到证明。
如果你的判断力可以被量化和系统化，那么你就没有必要在那里做出这些判断。
无论是管理足球队，还是做软件工程，都是如此。
做软件就是要做出和弗格森一样形状的决策类别。我应该：
- 修复还是删除测试？
- 重组管道，因为它的基础摇摇欲坠，还是暂时打补丁？
- 指导一个年轻人在几天内完成这项工作，还是自己在几个小时内完成这项工作？
- 用Python重写这个bash脚本，还是只是增加它的内容？
- 花时间将应用程序容器化，并说服其他人开始使用Docker，还是像我们一直以来所做的那样，用手工创建的环境蒙混过关？
- 花时间了解团队中的新成员，还是专注于在冲刺阶段完成更多的任务？
这些决定中的每一个都有许多后果，不明确且不可预知的。最后，需要有人根据经验来决定把时间花在哪里，因为标准的指标不能告诉你它们是否是一个好主意。
结论
在软件中这个问题的核心是我称之为 "砖家谬论 "的东西。 许多人把软件工程看作是一系列类似于砌砖的任务：一旦你准备好了，你就可以说大致需要多长时间来做一件事，因为砌一块砖需要的时间是可预测的。
这种谬误导致了把软件工程当作是可以随时转换为企业领导所需要的：一个可预测的随时间变化的交付图表。试图为企业领导保持这种幻觉的结果是故事点、速度和烧毁图表的童话故事。
如果你想知道这一点的证据，请看这里。在最大的科技公司中，Scrum作为一种软件方法论是明显缺席的。他们不认为他们的工程师是砌砖工人。
足球经理们没有那么多的谬误，因为我们直觉上明白，建立一个伟大的足球队并不像砌砖墙。
但是软件工程也是一门神秘而多样的艺术。它充满了工艺和微妙的选择，做好工作的满足感超过了出席和遵守规则的原始报酬。我经常观察到，"按部就班地工作 "与 "为了长期发展而努力做正确的事情 "得到的报酬和回报是一样的，但结果却是人类真正的苦难。在一个基本的层面上，你的努力和他们的后果往往甚至没有人注意到。
如果你把这种判断从人们身上移开，你就移开了他们的代理权。
这是知识工作的一个奇怪的新事物，在'砖家'或计件工作和泰勒主义
的时代并不存在。在知识工作时代，那些喜欢真正提供具有长期价值的工作的工程师们会感到不满意并辞职。给他们更多的钱让他们忍受也不一定有帮助，因为留下来的是那些已经学会优化的人，以获得更多的钱而不是更好的工作。
如果你想留住最好的和最有创意的员工--那些会对你的工作流程进行10倍的改进，从而带来显著的效率、改进和节约的员工--你需要弄清楚谁是Alex Fergusons，并给他们适当的自主权来为你工作。这就是你的管理挑战。
