现在快节奏的职场状况，让我们都习惯了一个项目一个项目地去完成工作，迅速成立一个项目，然后和其他部门进行沟通、协同、推进，最后执行、产生成果。在这个过程中，因为不只是我们自己在工作，还会涉及到别的部门、同事，甚至需要得到领导的、公司的资源支持，那么就会可能产生很多未必能预测到碰撞、撕逼、推诿等不好的情况。所以，很多时候作为项目负责人，往往都需要承担起让这个项目成功，而不是半途流产，或者是投入了成本和资源，完全没有成果的责任。最后，我们在有阶段性进展的时候，以及到项目正式结束之后，都要在成员内部开展复盘会议。以前叫总结会，更多的可能是老板一言堂，说说谁干得怎样，谁哪里做得不好，项目成绩如何等等。这对于成员来说，实际性帮助意义不大，更像是老板对员工的表彰大会。现在，大家都意识到一个人的成功远远不及团队的成功来得更能提升业绩，所以，我们就更倾向于让每个成员一起复盘。找到在这个项目里，大家的卡点在哪里，下次如何避免才能做得更好，哪个环节出了纰漏可以改进等。复盘的意义，就是要做到有效复盘，而“有效”的前提就是每个人都有参与，主动吸取教训，积累经验。01首先，大家都知道，“复盘”这个词最早出自围棋，复就是“重复”的“复”，盘就是“棋盘”的“盘”，指的是对一盘棋的深度讨论。下完棋之后，不管赢的输的，双方的棋手和一帮看热闹的都不走，坐下来围着棋盘，认真地讨论每一步下过的棋。大家一起分析那关键的几步棋，说“为什么当时会这么下？有没有其他更好的选择啊？”然后赢的或输的那个都是一拍脑门子说“唉呦，我当时没想到！”所以这就叫“吃一堑，长一智”，而不是念念检讨书，比谁的认错态度更好。02其次，复盘会议的主持人，第一件事就必须得让大家知道，这是一个可以放下戒心的复盘会。我们复盘的第一原则是对事不对人。因为针对了某个人，类似的问题还有可能会发生。很多时候，都是我们大家都做了各自认为正确的事，但是导致了一个特别错误的结果。但是，它不是因为某个人不靠谱，而导致了这个难以接受的结果。所以，所有的有效复盘要做的第一件事，先得保证整个流程里面对事不对人，能够关闭大家的威胁机制。复盘的第二个原则，叫还原现场。你得让每个人都知道，出现问题的那一刻，你在做什么？你的同事在做什么？大家沟通的盲点在什么地方？因为现在项目合作，更多的是涉及到各个部门的沟通协作问题，其实最容易产生的是对彼此动作的误判，也导致自己的动作变形。就好像球场上，俩人配合射门，你以为我要射，我以为你要射，传来传去，结果错失了机会。所以，在复盘的时候，最重要的就是所有人都在同一个时间点上，把自己动作的由来，思考的过程摆到桌面上。有时候老板一个人说，那听的过程当中，你也会有收获。但是大家对于搞砸事情的过程，都有一个自己内心的版本，所以只有一个角度，就很容易有局限。而通过大家都可以平等发言的复盘会议，大家就自然而然地把所有的信息都拼凑起来，就还原了整个事情的全貌。03最后，在一个事情当中，具体该怎么复盘？复盘的时候，最麻烦的事，不是大家都不愿意认错，而是好多人根本不知道自己做错了，而又是错在哪里。这时候就容易互相觉得彼此都在推诿，把责任推给别人，专门抓住别人的错误进行攻击，从而变成了互相指责。所以，冷静下来，就要从自己的主动的角度，把过去的时候，再想一遍，阐述的时候，用“我……”来开头。比如说，你本来是觉得，说“某某没把这个流程共享出来，所以我才没有做到哪个事情。”改为说，“我当时是这样想的，大概这么个方法适用，所以我和某某就没有进一步讨论。”这才是有价值的复盘，大家就事论事，从自身角度出发看待自己的动作和事情，你才知道说，整个流程下来，整个项目里，你处于什么的位置，哪些动作可以和哪些同事有更多的互动，自己真正能够改变的是什么。最后，复盘会结束之后，全体成员都要相互鼓励一下。这么做的目的，是说要建立大家对于复盘会的安全感，让公司变成一个有复盘习惯的地方，同时觉得下一个项目，和这群人在一起努力奋斗，会更有期待。●老板和直属上司的意见不和，作为下属要听谁的？●被同事八卦和误会了，我要怎样辩解？●职场中，跟对人比进好公司到底好在哪里？

