怎样打造研发体系?(打造研发体系的6个步骤)

qinzhiqiang 12-19 10:44 795次浏览

研发无小事,事事要重视。短期看效益,长期看体系!

思考:如何打造一个优秀的研发体系?

做了几年的产品,刚混熟了产品圈,今年又临危受命负责整个研发团队,对过去分散式的研发体系(研发在各事业部)进行整合,研发统一管理。

过去我们一个产品一个产品的突破,逐步形成了多产品线的研发模式,这种模式突出的优点就是敏捷迅速,能结合市场快速的试错,拥抱变化。但是当业务发展到一定阶段,这种太过分散式的管理就会产生一系列的问题,又给发展带来一定瓶颈。

结合自身团队,突出的问题表现在:

  • 产品分散重叠,产品线之间信息缺乏共享,公共部分产生重复开发;
  • 缺少统一技术路线,多语言,多技术体系,不利于深度积累和合作协同;
  • 研发人员分散管理,容易产生资源缺乏和浪费,且协同成本巨大。

其实这些问题在一些大的互联网公司都经历过,像腾讯、阿里这样的公司他们经历的时间也更长,毕竟业务发展太快,来不及调整只能往前冲。如何打造一个既能解决以上问题,又能依然保持早期的敏捷灵活,这的确是一个难题。这就像春秋战国一样,划分诸侯国容易,但是再把他们合起来那就太难了。

  • 难点1:某些业务和产品已经成型,我们知道存在很多重复和浪费,但共享重构是需要付出巨大时间成本和人力成本的,既要修车又不能把车停下来。
  • 难点2:每个团队的技术路线已经成型了,切换的成本是巨大的,但不切换未来的成本会更高,很纠结。
  • 难点3:山头已经形成,打破山头重新组合,虽然说是不破不立,但必然带来很多不安定因素。

图1:IPD研发管理体系

好在IPD(集成产品开发)的研发管理模式,给我提供了一定的理论基础。经过一个季度的推行,虽然取得一些成果,但依然离我的期望有很远的距离,过程也比较累。

近几年很多大公司都在向集成研发,共享研发方向转型,这是一个趋势。特别是阿里的中台战略就是一个特别典型的案例,通过设立共享事业部整合内部的研发资源,通过中台架构积累共享的平台能力,经过几年的阵痛,阿里的中台战略逐渐开始显露威力。

所以组织架构转型,着手打造一个优秀的研发体系,从长远看对业务的发展具有很大的推动作用,否则后面会越来越慢,越来越乱。

我在《互联网产品运营体系总结之产品设计》一文中曾总结了产品设计的框架模型,顺着我做产品的习惯,研发体系可以虚拟成我要做的产品,相对应的我依然提炼了一个框架模型。

研发体系思维框架

前提:清晰的业务模式

技术是为业务服务的!不管是技术驱动还是市场驱动,首先要清晰的了解公司的战略方向和规划,清晰的了解业务模式,因为不同的业务模式对于研发的要求也不是不同的,世上没有万能的理论和方法,只有因地制宜的实践。

在一次会议上,Boss曾提醒我说,“如果方向不对,管理做的越好可能离目标越远”,非常有道理,所以研发体系不只是一个技术活,它更是对公司战略分解的一个重要环节。

不同业务模式关注点

那我们的业务模式是什么呢?基于自己的业务模式我们又关注哪些因素呢?

用于举例说明,我简单的把业务模式抽象成:软件外包模式,产品销售模式,云服务模式和平台模式。前两种偏传统软件业务,后两种偏互联网业务,它们肯定会存在若干的差异(如上图表格,仅做示例,不全面)。

当然还有其他关注维度的划分,比如:从领域上分为行业应用、大数据应用、人工智能、基础技术服务等等,不论什么维度或者多维组合,我们要清晰的知道我们在哪!

而且我们也不能仅仅考虑当前的现状,还要考虑公司的战略规划和业务发展的要求,假如现在以做项目为主,但项目意味着源源不断的需求,这些需求沉淀积累就可能会变成产品,产品反过来又不断的支撑项目。

