编辑导语：对一个产品经理来说，一个项目从最初的点子到最后的发布整个流程都需要参与。本篇文章中作者从概念提出与筛选、需求阶段以及项目阶段三个方面，循序渐进地详细分析了点子到项目发布的全流程。相信能够对你有所帮助，感兴趣的小伙伴们快来一起看看吧！

关于流程的重要性，淘宝UED小组流传着这样一个理念：设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。

没错，80分已经很难了，当产品越大的时候，诞生天才产品的概率也就越小。“又快又稳定又有才”的100分产品是可遇不可求的。

PMP说高绩效组织的三大特征是项目管理标准化、注重人才培养、持续改进。流程是管理保准化的重要组成部分。

这里并不是说在任何情况下都需要流程，流程是手段，不是目的，但是合适的流程可以促进目的的达成。

这篇文章是根据苏杰老师的书籍，人人都是产品经理纪念本和2.0，结合工作经验，并融入部分项目管理理念而成，下面这张图是本篇的主要内容，可以根据需要阅读。

一、概念提出与筛选

1. 概念提出

很多项目都是从一个点子开始的，这个点子就是所谓的产品概念，它包含5个关键要素：核心用户、刚性需求、典型场景、产品概念、竞争优势。

核心用户：目标用户中最重要的用户是谁，表达为一个抽象的人群。

刚性需求：Ta们碰到的最痛的痛点是什么。满足刚性需求要优先于弹性需求；

典型场景：这些痛点最常出现在怎样的生活、工作场景

产品概念：用什么解决方案，用一个词、最多一句话概括你的解决方案是什么，一个App，一个网站，一个服务体系，还是一个企业协同办公的工具

竞争优势：相对已有方案的竞争优势。

这个时候的刚性需求、典型场景都是YY出来的，还未经验证。

比如某Boss想做一款校园社交App，那核心用户就是一批校花，典型场景就是各位帅哥想去追漂亮的女生，解决方案就是校园社交App。

2. 概念筛选

产品概念筛选的目的是对其进行可行性分析，通过对产品概念进行深入分析，产出商业论证。

商业论证会包含商业需求和成本效益分析，以论证项目是否可行及项目边界。

提出产品概念后，如何快速判断它是否靠谱呢？

通常是先随手找几个人问问，把产品概念将给他们听，如果听到大家说“呵呵，我好像不需要”、“好奇怪，不理解为什么这样做”，那就需要回炉重想，如果听到“这个准备卖多少钱”、“有点用，但是不是已经有类似的东西了”这样的问题，就说明这个概念靠谱，大家已经认可你的大方向了。

对这些相对靠谱的概念我们再次进行筛选，因为产品概念其实是在一个时间切片，所以每隔一段时间就要做一次。下图筛选的要素。

二、需求阶段

产品概念筛选之后，就需要投入更多的资源推进这个产品了，在进入开发之前，需要收集尽可能多的信息，并进行分析和筛选。

1. 需求采集

需求采集的目的是通过研究用户来更好的满足需求。需求采集方法的分类有如下四种：

（1）直接采集与间接采集

直接采集与间接采集，获取到的需求分别是一手需求和二手需求，可以从以下两个角度来理解它们的差异。

需求的提出者是不是有需求的人。如果用户为自己提需求，采集到的是一手需求，反之为二手需求。

需求是原始的还是加工过的，比如和用户直接聊，采集到的就是一手需求，而去看第三方机构的做的一些行业分析报告，就是二手需求。

（2）定性与定量，说与做

怎么说表达了观点，怎么做反映了行为，用户的说和做经常是不一致的。

“说”的最大劣势是“耳听为虚”，怎么解决耳听为虚呢？看他怎么做。

“做”的优势是“眼见为实”，但也有劣势：我们不知道用户是为什么这么做，不知道背后的原因，就意味着不能从根本上解决问题。

于是，需要再去听他如何说，所以说和做事一对不可拆分的方法，尽可能用于一次需求采集，否则可能出问题。