工作总结复盘是一种对工作进行回顾、总结和反思的过程，旨在发现问题、总结经验、改进工作方法，提高工作效率和质量。下面我将以一个销售人员的工作为例，详细说明如何进行总结复盘。一、明确总结复盘的目的和范围在进行总结复盘之前，首先需要明确总结复盘的目的和范围。例如，某销售人员的目标是提高销售额和客户满意度，那么他的总结复盘就应该聚焦于这两个方面。二、回顾工作过程和成果销售人员可以回顾自己的工作过程，包括销售策略、客户拜访、销售谈判等环节。同时，也要回顾自己的销售成果，比如销售额、客户增长情况等。通过回顾工作过程和成果，销售人员可以了解自己的工作情况，找出问题和不足之处。三、分析问题和不足在回顾的基础上，销售人员需要分析工作中存在的问题和不足。比如，销售额不达预期、客户投诉较多等。销售人员可以通过与同事、上级和客户的交流，了解问题的具体原因和背后的因素，找出问题的症结所在。四、总结经验和教训在分析问题和不足的基础上，销售人员需要总结工作中的经验和教训。比如，销售人员可以总结出一些有效的销售策略、客户管理方法等。同时，也要总结出一些教训，避免再次犯同样的错误。五、制定改进计划销售人员需要根据总结的经验和教训，制定改进计划。比如，销售人员可以制定提高销售额的具体措施，比如加强市场调研、提升客户服务质量等。同时，也要制定改进自身能力和技能的计划，比如参加销售培训、学习销售技巧等。六、执行改进计划并监督反馈销售人员需要执行制定的改进计划，并及时监督和反馈。比如，销售人员可以定期检查自己的销售额和客户满意度是否有所改善，同时也要向上级汇报自己的改进情况。七、总结复盘的持续性和反馈总结复盘是一个持续性的过程，销售人员需要定期进行总结复盘，并根据反馈不断改进。比如，销售人员可以每个季度或每个月进行一次总结复盘，以确保工作的持续改进和提高。总结复盘的过程中，销售人员需要保持客观、深入地分析问题和不足，同时也要积极寻找经验和教训。通过总结复盘，销售人员可以不断提升自己的工作能力和水平，实现个人和团队的发展。 #职场充电站#

