研发无小事，事事要重视。短期看效益，长期看体系！
做了几年的产品，刚混熟了产品圈，今年又临危受命负责整个研发团队，对过去分散式的研发体系（研发在各事业部）进行整合，研发统一管理。
过去我们一个产品一个产品的突破，逐步形成了多产品线的研发模式，这种模式突出的优点就是敏捷迅速，能结合市场快速的试错，拥抱变化。但是当业务发展到一定阶段，这种太过分散式的管理就会产生一系列的问题，又给发展带来一定瓶颈。
结合自身团队，突出的问题表现在：
产品分散重叠，产品线之间信息缺乏共享，公共部分产生重复开发；
缺少统一技术路线，多语言，多技术体系，不利于深度积累和合作协同；
研发人员分散管理，容易产生资源缺乏和浪费，且协同成本巨大。
其实这些问题在一些大的互联网公司都经历过，像腾讯、阿里这样的公司他们经历的时间也更长，毕竟业务发展太快，来不及调整只能往前冲。如何打造一个既能解决以上问题，又能依然保持早期的敏捷灵活，这的确是一个难题。这就像春秋战国一样，划分诸侯国容易，但是再把他们合起来那就太难了。
难点1：某些业务和产品已经成型，我们知道存在很多重复和浪费，但共享重构是需要付出巨大时间成本和人力成本的，既要修车又不能把车停下来。
难点2：每个团队的技术路线已经成型了，切换的成本是巨大的，但不切换未来的成本会更高，很纠结。
难点3：山头已经形成，打破山头重新组合，虽然说是不破不立，但必然带来很多不安定因素。
图1:IPD研发管理体系
好在IPD（集成产品开发）的研发管理模式，给我提供了一定的理论基础。经过一个季度的推行，虽然取得一些成果，但依然离我的期望有很远的距离，过程也比较累。
近几年很多大公司都在向集成研发，共享研发方向转型，这是一个趋势。特别是阿里的中台战略就是一个特别典型的案例，通过设立共享事业部整合内部的研发资源，通过中台架构积累共享的平台能力，经过几年的阵痛，阿里的中台战略逐渐开始显露威力。
所以组织架构转型，着手打造一个优秀的研发体系，从长远看对业务的发展具有很大的推动作用，否则后面会越来越慢，越来越乱。
我在《互联网产品运营体系总结之产品设计》一文中曾总结了产品设计的框架模型，顺着我做产品的习惯，研发体系可以虚拟成我要做的产品，相对应的我依然提炼了一个框架模型。
图2：研发体系思维框架
前提：清晰的业务模式
技术是为业务服务的！不管是技术驱动还是市场驱动，首先要清晰的了解公司的战略方向和规划，清晰的了解业务模式，因为不同的业务模式对于研发的要求也不是不同的，世上没有万能的理论和方法，只有因地制宜的实践。
在一次会议上，Boss曾提醒我说，“如果方向不对，管理做的越好可能离目标越远”，非常有道理，所以研发体系不只是一个技术活，它更是对公司战略分解的一个重要环节。
图3：不同业务模式关注点
那我们的业务模式是什么呢？基于自己的业务模式我们又关注哪些因素呢？
用于举例说明，我简单的把业务模式抽象成：软件外包模式，产品销售模式，云服务模式和平台模式。前两种偏传统软件业务，后两种偏互联网业务，它们肯定会存在若干的差异（如上图表格，仅做示例，不全面）。
当然还有其他关注维度的划分，比如：从领域上分为行业应用、大数据应用、人工智能、基础技术服务等等，不论什么维度或者多维组合，我们要清晰的知道我们在哪！
而且我们也不能仅仅考虑当前的现状，还要考虑公司的战略规划和业务发展的要求，假如现在以做项目为主，但项目意味着源源不断的需求，这些需求沉淀积累就可能会变成产品，产品反过来又不断的支撑项目。
软件产品互联网化就转变成云服务模式，云服务免费提供，服务开放也说不定变成平台。研发体系根据业务的变化和发展的不同阶段，要在时间和空间维度上建设的更加立体，有效的支撑业务的多样和多变！过早的投入是浪费金钱，太晚的投入是浪费时机，研发体系的建设也要讲究节奏！
发展：高效的产品转化
定制化的外包项目的毛利率在整个行业基本上不会超过30%，而产品（不管是单体软件还是平台上的功能，我们都可以称之为产品）代表着它具备通用性和普遍性，也就意味着产品具有很强的可复制能力，如何有效的支撑业务换句话讲就是看能否高效的进行产品的生产，不断满足更多客户的需求。
现在产品经理的岗位越来越多，也越来越受重视，因为产品经理的职责是设计产品，带领产品发展，是公司发展的强大支撑。
有的产品经理嗅觉敏锐，发现不为人知的机会，并有效的转化为产品上的解决方案，我们习惯成为市场型的产品经理，这一类产品经理是可遇不可求的，遇到了就是幸运。其实我们大多数都是从项目中去提炼普遍性的需求，最后转化为产品。
图4：需求转化路径
项目是需求的来源，它能不断丰富我们产品能力，前提是我们需要建立一个这样的体系，培养这样的意识去积极的挖掘项目中的产品需求。
很多公司的研发团队分为项目团队、产品团队还有比较纯粹的技术支撑团队，所以设计一个合理的协作流程并有效执行，有效的实现需求的转化，这是研发体系要重点去建设的。（当然需求的转化也要考虑到我们的业务方向和定位，过度的需求转化会让我们战线拉的太长，导致资源分散。）
动力：优秀的平台架构
根据图4的需求转化模型，产品的丰满不仅需要项目需求源源不断的滋养，它也依赖底层平台的支撑。
不论技术平台还是产品平台，平台的主要作用是：
需求的通用性的高度抽象，使其更标准化，便于复用，提升效率；
底层架构的设计、技术实现的封装，实现功能的可扩展性，支持更多场景。
平台的核心是低耦合，高内聚，一个大点的团队，可能存在不止一个平台，比如：互联网业务和企业应用之间存在着较大的差异，可能构建不同的平台来支撑不同的业务。比如：我在负责掌上医讯业务时，它本身是面向C端的互联网应用，我们构建了代号为camel的平台用来支撑和该业务相关的产品和项目，在公司内部的其他团队可能也存在着其他的各种各样的平台。
中台近几年特别火，阿里的中台架构开始被众多公司去学习模仿，但是如果我们不能理解中台的内涵，我们就会陷入更多的疑惑中，它和平台有什么区别？它到底承担什么作用？
中台不是凭空而来，也不是平台化架构换个名字。中台化架构是平台化架构的自然演进。平台化目标是高内聚、低耦合；职责边界清晰；易于集成等。那么中台化架构进一步可总结为：高内聚、低耦合；数据完整性原则；业务可运营原则。
简单的说，平台关注的更多是技术属性架构设计，所以平台的功能设计我们一般讲究业务无关性的设计原则，而中台在平台的基础上更关注的是业务属性的架构设计，它把业务的最佳实践进行更标准化、更具有扩展能力的设计。
所以中台不是多个平台的集合，否则中台就毫无意义，而是它应该具备以下几个特点：
公共业务组件的抽象设计，业务功能上实现更好的复用，减少重复建设，提高效率，降低成本；
过去叫集成平台，现在叫共享中台，一种是被动的事后工作，一种是主动的事前规划，都是为打破孤岛而生；
因为是主动共享，中台一个很大的作用就是它能快速孵化新产品，加快创新业务的发展进程，我认为这才是中台架构最有价值的地方。
图5：医疗服务中台架构
并不是所有的企业都适合做中台，像图3提到的那四种业务模式，前两种有平台就足够了，后两种就比较适合去构建中台，特别是平台化、生态化的企业。为了更直观的展现中台的架构。
我简单设计了一个医疗服务行业的中台架构（蓝色部分为中台部分），图好画，事难做。如果阿里的中台没有成为集团战略强力的自上而下推动，也很难成功。因为中台架构首先要调整组织架构以适应新的业务架构，而且过程中充满了各种矛盾，没有组织的强力推动，中台是很难成功的。但中台一旦成功，这就是产品研发最强有力的动力，为业务提供源源不断的能量。
基础：规范的研发管理
远大的理想不可缺少，但基础的能力更需要关注，否则就是好高骛远，伟大愿景则如空中楼阁，没有根基！所有的管理都是管人、管事、管物、研发管理也是如此。研发管理更偏重工程管理，研发过程就像构建一座城市，更加系统化，更加立体化。
图6：研发管理的范围
相对于其他的管理侧重管人不同，它首先更关注对物的管理。首先物作为工具意味着成本，分散式的研发团队很容易犯的错误就是对技术栈的管理。就像我们团队，存在三种主流服务端语言，现在要搞研发协同，资源根据项目情况进行调配平衡，技术体系都不一样，我想帮你但我不会你的技术，我这里闲的蛋疼也只能看着你忙的焦头烂额。
像我们这样规模的团队，人力一直都不够用，如果技术路线不控制，意味着研发成本根本没法控制，协同性太差也就意味着存在更多的浪费，效率是低下的。所以第一步就是要根据多数人使用的技术确定统一的技术路线，其他技术的团队和人员要逐步开始向这个技术路线来靠拢，大力推行微服务架构，支持异构系统之间的集成共享。
同时建立新技术的引进制度，我们鼓励创新，但一旦引入生产环境，我们需要进行技术评审，因为每引进一项新技术也就意味着为团队增加一项成本，我们必须评估它带来的价值。
其次，有些物是我们过程的成果，比如代码，文档，方案，这是我们的宝贵资产，过去它分散在各处，既不安全，而且不能形成知识，这就非常的可惜，所以这些都是我们做研发管理最基础的事情，没有这些基础，团队就无从建设，事情就混乱不堪。
协同是我们提倡的，但是它是一种精神，一种态度，我们不能过度的依赖它。我们所依赖的是大家的职责是清晰的，因为屁股决定脑袋！过去我们完全产品线的团队划分，考核的指标是产品的指标，现在我们需要共享研发。
谁去做共享的这部分？大家都在做广度，谁又该去做深度？
完全依靠协同是不行的，必须职责清晰。研发体系是立体结构，是T字型结构，如图4和图5所示，我们既要兼顾事业（如产品线）的维度，又要形成前台-中台-后台的分层梯队，按照不同的能力进行组织的调整。所以大部分的改革首先要伴随着人员的调整，因为屁股决定脑袋，屁股不动思想就不会动！
前几天在《领导力培训》上老师讲的，管理只要搞定了人，也就没有难办的事。
我很认同，毕竟事在人为嘛！对事情的管理最基本的建立基本的做事流程，建立各种评审机制，这些相对都不难，难的是在没有形成研发文化或者low一点说是研发习惯之前，执行必须靠盯。我们做cmmi，做项目管理培训那些理论不知道学了多少遍，但回头想想，那些规范、流程基本都躺在文档库里睡大觉了。
因地制宜，找到适合自己团队的方法，哪怕是很简单，关键是贵在坚持，在实践中不断的完善它，直至形成习惯和文化。
啰嗦了这么多，其实很多思路也没有表达出来，也有很多东西没有想清楚，研发体系的建设是一个长期的工程，并非一日之功，我们只要保持足够的重视，不断的实践，就一定能做好。
有人说研发部门是成本中心，其实我更愿意称它为效率中心、创新中心，因为它不仅仅是服务业务，更多时候是助力业务发展，是企业发展的核心动力。
故研发无小事，事事要重视。短期看效益，长期看体系！
附研发体系脑图供交流讨论：
图7：研发体系建设思路脑图
