在Ivan进行
了队列分析后 ，他讨厌任何含糖量度的指标。
但是具有讽刺意味的是，领导层一无所知，并且绝对不想知道。 我不得不超越自己，愚蠢地去满足老板的“要求”，以免赢得不遵守圣贤指示的坏人的声誉。
有时甚至从中获得有趣的结果。 现在将讨论一种这样的情况。
一次，经理要求伊凡（Ivan）找出为什么三队通过看台的转换率连续下降了三周：
我必须说，伊凡（Ivan）部门有很多团队，每天他们都会制作成百上千个发布的组件，并在展位上检查它们。
转换考虑了一个团队在一周内创建的构建数量与通过目标展位的组件数量之比。
含糖量度指标的主要缺点之一是无法从中确定任何内容。 伊万（Ivan）负责人使用的转换结果是典型的含糖量度。 转换率下降了，但原因尚不清楚。
自然地，所有团队为了不惜一切代价改善展台的性能而were之以鼻。 为此，可以很快编译出另一个包含“坏蛋”列表的含糖量度：
在图片的每一列下，团队的名称是实际写的。
车队大声疾呼，开始努力摆脱掉在他们身上的新不幸。
这位领导厌倦了追逐团队，敦促伊万找出导致转换率下降的原因。
因此，它产生了什么...
了解指标的本质
指标需要理解。 至少了解它们是如何考虑的。 然后，您可以更深入地挖掘并弄清楚。 因此，伊凡做了：
转换=建立的作品/其中的通过了标准了解该公式后，Ivan首先在图表上显示了转换的两个组成部分：
显而易见的是，创建的内部版本数量几乎没有变化，但与此同时，通过机架的组件数量却有所减少，并且在转换开始减少的那一刻它就开始减少。
由于创建的装配数量与过去的机架数量之间的差异有所增加，并且自 转换是彼此相除的结果，然后随着差值的增加，转换值也会同步变化（减小）。
图上的值之间的差异是一条黑线。
即 图中红色和蓝色列之间的差异增加表示转化率自动降低。
思考结果
伊万了解到，调查结果仍不足以确定病因。
以前在度量标准方面的经验使他有了一个重要的想法：您需要深入研究任何问题的根本原因。
DevOps转换更改的原因实际上是……人们。 团队的开发人员和开发人员。最终，伊凡（Ivan）希望与他们接触。
他看着正在创建的装配与通过展位之间的差异越来越大，他问自己：为什么会发生这种情况？谁是尚未到达展位的装配的“生成者”？
读过的书《丰田涛》给出了一个提示：有必要查看“剩余库存”或“进行中的工作”。
因为 这些组装件经过了几个摊位并可以留在那儿，伊万决定不仅计算一个摊位的组装量，而且要查看真正的“真实平衡”，即 计算没有任何支架完全使用多少组件并放置自重：
黑线表示残留物的数量，黄色-通过目标机架的组件数量，已在初始转换计划中考虑在内。
我什至不必猜测。 通过计算相关性，也可以确认两条直线的明显同步运动：
事实证明，剩余的组装残基越多，所需的转化率就越低。
找到根本原因
使用最简单的表确定由谁来创建剩余物并不难：
左栏中是团队的名称。 突出显示的列-该团队在一周内创建的残留数。
TOP-2领导人立即爬出来，伊万立即跑去与他们打交道。
原因当然是平庸的：这些团队只是开始了一个新的开发周期，并创建了功能，开始构建以验证其正确性。
含糖量度指标的主要缺点
实际上，转换的变化与周期性的发展过程密切相关，并且不是致命的或有害的。
在转换图表上，可以看到三个显影波（周期）。
这是应该遵循的自然过程。
而且与领导者起誓的团队是绝对正确的：在公司当前使用的开发流程中，增加转换不仅是“难以理解的”动作，而且可能会完全破坏流程并导致软件供应的严重延迟。
这是含糖量度标准的主要缺点-它们将积极的方面转变为消极的方面，而不是澄清情况，只会使情况变得混乱和恶化。
结论
总的来说，这种经历对Ivan来说很有趣，因此他即使很高兴地为管理层准备了一个演示文稿，在其中他解释说所使用的度量标准不适合管理部门，具有误导性，并且可能会引起大问题。
仅此而已。
如果Ivan的经历对您来说很有趣，他将非常感谢您的反馈。
顺便说一句，伊万现在想将自己和他的知识投入到一个鼓舞人心的煽动性项目中，因此他接受了PM中的有趣提议。