定性研究可以找出原因，偏向于了解，属于个体研究；而定量研究可以发现现象，偏向于证实，属于群体研究。

定性的的问题是“以偏概全”，可能会被部分样本的特殊情况带入歧途，需要辅以定量的方法，定量研究的问题是“以表带本”，只能用来发现表面现象，却无法从中知道背后的原因，可以通过定性研究加以证实。

（3）是否在真实场景中

需求通常是带场景的，只有到那时那刻去亲身体会，或者通过想象去体会，才知道你的设计有没有问题。

（4）是否与用户发生交互

有时候和用户沟通的时候，用户还没有接触这个产品，更没有真正用过这个产品。这种需求采集可能更多的是“发现新问题”。

还有一种需求采集方法是在用户和产品发生交互的状态下采集，往往用于“优化现有方案”。

所以，不同阶段，需要使用不同的需求采集方法。

需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它不是产品人员的中的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求。

2. 需求分析

用户说了很多需求，产品经理要“听用户说但不要照着做”，必须明确我们存在的价值是“把用户需求转化为产品需求”，这一过程就是需求分析。

（1）需求转化

在采集需求的时候，很多用户习惯给出Ta认为的问题解决方案，采集完需求后产品人员也会给出解决方案。

这个时候，对于同一个问题，就有了两套解决方案，它们的区别是，一个是用户需求，一个是产品需求。而这个中间转化的过程就是–需求分析。

用户需求：用户自以为的需求，并且经常表达为用户的解决方案

产品需求：经过我们的分析，找到真实需求，并且表达为产品的解决方案

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程

在需求转化的过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入产品需求列表，当然是否“明显不靠谱”，就要由产品团队来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了，这类需求可以标记为暂缓，并注明重启条件。

需求有三种深度：观点和行为，目标和动机，人性与价值观。

运用Y模型的一个主要的好处在于它不能跳过用户目标而直接从用户需求到产品功能，对用户的需求有更深层次的分析，我们才能够不被伪需求欺骗、能够解决需求冲突、能够发现更多用户目标、能够抓住恒定的人性、能够在成熟市场中找机会。

· “1”是用户需求场景，经常简单说成用户需求。这是起点，是表象，是需求的第一种深度—观点和行为。

· “2”是用户需求背后的目标和动机，是需求的第二种深度，产品经理在思考用户目标时也要综合考虑公司、产品目标。

· “3”是解决方案，是实施人员能够看懂的描述。

· “4”是人性，或者说是价值观，是需求的第三种深度，是需求的本质。

案例练习： 我们用Y模型来分析以下“秀场直播”观看者的人性需求。

· “1”用户的观点和行为是给主播送花，送游艇

· “2”用户的目的是和主播互动

· “3”解决方案是提供送礼物功能，并且在屏幕突出显示

· “4”从人性的角度分析，这么多人送礼，怎么让他们更开心，就会发现突破口是炫耀和攀比

好比在线下的演艺酒吧，经常出现前排卡座里的老板斗富的场景，这在线上也可以复现。

于是，所有的直播应用里，都可以找到排行榜，并且还有分类。

送礼榜表示谁为主播花的钱最多；分享榜表示谁榜主播做的宣传最多，即没钱的捧个人场；时长榜表示谁最忠诚，一直在看。

用户需求转化为产品需求后，我们会把它存储到产品需求列表。

（2）确定基本属性

转化的产品需求，我们会把它维护起来，这个时候就需要确定需求列表中需要哪些属性。

它大致包含了基本属性、种类、商业价值、开发量几个方面。

基本属性包括了下表中的字段：

需求的种类：

（3）需求的商业价值

基本属性和需求种类相对简单，可以由需求录入人独立完成。

一个公司的任何产品，一个产品的任何需求，最终都要满足一定的商业目的，所以“需求的商业价值”是最核心的内容，有条件的团队最好利用群体智慧，比如可以举行“需求讨论会”，如何通过具体的方法来衡量商业价值呢？

