不过很遗憾，这并不是一个正确的问题——这也是九成的初创公司走向失败的一个重要原因。据 Exploding Topics 报道，10% 的初创企业无法顺利度过第一年，而 70% 的企业也在第 2~5 年宣告失败。 最终，只有十分之一的初创企业能够幸存。

在过去 20 年与创业者的合作中，我参与了 20 多家初创企业从创意萌生到 IPO 的全过程——能获得成功的公司少之又少。我从中学到最有用的一课，不是「企业为什么能成功」，而是它们「会被什么击败」。

其中大部分首次创业者不够投入，往往仅凭直觉就匆忙拼凑出一个不经测试的产品，而其他人则是过于投入而忽略了市场验证和测试，产品功能要么太过单一，要么过分臃肿。

你可能想说：“这不就是没有通过 MVP （Minimum Viable Product，最小可行性产品）进行快速学习吗？”

——说的很好，但也不准确。

这个问题的关键在于「V」是什么。在商业语境下，真正重要的是 Viable 还是 Valuable？

首先，让我们从灯泡的故事讲起。

灯泡带来的启示

你或许在小学时学过「爱迪生发明了电灯泡」。

但事实并非如此。

在爱迪生之前，包括埃比尼泽·金纳斯利（Ebenezer Kinnersley）、汉弗里·戴维 （Humphry Davy）和约瑟夫·斯万（Joseph Swan）在内的许多发明家已经发明出了各式各样的白炽灯丝。甚至在 19 世纪 70 年代，当爱迪生转向安全、可持续、经济且无异味的照明方案研究时，就已经有了一些关于白炽灯泡的专利（当时主要的室内照明方案是煤气灯）。

作为一名创新者和企业家，爱迪生早就决定，商业变现不必依靠发明本身。他更感兴趣的是「完善」，即让事情变得更好或更便宜。 我很喜欢《纽约客》的说法：

爱迪生从不寻找需要解决方案的问题，他所找的是需要修改的解决方案。

当时现有的灯泡解决方案不太实用，而且灯泡的使用寿命也不长。也就是说，它们是可行的，但并不是特别有价值。

这正是爱迪生能够脱颖而出的原因。爱迪生和他的团队在位于加州门洛帕克的总部对 3,000~6,000 种材料和灯丝进行了测试，直到 1879 年才发现碳是最佳的解决方案。一年后，他们发现碳化竹子可以燃烧超过 1,000 个小时，于是今天为人熟知的白炽灯泡诞生了。

爱迪生如此努力创造的不是 MVP，而是 MVE（Minimum Valuable Experience）——最低价值体验。

如何将人们迫切需要的东西，变得易于获得、经济实惠且经久耐用？ 这才是真正的「灵光一现」。

A.C.T 框架

了解如何建立 MVE 前，有两个关键点需要注意：

• 你的故事就是策略。
• 表达的方式非常重要，它决定了用户对产品是「无感」还是「每月复购」。

所有的一切都是为了了解你的用户，了解什么话术和信息能够引起他们的共鸣，以及哪些策略、触点和触发条件能够刺激他们采取行动。

为了快速高效地建立 MVE，我开发了「A.C.T 框架」。它有助于快速明确方向并节省大量无用的营销活动。A.C.T 框架由三个重要部分组成：

• Audience 受众
• Communication 交流
• Touchpoints 触点

A = 受众群体：你要对「谁」说话？

想要知道说些什么，首先得弄清楚你要跟谁交流。

• 谁是你的理想客户？
• 客户考虑新的解决方案时，想要/需要/使用的是什么？
• 在寻找新方案的过程中，他们会搜索什么？
• 是哪些习惯、行为、目标或者决定性特征吸引了他们来使用你的产品？

C = 交流：你要说什么？

这是一件「用什么方式传递什么信息」的艺术。

你必须用能够引起客户共鸣的语言和方式，用他们的方法跟他们交流，去传达那些适配他们味蕾（和钱包）的愿景或动机。

T = 触点：在哪分享信息？

弄清楚「和谁说」以及「说什么」之后，就可以好好想想「该怎么做」了。

设计能刺激客户采取实际行动的触点和触发条件，包括官网展示、社媒传播和邮件营销等等。其核心目的是辨别和确定最有效且投资回报率最高的渠道和策略。

这也是最容易出错的部分。有时候，你可能只需要一个简单的注册表单，而有的时候则需要采取更有策略性（如建立私域群组）或更复杂（如一个详细的销售漏斗和沉浸式故事）的方法。

案例应用

假设现在要推出一款全新的无酒精啤酒饮料，你会如何应用 A.C.T 框架回答以上问题？

（花点时间，动动小脑瓜 ）

下面分享我的回答。别担心，问题没有标准答案，思路和分析才是重点。

A：无酒精啤酒的理想受众是谁？

传统人口统计特征中的年龄、性别或地理位置等数据并不能提供太多有效信息，因为无酒精啤酒很可能不在任何标签中。

从行为角度来看，购买无酒精啤酒的人喜欢喝啤酒，但不喜欢酒精对健康、行为能力和工作效率的影响；他们富有猎奇心，足够开放，愿意尝试和接受新鲜事物。

C：要向他们传递什么信息？

我需要让理想客户知道，这款饮品提供了最接近啤酒的体验：它采用高品质原料，通过手工精酿制成，其炫酷的包装甚至可以媲美最流行的 IPA 啤酒。最重要的是，它的热量很低，并且不会产生任何宿醉感。

T：在什么渠道发布和传播信息？

无酒精啤酒代表了一种健康但仍然可以享受乐趣的生活态度，所以年轻化的短视频平台是很好的渠道。如果是线下宣传，健身房旁边的水吧或者支持多人聚餐的健康餐厅也是不错的选择。

A.C.T 框架有助于了解「哪些体验或触点可以带来产品吸引力」。

对某些人来说，最好的触点可能是社交媒体上某个热门话题下的一张精美表单；对其他人而言，可能是一个关于产品如何提升生活品质的巧妙故事，或者一场能够清楚传递「我们如何能帮你成为更好的自己」的精彩活动。不同的品牌和产品会有不同的答案。

而「A.C.T + MVE」能让你快速迭代，获得最有价值的体验。当你专注于研究潜在客户真正重要的事情时，你就能点亮他们的生活。

在我看来，这是通往商业成功的唯一可行路径。

原文作者为 Pete Sena，内容经 LigaAI 翻译整理。

>> LigaAI 往期精彩阅读 <<

6 大原则！助你构建高绩效的研发强军 | Liga译文

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

• 你的产品待办列表中有多少项工作？
• 其中最早的待办事项是什么时候创建的？
• 你和 Scrum 团队多久会维护一次列表中那些从没进过迭代的「钉子户」事项？

我第一次问自己时，得到的答案是这样的：

• 产品待办列表中有 450 个待办事项；
• 最早的一项在三年零七个月前创建；
• 至少有 100 个事项被完善和评估，却从未被规划进迭代。

我开始反思产品待办列表（Product Backlog）和产品待办事项（Product Backlog Item）的奇怪现象，随后确定了一件事情：我没有理解「敏捷」的真正含义。

现在我将与你分享，为什么清理（甚至删除）产品待办列表可能让你拥抱更自由的敏捷。

01 笨重的产品待办列表是敏捷的劲敌

你能立刻说出「敏捷」的含义吗？

一千个人眼中有一千个哈姆雷特，而我的理解是：敏捷要更快地向用户和业务提供价值。

对于抽象的「价值」，大家或许也会有不同的解读。于我而言，「提供价值」意味着在帮助用户解决问题的同时，为业务带来回报。

从容地面对未知是践行敏捷的关键。

追本溯源，敏捷强调拥抱变化，在变化中学习。我们应该简单地创建假设、验证假设、学习、检查并调整。这听上去并不复杂，但不知何故，很多人都把它变得无比复杂，包括我自己。

庞大的、笨重的产品待办列表恰恰是敏捷的反面。我猜你可能会反驳说自己很敏捷，但你是不是

• 让事项在产品待办列表中呆了很多年？
• 不敢删除任何待办事项，唯恐惹恼干系人？
• 同开发人员一起浪费大量时间处理一些永远不被排进迭代的需求？

我认为，任何有超过三个迭代工作量的产品待办列表都是笨重的。如果产品待办事项的数量比 Scrum 团队几个迭代的工作量还要多，那就说明团队当前「拥抱计划 > 拥抱变化」。那这到底是敏捷呢？还是瀑布呢？

要想实现价值，就必须维护一个精益的产品待办列表。不要被计划的假象所迷惑。

02 大胆地删除产品待办事项

作为一名产品负责人，再没有什么比笨重的产品待办列表更能让我恐慌了。无条件地向利益相关者承诺交付，美其名曰「客户至上」；但事实上，在现存的所有产品待办事项中，有近乎一半的承诺难以兑现——它们始终在待办列表中占有一席之地，被「计划中」完美掩护。产品负责人换了一个又一个，它们却一直没有被交付和满足。

一个无限制的、庞大而笨重的待办清单让我们永远无法兑现所有的承诺。这也是一种无法持续管理产品待办事项的坏方法。

不要用「把需求放进产品待办列表」的方式，愚弄利益相关者。

我先后在多个组织担任过产品负责人，在很长的一段时间里，我都在以一种低效的、甚至可以说是毫无意义的方式适应新工作。我之前的做法是：

• 阅读整个产品待办列表；
• 接触关键干系人，了解每个事项背后的需求；
• 结合交流结果，丰富产品待办事项；
• 确定事项优先级，为产品待办列表排序。

这样做的结果是，我浪费了大量的时间，还给自己带来了更多来自不同干系人的压力。每个人都急切地想要一些东西，但没人愿意把自己的需求从产品待办列表中删除。

这是一个很常见的错误：让利益相关者掌握主动权，而不是自己把控产品方向。

现在，我会先做这些事：

• 理解产品战略；
• 清理/删掉产品待办列表；
• 定义要验证的假设；
• 创建与战略相关的事项，重建列表。

你一定在想：把产品待办列表删掉也太激进了！

