话说天下大势分久必合，合久必分。其实对于企业来说也是如此，业务的发展推进了组织的裂变，业务的整合也迫使组织进行合并。《组织的逻辑》这本书中说：企业成长和创新的最大瓶颈是组织的进化，而组织进化的最大瓶颈是创始人自身的进化。
可见组织的设计对于业务开展、企业的发展具有极其重大的意义，是典型的一把手工程。同样对于企业中的研发体系来说也是，我过去曾经写过一篇文章《没有匹配的研发组织，如何实现高效的产品研发》，探讨了研发组织的演化逻辑，但组织管理的体系岂非一两篇文章能说清楚的，今天站在研发组织是分是合这个维度再进行详细的分析。
在讨论研发组织具体是分是合，如何分如何合的问题之前，我们首先要明确研发组织设计的目的：
研发组织一定是站在企业管理者的视角，站在企业发展的角度去设计，如何更有利于公司的可持续发展，这是我们后续内容讨论的前提。
研发体系是企业管理体系的一部分，研发组织的设计，离不开企业组织的模式和现状，西方学者威廉姆森根据钱德勒的考证将公司内部管理的组织形式分为U型 (一元结构)、Ｈ型(控股结构)和Ｍ型(多元结构)三种基本类型。
U型组织结构
M型组织结构
H型组织结构
U型、M型、H型其实是组织结构的一种演变过程，无论是从出现的时间，还是结构自身特点，均符合组织结构演变规律，《组织的逻辑》一书中也呈现了组织演变的一般路径，在下图中我们也可以认为矩阵制和事业部制都归为M型组织。
当然U型、M型和H型并不是排他的，一个企业在一定时期同时包含两种，甚至三种组织模式都是正常的，比如老谭所在的公司，基本上三种类型都有体现。U型和H型对应研发体系的组织设计来说相对设计，U型倾向合，H型倾向分（子公司需要研发的话）。我们更关注的是M型组织下研发组织的设计，如何做到合理的配称，以支持业务更好的发展。
明确一个名词定义，为了更好的表达业务和研发二者关系，不论是业务事业部还是业务子公司，甚至是某条业务线，我们统一成为“BU”（Bussiness Unit），本文所谓的研发的“分”指是否放到BU内进行管理。
研发组织的架构其实没有好坏之分，是分是合也各有特点，从整体上来说：
优势：
-研发力量更集中，协同性更好，资源使用率更高，产品研发资源使用更合理，有利于核心产品的打造；
-研发资源没有固定到具体业务，有利于新业务的探索和试错过程中的资源协调。
劣势：
-从业务角度来说，研发和业务配合效率低，业务自主性弱，缺少灵活性；
-从整体角度来说，如果“过度创新”导致业务不聚焦，反而占用核心业务的资源。
优势：
-从业务角度来说，研发和业务利益绑定，目标一致，协同性更好，比较敏捷。
-从整体角度来说，总部管理成本降低，从繁忙的事务中解脱出来，也避免了单点故障的风险。
劣势：
-整体资源分散，整体浪费明显，隐性成本很高，难打大规模战役；
-研发和业务绑定太紧，业务短期目标和产品长期属性产生冲突，产品研发向短期业绩妥协。
既然分合有好处，也有缺点，这就要看哪个更适合我们，或者哪些是我们更关切的方向。那么影响我们选择判断的因素有哪些呢？
每个企业的发展都是有其生命周期的，大致分为导入期或者叫投入期、增长期、成熟期和衰退期，不同的发展时期，不同的发展时期都有自己的核心任务，比如：
所以我们要分析：
我们属于企业的哪个发展阶段？这个阶段最适合的组织架构是什么？
我们的核心业务是啥？核心产品是啥？竞争力如何？
是应该聚焦回收发展壮大核心业务还是搞多个BU，多处出击需求突破？
这个影响因素其实是企业发展阶段的延伸，企业的发展初期往往是资源相对贫乏，成熟期资源相对充足，资源的多少也决定了我们组织设计的方向，总的来说：
资源充足时，效率优先、前台灵活、快速变化，此时要鼓励创新，孵化更多新型业务，适当做加法，所以研发更多人要走到前台去；
资源贫乏时，成本优先、资源复用、集中力量，此时要集中精力，聚焦发展核心业务，必须做减法，所以研发资源聚拢合成一股力。
不同的企业类型对于组织架构的设计要求也是不同的，传统企业的组织架构和互联网企业的组织架构的设计有很大的不同，软件研发企业和互联网企业的组织设计也有不小的差别。在软件SaaS化的大趋势下，软件企业和互联网企业的界限在逐渐的模糊，而面向B端的产品和面向C端的产品对于组织的需求也是不同的，即使都是TO B的产品，SaaS化的产品和本地交付的产品也有很大的差别。
TO B产品特点
-产品需要标准化，并具备定制化能力，以适应客户的个性化需求
-以产品的定位作为销售方向，重销售，销售团队和销售策略非常重要
TO C产品
-产品没有标准化，也不需要兼容各个用户的个性化需求，产品的独特性是产品创新的体现
-产品更重运营，通过线上线下的运营推广获取用户，实现转化，研发需要更敏捷的支持运营
2B2C产品
-形态一：产品销售给B端，帮B端运营服务C端，比如帮专家搭建的患者服务平台
-形态二：产品销售给B端，B端服务C端实现C端用户增长，产品通过TO C服务转化成平台的C端用户
-通过TO B实现销售，通过TO C实现规模化增长，销售和运营并重
形态一从产品形态来说，其实可以归属为TO B的产品，只不过平台提供了代运营服务，BU主要负责运营，研发可以在总部；形态二是TO B产品向TO C产品转化的重要路径，TO B可以在总部，也可以在BU，但TO C部分的研发建议保留在BU中，保证其敏捷性。
我们之所以讨论研发组织分合的问题，必然是企业内存在了多产品线的问题，M型的组织架构也多因为是多产品线或多业务线的环境下对组织的调整，所以产品的发展阶段决定了组织架构的演化，几乎很少出现还没产品的时候就成立事业部来做这块业务的，因为第一是通常风险极大，违背了我们MVP验证迭代的思想，第二是实体组织建立比较简单，一旦撤销或者合并，存在利益的平衡，就比较头疼。
和企业的生命周期一样，产品也是具有相似的生命周期的（如上图），但我习惯站在研发角度把产品相应的阶段划分成0-1孵化器、1-10发展期、10-N成熟期三大阶段，当然还有衰退期，此时更多是考虑如何转型或者替换，本文暂不考虑。
1、0-1孵化期
1）从项目中孵化产品
–合作项目：产品孵化是核心目标，客户愿意陪你一起打磨产品，有耐心，愿贡献，容易成功。
–交付项目：产品孵化是附属目标，没有超强的架构能力和全局掌控能力，很难成功。
我造访了几个做外包的企业，现实很扎心，他们都想项目带产品，但很少有把产品做好的！产品不是核心目标的时候，你想做一个成功的产品，事与愿违的面大不要妄想在项目中直接产生产品，项目只是产品的前奏，需要专人为产品后期负责。
拓展阅读：《TO B产品从0到1：从项目中走出来》
2）“闭门造车”孵化产品
-对产品有明确的定义
-对产品有清晰的规划
-对业务有高于一般客户的理解
TO C的产品一般是通过产品经理对用户需求的理解和自己的业务发展要求，主动的设计产品功能，以提供符合用户需求的产品。对于TO B的产品，除了产品底层的设计逻辑外，还有很强的行业属性，如果产品经理不是这个行业的专家，很难通过自己关起门来做研发。这种“闭门造车”的模式如果取得成功，很大程度上取决与产品经理的行业经验，他应该是专家级，至少也是高于一般客户的业务熟悉程度和理解力的。
总之，孵化阶段因为充满了很多不确定性，生死都未可知，尽量不要过早的裂变成实体组织，否则总部资源支持和协同会存在问题，后期如果孵化不成功带来的组织重组也是比较麻烦，可以尝试研发中心内部做创新小组的方式进行。
2、1-10发展期
-标准化产品可以由总部的研发团队负责
-实施交付体系放在BU
这个阶段，产品还没有完全成熟，还处在一个快速迭代开发的过程中，对于TO B的产品来说，处理好产品研发和项目交付的关系和协同至关重要。项目是需求的重要来源，但并不是说要让产品研发团队完全参与到项目交付中，项目交付团队要放在BU内，和业务配合紧密，产品研发团队建议独立于BU，建立好协同机制，专注于产品研发。即使研发放在BU内，和交付团队适当分离也是应该强调的，否则往往产品研发团队会因为BU的短期经营目标和资源不足时被抽调做项目交付，最终导致无法保证产品研发的资源和有序发展。
3、10-N成熟期
-减少产品研发团队的投入，加强项目交付团队的投入，业绩优先
-产品研发团队可以和项目交付团队合并，BU整体负责该产品线，便于资源的利用
影响研发组织设计的因素还有公司治理的要求，比如课题申报、知识产权（专利、软著等）归属、政府补贴、财务优化、IPO要求等等，特别在H型结构的企业，这些因素更需要认真对待。另外在公司的管理体系里，也存在着公司组织架构、管理关系、预算关系不完全一致的情况，矩阵管理甚至多线管理，一兼多职等情况，对于研发组织的设计都有影响。
所以，研发组织的设计没有好坏之分，对错之别，最终的目的都是通过组织的设计，实现研发资源（人）、产品资产（物）、项目协同（事）的配称，让产品研发更好的支持业务的发展。
后续我们还会继续分享研发组织的设计及职责分工相关的内容。
菜根老谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发，擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
关注微信
