编辑导语：一款产品从需求到落地需要经历什么样的流程？这篇文章通过积分管理的案例，梳理了完整的需求落地流程、各个角色负责的事务，以及各个环节中的难点。希望对大家有所帮助。

刚刚入行的产品新人在面试时，被问最多的一句话就是：一款产品从需求到落地需要经历什么样的流程？

通过网课和实习项目的学习，大部分人能够较为准确的回答出「需求收集-需求分析-方案设计-开发-跟进上线」这个最为核心的流程。但是当面试官再追问细节时，缺少丰富实战经验的新人就难以准确地进行回答。

背下这个流程或者按照这个流程直接执行似乎不难。但如果想要认真做好每一个环节，保证上线后的产品能够高度贴合用户的需求、对用户真正产生价值却是一个永恒的难题。

笔者经历过数十次迭代上线，其中有1-2周的优化版本，也有长达数月的大功能版本，也算是在当前阶段沉淀出了一些经验。

因此，本文希望能够结合理论和实践，通过一个容易理解的案例——积分管理来帮大家梳理完整的需求落地流程，并给出每个流程和环节中的重点和难点，帮助大家形成更为立体的认知、避免踩坑。

首先，我们来看看一次完整的迭代需要经历什么？

下图为一个相对较为通用的迭代流程（建议放大看）：

（常见的迭代流程图）

1. 业务：提出需求
2. 产品：需求调研&分析
3. 产品&UI：产品设计之后，产品输出PRD、设计输出UI稿
4. 产品&UI&研发&测试：产品主导需求评审，设计主导UI评审，研发和测试为参与方
5. 研发：进入开发
6. 测试：研发提测后进入测试环节
7. 运营：进行运营方案设计
8. 业务&产品：对开发出来的产品进行验收
9. 上线：由运维主导版本上线
10. 运营：产品上线后，运营方案上线
11. 项目复盘：整个迭代组进行项目复盘

上图清晰地描述了一次迭代流程中，对应的7个角色核心要做的事情。其中，灰色竖栏为产品需要主负责的，共包含5件事：需求调研&分析、产品设计、需求评审、验收及项目复盘。而其余5件事（提出需求、开发、测试、上线、运营方案设计&上线）则是产品需要跟进和关注的。

以上为一个较为通用的迭代流程，但由于各公司的业务、组织架构、团队规模等不同，部分流程可能会更简略或更细致。

例如，有些公司业务和产品均由产品经理来负责，产品经理需要自己主动收集需求并进行分析设计；而另外一些公司没有专门的运维岗，这个时候可能会选择用后端工程师来替代进行上线发布。

因此，我们看上面这张流程图时，不用纠结于公司是否有具体对应的岗位，而应该从该角色的职责范围来看，这样才能对各角色职责边界有更清晰的理解。

在掌握整个迭代框架后，下面我们从每一个具体的环节切入，来学习如何能够很好地将一个需求落地上线。

一、业务：提出需求

大厂一般都配备有业务部门，而规模稍小一些的公司或者个别行业可能就没有单独的业务部门。例如笔者所在的公司就没有单独业务部门，那么需求从哪里来呢？

因为笔者从事B端SaaS行业，其实是有相对明确的业务来源的，那就是公司的销售及售后部门。对B端产品而言，大部分的需求来自于销售和售后部门，其他则可能来自于客户、老板、竞品等。

第一步虽然是由业务方来提出需求，但通常，产品都需要提前制定相关的需求收集方式和模板，便于高效地收集到能够为自己所用的需求。

关于需求收集的方式，有些公司选择自建内部系统，有些公司选择使用现有的需求管理工具（例如禅道）。

而考虑到录入的方便、简单和可上手性，我们团队使用了腾讯文档-在线收集表（见下图）。销售和售后的同事在遇到需求时，可以直接填写该表。表格设计的很简单，但却包含了较为关键的信息。

（问题收集表）

填好之后，会在系统后台默认生成一个「问题池列表」，在那里就可以非常直观地查看和管理问题池内的所有需求了。

二、需求调研&分析

在完成第一步需求收集之后，我们在问题池中发现销售同事在售卖SaaS系统时，录入了这样一条需求：

问题标题：积分功能

问题描述：希望系统有积分功能，学生可以用积分抵扣学费

问题紧急程度：需7日内回复

客户希望达到的目的：想降低线下发积分卡和管理积分卡的成本

当前客户如何解决该问题：线下手动发积分卡片

