一个优秀的研发团队是自生长的、生态化的、共建的，而不应是制度化的、命令式的、一言堂的。研发模式与技术架构一样，都是一个随着业务的发展而不断演进的过程，大家在这个过程中，清楚团队和个人的目标，并共同进行一些约定，共同维护一个良好的研发生态，让大家可以更高效、更快乐的“搞事情”，从而推动业务和团队生长。

基于互联网产品及工程师的特点（详见前文），通过团队组织架构的设计，组建生态化的研发环境，大家能够更多的参与到技术架构和研发体系的设计和建设中，围绕着共同的目标和原则，持续完善所负责的领域，衍生出一个适宜的、平衡的研发环境。从而，为灵活、高效的工作模式（详见后文）打下基础。

对于一个多产品的研发团队进行的组织架构设计，如下：

组织架构图

组织架构

平台研发中心下设2个虚拟组织和若干个职能组织。

根据业务领域（产品线）的划分，阶段性的、动态的将若干角色组建成若干跨职能的“产品（业务）敏捷团队”。团队中的产品经理与敏捷教练同时作为推动需求流动的主要监督人，但具有各自的职责和关注的方向，从研发人员池中吸纳符合业务特征的程序员，共同推进组内工作。

管控组与产品设计组两个职能组织，与各产品敏捷团队形成矩阵式组织结构，进行相关统筹和督导的工作。

研发公线类的组织会根据产品发展，按业务和技术领域的特征，阶段性的组成为新的小组（如数据分析工程研发组、XX中台产品研发组、前端中间件研发组、效能研发组等），通过对业务需求的分析，产生支撑类需求，逐渐形成对共享业务及技术中台/平台的沉淀，并反哺业务产品团队。

2个虚拟组织（管理执行委员会、架构设计委员会）则分别对业务及管理、技术领域产生的关键问题和事件，形成决策和方案。

组织架构的特点

轻管理、重协作：

扁平化，尽可能少的层级关系，通过建立合理的流程，通过职能团队间协作，自下而上的决策和推进。
小团队，组建5-9人的小团队，根据业务的需求及其擅长的领域，解决特定的问题，团队成员相对固定，对领域的熟悉度和经验的积累对于产出效率和质量有积极的影响。
自组织，团队成员通过良好的自我管理能力，并赋予一定的自主权（决策权），在既定环境（组织架构、流程、规范等）的基础上，根据产品的特点和迭代任务工作量，结合兴趣，自驱的组成团队。
重协作，基于合理的流程和可视化工具，拉通前后职能，对齐团队间目标，通过协作，持续且快速的交付价值。
多面手，在发挥团队成员擅长领域能力的基础上，调动成员的主观能动性，促进其在其它领域（角色）的能力发挥，广泛吸收其在各个环节提出的建议、方案、创新和成果；

打造技术驱动力：

中台化，共享业务和技术的通用领域能力，赋能业务团队，提升质量和效率。对特定的领域，便于深入、优化、沉淀，从而形成技术中台、业务中台、数据中台；
池化研发人员，降低研发技术领域墙、打破角色的边界，增强人员的可复用性，消除生产的波峰和波谷。促进研发人员在深入专业领域的基础上，拓展技术广度，增强人员间的技术交集，可被均衡被调配、补位。有助于个人专业领域（深度）及相关领域（广度）的能力提升，增加其职场竞争力。
有利于调动人员的主观能动性，有更多的机会在合适的任务作为“负责人”，实现个人价值的提升；
弱化岗位头衔（对内），以实现和提升用户价值、团队价值、个人价值、个人能力为主；

组织及角色的职能

虚拟组织

虚拟组织是在某个事项处理的流程节点或产品的特定发展阶段，根据要处理事项的特点，聚集相关需要的人员，开展工作的组织，常设“主席”角色负责统筹和组织相关工作。

管理执行委员会

偏向对“业务及管理领域”的问题进行支撑和决策的虚拟组织，主要负责下列事项的处理和解决：

对战略解读、关键业务方向、团队管理优化等事项进行支撑和决策，根据需要处理事项的特点，组织相关人员进行专题研究，并形成可执行方案；
对各组提出的涉及战略、业务、管理方面的执行方案进行评估、指导和决策；
对需求从等待阶段进入选择阶段进行监督；
以月度或季度为单位，复盘业务及产品的发展，并作出评估和调整；
以季度或年度为单位，复盘团队效能，并作出评估和调整；

