如何用 NPS 确定研发优先级，打破技术与业务的次元壁？

「不了解利益相关者的需求是僵尸 Scrum 团队的四大常见症状之一，其主要表现为成员们忽视价值链上下游的内容，无法或不愿意带来任何改变或影响」，《拯救僵尸 Scrum》如是写道。

它们的工作，以及工作所涉及的组织，往往被设计成远离真正使用产品或者为产品付费的人。……其结果是，团队大量炮制出价值可疑的产品功能。这些功能可能不是利益相关者真正需要的。或者它们很好用，但并不能真正帮助用户提高工作效率。这可能是产品开发中最大的浪费：平庸的产品没有提供多少价值。

——《拯救僵尸 Scrum：卓越敏捷团队生存手册》

《拯救僵尸 Scrum》从现象出发诊断僵尸 Scrum 的症状，运用大量的真实案例，解码僵尸 Scrum 给团队和组织带来的危害。同时，全书蕴藏大量的实践指南，提供了一系列的诊断工具和实验，有助于迅速提升 VUCA 时代下的团队和组织效能。对组织管理者、Scrum Masters，以及任何愿意了解如何摆脱僵尸 Scrum 困局的团队来说，这都是一本实操性极强的必读宝藏书籍。（此处感谢👉优普丰敏捷教练👈小伙伴的空投！比心🙆‍♀️）

那么，面对复杂多变的环境，企业应当如何培养并平衡团队的客户视角与商业视角，让组织专注于有效的价值交付而非高效的产出，真正打造利益相关者需要的产品，避免陷入/及时摆脱「僵尸 Scrum」困境？

本文将分享一个能够有效弥合技术和业务部门的理解鸿沟，让研发交付围绕业务和价值展开的管理指标—— NPS。

01 什么是 NPS？

NPS（Net Promoter Score），净推荐值，由 Fred Reichheld 于 2003 年提出，用于评估客户自发推荐产品的意愿强弱/可能性大小