（线下积分卡片）

那么，接下来我们就需要对这条需求进行调研和分析，了解客户为什么要该功能，具体想做成什么样子。

1. 调研

在一次迭代中，常见的调研包含行业调研、竞品调研和客户调研这3种。

关于行业调研，大家可以通过如下3种方式进行长期的积累：

• 艾瑞咨询、IT桔子等各类行业报告平台的调研报告
• 加入行业社群
• 关注行业自媒体，如公众号、知乎大v等
• 阅读行业相关书籍

行业调研是一个需要长期投入和关注的长线工程，虽然有些迭代会包含一部分行业调研，但主要还是以竞品调研和客户调研为主。因此，这里我们不展开看行业调研，而是以竞品和客户调研为主。

（1）客户调研

这里再着重强调一些客户调研核心关注的相关内容。客户调研的本质，就是在反复沟通中明确需求的核心3要素：用户、场景、目标。

那么将其代入到积分管理的例子中，我们就需要弄清楚：

• 什么人要用到积分？
• 这些人在什么场景下会用积分？
• 他们的目标是什么？

在明确调研方向之后，就可以选用相对合理的调研方式了，例如问卷、一对一访谈、现场观察等。

问卷适用于有一定的用户规模、调研深度较浅的需求，虽然节约时间但效果容易被问卷设计所干扰；一对一访谈和现场观察适用于更为深入和直接的调研，成本高但调研效果更为可靠。

（2）竞品调研

经常会有人问「如何做好一次竞品调研」，这个问题的范围其实很大。因为，只给出竞品这一个关键词，是很难框定竞品调研的目标和范围的。

就像leader命令你去调研一个人，在没有任何调研目的的情况下，其实是很难聚焦来得到有效结论的。「人」和「竞品」一样，都是对象，因此，竞品调研的关键点就在于竞品调研的目的！只有明确了目的，才能清楚的框定范围、选择合适的调研内容和方式。

那么，对于一次迭代而言，竞品调研的主要对象就是一个明确的功能或者业务，目标就是明确竞品是否有实现这个需求？实现了哪些？实现到了什么程度？

以积分管理为例，下图为一张竞品积分功能对比的简单清单，供大家参考：

（竞品功能对比清单）

竞品调研已经有非常成熟的方法体系了，鉴于篇幅，这里不展开讨论。除了上述内容之外，再和大家分享2个非常重要的点：

第一，在看竞品实现之前，提前思考自己会怎么做。

当我们直接打开竞品开始体验，会先入为主的接收到很多信息，并且会将很多细节自然地忽略掉。这其实会阻碍我们很好地把握竞品的调性和设计目的。

笔者的大哥曾经教过我这样一个很实用的办法：那就是打开竞品之前，提前想想自己会怎么做。思考半个小时后再简单画一个模型或图。随后，拿着自己的图去和竞品做对照，这样就能够非常有效的关注到差异点。

例如，客户有积分管理的需求，那我们先将业务拆分为获取、消耗和规则这3大需求，在满足客户核心场景的基础上没有太多延伸。

拿着这个思维导图的框架，我们再去对照竞品，看它做了哪些、哪些没做，并猜测对方的出发点是什么。

例如下图，我们发现竞品额外还做了礼品兑换的功能。

这个时候，我们就发现竞品有一个和自己预想不一样的功能点：为什么竞品的积分功能还支持做礼品兑换呢？

此时，我们就可以回过头来想想：是因为自己对场景了解不充分，客户有这样的需求，自己却没有了解到？还是因为对方希望引导客户去进行礼品兑换，从而通过提供商品购买渠道来增加变现方式呢？

经过这样的对比和冲突，才会让我们对竞争对手的思考更加集中和聚焦。

第二，关注竞品和自身在该功能上的竞争力对比

竞品调研时，我们很容易陷入功能和交互，忽略了背后的竞争力。

当我们的功能真的投入到市场接收客户的考验时，产品功能的完整性、覆盖度，各个功能的竞争力、短板和优势都会被客户拿到一起来进行赤裸裸地对比。

而如果我们在做竞品调研时，只考虑看对方的实现，没有关注竞手对该功能的宣传口径以及竞争力时，可能某种程度上会做出缺少竞争力的产品。当销售和售后部门去进行售卖和续费时，也难以给出能够打动客户的优势点。

