起点学院课程

复盘分析的方法论&应用技巧(适用于项目/产品/个人)

0 评论 4158 浏览 31 收藏 22 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

概括的四大步骤适用于以个人为主体的复盘分析,分析的对象可以是自己、产品或项目。本文主要介绍的方法论是概括的四大步骤,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 对项目的复盘分析

项目复盘的时间:最好在项目结束后的一个星期。这个时间节点,项目刚结束不久,参与项目的人员对项目各情况的印象还比较清楚,比较容易回忆。

项目复盘的参与人员:最好参与过项目的人都能参与进来,在项目开展过程承担关键角色的人员是必须要参与的,例如项目经理、产品经理、研发经理、运营经理等等。

项目复盘的提前准备:通知需参与会议的相关人员,让各自准备相关的材料、邀请一位复盘会议的引导者。

材料包含但不仅限:

  1. 文档:版本迭代记录、用户反馈记录等;
  2. 数据:过程中的数据、最终的数据等。

项目复盘的阶段流程

套用上面分享的四大步骤,对项目复盘分析的工作可分成以下3个步骤:

(1)对项目做整体的回顾

这一步将四大步骤中的(1)回顾目标和(2)评估结果进行了合并,从“起点”(目标)到“终点”(结果),对项目进行整体的回顾。

为了避免一上来就“唯结果论”,相互抢功或耍锅,开场应该相对轻松点,可以让大家先来聊聊对项目的理解:

  • 项目服务的对象是否符合项目定位的客户/用户?
  • 项目开展的过程中我们遇到了哪些机遇?什么挑战?
  • 项目取得的成果是否符合我们的期望值?好在哪?差在哪?
  • ……

(2)对关键事件进行回顾

项目的起止,有时间线,那自然就会对应有故事线。

过程中发生的各个关键事件,是影响项目运营和项目结果的重要因素,我们应当一一列举并分析。这时候让参与会议的人员提前准备,就很有意义了。

从项目立项开始画一条时间线,在时间线上标注出各个关键的节点,让所有人对应时间点,把自己印象深刻的、对项目当时有影响的事情写在便条上,然后贴上去。

便条需要讲清楚几点:当时发生了什么事,是怎么发生的,造成了什么问题,最后是怎么解决的。

(3)产出团队和个人收获

付出必然会有收获的(这不是一句毒鸡汤)。这里想说的收获,更多的是对人对事的收获。

还是那句话,项目的结果是既成的事实。结果有可能是不如预期的,有可能是刚好达到设想的,也有可能超出预期的,这始终不是关注的重点。

复盘的意义在于总结,找到对项目有贡献的人,肯定和学习ta;总结对项目有利的经验,校验然后放大它。

对人的部分,可以把项目关键角色的人头像贴出来或名字写出来,让大家把跟这个人合作的经历、感受和评价写下来,肯定ta过往对项目的贡献。

对经验的部分,可以从沟通、人员、流程和实践等方面进行收获总结。

2.2 对产品的复盘分析

对产品的复盘,更准确的说法,应该是对版本的复盘。

产品复盘的周期:这需要具体依据产品的版本迭代速度而定。一般是3个版本迭代完就应该进行一次产品复盘。

产品复盘的参与人员:参与版本设计、研发和运营的相关人员,例如产品经理、美术、研发、测试、运营、客服、商务等。

产品复盘的提前准备:通知需参与会议的相关人员,让各自准备相关的材料、邀请一位复盘会议的引导者。

材料包含但不仅限:

  1. 文档:版本迭代记录、需求管理表、需求文档、设计图稿、开发文档、测试用例、用户反馈记录等;
  2. 数据:版本迭代前一个周期的数据、版本迭代后一个周期的数据。

产品复盘的阶段流程

同样套用上面分享的四大步骤,对产品复盘分析的工作可分成以下4个步骤:

(1)回顾版本目标

依据准备好的版本迭代记录和需求管理表,先来回顾一下复盘版本的迭代内容,这些内容都是围绕什么重点/目标展开的,属于新增功能还是优化已有功能,这些功能点是服务于哪些人群的,他们的群体特征是什么样的,主要是想满足他们什么样的需求?表层需求是什么?底层需求又是什么?如何验证版本的效果?

所以这就要求我们接到需求后,要对需求进行足够的分析,在设计产品和规划版本的时候,要提前想好验证产品设计的方式,罗列出希望改善的数据/指标。它有可能是营收类指标比如订单金额,也可能是功能使用率的漏斗模型指标,或者用户好感度相关的指标等等。

(2)评估版本结果

用数据说话。将版本发布前后的两个周期进行对比,数据/指标上有哪些变化?版本面向用户的意见反馈怎么样?他们喜欢和认可新版本发布的内容吗?认为还有未被满足的需求吗?或者是还有期待被服务得更好的场景?

(3)分析关键环节

这一步,可以按产品开发生产线的各个节点划分为关键环节,依次可以划分为:需求——设计——开发——测试——上线。

A. 需求

这个环节,主要复盘的内容有以下几项:

  1. 需求对接:需求方的需求表述是否清楚?产品经理的需求分析是否准确?
  2. 需求定义:需求文档的输出是否完整清晰?设计师、交互师、开发、测试对需求是否了解?

产品经理需求方的对接:

