作为产品经理，我们的任务绝不仅规划功能那么简单，我们还需要负责建立工作流程、探索产品最优落地方式、并且努力搭建一个能让产品高效进化的团队文化。以下这些工作，都是在强化产品的进化引擎，让产品能随时间持续进化。 回溯（Retrospective）是强化引擎最有价值的方法之一。它帮助我们界定什么是好的、不好的，推动产品和流程向着越来越好的方向迭代。
一、回溯的定义
回溯指以批判性思维回顾过往经历。
它由4个核心要素组成：
- 定义什么是好的，继而在接下来继承
- 定义什么是不好的，继而在接下来改正
- 为了取长补短，制定下一步规划
- 确认制定的下一步规划得到执行。
二、如何实施回溯
一般来说，回溯都是在迭代周期中执行，所以接下来具体分析在版本迭代中怎么进行回溯。 在进行回溯前，有些准备工作要做： 首先，你需要找到正确的队友，即能够快速融入回溯过程中的同事，注意3点：
- 最好包括持不同意见的队友：想要精确地回顾好坏，团队必须从各个不同的方面去思考。
- 也别忘了带上有良好执行力的同事。
- 为了不稀释每个人的意见，回溯团队的人数也不要太多。就我自己来说，一般回溯团队中会包括一个工程师，一个设计还有一个QA。
其次，让团队保持信息同步：让每个人看到你们将要记录下来的东西，使用白板或者电脑都可以。一定要清晰地展示回溯四要素供随时参考。 团队组建好了，也找到使大家保持同步的方法了，现在可以正式进行回溯了。确保每个人知道正在回溯哪个版本，以及当初该版本的迭代计划。 接下来是正式的回溯流程：
第一步：”什么做得好”
在问大家觉得上次迭代中觉得那部分工作做得很好的时候，可能很多人不习惯表扬自己，我的应对方法是先真诚地表扬一些人，而且特别指出他们具体的贡献，这样之后大家就比较放得开。
下面是一些“做得好”的具体例子：
- 有一个组员冲刺得特别快，还能顺手帮助其他人
- 上线的某个功能在用户中反响非常好
- 整个团队的创新思维让我们项目进展比预估要快
第二步 “什么做得不好”
和不习惯表扬自己一样，团队可能也不习惯当众指出别人的问题。尽管很难在不归责的情况下界定“什么做得不太好”，还是要跟团队强调，回溯目的在于诊断问题和改进工作，而不是追责。如果大家仍然比较沉默，不妨从自己开始，反思自己哪些事情本可以做得更好。 下面是一些关于“什么做得不好”的具体例子
- 我有个JIRA卡写得不够清楚，导致分任务的人比较纠结
- 我们曾经没有如期完成任务
- 用户比我们自己更早发现了一些问题，而且这些问题影响大、原可避免
第三步“接下来该怎么做”
讨论完“什么做得好”“什么做得不好”，大家心里多少有些想法了，是时候进行头脑风暴了，头脑风暴的任务是确定接下来要做哪些取长补短的工作，要得到大家一致同意的结论。
第四步“是否执行了回溯讨论的决议”
到这步暂且放下刚刚讨论的，更往前去看看上次回溯工作的结论，看看上次大家一致同意的“接下来该怎么做”是否被有效地执行了。如果执行了，有什么效果吗？是否需要继续？对刚刚进行的最新一次回溯有什么启示？ 做完上述四步，回溯工作已近结尾，最后需要做的就是把讨论过程和结果文档化并且公告整个团队。
总结
回溯是个非常有效的工作方式，它帮助产品持续地向着更好的方向进化。作为产品经理，你几乎可以把回溯这种工作方式应用到产品管理的任何方面，而不仅仅是版本迭代。
回溯的四个核心要素：定义上次迭代的优点、定义上次迭代的缺点、制定下一步计划、回顾计划是否被有效执行。
最后，回溯提醒我们对每个人的工作心怀感激，如此，你和你的团队都将得到极大的成长。
原文地址：https://www.cnblogs.com/chuangye95/p/10176977.html