当然，一个saas产品卖的好坏并不只是因为产品的竞争力，某种程度上也取决于公司的客户资源、行业地位等等。但是对于产品经理而言，做好自己份内之事，积少成多，某种程度上也能带来持续而稳定的影响。

2. 分析

虽然在调研过程中，我们也会随着调研的结果产生各种碎片化的思考。但这里的分析则指的是在调研结束之后，将全部信息进行统一整合、整合后再通过思考提炼得出结论的过程。

最近在看《人人都是产品经理3.0》，里面提到了需求分为一手需求/二手需求，以及直接需求/间接需求，其实也就引出了笔者在这里想说的点：在真正分析开始之前，先要对用户的描述打破砂锅问到底，明确真实的信息，减少信息熵。

例如，客户说“我想要一个积分功能，我看其他门店都有，自己没有就落后了”。这类表述对我们想要明确积分功能本身的价值没有太多帮助，顶多让我们知道积分已经变成了一个相对比较普遍的营销方式。

因此，我们还需要继续追问客户：如果你们自己有了这个积分之后，会考虑拿来怎么用呢？只有不断地追问客户5个w，才能从客户那里挖掘到真正的需求。

在客户调研中，最大的坑就是还没弄明白真正的需求，就直接按照表面需求或者二手需求开始设计方案了。

以积分管理功能为例，我们通过数十份客户电话访谈，归类得到了客户想要积分功能的几大原因：

• 想通过出勤发积分，提升机构出勤和课消率
• 想通过一些活动发积分，促进家校互动和沟通
• 想通过积分抵扣学费，促进家长续报的积极性

然后，再根据上述调研结果给客户的出发点做一个整理和优先级的排序。在整理后我们发现：促进出勤和课消是80%客户的需求，促进续报有60%机构都需要，而促进家校互动只有10%。

那么，我们便可以得出一个初步的结论：大部分机构使用积分功能主要用来促进营收，而出勤获得积分和续报抵扣积分是2个需要重点满足的核心场景。

接下来，我们需要把客户使用积分的场景整理出来。便于在需求评审时，和整个团队讲清楚需求的背景和满足的场景。同时，再结合与竞品的对比，确认我们是否需要在这个方面投入更多的资源来提升竞争力，还是暂时持平即可、把资源投入其他方面的建设上去。

三、产品设计

如何把用户的需求从一个清单list变成一个有样式交互、有业务逻辑的完整PRD，并不是掌握了画原型的技巧那么简单的事情。

在笔者刚刚开始从事产品时，每次分析需求，都需要先手绘一张原型稿出来。只有看着原型稿，才知道怎么样去倒推需求背后的逻辑，否则大脑就是一片空白。

但慢慢随着经验的增长，现在，基本能够脱离对原型稿的依赖，先考虑场景和业务逻辑。在完整的梳理完业务逻辑后，再开始考虑样式和交互的具体实现。

那么，一个相对通用的产品设计流程应该是怎样的呢？

其实整个产品设计流程和需求评审是高度结合的，因为需求评审就是不同阶段产品设计成果的里程碑。

在笔者此前写过的需求评审文档中，详细介绍了需求评审的3个阶段：范围评审、低保真评审、方案评审。相应的，PRD的落地过程也需要对应分为3个阶段：需求范围稿、低保真稿、最终方案稿。

1. 需求范围稿

首先，我们需要和团队明确想做哪些东西、大致优先级是怎样的，即定义好需求的边界和优先级。

根据前述的调研，我们能够基本对客户的需求和竞手对该需求的满足情况有一个大致的了解。综合各方面的信息后列出一个简单的需求范围和优先级。

如下图所示，这是一个简单积分管理的需求清单：

（需求清单）

关于优先级的制定，网上也有非常多的方法：有使用KANO（基本型、期望型、兴奋型）进行大致归类判断的，也有各类按照公式进行精准计算的。但对于刚入门的产品而言，能够基本按照KANO模型和重要/紧急四象限去进行区分就已经足够了。

（网图，图源见水印）

举个例子，在本次积分管理中，能够按照学员出勤情况自动为其进行加分属于基本型需求，这是客户需要该功能的核心场景。

而得来的积分能够再用于在线上兑换礼品，则属于期望型需求。这类需求越多越好，能够有效促进学员获得积分的积极性。

而如果该学员长期没有出勤，系统能够自动告诉该学员：因为没有出勤，你有190个积分即将流失。通过这种自动提醒方式，有效唤醒学员出勤。那么，这将会是一种超出客户意料之外的兴奋型需求，因为系统具备了一定的智能召回能力。

