别数关闭的工单了，看看创造了多少业务价值吧

照片由 charlesdeluvio 拍摄，来自 Unsplash

作为一名工程经理，这些年来，我用过不少指标和系统来评估团队表现。

我尝试过简单一点的看板系统，还有更结构化的敏捷迭代，两者都有各自的利弊。

虽然看板系统易于管理和物流负担较小，但它降低了责任归属的程度。因为它没有承诺在一定时间内完成固定的工作量（像在冲刺中那样），这导致了更多的“无限循环”和缺乏回顾会议。

另一方面，有个Sprint系统建立了这样一个平台，鼓励更多的责任感，但这同时也意味着这也可能增加会议的频率，比如Sprint计划会、回顾会和待办事项梳理会等。

在运行这两个系统一段时间之后，我得出了这样的结论：重要的是你衡量什么，而不是用什么方法来衡量团队生产力。

我来解释一下。

照片由 Markus Spiske 拍摄，来自 Unsplash

用代码开发产品真不容易。

不仅仅是写代码，更重要的是人与团队之间的一致性。而且，每当你从1和0的世界转向人的世界时，事情会比预期花更多的时间。

无论是在确定设计方案、选定实验指标、审查技术规格，还是获得安全和数据需求的批准时——每当需要讨论时，都会对项目进度产生影响。

这就是为什么用这些“客观”指标来衡量生产力不太靠谱。我们来看看几个例子：

• 已发布的代码行数
• 已发布的 PR（拉取请求）数量
• 编写的测试数量
• Sprint 中完成的故事点总数
• Sprint 中关闭的 ticket 数量

当你选择要优化其中一个指标时，你实际上是在告诉团队你最看重的是什么。

这样做就是在激励你的工程师把这些指标做得漂亮。

我们来看几个具体例子。

• 编写的代码行数：您的工程师可以使代码变得过于冗长。
• 已合并的拉取请求数量：您的工程师可以故意将拉取请求拆分成最小单元。
• 编写的测试数量：您的工程师可以编写冗余的测试。
• 冲刺周期内完成的故事点总数：您的工程师可以夸大工时估算。
• 冲刺周期内关闭的工单数量：您的工程师可以将一个任务拆分成多个工单。

其实很简单嘛。

如果你选择了容易作弊的坑爹指标，你就会让人们把精力放在错误的事情上。

当你激励人们优化错误的目标时，你认为可以衡量团队生产力的指标实际上会变成衡量其他东西的指标。

这就提出了一个问题——你为什么想要衡量你团队的效率？这里真正重要的是什么？

每个工程团队最重要的成果是：业务成果。

那就是你想要衡量团队生产力的原因。你希望确保团队能够健康而可持续地为公司创造价值。

所以，这就是你激励工程师的方法，希望他们能够重视交付业务价值。

毕竟，这些行数、PR和测试数量甚至都不是衡量生产力的好指标，更不是唯一的衡量标准。

总之来说：你需要建立一个能激励你的工程师创造更多业务价值的系统……

问题是：你具体是怎么做的呢？

照片由 Sean Stratton 拍摄，来自 Unsplash。

衡量价值很难，这也不奇怪，人们在软件工程中会寻找替代指标（如）来衡量价值。

工程项目的价值需要尽早确定。

每个项目必须与某些业务指标相关联——如营收、点击数、节省的$、观看量等等，等等。
增加逗号隔开各个指标，使句子更清晰易读。此处“等等”重复出现，只保留一次即可。

每个项目必须与某些业务指标相关联——如营收、点击数、节省的$、观看量等。

不管公司重视什么，都应该有一种直接的方式将工程项目与之挂钩。一旦实现，这个项目就会体现出它的整体商业价值。

下一步是将其拆分成更小的部分（里程碑）。

每个里程碑都应该与大局有逻辑上的联系。这些里程碑应该被合理分解，这样在每个Sprint（比如两周）结束时，都能交付一些实际成果来显示进度。

交付成果不必是一个完善的功能。它可以是一个很简单的东西，比如：

• 正在审核的书面文件
• 确认规范
• API 合同
• API 骨架，包含测试数据
• 创建空数据库
• 统一数据库模式
• 一个无法使用的 UI 元素

这些小块如何拼凑成更大的拼图以交付业务价值，如果每个里程碑都能成为一个“可交付物”，就更清楚明了了。

每个里程碑最好由一位工程师来主导。他们应该有权制定自己的时间表，只要他们能在每个Sprint结束时展示进度即可。

没关系他们是怎么做到的——他们提交的PR数量、代码行数等——重要的是在冲刺结束时，他们有成果展示进展。更重要的是，因为他们可以告诉你他们能展示什么，他们在衡量自己的进度。不再是别人规定交付时间，他们自己掌握进度。

你现在是在鼓励工程师们定期交付业务价值，而不是鼓励他们优化像PR（拉取请求）关闭的数量或完成的故事点这样的逻辑指标。

他们知道他们的成功将在于完成这个里程碑，而这将直接为更大的项目带来业务价值。

虽然激励与该系统相吻合，还是遇到了一些显而易见的问题。

当工程师被激励去交付价值，不管他们用什么方式，当截止日期迫近时，他们可能会采取捷径。

实践中这可能意味着一些取舍，比如：

• 写更少的测试用例
• 更短的时间跨度 — 选择短期利益而非长期利益
• 任务跟踪较差

我觉得这可能只是这种方法产生的一个副作用。

没有完美的方法这一说。

不过，依我所见，这是让工程师的激励机制与业务最接近一致的方式。

照片由Igor Omilaev拍摄，来自Unsplash

另外一大好处是鼓励在每个Sprint结束时持续交付业务价值。

红旗或错误可以更早地被发现，在开发生命周期的早期。

如果你经常错过演示，那就是你要深入挖掘的信号。

好了，今天的各位朋友，今天就到这里吧。

感谢你抽出时间。希望你觉得这很有价值。

如果你想保持联系，这里有几个方式：关注我在Medium的动态，或者订阅我的网站邮件列表。