CTO 如何衡量业务影响：从开发者生产力到影响洞察的实践指南

知识工作者的生产力很难量化，而且往往与直接业务成果脱节。缺乏这种认知，会导致组织不断发起各种所谓提升开发者生产力的举措，造成技术支出膨胀，并做出并不恰当的投资选择。技术领导者，尤其是 CTO，需要避免陷入这种困境。他们需要构建一张能够洞察工作如何影响业务的网络，将团队产出与直接影响及下游影响关联起来。要做到这一点，可以从几个方面入手：引入稳健的需求管理，降低衡量成本，建立影响验证机制，并帮助交付团队看清自身工作如何转化为业务影响。

《影响洞察》一书讨论了如何提升组织对新举措业务影响的认知。传统企业通常会将这类举措的支出视为可自由支配支出。例如，软件公司可能会将其计入研发支出。本书以投资治理为分析框架，主要面向拥有投资审批权的高管。他们有权推动变革，也最有动力推动变革，因为他们需要对投资者负责。但他们并不是唯一有这种需求的人。科技公司的高管同样有动力提升组织的影响洞察能力。

试想一下：你是一位首席技术官（CTO），或者其他技术高管，例如首席信息官（CIO）、首席数字官，或负责数据职能的首席数据官（CDO）。你的团队负责交付由产品部门或业务关系经理团队确定优先级的工作。如今，你比以往任何时候都更需要汇报并提升团队的生产力。有时，这会成为预算讨论的一部分。首席运营官（COO）或首席财务官（CFO）可能会问你：“增加预算是唯一的选择吗？我们正在采取哪些措施来提升开发人员生产力？”

最近，这类问题又被纳入了人工智能讨论。例如：“我们是否正在使用 AI 来提升开发人员生产力？”甚至有人会问：“我们如何利用 AI 降低每个故事点的成本？”这其实是一种自相矛盾的单位经济效益分析，因为它试图优化一个与业务影响几乎没有关系的指标。这种做法可能适得其反，而且在很多情况下确实如此。

确保每个人都尽职尽责当然重要，但当前对开发者生产力的过度追逐，似乎已经有些过头，也偏离了重点。这个观点已经被反复强调，你可能也早已理解：开发者生产力属于产出层面的指标，其重要性远不如结果和影响。如果 AI 提升了生产力，却没有对业务成果产生任何影响，那这种提升就没有意义。对于许多产出与结果相关性较弱的公司来说，这确实是一个现实风险。

问题在于，如何说服 COO 或 CFO 少关注生产力，多关注整体业务影响？

即使没有生产力压力，技术高管也可以利用本文的建议，提高组织对各项工作业务影响的认知。如果你是产品高管，那就更好了。如果你认同这些建议，落地实施起来会更加容易。

业务影响胜过开发者生产力

在工厂生产中，生产率可以用每小时产量来衡量。在建筑行业，生产率可能用每平方英尺成本来衡量。在这些领域，工人的产出看得见、摸得着、可重复，绩效也相对容易衡量。

但知识型工作并非如此。知识型工作充满模糊性、创造性和非例行问题求解。它的生产力更难量化，而且通常与直接业务成果脱节。更多工时或更多产出，例如更多代码行、更高迭代速度、更多文档、更多会议，并不必然意味着更大的业务价值。除非你是服务提供商，并且收入完全基于计费工时。

作为技术领导者，你必须反复强调这一点。否则，你可能会陷入一种恶性循环。

事情通常是这样发生的：为了支持业务增长，你不断推出新的数字产品和功能。然而，这些交付物究竟产生了多少业务影响，往往并不清楚。原因在于组织缺乏影响反馈机制。在影响不明朗的情况下，为了勉强推进业务，你只能推出更多想法。结果就是盲目尝试。功能工厂逐渐形成，技术资产也随之膨胀。

图 1：业务影响不明的后果

