研发无小事，事事要重视。短期看效益，长期看体系！
做了几年的产品，刚混熟了产品圈，今年又临危受命负责整个研发团队，对过去分散式的研发体系（研发在各事业部）进行整合，研发统一管理。
过去我们一个产品一个产品的突破，逐步形成了多产品线的研发模式，这种模式突出的优点就是敏捷迅速，能结合市场快速的试错，拥抱变化。但是当业务发展到一定阶段，这种太过分散式的管理就会产生一系列的问题，又给发展带来一定瓶颈。
结合自身团队，突出的问题表现在：
产品分散重叠，产品线之间信息缺乏共享，公共部分产生重复开发；缺少统一技术路线，多语言，多技术体系，不利于深度积累和合作协同；研发人员分散管理，容易产生资源缺乏和浪费，且协同成本巨大。其实这些问题在一些大的互联网公司都经历过，像腾讯、阿里这样的公司他们经历的时间也更长，毕竟业务发展太快，来不及调整只能往前冲。如何打造一个既能解决以上问题，又能依然保持早期的敏捷灵活，这的确是一个难题。这就像春秋战国一样，划分诸侯国容易，但是再把他们合起来那就太难了。
难点1：某些业务和产品已经成型，我们知道存在很多重复和浪费，但共享重构是需要付出巨大时间成本和人力成本的，既要修车又不能把车停下来。难点2：每个团队的技术路线已经成型了，切换的成本是巨大的，但不切换未来的成本会更高，很纠结。难点3：山头已经形成，打破山头重新组合，虽然说是不破不立，但必然带来很多不安定因素。
图1:IPD研发管理体系
好在IPD（集成产品开发）的研发管理模式，给我提供了一定的理论基础。经过一个季度的推行，虽然取得一些成果，但依然离我的期望有很远的距离，过程也比较累。
近几年很多大公司都在向集成研发，共享研发方向转型，这是一个趋势。特别是阿里的中台战略就是一个特别典型的案例，通过设立共享事业部整合内部的研发资源，通过中台架构积累共享的平台能力，经过几年的阵痛，阿里的中台战略逐渐开始显露威力。
所以组织架构转型，着手打造一个优秀的研发体系，从长远看对业务的发展具有很大的推动作用，否则后面会越来越慢，越来越乱。
我在《互联网产品运营体系总结之产品设计》一文中曾总结了产品设计的框架模型，顺着我做产品的习惯，研发体系可以虚拟成我要做的产品，相对应的我依然提炼了一个框架模型。
图2：研发体系思维框架
前提：清晰的业务模式
技术是为业务服务的！不管是技术驱动还是市场驱动，首先要清晰的了解公司的战略方向和规划，清晰的了解业务模式，因为不同的业务模式对于研发的要求也不是不同的，世上没有万能的理论和方法，只有因地制宜的实践。
在一次会议上，Boss曾提醒我说，“如果方向不对，管理做的越好可能离目标越远”，非常有道理，所以研发体系不只是一个技术活，它更是对公司战略分解的一个重要环节。
图3：不同业务模式
