长话短说，腾讯产品项目的主体流程划分成了七个阶段：
“概念阶段（CONCEPT）”
“提案阶段（PROPOSAL）”
“原型开发阶段（PROTOTYPE）”
“产品开发阶段（ALPHA）”
“内测阶段（CLOSE BETA）”
“正式运营阶段（OPERATION）”
“结项（CLOSE）”
1 概念阶段（CONCEPT）
概念阶段主要由“专家评审组”和“概念提出人”共同参与。
概念提示人负责【概念提出】，交由专家评审组进行【概念评审】和【存入概念库】操作。
2 提案阶段（PROPOSAL）
提案阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。
由决策委员会组织【成立提案小组】，项目组和研发负责【准备提案评审材料】，材料交由专家评审组进行【提案专家评审】，通过专家评审后交由决策委员会进行【提案决策评审】。
未通过评审则提案PASS；待修订则打回至【准备提案评审材料】步骤；通过评审则进入下一阶段。
众所周知的是，“提案阶段”类似“需求调研阶段”。日常工作中，对于需求调研咱们会分成三个部分“行业调研”、“市场调研”和“竞品调研”。
2.1 行业调研
行业调研：行业分析是指根据经济学原理，综合应用统计学、计量经济学等分析工具对行业经济的运行状况、产品生产、销售、消费、技术、行业竞争力、市场竞争格局、行业政策等行业要素进行深入的分析，从而发现行业运行的内在经济规律，进而进一步预测未来行业发展的趋势。
政策！政策！政策！没有亘古不变的行业，要时刻拥抱变化，顺势而为，做该做的事。
2.2 市场调研
市场调研：市场调研常用手法有“定性研究”、“定量研究”、“技术观察”和“试验设计”四种。
专业的事尽量交由专业的人去做，可以有效规避企业在市场调研上所承受的风险。转移市场调研的风险，在国内有诸多知名机构可以选择，具体如下。
China Ceidea Market Research 策点市场调研公司
Acorn Marketing & Research Consultants 毅群市场研究咨询股份有限公司
上海伊霍珀信息科技股份有限公司
北京新数易博（EBMRS）信息咨询有限公司
华通明略（MillwardBrown ACSR）信息咨询有限公司 中机系（北京）信息技术研究院
中国商业数据中心
尼尔森市场研究中心
数字100市场研究公司
益普索（中国）市场研究咨询有限公司
凯度（中国）购物者指数（Kantar Worldpanel Chin- a）
上海AC尼尔森市场研究公司
盖洛普（中国）咨询有限公司
华南国际市场研究公司
百维数元信息科技（北京）有限公司
艾斯艾（北京）市场调查有限公司（SSI China）
欧睿（Euromonitor）市场调查机构
2.3 竞品调研
竞品调研：主要是对导入期竞争对手的市场经营情况与策略进行深入的调研分析。竞品分析一词最早源于经济学领域。市场营销和战略管理方面的竞品分析是指对现有的或潜在的竞争产品的优势和劣势进行评价。这个分析提供了制定产品战略的依据，将竞品分析获得的相关竞品特征整合到有效的产品战略制定、实施、监控和调整的框架当中来。
竞品分析包含了三部分内容：竞品选择、分析维度和分析准则。
竞品选择
竞品选择的范围并不局限于具有直接竞争关系的产品，以iPad版即时通讯应用为例，除了QQ、MSN等产品以外，我们还需要选择一些国外的产品如IM+、AIM、IMO等优秀且受众群体较大的产品。
分析维度
通常我们进行竞品分析，可能会从以下几个维度进行对比分析：战略定位、盈利模式、用户群体、产品功能、产品界面（交互方式、视觉表现）等。
竞品分析是每一个互联网从业人员都需要做的一项基本工作，不同的职能区分，侧重点会不一样。如运营人员可能更加侧重产品的战略定位、盈利模式、推广方式，产品策划人员更侧重于产品定位、目标用户、产品功能。交互设计师更侧重于产品界面、具体的交互形式。当然这些维度是有机联系的，断然不可以孤立对待。
分析准则
拿交互设计的竞品分析来说，需要参照“可用性准则”来进行分析，可用性准则有很多不同版本， 当前较为常用的10项可用性准则为：
一致性和标准性；
通过有效的反馈信息提供显著的系统状态；
方便快捷的使用；
预防出错；
协助用户认识，分析和改正错误；
识别而不是回忆；
符合用户的真实世界；
用户自由控制权；
美观，精简的设计；
帮助和说明。
3 原型开发阶段（PROTOTYPE）
原型开发阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。
决策委员会负责【成立原型小组】，交由对应的项目组和研发进行【原型版本制作】，完成制作后，交由专家评审组进行【原型专家评审】，通过专家评审后，交由决策委员会进行【立项决策评审】。
评审期间，立项决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入立项流程。
“原型开发阶段”对应咱们日常工作中的“需求澄清”和“需求设计”。
3.1 需求澄清
需求澄清：通过具体的方法论，澄清需求本身，消除项目参与人员对需求的认知差异。
需求池（Demand pool）
需求池（Demand pool）需求池将需求列成合同式的文件，最常见的方式是将需求列入一个合同式的表。
功能需求点列表(Function List)
功能需求点列表(Function List) 在功能需求分析完成后。要详细列出用户需求功能点列表。
用例图（use case diagram）
用例图（use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。
尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示，因此被誉为“搭建系统的蓝图”。
由于其简单纯粹的本质，用例图是项目参与者间交流的好工具。用例图的画法是对现实世界的一种刻画，可以让项目参与者明白系统要做成什么样。箫庆龙等（Siau and Lee）曾研究是否存在用例图不适用或不必要的情景，结果发现用例图可以更简洁地传达系统的设计意图，“比类图诠释得更加完整”。
用例图的目的就是为了可以让人在一个更高的层次概览整个系统，用平白的话语让项目参与者理解系统。它可以辅以额外的图表和文档，以更加完整地展现系统的功能和技术细节。
流程图（Flow Charts）
流程图（Flow Charts）是表示算法、工作流或流程的一种框图表示，它以不同类型的框代表不同种类的步骤，每两个步骤之间则以箭头连接。这种表示方法便于说明解决已知问题的方法。流程图在分析、设计、记录及操控许多领域的流程或程序都有广泛应用。
弄清楚用例图中的这些角色，在系统中每一步需要走什么流程，对应不同的判断状态进入怎样的子流程，是否支持逆向操作
产品整体架构图
产品架构图暂无一个标准答案。这里我们借鉴软件架构的解释来参考：软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
产品信息结构图
产品信息架构图暂无一个标准答案。个人认为，产品信息结构图就是告诉研发有什么关键信息，同时给需求提出者自查的一份文档。
3.2 需求设计
需求设计一般指的是设计“原型文档”和“PRD文档”。
在日常的工作中，时间紧任务重的项目，通常在绘制原型图的时候，专门备注了对应的说明文档。这样做的目的是为了方便研发人员快速理解需求，跟上快速迭代的节奏。
4 产品开发阶段（ALPHA）
产品开发阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。
①决策委员会负责【成立项目组】，交由对应的项目组和研发进行【PRE-ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再交由专家评审组进行【PRE-ALPHA专家评审】，通过专家评审后，交由决策委员会进行【PRE-ALPHA决策评审】，通过后交由运营准备【内部转产】。
②项目组和研发进行【ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【内测规划及准备】，下一步再交由专家评审组进行【产品内测上线专家评审】，通过专家评审后，交由决策委员会进行【P产品内测上线决策评审】。
③项目组和研发进行【总体运营规划】，交由专家评审组进行【总体运营规划专家评审】，通过专家评审后，交由决策委员会进行【总体运营规划决策评审】，通过后研发和运营准备【封测上线发布】并收集【封测运营反馈】，用于矫正项目组和研发进行【ALPHA版本制作】。
评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入内测阶段。
5 内测阶段（CLOSE BETA）
内测阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。
①项目组和研发进行【版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【正式运营规划及准备】，下一步再交由专家评审组进行【正式运营上线专家评审】，通过专家评审后，交由决策委员会进行【正式运营上线决策评审】。
②运营负责【产品内测上线发布】、【内测运营服务】以及【内测运营反馈】。交由对应的项目组和研发佐证【版本制作】，通过后交由研发和项目组负责【正式运营规划及准备】。
评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。
6 正式运营阶段（OPERATION）
正式运营阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。
①项目组和研发进行【版本制作】，完成制作后，先自行进行【小版本评审】，再交由运营负责【正式运营上线发布】、【正式运营服务】以及【正式运营反馈】如有问题自行修订，再交由项目组和研发安排【运营结项计划和准备】，下一步再交由专家评审组进行【正式运营结束专家评审】，通过专家评审后，交由决策委员会进行【正式运营结束决策评审】，通过后交由运营负责【正式运营结项准备】，准备进入结项阶段。
②在【小版本评审】通过后，交由专家评审组进行【大版本评审】，通过后交由研发和项目组进行【版本制作】。
评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。
7 结项（CLOSE）
结项阶段主要由“运营”负责。
确认项目进入结项阶段后，交由运营负责【产品下线】，OVER。
结项是一个项目的尾声，难免有种飞鸟尽良弓藏的感觉，这是正常的。
一方面，有“柯达”这样相当优秀的企业，带着遗憾离场，他没做错啥，只是不被大家所需要。
另一方面，正是有数不清的产品被干掉，咱们产品的存在才被衬托得更有意义。那为什么不去拥抱变化，选择去创造更能经得住时间检验的产品！
尾记
产品经理他可以是一个改变世界的神，他也可以是一个普通人。
本文作者:张小豪 来源:异世治人录
CIO之家 www.ciozj.com 微信公众号:imciow