所有这些新系统都需要持续运行，维护成本——也就是运行成本或“保持业务正常运转”的成本——不断上升。这会压缩可用于新开发、变更、研发和创新的预算比例。当你向 COO 或 CFO 申请增加预算时，他们又会要求你提升开发人员效率，或者要求你从业务影响角度证明预算需求的合理性。由于组织内部普遍缺乏对业务影响的认知，你很难拿出这样的论证。

如果你想摆脱围绕开发人员效率的反复追问，就必须找到方法，把对话引向更具建设性的方向。你需要重新调整讨论焦点：更多关注团队工作的业务影响，帮助组织提升对影响的洞察能力。下面我们从“影响洞察”谈起。

什么是业务影响洞察

影响洞察，是指持续关注各类举措对业务的影响。这些举措可以是技术举措、研发举措、转型举措，也可以是业务举措。影响洞察不仅关注与举措相关的底层指标，更需要追踪它们对关键业务指标的贡献。图 2 使用一种我称为“影响网络”的可视化方式对此进行了说明。

影响网络揭示了各类直接或间接影响业务的因素之间的关联。它有点像 KPI 树，但有时更像一张网络，而不是一棵树。此外，它遵循一些约定规则，使其更加实用。例如，绿色、红色、蓝色和黑色箭头分别表示预期效果、不良效果、汇总关系，以及某项功能的预期影响。实线和虚线箭头分别表示正向关系和反向关系。除汇总关系，也就是蓝色箭头之外，其他连接并不总是代表确定性关系。影响网络更像一种概率性的因果模型。书中还详细介绍了更多约定规则。

图中底部列出的功能、计划等，只是临时叠加在影响网络上的工作项。如前所述，影响网络本质上是一棵 KPI 树，其中每个节点都代表一个指标或可量化的内容。之所以说这些工作项是“临时的”，是因为工作内容会不断变化，而上方的 KPI 结构相对更稳定。

图 2：影响力网络图，叠加了当前的工作计划。

通常，新功能或新特性会直接影响产品或服务指标。它们对更高层级指标的影响，则是间接的，而且不那么确定。直接影响，也可以称为一级影响或近端影响，更容易被察觉，也更容易取得成效。间接影响，也可以称为下游影响，发生在更远的环节，且可能受到多种因素影响。下面几个例子将对此进行说明。

本文接下来的部分，将介绍企业整体影响网络中一些较小的、特定语境下的子集。

示例一：客户支持聊天机器人

在呼叫中心中，AI 客服聊天机器人在减少呼叫量方面究竟有多大贡献？它是否能在保持客户满意度的同时，真正降低人工来电数量？

图 3：人工智能聊天机器人的下游影响

仅仅根据解决方案交付数量来判断成功，已经远远不够。即使是图 3 中所谓的“虚拟助手承接量”，也就是令人满意的聊天机器人会话数量，也同样不够。这只是短期影响，也是精益创业中“构建—衡量—学习”通常追求的目标。然而，在这个场景下，真正重要的是下游影响，也就是通话量节省。

一般来说，短期影响未必是下游影响的可靠先行指标。

从更大的格局来看，聊天机器人可能只是一个小举措，但小举措正是训练影响洞察能力的好地方。

示例二：监管合规 AI 助手

再来看监管合规中的常见工作流程。合规分析师接到一个案例后，需要研究案例本身、相关法规及其最新变化。随后，他们运用专业知识提出建议。最终决策还需要经过一系列审核和批准，具体次数取决于案例的重要性和严重程度。决策时间可能长达数小时、数天，甚至数周，具体取决于案例以及所在行业。

缓慢的决策可能会对业务产生不利影响。如果分析发现，合规分析师是流程中的瓶颈，那么组织或许可以开发一个 AI 助手，用来解读并应用不断变化的法规。图 4 展示了该举措的影响网络。

图 4：人工智能法规解释器的影响网络

