是分是合?影响研发组织设计的主要因素

编辑导读:研发体系是企业管理体系的一部分,业务的发展推进了组织的裂变,业务的整合也迫使组织进行合并。本文围绕“研发组织设计”进行了分析,希望对你有帮助。

话说天下大势分久必合,合久必分。其实对于企业来说也是如此,业务的发展推进了组织的裂变,业务的整合也迫使组织进行合并。《组织的逻辑》这本书中说:企业成长和创新的最大瓶颈是组织的进化,而组织进化的最大瓶颈是创始人自身的进化。

可见组织的设计对于业务开展、企业的发展具有极其重大的意义,是典型的一把手工程。同样对于企业中的研发体系来说也是,我过去曾经写过一篇文章《没有匹配的研发组织,如何实现高效的产品研发》,探讨了研发组织的演化逻辑,但组织管理的体系岂非一两篇文章能说清楚的,今天站在研发组织是分是合这个维度再进行详细的分析。

一、研发组织设计的目的

在讨论研发组织具体是分是合,如何分如何合的问题之前,我们首先要明确研发组织设计的目的:

  1. 更有利于产品的研发!
  2. 更好的节省成本、提升效率!
  3. 更好的支持业务快速发展!
  4. 甚至更好的引领企业产品创新!

研发组织一定是站在企业管理者的视角,站在企业发展的角度去设计,如何更有利于公司的可持续发展,这是我们后续内容讨论的前提。

二、了解企业的组织设计

研发体系是企业管理体系的一部分,研发组织的设计,离不开企业组织的模式和现状,西方学者威廉姆森根据钱德勒的考证将公司内部管理的组织形式分为U型 (一元结构)、H型(控股结构)和M型(多元结构)三种基本类型。

U型组织结构

企业内部按职能划分成若干部门,各部门独立性很小,均由企业高层领导直接进行管理,即企业实行集中控制和统一指挥。U型结构保持了直线制的集中统一指挥的优点,并吸收了职能制发挥专业管理职能作用的长处。

M型组织结构

根据业务按产品、服务、客户、地区等设立半自主性的经营事业部,公司的战略决策和经营决策由不同的部门和人员负责,使高层领导从繁重的日常经营业务中解脱出来,集中精力致力于企业的长期经营决策,并监督、协调各事业部的活动和评价各部门的绩效。但缺陷是,资源重复配置,管理费用较高,且事业部之间协作较差。这种组织形式主要适用于产品多样化和从事多元化经营的组织,也适用于面临市场环境复杂多变或所处理地理位置分散的大型企业和巨型企业。

H型组织结构

它严格讲起来并不是一个企业的组织结构类型,而是企业集团的组织形式。在H型公司持有子公司或分公司部分或全部股份,下属各子公司具有独立的法人资格,是相对独立的利润中心。这种结构的公司往往独立性过强,缺乏必要的战略联系和协调,因此,公司整体资源战略运用存在一定难度。

U型、M型、H型其实是组织结构的一种演变过程,无论是从出现的时间,还是结构自身特点,均符合组织结构演变规律,《组织的逻辑》一书中也呈现了组织演变的一般路径,在下图中我们也可以认为矩阵制和事业部制都归为M型组织。

当然U型、M型和H型并不是排他的,一个企业在一定时期同时包含两种,甚至三种组织模式都是正常的,比如老谭所在的公司,基本上三种类型都有体现。U型和H型对应研发体系的组织设计来说相对设计,U型倾向合,H型倾向分(子公司需要研发的话)。我们更关注的是M型组织下研发组织的设计,如何做到合理的配称,以支持业务更好的发展。

明确一个名词定义,为了更好的表达业务和研发二者关系,不论是业务事业部还是业务子公司,甚至是某条业务线,我们统一成为“BU”(Bussiness Unit),本文所谓的研发的“分”指是否放到BU内进行管理。

三、两种模式的特点分析

