一、前言

现在绝大多数的团队都在拥抱敏捷，我经历过的公司大多数也都遵循敏捷的软件开发流程。今天就来聊一聊敏捷框架中产品经理的工作流程，主要包括产品设计工作流程、研发工作流程以及迭代流程。

二、产品设计工作流程

（一）需求收集

产品经理一切工作的起始点是需求收集。需求的来源很多，比较常见的有公司战略规划、竞品分析、合作方需求、数据分析得到的需求、用户反馈的需求等。产品经理这一阶段的重点就是将业务方主动提出的，以及自己主动收集的所有需求录进业务需求池（特别重要的，具有计划性质的需求很多时候会体现的员工及员工领导的OKR或绩效上）。

这一阶段追求的是需求的真实性、准确性，因此产品经理要深入的和业务方进行需求的沟通，避免遗漏关键信息。最后，最好是由需求方按照一定的内容要求将需求录入需求池。

最终需求池里的需求由对应产品经理负责，并向业务方、公司领导等相关人员开放，方便干系人随时查看需求的进度。

（二）产品迭代规划

每一个收集到的需求都需通过简要的分析，综合工作量、价值高低、紧急程度等因素判断产品的优先级，最终基于所有待处理需求的优先级以及研发团队的资源情况初步决定本次迭代需求的范围。

需要注意的是，如果规划的需求中存在不确定性较高的需求，需要先对需求做概要设计，否则后续的需求范围评审阶段你的同事无法进行有效的评审。如果短时间内没有办法给出需求的概要设计，团队也没有人能给予帮助的前提下，一般认为这个需求尚不具备研发的条件，请把它丢到后续迭代去。

（三）需求范围评审

需求范围评审的目的在于产品干系人共同确定迭代内的需求，达成一致的结果。同一个小团队的产品经理（一定要包括产品leader，小公司甚至会叫上老板）、研发组长、业务需求总负责人（如果有的话）都需要参与需求范围评审。产品leader拥有最终决策权，对整个产品负责。

（四）需求设计

通过需求范围评审后，产品经理需要迅速对需求进行需求分析、概要设计、原型设计、需求文档撰写等，并交付UI/UX同事出设计稿，使迭代内的需求进入待评审阶段。

（五）内部评审

内部评审是产品团队研发评审前对需求的最后一次把关，叫上你小团队的同事、产品leader、外部支持者（有些需求可能需要其他团队的支持）、研发组长、UI/UX同事共同进行一次基于详细需求的内部评审，并且在会后基于会议内容进行必要的调整。产品leader拥有最终决策权，对整个产品负责。

（六）研发评审

建议提前三天公布需求文档，以便于研发同事评审前阅读，这样评审时才能更高效。评审时记得叫上外部支持者、UI/UX同学、前后端研发同学、测试同学、研发组长。

评审通过后产品经理在当前迭代的主要工作流已经结束，可以着手下一次需求收集，开启新的迭代。

三、研发工作流程

研发需求评审通过后，研发团队正式介入迭代，研发工作流已经开始。其中的核心节点包括技术方案设计、技术方案评审、产品开发联调、测试用例设计、测试用例评审、测试。

测试通过后，产品经理一定要验收需求，经过产品经理验收的需求才能够灰度上线，否则一律视为不具备上线条件。

四、迭代流程

产品设计工作流程加上研发工作流程基本上等价于迭代流程，但还差了一环：迭代用户反馈收集。一般而言迭代用户反馈收集集中于迭代灰度上线2周内和全量上线2周内。

五、补充内容

敏捷宣言中有提到，个体和互动高于流程和工具。因此产品团队一定要保持高频次的、简洁高效的沟通，以便于随时发现问题、解决问题。其中产品经理尤其要注意：①项目管理。产品经理需要把控迭代的进度，并引导团队一起想办法解决影响进度的问题，尤其是产品经理兼任项目经理时。②相应变化，这也是敏捷宣言中的一条。不存在尽善尽美的需求，也不存在一成不变的外部环境、内部环境，因此一旦发现迭代的内容已经不能满足诉求，请立刻止损。

六、结语

如果你想要了解什么事敏捷，请查看：SAAS时刻 | 什么是敏捷？

如果你想要了解敏捷中常用的看板方法，请查看：SAAS时刻 | 什么是看板方法？

如果你想要了解支持敏捷的管理工具，请查看：SAAS时刻 | 项目/研发管理系统