产品负责人的轻度思考，6 个小策略，面对迭代 Sprint 评审会

人类并不善于将事情做得十全十美，于是软件中充满 Bug 也就不足为奇了。

Sprint 评审会议可能是产品负责人最重要的活动，它可以帮助你收集反馈意见，做出正确的产品决策，从而增加创造成功产品的机会。产品负责人可能并不总是清楚谁应该参加会议，应该如何开展这个会议，以及如何收集相关反馈。本文将回答这些问题，并分享一些建议，以帮助你在 Sprint 评审会上得到更多收获。

邀请正确的人参与

从正确的人那里收集反馈信息对于做出正确的产品决策至关重要：如果你邀请了不合适的人参与，或者关键人物未到场，那么你不太可能收到你所需要的反馈。因此，你应该确保你邀请合适的人参与。

一般来说，邀请那些你需要获得反馈来验证最新产品增量，以及可以帮助你推进产品发展的人参与。这些人通常是你的关键干系人 - 对你的产品有兴趣的人员，以及你需要去发掘的产品用户和需要你提供产品的人。这些人可能包括营销，销售，服务和支持人员以及其他业务部门的人员，具体取决于你的产品和组织。

为了鼓励干系人参与，以及管理干系人的期望，告诉他们为什么需要他们参加会议，以及他们可能会看到什么，这是很有帮助的。

协作但不要畏惧说不

我参加过不止一个很快就结束的 Sprint 评审会：一位开发团队成员向那些看起来很困惑的干系人和站在这些干系人身后的产品负责人演示了产品功能。然后，Scrum Master 询问大家是否有任何问题或反馈意见，这些干系人相互看着对方，有些人说：“干的不错”，“看起来还可以”，然后人们就离开了。这次会议收集到的有价值的意见是零。

因此，要鼓励人们积极参与并分享他们的观点，想法和担忧。使用开放式的问题，比如“你怎么看待我们对注册功能的改进？”，试着理解为什么有人喜欢或不喜欢这个迭代的产品增量。收到诸如“看起来很棒”的反馈可能会感觉很好，但是它并没有提供任何新的见解。为什么这个人喜欢这个功能？有什么可以进一步改善？

让所有的与会者有机会发表他们的观点，欣赏他们的意见和反馈，即使你不同意或难以接受他们。请记住：来自干系人的创造力，知识和反馈可以帮助你做出正确的产品决策，以提供可能的最好的产品。

同时，不要接受某些个人通过这个会议来达成他的个人目的或者某个业务单元的利益。我记得有一次 Sprint 评审会，当时一位高级干系人在产品负责人和开发团队中直言不讳地提出了他的要求，这当然不合适，也没有提供任何帮助。

作为产品负责人，善待和理解很重要。但是不要让干系人告诉你该怎么做。你对产品负责，你必须拥有最后的发言权，否则你无法获得足够的权力和尊重。

对于没有帮助的想法和不现实的要求，不要害怕说不。基于产品整体战略和产品路线图来决定是否需要接受相关请求。如果你怀疑你的决定，可以使用下一个 sprint 来测试这个想法或请求是否对用户有益。但请记住，提供一个令所有人满意的产品几乎是不可能的。

考虑把 Sprint 评审会分成两部分

在有些情况下，将 Sprint 评审会分为两部分是有帮助的。

第一部分，你和开发团队参与，团队向你演示产品增量。然后，你向团队成员提供反馈意见，并确定哪些条目已完成，我们现在进展如何。你可以使用发布燃尽图来看看进展。如果你在 Sprint 期间已经有了足够多的参与，并且已经看过相关完成的功能并给与了反馈，那么第一部分的环节你可能根本不需要。

第二部分，干系人参加会议。我发现，作为产品负责人，通常最适合向干系人呈现产品增量：你可能比开发团队成员更好地了解用户如何与产品进行交互并使用新功能。然后收集干系人的反馈意见，以了解我们是否开发出了具有正确用户体验和功能的正确产品。按照上面的建议询问开放式问题，以便了解为什么新功能很好或者为什么需要调整。