架构设计委员会

或“技术管理委员会”，偏向对“技术领域”的问题进行支撑和决策的虚拟组织，主要负责下列事项的处理和解决：

对整体的技术方向、技术架构进行决策，支撑产品发展阶段所需技术的选型和预研；
组织相关人员对产品迭代过程中的技术方案设计进行评估和决策；
对产品发展过程中出现的关键、核心、复杂的系统设计和技术难点进行研究，并形成可执行方案；
推进研发能力的提升，营造技术学习氛围，通过各种手段，提升研发团队的专业能力；
推进系统质量的提升，包括：性能、安全性；
推进研发质量的提升，提升工程的可维护性，制定相关技术标准及规范，并监督落实；

本质是汇集了团队中各领域架构师、CTO等技术决策者的职能，有利于在全局把控技术发展，统筹规划，形成技术管理的机制。

职能组织

职能组织是存续周期较长、相对固定的组织，组织中常设职能范围固定的角色，解决处理相关领域的问题。

管控组

主要对产品研发过程、机制和团队成员负责，具体岗位职责如下：

管控组长
- 主导研发效能的建立、优化及督导，建设合理的机制，调动大家共同推动价值流动，而不依赖某个组织角色；
- 协助人资，完成对人员激励、提升团队凝聚力等团建相关事项的推进；
- 组织并参与管理执行委员会的相关事项；
- 协助团队与外部资源的对接、合作；
敏捷教练（可多团队复用）

组内可根据产品的不同，也可根据价值流动的阶段（即某几个职能团队），灵活分配敏捷教练。

可设置独立于敏捷团队的敏捷教练，在多个敏捷团队中复用；也可设置专属于敏捷团队的敏捷教练，可由团队内选择一名成员担任（通常是主程或产品经理）
- 参与研发效能的建立、优化，并指导和推进其在团队实际工作中的落地；
- 分析团队执行过程中的问题，制定有针对性、阶段性的优化解决方案；
- 复盘执行过程中的问题及优秀实践，并在组织内传播、宣导；
- 对产品研发过程和节奏进行监督，协助或协调组内的任务分配和执行，发现价值流动过程中的问题，并及时推进解决，确保价值流动的顺畅程度处于较高水平；
- 在执行过程中的关键流程节点，协调推进相关人员，进行各种形式的有效沟通；
- 协助团队应用敏捷工具（看板、站会、复盘等），对齐团队目标；

产品设计组

主要对如何通过产品实现“用户”及“组织”价值负责，具体岗位职责如下：

产品总监
- 主导或组织产品规划的制定和调整，根据战略需要，通过头脑风暴、竞品分析、环境分析等手段，制定产品未来的发展规划；
- 把控整体的业务架构、应用架构及各业务/产品线的发展方向和发展过程；
- 根据各业务/产品线的发展，结合行业生态，探索业务场景，挖掘用户及商业价值；
- 协调组织内外部资源，推进达成战略目标；
产品经理（可多团队复用）

组内可根据产品类型的不同，分配多个产品经理，也可进一步根据产品内问题领域（子产品或模块）的不同，细分为专项领域的产品经理。
- 根据战略、业务及商业目标，设计和规划产品需求；
- 使用合适的手段，了解目标用户，对用户的潜在需求进行挖掘和分析，并结合业务发展阶段，制定所负责产品的发展方向和策略；
- 管控各个来源的业务类需求（优先级、版本排期），对需求进行选择、分析和澄清，并确保对需求的分析及设计结果在输入开发阶段（需求澄清）的质量保持较高水平；
- 跟踪价值流动过程中的价值偏离，并及时解决；
- 跟踪价值交付的进度，并对进度异常的需求，协调相关资源解决；
- 对即将交付的价值（需求），进行验证、验收；
设计师

组内可根据设计的专业领域（视觉/UI、体验/UE、交互/IxD、动画、3D等），分配多个设计师（共享型）；也可根据产品的不同，进一步细分为单个产品内专项领域的设计师（产品型）。
- 参与产品的需求分析，了解用户的真实诉求，并根据产品的原型设计，完成UI设计；
- 完成产品及组织发展过程中的各类素材的创意及设计；
- 与前端技术团队合作，提升产品的美观性和用户体验；
- 制定产品设计的标准和规范，形成设计的价值观、原则和模式（如组件库），在团队中推广应用，不断提升团队协作效率；

敏捷开发团队

