在大厂里，高级产品经理都在用的项目管理流程.pdf

1、文档制定目的

本文档的制定，主要是为了规范公司不同项目组之间，产品、设计、研发、测试等童鞋的工作标准和协作流程。通过实施完整的产品研发管理流程，做到在重点环节都有相应的工作文档产出及任务记录作为项目进展的沉淀，尽量减少人为因素对整个项目的干扰和影响。

2、整体项目开发流程

互联网产品整体研发管理流程如下图所示，具体包含6个环节：

• 需求管理阶段：包含需求的采集、分析和筛选，主要由产品经理进行日常的产品/用户需求收集，并制定相关的版本迭代计划；

• 产品设计阶段：包含产品方案的设计和产品需求评审，主要由产品经理输出PRD文档，并组织相关同事进行需求评审会议；

• UI 设计阶段：包含UI设计稿的整理和输出，主要由UI设计师操刀完成设计稿，并组织相关同事进行UI设计稿的评审会议；

• 产品研发阶段：包含架构设计、代码设计、代码实现等，主要由前、后端工程师完成产品架构、页面及逻辑的相关开发；

• 产品测试阶段：包含功能性测试和性能测试等，主要由测试工程师撰写测试用例，并在测试完成后输出测试报告；

• 产品上线阶段：包含灰度发布和全量发布，主要是项目负责人来确定具体的发布时间和发布渠道；

3、项目管理工具

3.1 TAPD协作工具

公司的项目管理工具，使用腾讯开发的TAPD敏捷协作平台。

TAPD强大的项目管理和协作功能，包含故事墙、迭代、看板、缺陷管理、在线文档等（具体功能及作用可查看TAPD帮助手册https://www./help）可以方便地支持互联网产品的整个项目开发流程，尤其是对于敏捷开发的项目团队来说，更是一款不错的支持产品快速迭代的工具；

实施之前，需要由项目负责人在TAPD内创建一个项目，并邀请自己的项目组成员进入到这个项目，这样就可以开始自己项目的团队协作之旅了。

3.2 每日项目站会

项目站会对于敏捷开发的互联网团队来说是非常有必要的一种会议，可以在每天上午10点进行召开，时间不宜过长，通常在15-20分钟以内结束，会议的主要内容就是项目参与人阐述各自完成的任务，包括：

• 昨天都做了什么；

• 今天打算做什么；

• 遇到什么问题和挑战；

会议过程中，项目负责人可以结合进度及任务优先级，对项目成员的任务做相关调整；项目站会结束后，项目负责人可将每日站会小结发到微信群里，将项目进展信息同步给所有人。

4、具体实施流程规范

4.1 需求管理阶段

4.1.1 需求管理简介

需求管理阶段为产品迭代的初始阶段，产品迭代都是从需求出发。具体来说，需求管理包含如下几个阶段：

• 需求采集：可以通过市场调研、竞品分析、用户反馈、数据分析、老板/同事反馈等

• 收集产品用户需求或技术型需求；

• 需求分析：通过场景分析法、kano模型等来进行分析；

• 需求筛选：将分析过的靠谱需求筛选出来，制定产品新一版的迭代计划或长期的版本迭代计划；

4.1.2 参与人员及职责

需求管理阶段的参与人员主要是产品经理，当然项目里的任何一个成员都能提出自己的产品需求建议（包含技术工程师提出的代码优化需求等），具体职责如下：

• 项目成员：任何一个项目成员都能提出自己的产品需求；

• 产品经理：负责需求的采集、分析、筛选，负责管理和维护产品需求池，并制定版本迭代计划；

4.1.3 需求池管理

产品需求池管理采用TAPD项目中的需求模块，每一个项目成员（尤其是运营、业务人员）都可以创建一个产品需求反馈给到产品，注意在创建需求时不要将需求归入到某一个迭代中；查看需求池的时候，只需将查看视图切换到【待规划需求Backlog】即可查看全部需求状况。

4.1.4 文档输出

• 版本规划文档：产品经理在需求管理阶段需要输出产品近期的一个版本迭代规划，如最近一个月，或一个季度的大致路线规划，并且需要将版本迭代规划文档上传到TAPD的文档管理中心，和项目成员一起进行分享；