是的，你说得对。但是，为了更快地交付价值，我们必须采用非常规的，乃至极端的办法。除非能消除所有干扰，否则你没有时间去做最重要的事。

我删掉了利益相关者想要的需求，他们会生气吗？肯定会啦，但是这跟他们发现产品无法达到预期而发的脾气可没法比。

再说一个秘密吧：我曾经一次性删掉了大约 500 个产品待办事项，最后只有 2 位利益相关者向我提出了疑问，而其他人没有任何反馈。我的经验是，如果你申请删除某个事项，大概率会被拒绝；但如果愿意冒一次险，那你可能会收获意外之喜。

03 没有冲突，敏捷就枯萎了

做对产品有利的事情很难不惹人生气。因为我们无法通过取悦所有人，更快地交付价值。正确地做产品一定需要面对冲突和压力，而处理冲突的能力又将决定我们是否是合格的产品负责人。

同生活中的任何事情一样，短期利好很可能是靠牺牲长期利益实现的。

如果产品待办列表能完美地符合利益相关者的期望，他们会在一开始时非常高兴，但久而久之逐渐失望，因为团队无法实现他们的预期。如若在最开始就选择那条艰难的路，选择拥抱冲突来实现承诺，那你将可以带领 Scrum 团队交付价值，而不是陷入 WaterScrumFall 的错误模式。

为了确保自己不会陷入「有效性错觉」，请每 3 个月清理一次产品待办列表，为新事物腾出空间，让噪音消失；也为 Scrum 团队留出时间复盘学习成果，评估当前的目标和意义，重新开始。

最后，有效性错觉和技能错觉是由一种强大的专业文化来支撑的。我们知道，在任何情况下，当身边的人都跟自己持同样的想法时，不论这种想法有多么荒唐，人们都能保持一种不可动摇的信念。——《思考，快与慢》，丹尼尔·卡尼曼

# LigaAI 总结

敏捷强调要拥抱变化，拥抱学习。无限制的、笨重的产品待办列表会使组织无法快速响应变化，而无法如约交付承诺也会让利益相关者越行越远。

定期清理产品待办列表，维护组织价值交付的敏捷性，始终关注最重要的事情，才能让企业和组织保持活力，一往无前。

（原文作者为 David Pereira，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

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

这 4 个系统可靠性评估指标，可能比 MTTR 更靠谱！

LigaAI：从效率、度量和价值维度，成为研发团队的智能医生

高绩效团队的 5 个优秀习惯，看看你占了几个？

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

你很难找到一个组织，可以让你按照最初的设想构建产品。通常，你需要做出一些妥协（有时甚至是很大的让步）来适应组织并维持自己的收入。

你会发现有一些人总在妥协，而他们的特点也非常明显。一种是灭火达人。 产品着火了，利益相关者上火了，产品经理也火烧屁股了。他们每天被战火纷争的会议塞满，却完全没有交付价值，只是被推着不停修复 Bug 并匆忙上线。

另一种是产品交付师。 他们的主要工作是交付，而不是思考。他们与完美无缺的待办列表和精美的用户故事一起工作，一个接一个地发布功能；没有价值评估，也不收集反馈，只是不断地发布、发布、发布……

不要变成他们，他们已经被抨击得够多了；你应该努力尝试摆脱它们。这两种是很容易识别的错误类型，你都不需要阅读其他文章来了解它们。今天，我想说明一些不那么容易识别的错误示范——它们看起来很像产品管理，但其实不是。

你通常可以在产品成熟度较高的公司中发现它们，而且很少有人愿意指出或批评这些问题，因为这会触动一些人的神经。但，管它呢，我爱干这种事。

第一类：产品学者 Product Scholar

这是一个经典类型，可以在 Medium 或 LinkedIn 上找到（很多）。产品学者总是讲很多，但交付得很少。 讲学是一件相当容易的事情，但他们似乎忘了「知道怎么做」并不等同于「能够做得到」。

产品学者们经常会在会议上丢出知识炸弹，比如「我们不能依赖假设」或「我们必须确保向用户交付价值」。之后，他们挥一挥衣袖，消失在迷雾中，而工程师和设计师则被留下做真正的决策。

他们大力提倡「持续发现」和「价值主张设计」，却没有可以展示的 KPI；只提供理论和指导，然后让小组里的 Tech Lead 或设计师为其工作。产品学者是产品经理里的「嘴强王者」，在业务上的表现却相当糟糕。

第二类：探索经理 Discovery Manager

与产品学者相比，探索经理说得并不多。事实上，他们非常害羞——他们会将话语权范围限制在创造假设上，从不承诺解决方案。这种类型的行为红线是，一个人应该与问题作伴而不是与解决方案。谈论「要交付什么」似乎成了他们的禁忌。

他们对任何事情都没有信心，从不承诺；他们避免大规模交付，因为他们没有承担风险的能力。 这些专业人士让业务内非技术垂直部门的同事不喜欢「探索」这个词。

探索经理将拥有一个美丽的机会解决方案树，但他们永远不会把它交付出去。他们只实现那些被告知要做的事情，或者到处灭火。

第三类：数字经理 Data Manager

不要将它和数据产品经理弄混，后者很好。数字经理是盲目追随数据的产品经理；如果没有数据，他们就无法完成工作。

如果说「灭火达人」和「产品交付师」是一种极端，那么「数字经理」和「探索经理」则是另一种极端。任何没有数据支持的反馈都该阅后即焚，不管它是客户要求的、老板指定的，还是从知识中获取得到的。

数字经理没有恶意，但他们常常因为缺乏灵活性，而对存在于数字外的机会和问题视而不见。数据驱动是指尽可能地诉诸数据，而不是完全依赖数据。

许多我们今天认为很棒的产品都不是建立在大样本 A/B 测试上的，它们也没有庞大的用户群组可以用于行为跟踪；而数字经理似乎忽视了这一事实。

第四类：产品巨星 Product Superstar

这是一个复杂的类型。理论上，产品巨星做的一切都是对的，问题出在他们的目标/出发点。

产品巨星对向用户提供价值，为业务负责并不感兴趣，他们关心的是「哪些交付能让他们成为焦点」。 有时候这两件事是一致的，但有时候不是。

产品巨星有耀眼的 KPI 可以展示，通常是基于技术细节的对象。尽管企业有负面新闻但 NPS 异常高，或者一个产品不为人知却增长惊人，都可能是由产品巨星掌控的。

不要误会，在工作中寻找发光的机会是可以的。产品巨星的问题在于，他们将这种雄心壮志视为优先级矩阵的一部分。并非所有发光的机会都是充满吸引力的，而巨星们永远不会去碰这些。

第五类：产品狂热者 Product Zealot

产品狂热者也是产品经理；事实上，还是很好的产品经理。他们的过错不是提供了预期外的表现，而是不能接受——如我开头所指出的——在工作中妥协和让步。

在科技行业大裁员之前，他们处于相当安全的位置。托 Cagan、Perry、Ries 和 Torres 的福，非技术部门不得不忍受他们以「用户价值」和「增长」为由，否决大部分功能和需求。

现在，世界变了，那些曾经遭受压迫的人重新拿到了话语权。创新和增长失去了在谈判桌上的位置，而那些真正能够带来稳定的、可靠的收入的人成为了交易者。

产品狂热者常常忽略一件事情：产品团队创造的所有增长和价值，只有在用户愿意为它买单时才有意义。 有时候你不得不因为大客户的一句话，就去灭火或者交付一个未完成的功能——没关系的！亚马逊被认为是最好的产品领导组织之一，哪怕是他们，也会在老板的命令下推出失败的产品——Fire Phone。

写在最后

在这些原型中看到其他人很容易，但你自己能「对号入座」吗？我很确定，你很可能是其中一个或多个类型的结合体（就像我自己一样）。

不需要遮遮掩掩，我们都是一样的。成为一个小小的「学者巨星」会让你有更多的机会；在组织中，当一名「数字经理」或「探索经理」也可能完全够用，不要为此感到沮丧。

无论你是否认为自己是产品经理，想要获得团队和整个组织的身份认可，下面这三点非常重要：

1. 承担起负责任的风险，抓住机遇。

2. 实现高效和有效的交付。

3. 与其他部门沟通和同步风险及交付情况。

（原文作者：Antonio Neto；文章出处：Medium)

>> LigaAI 往期精彩阅读 <<

什么是研发 Lead Time？我终于掰扯明白了！

研发效能管理中的经典度量——DORA 指标

清单推荐：常见的研发效能度量指标（科学管理版）

新任技术管理者如何更快更好地适应角色转变？

LigaAI 将持续分享更多成长经验、研发效能管理实践，陪伴每一个研发团队和开发者成长。欢迎关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

12 月 21 日，LigaAI 特别策划了「敏捷三人行」直播活动，与优普丰首席敏捷教练申健、乐豆信息 (Beansmile) 创始人杜立刚 (Leon) 一起探讨、分享并总结了快速识别高价值反馈、高效响应用户需求的经验之道。直播全程高能，金句频出，下面就随 LigaAI 一起回顾精彩内容吧！

一、 找准 「话语权」，让事情更顺利

主持人：任何形态的软件产品一旦面世，就会面对各种各样的用户反馈。B 端产品和 C 端产品在反馈关注点和处理流程上，都有哪些差异？

LigaAI – 张思：产品发布上线后，用户反馈是了解客户的重要渠道。B 端产品和 C 端产品在反馈的处理流程上没有表现出明显的差异性，大致环节是「收集 – 整理分类 – 优先级筛选 – 转化 – 计划上线和发布」。

但从业务特性来看，C 端产品注重打造产品「爽点」，让用户获得极致的用户体验。因此，C 端产品的用户反馈整体呈现更多的个性化和天马行空，也更符合个人用户的使用习惯；

而 B 端产品的最大目标通常是赋能客户更加成功，因此用户反馈更加关注产品对目标企业/客户的整体价值。它们围绕业务目标展开，目的性和业务属性会更强。

