技术人的话语权：正确地做事，比做正确的事更重要

以下文章来源于研发效能进化论 ，作者任晶磊

研发效能进化论.

分享与研发效能相关的见闻、知识、个人体悟

作者任晶磊——思码逸 创始人&CEO 

清华大学计算机系博士，前微软亚洲研究院研究员，斯坦福大学、卡内基梅隆大学访问学者；《软件研发效能度量规范》标准专家组核心专家。在软件系统、软件工程领域从事前沿研究多年，具备丰富经验。

▼

一直以来，“做正确的事，比正确地做事更重要”似乎成了某种政治正确，也成了技术人被老板、被业务 PUA 时的常用话术——当我们在管理会上兴奋地讲述产研团队通过各项举措把需求吞吐量提升了 20%，下一个被挑战的问题常常是：你们做的这些需求都有价值吗？客户吵着要的 X、Y、Z 怎么还没交付？

这些质疑听起来没毛病，但如果直接回答，你就输了。因为永远有听起来极其“正确”的需求还没做，而做完的需求再没人关心它们“正确”与否。在这样的对话中，产研永远是附庸，话语权被他人拿捏。要想摆脱这种尴尬的境地，技术管理者应当勇敢地说：

你们要的“正确的事”，只有通过我们“正确地做事”才能达成！

— 1 —

“正确的事”容易成为陷阱

“做正确的事更重要”隐含着一个假设：我们能明确知道什么是“正确的事”。但实际上，有几个人能做到呢？反正我不能。作为 CEO，带着思码逸跑了五六年，往事不堪回首。我最知道“正确的事”的时候，都是团队被带着走弯路最多的时候。

遥想当年，拿完奇绩创坛几千万投资，踌躇满志。和陆奇博士多次讨论，一致认为，从数据分析向上游 DevOps 工具链延伸是“正确的事”。于是我们做了开源项目 DevStream，成功进入 CNCF 沙箱。但事与愿违，把产品“做薄”和有足够的切入口“黏住”用户之间的磨合，不是靠谁拍脑袋就能定义“正确”的，而是要在实际场景中和大量种子用户反复迭代验证。最终，这个项目被我们挂起了。

从产品战略到具体功能，“正确的事”，特别再加上“难而正确”的自我感动，往往会成为一个花团锦簇的陷阱。

当然了，我肯定没有乔布斯、马斯克的远见卓识。但你的老板、你的业务方有么？既然大部分情况下没人知道“正确的事”到底是什么，就不要上来谈比“正确地做事”更重要了。

— 2 —

先有“正确地做事”，后有“正确的事”

“世有伯乐，然后有千里马”。两者的关系恰恰是反直觉的：管理层更应该关心组织是否能够“正确地做事”，因为只有以正确地方式做事，才能以更大的概率、更小的代价找到“正确的事”。

软件工程几十年发展正体现了这种理念。从瀑布模型，到敏捷方法，软件工程认知变迁的核心，是承认软件项目很难从一开始就明确所有正确的需求。而只有采用正确的做事方法，在持续交付的过程中不断调整，才有可能踩准正确的事，否则后者永远是镜中花、水中月，求而不可得。我甚至觉得，小到项目、企业，大到社会、国家，“正确地做事”都更胜一筹，没有法律、标准、规则，没有“程序”正义，“结果”正义虽可能碰对，但更容易跑偏。不能本末倒置。

那反过来，我们产研团队专注于正确地做事，就可以将“正确的事”这口大锅都甩给业务方了吗？我认为也不妥。唯业务马首是瞻的产研团队，恐怕同样危险。苏格拉底说，“未经省察的人生不值得过”，一样的：

未经产研提炼的业务需求也不值得做。

实际上，业务与产研应当有机结合，形成共赢的合作模式，而不是错误地认定哪一方该为“正确的事”负全责。双方应该共同以“正确的事”为最终目标，并在通往最终目标的路上“正确地做事”，业务给出需求的原材料，产研对需求进行加工提炼，并且配合一起迭代和回顾。高效能团队无一例外，业务和产研都有着健康的关系。

— 3 —

“正确地做事”举例：需求价值评分

业务与产研正确合作模式的关键是形成有效的反馈机制。思码逸很多客户正在践行的“需求价值评分”就是一个很好的例子。常规做法很简单：

• 在一个需求创立之初或者进行需求评审时，业务方和产研应共同设立需求要达成的价值目标。

• 对于可量化的目标（如点击率），建议设定具体的目标值；如果不能量化，可以主观评级，明确评级标准。

• 在需求交付后的预定时间内，业务方和产研共同回顾需求价值目标。如果有量化指标，可按实际值除以目标值计算评分，比如大于或等于 200%而小于 300%的分数为 2；如果只有主观评级，按实际达成的等级算分即可。

这样的过程就建立起“假设-验证”的小闭环，通过业务和产研的协作，不断走向“正确的事”。我们还可以通过数据度量帮助团队不断精进，基于某几个迭代或周期内需求价值评分的统计，可以绘制出如下图所示的“需求价值达成率漏斗”，帮助我们直观看清楚需求交付价值的现状和改变。

可能有技术管理者紧接着会提出一个问题：我们太忙了，哪有时间这么详细地评价每个需求？

其实需求价值评分也可以“丰俭由人”，通过需求分层分类。以敏捷项目为例，可以自然按 epic 和 user story 分两层。通常 user story 数量较多，如果无法都做到价值评分，那就从 epic 抓起，这一层应当与产品乃至企业战略对齐，有明确的量化指标或达成标准。当然，user story 理想来说应符合 INVEST（independent、negotiable、valuable、estimable、small）原则，独立有价值，所以尽量能够做到评价和回顾。实际当中，只有一部分 user story 设置了目标也很好，不强求但可以引导。上图中最顶端的漏斗就是统计了多少需求带有指标值。

管理不是非黑即白，而是用数据牵引团队向正确的方向前进。

除了需求分层，还可以通过分类划定需要价值评分的范围或者排除不必要的类型。例如，我们一个客户将业务需求分为目标型、风控型、合作方要求等。目标型需要走需求价值评分的流程，但合作方要求就跳过，这种需求……懂得都懂。有了分类，很多企业还会看每个迭代各类需求做了多少，以优化资源分配。

进一步地，单纯看需求数量仍存在不足，因为需求的颗粒度不一致，导致统计结果不能准确反映实际。特别是从资源分配的角度，如果我们想回答“团队的带宽是否都花在了正确的事上”这类问题，就需要对完成需求的工作量做评估，而不能仅仅数需求个数。

通过代码度量是一种无侵入、低成本的方式。但显然又不能只数代码行数。所以建议引入程序分析来计算代码的规模和复杂度，以校准需求颗粒度，帮助看清研发带宽的分配。

最后，“正确地做事”知易行难，如果在组织内缺乏共识和明确的指引，一样会被“高高挂起”。