• 市场调研文档：产品经理做的市场调研、用户访谈、竞品分析等一系列工作所产出的文档，同样，需要将这些文档上传到TAPD中进行管理；

4.2 产品设计阶段

4.2.1 产品设计简介

产品设计阶段主要由产品经理将需求转化为产品方案的输出，包含基本的功能流程设计、原型设计、PRD文档撰写等工作。

4.2.2 参与人员及职责

产品设计阶段主要由产品经理参与：

• 产品经理：负责输出整体产品方案设计，包含需求背景、需求目标、及具体产品方案等；完成PRD文档的撰写后，需要组织和邀请相关人员进行产品需求评审的会议，在会议上阐述清楚自己的产品方案。

4.2.3 产品需求评审会议

由产品经理来进行组织的一次会议，需求评审目的是让项目的参与者（这里主要指设计研发测试）能够快速理解产品的意图，认可采用的方案。当然，需求评审并不是说谁要说服谁，而是我们要就一个具体问题寻找到最优的解决方案。

关于需求评审的推进步骤：

• 先说我们这次需求的目标与目的；

• 在目标与目的达成一致的基础上，阐述具体的产品解决方案；

经过讨论后，产品经理整理好会议结果进行邮件通知，如果PRD方案调整较小则可以不用进行第二次需求评审，如果方案调整较大建议进行第二次需求评审；

4.2.4 文档输出

• PRD文档：也就是产品需求文档，主要由产品经理撰写，包含产品背景及目标说明、全局说明、产品详细方案说明等模块，整理完毕后需上传到TAPD文档中心进行留存；

• 评审会议邮件：评审会议开完后，需要将会议记录和结果做一个邮件通知抄送给所有的参与评审会议的人员，方便大家了解评审会议的最终结果；

4.3 UI设计阶段

4.3.1 UI设计简介

UI设计阶段主要由UI设计师来完成，包含做界面的视觉设计，进行布局、配色、样式不同风格的尝试等；

4.3.2 参与人员及职责

UI设计阶段主要由UI设计师、产品经理等进行参与：

• UI设计师：完成UI设计稿的设计、进行UI设计稿的评审宣讲等；

• 产品经理：对UI设计进行相应的把控；

4.3.3 UI设计稿评审会议

UI设计稿的评审可由UI设计师进行组织，也可由产品经理来协助设计师进行组织，邀请项目参与人员进行相关评审，评审内容主要如下：

• 整体方面：

• 设计理念是否与产品定位符合，整体风格是否与产品气质相符；

• 色调搭配是否舒适，整体的色调是否保持一致规范；

• 版面样式是否平衡，有没有存在一边倒的设计，或者整体不够协调；

• 内容层级是否清晰明了；

• 细节方面：

• 设计元素的选择是否与整体风格搭配，包括大小，色彩，质感等；

• 图标、button等元素是否与整体界面统一和谐；

• 文字、元素等细节是否存在冗余或错误、遗漏等；

4.3.4 文档输出

• UI 设计稿：通过设计软件进行创作的UI设计稿件，做好标注后上传到TAPD的文档管理中心；

4.4 产品研发阶段

4.4.1 产品研发简介

产品研发阶段主要是指各类型的工程师为实现产品功能、页面、逻辑所做的代码研发工作。

4.4.2 参与人员及职责

• 前端工程师：搭建前端框架，根据原型设计稿/UI设计稿实现产品前端的静态页面，在静态页面的基础上绑定数据接口；

• 后端工程师：搭建后端框架，结合需求文档提供产品功能所需的各类接口，并与前端一起进行接口调试工作；

• 算法工程师：搭建算法框架，为产品提供算法方面的研发工作；

4.4.3 代码库管理

a）代码库权限分配

• 使用公司内建的GitLab保存和管理属于本公司的代码资源；

• 公司总技术负责人和项目直接负责人有项目的Master权限；

• 负责项目的权限管理

• 项目内人员管理

• 受保护分支的操作

• 参与项目研发的技术人员设置为Developer权限；

• 白盒测试人员和相关人员设置为Guest权限；

b）代码库分支管理方法

分支:

• 为项目创建 release(或相同职能的其它名字) 分支, 专用于发布生产环境；