当然，一个需求的优先级绝不仅仅局限于需求本身，可能还关联到该需求的实现成本、商业价值等。

比如，虽然客户认为该需求非常紧急和重要，但实现成本极高；又比如，有甲方爸爸说加重金必须要实现某一个性化功能。当遇到这两种情况后，某种程度上，我们的需求优先级就会受到一定影响。

但是对于新人而言，判断需求本身的业务价值是最重要和核心的能力，所以这里暂时只和大家提及这一点。

综上，我们在需求调研&分析阶段得出了含有优先级的需求清单。接下来，我们就要按照这个需求清单进行下一步的设计了。

2. 低保真稿

在低保真稿中，我们需要确定业务核心的逻辑、流程、交互和样式。

（1）核心业务逻辑

核心业务逻辑指我们需要找出功能中涉及到的实体有哪些、实体关系如何，当需要设计表时，表字段应该包含哪些等等。

例如，在积分管理的业务中，学员、校区和积分账户的关系就可以列出至少如下3种方式。

现在看起来，似乎不同的方式没有太大区别。但是如果实体关系和表结构没有设计好，后期就很难在此基础上进行业务的更新和优化了，甚至会有可能导致重构。

（2）核心流程

在理清楚实体及实体关系后，我们就可以开始来梳理整个业务的核心流程了。

在积分管理中，有加积分流程、扣积分流程、积分规则配置流程等等，我们以下图最为简化的加积分流程为例：

通过这张图，我们就能很清晰的了解：完成一次加积分大致需要经过哪些步骤，需要哪些前置数据，最终一系列操作完成后，又会产生哪些数据。

这样，我们就能对整个积分业务中的核心路径有了很好的把握，同时也能关注到信息和数据的流转。

（3）核心交互和样式

相较于C端产品，B端产品会更关注业务逻辑和功能易用性。而页面交互往往都会倾向于使用通用的框架。

因此，在设计交互和样式时，B端产品经理最主要的是需要熟知团队内部是否有统一的组件和交互。如果有，需要尽量去遵循已有组件。

同时，也需要熟知市面上常见的一些交互框架，例如Ant Design、Material Design等等。这些交互框架能够有效提升我们画原型的效率。

当然，并不是不鼓励创新。只是说对于B端产品而言，某种程度上，能帮助客户把事情高效办成才是最重要的事情，而常见的交互样式框架某种程度上也降低了用户的学习成本，使他们能够花更多的精力专注在完成任务上面。

例如，下图就是在设置加分规则时的一个低保真页面。页面的tab式导航、按钮位置、表格样式、表头内筛选都是遵照了团队的统一交互。那么，后续UI基本不需要重新出图，而前端也可以直接引用团队现有的组件进行快速实现。

此外，新人都十分关注交互的实现，好像实现了一个很酷炫的交互是一件很有成就感的事情。虽然也存在部分公司要靠成熟可交互的产品demo去谈项目，但大部分B端产品的交互都十分简单。个人建议不必要花太多心思去学习axure、墨刀这类软件上的交互部分，掌握基础交互即可。

3. 最终方案稿

在完成了核心逻辑、流程、样式和交互之后，最终方案稿就是在补全其他场景的内容。

例如，在上一步骤低保真稿中，我们在积分设置中出现了积分规则的列表和新增加分规则的按钮。那么，在方案评审稿中，我们就需要明确写出列表和按钮的对应相关逻辑，便于研发可以直接拿来开发。

如下图所示，就是一个加分规则列表的逻辑和交互说明：

到了这一步，我们基本就结束了产品设计这一阶段的全部工作。

四、项目管理（开发&测试&验收）

在完成最终一次的需求评审之后，产品就可以短暂的舒一口气了，因为剩下的主要工作将由研发和测试来完成。

那研发和测试具体都在这段时间做什么呢？

对于没有技术经验的笔者而言，刚入行产品时，就一直觉得研发的工作像一个黑盒：扔进去需求文档，过一段时间就收获了可使用的功能。但其实随着经验的增长，了解完整的研发过程是很有必要的。

下图就描述了一个常见的从开发到上线的过程（感谢研发&测试同事们提供的素材）：

通过这张图，我们能很清晰地看出每个角色在其中的工作职责：

前后端需要评估&阅读需求、技术方案设计、技术方案评审、排期、开发和代码审查、联调、提测以及解bug。