这个助手的直接影响可以通过使用率来衡量，例如每位分析师每周输入提示词的次数。但更有意义的指标，是分析师在处理案例时节省了多少时间。真正的业务影响，来自决策时间的缩短。这是下游影响，只有当助手确实有效，并且首次提出建议的时间确实是瓶颈时，这种影响才会出现。

示例三：电子邮件营销 SaaS

假设有一家提供电子邮件营销解决方案的 SaaS 公司。其收入取决于新订阅和续订。续订率取决于该解决方案对客户的实际价值，也受到价格竞争力等其他因素影响。图 5 展示了其影响网络的一部分。

图 5：电子邮件营销 SaaS 的影响力网络

客户成功最明显的标志，是客户通过使用这套解决方案产生的潜在客户，最终能带来多少额外收入。因此，产品团队会不断添加功能，以提升电子邮件互动效果。例如，他们可能会根据收件人的历史行为，个性化安排邮件发送时间。

这一功能的实现，会利用打开日志和点击日志中的行为线索，识别每个联系人的互动高峰时段。随后，这些信息会被输入到营销活动调度器中。

你认为应该如何衡量这个功能是否成功？如果只用邮件打开率或点击率作为衡量标准，那么可以通过 A/B 测试进行验证。但这只能反映短期影响。

影响洞察的两个杠杆点

绘制影响网络，通常是第一步。它提供了一种易于理解的可视化方式，类似领域驱动设计中的“通用语言”。为了提升影响洞察能力，领导者必须解决组织从创意到影响这一循环中的缺陷。图 6 展示了这个循环。虽然图中以线性顺序呈现，但由于存在迭代，它本质上是一个循环。

这个周期中的任何环节都可能存在薄弱点，但第一个环节“创意选择”和最后一个环节“影响评估与迭代”，对于影响洞察尤其重要。如果这两个环节缺乏严谨性，就会导致图 1 所示的“广撒网”式恶性循环。中间环节更多属于执行或交付范畴，它们对实际影响的贡献，通常大于对影响洞察的贡献。

图 6：从想法到影响周期中的关键杠杆点

在系统思维中，杠杆点是系统中的战略干预点。对某个要素做出微小改变，就可能对整个系统行为产生显著影响。图 6 重点展示了影响洞察的两个杠杆点：创意选择和影响评估。

然而，这两个环节通常由业务领导者、业务关系经理或首席产品官（CPO）负责。另一方面，作为技术公司的高管，你却往往因为业务影响不佳而承受生产力压力。那么，你该如何在这里引入严谨性？

理论上，你可以尝试与负责创意筛选和影响评估的领导者沟通。但如果他们有意愿且有能力，他们很可能早已发现并解决问题。典型的传统企业并非没有政治因素。在这样的环境中发起这类对话，可能只会得到一些礼貌保证，以及一些委婉提醒：作为技术高管，你不必为此操心。

这种情况在产品和工程已经发展为两个独立职能、各自拥有首席负责人或高级副总裁的公司中很常见。规模较小或成立时间较短的公司，有机会避免陷入这种组织结构失衡。但你所在的公司，可能早已过了重新决定组织结构的阶段。

CTO 提升业务影响洞察的行动

接下来，你可以向 COO、CFO 或 CEO，也就是核心高管团队，提出本文中的建议。你也可以送他们一本相关书籍，或者在领导力研讨会上做一次概要介绍。核心高管团队负责审批投资，他们既有权力，也有动力提升影响评估能力。他们最适合改进投资治理。这正是相关方法论提出的路径。

但如果出于某种原因，这条路走不通怎么办？如果他们有其他优先事项怎么办？

如果无法让他们积极参与，至少也要争取他们的支持，让你能够自行尝试一些改革。这是值得做的。正如前文所说，最终为维持现状付出代价的人，往往还是你自己。

下面，就来谈谈如何成为一名改革派，或者说行动派 CTO。

行动一：引入稳健的需求管理