面向业务产品的敏捷开发团队，由1名敏捷教练、1名产品经理、若干名设计师、若干名程序员组成，团队中的产品经理与敏捷教练同时作为团队的主要监督人，但具有各自的职责和专注的方向，从研发人员池中吸纳符合业务特征的程序员，共同推进组内工作。

单个产品敏捷团队人员数量一般在5-9人之间（若发现人员需求过多，则首先考虑业务领域的切分是否合理，是否可以进一步的细化产品线）。根据业务领域（产品线）的划分，成立若干个“产品敏捷开发团队”。随着产品的发展，在产品类型的基础上，根据产品内问题领域（子产品或产品的某个模块）的不同，进一步拆分为多个敏捷团队，进而衍化为“XX产品事业部”的组织形态。

对于需求的分析及设计，在各敏捷团队中进行，而产品需求的软件系统设计工作（仅概要设计，详细设计依然在敏捷开发团队中进行），则根据中台成熟度决定。在中台成熟度较低的阶段，由公线类职能组织主导概要设计，各敏捷开发团队配合，并在概要设计的基础上，完成详细设计，待中台成熟度较高时，由敏捷开发团队主导软件系统设计工作，公线研发职能组织可做协助。

注意，不建议按照产品所属层级（前台、后台）划分团队，从业务流程的角度来理解，这样做会切断业务流程，从而因过多的信息不一致而产生过多的团队沟通。建议通过业务领域（业务线）的方式来划分，一个业务线内的业务流程可能会与其他业务线有依赖关系，但因这种依赖关系产生的沟通和约定是良性的，可控的。但中台类的产品比较特殊，需要按产品所属层级划分，这样可以最大化的统筹各业务线的需求。

每个产品敏捷开发团队的职责基本一致，会根据所负责产品的特性和技术栈的不同，产生略微差异。主要对“研发产品相关的前后台工程实现用户价值”负责，主要职责如下：

根据用户及业务对产品的需求，进行需求分析及设计，并对组内开发团队澄清；
深入理解业务，协助研发公线职能团队，完成产品的系统分析及设计；
完成系统的功能实现，确保产品的交付进度和质量；
持续对产品相关工程的代码质量进行管控、优化，确保工程的可维护性和可扩展性；
对产品发生的线上问题（异常/疑问）进行定位并解决；
根据产品的特性，持续优化技术架构及非功能性指标（性能、安全性、可用性、健壮性等）；
基于研发统一的技术标准、规范指导及研发模式，根据本团队所做产品及所用技术的特性，建立细化的技术标准、规范及研发模式，提升组内团队输出成果的质量和效能；

研发公线类职能组织

研发公线类的职能组织，会根据产品发展，按业务和技术领域的特征，阶段性的组成为新的研发公线小组（团队类别属于敏捷团队），如数据分析工程研发组、XX中台产品研发组、前端中间件研发组、XX模块研发组、XX子系统研发组，小组的存续周期可能是1周，也可能在产品的生命周期内一直存在。下面以具备前后台产品规划、前后端分离为开发模式的团队举例，根据产品及技术栈的不同，初始划分为4个通用的小组，每个小组最少有一个固定的负责人，其它人员根据需要，从研发人员池吸纳合适的人员，动态调度至各个小组。

后期，研发公线类小组，会在业务模式相对成熟，且通用领域的抽象程度达到中等水平（需求稳定且持续时），衍化为独立的部门或事业部（如阿里的“共享业务事业部”），专心打造技术中台或业务中台，以支撑各业务线的通用业务，加速业务开发的效能，提升业务线的开发质量。

公线类组织的职能如下：

后端工程研发组

团队类别属于敏捷团队

主要对“帮助业务开发团队更快、更高质量和持续的交付价值”负责，小组主要职能如下：

参与、了解各产品敏捷开发团队的需求分析及设计，并从中识别（抽象）公共业务领域和通用领域服务；
对识别的公共业务和通用领域的需求，进行系统分析及设计，结合业务开发团队的产品发展，进行相关规划；
基于团队的工作模式，根据设计结果，完成相关系统的功能实现，支持产品开发团队对相关能力的需求；
设计后端系统的技术架构，搭建并维护后端工程的技术开发框架；
建设后端工程统一的技术标准及规范指导，提升各业务产品开发团队输出成果的质量；
支撑各业务产品开发团队，主导或协助其完成后端系统的分析设计工作；
支撑各业务产品开发团队，持续优化后端系统的技术架构和非功能性指标（性能、安全性、可用性、健壮性等）；
协助各业务产品开发团队，对后端工程的代码质量进行管控、优化，确保后端工程的可维护性和可扩展性；
协助各业务产品开发团队，对产品相关后端系统的线上问题，进行定位和解决；
推进相关中台产品（如：技术中台、业务中台、数据中台）的建设；
对后端系统相关技术进行预研及追踪，引入适配产品和团队的关键技术，形成方案，并推广应用；