概括的四大步骤适用于以个人为主体的复盘分析，分析的对象可以是自己、产品或项目。本文主要介绍的方法论是概括的四大步骤，enjoy~1. 复盘分析的方法论复盘分析的核心思路，就是戴明环（PDCA）的应用，由此来分析过去某一段时间内产品和项目的工作情况以及成果总结，更重要的是获得可验证的规律/经验。概括的四大步骤适用于以个人为主体的复盘分析，分析的对象可以是自己、产品或项目。细分的八大步骤适用于以团队为主体的复盘分析，形式通常是会议，分析的对象可以是产品或项目。本文主要介绍的方法论是概括的四大步骤（因为使用范围和对象更广，实际应用的频率也会高，Sue过往的工作经验中，有勇气有意识开复盘分析会议的公司和领导不算常见，会有互撕耍锅的情况发生）。1.1 回顾目标P-plan，所设定的计划/目标是怎么样的？大到项目立项，小到版本迭代，我们任何一项工作的开展，都不能忘了初衷和目的。在工作开展的过程中，应当始终朝着所设定的目标去努力实现。但理想与现实往往都有偏差，有各种各样的因素存在，也有各种各样的情况会出现，最终导致不同结果的发生。所以复盘分析的第一步，是回顾目标。走到了今天，不妨回过头去看看当初的目标。1.2 评估结果D-do，做了什么？执行的情况如何？结果是既成的事实了。结果的好与差，多好或多差，它需要有一个参照标准来对比的。我们第一步回顾的目标就是参照物了。通过对比，会找到目标和实际结果的差距。类似两个数字之间的比大小，情况可分为三种：“大于”，结果大于目标，就是指完成的情况比设定的目标要好；“等于”，结果等于目标，就是指完成的情况刚好达到设定的目标；“小于”，结果小于目标，就是指完成的情况比设定的目标要差。除了上面的三种情况，还有两种情况需要注意的：一是，目标里面的事项没有做，那结果可视为0，这种情况也属于结果不如目标，但需要单独讨论，是因为差距的原因是根本没有行动，那为什么设定了目标且始终没有行动呢？二是，结果里面的事项是没在目标内的，通俗的说法就是，明明是数字比大小，你却把结果改成了字母，那跟目标（数字）的对比，就不能是单纯的大小了。这说明差距是我们做了目标计划之外的事情，为什么会出现这样的情况呢？需要强调，关注的重点不是差距的大小，而是出现差距的地方，可以是试着去思考：为什么会出现这样的差距？1.3 分析原因check，检查分清对错好坏，找到原因和问题。通过第二步的对比，找到了差距，那这些差距造成的原因是什么，我们失败了吗？失败的根本原因是什么？如果没有失败，那我们成功的关键因素是什么……这些都需要深入去思考。对发生过的事情，尤其是特殊时间节点的举措，一一罗列然后进行反思，分析得出的原因要包括主观和客观两个方面的，都要尽量穷尽，且尽量触达最深刻的“根因”。1.4 总结规律action，总结经验、吸取教训，得到规律，行动验证，不断循环。这是复盘分析最重要的一步。上面所有的步骤都是为了得出一般性的规律，形成符合真相的认识。总结规律得出的结论是否正确，最好的方式是检验。复盘得出的结论是否可靠，必须在复盘的当时做出判断，一般来说可以通过 4 原则来评判：（1）复盘结论的落脚点是否在偶发性的因素上？当复盘的结论落脚在偶发性因素上，那一定是错误的。如果复盘没有进入到逻辑层面，没有经受住逻辑的验证，则这样的复盘结论，一定是不可信的。（2）复盘结论是指向人还是指向事？复盘的结论如果是指向人，则很可能说明复盘没有真正到位。因为复盘得出的是规律性的认识，而人是具体的，各不相同。指向事，则复盘到规律的可能性更高。当然，这里的“事”不仅仅是指某件具体的事，而是人之外的事物。不要随意外部归因，比如：“如果出租车司机都开这么慢，那我以后都会迟到”等等，这会将事件引导到阴谋论上。复盘的结论不是指向人，而是从事物的本质去理解分析，这是验证复盘结论是否可靠的标准之一。（3）复盘结论的得出，是否有过3次以上连续的 why 或者 why not 的追问？复盘得出的结论，至少应该有过三次以上的连续的 why 或者 why not 的询问。如果次数不够，也很可能意味着复盘没有找到真正的原因。探寻问题背后的问题，找出答案之后的答案，这就是追问的目的。（4）是否是经过交叉验证得出的结论？“孤证不能定案”是法律上的术语，用来比喻复盘得出的结论通过其他事情交叉验证，也可以为结论的有效性提供一定的保障。2. 复盘分析的应用和技巧2.1 对项目的复盘分析项目复盘的时间：最好在项目结束后的一个星期。这个时间节点，项目刚结束不久，参与项目的人员对项目各情况的印象还比较清楚，比较容易回忆。项目复盘的参与人员：最好参与过项目的人都能参与进来，在项目开展过程承担关键角色的人员是必须要参与的，例如项目经理、产品经理、研发经理、运营经理等等。项目复盘的提前准备：通知需参与会议的相关人员，让各自准备相关的材料、邀请一位复盘会议的引导者。材料包含但不仅限：文档：版本迭代记录、用户反馈记录等；数据：过程中的数据、最终的数据等。项目复盘的阶段流程：套用上面分享的四大步骤，对项目复盘分析的工作可分成以下3个步骤：（1）对项目做整体的回顾这一步将四大步骤中的（1）回顾目标和（2）评估结果进行了合并，从“起点”（目标）到“终点”（结果），对项目进行整体的回顾。为了避免一上来就“唯结果论”，相互抢功或耍锅，开场应该相对轻松点，可以让大家先来聊聊对项目的理解：项目服务的对象是否符合项目定位的客户/用户？项目开展的过程中我们遇到了哪些机遇？什么挑战？项目取得的成果是否符合我们的期望值？好在哪？差在哪？……（2）对关键事件进行回顾项目的起止，有时间线，那自然就会对应有故事线。过程中发生的各个关键事件，是影响项目运营和项目结果的重要因素，我们应当一一列举并分析。这时候让参与会议的人员提前准备，就很有意义了。从项目立项开始画一条时间线，在时间线上标注出各个关键的节点，让所有人对应时间点，把自己印象深刻的、对项目当时有影响的事情写在便条上，然后贴上去。便条需要讲清楚几点：当时发生了什么事，是怎么发生的，造成了什么问题，最后是怎么解决的。（3）产出团队和个人收获付出必然会有收获的（这不是一句毒鸡汤）。这里想说的收获，更多的是对人对事的收获。还是那句话，项目的结果是既成的事实。结果有可能是不如预期的，有可能是刚好达到设想的，也有可能超出预期的，这始终不是关注的重点。复盘的意义在于总结，找到对项目有贡献的人，肯定和学习ta；总结对项目有利的经验，校验然后放大它。对人的部分，可以把项目关键角色的人头像贴出来或名字写出来，让大家把跟这个人合作的经历、感受和评价写下来，肯定ta过往对项目的贡献。对经验的部分，可以从沟通、人员、流程和实践等方面进行收获总结。2.2 对产品的复盘分析对产品的复盘，更准确的说法，应该是对版本的复盘。产品复盘的周期：这需要具体依据产品的版本迭代速度而定。一般是3个版本迭代完就应该进行一次产品复盘。产品复盘的参与人员：参与版本设计、研发和运营的相关人员，例如产品经理、美术、研发、测试、运营、客服、商务等。产品复盘的提前准备：通知需参与会议的相关人员，让各自准备相关的材料、邀请一位复盘会议的引导者。材料包含但不仅限：文档：版本迭代记录、需求管理表、需求文档、设计图稿、开发文档、测试用例、用户反馈记录等；数据：版本迭代前一个周期的数据、版本迭代后一个周期的数据。产品复盘的阶段流程：同样套用上面分享的四大步骤，对产品复盘分析的工作可分成以下4个步骤：（1）回顾版本目标依据准备好的版本迭代记录和需求管理表，先来回顾一下复盘版本的迭代内容，这些内容都是围绕什么重点/目标展开的，属于新增功能还是优化已有功能，这些功能点是服务于哪些人群的，他们的群体特征是什么样的，主要是想满足他们什么样的需求？表层需求是什么？底层需求又是什么？如何验证版本的效果？所以这就要求我们接到需求后，要对需求进行足够的分析，在设计产品和规划版本的时候，要提前想好验证产品设计的方式，罗列出希望改善的数据/指标。它有可能是营收类指标比如订单金额，也可能是功能使用率的漏斗模型指标，或者用户好感度相关的指标等等。（2）评估版本结果用数据说话。将版本发布前后的两个周期进行对比，数据/指标上有哪些变化？版本面向用户的意见反馈怎么样？他们喜欢和认可新版本发布的内容吗？认为还有未被满足的需求吗？或者是还有期待被服务得更好的场景？（3）分析关键环节这一步，可以按产品开发生产线的各个节点划分为关键环节，依次可以划分为：需求——设计——开发——测试——上线。A. 需求这个环节，主要复盘的内容有以下几项：需求对接：需求方的需求表述是否清楚？产品经理的需求分析是否准确？需求定义：需求文档的输出是否完整清晰？设计师、交互师、开发、测试对需求是否了解？产品经理需求方的对接：需求变更：需求变更的次数是否频繁？存在需求变更影响到了版本进度？需求变更的原因是什么？需求变更后是否有对文档进行及时的更新？是否做好沟通工作，把需求变更的事宜清楚地传递给相关人员？B. 设计这个环节，主要复盘的内容有以下几项：设计确认：是否有确定视觉设计的最终审核人？设计标准：UI设计产出是否符合统一标准？工期进度：产品设计工作在什么时候，由谁来完成的？设计工作是否影响开发工作的进度？影响原因是什么？C. 开发这个环节，主要复盘的内容有以下几项：工期进度：开发实施前，是否有充分的时间做工期预估？工期预估与实际开发时间是否有差异，及差异原因分析。开发文档：是否有撰写开发文档？开发文档是否符合规范?突发状况：是否出现需求无法实现的状况？原因是什么？是否出现团队成员变动情况？如何应对成员变动？后期如何避免？是否出现功能模块与需求不符的情况？出现原因是什么？D.测试这个环节，主要复盘的内容有以下几项：测试计划：是否有完整、准确的测试用例？是否有一个测试计划？这样的计划是否有效？团队是如何测试并跟踪产品开发效果的？测试工具：使用了哪些测试工具来帮助测试？是否可以持续使用？测试的时间、人力和软件/硬件资源是否足够?测试结果：哪个功能模块产生的Bug最多，为什么？哪些BUG出现回滚，原因是什么？E. 上线这个环节，主要复盘的内容有以下几项：版本验收：是否进行了正式的上线验收？在正式发布的过程中是否有出现状况？后续如何避免？是否检查了数据埋点，数据埋点是否满足要求？上线通知：是否有通知到相关人员？上线前是否和运营、文案进行充分的沟通？发版效果：在上线之后是否出现重大bug? 为什么测试阶段没有发现？产品上线后的问题反馈渠道是否流程？产品上线后收集到哪些问题反馈？都是什么类型？如何改进？（4）总结版本经验顺着产品开发生产线的各个关键节点逐一去反思总结存在的问题，得出版本迭代的经验：有哪些错误我们要去改正的？哪些情况可以去避免的？有哪些避免的措施可以做？哪些好的经验和配合我们要继续保持的？2.3 对个人的复盘分析同样套用上面分享的四大步骤，对个人复盘分析的工作可分成以下4个步骤：（大白话的复盘思路就是：我是谁？做了什么？做得怎么样？还能不能更好？）（1）自我定位不要用类似“我是xxx项目xx产品的产品经理”这种简单的表述作为你的自我定位，这更准确的说法是“职位/title”，不能算“自我定位”。试着去描述你在团队/项目中，承担着什么样的角色，这个角色存在的价值是什么？除了在企业的角度上看你作为产品经理的价值，更重要的是在你的理解下，你的价值是什么？你不可替代或难以替代的地方是什么？甚至都可以是你在承担这个角色时的人物性格、人格魅力的自我剖析。假设Sue作为一名数据型的产品经理，除了负责数据采集、加工、分析；负责整个项目的数据平台搭建，还有应该做到充分理解平台项目业务，为业务增长和用户体验提供数据服务支持，很好地对数据进行应用与实践，优化产品策略和提高业务收入，实现数据驱动、数据赋能的价值。（2）个人产出根据自我定位的职责和价值，和你实际的产出进行对比，找出差距。你在项目发展中，做了什么事情？这些事情对项目的推进有什么作用？你在版本迭代中，做了什么事情？这些事情对产品的发展有什么影响？你在整个团队中，贡献的价值是什么？有多大？简单的说就是：你做了什么？结果怎么样？有哪些亮点？哪些不足？（3）深入分析对差距存在的原因进行反思和分析，取得成绩（亮点）的原因是什么？造成问题（不足）的原因是什么？这里可提供几个参考角度：依据差距去追查原因：对比往期结果、对比同行分析分析原因时明辨内外：是自己的努力带来的？外在环境造成的？厘清线索判定是否可控：可控？不可控？半可控？（4）总结成长可以从以下几个方面，进行思考和总结，帮助自己更好的成长。A. 工作流程需求方面：需求对接、需求管理、需求设计、需求评审。版本管理方面：周期确认、周期跟进、验收确认、跟进反馈。B. 产品技能流程梳理能力：业务流程、页面流程、涉及多角色的跨职能流程；文档撰写能力：交互设计、页面布局设计、文字表述能力。C. 工作习惯是否养成记录工作日志的习惯？是否养成定期体验产品的习惯？是否养成关注行业动向的习惯？产品经理是个综合性要求很强的职位，除了上面简单提到的几个方面外，还有很多需要不断学习的地方：类似企业经营、团队管理、运营推广等等。以上，是Sue最近做自己所在项目的复盘分析以及个人的工作总结时，对“复盘分析”有了一些新的总结与思考，整理后与大家分享，希望有小伙伴一起交流学习。项目具体的复盘分析不便分享，跟大家分享一下梳理的学习脑图（https://kdocs.cn/l/sRcLmnp5U?f=131）本文由 @素小白 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议