需求的商业价值可以通过重要性、紧急程度、持续时间3个维度来综合衡量。

重要性：可以细分为满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”。

紧急程度：从时间维度上判断这个需求是否迫切。通常采用重要紧急程度四象限评估法和重要性结合使用。

持续时间：需求有长寿的，也有短寿的，比如为了迎合逢年过节做的需求，一般来说是短寿的，但是把过节做成一个可配置化的功能模块，不用每次都重新开发，就是长寿的，我们可以持续优化。

需求讨论会：商业价值的判断，直接影响产品未来的走向，一般的做法是需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。

对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做下陈述，主管定个级别，可以用1到5来表示。然后大家讨论，讨论前参会人员要做好功课。

上述那么多维度，可以加权平均得到综合的商业价值，但是实施起来成本太高，很难推动，也不是很有必要。

所以建议在讨论的时候，大家充分表达完意见后，安全的做法是谁官大谁负责，俗称老板拍脑袋，最终由会场上级别最高的人报一个数字结束（1-5之间），这就是现实，也是一种高效的方法。

一般我们还会在列表中添加1列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司有什么帮助。

（4）初评需求的实现难度

绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。

我们知道了每个需求的商业价值，决定是否做还要参考另外一个关键指标—实现难度，实现难度太难量化，工作中一般简化为开发工作量（人天）。

（5）性价比

绝不能因为某个需求的实现难度大就不做，某个需求的实现难度小就做。

比如我们的用户群体有99%是A类型，1%是其他类型，现在有两个需求分别针对A类型、其他类型，针对A类型用户的需求需要4人天，针对其他类型用户需要3人天，在不考虑其他因素的情况下，会做哪个需求呢？这就涉及到这一节的标题“性价比”。

性价比= 商业价值 /实现难度（简化为开发量）。这也是商业价值用1到5之间数字表示的原因，便于计算性价比。

现在我们就可以把产品需求列表按照“性价比”从大到小进行排序了，先做上面的就可以了。

3. 需求筛选

资源总是有限的，所以我们只能做性价比高的事情。

BRD是我们的武器，产品会议是我们的战场，经过产品经理间的PK，最后由公司各个相关部门的领导决定做BRD中的哪些需求。

产品会议：各个产品带着自己的BRD给公司高层领导讲解为什么要做这个产品？需要做什么？怎么做？

通过的需求会作为项目立项的输入，没有通过的需求会被标记为暂缓或拒绝。

（1）需求打包

产品是需求的集合，我们会在每个迭代上线一些功能，选取上线哪些功能的过程就是需求打包。

那打包多少需求呢？这就涉及到项目管理的问题了，做项目的终极目的是“多快好省，即范围大、时间短、质量好、资源低”。

但又要马儿跑又想马儿不吃草的想法是不现实的，所以通常我们需要在上述4个条件中寻求平衡。

我们以互联网常用的开发方法，敏捷型开发方法来聊下需求打包，迭代周期固定、团队稳定、任何项目都要保证质量，那变量就只能是量—项目范围了。

有人说，在产品需求列表中我们已经把需求按照“性价比”进行排序了，每个需求后面都对应着工作量，直接从上向下加起来就可以了，实际情况是不可以的，为了让项目靠谱，还要注意下面的几个地方。

“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，一般来说业务上紧密联系的才会打包在一起，不然产品就成修修补补的大杂烩了。需求在打包以后，最好通过业务逻辑图的方式可视化可以更直观地给别人讲解。

需求依赖，功能互相之间有依赖关系，哪些功能点需要优先去做，需要在需求列表中注明。功能与人力资源之间的依赖关系也会经常存在，比如某个功能只有团队中某个人才能实现。在项目立项后就需要评估工作量，最好的方式组建项目团队时候就重点考虑，或者提前培养提升团队成员的能力才是王道。