产品经理可能负责对创意进行分类和优先级排序，但他们并不总是能够很好地记录创意选择背后的理由。无论是商业案例，还是论证幻灯片，一份好的文档都应该回答“稳健需求管理问卷”中的所有问题。

稳健需求管理问卷

如果一个想法能够清晰回答以下问题，那么这个想法就得到了较充分的论证：

1. 这个想法试图解决什么问题？或者，它试图利用什么机会？
2. 有什么证据表明这个问题或机会确实存在？
3. 提议的解决方案是什么？谁是主要倡导者？
4. 曾经考虑过哪些替代方案？哪些方案被放弃了？为什么？
5. 该方案可能改善哪些指标？包括直接指标和下游指标。
6. 预计改善多少？在多长时间内实现？
7. 你对此有多大把握？依据是什么？
8. 这些预期建立在哪些假设和依赖关系之上？
9. 如何验证影响？我们是否具备相应的衡量能力？
10. 如果不做这件事，会有什么风险？这些风险发生的可能性有多大？

一张被广泛理解的影响网络，有助于回答上述部分问题。但对于稳健需求管理而言，真正关键的不是影响网络本身，而是这些问题的答案。

回答这些问题，才能形成 SMART 的想法，也就是具体、可衡量、可实现、相关且有时限的想法。否则，这些想法就可能是 VAPID 的：模糊、含混、空想、不相关且遥遥无期。对于 VAPID 想法，即使技术交付完成，也很难验证其业务影响。这会导致图 1 所示的不良后果。

为了避免这种情况，你必须坚持将团队资源——这本质上是宝贵的业务资源——分配给那些经过充分记录的想法，而不是分配给所有看起来重要的项目。当然，这种做法只适用于需要投入较大精力的工作，而不是每一个用户故事或缺陷。你可以自行设定阈值，例如两周工作量以上。

还需要区分优先级排序和进度安排。前者是为工作项分配优先级，后者是将工作项安排到具体工作周期中，例如某个迭代。许多组织没有区分这两者，而是把优先级排序等同于进度安排。请重新思考这一点。

产品经理仍然有权确定优先级。进度安排则一直受到实际因素影响，例如依赖关系，或者某些团队成员的可用性。现在，进度安排也应考虑上述问题是否得到回答。对于希望把目标、反馈、需求、评审、排期、开发、测试、发布和知识沉淀串联起来的研发组织，PingCode 这类智能化研发管理工具也可以作为承载稳健需求管理的系统基础，让需求选择、交付过程和影响验证之间的数据更连续。

如果这些问题已经在创意筛选阶段得到回答，工程团队必须能够访问相关信息。稳健需求管理意味着，除了常规文档要求，例如产品需求文档之外，工程团队只会承接已经按上述方式记录的工作。这也意味着，不仅你自己，你的团队也必须理解影响洞察是什么、如何运作，以及为什么重要。后文会对此做更详细说明。

需要注意的是，文档齐全并不一定意味着理由充分。稳健需求管理并不意味着工程部门要自行判断某项工作是否值得做，而只是确保预期收益和时间表以可验证的方式记录下来。产品部门仍然拥有优先级决策权。为了安排工作，他们甚至可以对某些问题回答“我们不知道”。至少这样一来，我们可以知道，有多少工程资源被分配给了基于充分信息的优先级决策，又有多少被分配给了基于不充分信息的优先级决策。

我曾帮助一家海外体验式旅游公司实施过早期版本的稳健需求管理机制。他们也曾在一次会议分享中介绍过这套机制。

这种方法会招致一些反对，尤其是来自那些原本直接受益于低门槛需求机制的人。他们可能会嘲讽这是在设置关卡。你必须主动解释其必要性。后文会提供一些指导，说明如何应对。这里先列举一些常见反对意见：

• 这会拖慢我们的进度，我们承受不起。
• 先管好我们自己的事情。
• 事先考虑这么多，并不敏捷。
• 创新是不可预测的。
• 我们的项目管理办公室或价值管理办公室已经负责这件事。
• 这不是协作。
• 我们没有相关数据。

