我花了上半年的时间咨询不同类型的企业如何利用数字存在(即应用程序和网站)转为核心业务kpi。我的销售方法很简单:100%投入到工程组织中,我会适当调整底线,否则你不会为此买单。

我不是通过添加功能来完成，而是通过关注工程资源重要的度量标准来完成。大约十年左右的时间里我都在关注这方面,各种类型大小的商业教会了我:关注正确的数字,忘记其他数字存在。不要因外在噪音而分心。

也许你听说过“如果事情可以被度量，被管理，那么这事你就能做好”，但这句话只说了一半：

“可以被度量、管理的事情，就能做好—即使是毫无意义的度量和管理，即使它会损害组织这样做的目的。”~ Peter Drucker

换句话说，要度量正确的事情 - 更重要的是不要去度量错误的事情。 我有一些坏消息要告诉你。如果你像现在的大多数软件开发团队一样，你肯定度量了一些错误的东西。

为什么敏捷是一个肮脏的词汇?
我最近看到一篇谴责“敏捷”的博客文章，文章很受欢迎。但作者却不是在谈论敏捷。作者只是在谈论Scrum会议,票计算和速度度量的微观管理。

从总体看,不断收票的样子像是完成了工作。为了获得商业价值,你必须完成任务，所以，任务数=数量的交付。对吗?

哦，不，不，我的朋友。你错了。

几年前我为一个世界领先的购物车零售商工作。有一天我停下正在写的代码，在Jira软件上关闭票(选择在其一天的票跟踪器)。我添加了一张票:“可用性学习”。

我们花费超过一年的时间致力于重新设计我们的购物车，新产品发布的时间很快接近。但我们没有进行任何终端用户可用性测试的新检验经验：所以我花了一个星期给1000位早期铁杆的支持者，并进行了调查，收集反馈。我分析了结果，并注意到在评论和日志文件中一个令人不安的模式。

该车放弃率高达两位数。一个悬而未决的灾难！所以我设置为在人的可用性测试的工作规划视频记录。我把新手放在新的购物车前面，给他们一些需要完成的任务，让他们工作。我什么也没说。只是看着他们使用购物车。

我注意到在结帐过程中，人们在付款方式上很难给予误差反馈。在GitHub上的开源项目上我稍微改变了一下手头上的数据（注：记录在GitHub上，而不是我们自己的问题跟踪器）。

过了一段时间后，我得出了我之前作出的相同的分析。购物车放弃率降低了两位数：每个月的价值超过100万美元。

那个星期,我在Jira上关闭一个票。一个数百万美元的票。 当你看到票错了，他们并不是毫无意义的…他们是可怕的误导。对于商业和销售团队来说，只在聚合和只涉及到“责任”独立时任务与价值相关。

在微观层面，通过Scrum鼓励，票在幂律曲线上有着任意值，但他们都是一样的。

幂律是什么？

80%的门票占公司成功的20%。门票不是创造了平等，但我们对待他们就像他们一样。

任务对于商业价值的重要性就像一个终点钉对于摩天大楼的重要性。相反，一个任务可能是“倒基础”。

如果没有那个任务，这一建筑甚至不可能存在。有时我们把任意点分配给票，希望能更真实地给他们以重量，但说实话，这就像是要用一个桶来铲出海洋里的水。这是一个失败的原因。来看看我的观点。

在会议上停止浪费你的时间。

管理在不断的斗争中反复，以力量的速度来匹配承诺。他们认为，将任意价值分配给票将使这一情况发生。但它从来没有起作用。他们总是失望，开发团队一直在过度承诺却低值交付。有人被辞退会是一个不断的威胁。听起来熟悉吗？

我有消息告诉你：这些都不是敏捷。

Scrum不是敏捷。票计数不是敏捷。速度测量不是敏捷。

什么是敏捷？你的团队面对变化时的适应能力是敏捷。

票计数和“速度跟踪”是自瀑布混沌以来软件开发管理中最坏的思想。

忘记开票

忘记点。忘记估计和承诺。估计都是毫无价值的谎言。试着每周演示。让营销团队炒作你上个月完成的功能,而不是你认为你能在下个月可以完成的功能。

建立自己良好的功能切换和营销发布管理系统,根据营销宣传计划你仍然可以释放特性,但你会炒作已完成功能,您的团队不需要在晚上和周末再次加班加点。

提示：你的营销和销售团队不应该被允许讨论功能的“管道”，你的销售和业务开发团队如果没有真正灵活的MVP（最小可行产品）计划那应该永远无法承诺期限。我所指的灵活是：

例如，Elon Musk将带我们去火星。最初的销售MVP：先让一个气球入云。

工程由数量级估计通常是错的,但在现实中没有人愿意面对这一事实。

我们应该衡量什么？

在软件开发中唯一重要的是，让用户喜欢你的软件。

记住在这个列表中的其他任何事情都是为此目标服务。现在带来真正的指标！

以下前5个指标对于每个应用程序开发都是必不可少的业务关键绩效指标（KPI）。

你也许会奇怪为什么我会与一群开发人员分享这些并且告诉你,这些都是你需要关注的指标。

1.收入
如果你破产了，若没有其他指标意味着一切都毁了。如果你用完了燃料,那么游戏就结束了。你就完了。打包回家吧。

核心策略：