• 创建develop(或相同职能的其它名字)分支, 专用于测试环境发布；

• Master分支用于备份release分支发布的最后一次稳定版代码. 用于灾备；

• 将release和master分支设置为受保护的状态. 只有master权限的管理人员可以合并, 提交这两个分支的代码. 并且在合并提交代码的过程中对代码review 并留痕；

使用：

• 开发人员每次任务都需要创建针对此次任务的开发分支(仅供个人使用)；

• 每个开发人员(不同的开发分支)可以在任何时间将代码合并至develop分支, 并由有权限的人员发布到测试环境. 如果develop分支有任何异状, 可以随时删除并重建同名分支. 这个分支不用担心被污染；

• 开发分支的代码全部开发完成, 并在develop分支测试通过后. 需要各个开发人员发起向release分支的merge request, 由项目负责人code review并完成合并[留痕]. 如有冲突需要具体开发人员配合项目负责人解决冲突；

• 代码合并至release分支后, 需要经过回归测试. 无误后由项目负责人发布至生产环境；

4.5 产品测试阶段

4.5.1 产品测试简介

产品测试阶段主要由测试工程师来完成，根据由PRD文档编写的测试用例来对产品进行测试，找到产品界面、功能和不满足产品需求文档的相关bug缺陷，研发团队在这个阶段要对缺陷进行修改，测试工程师则需要跟踪缺陷的修复情况；

4.5.2 参与人员及职责

产品测试阶段主要由测试人员和开发人员进行参与：

• 测试人员：了解项目背景，熟悉产品的需求，通过产品需求文档来编写产品的测试用例，组织和邀请相关人员进行产品测试用例的评审会议，在会议上测试人员向其他参与人员讲解自己测试用例的编写原理。会议之后，测试人员对产品进行测试，在测试之前，需要向产品经理确认当前测试版本的版本号与版本名，并跟踪提交的测试缺陷；

• 开发人员：对测试人员找到的缺陷进行代码修复；

• 项目成员：所有项目成员在测试过程中都应尽量参与测试，提出发现的bug，让产品在上线前得到完善；

4.5.3 测试用例评审会议

测试用例的评审会议由测试工程师组织相关项目人员进行参与，会议过程应该着重于如下几点：

• 测试用例本身的描述是否清晰，是否存在二义性；

• 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同， 而且测试设计的冗余性，都造成了效率的低下；

• 是否覆盖了所有的产品需求；

• 是否完全遵守了产品设计需求的规定，即与PRD文档匹配；

4.5.4 文档输出

• 测试用例文档：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试产品是否可以正常上线，测试用例文档做好标注需上传到TAPD文档管理中心；

• 产品测试报告：测试报告是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正产品存在的质量问题提供依据，同时为产品测试验收和交付打下基础。测试报告包含了测试目的、项目背景、测试安排、测试方案、测试结果、缺陷分析、测试总结等要素；完成撰写后同样需要上传到TAPD文档管理中心；

4.6 产品上线阶段

4.6.1 产品上线简介

产品上线对于项目组来说是具有里程碑意义的事件，指产品代码从测试环境切换到正式的生产环境，外部的普通用户通过更新APP或者打开线上网页链接就可以直接对产品进行访问。

4.6.2 参与人员及职责

产品上线主要参与人员包含项目负责人、产品经理、开发等；

• 项目负责人：确定项目的发布版本、发布时间及发布渠道；

• 产品经理：上线前做最后的回归测试，及时发现明显的bug，撰写好产品发版说明；产品上线后，撰写产品上线发版邮件进行项目全员通知；

• 开发工程师：进行封版工作，同时经过项目负责人同意后在钉钉上提交发版申请；

4.6.3 灰度发布

所谓灰度发布，是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈，以及对新版本功能、性能、稳定性等指标进行考核和评定，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。

4.6.4 文档输出

• 产品发版说明：产品上线后的发版说明，包含产品更新的功能、范围等，发版后需要发布发版邮件来进行项目全员通知；APP产品通过应用商店渠道进行发版，还要撰写更新说明；

• 灰度测试报告：结合灰度版本的发布情况，撰写灰度测试报告，包含产品数据总结、用户反馈总结等，并阐述下一步具体行动方案；