这是在某社区的一位前辈作出的总结，结合自己的产品经历进行了一些补充和修改。

1. 需求来源部分

不同方向的需求来源略有不同，总体来说，产品经理的需求来源有以下几个方面：

业务需求：由业务方，比如 BD、编审、运营等，直接提出的业务需求；

数据挖掘：通过数据挖掘和分析，发现的问题或需求；

竞对调研：通过分析竞对的产品，发现竞对比我们有优势或值得学习借鉴的地方；

实地观察：不论是 B 端产品还是 C 端产品，其实都有大量的机会实地观察用户行为。比如直接陪访城市运营等；

战略需要：俗话说「老大拍的」，这类是由公司 leader 直接安排的需求，通常表示公司未来发展方向或急需解决的关键问题；

其他还包括客服、商服反馈的问题，通过在线渠道或用户访谈获得的需求，还有微博、朋友圈吐槽等各种 SNS 途径。不论哪种途径获取的需求，产品经理都应该有一个自己的需求池，统一记录各种想法。

在不同需求来源中，最看重的产品经理自己发现/评估的需求，这是评价产品经理需求决策能力的重要指标。

2. 收集和整理需求

收集和整理需求，就是将需求统一记录到需求池，方便团队内/间的传播。每个团队建议维护自己的需求池地址。

需求池只是一个备忘，记录下来的需求不一定都要做，也未必是值得做的需求才记录下来。

及时维护

3. 立项审批

立项是产品流程中的第一个必要步骤，在这个阶段，核心的是要确定项目的价值和目标。

3.1 确定项目的价值

确定项目价值有三个核心要素：角色、场景和目标。也就是，谁在什么情况下要解决什么问题（满足什么需求）。三个要素必须齐备，才能做出基本的价值判断。

具备了三个要素，还需要从两个维度去定义项目的价值。

