DevOps｜研发效能团队组织架构和能力建设

devops,研发,效能,团队,组织,架构,能力,建设 · 浏览次数 : 22

小编点评

**职能独立型组织架构** * 每个职能都根据专业线，按照职能向上汇报，决策集中在最高领导当需要做项目时。 * 优点： * 决策效率高 * 专家领导 * 劣势： * 决策链路长 * 决策过程慢 **业务闭环型组织架构** * 拥有特性团队，一个长期稳定、跨职能跨组件、持续端到端交付用户价值的团队。 * 特性团队是一个业务闭环的组织架构。 * 优点： * 交付快 * 效率高 * 降低沟通成本 * 劣势： * 团队整体压力大 * 要求高

正文

研发效能团队相对于各个公司主营业务规模来说并不是很大，但是在经历的几家公司里主要是有两种组织架构，职能独立型组织架构和业务闭环型组织架构。本文主要讲解这两种组织架构的特点、优劣、劣势。

业务闭环组织架构

这里引入了一个概念-特性团队，以及特性团队的负责人（FTO），更多的内容在我之前的文章《研发效能组织能力建设之特性团队FeatureTeam（上）》有过介绍，这里只把一些关键点列出来。特性团队是一个长期稳定、跨职能跨组件、持续端到端交付用户价值的团队。特性团队就是一个业务闭环的组织架构。图中的负责具体业务的运维人员、QA、设计师甚至都可以闭环到业务中去，这样整体效率会更高。

业务闭环组织架构特点

最大化响应速度
最大限度减少外部、内部依赖
最大限度降低沟通成本
最大限度降低决策成本
责、权、利对等

业务闭环组织架构好处

交付快，单位产出多
小步快跑，唯快不破，精英小团队
团队内可以做到端到端交付，极少等待时间，交付速度快

一手的信息来源，从头跟到尾的负责制模式

减少团队之间依赖，计划更容易、更有保障

如果团队间有依赖，那肯定是弱依赖，如果是非常强的依赖，团队内部要么有人主动出来承担这部分工作，要么闭环到团队内部。

团队内部快速沟通、交流、决策，快速响应用户的诉求

大家都围绕着几个桌子坐，每日例会，平时有问题快速沟通。

以业务为中心、以用户为中心驱动团队运转

闭环团队的工作人少活多，强调自我驱动、主动承担。

责、权、利对等，成员责任心、自驱力高

大家每天坐在一起工作，每天做什么，做得怎么样，团队贡献度，每个人心里都有一杆秤

业务闭环组织架构劣势

团队整体压力大
对业务闭环组织的负责人(FTO)要求高，定方向、搭班子、带团队的综合能力都要很出色。FTO不但要强于业务，还要在多项职能上都要有很好的判断，尤其是带领产品、研发、QA、运维、设计师、运营等多种背景的小伙伴上。虽然很多决定是FTO和团队沟通后作出的，但是我们依然认为FTO是所有问题的第一责任人，团队内部所有问题，业务问题等都要FTO担责，FTO压力比职能型管理者大很多。千金易得，一将难求
对成员要求高，不断学习、自我驱动、主动承担。每日例会，每个人都做了哪些事情质量如何，团队内部每个人心知肚明，大家都知道。任务催的紧，工作压力很大，「葛优躺」「摸鱼族」难生存，未必所有人都能适应

长期高强度的端到端用户价值的交付，团队注意力全部集中在事上，工作压力大、对团队内部成员的关怀度低
长时间工作在一个业务领域，部分队员可能会对做的事情失去兴趣，公司、部门需要有便利的内部活水、转岗制度和机制。很多公司在这一点做得不好，我觉得要放开这方面的限制。
各个业务闭环团队都会针对自己的团队、自己的业务非常实际地做出决定，在技术栈选择、规范性遵从上一般不是很注重，需要技术委员会、专家团队横向引导

业务闭环组织架构的一个很重要的点在于找到一个懂业务的 FTO来负责整个业务。

职能独立型组织架构

职能独立型组织架构特点

每个人都根据专业线，按照职能向上汇报，决策集中在最高领导
当需要做项目时，从产品、技术，运维、QA等团队中抽调人员组成项目团队。
一线的项目人员需要按照职能线向上汇报，也需要横向做项目上的沟通，有更多的沟通、协调工作。
对一线的项目人员要求高。不但要处理好项目上的事情，还需要处理好职能线的事情。
虽然某些公司号称context not control，但是实际一线的项目人员在某些方面还是无法作出决策的，要不断的向上反馈，有时要上升到整个组织/团队的高层，同时也需要不断的横向沟通
为了推动项目顺利开展，因为涉及众多角色，需要更多工作流程、平台的支持，以便减少在模糊地带、中间地带的沟通、等待、决策成本。
项目规模大、共享资源多
比较适合成熟的业务，或者团队比较大的公司

职能独立组织架构优势

专家领导专家。你的汇报线都是相关职能的专家。上级对下级有绝对的专业判断。很少会出现外行领导内行。
同一职能团队内部可以相互交流、相互支援
因为决策团队中包含了各个职能的相关人员，集体决策。集体决策在大团队大组织里永远是最不坏的选择，但未必是最优选择。
面向规则办事，一切走流程

职能独立组织架构劣势

决策链路长、决策过程慢，决策时间长

职能线之间达成一致后，再横向沟通，横向都满意后项目才能向下推进。如果有不同意见，那么只能职能线沟通->横向沟通再来一遍。
职能线内部也要同时承担多个横向项目，优先级重要度出现变化时，其他职能团队也需要变化，但未必能及时反应。

责、权、利不对等。「摘桃子」「背黑锅」常发生。

职能线内部被「摘桃子」「背黑锅」时常发生。不同职能线基于脸面都是有桃子一起吃，更多的是「被甩锅」。

各个职能部门的利益与横向团队的利益、客户的需求未必一致，缺少用户利益的代言人

谁代表用户谁有决定权。职能独立型的组织之间，各个职能是互相配合的关系，谁都可以说代表用户可是谁又无法完全代表。

分割的各个职能部门之间的沟通交流协作耗时、耗力、费心
按照流程做事，集体决策，各个职能部门集体对最终业务成果负责，常常导致无人对业务结果负责

谁都在做事，也都很辛苦，可是最后结果不好，能怪谁？产研运各个职能向上最近交叉点的那个人么？
更多的对流程、对支撑平台的反馈、抱怨。但是平台无法解决解决不了人心。

本文总结

本文主要对比了职能独立型组织架构和业务闭环型两种组织架构的特点、优势、劣势。通常来说对于小组织、小业务、业务目标相对明确采用业务闭环型组织更好。