惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
WordPress大学
WordPress大学
T
Tailwind CSS Blog
V
Visual Studio Blog
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Last Week in AI
Last Week in AI
阮一峰的网络日志
阮一峰的网络日志
量子位
有赞技术团队
有赞技术团队
酷 壳 – CoolShell
酷 壳 – CoolShell
Apple Machine Learning Research
Apple Machine Learning Research
博客园_首页
Jina AI
Jina AI
雷峰网
雷峰网
博客园 - 【当耐特】
博客园 - 叶小钗
美团技术团队
宝玉的分享
宝玉的分享
IT之家
IT之家

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品上线后如何进行复盘?
成于念 · 2025-01-21 · via 人人都是产品经理

本文从目标完成度、计划执行情况、资源协调、变更管理、设计到编码、测试到发布以及团队协作等多个维度,详细梳理了产品上线后复盘的重点问题。通过这些问题,项目组成员可以深入思考并交流,将复盘转化为持续改进的动力,为后续的产品优化和团队协作提供有力支持。

我们在进行系统建设或者产品研发的过程中,经历了测试特别是UAT测试后,需要阶段性的对需求开发全过程进行复盘,特别是大型项目而言,因为后续还有历史数据处理,正式上线全员培训,二次优化等工作,复盘总结有利于发现当前阶段出现的问题或者多次返工、阻断性问题等等。避免下一个阶段出现类似的错误,能进一步提升效率。

在复盘前,PM要充分动员项目组的所有成员,包括参与的业务部门、项目组、产品组、开发组、测试组等等。一定是围绕目标达成度、计划执行情况、资源协调情况、变更管理、从设计到编码、从测试到发布以及团队协作等方面设置问题,并提前发送给团队成员,以收集大家的反馈。

这里主要总结一些我们需要重点关注,复盘的问题。围绕这些问题,我们需要每一个项目组成员去进行复盘思考,把做得好的,做得不好的,都能提出来进行沟通交流。具体包括且不限于以下问题:

【目标完成度】:

1. 我们的产品旨在解决哪些问题?这些问题的定义是否清晰明确?对于典型用户和典型场景的描述是否足够清晰?

2. 我们是否达成了既定目标?原计划的功能实现了多少?是否按照原计划的交付时间准时交付?

3. 用户量以及用户对关键功能的接受程度与我们事先的预期是否相符?我们距离目标更近了还是更远了?(此问题需上线后观察再作答)

【计划执行情况】:

1. 在开发前,是否预留了充足的时间来制定计划?

2. 在计划阶段,团队是怎样解决成员间对于计划的不同意见的?

3. 你原计划的工作是否全部完成?若未完成,原因是什么?

4. 有没有发现自己做了一些事后看来毫无必要或价值不大的工作?

5. 每一项产品需求是否都有明确的定义和可衡量的交付成果?

6. 项目的整个过程是否都严格按照计划进行?期间出现了哪些意外情况?有哪些风险在当时未被预估到?为何会出现这种情况?

7. 在计划中是否设置了缓冲区?缓冲区起到了实际作用吗?

8. 未来的计划需要做出哪些调整和修改?

【资源协调情况】:

1. 我们是否拥有足够的资源来确保项目的顺利完成?

2. 项目所需的时间以及其他资源是如何进行预估的?预估的精度如何?

3. 测试所需的时间、人力以及软件/硬件资源是否充足?对于那些非编程类的资源(如产品、设计、文案、运营策略等),是否低估了其难度?

4. 你是否觉得自己所做的某些工作可以由他人来完成,且效率会更高?

【变更管理】:

1. 需求是否发生了变更?变更的次数是多少?每次变更的具体原因是什么?

2. 当需求变更时,是否所有相关员工都能及时获取变更的消息?

3. 针对每次变更,我们采取了何种决策方式,是选择“推迟”还是“必须实现”?

4. 变更的出口条件(即怎样才算“改好了”)是否有清晰明确的定义?

5. 对于可能出现的变更,是否能够提前制定相应的应急计划?

6. 员工能否有效地应对意料之外的工作变更?

【从设计到编码】:

1. 产品设计工作是在何时、由何人完成的?时间和人员的安排是否恰当合理?

2. 产品设计过程中是否遇到过模糊不清的情况?团队是如何解决这些问题的?

3. 团队在编码过程中是否运用了单元测试、测试驱动开发、UML、LINT等工具?这些工具的实际效果如何?

4. 哪些功能在测试过程中出现的bug最多?导致这种情况的原因是什么?

5. 在产品发布后,发现了哪些重要的bug?为何在设计和开发阶段没有预见到这些情况?(此问题需上线后观察再作答)

6. 代码走查是如何开展的?是否严格执行了代码规范?

【从测试到发布】:

1. 团队是否制定了测试计划?该计划的实际效果如何?

2. 是否进行了正式的验收测试?

3. 团队是否使用了测试工具来辅助测试?其效果怎样?

4. 团队是通过何种方式测试并跟踪产品开发效果的?从软件的实际运行结果来看,这些测试工作是否有效?存在哪些需要改进的地方?

5. 在发布过程中出现了哪些意外情况?是如何解决的?今后应如何避免类似情况的再次发生?

【团队协作】:

1. 团队中每个角色是如何确定的?是否做到了人尽其才?

2. 在项目执行过程中,团队成员是否发生了变更?变更是否引发了问题?如果有,是如何解决的?

3. 团队成员之间是否相互协助?

4. 当出现需求描述、项目管理以及合作方面的问题时,团队成员是如何解决的?

当然上述的问题,不一定都需要每个人回答。我们可以根据项目的自身特点,或者产品系统的研发流程等等,去进行调整。

例如,我们在进行产品研发的过程中,会单独对产品组的同事进行一个小范围的复盘。我们会列出相应的问题,由各个产品经理进行复盘,并将复盘的内容与项目组、研发、测试不同角色进行分享,这样才能有效的拉通各个角色分工,让不同角色的同事明白自己的工作存在哪些缺漏或者值得提升的地方。

本文由人人都是产品经理作者【老司机聊数据】,微信公众号:【老司机聊数据】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。