需求的粒度大小问题，商业价值很高的功能，如果细分的话，我们会发现其中有价值相对低的部分，所以需求的粒度要尽量细，前提是细化引起的管理成本在可接受范围内。在打包这个阶段的工作量还是比较粗粒度的评估，一般不要超过“5人天”就可以。

（2）编写BRD

BRD主要回答三个问题，为什么要做这个产品？需要做什么？怎么做？

Why：为什么要做这个产品， 动之以情（通过用户故事，让受众一开始就感到需求之强烈，问题之严重），晓之以理（产品概念阶段做的内部能力、意愿；外部的价值、成本判断就用上了），诱之以利（做了这个项目会产生什么价值做一个ROI预估，当然，这里的ROI是广义的，回报的不一定是金钱，还可能是用户数，市场占有率等其他指标）

What：产品MVP包含哪些功能（功能需求，非功能需求）及要做什么。

How：项目计划及风险对策等。 说清楚项目计划需要多少资源做保障，让老板知道需要多少人、财、物。

所以BRD主要组成部分是项目背景、商业价值、资源评估、功能需求描述、非功能需求描述、风险和对策。

（3）产品会议

产品会议的目的，是通过对BRD的评审，决定是否做BRD中的功能，获得开发的资源。参与BRD评审的一般都是各个部门的高层，资源掌握在他们的手里。

一般先回顾下上次产品会议通过的项目，进展情况如何，是否需要调整资源、时间，是否有重大变更，发布后的项目表现如何，有什么问题。

这样一方面可以各位领导更新各个项目的信息，更重要的是为了积累经验，让今后的产品决策更合理。

回顾之后，就是最关键的部分，拿出准备好的BRD进行讲解，通过动之以情、晓之以理、诱之以利的讲解，力争通过评审，并获得各位领导对资源的承诺。

三、项目阶段

通过概念提出与筛选、需求采集、需求分析、需求筛选等前期过程决定了“做不做，做多少“的问题，接下来通过项目阶段来回答怎么”做出来“的问题。

产品会议评审通过后，确保有的放矢，不要努力做错误的事，这是在产品立项前做的最重要的判断。

因为立项就意味着资源的正式投入，在这个节点的验证，叫原型验证，之前的验证，主要目的是验证用户需求抓的准不准，而本次验证则是考察用户是否认可解决方案。

有的公司把这个环节叫做POC，产品概念测试，在这个环节，需要用尽量低的成本，做出某种形式的产品原型或demo，来让用户试用。用户试用通过就可以正式进入立项环节了。

1. 立项

项目启动总是以“Kick Off”开始，我们确定了团队成员、时间计划、沟通方法等，就可以在任何时候都做到心中有数。

（1）团队组建

经过产品会议后，需求基本确定下来了，项目经理就可以根据需要列出团队需要的角色有哪些，需要的数量大概是多少，当然团队成员需要使用的各种软硬件设施也是必不可少的。

团队成员招募完成后，不要忘记重要的一点，在项目的组织结构中，项目经理并不是结构中的顶端，我会组织一个“变更控制委员会”，这很有必要，成员一般是项目成员的领导，甚至领导的领导，他们的任务也很简单—“背锅”和“买单”，因为权力越大，责任越大，权责利对等。

当项目因为种种原因出现重大变更的时候，比如成本、时间、需求等，我会向他们提出申请，获得批准后才执行变更，这也是项目经理对自己和项目成员的保护。

在整个项目过程中，需要他们来提供项目资源，包括人、财、物。

这样有两个好处，对项目变更控制委员会来说，他们可以及时了解项目情况，领导在不知道项目具体情况时也会焦虑的，对项目成员来说，知道领导在监督工作，并且看到自己的努力，所以也会格外卖力。

（2）开发计划确定

决定何时做，谁来做，在项目中，就是项目计划，在这里最重要的一件事情就是：再次评估“工作量”，并推算出工期。

步骤如下：

1. 在BRD中给各项需求进行了工作量初评，现在把这些信息再一次拿出来参考，因为从产品会议结束到制定到制定项目计划的日子中，产品经理同时也在做PRD的细化，项目经理可以根据PRD文档，对任务进行拆分，即创建WBS，重视完整性，需遵循MECE法则。