研发组织的架构其实没有好坏之分,是分是合也各有特点,从整体上来说:

1. 集中的模式

优势:

-研发力量更集中,协同性更好,资源使用率更高,产品研发资源使用更合理,有利于核心产品的打造;

-研发资源没有固定到具体业务,有利于新业务的探索和试错过程中的资源协调。

劣势:

-从业务角度来说,研发和业务配合效率低,业务自主性弱,缺少灵活性;

-从整体角度来说,如果“过度创新”导致业务不聚焦,反而占用核心业务的资源。

2. 分散的模式

优势:

-从业务角度来说,研发和业务利益绑定,目标一致,协同性更好,比较敏捷。

-从整体角度来说,总部管理成本降低,从繁忙的事务中解脱出来,也避免了单点故障的风险。

劣势:

-整体资源分散,整体浪费明显,隐性成本很高,难打大规模战役;

-研发和业务绑定太紧,业务短期目标和产品长期属性产生冲突,产品研发向短期业绩妥协。

四、组织设计的影响因素

既然分合有好处,也有缺点,这就要看哪个更适合我们,或者哪些是我们更关切的方向。那么影响我们选择判断的因素有哪些呢?

1. 企业的发展阶段

每个企业的发展都是有其生命周期的,大致分为导入期或者叫投入期、增长期、成熟期和衰退期,不同的发展时期,不同的发展时期都有自己的核心任务,比如:

  • 投入期要集中资源打造核心业务;
  • 增长期要构建完善的产品体系;
  • 成熟期后考虑创新,新兴业���的孵化,寻求二次发展;

所以我们要分析:

我们属于企业的哪个发展阶段?这个阶段最适合的组织架构是什么?

我们的核心业务是啥?核心产品是啥?竞争力如何?

是应该聚焦回收发展壮大核心业务还是搞多个BU,多处出击需求突破?

2. 企业的资源情况

这个影响因素其实是企业发展阶段的延伸,企业的发展初期往往是资源相对贫乏,成熟期资源相对充足,资源的多少也决定了我们组织设计的方向,总的来说:

资源充足时,效率优先、前台灵活、快速变化,此时要鼓励创新,孵化更多新型业务,适当做加法,所以研发更多人要走到前台去;

资源贫乏时,成本优先、资源复用、集中力量,此时要集中精力,聚焦发展核心业务,必须做减法,所以研发资源聚拢合成一股力。

3. 产品的类型

不同的企业类型对于组织架构的设计要求也是不同的,传统企业的组织架构和互联网企业的组织架构的设计有很大的不同,软件研发企业和互联网企业的组织设计也有不小的差别。在软件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中,保证其敏捷性。

4. 产品的发展阶段

我们之所以讨论研发组织分合的问题,必然是企业内存在了多产品线的问题,M型的组织架构也多因为是多产品线或多业务线的环境下对组织的调整,所以产品的发展阶段决定了组织架构的演化,几乎很少出现还没产品的时候就成立事业部来做这块业务的,因为第一是通常风险极大,违背了我们MVP验证迭代的思想,第二是实体组织建立比较简单,一旦撤销或者合并,存在利益的平衡,就比较头疼。

和企业的生命周期一样,产品也是具有相似的生命周期的(如上图),但我习惯站在研发角度把产品相应的阶段划分成0-1孵化器、1-10发展期、10-N成熟期三大阶段,当然还有衰退期,此时更多是考虑如何转型或者替换,本文暂不考虑。

1、0-1孵化期

以MVP产品为主,经过产品验证就达到1的阶段。每个企业对于产品到1的验证标准不同,比如笔者的标准就是该产品成功在第一个典型客户(符合客户定位,需求覆盖率达80%以上)商业化落地(不是合作研发,不是友情体验,是客户主动选择),并取得好的反馈。

1)从项目中孵化产品

合作项目:产品孵化是核心目标,客户愿意陪你一起打磨产品,有耐心,愿贡献,容易成功。

