超越速度：以影响而非速度衡量工程成功

对许多软件开发团队而言，速度（velocity）——衡量开发者投入的工作量，通常以冲刺中完成的故事点计——似乎是跨项目、跨计划衡量输出的最佳方式。但从负责衔接技术执行与业务目标的领导者视角看，它远不能说明全部问题。若速度很高，为何营收、留存或销售等业务目标仍未达成？

当技术领导者跳出“输出”看“影响”，企业会更繁荣，团队也更健康。但如果速度只是工具而非目标，该如何衡量软件开发团队的真正成功？答案在于理解组织的核心目标，以及软件开发团队如何为其贡献力量。“我们如何超越速度这类指标，触及真正的业务影响？”LinearB联合创始人兼COO丹·莱恩斯（Dan Lines）在节目中问，“我的客户群和接触的人都对生产力负责。所以我认为第一步是明确：什么是真正的业务影响。”

速度的陷阱

从规划和问责角度看，速度给了团队一个清晰的“输出vs工作量”衡量方式。它能帮助规划冲刺、优先长期生产力目标，甚至辅助问责——让团队合理调整工作量并跨部门沟通。

问题始于将其作为团队成功的唯一指标。它无法揭示高层战略思考和定位所需的细微差别，反而树立了一种标准：过度强调纯工作量，而非对组织目标的有效投入。

团队可能“快速推进”却未交付有意义的结果。这时，质量往往为数字牺牲：偷工减料、跳过测试和评审，速度却越来越高。开发者体验（DX）平台将速度列为开发者五大 flawed 生产力指标之一，称团队可能虚报数字显得更高效，最终背离了帮助团队估算和沟通工作的初衷。

当领导层传达的目标只是“每个冲刺冲更高数字”，我们能怪开发者吗？正如马修斯在之前的Stack Overflow博客中写道：“所有团队成员（不止开发者）开始意识到自己没做正确决策——走偏了路，但这个任意的速度数字却定义了对错。”

在强调速度高于一切的团队中，倦怠是必然结果。工程师被要求做更多事，却不明白自己的工作有何意义。德勤报告显示，75%的IT、工程和商业领袖认同：开发者体验对整体业务成功至关重要。许多领导者清楚，软件开发团队一旦倦怠，涟漪会波及整个组织。

速度简化了软件开发团队复杂且具创造性的工作，将协作过程塞进简单数字，无法讲述组织健康的全貌。但这并不意味着速度在高效团队中毫无用处。

速度是工具，不是目标

速度提供的是开发团队的单一快照。“很多人视其为团队指标，”马修斯在LinearB的《Dev Interrupted》播客中说，“但我们真的把它当作众多数据点之一。”作为诊断工具，它能帮领导者判断策略何时有效、团队何处需增资源。

当团队速度高时，工程领导者应细究其工作方式，理解效率来源；若速度低于预期，可能是时候重新审视目标、调整策略。也要注意，两种情况都可能受不可避免的业务因素影响——病假、季节性放缓或领导层变动，都会冲击速度的原始数字。

说到底，速度不是全貌，只是工程领导者理解团队状况的一个指标。那么，若速度不是目标，什么才是？

如何衡量开发者的成功

考虑衡量开发团队成功时，麦肯锡警告避免过度简化，鼓励领导者理解工程的复杂性，更好支持团队的创造性与协作过程。团队时间投在哪里？瓶颈在哪？是否达到行业标准基准？谷歌近期的EngSat调查显示，速度、易用性、质量都是开发者满意度与生产力的关键标志。

但仅靠领导层对开发团队的可见性不够。开发者也需要明白：自己的工作如何影响和支持公司级目标与计划。当开发团队被孤立、仅按纯数字考核时，其对整体业务的影响力会被扼杀。

当领导层与软件开发团队合作解决业务挑战，会在每个开发者与终端客户间建立高度可见的价值流。对技术驱动型组织而言，开发者体验与满意度是首要任务，透明度、工作认可等因素对开发者福祉影响深远。

最关键的是，业务与技术领导者要为工程师制定与整体业务目标对齐的成功路线图。不同企业的业务目标差异巨大：“对我合作的一些领导者来说，真正的业务影响可能很简单——我们得更快上线……另一些则可能是在生产环境出了问题，客户正不满，此时真正的业务影响是提升质量。”

将工程OKR（目标与关键成果法）直接与产品或业务目标挂钩，能让团队为目标努力，而非仅为输出。对马修斯而言，让软件开发团队参与决策本身至关重要：“你和其他人一样是利益相关者。我们让你参与用户会议、销售和客户支持会议。这真的能把业务影响更全面地传递给所有工程师。”

新指标的实施

和任何策略变革一样，超越输出、转向影响也有陷阱。领导者需定期审视团队贡献的衡量效果，相应调整。

团队也需要充分理解被衡量的内容及原因，并有空间适应新汇报指标。花时间研究客户、设定清晰目标、测试想法的软件开发团队，其功能的年度积极影响比率更高。

随着新洞察出现，领导层应庆祝成功，将低谷视为改进机会，而非推动团队无反思地增加输出。

速度是领导者的好诊断工具，却无法呈现开发团队健康度与生产力的全貌。随着技术日益复杂，认可开发者的创造性与协作性工作，对开发者体验比以往更重要。而超越纯输出后，开发团队能支持组织级目标，对业务的健康与成功产生真正影响。