软件产品互联网化就转变成云服务模式,云服务免费提供,服务开放也说不定变成平台。研发体系根据业务的变化和发展的不同阶段,要在时间和空间维度上建设的更加立体,有效的支撑业务的多样和多变!过早的投入是浪费金钱,太晚的投入是浪费时机,研发体系的建设也要讲究节奏!

发展:高效的产品转化

定制化的外包项目的毛利率在整个行业基本上不会超过30%,而产品(不管是单体软件还是平台上的功能,我们都可以称之为产品)代表着它具备通用性和普遍性,也就意味着产品具有很强的可复制能力,如何有效的支撑业务换句话讲就是看能否高效的进行产品的生产,不断满足更多客户的需求。

现在产品经理的岗位越来越多,也越来越受重视,因为产品经理的职责是设计产品,带领产品发展,是公司发展的强大支撑。

有的产品经理嗅觉敏锐,发现不为人知的机会,并有效的转化为产品上的解决方案,我们习惯成为市场型的产品经理,这一类产品经理是可遇不可求的,遇到了就是幸运。其实我们大多数都是从项目中去提炼普遍性的需求,最后转化为产品。

图4:需求转化路径

项目是需求的来源,它能不断丰富我们产品能力,前提是我们需要建立一个这样的体系,培养这样的意识去积极的挖掘项目中的产品需求。

很多公司的研发团队分为项目团队、产品团队还有比较纯粹的技术支撑团队,所以设计一个合理的协作流程并有效执行,有效的实现需求的转化,这是研发体系要重点去建设的。(当然需求的转化也要考虑到我们的业务方向和定位,过度的需求转化会让我们战线拉的太长,导致资源分散。)

动力:优秀的平台架构

根据图4的需求转化模型,产品的丰满不仅需要项目需求源源不断的滋养,它也依赖底层平台的支撑。

不论技术平台还是产品平台,平台的主要作用是:

  1. 需求的通用性的高度抽象,使其更标准化,便于复用,提升效率;
  2. 底层架构的设计、技术实现的封装,实现功能的可扩展性,支持更多场景。

平台的核心是低耦合,高内聚,一个大点的团队,可能存在不止一个平台,比如:互联网业务和企业应用之间存在着较大的差异,可能构建不同的平台来支撑不同的业务。比如:我在负责掌上医讯业务时,它本身是面向C端的互联网应用,我们构建了代号为camel的平台用来支撑和该业务相关的产品和项目,在公司内部的其他团队可能也存在着其他的各种各样的平台。

中台近几年特别火,阿里的中台架构开始被众多公司去学习模仿,但是如果我们不能理解中台的内涵,我们就会陷入更多的疑惑中,它和平台有什么区别?它到底承担什么作用?

中台不是凭空而来,也不是平台化架构换个名字。中台化架构是平台化架构的自然演进。平台化目标是高内聚、低耦合;职责边界清晰;易于集成等。那么中台化架构进一步可总结为:高内聚、低耦合;数据完整性原则;业务可运营原则。

简单的说,平台关注的更多是技术属性架构设计,所以平台的功能设计我们一般讲究业务无关性的设计原则,而中台在平台的基础上更关注的是业务属性的架构设计,它把业务的最佳实践进行更标准化、更具有扩展能力的设计。

所以中台不是多个平台的集合,否则中台就毫无意义,而是它应该具备以下几个特点:

  1. 公共业务组件的抽象设计,业务功能上实现更好的复用,减少重复建设,提高效率,降低成本;
  2. 过去叫集成平台,现在叫共享中台,一种是被动的事后工作,一种是主动的事前规划,都是为打破孤岛而生;
  3. 因为是主动共享,中台一个很大的作用就是它能快速孵化新产品,加快创新业务的发展进程,我认为这才是中台架构最有价值的地方。

医疗服务中台架构