交付项目:产品孵化是附属目标,没有超强的架构能力和全局掌控能力,很难成功。

我造访了几个做外包的企业,现实很扎心,他们都想项目带产品,但很少有把产品做好的!产品不是核心目标的时候,你想做一个成功的产品,事与愿违的面大不要妄想在项目中直接产生产品,项目只是产品的前奏,需要专人为产品后期负责。

拓展阅读:《TO B产品从0到1:从项目中走出来》

2)“闭门造车”孵化产品

-对产品有明确的定义

-对产品有清晰的规划

-对业务有高于一般客户的理解

TO C的产品一般是通过产品经理对用户需求的理解和自己的业务发展要求,主动的设计产品功能,以提供符合用户需求的产品。对于TO B的产品,除了产品底层的设计逻辑外,还有很强的行业属性,如果产品经理不是这个行业的专家,很难通过自己关起门来做研发。这种“闭门造车”的模式如果取得成功,很大程度上取决与产品经理的行业经验,他应该是专家级,至少也是高于一般客户的业务熟悉程度和理解力的。

总之,孵化阶段因为充满了很多不确定性,生死都未可知,尽量不要过早的裂变成实体组织,否则总部资源支持和协同会存在问题,后期如果孵化不成功带来的组织重组也是比较麻烦,可以尝试研发中心内部做创新小组的方式进行。

2、1-10发展期

产品到1的状态很大程度上是基于产品功能的成熟度来决定的,只是证明了客户有需求,我们能满足。而产品真正的商业化,不仅仅是由需求决定的,还要看市场的竞争格局,并在竞争中找到自己独特的差异点和优势,从而获取可观的市场份额。1-10发展期我理解是产品差异化优势打造,能充分参与到市场竞争中的阶段。

-标准化产品可以由总部的研发团队负责

-实施交付体系放在BU

这个阶段,产品还没有完全成熟,还处在一个快速迭代开发的过程中,对于TO B的产品来说,处理好产品研发和项目交付的关系和协同至关重要。项目是需求的重要来源,但并不是说要让产品研发团队完全参与到项目交付中,项目交付团队要放在BU内,和业务配合紧密,产品研发团队建议独立于BU,建立好协同机制,专注于产品研发。即使研发放在BU内,和交付团队适当分离也是应该强调的,否则往往产品研发团队会因为BU的短期经营目标和资源不足时被抽调做项目交付,最终导致无法保证产品研发的资源和有序发展。

3、10-N成熟期

产品的市场格局已经确定,有一定的品牌力,这个阶段就是保持产品的稳定,提供良好的服务,靠品牌获取客户,挖掘老客户新的需求价值,应对外部竞争,巩固市场地位的基础上扩大市场份额。

-减少产品研发团队的投入,加强项目交付团队的投入,业绩优先

-产品研发团队可以和项目交付团队合并,BU整体负责该产品线,便于资源的利用

五、总结

影响研发组织设计的因素还有公司治理的要求,比如课题申报、知识产权(专利、软著等)归属、政府补贴、财务优化、IPO要求等等,特别在H型结构的企业,这些因素更需要认真对待。另外在公司的管理体系里,也存在着公司组织架构、管理关系、预算关系不完全一致的情况,矩阵管理甚至多线管理,一兼多职等情况,对于研发组织的设计都有影响。

所以,研发组织的设计没有好坏之分,对错之别,最终的目的都是通过组织的设计,实现研发资源(人)、产品资产(物)、项目协同(事)的配称,让产品研发更好的支持业务的发展。

后续我们还会继续分享研发组织的设计及职责分工相关的内容。

#专栏作家#

菜根老谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发,擅长企业IT架构及互联网产品架构。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

免责声明:以上内容(如有图片或视频亦包括在内)有转载其他网站资源,如有侵权请联系删除

为你推荐
加载中...
咨询热线(9:00 - 18:00)
0755 - 29812418
微信公众号二维码
微信公众号二维码
微信公众号
返回顶部