整体管理流程

整体项目开发流程

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

1. 需求管理阶段：包含需求的采集、分析和筛选，主要由产品经理进行日常的产品/用户需求收集，并制定相关的版本迭代计划；
2. 产品设计阶段：包含产品方案的设计和产品需求评审，主要由产品经理输出PRD文档，并组织相关同事进行需求评审会议；
3. UI 设计阶段：包含UI设计稿的整理和输出，主要由UI设计师操刀完成设计稿，并组织相关同事进行UI设计稿的评审会议；
4. 产品研发阶段：包含架构设计、代码设计、代码实现等，主要由前、后端工程师完成产品架构、页面及逻辑的相关开发；
5. 产品测试阶段：包含功能性测试和性能测试等，主要由测试工程师撰写测试用例，并在测试完成后输出测试报告；
6. 产品上线阶段：包含灰度发布和全量发布，主要是项目负责人来确定具体的发布时间和发布渠道。
   

3. UI设计阶段

（1） UI设计简介
UI设计阶段主要由UI设计师来完成，包含做界面的视觉设计，进行布局、配色、样式不同风格的尝试等。
（2）参与人员及职责
UI设计阶段主要由UI设计师、产品经理等进行参与：

• UI设计师：完成UI设计稿的设计、进行UI设计稿的评审宣讲等。
• 产品经理：对UI设计进行相应的把控。

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

• 整体方面：
  设计理念是否与产品定位符合，整体风格是否与产品气质相符；
  色调搭配是否舒适，整体的色调是否保持一致规范；
  版面样式是否平衡，有没有存在一边倒的设计，或者整体不够协调；
  内容层级是否清晰明了。
• 细节方面：
  设计元素的选择是否与整体风格搭配，包括大小，色彩，质感等；
  图标、button等元素是否与整体界面统一和谐；
  文字、元素等细节是否存在冗余或错误、遗漏等。

（4） 文档输出

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

4. 产品研发阶段

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

（2）参与人员及职责

• 前端工程师：搭建前端框架，根据原型设计稿/UI设计稿实现产品前端的静态页面，在静态页面的基础上绑定数据接口；
• 后端工程师：搭建后端框架，结合需求文档提供产品功能所需的各类接口，并与前端一起进行接口调试工作；
• 算法工程师：搭建算法框架，为产品提供算法方面的研发工作。

（3）代码库管理

① 代码库权限分配
使用公司内建的GitLab保存和管理属于本公司的代码资源；
公司总技术负责人和项目直接负责人有项目的Master权限；
负责项目的权限管理；
项目内人员管理；
受保护分支的操作；
参与项目研发的技术人员设置为Developer权限；
白盒测试人员和相关人员设置为Guest权限。

② 代码库分支管理方法

• 分支:
  为项目创建 release(或相同职能的其它名字) 分支， 专用于发布生产环境；
  创建develop(或相同职能的其它名字)分支， 专用于测试环境发布；
  Master分支用于备份release分支发布的最后一次稳定版代码. 用于灾备；
  将release和master分支设置为受保护的状态. 只有master权限的管理人员可以合并， 提交这两个分支的代码，并且在合并提交代码的过程中对代码review 并留痕。

• 使用：
  开发人员每次任务都需要创建针对此次任务的开发分支(仅供个人使用)；
  每个开发人员(不同的开发分支)可以在任何时间将代码合并至develop分支，并由有权限的人员发布到测试环境。如果develop分支有任何异状，可以随时删除并重建同名分支，这个分支不用担心被污染。
  开发分支的代码全部开发完成，并在develop分支测试通过后。需要各个开发人员发起向release分支的merge request， 由项目负责人code review并完成合并（留痕）。如有冲突需要具体开发人员配合项目负责人解决冲突。
  代码合并至release分支后，需要经过回归测试。无误后由项目负责人发布至生产环境。
  

  

5. 产品测试阶段

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

（2）参与人员及职责
产品测试阶段主要由测试人员和开发人员进行参与：

• 测试人员：了解项目背景，熟悉产品的需求，通过产品需求文档来编写产品的测试用例，组织和邀请相关人员进行产品测试用例的评审会议，在会议上测试人员向其他参与人员讲解自己测试用例的编写原理。会议之后，测试人员对产品进行测试，在测试之前，需要向产品经理确认当前测试版本的版本号与版本名，并跟踪提交的测试缺陷。
• 开发人员：对测试人员找到的缺陷进行代码修复。
• 项目成员：所有项目成员在测试过程中都应尽量参与测试，提出发现的bug，让产品在上线前得到完善。
  （3）测试用例评审会议
  测试用例的评审会议由测试工程师组织相关项目人员进行参与，会议过程应该着重于如下几点：
  测试用例本身的描述是否清晰，是否存在二义性；
  是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
  是否覆盖了所有的产品需求；
  是否完全遵守了产品设计需求的规定，即与PRD文档匹配。
  （4）文档输出
• 测试用例文档：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试产品是否可以正常上线，测试用例文档做好标注需上传到TAPD文档管理中心。
• 产品测试报告：测试报告是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正产品存在的质量问题提供依据，同时为产品测试验收和交付打下基础。
  测试报告包含了测试目的、项目背景、测试安排、测试方案、测试结果、缺陷分析、测试总结等要素，完成撰写后同样需要上传到TAPD文档管理中心。

6. 产品上线阶段

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

（2）参与人员及职责
产品上线主要参与人员包含项目负责人、产品经理、开发等。

• 项目负责人：确定项目的发布版本、发布时间及发布渠道；
• 产品经理：上线前做最后的回归测试，及时发现明显的bug，撰写好产品发版说明；产品上线后，撰写产品上线发版邮件进行项目全员通知；
• 开发工程师：进行封版工作，同时经过项目负责人同意后在钉钉上提交发版申请。
  （3）灰度发布
  所谓灰度发布，是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈，以及对新版本功能、性能、稳定性等指标进行考核和评定，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
  （4）文档输出
• 产品发版说明：产品上线后的发版说明，包含产品更新的功能、范围等，发版后需要发布发版邮件来进行项目全员通知；APP产品通过应用商店渠道进行发版，还要撰写更新说明；
• 灰度测试报告：结合灰度版本的发布情况，撰写灰度测试报告，包含产品数据总结、用户反馈总结等，并阐述下一步具体行动方案。

来源：翠玲的菜园子