研发效能组织架构：职能独立vs业务闭环

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

业务闭环组织架构

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

业务闭环组织架构特点

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

业务闭环组织架构好处

• 交付快，单位产出多
• 小步快跑，唯快不破，精英特种兵
• 团队内可以做到端到端交付，极少等待时间，交付速度快
  • 一手的信息来源，从头跟到尾的负责制模式
• 减少团队之间依赖，计划更容易、更有保障
  • 如果团队间有依赖，那肯定是弱依赖，如果是非常强的依赖，团队内部要么有人主动出来承担这部分工作，要么闭环到团队内部。
• 团队内部快速沟通、交流、决策，快速响应用户的诉求
  • 大家都围绕着几个桌子坐，每日例会，平时有问题快速沟通。
• 以业务为中心、以用户为中心驱动团队运转
  • 闭环团队的工作人少活多，强调自我驱动、主动承担。
• 责、权、利对等，成员责任心、自驱力高
  • 大家每天坐在一起工作，每天做什么，做得怎么样，团队贡献度，每个人心里都有一杆秤
  • 大家都是一个整体，即便想躺平估计都难，活就是咱们团队的，我们都在咔咔的干活，你想躺平，不行，拉起来一起干。

业务闭环组织架构劣势

• 团队整体压力大
• 对业务闭环组织的负责人(FTO)要求高，定方向、搭班子、带团队的综合能力都要很出色。FTO不但要强于业务，还要在多项职能上都要有很好的判断，尤其是带领产品、研发、QA、运维、设计师、运营等多种背景的小伙伴上。虽然很多决定是FTO和团队沟通后作出的，但是我们依然认为FTO是所有问题的第一责任人，团队内部所有问题，业务问题等都要FTO担责，FTO压力比职能型管理者大很多。千金易得，一将难求
• 对成员要求高，不断学习、自我驱动、主动承担。每日例会，每个人都做了哪些事情质量如何，团队内部每个人心知肚明，大家都知道。任务催的紧，工作压力很大，「葛优躺」「摸鱼族」难生存，未必所有人都能适应
• 长期高强度的端到端用户价值的交付，团队注意力全部集中在事上，工作压力大、对团队内部成员的关怀度低
• 长时间工作在一个业务领域，部分队员可能会对做的事情失去兴趣，公司、部门需要有便利的内部活水、转岗制度和机制。很多公司在这一点做得不好，我觉得要放开这方面的限制。
• 各个业务闭环团队都会针对自己的团队、自己的业务非常实际地做出决定，在技术栈选择、规范性遵从上一般不是很注重，需要技术委员会、专家团队横向引导

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

职能独立型组织架构

职能独立型组织架构特点

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

职能独立组织架构优势

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

职能独立组织架构劣势

• 开不完的会
• 决策链路长、决策过程慢，决策时间长
  • 职能线之间达成一致后，再横向沟通，横向都满意后项目才能向下推进。如果有不同意见，那么只能职能线沟通->横向沟通再来一遍。
  • 职能线内部也要同时承担多个横向项目，优先级重要度出现变化时，其他职能团队也需要变化，但未必能及时反应。
• 责、权、利不对等。「摘桃子」「背黑锅」常发生。
  • 职能线内部被「摘桃子」「背黑锅」时常发生。不同职能线基于脸面都是有桃子一起吃，更多的是背后「被甩锅」。

举个例子：公司需要做构建优化，PMO横向拉了几个团队协调配合做这件事情。实际干活的就1个人。这个人把项目做好后，参与这个项目的人顺利拿到了公司的效率提升大奖。分享成果也无可厚非，甭管多少至少大家都参与了。年中有人要晋升，直接拿了这个成果就去述职了，这就是所谓的摘桃子。

• 各个职能部门的利益与横向团队的利益、客户的需求未必一致，缺少用户利益的代言人
  • 谁代表用户谁有决定权。职能独立型的组织之间，各个职能是互相配合的关系，谁都可以说代表用户可是谁又无法完全代表。
  • 横向的项目经理能代表用户么？项目经理解决的是项目按照流程节奏进行下去，无法保证最终的结果就是用户想要的；也无法直接调动项目外额外的资源，有需要只能去协调职能线资源。
  • 产品经理能么？在这种组织架构下也比较难。
  • 1024程序员节快到了，产品经理想加入一些程序员节相关的内容到产品中，提高公司技术氛围，让大家快乐过节。看了产品需求文档(PRD)后，后端说周末加班就可以搞定，前端说工作量较大，组内设计师暂时没时间，项目经理评估后说要不砍点其它需求？上面领导知晓后批评产品经理为啥不早规划，产品经理抽了自己一嘴巴，修改了PRD再次评审，前后端设计师都觉得没问题，项目经理一看不会延期点了一个大大的赞。10月24日那天产品正式上线横幅处飘过一段话“xx科技祝广大小哥哥小姐姐程序员节快乐。” 这真是我们想要的结果么？
• 分割的各个职能部门之间的沟通交流协作耗时、耗力、费心。共享的资源是你的，也不是你的，想要拿到好结果就要做事做成事，但是只有一个人这样想是做不成的，需要相关方一起这样想，都想把事情做好才行。
• 按照流程做事，集体决策，各个职能部门集体对最终业务成果负责，常常导致无人对业务结果负责
  • 谁都在做事，也都很辛苦，可是最后结果不好，能怪谁？产研运各个职能向上最近交叉点的那个人么？
  • 更多的对流程、对支撑平台的反馈、抱怨。为啥那么多流程，那么多节点？IT要管控、行政要管控、财务也要管控，采购一个苹果Mac Pro构建App，流程要走一个月。每个人每个节点都在坚守自己的职责和保护着自己的领地，却从来没有顾忌申请人的感受，也没有想过这样做造成的影响。
  • 流程化自动化平台化可以解决一些事，但还远远不够。

本文总结

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

阅读我的更多文章

研发效能组织能力建设之特性团队FeatureTeam（上）

高效能敏捷交付团队反思：特性团队(FeatureTeam)+Scrum

互联网公司研发效能/工程效率团队建设和规划

找到能做好研发效能的人

中小互联网公司研发效能团队规模、职能划分和优劣势分析