活动运营：一场完整活动项目的复盘流程！

复盘是运营必备能力，小到买菜经历，大到百亿千亿投资项目，都能通过复盘总结规律、提升水平。

简单来说，复盘能达成两个效果：

• 优化弱项，强化强项
• 明确自身价值与工作价值

那么，该如何做好复盘？是否有高效实用的方法？答案是肯定的。

以下内容源于我工作中的思考，同时参考了柳传志的复盘方法论，旨在呈现完整、可实践的项目复盘流程。

一、复盘的底层逻辑

复盘首先要进行事实陈述，有效的AAR（After Action Review）必须建立在“铁的事实”基础上。若现实难以清晰陈述并达成一致，复盘将进展缓慢或难以深入。

事实确定后，开始诊断、分析差异原因，找出成功或失败的根本原因并总结规律。明确成功原因、关键行为及其适用条件，以及这些对提高后续行动成功率的价值。

因此，完整的复盘包含四个步骤：目标回顾、结果陈述、过程分析、规律总结。

• 目标回顾

  当初行动的意图或目的是什么？

  事件/行动期望达成的目标是什么？

  我们计划如何开展？

  预先制订的计划内容是什么？

  事先预想会发生什么事情？

• 结果陈述

  实际发生了什么事？

  在何种情况下发生的，过程如何？

  与目标相比，哪些方面表现出色，哪些未达预期？

• 过程分析

  实际状况与预期是否存在差异？

  若有差异，原因是什么，哪些因素导致未达预期目标？

  失败的根本原因是什么？

  若未失败，成功的关键因素有哪些？

• 规律总结

  从过程中学到了什么新内容？

  若有人开展同样行动，我会给出什么建议？

  接下来应采取哪些行动？

  哪些是可直接执行的行动？

二、项目复盘的阶段流程

一个项目通常包含目标、需求、设计、开发、测试、上线等核心阶段。分解每个阶段的具体工作，才能分析工作进展是否顺利、问题所在及优化方法。

这里分享一个项目复盘小技巧：按项目执行时间线记录工作日记。

不一定要每日记录，但要在重要时间节点留下工作记录，以便对活动过程了如指掌。复盘时，只需翻看日记，列出实际工作时间表，与策划书的计划时间表对比，就能知晓哪些工作提前、延后或临时加入，以及完成情况。

比如项目目标回顾，优质项目通常有明确预设目标。若目标不合理，复盘结论也难有说服力。所以复盘时要从目标设定合理性入手，思考当初设定目标的条件。

若项目整体目标较大，建议进行目标分解，确定项目实施里程碑，形成子目标或阶段性目标，便于衡量和跟进。以电商活动策划为例，影响交易额的子目标包括流量、转化率、客单价、复购率。

后续步骤同理，通过不断分解，对项目流程进行完整、可量化的梳理，从而对比项目指标实际情况与预期。

三、如何做产品项目复盘？

复盘最重要的两个环节是过往演绎和复盘优化，需明确偏差原因并提出针对性建议。

• 项目目标复盘

  1.1 项目进度复盘

  • 是否按原计划交付时间完成交付？
  • 原计划的需求点实现了多少，哪些未按计划实现？
  • 每个需求点延后的原因分别是什么？
  • 哪些里程碑出现延迟，原因是什么？

  1.2 项目结果复盘

  • 项目中出现了哪些意外，原因是什么？
  • 用户对新增功能点的接受程度是否与项目规划一致？
• 需求阶段复盘
  • 是否提供了完整的需求输出，如原型、MRD、PRD、UML等？
  • 设计师、交互师、开发人员是否明确需求？需求不明确会严重影响项目进度和质量。
  • 是否清晰描述了典型用户和使用场景？
• 设计阶段复盘
  • 是否确定了视觉设计的最终审核人？
  • UI设计产出是否符合统一标准？
  • 设计工作是否影响开发工作进度，原因是什么？
  • 产品设计工作何时由谁完成？
• 开发阶段复盘

  4.1 工期评估复盘

  • 开发实施前，是否有足够时间进行工期预估？工期评估既能让项目成员了解整体进度，也是梳理项目需求的过程。
  • 工期预估与实际开发时间是否存在差异，原因是什么？

  4.2 开发文档复盘

  • 是否撰写了开发文档？
  • 开发文档是否符合规范？

  4.3 突发状况复盘

  • 是否出现需求无法实现的情况，原因是什么？
  • 是否出现团队成员变动，如何应对，后期如何避免？
  • 是否出现功能模块与需求不符的情况，原因是什么？
• 测试阶段复盘

  5.1 测试计划复盘

  • 是否有完整、准确的测试用例？
  • 是否有有效的测试计划？
  • 团队如何测试并跟踪产品开发效果？

  5.2 测试工具复盘

  • 使用了哪些测试工具，是否可继续使用？
  • 测试的时间、人力和软件/硬件资源是否充足？

  5.3 测试结果复盘

  • 哪个功能模块产生的Bug最多，原因是什么？
  • 哪些BUG出现回滚，原因是什么（回滚：即程序版本回退。出现较大bug，程序从1.1回退到1.0，迭代之后全是bug，修复成本高）？
• 上线阶段复盘

  6.1 验收复盘

  • 是否进行了正式的上线验收？
  • 正式发布过程中是否出现状况，后续如何避免？
  • 上线前是否与运营、文案充分沟通？
  • 是否检查了数据埋点，是否满足运营要求？

  6.2 上线后效果复盘

  • 上线后是否出现重大bug，为何测试阶段未发现？
  • 产品上线后的问题反馈渠道是否畅通？
  • 产品上线后收集到哪些问题反馈，类型如何，如何改进？

每次项目复盘都是自我审视和锤炼。迭代型产品每3个版本进行一次复盘，通常发版节奏为每月一个版本，可按3个月周期复盘。

复盘结束后，尽快召开复盘会议，此时活动执行细节和用户反馈清晰，复盘可靠性高。

参与者应坦诚剖析，不推卸责任、不妄自菲薄，尽可能呈现完整真实的项目流程。每个人都有平等发言权，可真实表达想法。

要有专人控制时间和记录要点，避免会议冗长无重点。控制各部分时间很重要，记录要点也是会议成果输出，有助于总结经验和开展后续行动。