需求变更:需求变更的次数是否频繁?存在需求变更影响到了版本进度?需求变更的原因是什么?需求变更后是否有对文档进行及时的更新?是否做好沟通工作,把需求变更的事宜清楚地传递给相关人员?

B. 设计

这个环节,主要复盘的内容有以下几项:

  1. 设计确认:是否有确定视觉设计的最终审核人?
  2. 设计标准:UI设计产出是否符合统一标准?
  3. 工期进度:产品设计工作在什么时候,由谁来完成的?设计工作是否影响开发工作的进度?影响原因是什么?

C. 开发

这个环节,主要复盘的内容有以下几项:

  1. 工期进度:开发实施前,是否有充分的时间做工期预估?工期预估与实际开发时间是否有差异,及差异原因分析。
  2. 开发文档:是否有撰写开发文档?开发文档是否符合规范?
  3. 突发状况:是否出现需求无法实现的状况?原因是什么?

是否出现团队成员变动情况?如何应对成员变动?后期如何避免?是否出现功能模块与需求不符的情况?出现原因是什么?

D.测试

这个环节,主要复盘的内容有以下几项:

  1. 测试计划:是否有完整、准确的测试用例?是否有一个测试计划?这样的计划是否有效?团队是如何测试并跟踪产品开发效果的?
  2. 测试工具:使用了哪些测试工具来帮助测试?是否可以持续使用?测试的时间、人力和软件/硬件资源是否足够?
  3. 测试结果:哪个功能模块产生的Bug最多,为什么?哪些BUG出现回滚,原因是什么?

E. 上线

这个环节,主要复盘的内容有以下几项:

  1. 版本验收:是否进行了正式的上线验收?在正式发布的过程中是否有出现状况?后续如何避免?是否检查了数据埋点,数据埋点是否满足要求?
  2. 上线通知:是否有通知到相关人员?上线前是否和运营、文案进行充分的沟通?
  3. 发版效果:在上线之后是否出现重大bug? 为什么测试阶段没有发现?产品上线后的问题反馈渠道是否流程?产品上线后收集到哪些问题反馈?都是什么类型?如何改进?

(4)总结版本经验

顺着产品开发生产线的各个关键节点逐一去反思总结存在的问题,得出版本迭代的经验:有哪些错误我们要去改正的?哪些情况可以去避免的?有哪些避免的措施可以做?哪些好的经验和配合我们要继续保持的?

2.3 对个人的复盘分析

同样套用上面分享的四大步骤,对个人复盘分析的工作可分成以下4个步骤:

(大白话的复盘思路就是:我是谁?做了什么?做得怎么样?还能不能更好?)

(1)自我定位

不要用类似“我是xxx项目xx产品的产品经理”这种简单的表述作为你的自我定位,这更准确的说法是“职位/title”,不能算“自我定位”。

试着去描述你在团队/项目中,承担着什么样的角色,这个角色存在的价值是什么?除了在企业的角度上看你作为产品经理的价值,更重要的是在你的理解下,你的价值是什么?你不可替代或难以替代的地方是什么?甚至都可以是你在承担这个角色时的人物性格、人格魅力的自我剖析。

假设Sue作为一名数据型的产品经理,除了负责数据采集、加工、分析;负责整个项目的数据平台搭建,还有应该做到充分理解平台项目业务,为业务增长和用户体验提供数据服务支持,很好地对数据进行应用与实践,优化产品策略和提高业务收入,实现数据驱动、数据赋能的价值。

(2)个人产出

根据自我定位的职责和价值,和你实际的产出进行对比,找出差距。

你在项目发展中,做了什么事情?这些事情对项目的推进有什么作用?

你在版本迭代中,做了什么事情?这些事情对产品的发展有什么影响?

你在整个团队中,贡献的价值是什么?有多大?

简单的说就是:你做了什么?结果怎么样?有哪些亮点?哪些不足?

(3)深入分析

对差距存在的原因进行反思和分析,取得成绩(亮点)的原因是什么?造成问题(不足)的原因是什么?

这里可提供几个参考角度:

  1. 依据差距去追查原因:对比往期结果、对比同行分析
  2. 分析原因时明辨内外:是自己的努力带来的?外在环境造成的?
  3. 厘清线索判定是否可控:可控?不可控?半可控?

 (4)总结成长

可以从以下几个方面,进行思考和总结,帮助自己更好的成长。

A. 工作流程

  • 需求方面:需求对接、需求管理、需求设计、需求评审。
  • 版本管理方面:周期确认、周期跟进、验收确认、跟进反馈。

B. 产品技能

  1. 流程梳理能力:业务流程、页面流程、涉及多角色的跨职能流程;
  2. 文档撰写能力:交互设计、页面布局设计、文字表述能力。

C. 工作习惯

  1. 是否养成记录工作日志的习惯?
  2. 是否养成定期体验产品的习惯?
  3. 是否养成关注行业动向的习惯?

产品经理是个综合性要求很强的职位,除了上面简单提到的几个方面外,还有很多需要不断学习的地方:类似企业经营、团队管理、运营推广等等。

以上,是Sue最近做自己所在项目的复盘分析以及个人的工作总结时,对“复盘分析”有了一些新的总结与思考,整理后与大家分享,希望有小伙伴一起交流学习。

项目具体的复盘分析不便分享,跟大家分享一下梳理的学习脑图(https://kdocs.cn/l/sRcLmnp5U?f=131

 

本文由 @素小白 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 目前还没评论,等你发挥!