互联网公司有千万种，产品经理却只有一种。产品经理和各行各业的创意者一样，是一群最富有创造力的群体，不同是产品经理创造的是互联网应用（系统、软件或应用等等）。虽然，各公司的产品经理职责约束存在差异，但是产品经理的基本工作却大同小异。本文结合5年来得工作经验，总结产品经理在互联网项目中的基本工作如下，仅做参考。
1 目的
产品经理工作规范是指导产品经理快速熟悉工作流程，明确项目活动各节点产品经理的工作目标、任务及输出，促进产品经理对产品的计划性、规范性、系统性管理的说明文档。
产品经理工作规范配套的规范包括：需求过程管理规范、产品原型设计规范、版本发布流程规范以及产品经理考核指标等。
2 适用范围
本规范由产品经理部负责制和修订，本规范影响范围包括：产品经理和项目组等。
3 角色和职责
产品总监/主管
产品经理
项目经理
开发组
测试组
配置管理组
需求评审组
4 过程说明
图 1产品经理工作流程图
产品经理的工作流程关系产品的生命周期和项目管理，上图是对产品经理工作流程及各节点成果的描述，后续章节做详细介绍。
5 输入
项目已启动或者计划启动。
6 活动
6.1 需求调研
6.1.1. 活动
需求调研的目标是充分研究市场、用户和公司战略，明确产品的定位、用户和价值等。为了保证需调研的有序进行，产品经理应编制需求调研计划表。需求调研工作内容包括：市场调研、用户调研和文献调研等。产品经理应保存各类需要调研的原始材料（如：需求单、运营数据报表）为后续产品定义提供基础，并负责编制《需求池》对原始需求进行跟踪管控。需求调研完成后，进行系统性的总结形成《需求分析报告》。需求调研活动应遵循《需求过程管理规范》。
注：需求调研阶段，推荐邀请项目各口主管参与，了解需求调研工作，为后续相关的活动的开展提供基础。
6.1.2. 输出
需求调研计划表
需求原始材料
需求分析报告（RAR）
需求池
6.2 产品定义
6.2.1. 活动
产品定义的核心目标是将用户需求转化为产品需求，定义产品的功能、边界和作用。产品定义阶段，产品经理应基于需求调研成果：《需求池》和《需求分析报告》，将需求固化为《需求跟踪矩阵》和《需求规格说明书》，并输出高保真产品原型。需求文档直接构成系统设计和测试的基础和依据，高保真产品原型是对需求的可视化呈现，可直接指导视觉设计、产品开发和测试等工作。
高保真产品原型设计过程中，一般需要邀请用户/项目组进行测试/体验，暴露产品原型设计中的用例缺陷和交互缺陷等，并评判产品原型是否满足需求调研成果。经过多次的产品原型测试和修正，保证产品原型的可用性。产品原型设计应遵循《产品原型设计规范》。
6.2.2. 输出
需求跟踪矩阵（RTM）
需求规格说明书（PRD）
高保真产品原型（源文件及HTML文件）
注：需求跟踪矩阵有2种模板，内部项目推荐使用EXCEL模板，外部项目推荐使用WORD模板。
6.3 需求评审
6.3.1. 活动
需求评审的主要目的有2个方面，一方面是需求的阐述与理解，另一方面是评审需求的一致性、准确性和完备性。需求评审的会议材料包括：《需求跟踪矩阵》（必备）、《需求规格说明书》和高保真产品原型（必备）。需求评审分为产品组评审（内审）和项目组评审（外审）2个环节，只有通过内审后，才能发起外审。内审推荐3~5名产品经理参加，外审参与方包括：客户/用户代表、产品经理、项目经理、UED设计师、测试经理和相关的技术人员等。
需求评审会议应由产品经理组织，每次需求评审会议结束后，需要根据评审意见修订需求文档和高保真产品原型，然后继续组织评审会议，直至3/4或以上成员无意见通过。
6.3.2. 输出
评审报告/会议纪要
6.4 版本计划
6.4.1. 活动
版本计划的主要目的是配合公司战略、市场运营和关联产品等计划或目标，结合产品自身的路线和目标，规划需求的优先级和范围，形成一个计划版本。产品经理需要优先提出《版本计划表》草案及配套的需求文档，然后组织相关人员进行评审，形成正式的版本计划，自此正式进入的产品研发阶段。完成版本计划后，产品经理应将需求录入Phabricator，形成产品积压。
需求池实现原始需求的跟踪管控，需求评审实现将原始需求进行固化，版本计划实现将固化需求的进行优先级排列，并确定一个可执行的范围。然后为项目组准备项目计划提供基础。
注：版本计划形成有2种方式：
计划型：即基于需求池优先确定版本计划，然后组织产品定义、需求评审和项目计划的实施。此方式比较容易保证活动和成果的一致性；但是弹性较弱。
迭代型：产品定义和需求评审是一个连续的、动态的过程，然后根据需要组织版本计划评审，形成计划版本。此方式比较灵活能够快速响应市场需求，推出版本；不足在于产品定义和需求评审比较碎片化，不便于形成完整成果进行评审，版本计划的配套需求文档基于多次的需求评审结果组合而成。
6.4.2. 输出
版本计划表
Phabricator产品积压
6.5 项目计划
6.5.1. 活动
项目经理基于版本计划和配套的需求文档，组建/组织项目组、分配研发任务、评估项目周期，输出《项目计划》。接下来，项目组将按照项目计划进行开发、测试和验收等工作。
注：一般一个版本配套一个项目计划，一个项目计划可能包含多个迭代，一个迭代一般2~4周。
6.5.2. 输出
项目计划
项目报告（按需）
6.6 视觉设计与评审
6.6.1. 活动
视觉设计和评审是与产品经理日常工作密切相关的活动，视觉设计由UED设计师负责。产品经理应与UED设计师保持良好沟通，保证视觉设计工作满足产品需求。产品经理与UED设计师的通过产品经理输出的《视觉设计需求》表格进行工作衔接，UED设计师接受《视觉设计需求》后，需要响应设计说明和完成任务的时间节点。
视觉设计完成后，UED设计师需要先组织UED组内审，然后组织项目组评审，参与视觉设计评审的主要人员应包括：客户/用户代表、产品经理、项目经理、UED设计师、测试经理和相关的技术人员等。UED设计师输出定稿PSD文件后，交付项目组进行页面编码，同时需要输出相应的视觉设计规范，必要时还需负责页面切图。
注：产品经理输出的高保真产品原型不能满足复杂的交互时，应进一步交付给交互设计师进行产品原型交互设计，并组织交互设计评审。
6.6.2. 输出
PSD文件
JPG文件
页面标注及切图（按需）
视觉设计规范
评审报告/会议纪要
6.7 编码与测试
6.7.1. 活动
编码与测试是研发活动重要内容，是与产品经理日常工作相关的活动。项目计划启动后，产品经理应对产品的研发情况进行跟踪，积极配合开发工程师和测试工程师的工作，答复编码测试阶段关于产品需求和界面交互的各类问题。
编码与测试阶段，项目组开发工程师依据需求文档、产品原型和视觉设计稿等，进行系统架构设计输出《软件设计文档》及编码；测试工程师编制《测试计划》和《测试用例》，并组织各迭代提测版本测试工作，完成测试工作后，由测试经理组织编写《测试报告》。
注意：编码阶段，一般需要组织设计文档评审。测试阶段，一般需要组织测试用例评审，必要时需要组织BUG评审。
6.7.2. 输出
软件设计文档
数据库设计文档
接口设计文档
迭代版本
可发布版本
测试计划
测试用例
测试报告
6.8 产品体验
6.8.1. 活动
产品体验活动是一个持续的活动，每位产品经理都应是产品的首席体验官。产品经理需要积极体验每个迭代提测的版本，验证需求是否实现，软件是否稳定等，并输出《产品体验报告》。产品体验可邀请项目组和其他产品经理共同参与。
注：广义的产品体验不仅包括提测版本的体验，还包括竞品的体验等。
6.8.2. 输出
产品体验报告
6.9 版本发布
6.9.1. 活动
编码测试阶段输出可发布版本后（注：可发布版本由测试经理认定），一般由产品经理或者项目经理组织产品发布会，版本发布活动应遵循《版本发布流程规范》。
产品发布会有2种情况，一种是公司内部版本发布会，另一种是对外版本发布会。公司内部版本发布会要求输出：《版本申请表》《版本说明书》《安装包或运行包》《安装部署手册》《用户使用手册》等必备材料，其中，《版本说明书》和《用户使用手册》由产品经理负责编制；对外版本发布会是面向市场和公众的发布会，需要进行整体策划，除了准备项目必备的材料的外，还需根据策划案输出相关的宣传物料。
注：版本发布前，产品经理经进行材料归档，产品组SVN归档材料包含但不限于：需求跟踪矩阵、需求规格说明书（C端产品可选）、高保真产品原型（源文件）、产品功能思维导图（源文件）、用户使用手册、安装部署手册。
6.9.2. 输出
版本申请表
版本说明书
安装包或运行包
安装部署手册
用户使用手册
6.10 项目考核
6.10.1. 活动
项目计划结束后，将组织项目考核，一方面是公司对项目实施情况进行考核（具体参考相关制度），另一方面是项目组经理对项目成员的考核。其中，项目成员绩效考核结果分为2个部分：一部分是来自职能组主管（如产品主管），一般占30%权重；另一部分来自项目经理，一般占70%权重。
产品经理需要对需求进行度量统计，输出《需求度量统计报告》，并需通过项目经理确认，同时按照项目要求做好相关材料归档。组内考核由产品部经理（主管）负责，从产品经理的工作态度、输出物规范程度和质量、产品组团队协作、产品组团队贡献等维度进行综合考核。
6.10.2. 输出
各类统计报表（产品经理：需求度量统计报告）
项目成果物
项目成员考核表
产品经理内部考核表
7 输出
表 1项目主要成果物清单
注：以上成果物清单仅供参考，项目成果物归档以项目需要为准。项目组归档材料还应包括各节点的评审报告、会议纪要、各类统计报告、源代码和安装包等。
8 测量和分析
对需求管理活动进行测量，并将测量结果用于确定软件策划活动的状态。
要进行如下测量：
项目需求度量，对原始、增加、删除、修改的数量统计和分析，通过检验《需求度量统计表》考评；
需求文档规范度和质量的度量，包括：文档编制规范度（参照相关模板和规范）、文档一致性、准确性和完备性，通过检验需求文档考评；
产品原型设计质量度量，产品原型输出时效性，产品原型设计规范度，通过检验产品原型源文件和产品原型HTML页面考评；
9 验证实施
- 产品部经理（主管）定期或事件驱动地参与评审需求的管理活动。
- 产品部经理（主管）定期评审软件项目计划活动的执行状况，并解决相关的问题。
- 项目经理定期或事件驱动地参与检查、评审软件需求的管理活动。
- 需求评审团通过参与评审活动监督需求管理和产品定义等。
- 测试组在新版本提测后，定期向项目经理报告版本质量和测试结果。
