关于流程的重要性，淘宝UED小组流传着这样一个理念：设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。没错，80分已经很难了，当产品越大的时候，诞生天才产品的概率也就越小。“又快又稳定又有才”的100分产品是可遇不可求的。
PMP说高绩效组织的三大特征是项目管理标准化、注重人才培养、持续改进。流程是管理保准化的重要组成部分。
这里并不是说在任何情况下都需要流程，流程是手段，不是目的，但是合适的流程可以促进目的的达成。这篇文章是根据苏杰老师的书籍，人人都是产品经理纪念本和2.0，结合工作经验，并融入部分项目管理理念而成，下面这张图是本篇的主要内容，可以根据需要阅读。
很多项目都是从一个点子开始的，这个点子就是所谓的产品概念，它包含5个关键要素：核心用户、刚性需求、典型场景、产品概念、竞争优势。
核心用户 ：目标用户中最重要的用户是谁，表达为一个抽象的人群。
刚性需求 ：Ta们碰到的最痛的痛点是什么。满足刚性需求要优先于弹性需求；
典型场景 ：这些痛点最常出现在怎样的生活、工作场景
产品概念 ：用什么解决方案，用一个词、最多一句话概括你的解决方案是什么，一个App，一个网站，一个服务体系，还是一个企业协同办公的工具
竞争优势 ：相对已有方案的竞争优势。
这个时候的刚性需求、典型场景都是YY出来的，还未经验证。比如某Boss想做一款校园社交App，那核心用户就是一批校花，典型场景就是各位帅哥想去追漂亮的女生，解决方案就是校园社交App。
产品概念筛选的目的是对其进行可行性分析，通过对产品概念进行深入分析，产出商业论证。商业论证会包含商业需求和成本效益分析，以论证项目是否可行及项目边界。
提出产品概念后，如何快速判断它是否靠谱呢？通常是先随手找几个人问问，把产品概念将给他们听，如果听到大家说“呵呵，我好像不需要”、“好奇怪，不理解为什么这样做”，那就需要回炉重想，如果听到“这个准备卖多少钱”、“有点用，但是不是已经有类似的东西了”这样的问题，就说明这个概念靠谱，大家已经认可你的大方向了。
对这些相对靠谱的概念我们再次进行筛选，因为产品概念其实是在一个时间切片，所以每隔一段时间就要做一次。下图筛选的要素
产品概念筛选之后，就需要投入更多的资源推进这个产品了，在进入开发之前，需要收集尽可能多的信息，并进行分析和筛选。
需求采集的目的是通过研究用户来更好的满足需求 。需求采集方法的分类有如下四种
直接采集与间接采集，获取到的需求分别是一手需求和二手需求，可以从以下两个角度来理解它们的差异。
怎么说表达了观点，怎么做反映了行为 ，用户的说和做经常是不一致的.“说”的最大劣势是“耳听为虚”，怎么解决耳听为虚呢？看他怎么做。“做”的优势是“眼见为实”，但也有劣势：我们不知道用户是为什么这么做，不知道背后的原因，就意味着不能从根本上解决问题。于是，需要再去听他如何说，所以说和做事一对不可拆分的方法，尽可能用于一次需求采集，否则可能出问题。
定性研究可以找出原因，偏向于了解，属于个体研究；而定量研究可以发现现象，偏向于证实， 属于群体研究。定性的的问题是“以偏概全”，可能会被部分样本的特殊情况带入歧途，需要辅以定量的方法，定量研究的问题是“以表带本”，只能用来发现表面现象，却无法从中知道背后的原因，可以通过定性研究加以证实。
需求通常是带场景的，只有到那时那刻去亲身体会，或者通过想象去体会，才知道你的设计有没有问题。
有时候和用户沟通的时候，用户还没有接触这个产品，更没有真正用过这个产品。这种需求采集可能更多的是“发现新问题”。还有一种需求采集方法是在用户和产品发生交互的状态下采集，往往用于“优化现有方案”，所以，不同阶段，需要使用不同的需求采集方法。
需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它不是产品人员的中的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求。
用户说了很多需求，产品经理要“ 听用户说但不要照着做 ”，必须明确我们存在的价值是“把用户需求转化为产品需求”，这一过程就是需求分析。
在采集需求的时候，很多用户习惯给出Ta认为的问题解决方案，采集完需求后产品人员也会给出解决方案，这个时候，对于同一个问题，就有了两套解决方案，它们的区别是，一个是用户需求，一个是产品需求。而这个中间转化的过程就是--需求分析。
用户需求 ：用户自以为的需求，并且经常表达为用户的解决方案
产品需求 ：经过我们的分析，找到真实需求，并且表达为产品的解决方案。
需求分析 ：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
在需求转化的过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入产品需求列表，当然是否“明显不靠谱”，就要由产品团队来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了，这类需求可以标记为暂缓，并注明重启条件。
需求有三种深度：观点和行为，目标和动机，人性与价值观。运用Y模型的一个主要的好处在于它不能跳过用户目标而直接从用户需求到产品功能，对用户的需求有更深层次的分析，我们才能够不被伪需求欺骗、能够解决需求冲突、能够发现更多用户目标、能够抓住恒定的人性、能够在成熟市场中找机会；
“1”是用户需求场景，经常简单说成用户需求。这是起点，是表象，是需求的第一种深度—观点和行为。
“2”是用户需求背后的目标和动机，是需求的第二种深度，产品经理在思考用户目标时也要综合考虑公司、产品目标。
“3”是解决方案，是实施人员能够看懂的描述。
“4”是人性，或者说是价值观，是需求的第三种深度，是需求的本质。
用户需求转化为产品需求后，我们会把它存储到产品需求列表。
转化的产品需求，我们会把它维护起来，这个时候就需要确定需求列表中需要哪些属性。它大致包含了基本属性、种类、商业价值、开发量几个方面。
基本属性和需求种类相对简单，可以由需求录入人独立完成。一个公司的任何产品，一个产品的任何需求，最终都要满足一定的商业目的，所以“需求的商业价值”是最核心的内容，有条件的团队最好利用群体智慧，比如可以举行“需求讨论会”，如何通过具体的方法来衡量商业价值呢？
重要性 ：可以细分为满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”。
紧急程度： 从时间维度上判断这个需求是否迫切。通常采用重要紧急程度四象限评估法和重要性结合使用。
持续时间： 需求有长寿的，也有短寿的，比如为了迎合逢年过节做的需求，一般来说是短寿的，但是把过节做成一个可配置化的功能模块，不用每次都重新开发，就是长寿的，我们可以持续优化。
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
我们知道了每个需求的商业价值，决定是否做还要参考另外一个关键指标—实现难度，实现难度太难量化，工作中一般简化为开发工作量（人天）。
绝不能因为某个需求的实现难度大就不做，某个需求的实现难度小就做。比如我们的用户群体有99%是A类型，1%是其他类型，现在有两个需求分别针对A类型、其他类型，针对A类型用户的需求需要4人天，针对其他类型用户需要3人天，在不考虑其他因素的情况下，会做哪个需求呢？这就涉及到这一节的标题“性价比”。
性价比= 商业价值 /实现难度（简化为开发量）。这也是商业价值用1到5之间数字表示的原因，便于计算性价比。
现在我们就可以把产品需求列表按照“性价比”从大到小进行排序了，先做上面的就可以了。
资源总是有限的，所以我们只能做性价比高的事情。BRD是我们的武器，产品会议是我们的战场，经过产品经理间的PK，最后由公司各个相关部门的领导决定做BRD中的哪些需求。
产品会议：各个产品带着自己的BRD给公司高层领导讲解为什么要做这个产品？需要做什么？怎么做？，通过的需求会作为项目立项的输入，没有通过的需求会被标记为暂缓或拒绝。
产品是需求的集合，我们会在每个迭代上线一些功能，选取上线哪些功能的过程就是需求打包。那打包多少需求呢？这就涉及到项目管理的问题了， 做项目的终极目的是“多快好省，即范围大、时间短、质量好、资源低 ”。
但又要马儿跑又想马儿不吃草的想法是不现实的，所以通常我们需要在上述4个条件中寻求平衡。
我们以互联网常用的开发方法，敏捷型开发方法来聊下需求打包，迭代周期固定、团队稳定、任何项目都要保证质量，那变量就只能是量—项目范围了。
有人说，在产品需求列表中我们已经把需求按照“性价比”进行排序了，每个需求后面都对应着工作量，直接从上向下加起来就可以了，实际情况是不可以的，为了让项目靠谱，还要注意下面的几个地方 。
在项目立项后就需要评估工作量，最好的方式组建项目团队时候就重点考虑，或者提前培养提升团队成员的能力才是王道。
BRD主要回答三个问题，为什么要做这个产品？需要做什么？怎么做？ Why:****为什么要做这个产品 , 动之以情（通过用户故事，让受众一开始就感到需求之强烈，问题之严重），晓之以理（产品概念阶段做的内部能力、意愿；外部的价值、成本判断就用上了），诱之以利（做了这个项目会产生什么价值做一个ROI预估，当然，这里的ROI是广义的，回报的不一定是金钱，还可能是用户数，市场占有率等其他指标）
What: ****产品MVP 包含哪些功能（功能需求，非功能需求）及要做什么。
How: 项目计划及风险对策等 。 说清楚项目计划需要多少资源做保障，让老板知道需要多少人、财、物
所以BRD主要组成部分是项目背景、商业价值、资源评估、功能需求描述、非功能需求描述、风险和对策。
产品会议的目的，是通过对BRD的评审，决定是否做BRD中的功能，获得开发的资源。参与BRD评审的一般都是各个部门的高层，资源掌握在他们的手里。
一般先回顾下上次产品会议通过的项目，进展情况如何，是否需要调整资源、时间，是否有重大变更，发布后的项目表现如何，有什么问题。这样一方面可以各位领导更新各个项目的信息，更重要的是为了积累经验，让今后的产品决策更合理。
回顾之后，就是最关键的部分，拿出准备好的BRD进行讲解，通过动之以情、晓之以理、诱之以利的讲解，力争通过评审，并获得各位领导对资源的承诺。
通过概念提出与筛选、需求采集、需求分析、需求筛选等前期过程决定了“做不做，做多少“的问题，接下来通过项目阶段来回答怎么”做出来“的问题。
产品会议评审通过后，确保有的放矢，不要努力做错误的事，这是在产品立项前做的最重要的判断。因为立项就意味着资源的正式投入，在这个节点的验证，叫 原型验证 ，之前的验证，主要目的是验证用户需求抓的准不准，而本次验证则是考察用户是否认可解决方案。有的公司把这个环节叫做POC，产品概念测试，在这个环节，需要用尽量低的成本，做出某种形式的产品原型或demo，来让用户试用。用户试用通过就可以正式进入立项环节了。
项目启动总是以“Kick Off”开始，我们确定了团队成员、时间计划、沟通方法等，就可以在任何时候都做到心中有数。
经过产品会议后，需求基本确定下来了，项目经理就可以根据需要列出团队需要的角色有哪些，需要的数量大概是多少，当然团队成员需要使用的各种软硬件设施也是必不可少的。
团队成员招募完成后，不要忘记重要的一点，在项目的组织结构中，项目经理并不是结构中的顶端，我会组织一个“变更控制委员会”，这很有必要，成员一般是项目成员的领导，甚至领导的领导，他们的任务也很简单---“背锅”和“买单”，因为权力越大，责任越大，权责利对等。
这样有两个好处，对项目变更控制委员会来说，他们可以及时了解项目情况，领导在不知道项目具体情况时也会焦虑的，对项目成员来说，知道领导在监督工作，并且看到自己的努力，所以也会格外卖力。
决定何时做，谁来做 ，在项目中，就是项目计划，在这里最重要的一件事情就是： 再次评估****“****工作量”****，并推算出工期， 步骤如下：
Kick Off通常意味着规划阶段结束和执行阶段的开始，旨在传达项目目标，获得团队对项目的承诺，阐明每个干系人的角色和职责。主要内容如下：
经过需求采集、分析、筛选，决定要做项目，通过团队组建、计划制定、Kick Off会议等步骤后，正式开始实施的第一步就是“写PRD文档”。
PRD文档包含两大部分：总体说明和UC(Use Case)
总体说明主要包含了修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明7个部分；
我们辛辛苦苦地把各种虚伪文档都写完了，开发和测试可不敢拿过去直接用，为了保证产品的质量，需求还必须通过项目中各方的评审，方可进入开发阶段。
项目的需求阶段，通常会围绕着“写作--评审--修改--评审”循环展开；
一般来说，项目中最重要的三种角色是产品、测试、开发，所以派生出三次评审-- 需求评审、设计评审、测试评审 。
需求评审 ：PRD编写完成后，由产品经理把需求细化的成果说给相关干系人听，下面会有详细说明。
设计评审 ：概要设计与详细设计完成之后，由开发工程师把对需求的理解以设计文档的形式说给产品和测试听。
测试评审 ，在TC编写完成，测试开始执行之前进行，有测试工程师把对需求的理解以TC的形式说给产品和开发听。
除需求评审外，设计评审和测试评审也很有必要，进入执行阶段后，如果因为需求理解不一致或有偏差，返工的成本会随着项目的进展越来越高。
一般我们会在做出 比较大粒度的****PRD 之后马上安排一次评审，当然会有UC和Demo的半成品，以期尽早发现问题，比如业务规则的不合理，产品界面太丑陋，某功能技术上无法实现。这次的评审偏商业部分，建议叫上老板、营销人员、服务人员，甚至用户一起来听；
粗粒度的PRD通过以后，PM会和Ui一起细化UC和Demo，而开发会同步进行一些开发前的准备工作，比如细化和修正项目计划，部分系统的设计等， 当然这些在评审的过程中会做多次 。接下来是Demo的评审，决定了产品的外观，项目干系人最好把一下关，而UC评审偏更偏重技术实现，商业团队人员可以不参加；
项目启动之后，PM就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题。PM收集意见发布修改，直到最后一次，需求得以确认， 状态变为“开发中”。当然，之后的需求微调总是无法避免，但是“需求冻结”的里程碑要求我们在这之后不要轻易改动了。
开发阶段的流程如下：
测试阶段流程如下：
发布阶段流程如下：
发布成功！回家睡个好觉。
所有人终于如释重负，但作为项目事情还没有完，第一件事就是赶紧发布一封Email—”项目发布公告“，一般会写的比较煽情，比如项目中的各种艰辛、对每个参与者的感谢，发布之后的内心感言、产品对公司和用户的革命意义，贴几张产品的最新图片等，根据沟通管理计划，发送给项目的干系人。作为项目经理，应该做到时刻为团队争取各种精神、物质奖励，这种邮件、海报、老板的回信……都是很好的鼓励，如果还有项目经费的话，在组织一次聚餐，大家以后还要继续合作，开开心心，皆大欢喜。
之后，以终为始，对项目进行回顾，写一份项目小结，小结一下做这个项目的心得体会，比如碰到了什么问题，原因是什么，怎么解决的，怎么避免再犯；项目资源评估是否合理，收获了哪些经验，如何提高项目的准确度；根据数据监控的反馈，分析除了什么结果，项目的商业目标是否达到等。最后更新至组织的经验教训登记册，方便追溯及参考。
至此，一个产品从“想清楚“到”做出来“已经聊完了，我们可以根据需求选择性阅读，这里是各个流程的概述，我们可以通过其他资料进行针对性的完善。