前端工程研发组

团队类别属于敏捷团队

主要对“帮助业务开发团队更快、更高质量和持续的交付价值”负责，小组主要职能如下：

设计前端系统的技术架构，搭建并维护前端工程的技术开发框架；
推进前端技术中台的建设，统一前端工程的技术标准和规范指导，提升各业务产品开发团队输出成果的质量；
支撑各业务产品开发团队，主导或协助其完成前端系统的分析设计工作；
支撑各业务产品开发团队，持续优化前端系统的技术架构和非功能性指标（性能、安全性、可用性、健壮性等）；
协助各业务产品开发团队，对产品相关前端系统的线上问题，进行定位和解决；
协助各业务产品开发团队，对前端工程的代码质量进行管控、优化，确保前端工程的可维护性和可扩展性；
对前端系统相关技术进行预研及追踪，引入适配产品和团队的关键技术，形成方案，并推广应用；

质量控制组

主要对需求实现结果的质量验收负责，小组主要职能如下：

组内可根据专业领域（功能测试、性能测试、自动化测试、兼容性测试等），分配多个“测试开发工程师”及团队，也可根据产品的不同，进一步细分为某个产品内专项领域的“测试开发工程师”。

参与迭代需求的澄清，并根据需求，设计测试用例，制定测试计划；
构建测试环境，应用适合团队的测试方法（单元测试、集成测试、回归测试等），保证产品发布质量；
设计针对不同产品的质量保障和测试策略，通过持续的测试流程和方法创新，利用工程化、体系化的思路方法，构建成熟稳定的质量保证体系，建设并不断完善产品的功能性、安全性、性能、兼容性等测试标准、测试方法、模式及度量指标；
提升自动化测试的比例和效果，提升测试环节的效率；
通过DevOps流程中的代码质量检查工具（Sonar等）对工程的扫描结果，进行定期的检查，并推进问题的解决；
根据系统承载用户的量级增长情况，基于场景范围，完成后端服务的压力测试，并与开发团队协作优化，推进吞吐量达到期望的水平；
协助定位、解决线上问题；

运维组

主要对产品上线后的运行状况及各系统环境负责，小组主要职能如下：

组内可根据运维范围细分负责人及小组，如：产品运维、硬件/环境/云服务运维、配置运维、DevOps运维等。

主导DevOps实践的建设、优化，维护相关系统，提升研发过程自动化水平；
对各个产品的各个运行环境，建立监控报警机制，及时发现、定位、反馈问题；
完成并优化产品部署的相关工作；
与研发协助，共同优化、提升系统的性能、可用性、安全性、健壮性等非功能性指标；
协助运营、开发解决线上的疑问或异常；

“测试开发工程师”和“运维开发工程师”是两个相对特殊的职能角色，所做的工作本质上属于研发工程师的工作范畴，均可在敏捷研发组内消化，有很多工作也可以通过自动化的手段来完成，阶段性的独立出固定的小组（本质是属于公线类特定领域的敏捷团队），可以针对相关工作进行细致的规划和沉淀，当模式形成且自动化程度达到较高的水平时，质量控制组和运维组的相关工作职能会合并至研发类的小组、工作流程及模式中，人员也会回归研发人员池，根据需要动态调配。

研发人员池

研发人员池是对工程师群体的一种概念性划分，不区分具体的角色，统称为“程序员”，通过建立并持续维护“程序员”的能力和技能模型（雷达图），具象化团队成员擅长处理的技术及业务领域，以个体的能力和技能长板，组成团队的能力及技能雷达图，在承接对应需求时，按需求的特点、难易、工作量，将适合的人员动态调度至各个小组，承接相关任务的执行。

本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。
1.引言
 2.几个重要的观念
 3.形而上
 4.设计组织架构
 5.1.工作模式设计——需求处理
 5.2.工作模式设计——迭代规划
 5.3.工作模式设计——其它事务
 6.建立可视化协作机制
 7.进行评估和激励
 8.附录