测试需要阅读&评估需求、设计测试用例、评审测试用例、冒烟测试、正式测试、确认达到初步上线标准、输出测试报告。

运维需要准备发布环境、检查发布环境，并负责发布上线（如果你对上述专业技术词汇不甚熟悉，建议善用搜索，或不妨直接找关系还不错的技术同学请杯奶茶聊一聊～）。

上面说了研发测试的核心工作，那在这个期间，产品就闲着摸鱼什么事都没有了吗？

那肯定不会。

在研发埋头苦干期间，产品需要对整个迭代进行项目管理。同时，当研发出现需求疑问时，需要及时给予需求澄清和解答；当然，产品需求文档也不能保证100%正确，当自己有需求bug时，也要配合测试进行处理。

在这几件事中，最核心的就是进行项目管理。

首先，一次迭代本质上是一个项目，即一个需要在固定时间内按照明确标准进行交付的工程。而产品经理除了自身进行需求调研和产品设计之外，还要肩负项目经理的工作，即管控整个迭代。

而大多数产品在最开始做迭代的时候，其实是缺少项目管理知识和经验的。因此，我们需要先建立对一个迭代（项目）的完整认知，了解到一个迭代到底需要从哪些地方进行关注、形成项目管理的框架、有更全面和宏观的视野；之后再对我们需要做的事情进行一步步案例拆解。

那么，理论篇我们就引入项目管理中2个非常熟知的理论框架：PDCA戴明环和项目管理理论中的十大管理。

1. PDCA戴明环

在笔者刚刚自学转行产品经理时，就常常听说PDCA这样一种思想，这也是相对很好入门的一种项目管理思路。

• P=plan
• D=do
• C=check
• A=action

首先做一件事，我们要有计划性plan、做好计划后开始执行do、执行完成后时刻进行检查check、检查复盘后若有问题，则持续的进行改进act。

这就和我们要减肥是一样的，为了要减肥我要做哪些健身计划，做好计划后就开始按照计划执行。执行一段时间后回过头来看看效果怎么样，如果减肥反而越减越肥，那就该找找问题看看怎么样去优化了。

PDCA看起来就是简单的4个动作，但代入到迭代来看，其中其实蕴含了3层大部分人都做不到的简单道理：

1. 凡事要有计划性。迭代开始之前，需要有明确的目标、行动、衡量，在做事之前如果能够想清楚计划，那么也就成功了一半；
2. 迭代上线后不能就扔在那里不管了，而需要及时进行复盘和检查。当发现问题后，也要行动起来进行优化。很多产品新人做迭代，方案设计好或者上线之后就不管了，这其实是一种思维和行动懒惰的表现；
3. PDCA是一个循环，强调我们不仅要把这个事情按照PDCA做完，还要持续的去循环这4个动作，才能不断地进行优化和提升。这是戴明环对于迭代的一个非常重要的指导思想。

2. 十大管理

笔者之前考过软考系统高级项目管理师，其实考试是一个借机学习项目管理知识很好的方式。

在没有学习系统的项目管理知识之前，其实对一个迭代的认知是非常窄的：只会关注用户的需求是什么、bug多不多能不能最终上线，只关注「需求-功能-实现」这一条单线程的管理。

而在学完项目十大管理之后，笔者发现自己看待整个项目的视角立体了很多。

例如，会开始关注研发同事的人员流动大不大，会不会有人力风险，也会去关注某个需求的实现成本，而不是一味任性的说“我不管，这个需求必须要做”。

那么十大管理都指哪几个方面呢？

十大管理包含整体管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、干系人管理。

（网图，图源见水印）

这里不展开细讲，感兴趣的同学可以直接搜索「十大管理」关键词进行详细了解。

十大管理中，我们最常关注的是时间管理、成本管理、人力资源管理和质量管理，最容易忽略的是沟通管理、风险管理和干系人管理。

为什么沟通、风险和干系人管理是比较容易忽视的呢？这是因为相较于范围、时间、成本等，后面的沟通、风险和干系人一般都比较隐性，不会非常直接的影响上线，但却很容易埋下大坑，一旦积攒到某一时刻就会爆发，从而影响整个迭代。

所以，当我们学习了十大管理的知识之后，就能够跳出产品和需求的单一视角，从整个项目的多个维度去看待一次迭代，也能够在一定程度上更大地提升迭代的成功率和团队合作的效率。

通过上述的理论学习，我们对项目管理有了一个初步的框架。那么，下面我们就来具体说说怎么进行项目管理。

