怎么为“不可量化的任务”制定指标?

0 评论 6827 浏览 22 收藏 12 分钟

无论采用哪种方式,都应该记得指标是最终目标。可是指标的抽象化和不容易量化的领域增加了制定指标的难度。曾在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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!