Beansmile – Leon：我也赞同思哥的说法。整体看来，B 端产品的规则更明确，处理反馈时闪转腾挪的空间相对较小；而 C 端产品通常极富创新性，其业务发展和法规监管有更强的探索性。

我们之前服务过一个金融行业客户，同期需要交付 To B 和 To C 两个产品。B 端产品面向各大金融机构，受到证券、基金投资等行业法律法规的约束，几乎不太能在规则上探索，研发过程最大要求就是保证功能稳定、数据安全、逻辑正确；

而面向个人理财的 C 端产品有许多内容可以一边做，一边调整、逐步完善。相比成熟的 B 端产品，更具创新的 C 端产品可以逐步参考行业头部企业的做法，总结分析后再制定，这是一个比较明显的差异。

优普丰 – 申导：我也想从决策角度补充一点。C 端产品的购买决策是短决策链的个体决策，通过打击用户「痛点」和「爽点」，激发用户为产品和体验付费的冲动与欲望。

而 B 端产品的决策复杂度则更高：决策路径通常很长，而且不同环节的决策负责人通常不一样，他们的决策影响力也不尽相同。因此只有找到决策链上的「关键强节点」，识别他们的真正需求，才能让事情更顺利。

主持人：谈到决策复杂度，就少不了要提「决策权」。在敏捷团队中，面对海量的用户反馈，谁具有对用户反馈拍板定案的决策权？

LigaAI – 张思：在 LigaAI，用户反馈的处理通常由产品负责人 (PO) 或者产品经理 (PM) 主导。他们会与客户成功 (CSM) 伙伴一起，共同评估和分析用户反馈的具体内容、价值排序，以及同当前目标的整体匹配度，综合多个因素完成判断和处理。

Beansmile – Leon：对于纯交付类的客户项目，我们最重要的任务就是找准有决策权和最终影响力的产品负责人 (PO) 。他们通常是企业老板或者高级负责人，能对产品的投入产出比负责，具有接纳或拒绝需求的能力和魄力。

如果是技术入股的项目，我们更注重于维护技术自主权。在挑选合作伙伴时，我们更倾向于选择理解技术、愿意为技术放权、不干涉技术或研发过程的伙伴，以此避免过程中不合理的时间线或者产品路径加重研发负担。

优普丰 – 申导：在敏捷开发里，产品负责人之所以称为 Product Owner，是因为他们天然要承担决策拍板权 (Ownership)。

好几年前，我与朋友一起参加一个 O2O 创业项目。第一次开会面议时，我发现朋友和甲方领导都不太懂技术，于是我花了一些时间跟甲方领导介绍互联网的玩法和 O2O 产品。领导听了觉得很不错，我便乘胜追击地说：“要不这个产品您就听我的？”结果对方答应了。这样，我将原本属于甲方的决策责任，经过授权，揽到了乙方身上，让研发过程顺利很多。

理论上，B 端产品的反馈决策权一般只在（最）高级负责人身上。许多与我们直接联系的产品负责人或者项目经理，他们不一定拥有最终拍板权，而找不到项目中真正的「话事人」也会导致项目最终推倒重来。

二、提出反馈的人，往往不自己想要什么

主持人：刚刚三位都提到用户反馈过程中产品负责人 (PO) 的重要性。在应对海量的用户反馈时，PO 该如何透过反馈，洞察真正的用户需求？

LigaAI – 张思：用户的反馈总是很主观。想要找到用户的真实需求，便要求产品负责人对客户群体、行业模式、具体的消费场景和使用场景有较深的理解，才能对充满随机性的用户反馈做出相对准确的判断。

用户反馈总会指向一个「问题」，传递的信息是「用户需要什么」和「希望产品如何解决问题」。产品负责人需要根据已知的信息，提供一个良好的解决方案。在理解和分析反馈时，一定要深挖问题背后的原因，区分「Want」和「Need」的区别，找到用户完成目标的路径中真正「Need」的部分，才能洞悉有效的用户需求。

具体的做法是，基于对客户和业务的整体理解，多问自己「为什么」。产品负责人经过反问和反推，逐步整理出用户反馈背后更深层的原因；当出现明确的可验证想法，再进一步与用户对话，探索更多方案的可行性。

Beansmile – Leon：一个很有意思的现象是，很多提出反馈的用户往往不清楚自己想要什么，而初级的产品经理则很容易被这些信息误导。就像几乎所有主流的视频会议软件都默认带有视频美颜功能。尽管没有用户会明确指出自己需要美颜，但他们都不会拒绝美颜带来的更好的视觉效果。

而同样的功能发生在另一个场景，则完全不一样。一个受伤的用户想将伤口拍下，上传供互联网医生诊断，而手机自带的不可关闭的相机磨皮功能，却将疤痕完全磨平了。这个场景中，用户就无法达成自己的目的。

不难看出，想要透过用户反馈，了解背后真正的需求，关键在于理解业务、理解场景、理解人性。需求分析人员需要具备相当的同理心和换位思考能力，才能以更真实的用户视角考虑使用场景，设计出优秀的产品和功能。

优普丰 – 申导：用户洞察是相对复杂的事情。有的用户嘴上说的是 A，脑子里想的是 B，潜意识里想要 C。中国有句老话，听话听音。我自己也一直在研究，如何更好地洞悉人的诉求和意图。总结下来主要有三点。

第一，学会观察和倾听，只有静下来才能听进去别人在说什么。产品负责人不能沉浸在自己的想法世界里，而是应该在拿出可验证的产品测试之前，安静且专注地做好用户调研，观察用户行为，了解真实状态下的用户表现。

第二，正如 Leon 提到的，关注人性。人性就是最基本的需要，七宗罪、贪嗔痴、酒色财气这些都是人性。有的用户反馈和需求为业务服务，也有的仅为了面子工程存在。产品负责人需要在历练中积攒和沉淀，你必须见识过很多的场景，才能洞察反馈背后反映出来的「真需求」。

第三，借用乔布斯的一句名言：不要听用户的，因为他们不知道自己想要什么。

主持人：敏捷团队如何通过分工协作，将源源不断的用户反馈转换为迭代中的用户故事？

优普丰 – 申导：「用户故事」顾名思义是从用户角度讲故事：通过对场景、人物和事件的描述，试图找出用户诉求背后真正的、感性的、情绪性的需求意图。使用简单的「Who – What – Why」三段式结构，讲清楚待完成的特性或功能、背后的价值，以及为什么要实现这个功能。

国内有一些团队会僵化地使用用户故事，认为过去写 PRD 文档，现在就写用户故事文档。这是错误的。用户故事的作用是让大家交流和思考需求所提的场景里面有谁，要做什么以及意图是什么。所以，技术团队不要着急跳进解决方案里，要先研究清楚需求意图，这个特别重要。

用户故事通过更频密的对话达成团队内部的一致，消除不同角色的理解差异。从用户反馈到用户故事，一般会使用三个思考框架。

首先是业务问题域的影响力地图 (Impact Mapping)，它可以帮助团队挖掘原始的需求。具体的做法是，从业务目标开始找到目标用户，找准用户痛点和产品价值点，最后为此提供解决方案。

第二，利用解决方案域的用户故事地图 (User Story Mapping)，将交谈中产生的用户故事拆分、归类、简单排期，帮助团队找到真实需求全貌，并查漏补缺。

第三是技术实现域的产品待办列表 (Product Backlog) 和迭代待办列表 (Sprint Backlog) 。落到具体的实现层面，就必须有先后顺序，所以我们需要待办列表将排队过程落地，将地图式的二维信息，转变为列表式的一维信息。

Beansmile – Leon：与合作方一起挖掘用户故事时，我们喜欢使用「电影制作」做场景类比。软件定制研发就像是双方合作制作一部电影，讨论阶段就是在研讨剧本：故事需要涉及哪些角色、他们分别有哪些故事、需要做什么、每个角色在具体场景中的使命是什么……

通过将用户故事总结、罗列出来后，我们就能将很多细节信息研究清楚，比如不同角色的管理权限、不同故事场景的具体操作和限制条件等等。在聊天中，一步步引导合作方「聊」出更多的细节，识别更多的关键路径，后续的研发工作才会顺利。

还有一点比较重要，也是敏捷开发里强调的「Deploy Early, Deploy Often」——早点部署，频繁交付。我们发现相比 Staging 环境，部署到 Prod 环境的交付成果，客户关注得更多。因此，可以早一点将功能放到 Prod 环境里跑，尽早地让客户看到、体验到实际的产品。

LigaAI – 张思：我们在处理小型需求和反馈时，经常使用待办列表工具进行排期和排序。除了申导提到的三种框架外，LigaAI 团队还会使用 JTBD 理论 (Job To Be Done) 分析用户故事。

JTBD 理论指出，用户使用一款产品，本质上是为了达成一个工作目标。因此，在 LigaAI 团队中，我们会逐级拆解用户要实现的「大目标」，及若干个指向最终目标的小工作 (Job) 。这个我们有个标准的协作流程：

并且在这个流程中，我们和很多 LigaAI 的客户都用上了 LigaAI 的智能助理、跨项目流转等自动化工具。比方说：从提交反馈 – 分析设计 – 迭代排期 – 开发上线 – 用户通知，全流程通过机器人自动推送、实现无缝衔接；避免了沟通中的信息差和时间差，让整个团队能够基于对用户反馈的共识，快速推进迭代开发。

另外，我也非常赞同 Leon 提到的应该「尽早部署，频繁交付」。LigaAI 团队在研发过程会使用 MVP (Minimum Viable Product) ，尝试先将一些 MVP 功能实现交付，让客户提前体验；再根据客户的反馈意见，做进一步的完善和优化，逐步交付更大的价值。

三、只有变化，是唯一不变的

主持人：今天的三位嘉宾都（曾）是技术团队的负责人。那么在管理角度，敏捷团队应该如何打造积极拥抱变化、快速响应变化的团队文化？

LigaAI – 张思：对任何团队而言，人都是最重要的。想让研发团队适应敏捷，就一定需要打造信息流通、自主交流的团队氛围。让团队内部自然地形成协作的默契，一起拥抱变化，这是团队建设的大前提。常规的团建活动、内部分享或者非正式会谈，都是比较好的低负担的文化建设手段。

