怎样打造研发体系?打造研发体系的步骤

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

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

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

结合自身团队，突出的问题表现在：

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

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

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

图1:IPD研发管理体系

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

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

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

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

研发体系思维框架

前提：清晰的业务模式

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

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

不同业务模式关注点

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

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

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

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

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

发展：高效的产品转化

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

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

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

图4：需求转化路径

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

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

动力：优秀的平台架构

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

不论技术平台还是产品平台，平台的主要作用是：

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

平台的核心是低耦合，高内聚，一个大点的团队，可能存在不止一个平台，比如：互联网业务和企业应用之间存在着较大的差异，可能构建不同的平台来支撑不同的业务。