产品之道——不复盘,不成长

2019-10-07277

复盘的背景

“复盘”这个词最早来自棋类术语,也成“复局”,指对局完毕后,复演该盘棋的记录,以检查对局中对弈者的优劣与得失关键,有效地加深对这盘对弈的印象,也可以找出双方攻守的漏洞。

复盘的定义

  • 简单说就是回放过去,反思不足,总结经验,复用未来;
  • 把过去好的留下来,整理成规范、体系,服务现在和未来;

复盘的价值

  • 站在巨人的肩膀上;
  • 少走弯路,少踩坑;
  • 把经验转化为能力;
  • 不重复交学费,降低学习/工作/试错的成本;
  • 做更好的自己(革过去自己的命);
  • 站在今天看昨天,看昨天干得漂亮的活,今天漂亮的干活,让明天活得漂亮。

复盘的类型和特性(时间维度、用户属性)

  • 日会-晨会(吾日三省吾身、及时反省和调整、适用个人);
  • 月复-月会(小型项目或团队、阶段性调整、适用个人或团队);
  • 季度复-季度会(中型项目或团队、阶段性调整、适用团队和公司)
  • 年复-年会(大型项目或团队、阶段性调整、适用团队和公司)
  • 公司和用户/加盟商/客户(粉丝)的交流会/年会/生日会(开放参与对象 | 让用户参与进来,倾听用户心声,挖掘潜在需求和痛点,吸收用户端的建议和创意,调整公司市场战略和产品战略)。