2. 开发的同学拿到PRD和WBS时，每个功能点的工作量就可以评估的更准确一些了，最重要的区别是，初评一般是开发经理之类的角色来做，未考虑谁来做，而现在开发经理根据团队里开发工程师的能力特点、擅长领域等因素，“因事择人”，把各项开发任务分配给团队里最合适的人（当然，要把高手调入项目的关键路径）。之后，每位领导开发任务的开发工程师自己评估工作量，为各自任务买单，承诺最可能的时间，之前的初评只是做一个参考，毕竟每个人对自己最熟悉。

3. 这里的粒度比初评的时候更细，至少精确到“1人天”，按照经验，这里的“1人天“通常等价于”5~6个小时“，而不是按照一天工作8小时计算，因为人很难保持持续高效，并且不被其他时期打断。

4. 项目经理把工作量转化为工期，同时考虑任务的依赖关系，也就得到了项目的进度计划，通常用逻辑横道图呈现。

5. 详细的项目进度计划做完后，项目经理，需要在更大的粒度上把开需求计划、开发计划、测试计划等合并成项目进度计划，并确定项目的几个里程碑，也就是监控点，通常是需求完成，开发完成，编码完成，内部测试完成、UAT测试完成，发布上线，以里程碑图呈现，便于给高层展示。

（3）Kick off

Kick Off通常意味着规划阶段结束和执行阶段的开始，旨在传达项目目标，获得团队对项目的承诺，阐明每个干系人的角色和职责。

主要内容如下：

参加方包括项目各重要干系人包括发起人、项目经理、项目团队、客户、高管层、职能管理部门、供应商代表等。

传达的信息主要包括项目背景、项目意义、目的与目标、需求、功能点概述、项目组织结构、项目计划、沟通计划等。

2. 需求开发

（1）PRD文档编写

经过需求采集、分析、筛选，决定要做项目，通过团队组建、计划制定、Kick Off会议等步骤后，正式开始实施的第一步就是“写PRD文档”。

PRD文档包含两大部分：总体说明和UC(Use Case)。

总体说明主要包含了修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明7个部分。

（2）需求评审

我们辛辛苦苦地把各种虚伪文档都写完了，开发和测试可不敢拿过去直接用，为了保证产品的质量，需求还必须通过项目中各方的评审，方可进入开发阶段。

项目的需求阶段，通常会围绕着“写作–评审–修改–评审”循环展开；

一般来说，项目中最重要的三种角色是产品、测试、开发，所以派生出三次评审–需求评审、设计评审、测试评审。

需求评审：PRD编写完成后，由产品经理把需求细化的成果说给相关干系人听，下面会有详细说明。

设计评审：概要设计与详细设计完成之后，由开发工程师把对需求的理解以设计文档的形式说给产品和测试听。

测试评审：在TC编写完成，测试开始执行之前进行，有测试工程师把对需求的理解以TC的形式说给产品和开发听。

除需求评审外，设计评审和测试评审也很有必要，进入执行阶段后，如果因为需求理解不一致或有偏差，返工的成本会随着项目的进展越来越高。

一般我们会在做出比较大粒度的PRD之后马上安排一次评审，当然会有UC和Demo的半成品，以期尽早发现问题，比如业务规则的不合理，产品界面太丑陋，某功能技术上无法实现。

这次的评审偏商业部分，建议叫上老板、营销人员、服务人员，甚至用户一起来听。

粗粒度的PRD通过以后，PM会和Ui一起细化UC和Demo，而开发会同步进行一些开发前的准备工作，比如细化和修正项目计划，部分系统的设计等，当然这些在评审的过程中会做多次。

接下来是Demo的评审，决定了产品的外观，项目干系人最好把一下关，而UC评审偏更偏重技术实现，商业团队人员可以不参加。

（3）需求确认

项目启动之后，PM就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题。