如果最后一个问题确实存在，那它就不仅仅是反对意见了。它可能会严重阻碍影响洞察能力的建立，因此需要被立即重视。

“我们没有这些数据”

数据对于回答“稳健需求管理问卷”中的问题至关重要。需求方可能会抱怨，他们没有数据来回答某些问题。那么，CTO 该怎么办？

至少，你可以开始汇报当前状况。我曾帮助另一位客户设计过一套答案评级体系。根据问卷答案，符合条件的需求会被评为从“不合格”到“优秀”等不同等级。其目的，是每月分享一份报告，展示这些需求的论证质量。报告可以让 COO 和 CFO 清楚看到，有多少工程资源被投入到仅仅基于猜测的工作中。通过报告提升认知，是第一步。

当组织意识到存在数据缺口时，新的问题就会出现：为什么我们缺乏数据？常见原因是衡量基础设施不足。我们应该将其定义为“衡量债务”，这样它至少能获得与“技术债务”同等的关注和资金支持。

如果一个组织在实施各项举措时，没有投资建设验证这些举措收益所需的衡量基础设施，那么这个组织就在背负衡量债务。

行动二：偿还衡量债务

解决指标不足的最佳方法，是启动一项衡量能力改进计划。该计划需要组建一个团队，负责消除衡量方面的盲点。但这通常需要额外资金支持，也意味着技术高管可能需要说服 COO 或 CFO。如果这条路不可行，可以考虑先在技术团队内部推动。

率先减少衡量债务。你可以建议团队对应用代码进行插桩，使其在关键节点发出结构化的、与业务影响相关的事件。随后，存储这些事件，并利用它们构建分析仪表板，以帮助验证直接影响和间接影响。这些仪表板必须与新功能同步构建。

要确保团队只是填补衡量与集成方面的空白，而不是重复开发产品团队已经部署的第三方分析工具所提供的功能。如果团队中设有产品运营职能，减少衡量债务可能会更容易。开发人员可以与他们合作，更有效地识别并解决这些差距。

这项工作可以被视为非功能性需求，或者跨功能需求的一部分。不妨将其视为另一种可观测性：业务影响的可观测性。初期只需要针对重要或耗费大量精力的功能开展此类工作。这或许有些非传统，但可能有助于你成为一位更有影响力的 CTO。

行动三：引入业务影响验证

将影响评估制度化，可以帮助你维护一份如下表所示的报告。这份报告总结了前文讨论的各项工作，其预期结果与实际表现之间的差异。产品团队通常应该负责这项工作。如果产品团队负责，工程团队应主动要求参与。如果产品团队没有负责，工程团队就应牵头推进，避免陷入前文所说的“广撒网”式陷阱。否则，当你被问及开发人员生产力时，将没有更好的替代性回答。

现在，你有机会开展影响回顾。对于“预计改善多少、在多长时间内实现”这一问题的回答，可以帮助我们初步确定一次近端影响回顾会议的日期。会议的目标，是讨论预测与实际结果之间的差异。如果存在差距，会议目标应是学习，而不是追责。这将有助于未来预测，并反过来改进稳健需求管理。

近端影响报告样例

功能 / 举措	近端影响指标	预期值或预期改善	实际值或实际改善
客户支持 AI 聊天机器人	高峰时段每小时平均满意聊天会话次数	2350	1654
监管合规 AI 助手	每位分析师每周提示次数	> 20	23.5
监管合规 AI 助手	首次建议所需时间	-30%	-12%
电子邮件营销：个性化发送时间	邮件打开率	10%	4%
电子邮件营销：个性化发送时间	点击率	10%	1%

如果项目推广第一年的实际效果远低于预期，也没关系。项目倡导者可能需要一段时间，才能调整他们对预期收益的乐观估计。这不应影响个人绩效评估。影响洞察的目的，是让资金与项目组合的真实表现相匹配。