第二，敏捷团队的管理者需要为团队提供更多赋能的后勤保障和支援。在适当的时候，提供敏捷方法论的指导，保障物理层面的需求。

Beansmile – Leon：打造拥抱变化和快速响应变化的团队文化，可以从思维方式和技术操作两个层面入手。

首先，大家一定要意识到，变化是永远不变的。尤其是交付型团队，几乎没有任何一个客户的需求是一成不变的。所以，敏捷团队要从观念上接受变化，才能真的拥抱变化。

其次，产品负责人要做好预期管理，包括调节需求、把控进度等想法。不要试图向客户传递要创造鸿光伟业的想法，尽量将产品预期压低，务实一些，将研发过程持续维护在可控的范围内。

比如，通过每日站会将风险粒度最小化、使用量化手段监控成员的工时或者点数、将子任务拆细更清晰地完成过程管理。只有当可量化的研发工作经受得起每日的定期同步，过程管理才不容易出错。

风险始终存在，我们不能消灭风险，但是可以控制风险的粒度。在技术操作层面，建立严格的 Code Review 标准，应用 CI/CD 等自动化部署工具，介入人工测试等等，也可以在一定程度保障团队拥抱变化的能力和信心。

优普丰 – 申导：在软件开发领域，敏捷开发为变化而生。在充满创造性和探索性的工作中，我们要不断地验证，不断地拿产品说话。拥抱变化也不是一蹴而就的事情，也要在不断地磨合和迭代优化中，逐步验证更好的方式。

第二，技术管理者要充分发挥「培养人」的职责，把团队发展起来。培养成员的心智、认知领导力和拥抱变化的勇气，不断地磨炼、打造一个更加敏捷的团队。

中层管理干部打造自组织团队的关键在于不断地磨炼成员，手把手带领成员成长；而中层管理者的成长则要亲自接受市场和客户的打击与挑战，亲临实地地了解市场和客户需求。管理者必须自己经历风暴，才能快速成长。

随着组织走向成熟，团队规模不断扩大，外部与内部变化也将生生不息，没有休止。敏捷团队只有拥抱变化、快速响应变化，才能在变化中找到组织稳步发展的生存之路，否则就会被市场和竞争淘汰。

而在一次次拥抱变化与响应变化的敏捷实践中，如同优普丰和 LigaAI 般的敏捷践行者也将持续以更优秀的产品与服务，助力每一位踏上敏捷转型之路的朋友，成就敏捷。

>> LigaAI 往期精彩阅读 <<

一文讲清「敏捷路线图」，不再掉入瀑布陷阱

多个服务器如何跨命名空间，访问公共服务？

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

原则上，践行敏捷开发很简单：构建一个增量；测试这个增量；了解需要改变的信息；将信息反馈到第一步中，并重复步骤。

整个过程可以从两个方面，将敏捷开发与瀑布开发彻底区分开：第一，尽早且频繁地交付小批量的可工作的产品；第二，根据（一）得到的新变化和信息，对产品进行恰当的调整。

如下图所示的敏捷路线图很常见。时长一年的甘特图上堆满了功能，并提前完成了任务分配。研发团队只能在一个个不间断的迭代中，实现所有的功能；他们还没有机会总结已交付的工作并作出调整，就必须立刻进入下一个功能开发。

如果前两个产品功能交付后被证明是错误的（这非常有可能发生），难道我们还要按原计划迭代下去吗？继续遵循上面的甘特图，可能会一错到底。因为计划好的路线图无法帮助我们评估交付效果，识别问题并及时调整。

敏捷开发刻意只关注下一次迭代的即时计划，但许多团队构建了一年甚至更长时间的甘特图，并且罗列了无数个待开发功能和完成截止日期。这样怎么会敏捷呢？

01 前瞻性计划：敏捷刻意忽略的部分

除了当前迭代正在构建的产品外，敏捷方法论不太关注前瞻性的计划。因为只有这样才能做到「实时计划」——我们应该看到什么是可行/不可行的，并根据反馈的数据决定下一步该怎么做。

敏捷意味着「能够快速轻松地行动」，而敏捷开发需要被持续引导，逐步提供价值，再根据市场反馈的情况快速调整策略和方向。这是一个建立在洞察与反应几乎同步的快速反馈周期，而不是基于前期的大计划。

但是，组织（尤其是大型或传统组织）通常不喜欢没有计划地工作。没有计划的组织会陷入「计划缺失焦虑症」；更准确地说，组织的领导者会很焦虑。因此，他们会制定一个功能列表，提前做好分配，以确保每个人都能按预定的方式有序地工作。

敏捷的组织应当正面解决计划缺失的焦虑，但许多团队没有这样做。反而是领导者们认为，过去路线图和甘特图很有用，那就应该继续使用它们。慢慢地，敏捷就变形成「Water-Scrum-Fall」，就像下图这样。

不幸的是，敏捷的核心——灵活自由地根据新信息进行调整——被完全忽略了。许多团队实践的敏捷并不是真的敏捷，而过去的瀑布式任务列表也演变成了「用户故事」列表。

02 SAFe：敏捷适配器

敏捷框架没有提供任何当前迭代以外的具体规划建议，而扩展框架正填补了这一空白。SAFe 有一个优点：作为从前期瀑布式大计划到团队敏捷执行的适配器，它可以很容易地被理解。

使用 SAFe（或其他扩展框架），产品管理团队提出功能，设计团队绘制 UI 模型，再发送给管理层审批。当工程师开始编写代码时，管理层会很放心。因为他们已经做好了充分的计划，而成百上千名程序员都会尽职尽责地工作。通过敏捷扩展框架，管理人员可以看到所有计划中的功能，而开发人员可以在迭代中专注地写代码。

这也是敏捷扩展框架受欢迎的原因：它们将领导者熟悉的大型计划，转换为研发团队可执行的敏捷迭代。在一些高级管理者看来，这就是最重要的。事实上，工程团队已沦为「功能工厂」，他们几乎失去了所有学习、快速调整和改变的能力。管理者却真诚地相信，团队已经完成「敏捷转型」。

03 敏捷性需要空间来操作

回到前面提到的两个决定性敏捷特征：尽早且频繁地交付小批量的可工作的产品；根据（一）得到的新变化和信息，对产品进行恰当的调整。

第一点比较好理解，几乎所有资料也都集中在这上面；能够正确掌握第二点的人要少很多。如果团队没有从早期部署的迭代中学习，也没有将洞察力融入后续的迭代优化，那么就没有正确地践行敏捷——这其实只是「增量瀑布」。

正确的敏捷要求组织多次发布和重新发布相同的功能，并且每次都要从早期的经验中吸取教训，使该功能更易于使用、更强大、性能更好或在某些方面更好。这需要时间，而且这些时间无法在前期被充分估计和预先承诺。因此，要想成功地洞悉变化，完成迭代优化，团队需要在计划中做到以下三点。

1. 计划实现的路径必须是可塑的。定义一个愿景或最终目标，但允许具体的功能和内容在执行时可以有所变化。我们无法准确预测一个功能会如何运转，所以需要测试它。敏捷团队要允许每个功能能被反复加工、打磨或扩展几次，直到真正实现它。
2. 计划需要为调整和优化留出弹性空间。如果时间已经全部按计划分配完，就需要删掉一些东西。正确的策略是在一开始就不要填满所有时间，让它保持开放状态；可以为新想法整理一个新队列，直到时间允许，再进入迭代分配。后文的 「Now-Next-Later」也会详细讲解这一方法。
3. 领导的支持。这通常是三点中最难实现的。

04 领导力是敏捷性的关键

最具影响力的成功因素是组织展示和激励的领导范式。—— Agile 2

很多领导层都认为敏捷是团队内部的事情。这种假设肯定是错误的，而领导们也需要以敏捷的方式行事。在项目过程中，如果要为团队提供调整的空间，领导者就要接受临时的计划。「可塑性强的路径」和「允许调整的弹性空间」印证了这点。

管理者要有足够的勇气和决心，才能对团队说：“我们不打算在这个迭代将你们的工作填满；你们需要跟着数据走，看看自己的工作成果。” 如果领导者要真正拥抱敏捷，他们就需要做出根本性的改变。这遵循精益创业的精神：建立一个项目、测试它、从数据中学习、并将这些经验直接反馈到后续的项目中。

同时，领导者也要有勇气，接受这些事实：团队不会在外部干扰下提前确定工作，也不会一轮接一轮无缝地进行功能开发。团队需要更多实验性、创造性和跨职能的工作。

这同样意味着，领导者需要快速响应、批准通过更多碎片化的需求变更。他们要探索出更灵活地工作方法，以便为团队提供及时审批。这无疑会打破官僚主义的枷锁，而由领导者们组成的小团队则能更快、更独立地监督和批准自己团队的工作。

05 Now-Next-Later 模型

更常用的敏捷路线图工具是「Now-Next-Later」模型。甘特图中层层叠叠的功能集可以归纳总结为三个模块。

• Now：我们正在积极工作的事情。
• Next：「Now」完成后，即将开始的工作。
• Later：其他所有未分配和未承诺的功能。

将新的需求、功能和工作按模块规划好，比挤进拥挤的甘特图要容易得多。我们可以很轻松地在每个模块中留出弹性容量空间，以便后续根据最新信息做出调整。

可以看到，「Now」中的项目定义得比「Next」更加详细，「Later」是定义和描述最少的。每个模块的时间跨度可以自由决定，但最好跨度大一些，尽量覆盖多个迭代和优化周期；建议的时间周期是每个模块 6 周或者一个季度。

正确地使用「Now-Next-Later」，既能让我们适应短期变化，为后续工作和 Bug 修复留出空间，也能适应长期变化，改变我们对哪些功能要从模块中取出的想法。

但它不会消除干系人要求尽快交付功能的压力。这也是为什么领导者需要自己拥抱敏捷，才能让团队成功。领导者需要通过自己的努力，倡导敏捷的工作方式，并以同样的标准要求自己。

06 结论