优化转化率
抓取内容
共享内容
页面加载和性能

优化保持轻松的关系。

2.月活跃用户（MAU）

你有没有用户？数量超过上个月吗？如果你是一个创业投资创业公司，你最好祈祷你的公司快速发展。在开始的时候，如果你努力工作的话，你可以在一个月内加倍努力。当然，所有的曲棍球棒曲线都是S曲线，但你有足够的空间去成长。

核心策略：
页面加载和性能
共享内容
TDD和代码审查

优化发展。

3.净启动子（NPS）

还记得我说过如果你耗尽燃料,游戏就结束了?你认为我说的燃料是指资金？

资金不是你的燃料。粉丝才是你的燃料。

粉丝是谋取钱的关键。更多的分享。更多的增长。更多的欢乐。更多的魔法。

核心策略：
TDD和代码评审
页面加载和性能

支持并与质量保证人员合作

优化用户变成布道者。

4.病毒因素
也被称为k系数或病毒商。如果你不度量,现在开始:
k = i * c
我=用户邀请（例如，股份）的数量 c =每股转化率
k = 1是稳定的。没有增长也没有下降。
k > 1意味着指数增长。
k < 1意味着指数下降。

在办公室中间应该有一个巨大的屏幕，MAU增长图增殖系数< 1用红色表示，增值系数> 1用绿色表示。

核心策略：
共享内容
将共享集成到核心产品
转化率优化
页面加载和性能

优化共享和新访问者转换。

5.支持票

没有什么比发电子邮件更能说明废旧方式是可以被打破的。上一次有人联系你只是告诉你你有多酷是在什么时候呢?

支持门票是煤矿中的金丝雀。当有人说这不对时，你不需要赞同他的意见,“只要它适合你就好”。即使用户错误,这不是用户错误。很有可能设计中的一个缺陷会影响其他1000人。这1000人宁愿点击返回键也不愿意把他们的时间浪费在你的应用上。

在理想情况下,您应该追求零票支持。你永远不会达到这个指标(如果幸运的话),但是你应该考虑支持错误报告的每一票。开始分类以下常见问题。解决它们并使用它们来解决问题。

我不是说顾客永远是对的。在你给顾客事物前，有时客户不知道他们想要什么。如果它出现在你的收件箱里，你肯定做错了什么。

TDD和代码审查
CI/ CD
功能切换与部署
周期性缺陷等形式的比赛
支持并和质量保证人员合作

优化问题免费客户体验。

重点工程重点指标
正如所承诺的，业务kpi的奥秘的关键是：事实证明,你可以用两个标志来度量：

6.错误计数
很震惊有些票对某事是有好处。不要把所有的bug票错误分类,否则你会得到一个错误计数。

所有软件都有错误，但不是所有的错误都需要修正。如果一个错误只出现在一个古老的手机中，而且只有一个用户使用这款手机，用户甚至不是一个付费的客户，你需要修复错误吗？当然不用。不用管它并继续前进。优先考虑修复最受影响的错误。

变得繁忙，挤压他们。

核心策略：
TDD和代码审查
周期性缺陷等形式的比赛
支持并和质量保证人员合作

对于一个bug优化体验。

7.性能
这次我作弊了。要包含三个关键指标:

加载时间
用户点击图标或点击你的网址，你的应用程序需要的时间是可用的。目标< 1秒。否则你会失去用户。每一秒你都可以在度量好处的同时修整时间。

响应时间
从用户操作（如点击）的时间响应到应用程序中。目的为＜100ms。任何超出都有滞后感。

动画时间
最长时间画一个动画帧。目的为10 ms。超过16ms将导致明显的闪避,甚至可能让用户感觉有点恶心。你需要一点喘息的空间。保持在10 ms内。

在这个列表中，负载时间是迄今为止最重要的微型度量。它重点提到移动业务KPI针。但响应时间和光滑的动画，造成一个神奇的副作用。用户在使用你的应用程序后更快乐。你看，每个janky 故障，每一个小的延迟都会让用户潜意识层面不爽。
给同一个用户相同的优化后的应用程序，用户会更满意。 我们的小秘密。

核心策略：
周期性的表演活动
深度绩效审计
1000ms 10ms，100ms，重复

优化jank-free体验。

还有很多

当然，这个小小的咆哮不能深入开发者如何直接操纵病毒因子和MAU数，但我会给你一个提示：你可以。当每天面对这些数字时，你知道，你的任务是解决它们— 不是管理的工作，不是销售的工作 - -你的工作，我相信你会想出一些有创意的想法解决。

如果你的经理认为你有更重要的事情要做,把这个链接发给他们。

现在就去那里，并针对实际问题移动针上的一些指标。

告诉你的JavaScript团队高速发展到底意味着什么
Eric Elliott 是“JavaScript应用程序”（O’Reilly），和“学习通用的JavaScript应用程序开发与节点的反应”的作者。他参与了Adobe系统软件经验，尊巴健身、华尔街日报、ESPN、英国广播公司和顶级艺术家包括亚瑟，Frank Ocean，Metallica等。
阅读英文原文

https://medium.com/javascript-scene/how-one-jira-ticket-made-my-employer-1mm-month-7-metrics-that-actually-matter-ffb5b2376a6b#.ri7db1utu

本文由ShineScrum翻译，吴继宗审核