影响评估同样适用于下游影响，但影响验证方式会有所不同。这是因为，与直接影响不同，下游影响可能由多种因素共同造成。下表以前面讨论的示例说明这一点。任何下游指标的改善，都不能自动且完全归因于某一项改进。例如，你可能会发现，虽然客户群增长了 4%，但上个季度呼叫量只增长了 2.4%。但这是否完全归功于客户支持聊天机器人？这需要进一步分析。

下游影响报告样例

功能 / 举措	下游影响指标	预期改善	观察到的改善（未归因）	归因改善
AI 聊天机器人	呼叫量（按业务增长调整后）	-2%	-1.6%	？
监管合规 AI 助手	决策时间	-30%	-5%	？
电子邮件营销：个性化发送时间	MQL	7%	0.85%	？
电子邮件营销：个性化发送时间	营销归因收入	5%	不可用	？

下游影响回顾的目的，是将观察到的改进归因于正在实施的各项举措以及其他因素。这被称为贡献分析。工程部门很难独立主导这项工作，因为它需要纳入所有相关举措，即使这些举措并不属于工程部门。此类回顾最好按月或按季度开展，由与相关下游指标对应的业务负责人召集。

因此，即使对一位改革派 CTO 来说，下游影响回顾也可能过于繁重。尽管如此，如果业务负责人愿意开展回顾，你仍然可以确保相关衡量指标已经到位。

为了完整起见，图 7 展示了以客户支持聊天机器人为例，下游影响回顾的结果可能是什么样子。

数据显示，虽然客户群增长了 4%，但呼叫量环比只增长了 2.4%。模型假设，在其他条件不变的情况下，呼叫量变化应该与客户群变化相匹配。然而，我们发现两者之间存在 1.6 个百分点，也就是 160 个基点的差异。我们该如何解释这一现象？

数据分析师可能会告诉你，其中 60 个基点来自季节性因素。剩余的 100 个基点，则可以归因于自助服务渠道，并要求相关渠道申报各自贡献。经过一轮贡献分析后，或许就能得出图中底部所示的数字。你可以使用一些启发式方法和简单的数据分析完成这一判断。我们可以称之为“简单影响归因”，以区别于数据科学家可能更偏好、但并不总是可行的更严谨方法，例如对照实验。

图 7：影响归因示例

行动四：向 CFO 或 COO 提供 ROI 的替代指标

如今，几乎没有人能准确知道一项举措的投资回报率（ROI）。为了获得批准而做出的预测，通常并不是严格意义上的 ROI 指标。它们可能只是声称：通过执行举措 X，某个重要指标将提升 5%。仅凭这些信息，无法确定 ROI。

但是，有了前述影响验证结果后，或许可以计算一个次优但更现实的指标：预测实现率（ROP）。如果某个指标原本预测提升 5%，实际提升了 4%，那么 ROP，也可以称为收益实现率，就是 80%。知道这一点，显然比一无所知要好得多。它也远比“只要举措被正确交付，就一定取得了成功”这种判断方式要好得多。

ROP 衡量的是预测与实际表现之间的差距。科技公司的高管可以鼓励 COO 或 CFO 在下一轮投资决策中使用 ROP，从而做出更明智的投资判断。

在投资前要求详尽论证固然重要，但这些论证都建立在假设之上。预测值通常包含在论证中。如果决策只基于预测，就会激励人们做出不切实际的预测。业务领导者可能会为了赢得投资，或者争取团队能力等资源，而竞相做出过于乐观的预测。毕竟，如果事后无法验证，这些预测就不会受到约束。

除非你拥有一套有效的影响洞察框架。

相关方法论会更详细介绍如何在投资组合层面汇总和使用这一指标。需要注意的是，我们并不是追求完美预测。我们理解产品开发并不是确定性的。相反，我们的目标是抑制不切实际或不合理的预测，从而更有效地管理需求。不要盲目撒网。