把会议分成两个部分，这样你可以与开发团队有一个线下沟通的机会，也可以在 Scrum 团队以外的人加入之前理清分歧。当你在 Sprint 期间没有机会与团队互动时，这种方式尤其有用，例如，你和团队不在一个地方办公，或者你忙于访问用户和客户，或参加展会或会议。但是要确保开发团队成员出席整个会议。直接听取干系人的意见是非常宝贵的。

考虑分开收集最终用户和干系人的反馈

Sprint 评审会的原意是将所有合适的人聚集在一起，同时收集每个人的反馈意见。如果这对你有效，那很好。但是，我经常发现分别收集用户和内部干系人的反馈信息会更有帮助。为什么？这两个群体往往有不同的观点和利益。

通过用户测试产品增量可以让你了解产品是否适用于你的目标用户群，是否提供了正确的用户体验和正确的功能。与干系人讨论产品增量可帮助你了解是否高效地提供了产品，是否可以开始运营、销售和支撑你的组织了。

更重要的是，最好用不同的技术来收集用户和干系人的反馈：当实现的功能很少时，向最终用户演示产品增量是有意义的。否则，观察或测量用户实际使用产品的方式会更有帮助，例如可用性测试和早期版本。

相比 Sprint 评审会，这些技术通常需要更长的时间，可能需要几天的时间才能将产品增量发布给（选定的）用户后收集相关数据，这种方式自然而然地把收集最终用户反馈和收集干系人反馈分开了。

用户胜过干系人：如果产品不利于用户，人们不会长期使用它，无论它是多么可销售或者可服务，或者 CEO 有多喜欢。

不要急于决定

有些情况下，你可以在 Sprint 评审会议上立即做出产品决策，甚至可以调整好产品 Backlog。很多时候，特别是如果反馈的影响比较大，导致产品 Backlog 变化更大的时候， 花更多的时间来分析反馈，得出正确的结论，然后再决定如何调整产品 Backlog，这样你能够得到更多的收获。

此外，如果你决定分开收集用户和干系人的反馈意见，如上所述，你可能不会在 Sprint 评审会获得相关反馈数据。因此，你应该考虑把收集反馈和数据，跟分析和采取行动分开进行。例如，你可以选择在下一次 Sprint 计划会议之前开展一个简短、聚焦的产品 Backlog 工作坊，用这种方式来客观评估这些反馈，并和开发团队讨论如何调整产品 Backlog。 或者，你可以在分析工具的帮助下，收集到足够多的用户数据以后，在下个 Sprint 组织一次产品 Backlog 的会议来评估这些反馈。

讨论发布进度

想象一下，所有的反馈和数据表明，人们将会热爱你的产品。然而，如果你的产品发布延迟或者超出预算，那么产品可能不会成功，甚至可能不会正式发布。因此，你必须定期确保产品要有进展。

Sprint 评审会是一个很好的机会，因为你现在应该知道哪些条目已经完成，距离终点还有多远。此外，参加会议的关键干系人可能需要知道新的产品版本是否能按计划发布，或者是否有延误，因为这可能会影响他们的工作。更重要的是，讨论发布进度将当前的 Sprint 放到了上下文环境中，并和之前 Sprint 连接起来，让我们能看到整体的进展。

我喜欢使用发布燃尽图——Scrum 的标准工具来跟踪发布进度，并预测项目的后续进展。发布燃尽图展示了产品 Backlog 中剩余的工作量随着迭代的开展不断减少的趋势。

无论你使用哪种工具：确保它可以帮助你了解你的进度如何，并进行必要的调整：比如，推迟发布日期、只部分满足发布目标、比计划交付更少一些的功能等。

<img class="alignnone size-full wp-image-642" src="https://raw.githubusercontent.com/reachsys/imagebed/master/blog/image/202007/qrcode_for_gh_babbdd98b6f5_258-1-20200606164316652.jpg" sizes="(max-width: 258px) 100vw, 258px"/>