复盘的执行(如何把复盘做好)

  • 复盘会议邀请(负责人 | 复盘目标、参与成员)
  • 复盘内容准备(参与全员 | 过去做的事情,拿的目标结果(定性和定量的数据)、找到捷径的经验分享、挖/踩到坑的反思、未来的规划、个人成长)
  • 复盘内容分享(全员)
  • 复盘内容提问、回答、讨论(全员
  • 复盘点评、整理(负责人 | 发现/优化团队长板)
  • 复盘总结内容、笔记共享(全员 | 知识库、成长体系文档)

常见复盘角度

四部曲复盘法

  • 第一步:回顾目标

    1. 当初行动的目的和意图是什么?
    2. 时间或行动想要达到的目标是什么?
    3. 预先制定的计划是什么?
    4. 事先设想要发生的事情是什么
  • 第二步:评估结果

    1. 实际上发生了什么事?
    2. 在什么情况下?是怎么发生的?
    3. 与目标相比,哪些地方做的好?
    4. 哪些地方未达到预期?
  • 第三步:分析原因

    1. 实际情况与预期有无差异?
    2. 如有,为什么会发生这些差异?
    3. 哪些因素导致未达到预期目标?
    4. 失败的根本原因是什么?
    5. 如无,成功的关键要素是什么?
  • 第四步:总结经验

    1. 在过程中学到什么新东西?
    2. 有人进行同样行动,有啥建议?
    3. 接下来该做些什么?
    4. 哪些是可以直接行动的?
    5. 哪些是其它层级才能处理的?
    6. 是否要向上呈报?
  • 复盘结论判断

    1. 是否排除了偶发因素?
    2. 是否具有普遍性?个例?
    3. 结论指向人还是指向事?
    4. 是否经过三次以上追问为什么?
    5. 是否有类似事件的复盘结果?
    6. 是否可以交叉验证?
  • 行动

    1. 开始做什么?
    2. 继续做什么?
    3. 停止做什么?

常见项目复盘提纲

  1. 目标达成度
    • 我们的产品要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
    • 我们达到目标了么?(原计划的功能做到了几个?按照原计划交付时间交付了么?)
    • 用户量,用户对重要功能的接受程度和我们实现的预想一致么?我们离目标更近了么?(需要上线后观察再回答)
  2. 计划执行情况
    • 开发前,是否有充足的时间来做计划?
    • 团队在计划阶段如何解决同事们对于计划的不同意见的?
    • 你原计划的工作是否最后都做完了?如果由没做完的,为什么?
    • 有没有发现你做了一些时候看来没必要或没多大价值的事?
    • 是否每一项产品需求都有清晰定义和衡量的交付成果?
    • 是否项目的整个计划都按计划进行?项目出了什么意外?有什么风险是当时没有预估到的?为什么没有预估到
    • 在计划中有没有留下缓冲区,缓冲区有作用吗?
    • 将来的计划会做什么修改?
  3. 资源协调情况
    • 我们有足够的资源来完成这个项目吗?
    • 项目所需时间和其他资源是如何估计的?精度如何?
    • 测试的时间、人力和软件/硬件资源是否足够?对于那些不需要编程的资源(产品设计/文案/运营策略)是否低估了难度?
    • 你有没有感到你做的事情可以让别人来做(更有效女)?
  4. 变更管理
    • 是否存在需求变更?变更了几次?每次变更的原因是什么?
    • 需求变更时,是否每个相关的员工都及时知道了变更的消息?
    • 我们采用什么方法来决定每次变更,是“推迟”还是“必须实现”?
    • 变更的出口条件(也就是什么叫“改好了”)有清晰的定义吗?
    • 对于可能的变更是否提前制定应急计划?
    • 员工是否能够有效地处理意料之外的工作变更?
  5. 从设计到开发
    • 产品设计工作在什么时候,由谁来完成?是合适的时间、合适的人么?
    • 产品设计工作有没有碰到模棱两可的情况,团队是如何解决的?
    • 团队是否运用单元测试(Unit Test),测试驱动开发(TDD)、UML、LINT或其他工具来帮助编码?这些工具有效么?
    • 什么功能产生的BUG最多,为什么?
    • 在发布之后发现了什么重要的BUG?为什么我们在设计/开发的时候没有想到这些情况?(需要上线后观察再回答)
    • 代码走查(Code Review)是如何进行的?是否严格执行了代码规范?
  6. 从测试到发布
    • 团队是否有一个测试计划?这样的计划是否有效?
    • 是否进行了正式的验收测试?
    • 团队是否有测试工具来帮助测试?效果如何?
    • 团队是如何测试并跟踪产品开发效果的?从产品实际运行的结果来看,这些测试工具有用吗?应该有哪些改进?
    • 在发布的过程中发现了哪些意外问题?如何解决的,后续如何避免?
  7. 团队协作
    • 团队的每个角色是如何确定的,是不是人尽其才?
    • 项目执行过程中是否有团队成员并更?变更是否带来问题?是如何解决的?
    • 团队成员之间有互相帮助吗?
    • 当出现需求描述、项目管理、合作方面的问题时,团队成员如何解决问题?
  8. 总结
    • 关于以上问题,有什么经验教训?如果历史重来一遍,我们会做什么改进?
    • 你觉得团队目前处于“萌芽/磨合/规范/创造”阶段的哪一个阶段?为什么?
    • 你觉得团队在这个项目相比前一个项目有什么改进吗?
    • 你觉得目前最需要改进的一个方面是什么?

按照流程的复盘

  1. 项目的出发点:需求目的是否准确,回头来看对问题的分析准不准确
  2. 项目的解决思路:当时为什么按照这个思路来设计,现在来看,是否有更好的解决思路
  3. 设计细节:规则和流程设计上有没有漏洞?有没有优化的空间让效果更好?当时为什么没有发现这些?
  4. 项目管理和执行:人员安排上有没有不足?数据需求是否确认好?沟通协调是否有不足?是否延期及原因;
  5. 数据表现分析:是否达到预期?没有的话是主观原因还是客观原因?下一步如何做?继续尝试还是放弃
分享
点赞1
打赏
上一篇:2018年,我们该如何看待微信小程序?
下一篇:产品定位:深入挖掘真实需求