行动五：武装你的交付团队

如果你是唯一一位倡导提升影响洞察能力的高管，可能会感到孤立无援。但你不必单打独斗。帮助交付团队理解全局，让他们团结起来支持这项事业。

帮助他们认识到，软件交付并不必然带来业务影响。即使功能被采用，也并不必然产生业务影响。第一步，是帮助他们理解在不同情境下，业务影响究竟意味着什么。

我发现，用图 8 所示的成果层级图来解释这一点很有帮助。最顶层的成果最接近业务影响。较低层级的成果，可能支持或促成较高层级的成果，但我们不能想当然地认为它们必然如此。影响洞察的关键，在于追踪这些预期关联是否如预期那样发挥作用。

当你的团队真正理解了这个层级结构后，他们就能更好地帮助你实施稳健需求管理。他们会开始理解你为什么建议减少衡量债务，也会开始主动向产品和业务负责人询问已交付功能的业务影响。在这一过程中，Worktile 这类通用项目协作系统可以帮助团队把任务、项目、文档、目标、日历、甘特图、工时和审批等协作信息集中管理，减少跨团队沟通中的信息断点，让围绕业务影响的讨论更容易被跟踪和沉淀。

图 8：结果层级

推行业务影响洞察时的常见反对意见

第一项建议行动，也就是引入稳健需求管理，是其他四项行动的关键。如前所述，这项行动可能会遭到目标群体的抵制。下面是应对常见反对意见的方式。

反对意见一：我们不能放慢速度

反对者通常会用“我们没时间回答这些问题，赶紧交付吧”来反驳稳健需求管理。这种做法牺牲准确性来换取速度，并不明智。这里的准确性，指的是充分准备，以便实现预期效果。

为了追求速度而忽视准确性，正如图 1 所示，是一种“广撒网”式失灵，也是一种最终无法持续的盲目尝试。“广撒网”意味着缺乏精准性，依赖运气，而不是依赖技能或策略。任何需要技能和策略的事情，都应该先追求准确性，再追求速度。当准确性不足时，放慢速度以提高准确性，反而有助于提升业务影响。这就像下棋一样。

请注意，所有建议行动都不要求你削减现有提升生产力或流程效率的工作。改革派 CTO 并不是忽视效率，而是努力在追求效率和追求效果之间取得平衡。他们认识到，传统企业过于关注软件交付的敏捷性，也就是流程和产出，却忽视了业务敏捷性，也就是影响，从而失去了平衡。

反对意见二：我们先管好自己的事情

过于尽责的 CTO 可能会犹豫是否要采用稳健需求管理。例如，他们可能会说，等所有 DORA 指标都达到精英级别之后再说。他们可能认为，这是先把工程内部事务处理好。

这是一种善意但错位的判断。如果缺乏影响洞察，每天多次部署又有什么意义？这不过是“速度重于准确性”谬误的另一种变体。

这种思维方式也可能反映了组织信息孤岛。一种不成文的共识是：工程部门只需关注交付速度和质量，也就是快速、正确地构建；而产品经理或业务关系经理负责准确性，也就是构建能够产生业务影响的正确产品。

但如果没有影响洞察，准确性就无从谈起。这只是一种盲目信念。它要么是对创意筛选流程的盲目信任，要么是认为“其他人已经从某项能力中获益，所以我们也一定会获益”。如果你认为这种现状已经导致“广撒网”式功能工厂——而这种情况很可能发生——那么你最好不要过度纠结于“先管好自己”的说法。

反对意见三：这不符合敏捷原则

有时，产品经理或业务关系经理看到“稳健需求管理问卷”中的所有问题，会说：“前期分析太多了！这不符合敏捷开发理念。”

其实，我们并没有深入研究解决方案，只是在认真记录假设。敏捷并不意味着你要从飞机上跳下来，然后在半空中摸索如何着陆。先制定计划，再迭代开发，完全没有问题。

