无论采用哪种方式，都应该记得指标是最终目标。可是指标的抽象化和不容易量化的领域增加了制定指标的难度。曾在Digg、 Uber、Stripe以及Calm等多家公司工作的Will Larson将在这篇文章分享关于指标的思考，感兴趣的小伙伴赶紧来看看吧。

随着组织变得越来越复杂，其管理要靠无形的抽象，越来越脱离其所代表的现实的抽象。

在最小规模的团队里面，决策者可能每天都埋头于代码之中。稍微大一点的呢，就会跟你谈论正在赶的任务。团队再大些之后，领导要讨论的就变成了任务组，并采用诸如“史诗”（epic）之类的花哨用语。

如果要管理的工程师达到上百时，你可能就主要是围绕着工作主题展开讨论了，并且会侧重在若干关键计划上面。如果手下千军万马，你讨论的也许就是用于资源分配决策的投资框架。

无论采用哪种方式，指标都是你的最终目标。

指标是非常有效的抽象。一个结构得当的指标会有足够的上下文信息，通过它可以了解你的工作状况，把表现跟过去的表现进行上下文关联，然后定义清晰的、可分级的目标。

带有目标的指标的例子：

20%的部署在第四季度完成金丝雀发布，比第三季度的10％有所提高，但未达25％的目标。

这样的指标很强大，原因有几点：

• 首先，历史背景描述了所取得进展的情况，尤其是跟图表结合在一起的时候更能昭示。
• 其次，目标是否已实现一目了然，从历史记录可以大致了解目标实现的难易程度。
• 最后，也是最重要的一点是，人们可以在对基本主题了解最少的情况下对其进行评估。

领导复杂公司的家伙对基础工作的了解自然不成问题，但是他们出这张牌要非常谨慎。以内需要他们关注的事情太多了，而指标就成为他们筛选哪些领域只需要大概观察一下，哪些需要再具体研究的重要手段。

组织需要一些时间来获得新的能力，才能满足对指标的这种贪得无厌的需求。好的指标需要对底层数据有深刻的理解，而形成那种熟悉程度是真正的工作。

什么时候象征着指标时代的开始呢？看你选择的指标被废弃的程度。每一次学习都会激发你对指标的类别进行改进，而且大多数的新指标都需要新的手段、管道和环境来支持。

这需要时间，而且是一项艰巨的工作，但这项工作的成果是可预见的。你投入的时间越多，掌握的信息越多，那么你选择的指标就会成为其下的现实更持久、更有用的实现。

不管怎样，指标就是这样发挥作用的。随着我在定义和使用指标方面的经验越来越丰富，我的时间越来越多地花在跟不容易衡量的领域打交道上面，有时候我将其称为不可测领域。

当我碰到负责基础设施的新领导时，我的问对方的第一个问题通常是以下之一：

• 你怎么去衡量公司的安全性？
• 你怎么衡量团队的生产效率？

我会得到各种不同的答案，但是答案通常都不尽人意。这两个问题的挑战非常相似，所以，我会特别探讨一下对安全性的衡量。

01 衡量安全性

我们在讨论安全性的衡量时，描述你期望的结果的输出指标是相对容易的。但是，在一般情况下，安全指标的分子或分母都是不可知的。比方说，你可能想为入侵检测设定一个目标，但是从定义上讲，你不会知道分母是什么，因为你自然不知道没检测到的入侵有多少。

同样，在你的确知道分子的情况下（比方说，已知的安全漏洞数量），一般来说，唯一可接受的目标只能是零。在这些力量的共同作用之下，结果就是“零指标”的扩散，比方说设定“违规数为0”，“内部作案数为0”，“被感染系统数为0”等目标。

“零指标”是二元制指标的一种特殊形式，这种指标唯一有用的数据是能说明你成功（被击中为0）还是失败了（被击中大于0）。