并不是所有的企业都适合做中台,像图3提到的那四种业务模式,前两种有平台就足够了,后两种就比较适合去构建中台,特别是平台化、生态化的企业。为了更直观的展现中台的架构。

我简单设计了一个医疗服务行业的中台架构(蓝色部分为中台部分),图好画,事难做。如果阿里的中台没有成为集团战略强力的自上而下推动,也很难成功。因为中台架构首先要调整组织架构以适应新的业务架构,而且过程中充满了各种矛盾,没有组织的强力推动,中台是很难成功的。但中台一旦成功,这就是产品研发最强有力的动力,为业务提供源源不断的能量。

基础:规范的研发管理

远大的理想不可缺少,但基础的能力更需要关注,否则就是好高骛远,伟大愿景则如空中楼阁,没有根基!所有的管理都是管人、管事、管物、研发管理也是如此。研发管理更偏重工程管理,研发过程就像构建一座城市,更加系统化,更加立体化。

研发管理的范围

相对于其他的管理侧重管人不同,它首先更关注对物的管理。首先物作为工具意味着成本,分散式的研发团队很容易犯的错误就是对技术栈的管理。就像我们团队,存在三种主流服务端语言,现在要搞研发协同,资源根据项目情况进行调配平衡,技术体系都不一样,我想帮你但我不会你的技术,我这里闲的蛋疼也只能看着你忙的焦头烂额。

像我们这样规模的团队,人力一直都不够用,如果技术路线不控制,意味着研发成本根本没法控制,协同性太差也就意味着存在更多的浪费,效率是低下的。所以第一步就是要根据多数人使用的技术确定统一的技术路线,其他技术的团队和人员要逐步开始向这个技术路线来靠拢,大力推行微服务架构,支持异构系统之间的集成共享。

同时建立新技术的引进制度,我们鼓励创新,但一旦引入生产环境,我们需要进行技术评审,因为每引进一项新技术也就意味着为团队增加一项成本,我们必须评估它带来的价值。

其次,有些物是我们过程的成果,比如代码,文档,方案,这是我们的宝贵资产,过去它分散在各处,既不安全,而且不能形成知识,这就非常的可惜,所以这些都是我们做研发管理最基础的事情,没有这些基础,团队就无从建设,事情就混乱不堪。

协同是我们提倡的,但是它是一种精神,一种态度,我们不能过度的依赖它。我们所依赖的是大家的职责是清晰的,因为屁股决定脑袋!过去我们完全产品线的团队划分,考核的指标是产品的指标,现在我们需要共享研发。

谁去做共享的这部分?大家都在做广度,谁又该去做深度?

完全依靠协同是不行的,必须职责清晰。研发体系是立体结构,是T字型结构,如图4和图5所示,我们既要兼顾事业(如产品线)的维度,又要形成前台-中台-后台的分层梯队,按照不同的能力进行组织的调整。所以大部分的改革首先要伴随着人员的调整,因为屁股决定脑袋,屁股不动思想就不会动!

前几天在《领导力培训》上老师讲的,管理只要搞定了人,也就没有难办的事。

我很认同,毕竟事在人为嘛!对事情的管理最基本的建立基本的做事流程,建立各种评审机制,这些相对都不难,难的是在没有形成研发文化或者low一点说是研发习惯之前,执行必须靠盯。我们做cmmi,做项目管理培训那些理论不知道学了多少遍,但回头想想,那些规范、流程基本都躺在文档库里睡大觉了。

因地制宜,找到适合自己团队的方法,哪怕是很简单,关键是贵在坚持,在实践中不断的完善它,直至形成习惯和文化。

啰嗦了这么多,其实很多思路也没有表达出来,也有很多东西没有想清楚,研发体系的建设是一个长期的工程,并非一日之功,我们只要保持足够的重视,不断的实践,就一定能做好。

有人说研发部门是成本中心,其实我更愿意称它为效率中心、创新中心,因为它不仅仅是服务业务,更多时候是助力业务发展,是企业发展的核心动力。

  • 暂无推荐