3. 项目管理流程

那么，要做好一次迭代的项目管理，应该按照什么样的步骤去展开呢？

其实这里还是以PDCA戴明环的4个步骤为主，其中因为产品偏向于管理，因此更多以plan、check和act为主。

（1）整体计划

有计划才能识别变化，因此，在开发开始之前，我们就要列出一个明确的迭代计划。计划的内容需要包含项目基本情况、项目描述、项目里程碑计划、评价标准、项目假定与约束条件、项目主要利益干系人等。

（表格来自华为项目管理10大模板）

在列出基本策划之后，我们对整个项目就有了一个大致的框架，同时也有了明确清晰的评价标准。接下来，就要进行进度方面的监控了。

下图是一个简单的甘特图，用于进行进度管理和风险预估。通过这张表，我们就能很清晰的核对出项目的进度，大致哪个环节出现了问题、哪个环节未来可能会出现风险。当我们找到问题后，就能够进行跟进和问题处理了。

（表格来自华为项目管理10大模板）

例如，后端同事在开发某一个模块时，因为家里有事要请假1周，为了保证按时上线，是选择临时借调其他项目组的后端来顶替，还是等该同事回来之后再加班处理？这些处理方案没有绝对正确，都需要依照具体的项目和业务来进行处理。

当然，刚刚入门的新人都缺乏一定的跨部门协作经验，不要担心，作为过来人，笔者在这里给你2个衷心的建议：

1. 产品需要对结果负责。因此，需要积极主动去帮助解决灰色地带的问题，不要遇事就甩锅。
2. 先自己独立思考处理方式，思考后再和直系leader或者同部门同事请教。这样，既能保证自己有一定思考有所成长，也能与内部同事核对之后再对外协作和处理，让事情处理的更「漂亮」一些。

当然，在上线之前，整个PCA都会是一个持续循环的3个动作。

上线，是一个特别令人激动和紧张的时刻，也是功能第一次真正面向客户投入市场的一个终极里程碑。稍微成熟一点的公司一般都会有对应的上线检查表，这里也给出一个简单的参考，但具体上线的检查清单要根据具体的业务来。

（图源邱岳《产品训练营》）

五、项目复盘

还记得我们前面说过「千万不能上线后就不管了」，一个负责的产品经理既要管生，也要管养。当然，不一定全盘都是自己养，但是一定要注意跟进和复盘。

下图为《复盘》这本书中给出的复盘模板，我们自己团队也在使用该模板进行复盘：

（《复盘》书中提供的复盘模板）

上线后的项目复盘应该分为2个方面，第一类是项目本身进行复盘，第二类是产品复盘。

项目复盘更关注过程，即我们要对团队内每个人的工作效率/质量、互相之间的协作等整个项目进行复盘。而产品复盘则更关注结果和价值，指我们要对上线功能的可用性、实际产生的价值等进行复盘。

对于B端产品而言，功能反馈不一定非常及时，因为系统内大部分功能都是没有人在用的。因此，一般需要等2-4周再进行数据的收集，而数据收集的方式分为埋点和回访2类，这和我们去进行客户调研的方法是有些类似的。

下图是积分管理功能中，真实的一次产品设计组项目复盘的内容截图：

（项目复盘截图）

在这次积分迭代中，产品和UI组分别就目标和结果做了对照评估，并从中提炼出了出现问题的关键原因，同时也给出了后续的行动计划。

当然，本处只有产品和设计部门的复盘内容，整个参与迭代的前端、后端、测试等都需要分别列出自己的复盘内容，并由产品组织在项目复盘会上统一进行交流。

通过这样一个成体系的复盘思考，能够让我们不仅仅完成了眼前的迭代，还能在同样时间的项目经验里收获成倍的经验，从而在未来的迭代中举一反三。

以上就是一个完整的需求迭代过程了，我们再来回顾一下。整个需求迭代的参与角色包含业务、产品、研发、测试和运营。产品经理主要负责产品设计和项目管理2大方面，包含需求调研分析、产品设计、需求评审、验收和项目复盘。

最后，在文中也穿插了非常多的难点和避坑点提醒，这些都是笔者的血泪史～相信读完本文的你，已经对一次迭代建立了较为完整而全面的认知框架，也同时掌握了足够落地的技巧和方法，那就快去实战操练下吧！

作者：冰冰酱；公众号：setmefree

本文由 @冰冰酱 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议