许多自称敏捷的组织，他们提前计划了大量功能列表——通常提前一整年——并告诉团队要以小批量的方式交付。这不是敏捷，这是增量瀑布。

敏捷开发的核心特征是小批量地交付可工作的产品，从早期迭代中获得洞察力，并在后续迭代中进一步完善和优化相同的功能。其中的关键在于我们无法预知和确定什么是可行的，什么是行不通的；这需要洞察和跟踪数据。打造一款优秀的产品，我们要一边走，一边制定计划。这与一年长的甘特图完全不同。

「Now-Next-Later」只有与团队自主权相结合时才有意义。这样才能使团队发现计划的调整空间，及时做出应对。想要灵活地工作，在做计划时要注意建立高度灵活的路线图、留出充足的弹性空间用于响应调整，以及获得领导层的积极支持。利用好这三点，就可以持续地引导项目，而不是在前期就将它固定下来。这就是敏捷真正的意义所在。

原文作者：Raj Nagappan

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

多个服务器如何跨命名空间，访问公共服务？

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

多测试环境的动态伸缩实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

文章来源 | Medium

我将在这篇文章与诸位分享，如何扭转产品管理过程，并获得真正的成功。而你只需花上 15 分钟，便能获得一名产品负责人用三年血泪史总结出的产品管理经验。

PART 1：夸夸其谈的创始人

刚加入这家初创公司担任产品负责人时，我非常激动和兴奋。在我入职的第一天，其中一位创始人向我介绍了公司愿景和产品，还点出了竞争对手的种种弱点，全程口若悬河，十分精彩。

但几天后，我发现所有声称的「成绩」都只停留在宣传层面，产品本身的进度并不明朗。震惊之余，我也意识到，想让产品获得真正的成功绝非易事。

PART 2：自欺欺人的谎言

入职几周后我再次意识到，原来我们一直处在幻想之中：我们日复一日地向彼此传递同样的谎言，并且毫不质疑这些信息是否真实、是否来自真实出现的事实。

我们经常说的谎言是这样的：

• 这个功能对用户非常重要。
• 我们需要完成此功能，然后用户才会喜欢我们的产品。
• 这是我们产品的主要用户。
• 用户需要这个和那个。

我们总是告诉对方这些「事实」并将它们奉为真理，但实际上，我们并不知道「用户是谁」以及「他们想要什么」。

PART 3：产品负责人的唯一职责

目前来看，在我之前没有人在做产品管理，也没有真正的产品负责人——虽然确实有人担任了该职位，工作内容也都被不同的成员分担。

但是，没有人提出「我们该如何构建正确的产品？」这个问题，而产品负责人的唯一职责就是要构建正确的产品。

PART 4：好的产品负责人总是「一无所知」

一个好的产品负责人总是持空杯心态，且自觉「一无所知」。要知道我们的所有主张和决定都只是假设，而我们要做的就是将其证伪或证实。

我们的所有工作都以假设为基础。当一个假设在上述金字塔中的位置越低，想要纠正不正确假设引起的错误就越困难。

因此，为了确保我们在构建正确的产品，我们必须通过测试来确认或否定这些假设。

PART 5：倒金字塔型假设试验

几周后，我成功说服团队理解并接受：我们对用户和真正的需求一无所知，我们的产品是基于假设构建的，而我们必须通过试验来验证这些假设。

产品的假设试验最好按照精益产品管理金字塔的相反顺序来完成。

我们首先验证了当前的目标用户群体是否是正确的目标群体；

其次，验证我们是否用计划的和已交付的功能解决了正确的用户需求；

最后，我们测试了客户的支付意愿。

Alexander Osterwalder 等人的测试漏斗更侧重精益产品金字塔的市场方面。为进一步测试价值性、功能集和用户体验，我们必须扩展测试漏斗。

PART 6：提出假设，制定测试验证方案

使用测试卡片制定和记录假设，并定义验证方案，对我们的帮助很大。测试卡片为我们创造了一个定义假设确认状态的待办列表；在这些测试验证的过程中，我们也得到了大量的学习成果。

PART 7：了解真正的问题空间，而非解决方案

进行假设验证时，产品负责人应该向用户询问有关需求和问题空间（Problem Space），而不是解决方案（Solution Space）。

福特汽车公司的创始人亨利·福特曾说：「如果我问人们，他们想要什么？他们会说更快的马匹」。

因此，永远不要向用户询问可能的解决方案，而应该尝试了解他们的问题，并为此找到更好的解决方案——这是我们学到的重要教训。

谈到用户需求，就少不了要聊卡诺模型。卡诺模型将用户需求分为三类：必备型需求即基本需求-Basic Features、期望型需求-Performance Features 和兴奋型需求-Excitement Features。

试验假设时，我们必须瞄准一个目标，而这一目标应该在产品战略中加以定义，使我们有别于竞争对手。然而，通常情况下最大的竞争对手不是公司，而是满足用户不同需求的替代方案。

开始试验大量测试卡片前，我们先为产品定义了一个明确的定位策略。受到 Dan Olsen 的启发，我们设计了一张用于定位策略的表格。

如果是亨利·福特，那他的表格应该长这样：

PART 8：产品负责人应如何进行假设试验？

01 评估优先级和工作量

不同假设的试验难易程度不同，所需要付出的努力也不一样。因此，第一步就是要确定试验任务的优先级次序，并评估试验工作量，这非常重要。

02 对试验类别进行区分

除了区分定性试验和定量试验，我们还会区分市场验证和产品验证。

我们尝试了不同类型的用户测试，最开始做的大多数都是定量的。通过采访和观察部分用户，我们了解了很多关于用户、客户以及问题和需求的信息。

在那之后，用户测试的重点更多地转移到了价值主张和实际解决方案上，包括用户体验等等。

03 产品策略细化到目标

确认了真正的目标用户群体，确定我们确实在解决正确的用户问题后，我们便进一步细化产品策略。这也是从问题空间切换到解决方案的时间。

我们先制定了一个发布计划（Release Plan），详细地说明了我们希望在第一个 MVP 中包含的内容。而先前得到的关于用户需求和实际问题的信息，则很好地帮助我们创建了一个优先级最高的用户目标列表。

有了这些用户目标，就可以通过用户故事地图（User Story Map）将用户旅程从头到尾地进行可视化和建模。

04 用户故事地图搭建解决方案

在用户故事地图中，你可以为特定用户的主要目标旅程进行建模。也就是说，用户故事地图是针对特定用户群体量身定制的。

一个用户故事地图的主要目标就可以被分解为多个连续的子目标；

每个子目标又可以被划分为若干个用户完成子目标所必须进行的活动流程；

每项活动又能创建一个或多个详细的活动卡片。

举个例子，「购买某种产品」的用户故事地图应该这样呈现：

• 白色卡片 | 主要目标/用户故事地图主题：购买产品
• 蓝色便笺 | 子目标：查找产品、比较产品、将产品添加到购物车等
• 绿色便笺 | 查找产品的活动流程：浏览类别、搜索产品等
• 黄色便笺 | 具体的详细活动：导航到商店、选择类别、搜索产品关键字、滚动浏览产品搜索结果等；也可以是活动的替代任务、例外或详细信息。

不难发现，通过逐步拆解和细分，用户故事地图进一步将问题空间（蓝色和绿色便笺）与解决方案（黄色便笺所示的史诗和功能集）联系起来。

05 发布规划和 MVP

通过对产品发布进行分割和切片，用户故事地图还能定义每个发布版本应该为目标用户提供哪些价值主张。这进一步加强了我们的产品战略。

对用户需求进行切片时，正确地切分价值主张非常重要。Dan Olsen 创建了一个很好的切割 MVP 的可视化图像：像左图般纵向地切割你的 MVP，而不是右图的横向切片。

MVP 必须具有真实产品的所有功能，具备功能性、可靠性、可用性、直观性和令人愉悦等特点。

06 用情感曲线测试 MVP/发布

要验证 MVP/版本是否具有良好的用户体验，我们可以将情感曲线图和用户故事地图结合起来。

让一些用户来尝试你的解决方案，先观察他们在使用某个功能时的整体感受；

体验结束后，采访他们并询问对过程中某个特定步骤的想法；

然后，通过对试验结果取平均值，可以很清晰地了解产品的可改进空间；

也可以通过比较情感曲线图，比较不同版本的产品，并找出改进的地方。

# SUMMARY：总结一下

不要相信自己的谎言。做一个真正的产品负责人，问问自己「我们该如何构建正确的产品」。

不要相信任何人，用试验和数据说话。首先要验证产品是否在正确的市场中、谁是最大的竞争对手，以及用户的真正需求和问题是什么。

对提出的假设进行优先级排序，并选择适当的测试来验证它们。

只有去除最大的不确定性，确认假设后，才能借助用户故事地图和情感曲线，对产品策略进行细化和可视化。

>> LigaAI 往期精彩阅读 <<

研发效能应该如何管理与度量？

如何让敏捷小组在迭代回顾会上「知无不言」？

如何搭建可伸缩的研发流程管理方案？

影响研发效能的7个常见场景解读

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

撰文编辑 | LigaAI

敏捷团队在迭代评审会（Sprint Review）中展示和评估产品增量，并调整待办列表；随后，在迭代回顾会（Sprint Retrospective）上，聚焦开发与发布全过程，讨论有关工作和协作的优化方案，以改善开发过程、提高开发质量。

释放有效沟通，鼓励畅所欲言。迭代回顾会通过分析流程和协作中存在或潜在的缺陷，帮助团队识别和解决冲突，是实现迭代提升和增补动力的最佳实践，也是不可或缺的重要敏捷环节。

但在真正的落地与实践中，许多团队总会因为成员参与度低、内容空泛不聚焦、气氛压抑流于形式等挑战，最终放弃会议。如何让含蓄内敛的成员发声，言之有物地参与到迭代优化的建设中，困扰着每个回顾会失意的敏捷团队。

其中，构建安全场域，赋予全员安全感是激发自主表达的第一步，也是最容易被忽视的关键技巧。

一、什么是安全场域？