此外，通常会有很多想法争夺有限的工程资源。而正如前文所述，工程资源是一种成本高昂的业务资源。产品待办事项列表的规模，本身就反映了需求量。如果第一轮筛选，也就是产品经理或业务关系经理的筛选不够严格，那么后续筛选就显得更加重要。

AI 带来的生产力提升，有望缓解工程资源有限的问题。但如果只追求功能产出提升，而忽略影响洞察，只会加剧图 1 所示的恶性循环。

敏捷宣言提倡“可工作的软件高于详尽的文档”，但这并不意味着不需要记录为什么要开发这款软件。遗憾的是，可工作的软件并不总是能带来业务影响。我们也没有违背“响应变化高于遵循计划”的原则。稳健需求管理问卷并不是计划，而是对假设和预期影响的记录。

反对意见四：创新是不可预测的

创意倡导者可能会抗议说，他们无法在早期阶段确定收益。那么，在确定优先级和安排进度时，我们就不要再假装一切尽在掌握。不要为了抢占资源而做出不切实际的预测。

如果他们相信自己的预测，就通过问卷记录这些信念，并在交付后重新审视。如果组织想在没有任何可靠信息证明其收益的情况下继续开发功能，也应该把这一点记录下来。那些签字拨款的人应该清楚，他们的资金有多少被用于盲目尝试，甚至是在迷雾中摸索。

这并不是要消除失败。失败是创新的一部分。真正的问题在于，传统企业往往根本不知道某个项目没有带来足够的业务影响。如果他们知道了，就可能停止继续使用已经开发出的项目，从而避免由此产生的技术臃肿和运行成本。

反对意见五：我们的项目管理办公室或价值管理办公室已经负责这件事

不，他们通常没有真正做到。他们也许有创意论证模板，但他们既没有手段，也没有权限在交付后验证影响。此外，他们的模板可能缺乏针对性问题，或者他们早已接受了含糊不清的答案。有时，他们会把“工作已完成”或“资金已花出”含糊地报告为“收益已实现”。也就是说，只要交付了功能或投入了资金，就被默认认为实现了预期业务影响。

另一方面，如果他们确实已经有类似问卷，并且工作到达你这里之前已经被正确填写，那么请务必使用这份问卷继续完成其他建议步骤。没有必要重复造轮子。

反对意见六：这不是协作式的

变革并不容易。作为一位改革派 CTO，你竭尽所能力求带来真正改变，但仍可能被指责缺乏协作精神。那些习惯于让自己的意愿被优先考虑并排入计划的人，可能会抱怨你是未经授权的守门人。

因此，在开启改革之旅前，你应该先争取 COO 或 CFO 的同意。

还有一点需要注意。虽然本文为了清晰起见使用了“稳健需求管理”这个术语，但在社交场合或正式介绍时，你也许不应该使用这个词。可以考虑称之为“可验证的想法”或“充分公开的想法”。这样的表述更容易被接受。

立即行动：让 CTO 从交付执行者走向业务影响推动者

如果你的同事以及技术部门以外的高层领导没有主动提升影响评估能力，那么为了你自己，也为了公司利益，你必须挺身而出，采取行动。

建立稳健需求管理机制，减少衡量能力缺口，引入影响验证机制，并分享预测与实际结果的对比报告。赋能你的团队，让他们能够专注于业务影响。这样做，你就能摆脱关于开发人员效率的低效争论。更重要的是，你能够引领组织提升可自由支配支出的业务影响。

这些建议行动并不容易。它们甚至可能让你觉得难以应对，以至于你宁愿继续专注于提升生产力，也不愿尝试成为一名改革派 CTO。但如果那样做，你可能永远无法真正衡量这些措施对业务的影响。你或许不得不接受图 1 所示的恶性循环。

而且，核心高管团队也会始终把你的角色视为执行者：专注于技术交付、基础设施和运营。这本身并没有错，除非你认为自己可以做得更多，也可以做得更好。