第一个维度，是当前业务/产品阶段。基于不同的业务阶段(一般都是萌芽期、成长期、发展期、稳定期、衰退期），产品在战术和战略的打法各有不同。比如某共享单车做Growth中的17年红包大战，虽纵向来看不利生态循环，但横向来看利于业务竞争。后面会另起一篇分享“业务型产品经理赋能业务的逻辑与思考”

第二个维度，是影响范围。抛开计量谈毒性，都是耍流氓。前面我们提到了用户第一个的标准，但是，如果一个需求仅对 1000 个用户有收益，但对 50000 个商家有收益，那么优先级的判断也是不同的。影响范围是大家日常工作中非常容易忽略的思考点，往往发现一个 badcase，就拼命想解决，说好听点叫偏执，说难听点就是本末倒置。

思考项目价值，推荐用5 Why 分析法，对事情不断追问，看看一个需求，是否还有成本更低的解决方案，本质收益到底是什么，到底会影响多少人。

3.2 确定项目目标

价值说的是对什么有好处，目标说的是有多少好处。

制定目标必须符合 SMART 原则 ，细节看链接，我这里举个例子。

我的目标是要变成瘦子；

我的目标是要减肥 6 斤；

我的目标是要一个月减肥 6 斤；

我当前体重是 75 公斤，以我的身高计算，合理体重是 72 公斤，我希望在下个月 1 号前减重 1 公斤，3个月内达到标准体重。

上述四种描述目标的方式：

第一种，典型的没有任何意义的目标，没有时间点、没有量化目标；

第二个，有了一个量化目标，但是什么时候到达，没有明说。还记得我说过的抛开计量谈毒性么？

第三个，有个一个时间点，但是几乎不可能完成，即便能完成，也是以牺牲健康为代价。这就是不具备可完成性和与总体目标的相关性；

第四个，相对比较合理。首先说明了当前的情况，以及合理的目标值。其次，有明确的时间点和量化指标，还有相对长期的规划。最后，相比之下，可行性也会更高一些。

3.3 如何进行立项审批？

建议组/团队有一个立项表，其实核心就是确定价值和目标。表格填写好以后，可以在**每周一**早上的例会上提出立项的要求，leader确认立项后会将立项**标红**。

任何口头承诺都是无效的，只有立项表中的项目被标红，才说明立项成功。

价值描述是否清楚，价值优先级是否足够高；

项目目标是否 SMART；

项目主 R 是否有足够的时间精力确保项目的质量；

项目投入有多大；

立项有三种结果：成功、待定和放弃。需要严格把控需求，以确保资源的最大利用化(切记不仅仅是研发资源)。

4. 调研、写方案和组内评审

立项成功只是第一步，围绕立项时确定的项目价值和目标，需要进行深入的方案设计工作。

4.1 方案调研

所谓调研，就是收集我们设计方案所需的背景信息和数据。需要遵循以下原则：

有明确的调研范围，不能太窄，也不能无休止的调研；

一定要调研第一手资料，不能偏信二手信息。比如综运反馈运维师傅有需求或者有问题，我们就应该直接调研运维，了解商家的真实需求；

数据调研需要足够的样本量；

实地调研。如果是系统功能，就要自己测试；如果是需求，最好直接和需求方进行面谈；

要输出调研报告，尤其是调研结论；

4.2 方案编写

这里不多讲，需求文档最重要/首先是讲明白事、拉齐认知。后面会另起一篇分享“需求文档编写规范”

4.3 组内评审

评审注意事项：

各组 leader 必须参加组内评审；

所有需求必须经过组内评审；

评审需要输出评审结果报告，记录修改点、反馈和是否通过的结论；

根据不同需求类型，评审可以酌情邀请业务、RD、UI/UE 和 QA 参加；

建议方案出来以后，PM 先和需求方或自己的 leader 进行一对一沟通，对方案要点进行确认；

组内评审原则上不应该超过 2 次；

如果评审次数过多，需要评估对应 PM 是否具备完成该项目的能力，如不胜任，需要及时换人，确保项目进展和质量；

5. 项目评审

也可以叫做大组评审或正式评审，评审要点如下：

大组评审必须邀请 RD、QA 、UI/UE、业务方和关联方，周知到业务 leader 和各产品 leader；

评审形式，以主 R PM 讲产品需求文档为主，讲解过程中，尽量不要打断陈述人，让陈述人有机会完整表达方案；

避免「钓鱼评审」，不能出现大家写需求，PM 记录的情况；

严格控制评审时间；

评审结果分为：重写、修改和通过；

评审至少提前一天发出会议邀请

6. 技术评审

技术评审的重点是技术评估项目可行性，有以下要点：

技术评审也可以由 PM 发起，最好是 PM 发起；

技术评审后必须拿到估时；

按照功能列表，如果能给出每个具体功能的估时最好；

技术评审必须在排期会之前完成；

重点项目需要邀请 RD leader 参与；

多系统关联项目，需要邀请关联方 RD 参与；

需要 UI/UE 参加的项目，技术评审前需要完成相关交互设计；

原则上，进入技术评审后，需求关闭，不允许进行需求增改；

评审至少提前一天发出会议邀请，需带文档链接，方便相关团队提前熟悉；

之所以需要按照功能列表进行每个功能点的估时，同时也需要给每个功能点确定优先级，是因为在后续的排期中会用到。

7. 排期会

所有开发资源都需要排期，一般来说，后端和 FE 因为不依赖版本，可以在一个排期会进行；客户端由于需要跟版，有自己独立的排期会。

这里不多阐述，每个团队有自己的节奏，关键在于“严格执行和优化迭代”

8. Task 分解

项目排期成功后，建议 PM 给相关 RD 和 QA 创建 task。要求如下：

Task框架最好覆盖“需求开发流程的各节点”；

至少一个功能点要分拆一个 task，或一个页面也需要一个 task；

测试任务也需要开 task；

中大型项目，或 task 数量超过10个的项目，需要创建 dashboard；

一个功能点，如涉及多个 RD，每个都需要创建 task；

task 必须在开发之前创建；

没有开 task 的功能点或页面需求，RD 可以不做；

及时维护

9. 项目进度跟踪

项目开始开发后，PM 不能做甩手掌柜，还需要对项目进度进行跟踪。一些项目进度管理方面的方法：

开发周期较短的项目，PM 需要每天 check task 的完成情况；

开发周期较长的项目，项目初期可以每两天 check 一次 task 完成进度，临近 deadline 需要每天 check；

根据项目要求，可以周期性与 RD 开项目沟通会，了解 RD 在项目进度中的问题和困难。比如相关方响应速度、需求理解、资源协调等；

重点项目或难度比较大的项目，PM 可以酌情开每日站会。站会可以在早上，5-10分钟，沟通前日进度或 todo；

项目跟进过程中，要非常关注外部依赖，需要明确依赖方和依赖顺序，尤其是对外部资源的依赖；

优先级比较高的要求，可以每天汇总项目进度，发送给相关方和需求方；

10. 功能验收

功能验收指的是确保项目完成了最基本的功能实现，与 RD 一起确定项目是否达到提测需求。

需要在编写需求文档的时候，就确定功能的验收标准，所以验收环节就要严格按照验收标准进行验收。

验收完成后，可以发出一个正式的验收结果。但是，需要注意的是，验收不代表项目达到上线标准，仅表示项目可以提测。

为什么在提测前 PM 需要验收？主要还是因为我们的 QA 资源非常紧张，希望 QA 用在更有价值的地方，而不用去操心基本的功能完整性问题。

11. 项目提测

项目开发并进行基本验收后，由 RD 发提测邮件。

测试之前，其实在项目开发过程中，PM 需要与 QA 一起编写测试用例。原则上来说，项目提测之后，PM 只需要与 QA 沟通测试进度，了解测试中出现的问题。测试中的 bug，需要 PM 和 QA 来判断是开发 bug 还是产品设计的缺陷。

如果提测过程中有产品设计缺陷，需要分情况讨论。

如果是客户端版本，而产品设计缺陷并没有很大的影响范围，不会导致用户体验层面的 block 和太大伤害，原则上不在提测后修复产品逻辑的问题。可以将这些问题作为高优先级的需求列入下次项目。这个判断需要产品线 leader 来判断。

如果是服务端需求，不存在严格的发版和上线时间，可以评估 bug 的影响范围和严重程度，酌情进行修复。

当然，项目中出现产品逻辑 bug 属于 PM 的严重失职，需要我们避免。

在项目开发过程中，如果有 delay 的风险，需要尽早发项目延期预警邮件，最好面对面周知到KP，如关联方 RD、PM 和需求方。

测试过程中，最终 PM 还要进行一次产品上线验收，在 QA 确保项目质量的情况下对功能完整性和可用性进行评估。并正式邮件发出。

12. 预上线与上线

项目开发并测试完成后，PM 需要先发预上线邮件，并在相关渠道进行周知。之所以要发预上线邮件，是因为考虑到项目上线对各方可能带来的影响，需要各方提前有所准备。原则上，预上线邮件至少提前 1-2 天发出。

项目上线后也需要发正式邮件周知，注意事项如下：

原则上，周五和节假日前三天，不能上线。如有特殊需求要上线，需要产品线 leader 和 RD leader 确认；

预上线和上线邮件要发送全组，包括业务、运营、PM、RD、UI/UE、QA 等；

预上线邮件侧重说明项目上线的影响范围；

上线邮件侧重说明项目的价值、目标和方案，邮件中需要明确说明上述内容；

上线邮件中，不仅应该包含项目的方案说明，还需要酌情考虑增加使用说明、运营计划、FAQ 等内容；

上线邮件中，要说明项目上线后各方需要关注的数据和异常；

13. 项目总结评估

项目总结评估是整个项目中最重要的环节之一，有 PM 主导，主要做以下几个事情。

第一个，写项目总结文档。从以下几个方面：

目标完成统计（数据）

目标完成情况的分析，为什么完成得好，为什么完成不好

方案设计问题复盘

项目执行问题复盘

开发测试问题复盘

产品运营问题复盘

后续运营推广方案

下一步产品计划

第二个，需要基于总结文档开项目复盘会。是否需要正式复盘会，视项目情况绝对。大中型项目一定需要复盘会，效果突出或不能达到预期目标的项目，也需要专题复盘。

第三个，将上述信息内容，简要填入项目总结表。