场域（Field）一词起源于物理学，后成为社会学的重要概念之一。布迪厄将场域定义为「位置间客观关系的一个网络或一个形构」。 它不是由一定边界物包围的领地，也不等同于一般领域，而是有内含力量的、有生气的、有潜力的、相对独立的社会空间，通常分为物理场域和心理场域两种。

场域理论指出，人的每一个行动均会被行动所发生的地理和行为环境所影响，而勒温的场动力理论则说明，一个人的行为与个人主体、内在动力、空间环境及氛围等多重因素有关。

基于场动力理论，打造迭代回顾会的安全场域可以从三个维度解释：

• 建立与会者间的相互连结，给彼此安全感；
• 创造与会者和空间环境的连结与舒适感；
• 打造与会者与会议带领者的连结和信任感。

关注迭代回顾会的场域价值，为敏捷团队创造和维护一个高效的、有安全感的空间环境和氛围，能促成与会者间的良性互动，更聚焦地达成会议目标；

同时，安全场域所激励的情绪或能量上升，还能让会议流动起来，在保证会议目标顺利完成，提供迭代优化价值等方面都有重要意义。

二、如何打造回顾会的安全场域？

引导和打造场域应关注五大要素，他们既是场域的组成部分，也是场域的显化。

• 信息：大量的事实、想法、意见、观点、决策、行动方案等信息会在会议过程中浮现出来并不断变化，相互作用，彼此影响。
• 能量/情绪：与会人的能量状况包括活力、情绪、精神状态等等，会直接影响场域，并最终作用于目标和结果的产出。
• 空间：在心理场和物理场两个层面，为敏捷团队营造一个开放、安全的空间，是会议有效产出的必要前提。
• 关注/关系：包括会议引导者对与会者个人和会议产出的关注，以及与会者对议题、流程和结果的关注，通常是动态变化的。
• 流程/时间：流程的变化会直接带动场域的变化，并影响到其他四个要素。

引导场域的五大要素相互关联与作用，最终影响整个场域和会议结果。更具体地，创造和维护迭代回顾会的安全场域，可以从以下四个方面着手。

01 培养场域意识

心理场域层面，会议组织者/主持人在会议过程中应结合上述五大要素，关注场域的动态变化，观察成员的状态和心理活动，并在必要时候提供支援，引导会议向和谐、轻松、开放的方向进行。

在物理场域角度，敏捷团队应重视会议环境、流程以及外在行为线索环境的搭建，尽可能帮助与会者投入到迭代回顾的主题当中，获得沉浸式体验。

• 会议室的物理环境和设置
• 视觉海报冲击，如主题欢迎海报、总结海报等
• 日程安排的衔接
• 入场调查的细节
• 参与原则的说明
• 问题停车场的安排
• 流程中的工具规则
• 与会人的着装和动作

02 关注所有人

经验表明，人们更倾向于在熟悉的环境和团体中坦诚交流。也因此，营造安全场域的第一步就是「消除」陌生人。

花点时间介绍在场的所有人，让与会者彼此熟悉，包括那些在线上或角落里旁听，不参与讨论的伙伴。别让会议空间里存在陌生人，是维护安全场域中不可忽视的技巧。

03 尊重不同声音

有效的迭代回顾会欢迎多元的建议和意见；有安全感的场域也意味着所有成员可以自由表达，且所有声音都会被尊重和认真聆听，而不是被无理由驳回、批评或攻击。

有领导者在场的迭代回顾会议，或许需要一个能够鼓励成员勇敢发言的引导者，或者也可以考虑采用更能激发群体表达的创意会议形式。

场域的安全感来自于团队内自由的表达：允许并尊重各种声音，安全感就会升起；而当会议充斥着热烈的表达，场域安全感又会被进一步增强，进而形成良性的动态激励。

04 共创参与规则

参与原则是指为了实现既定目的和产出，由团队成员共同承诺并愿意遵守的行为准则。同DoD与DoR类似，迭代回顾会的参与原则规范了会议开展和进行的标准，通过建立统一的共识和规则，确保会议可以融洽地、相互支持地完成。

敏捷团队可以邀请所有成员一起制定规则，让每个人在参与讨论时获得安全感；在定期的会议经验加持下，持续优化和补充规则集，避免参与原则成为形式主义产物。

而在共创参与原则时，聚焦成员互动和具体行为，提出针对性的、非抽象的说明，更能发挥参与原则的最大价值。

当回顾会上出现震荡/冲突，或团队触及敏感话题时，主持人做出积极引导，让讨论回归到参与原则上，也能为安全场域的维护做出贡献。

# Liga 总结

一个好的场域能够激发参与者的表达欲，建立成员间的和谐关系。

而基于安全场域开展的迭代回顾会可以赋予所有成员坦诚表达的勇气，成就更紧密、更顺畅的协作，并成为敏捷团队前进的核心动力。

>> LigaAI 往期精彩阅读 <<

如何搭建可伸缩的研发流程管理方案？

影响研发效能的7个常见场景解读

分享一个优先级系数计算公式

迭代评审会的七宗罪，你知道吗？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

不幸的是，于我们而言——作为产品经理的我们——我们或许有远见和决心，但却很可能缺乏无穷无尽的可消耗的劳动力（和时间）。这就是为什么我们要对团队的工作进行优先级排序。我们必须确定哪些成果唾手可得：相较预期的成果而言，这些工作可以轻而易举、不费吹灰之力地完成。

几年前，我编译了这个优先级排序框架的早期版本，并将它投入Voice123，Bunny Studio和Torre等多家公司的团队进行测试。经过多年的调整、改进和验证，我想公开分享它——Prioridad。

一、需求、事务和缺陷 如何确定三者的优先次序？

产品经理和研发团队通常会处理三种类型的工作：需求、事务和缺陷。

缺陷（Bug）是与规格相比，会导致意外行为的产品漏洞，通常由开发团队产生；而事务是产品设计中导致用户体验不佳的缺陷，通常由产品经理或产品设计师产生。

首先，我们需要一个用于确定需求、事务和缺陷三者优先次序的方法——这很大程度上取决于业务性质、产品所处的阶段（跑通PMF前/后）和团队规模。两种常见的方法分别是基于产品卓越性，或基于时间分配确定优先级。

01 基于产品卓越性排序

这种排序基于一个前提：拥有一个（近乎）完美无缺的产品，至关重要。对于「产品即业务」的公司而言，这很常见，比如SaaS产品和视频游戏。基于产品卓越性的工作优先级也很容易确定：

• 总是先修复缺陷
• 然后处理事务
• 最后再开发新需求

它对产品经理和研发成员都适用；但是，对尚未跑通PMF的产品不太适用：默认情况下，此时产研团队应该专注于实现达到市场需要的新需求，而事务和缺陷往往只在需求完成后才解决。

02 基于时间分配排序

这种排序方法的前提是，即使产品存在一些缺陷，持续推出新的产品功能依旧是必不可少的。它适用于「产品是业务推动者，而非业务本身」的公司，例如Steam V.S. 羊了个羊——前者属于服务型产品，后者属于流量型产品。

对于这种情况，可以尝试在三种工作之间平均分配精力，将产品团队和研发团队的可用时间划分为三周的循环：

在某些情况下，比如实现复杂功能或偿还大量技术债务时，这样的循环是行不通的。需要注意，尽管开发团队可以在解决事务和实现新需求时修补技术债，但仍需要时常为它分配特定的解决时间。

无论你采用哪种方式，每组任务、需求、事务和缺陷都有自己的优先级排序逻辑。

二、如何确定需求/事务的优先次序？

确定多个需求/事务的优先级，可以结合优先级系数辅助完成。优先级系数的计算公式如下：

核心KPI（Core KPI ）反映的是产品的核心交互。于Bunny Studio而言，核心KPI是完成的项目数量；对Voice123来说，核心KPI则是提交的项目和提交的信息。

核心效果指标（Effect in core KPI）指新需求/功能或事务发布后，核心KPI的预期增量，可以用一段时间内核心KPI的绝对数量、与之相关的收入增长或各自的百分比来估计。下面是一些参考指标：

• 50, 000 次授权/年
• 300 万项目收入/月
• 提升 20% 的功能使用率
• 线上收入占比提升 20%

此外，核心效果指标也可以是一个结合多个因素计算得出的指标。因子是否相乘或相加取决于它们是否相互复合。

如果需要相加，那么所有因子在相加前，都需要遵循统一的数据基准进行标准化，比如使用 1 到 10 的评分体系。 举个例子，Torre的大多数团队会为每个新需求，分析下面这些复合因素：

• 与用户用途的相关性：使用 0-10 的衡量等级，0 代表「没有解决用户需求」，10 代表「总能解决用户需求」。
• 用户粘性：每周潜在的互动数量。
• 新功能的总可寻市场：以可能使用新功能的人数为计量单位。
• Wow因子：用 1-10 的评分衡量，1 分代表「不怎么样」，10 分代表「和我第一次看到iPhone一样令人印象深刻」。
• 转化率提升：指增加的访客成为注册用户的可能性，测量范围可以从 0 到 100% 或更多。
• 价值感知速度：以 1/d 为单位，其中d是新用户在注册后感知价值所需的天数。
• 病毒式传播：一个普通用户在使用Torre的前 30 天内会给Torre带来多少新用户。
• 病毒传播速度：以 1/d 为单位，其中d是新用户发送第一个邀请给其他人可能需要的天数。
• 公关潜力：以 1-10 的评分衡量，1 分代表「没啥可吹的」，10 表示「媲美首次登月」。

这些因素适用于Torre大多数团队，但并不适用于所有团队。例如，SEO团队就使用每月搜索量、竞争力、用户生成内容（UGC）等其他因素指标。

成功几率（Chance of success）是一个 0%-100% 的估计值，用于捕捉交付的努力能够达成核心效果指标的可能性。这最开始会是一个大胆的预估，但通过后续的原型设计和分割A/B测试，可以降低其不确定性。

实现复杂度（Implementation complexity）用于衡量实现新功能或事务所需的工作量。理想情况下，这个估计值会受到产品经理、产品设计师和技术主管意见的影响。这个值可以是工时，也可以是斐波那契数列。

