互联网产品研发模式与效能提升指南 - 5.1.工作模式设计——需求处理
本章是基于互联网产品的特点和前文的组织架构，结合团队协作工具，对产品研发过程中核心职能的工作模式设计。
对于业务线和公线的需求来说，从决定做一个需求（选择一个机会）开始，直到需求上线，这是一个端到端的过程，需要拉通产品、开发、测试、运维等各个前后职能环节的同时，通过用户价值（需求），作为团队间对齐的目标，让团队可以基于一个约定的流程，朝着共同的目标，顺畅的完成各职能团队的职责，建设持续发布价值的机制，降低需求的开发和交付的周期，提升价值交付的吞吐率（单位时间交付用户需求的数量）。
需求的处理流程
关键点说明
【节点】需求选择：组织团队从众多潜在的机会中，选择接下来需要投入的需求，这是价值流的起点，是一个同时具备阶段性（批量）和随机性（随时）开展的工作。这个节点的输出是一个从需求池筛选后拟定了优先级和版本规划（期望的排期）的需求列表。需要注意的是，对需求粒度的控制应该符合产品迭代的规划，对于相对固定的迭代周期，那么需求的粒度应控制在一个迭代可以完成，对于持续交付的方式来说，需求的粒度应控制到可在一周左右交付。对那些大的、周期长的需求，应进行拆解，分为若干小需求，分几个迭代交付；对一些因技术因素不确定的需求，应使用后文中的“规划、预研类需求处理流程”，发起预研，将不确定的点明确后，需求再进入就绪状态。
【节点】需求分析：对选择的需求逐一进行需求分析设计，过程中，与需求的提出方或业务相关方商议，最终形成产品需求文档（PRD），作为后续系统设计的输入。通过了需求分析评审后，若需求有变更，则需要修订PRD，并将修订向相关人员澄清，团队根据修订，调整设计和开发任务。
系统设计阶段：当需求评审通过后，进入系统设计阶段。相关角色根据PRD，进行软件、产品、测试用例的设计。
其中，系统分析设计的主导团队会根据业务中台成熟度决定，在成熟度较低的阶段，由公线类职能组织主导概要设计，敏捷开发团队配合，并在概要设计的基础上，完成详细设计，待成熟度较高时，由敏捷开发团队主导业务系统设计工作，相关公线研发组协助。
经过这个阶段，需求应该已经被澄清和处理，对技术团队就绪，等待进入实现阶段。
【节点】产品设计：这个节点的工作，可以合并至需求分析阶段，也可以在需求评审之后进行，在需求评审之后进行的好处是需求原型的变更概率会小，避免过多的反复修改产品设计。
【节点】任务分解评估排期：这是一个组内讨论的过程，由敏捷教练根据系统分析设计结果，将需求细化拆分为开发任务（创建关联需求的任务卡片，移动需求和任务卡片至“就绪”看板），并组织研发工程师讨论任务的认领和排期，明确任务的迭代、工期、优先级、处理人。
【节点】就绪：就绪是一个重要的阶段，它决定了开发团队的输入质量。到达这个节点的需求，已经被分解为具体的开发任务，规划了任务排期，但还未进行相关任务的处理。产品经理可根据排期，确认或调整需求的里程碑规划。
【节点】处理开发任务：开发团队从就绪的需求和任务中，选择要开始开发的，根据子流程的设计，完成任务。
【节点】发布：触发产品发布的条件有多种，如：完成全部需求、里程碑截止、提前发布版本、紧急需求上线、线上Bug修复等，产品经理和敏捷教练关注里程碑的完成度，综合各种因素，决定是否将已完成的需求，发布给用户。
敏捷教练要在整个流程中，发现价值流动过程中的问题，并及时推进解决，确保价值流动的顺畅程度处于较高水平。
关键会议说明
会议的形式不限，要做到简洁、有效
产品设计评审（需求澄清）会
- 主持：产品经理
- 参与：敏捷团队全员、公线研发组负责人、质量控制组、运维组
- 目的：对需求进行澄清，对齐实现目标，并评估是否可以进入到系统设计阶段
- 输入：PRD（产品需求文档）
- 输出：PRD修订记录
- 决议：是否进入系统设计阶段（有些无需进行软件设计的需求可直接进入就绪状态）
第一次评审采用集中讨论方式，修订后的评审只做修订结果的通知
技术设计评审会
- 主持：技术经理或敏捷团队主程
- 参与：技术团队全员、公线研发组、质量控制组
- 目的：宣讲系统设计的结果，评审设计是否有问题
- 输入：PRD、UI设计、软件概要设计、测试用例设计
- 输出：各个设计成果的修订记录
- 决议：需求是否进入就绪状态
需求验收（阶段）
- 主持：产品经理
- 参与：管理执行委员会、相关业务团队
- 目的：对研发结果进行验收，检查是否存在需求偏离；将本次迭代要发布的需求和可能的影响同步至负责统筹工作的团队；
- 输入：上线申请、部署文档
- 决议：是否上线
迭代复盘会
- 主持：敏捷教练
- 参与：敏捷团队全员
- 目的：总结本次迭代中的各项效能指标，执行过程中的问题及优秀实践，对团队公布，讨论改进措施，收集反馈意见。
- 输出：迭代报告
[子] 开发任务的处理流程
当需求进入就绪状态后，可由团队成员自行进行需求的认领，并自行分解，也可由敏捷教练或主程统筹分配。根据分支管理方式的不同，分为“单分支方式”和“特性分支方式”，可根据需求和团队情况自行选择合适的方式，但推荐特性分支方式：
单分支方式
关键点说明：
单分支处理方式要确保后端系统与前端系统对接的兼容性，才可做到多产品的灵活发布，满足持续发布的节奏。
【节点】任务部署：敏捷教练通过组内的每日站会，盘点开发中的需求和任务进度，调整优先级，对需要进入开发中的就绪需求及相关任务进行部署。
【节点】完成：需求关联的任务全部完成后，需求进入到了完成状态，可以将需求提交进行测试。
对进入此节点的需求，可进行两个辅助性任务：对提交的代码进行评审、关闭需求关联的任务卡片。
对于代码的评审，是提高代码质量，发现代码问题的，团队学习提升的辅助手段，可按单个需求的维度，也可按固定的周期，按技术栈分组，在组内组织技术团队，对编写的代码逐一进行讲解。
可利用GitLab中Group的Activity，对提交点操作进行评审并留言评论。
将代码部署至开发环境或测试环境，由DevOps套件提供持续集成的能力，其中，部署测试环境时，对变更的代码要自动创建release分支（在打包要发布到生产环境的工程时，要从release分支创建tag）。
特性分支方式
与单分支方式开发的主要区别：
- 【节点】按任务要求编写代码
- 单分支：在master中编写代码；
- 功能分支：按照需求编号从master创建功能分支，在功能分支中按任务要求编写代码；
- 代码评审固定在合并功能分支至release时进行
- 通过合并功能分支到各个发布分支，完成各环境的发布
- 发布到打包之间，需要进行分支的合并
优劣对比
| 单分支方式 | 功能分支方式 | |
|---|---|---|
| 复杂度 | 优 | 高 |
| 灵活发布 | 良 | 良 |
| 人员能力要求 | 低 | 高 |
“灵活发布”与“复杂度”和“人员能力要求”成正比例关系
微服务架构，工程数量很多，通常一个开发任务可能会关联多个工程，这会增加分支管理的复杂度。可以考虑使用Google的方式，将各个工程放到一个代码库中（甚至包括前端工程），可以大幅降低复杂度，相应的DevOps套件就需要更好的适应一个repo库中多个子工程的构建处理方式。
[子] 部署任务的处理流程
根据产品的不同、DevOps套件的不同，产品的部署处理方式存在差异，对此流程应根据自身实际情况进行调整。
本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。
1.引言
2.几个重要的观念
3.形而上
4.设计组织架构
5.1.工作模式设计——需求处理
5.2.工作模式设计——迭代规划
5.3.工作模式设计——其它事务
6.建立可视化协作机制
7.进行评估和激励
8.附录