这样的指标不是很有用，因为所提供的对表现的评价非常粗粒度，真的只有通过或者失败。更糟糕的是，这种指标还不可执行。假设这不是可以忽略的领域，你在安排下半年工作的时候，不管漏洞数是0还是4，你对这项工作的优先考虑程度都会是一样的。

如果我们不考虑这些二元化的指标的话，其实还有很多非常有用的指标可以考虑用来衡量我们的安全性的，比方说：

• CVE（通用漏洞披露）库的升级速度有多快？
• 公司最老的那台还在用的服务器用了多久了？
• 通过mTLS 发起的请求百分比是多少？
• 有多少家伙可以通过SSH访问服务器？
• 有多少家伙具备对服务器的根访问权限？

这里所面临的挑战是，所有这些输入指标都非常适合针对计划衡量进度，但对衡量该计划的质量却无能为力。当然，我们对服务器的存储进行了100％的加密，但这种举措对安全性的贡献究竟有多大呢？

依赖输入指标还有一个问题，那就是输入太多而且太具体，以至于想要综合成有用的洞察很难。这意味着这类指标没法发挥出关键作用，也就是不能为高层领导提供有效理解某部分工作绩效的抽象方法。

02 综合指标

综合考虑上述挑战，那么什么才是衡量一个组织绩效的好指标呢？我们认为它应该具备以下几点：

1. 指标应该暴露出足够的层级，从而检测出表现随时间的变化情况；
2. 等级之间的变化应该为行动提供有用的指导；
3. 指标应该在有限的上下文背景下进行评估，以及
4. 应该足够广泛，可以对巨大的复杂性进行抽象。

按照上述要求看，我觉得具备这些属性的纯天然安全指标并不存在，但幸运的是，我们不必依赖纯天然的指标。我最近的办法是创造出综合指标，也就是把输入指标打包成有用的抽象。

一个很好的例子是：

如果您想建立一个“服务器安全等级”，也就是根据输入指标为每个服务器从“A”到“F”分配一个字母等级。这里的细节有点难解释，不过具安全等级为“A”的服务器的等级也许比不上一台刚上线7天，跑的是最新的操作系统，并且具备根访问权限的人很少的服务器。

每天，你都要评估每台服务器的安全等级，然后就可以开始跟踪不同字母等级的服务器的分布情况。

然后，与其详细讨论每一个输入指标，不如围绕着改变等级的分布来设定目标。比方说，你的目标指标可以是：

80％的服务器的安全级别为A，高于第四季度的60％，达到了我们设定的75％的目标。

这样一来，就用非常简洁的方式代替了大量的复杂性。每一个安全等级应该怎么定义还可以进行非常仔细的讨论，但是大家已经不需要深入了解相关定义就可以了解情况了。你可以测量等级分布的变化来评估长期的进展情况。如果等级分布往下走了，那就可以去深入了解一下导致等级下移的输入指标的情况，然后用来识别出纠正措施。

总的来说，我认为这种方法出奇的有用，但这并不是没有代价的。这种方法的主要缺点是设计、检测和改善综合指标的复杂性。取决于你使用什么样的工具，维护此类指标的开销可能难以为继，但是我认为随着事情变得越来越复杂，这是一项值得放进你工具箱的强大技术。

人们还如何为无法衡量的指标制定指标？

顺便说一句，跟衡量安全性一样，衡量生产效率也很有挑战。之前，我写过一篇文章来讨论过这一点，一方面概括了Accelerate 对生产效率的定义（重点是利用行业研究来选择正确的输入指标），同时我还引入了系统思维把输入指标归纳为一个可理解的模型。

现在我的想法稍微有些改进了，重点放在对内部开发人员的调查上面（而不是CSAT 客户满意度调查得分，而是参与率以及最关注问题的变化率），并围绕着工作流的可用性构成一个综合指标（基于一系列输入指标，比方说开发、测试以及部署的速度和可靠性）。

看来要学习的东西还有很多啊！

作者：boxi，发布平台：36氪

原文地址：https://36kr.com/p/5298480

本文由 @36氪 授权发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Pixabay，基于CC0协议