例如，预计能将核心KPI提高 30%、成功几率仅为 10%、需要耗费 15 个工时的工作，其优先级系数将如下所示：

无论为每个变量选择怎样的计量单位和度量标准，确定优先级顺序时，对所有新需求/事务应用相同的单位和参考标准是最重要的。

三、如何确定缺陷的优先次序？

确定缺陷修复的优先级时，一个最重要的判断因素是该缺陷是否阻碍了用户。在本篇指南的语境中，用户无法继续完成预期的使用，就是被阻挡了。

• 最高级：妨碍大多数用户使用产品的缺陷
• 高级：妨碍少数用户使用的缺陷
• 中级：大多数用户遇到但不妨碍使用的缺陷
• 初级：少数用户遇到但不妨碍使用的缺陷

四、关于优先级排序的实用技巧

1. 始终使用相同的公式进行优先级排序。用相同的计算公式比较多项工作，优先级排序才能奏效。

2. 在每项工作的标题上添加优先级值。这将能让你更轻松地根据优先级系数，完成项目/产品管理面板的排序。

3. 每项工作都要记录下计算方式、计算者以及结果日期。这会帮助其他成员更好地理解你的预估值来源，并对估算结果提出质疑；还将帮你确定估算是否过时，以及是否需要更新。

4. 培养直觉。进行数百次数学运算后，你将会发展出无需手动计算，就能确定工作优先级的能力，并且结果仍然具有很高的准确性。

# Liga总结

Prioridad是一个经过多次实践和验证的框架，通过引入「优先级系数」概念，量化并确定新功能、产品设计缺陷（事务）和产品使用缺陷（Bug）的优先次序。 优先级系数通过综合新功能的预期效果、成功几率和工作量等指标，帮助敏捷团队更直观地掌握和分析研发工作的重要性。

原文作者：Alexander Torrenegra

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

迭代评审会的七宗罪，你知道吗？

优秀的程序员如何提升个人能力？

每日站会能不能取消？

如何消减协同合作中的认知偏差？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

• 展示结果：开发团队检视当前迭代的最初计划，展示每个需求/故事的工作结果及变化；
• 评审反馈：产品负责人进行确认，收集反馈，并记录进一步的改进设想为新需求/故事；
• 调整方案：产品负责人及关键干系人介绍有关后续迭代的新信息/设想，为接下来的迭代计划会议提供有价值的输入信息。

基于清晰的会议目的和讨论重点，如何更好地完成迭代评审会？高效的迭代评审会又有哪些不为人知的事半功倍小技巧？

本期敏捷实践，LigaAI联合潮海项目教练团队的资深敏捷教练，一一为你解答。

一、 每个迭代结束都要进行评审吗？

作为Scrum五大事件之一，迭代评审会通常在产品增量完成后、正式发布前举行，但在实践经验中，并非每个迭代完成都必须要进行评审。依据时间频率的不同，迭代评审会分为高频评审和低频评审。

• 高频评审适用于产品增量复杂的情况。通过将产品增量拆分成若干个关键需求，并在每个关键需求完成后，邀请重要干系人参与检验，以分散一次性评审的会议压力。
• 低频评审适合产品增量对干系人的感知价值不大（比如长流程的端到端需求）或干系人时间紧张等情况。通过多个增量的合并评审，减少频繁会议对工作的占用和干扰。

此外，以迭代周期/固定周期作为举行迭代评审会的标志并非最优解。迭代周期是团队内部的开发管理单位，在可感知价值增量层面或有不稳定性。

更好的做法是基于里程碑/史诗的完成情况，以增量结果为指标，按需开展迭代评审会。研发里程碑一般分为「内部里程碑」和「外部里程碑」两种。

• 内部里程碑常指项目关键决策点，如需求阶段完成、设计阶段完成，主要用于评估项目内部风险，一般不涉及用户反馈，无需迭代评审；
• 外部里程碑是涉及对外发布的重大功能/模块的完成，需要在产品发布前邀请关键干系人参加迭代评审会，并贡献真实的使用反馈。

二、 干系人一定要参与会议吗？

在《每日站会能不能取消？》一文中，我们曾提到「非必要情况下，Scrum Master可以不参加每日站会」。那么，迭代评审会是否也可以不需要关键干系人的参与呢？

答案是——不可以。

迭代评审会的核心目标是收集用户反馈，所以关键干系人的参与极其重要。但在实际中，不可避免地，干系人可能因各种原因无法参加会议，可以采用以下几种方式解决：

第一，由干系人授权的决策代表代替干系人参加会议。决策代表需要具备对产品增量贡献反馈的能力，并且要能够提出「通过与否」的关键性意见。

第二，如果干系人无法分出大块时间参与评审，那Scrum团队可以采用高频小模块的方式完成反馈，遵循「价值原则」——先展示最急需反馈的功能。

第三，将干系人的会议预约列入待办。避免临期预约的冲突和缺席隐患，产品负责人可以在迭代规划期，就提前锁定关键干系人的会议时间，或将迭代评审会以定期形式常态化（比如安排在每双周的固定时段），确保干系人可成功出席。

贡献反馈的干系人必须参加，而执行反馈的技术人员也同样不能缺席。开发团队应在现场直面用户，聆听最真实的用户声音，才能更好地理解业务、理解需求。

理想情况下，开发团队应全员参与迭代评审会，同干系人一起协作讨论，在认同中建立工作价值感；

如果团队规模较大，也可以轮流派代表或者安排技术骨干参与会议，负责本次产品增量的开发人员必须出席会议，以减少一手反馈的传递偏差。

三、迭代评审会的多种打开方式

01 合而为一

践行Scrum的过程中，敏捷四会（即计划会、每日站会、评审会和回顾会）不必是完全独立的。

例如，对于每周一迭代的短周期敏捷团队，可以考虑将评审会和计划会合为一次会议，以减轻会议负担。会议中，应先评审、后计划：关键干系人在评审结束后先行离场，Scrum团队继续进行新一期迭代的计划会议。

迭代回顾会则不建议与其它会议合并，因为这是敏捷团队复盘和经验总结的宝贵机会；但可以考虑将多个迭代的回顾会合并一次举行。

02 一分为二

对于产品增量价值低、客户感知影响不大、或有高质量要求，需先进行内部评审的迭代而言，可以采用「一分为二」的低频评审形式，将迭代评审会分为「Scrum团队的内部会议」和「与干系人协作的外部会议」两次进行。

• Scrum团队的内部评审侧重于完整的功能展示，重点审查关键功能能否跑通、是否存有Bug尚未修复/发现等；
• 有关键干系人参与的外部评审以收集用户真实反馈为主，重点验证产品增量是否满足客户需求、是否达成真正的产品价值。

03 直面客户是最好的形式

远程办公和异地协作盛行的今天，共享式的文档/表格/问卷协作免去许多会议，但是迭代评审会以获取用户真实反馈为核心，面对面沟通却是不可省去的重要仪式——直面客户、观察用户的使用和体验是获取有效反馈的主要途径。

对于重要且急需用户反馈的功能，Scrum团队应主动安排产品负责人和功能相关的技术骨干前往干系人公司，进行一对一展示和沟通；

面对无法克服的时差或时空问题，也可以采用线上视频会议的形式，但是建议要开启摄像头和麦克风，并使用共享屏幕，让Scrum团队「看到」干系人的使用反馈。

四、迭代评审会的四个黄金搭档

高效的迭代评审会一般包含功能演示、体验试用、讨论反馈和待办优化四个环节。

01 功能展示

述清会议内容与目的后，开发成员结合迭代计划与产品增量，向产品负责人和关键干系人展示已经完成的产品价值。

看似简单的功能展示，也存在一些共性的改进空间——《深入核心的敏捷开发》提出「展示会七宗罪」以描述功能展示过程中的七大问题，并针对性地提出了高效展示会的七个技巧。

七宗罪之一：准备工作没做好，空耗会议时间

正确做法：主讲人在正式展示前，应该做好充分的准备工作——预演演示步骤，准备测试数据，提前部署演示环境等等，避免手忙脚乱和空转浪费，提高会议效率。
七宗罪之二：没有说明铺垫，云里雾里不知所以

正确做法：在开始演示之前，主讲人应当简要地介绍会议目标和所要展示的功能，并说明功能给用户带来的价值。清晰的上下文能让产品负责人和干系人更快地进入状态。
七宗罪之三：逐条过验收标准，缺失业务完整性

正确做法：不要逐个演示用户故事/验收标准。主讲人应以功能为单位，将完整的产品/功能/模块串起来展示；最好定义出单独的业务场景，使用业务语言让业务成员更有代入感。
七宗罪之四：相同/类似的功能，演示所有路径

正确做法：只演示最关键的路径。遇到多个路径实现相同或相似功能时，选择其中一条最复杂/重要的路径详细演示，其他路径指出不同的地方，点到为止，无需覆盖全部路径。
七宗罪之五：过多提及跟演示功能无关的内容

正确做法：专注于最有价值/重要的功能演示，不要让小反馈/未完成的模块耽误会议时间；尽量不提及技术难题或技术方案等业务人员不感兴趣的内容。
七宗罪之六：认为展示仅仅是BA或QA的事情

正确做法：不让某个角色独占功能展示，人人都应该参与进来；可以采用人员轮换的方式进行展示，这样可以提升成员的业务意识，更熟悉整个系统功能。
七宗罪之末：不熟悉的新人负责展示，重点模糊

正确做法：新人展示前应充分了解业务和系统，确保能够应对和解答业务的挑战和疑问；也可以让新人在结对编程、Story Kickoff等多做主导，具备一定的系统和业务意识后再向干系人展示。

02 体验试用

开发成员完成功能演示后，更重要的是要让关键干系人亲自体验和试用系统功能/Demo。用户亲自下场试用和检验，是获取反馈中必不可少的一环。

产品负责人也可以邀请真实的用户参加评审会，让其在开发的指导下体验演示的功能和系统。需要注意，此时开发团队应该为干系人和用户留出足够的自主探索空间，引导他们重现最真实的使用习惯和场景，避免成为「产品推销员」。