PM收集意见发布修改，直到最后一次，需求得以确认， 状态变为“开发中”。

当然，之后的需求微调总是无法避免，但是“需求冻结”的里程碑要求我们在这之后不要轻易改动了。

3. 开发阶段

开发阶段的流程如下：

1. 开发经理或能力比较强的开发工程师会带着普通工程师一起做概要设计、详细设计。
2. 设计完成后会组织一次设计评审，产品和测试人员都会参与，审核一下工程师们对需求的理解是否正确。
3. 评审通过后，进入编码阶段。
4. 之后工程师需要对自己的代码进行单元测试，自测环节做到位，可以减少测试人员的很多工作量。
5. 当开发工程师认为自测已完成，就可以把代码提交到测试环境。按照开发计划，当项目主体部分提交测试的时候，我们就走过了一个里程碑—开发完成。

4. 测试阶段

测试阶段流程如下：

1. 开发工程师在设计与编码的同时，测试工程师也没有闲着，他们会继续细化和调整测试计划，并完成测试用例的编写。
2. TC编写完成后，测试经理会组织TC评审，时间一般在开发人员提交测试之前，PD和开发人员都要参加，再次确认大家对需求理解是否一致。很多需求的细节无法再需求阶段考虑完全，我们会通过开发和测试阶段的反复沟通不断细化。
3.  TC评审通过，待开发提交测试后，测试人员会迅速进行一轮“冒烟测试“，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
4.  在测试人员开始做正式测试的同时，产品经理又出场了，他们会组织一场“功能评审会“，利用测试环境，第一时间把需求展示给所有的项目干系人，进一步确保做出来的东西是大家想要的。

接下来，测试会进行多轮测试，直到项目满足上线条件，项目就进入了发布阶段。

5. 发布阶段

发布阶段流程如下：

1. 拟定发布计划（checklist）：包括发布时间、发布渠道、发布节奏（什么时间点在什么渠道铺）、应急措施（用户使用时出现严重问题垓如何处理，系统是否可回滚）等，这在可能出现的混乱发布时是很有效的，避免疏漏；
2.  发布计划评审：对项目质量、风险点进行评审，得出评审结论，如果整体风险可控，评审通过，则进入预发布环节，反之则需要进一步完善。
3. 正式发布过程：是从更新到“预发布环境“开始的。预发布环境尽量模拟生产环境上的真实状态，测试人员会在预发布环境进行最后的回归测试。
4. 在预发布环境回归测试通过后，按预定的发布时间更新到“生产环境“，测试人员再一次做简单的回归测试，完成发布。

6. 项目小结

发布成功！回家睡个好觉。

所有人终于如释重负，但作为项目事情还没有完，第一件事就是赶紧发布一封Email—”项目发布公告“，一般会写的比较煽情，比如：

•  项目中的各种艰辛
• 对每个参与者的感谢
• 发布之后的内心感言
• 产品对公司和用户的革命意义
• 贴几张产品的最新图片
• ……

根据沟通管理计划，发送给项目的干系人。

作为项目经理，应该做到时刻为团队争取各种精神、物质奖励，这种邮件、海报、老板的回信……都是很好的鼓励，如果还有项目经费的话，在组织一次聚餐，大家以后还要继续合作，开开心心，皆大欢喜。

之后，以终为始，对项目进行回顾，写一份项目小结，小结一下做这个项目的心得体会，比如:

• 碰到了什么问题
• 原因是什么
• 怎么解决的
• 怎么避免再犯
• 项目资源评估是否合理
• 收获了哪些经验
• 如何提高项目的准确度
• 根据数据监控的反馈分析出了什么结果
• 项目的商业目标是否达到
• ……

最后更新至组织的经验教训登记册，方便追溯及参考。

至此，一个产品从“想清楚“到”做出来“已经聊完了，我们可以根据需求选择性阅读，这里是各个流程的概述，我们可以通过其他资料进行针对性的完善。

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

题图来自Unsplash，基于CC0协议