知识工作者的生产力很难量化而且往往与直接业务成果脱节。缺乏这种认知会导致组织不断发起各种所谓提升开发者生产力的举措造成技术支出膨胀并做出并不恰当的投资选择。技术领导者尤其是 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。行动一引入稳健的需求管理产品经理可能负责对创意进行分类和优先级排序但他们并不总是能够很好地记录创意选择背后的理由。无论是商业案例还是论证幻灯片一份好的文档都应该回答“稳健需求管理问卷”中的所有问题。稳健需求管理问卷如果一个想法能够清晰回答以下问题那么这个想法就得到了较充分的论证这个想法试图解决什么问题或者它试图利用什么机会有什么证据表明这个问题或机会确实存在提议的解决方案是什么谁是主要倡导者曾经考虑过哪些替代方案哪些方案被放弃了为什么该方案可能改善哪些指标包括直接指标和下游指标。预计改善多少在多长时间内实现你对此有多大把握依据是什么这些预期建立在哪些假设和依赖关系之上如何验证影响我们是否具备相应的衡量能力如果不做这件事会有什么风险这些风险发生的可能性有多大一张被广泛理解的影响网络有助于回答上述部分问题。但对于稳健需求管理而言真正关键的不是影响网络本身而是这些问题的答案。回答这些问题才能形成 SMART 的想法也就是具体、可衡量、可实现、相关且有时限的想法。否则这些想法就可能是 VAPID 的模糊、含混、空想、不相关且遥遥无期。对于 VAPID 想法即使技术交付完成也很难验证其业务影响。这会导致图 1 所示的不良后果。为了避免这种情况你必须坚持将团队资源——这本质上是宝贵的业务资源——分配给那些经过充分记录的想法而不是分配给所有看起来重要的项目。当然这种做法只适用于需要投入较大精力的工作而不是每一个用户故事或缺陷。你可以自行设定阈值例如两周工作量以上。还需要区分优先级排序和进度安排。前者是为工作项分配优先级后者是将工作项安排到具体工作周期中例如某个迭代。许多组织没有区分这两者而是把优先级排序等同于进度安排。请重新思考这一点。产品经理仍然有权确定优先级。进度安排则一直受到实际因素影响例如依赖关系或者某些团队成员的可用性。现在进度安排也应考虑上述问题是否得到回答。对于希望把目标、反馈、需求、评审、排期、开发、测试、发布和知识沉淀串联起来的研发组织PingCode 这类智能化研发管理工具也可以作为承载稳健需求管理的系统基础让需求选择、交付过程和影响验证之间的数据更连续。如果这些问题已经在创意筛选阶段得到回答工程团队必须能够访问相关信息。稳健需求管理意味着除了常规文档要求例如产品需求文档之外工程团队只会承接已经按上述方式记录的工作。这也意味着不仅你自己你的团队也必须理解影响洞察是什么、如何运作以及为什么重要。后文会对此做更详细说明。需要注意的是文档齐全并不一定意味着理由充分。稳健需求管理并不意味着工程部门要自行判断某项工作是否值得做而只是确保预期收益和时间表以可验证的方式记录下来。产品部门仍然拥有优先级决策权。为了安排工作他们甚至可以对某些问题回答“我们不知道”。至少这样一来我们可以知道有多少工程资源被分配给了基于充分信息的优先级决策又有多少被分配给了基于不充分信息的优先级决策。我曾帮助一家海外体验式旅游公司实施过早期版本的稳健需求管理机制。他们也曾在一次会议分享中介绍过这套机制。这种方法会招致一些反对尤其是来自那些原本直接受益于低门槛需求机制的人。他们可能会嘲讽这是在设置关卡。你必须主动解释其必要性。后文会提供一些指导说明如何应对。这里先列举一些常见反对意见这会拖慢我们的进度我们承受不起。先管好我们自己的事情。事先考虑这么多并不敏捷。创新是不可预测的。我们的项目管理办公室或价值管理办公室已经负责这件事。这不是协作。我们没有相关数据。如果最后一个问题确实存在那它就不仅仅是反对意见了。它可能会严重阻碍影响洞察能力的建立因此需要被立即重视。“我们没有这些数据”数据对于回答“稳健需求管理问卷”中的问题至关重要。需求方可能会抱怨他们没有数据来回答某些问题。那么CTO 该怎么办至少你可以开始汇报当前状况。我曾帮助另一位客户设计过一套答案评级体系。根据问卷答案符合条件的需求会被评为从“不合格”到“优秀”等不同等级。其目的是每月分享一份报告展示这些需求的论证质量。报告可以让 COO 和 CFO 清楚看到有多少工程资源被投入到仅仅基于猜测的工作中。通过报告提升认知是第一步。当组织意识到存在数据缺口时新的问题就会出现为什么我们缺乏数据常见原因是衡量基础设施不足。我们应该将其定义为“衡量债务”这样它至少能获得与“技术债务”同等的关注和资金支持。如果一个组织在实施各项举措时没有投资建设验证这些举措收益所需的衡量基础设施那么这个组织就在背负衡量债务。行动二偿还衡量债务解决指标不足的最佳方法是启动一项衡量能力改进计划。该计划需要组建一个团队负责消除衡量方面的盲点。但这通常需要额外资金支持也意味着技术高管可能需要说服 COO 或 CFO。如果这条路不可行可以考虑先在技术团队内部推动。率先减少衡量债务。你可以建议团队对应用代码进行插桩使其在关键节点发出结构化的、与业务影响相关的事件。随后存储这些事件并利用它们构建分析仪表板以帮助验证直接影响和间接影响。这些仪表板必须与新功能同步构建。要确保团队只是填补衡量与集成方面的空白而不是重复开发产品团队已经部署的第三方分析工具所提供的功能。如果团队中设有产品运营职能减少衡量债务可能会更容易。开发人员可以与他们合作更有效地识别并解决这些差距。这项工作可以被视为非功能性需求或者跨功能需求的一部分。不妨将其视为另一种可观测性业务影响的可观测性。初期只需要针对重要或耗费大量精力的功能开展此类工作。这或许有些非传统但可能有助于你成为一位更有影响力的 CTO。行动三引入业务影响验证将影响评估制度化可以帮助你维护一份如下表所示的报告。这份报告总结了前文讨论的各项工作其预期结果与实际表现之间的差异。产品团队通常应该负责这项工作。如果产品团队负责工程团队应主动要求参与。如果产品团队没有负责工程团队就应牵头推进避免陷入前文所说的“广撒网”式陷阱。否则当你被问及开发人员生产力时将没有更好的替代性回答。现在你有机会开展影响回顾。对于“预计改善多少、在多长时间内实现”这一问题的回答可以帮助我们初步确定一次近端影响回顾会议的日期。会议的目标是讨论预测与实际结果之间的差异。如果存在差距会议目标应是学习而不是追责。这将有助于未来预测并反过来改进稳健需求管理。近端影响报告样例功能 / 举措近端影响指标预期值或预期改善实际值或实际改善客户支持 AI 聊天机器人高峰时段每小时平均满意聊天会话次数23501654监管合规 AI 助手每位分析师每周提示次数 2023.5监管合规 AI 助手首次建议所需时间-30%-12%电子邮件营销个性化发送时间邮件打开率10%4%电子邮件营销个性化发送时间点击率10%1%如果项目推广第一年的实际效果远低于预期也没关系。项目倡导者可能需要一段时间才能调整他们对预期收益的乐观估计。这不应影响个人绩效评估。影响洞察的目的是让资金与项目组合的真实表现相匹配。影响评估同样适用于下游影响但影响验证方式会有所不同。这是因为与直接影响不同下游影响可能由多种因素共同造成。下表以前面讨论的示例说明这一点。任何下游指标的改善都不能自动且完全归因于某一项改进。例如你可能会发现虽然客户群增长了 4%但上个季度呼叫量只增长了 2.4%。但这是否完全归功于客户支持聊天机器人这需要进一步分析。下游影响报告样例功能 / 举措下游影响指标预期改善观察到的改善未归因归因改善AI 聊天机器人呼叫量按业务增长调整后-2%-1.6%监管合规 AI 助手决策时间-30%-5%电子邮件营销个性化发送时间MQL7%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 所示的恶性循环。而且核心高管团队也会始终把你的角色视为执行者专注于技术交付、基础设施和运营。这本身并没有错除非你认为自己可以做得更多也可以做得更好。