03 讨论反馈

产品负责人要收集关键干系人（和用户）的反馈，及时记录最新的改进与设想为新的需求。在体验试用环节，Scrum团队可以通过以下几种方式，观察用户体验，洞悉真实反馈。

• 注重整体的展示，避免成为验收测试

让干系人和用户体验功能并非授权全自主探索——开发成员需要提供必要的场景描述，还原功能使用场景，让用户更有代入感；但，切忌进行步骤指导，过多的干预反而不利于观察真实反馈。

另外，不要逐一演示用户故事。开发成员应尽可能引导用户对整个产品/功能模块进行试用，并关注基于产品整体的功能完整性和衔接流畅性，观察和分析可能存在的优化空间。

• 细心观察用户表现，敏感捕捉使用障碍

在用户体验功能时，Scrum团队应该留心观察他们自然表达和流露的语言、表情、操作和使用习惯等，要具备捕捉异常的敏感度。

比如用户是否在使用期间出现困惑表情、在无反应的地方反复点击等等。通过深入挖掘用户行为背后的原因，了解最真实的行为反馈。

• 使用开放性问题，引导用户自主表达

与干系人和用户协作、沟通和讨论时，避免使用「是不是」、「有没有」等封闭性问题；多用开放性问题，一步步引导用户表达出最真实的想法。

发现用户频繁点击某个按钮，或浏览选项的时间过长时，可以通过抛出「你希望这个按钮提供什么功能/选项（但没有满足）吗？」等问题，鼓励用户主动说出对系统功能的期待，为后续的迭代贡献有价值的意见和改进空间。

04 待办优化

在评审会的最后，产品负责人及关键干系人介绍有关后续迭代的新信息或新设想，结合当前产品或市场环境的变化，讨论即将发布的版本的产品功能，为接下来的迭代计划会议提供有价值的输入信息。

通常在会后，产品负责人会结合迭代评审会的结果，对产品待办列表和需求优先级进行重新评审和整理——这也是衡量会议成功的关键。

为了更准确地完成待办列表调整，开发团队应对未完成的工作保持开放和透明，以便产品负责人能制定更全面的决策；

产品负责人可以结合不同决策依据，应用优先级排序的三个模型和四张画布，更高效地完成调整。

更多阅读请点击：

不同决策应参考什么指标进行优先级优化？

做优先级排序时使用最多的三个模型

译文 | 四张画布教你判断「产品开发优先级」

# Liga总结

迭代评审会的核心目标是为了获取真实的用户反馈，为后续的迭代和研发工作贡献有价值的意见。

高效的迭代评审会要抓住功能展示、体验试用、讨论反馈和待办优化四个关键环节。Scrum团队以专业、高效的姿态，向干系人和用户呈现研发成果；通过引导和观察，洞悉真实场景下的使用反馈，更好地服务后续迭代。

>> LigaAI 往期精彩阅读 <<

优秀的程序员如何提升个人能力？

每日站会能不能取消？

如何消减协同合作中的认知偏差？

敏捷实践 | 《需求拆分流程图》详解

垂直切片是敏捷需求拆分的最佳实践 | 敏捷实践

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

在Scrum中，Sprint Review是践行其言的最佳实践。

迭代结束前，敏捷团队通过Sprint Review，向关键干系人展示其工作结果和目标完成进度，检查已交付的价值增量，并结合反馈确定或调整未来的产品规划和待办列表。

依据敏捷联盟的描述，Sprint Review的与会人包括Scrum团队（产品负责人、Scrum Master和研发团队），以及产品负责人邀请的关键干系人；会议的一般流程如下：

Scrum团队说明产品待办列表中哪些项目已经/尚未完成。

开发人员讨论在迭代期间达成的进展、遇到的问题以及其解决方案。

开发人员展示已经完成的工作，并回答关于价值增量的问题。

产品负责人讨论现有的产品待办列表，并根据目前的项目进展预测可能的目标和交付日期（如果需要的话）。

敏捷团队合作讨论下一步怎么做，Sprint Review要为后续的迭代提供有价值的意见。

审查产品或市场环境的变化，分析可能对下一步要做的最有价值的事情产生的影响。

讨论即将发布的版本的产品功能，审查时间表、预算、潜在功能以及市场变化。

不同语境下，Sprint Review多被译为「迭代评审会」或「功能演示会」。但众多实践经验却强调：

You should never call the Sprint Review the Sprint Demo.

Sprint Review是不是Demo/功能演示会？解答这个问题，要先回答会议的「讨论对象」和「会议目标」分别是什么。

一、不局限于迭代成果，重点展示整个产品增量

若从字面涵义理解Sprint Review，或许有朋友会认为它是关于迭代成果的会议，即讨论当前迭代已交付的价值。但Sprint Review的一般流程指出，与会人应该围绕「价值增量」展开讨论。

开发人员展示其已经完成的工作，并回答关于价值增量的问题。

Scrum Guide中定义「增量 Increment」为「所有先前增量的累加」，且实践经验表明，增量会在Sprint Review会议呈现。

每个增量都是所有先前增量的累加，并经过全面验证以确保所有增量可协同工作……增量的总和会在Sprint Review中呈现，以支持经验主义。

因此，除了同步迭代期间工作和障碍外，更重要的，Sprint Review要展示整个产品增量，以供检视，而不仅是关注最新的迭代所实现的价值。

技术侧成员向业务侧呈现基于整个产品目标的已完成工作，业务侧成员结合产品目标和外部变化，对研发成果进行验收。

Sprint Review能够实现「产研-业务-用户」多终端的进度同步和目标对齐。若只停留在迭代增量的展示或报告上，恐怕就会降级成围绕「完成了什么 > 没完成什么 > 为什么没完成」的工作汇报。

相比逐一展示用户故事，或者仅使用含功能截图的PPT汇报，Demo演示能够更加直观、全面且集中地呈现业务目标的完成进度，也更便于产品负责人和关键干系人评估研发成果，更快地完成目标的调整和待办优化。

也因此，许多实践经验都证明，完整的产品功能展示/Demo演示是更理想的Sprint Review形式。

二、不止于Demo演示，协作与反馈更为关键

虽说功能/Demo演示是更理想的形式，但这并不意味着，顺利完成功能演示就大功告成。Sprint Review的最终目的不是演示，而是对产品待办列表做出调整。

敏捷开发的核心是快速响应和拥抱「变化」——所有外部的、业务的、基于时间/预算/组织的变化。敏捷开发通过短周期的价值交付，和及时地获取源自业务的反馈，持续地明确、修正和调整前进目标，以减小变化带来的影响。

是以，Scrum团队呈现围绕目标和业务交付的研发成果（即产品价值增量），只是完成信息透明和进度同步的第一步；

更重要的下一步是，与关键干系人协作，获得基于迭代和增量的反馈，为后续的迭代工作提供宝贵意见，再次明确目标，并分析下一迭代所需交付的「最有价值的事情」的变化。

所谓「协作」就是要打破技术和业务、Scrum团队和干系人之间的「隐形墙」，将所有人揉成一团，在统一的会议目标基础之上，展开互动和讨论。

比如，与其让开发团队演示产品功能，不如让干系人在开发的指导下完成用户路径，以真正的用户视角检查研发成果，贡献反馈。

换句话说，让Scrum团队与主要干系人组织协作，完成对产品待办列表的检查和调整是会议的关键。脱离反馈和待办调整的单方面的功能演示，只是换了外衣的「工作汇报」罢了。正如《深入核心的敏捷开发》所说的：

如何评价迭代评审会的效果？唯一的评价标准是，会后有没有对Product Backlog做出调整。

三、给予正向反馈，尊重并认可团队的贡献

Scrum团队与主要干系人破冰协作，为当前的产品增量提供反馈意见，并确定后续的迭代目标。但在许多敏捷实践中，贡献反馈的环节很容易变形成「质量检验」和「缺陷问责」。

当与会人将Sprint Review视作「成果汇报」或者「阶段验收」，业务端会天然地形成「查漏补缺」和「拨乱反正」的自觉，而技术端则会因免于指责而陷入「粉饰太平」之中。

长此以往，技术和业务、Scrum团队和干系人之间的关系会越发紧张，阵营堡垒也逐渐坚厚，最后Sprint Review成为人人抗拒的仪式。

因此，Sprint Review不是为了贡献一个集中问责的机会，而是为了及时的反馈和更好的提升——这也是敏捷开发所追求的——持续地学习、反馈、提升和再实践。

换言之，Sprint Review希望输出正向反馈：业务端对技术端为实现目标所作出的贡献和成果表示认可与尊重；技术端对业务端传递的反馈和改进建议持以开放心态；至于那些尚未完成/仍需优化的部分正是下一阶段或后续的努力方向。

Sprint Review不是针锋相对的修罗场，而是结合沟通、协作和反馈的最佳实践。

• 产品负责人和干系人通过功能演示掌握最新的产品增量和目标进度，作出最及时的修正和调整，确定正确的业务方向；
• Scrum Master和开发团队在展示和讨论中，同步成果、统一目标、定位和评估目标贡献度，在真实的反馈中赢得工作成就感。

正确的Sprint Review能让每一位与会人在结束会议时都认为「我们正朝着正确的方向前进」。

# Liga总结

Sprint Review是「以终为始」的优化过程——围绕完整的产品/模块形态，检视当前的进度，评估需要修正的阶段目标并制定下一步的成长计划。

因此，Sprint Review应该围绕产品的价值增量展开，而不是只关注最新的迭代交付了哪些价值；同时，会议结束要有反馈输出，对产品待办列表做出恰当的调整。

Demo演示是比较理想的会议形式，但不要只停留在演示；反馈不为问责，而是为了提升和优化，成就更好的敏捷协作。

>> LigaAI 往期精彩阅读 <<

分布式团队的高效站立会说明书

优秀的程序员如何提升个人能力？

每日站会能不能取消？

如何消减协同合作中的认知偏差？

敏捷实践 | 《需求拆分流程图》详解

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。