作为产品研发，我们如果既要降本增效，又想保持创新，没有合理的匹配的研发组织，那也只是一场梦而已。本文作者分享了关于没有匹配的研发组织，如何实现高效的产品研发，我们一起来看一下。
最近阿里一系列的组织架构调整，随之而来对阿里拆中台等相关解读的文章又尘嚣直上，再加上中台这几年的发展，大家对中台充满了争议，中台死亡论也成了一股暗流。
有人把它捧到天上，又有人把它甩到茅房；我认为中台概念现在没有可以丈量的标准，一千个人就有一千个中台的模样，有的人运用中台提升了组织的运行效率；有的人建中台却劳民伤财最后失败告终，中台没有错，只是用的人用错了而已。
很多传统企业数字化转型，太过强调中台的平台属性却忽视了更为重要的组织属性，一个不能变革组织的中台建设是注定要失败的；因为所有事情的执行者是人，没有匹配的组织架构，没有合适的岗位人员，相应的事情就很难执行。
一、从大秦帝国看中台
最近大秦赋在热播中，“及至始皇，奋六世之余烈，振长策而御宇内，吞二周而亡诸侯，履至尊而制六合，执敲扑而鞭笞天下，威振四海。”看的我们也是心潮澎湃，激昂壮烈。
回顾那段历史，我一直在思考，为什么是秦国一统天下，结束五百年的诸侯之争，为什么秦朝短短十几年就走上覆灭之路，它对后世中国带来哪些影响呢？它对我们的工作有什么指导启示吗？
和春秋战国时期的周王朝相比，秦制的本质是实行中央集权的郡县制，撤销了诸侯国，有人说秦制就是大中台，书同文、车同轨，其实就是one id；这么说也是有一定道理的，中台的本质就是由过去分散式的前台应用独立建设转变为统一建设，以达到更好的能力积累和复用。
但有人把秦二世亡国类比中台的死亡，这就有点牵强了。
秦朝灭亡从表面上来看是秦二世的昏庸无道，实行暴政，本质上更多是秦朝中央集权的政治改革过于激进，对过去的分封体制是一种颠覆，对于法家思想的过度执念，这样的改革只有像秦始皇这样雄才大略的帝王才能hold住；如果再给秦始皇更多的时间，也许秦朝就不至于二世灭亡。所以汉朝初期采用了郡县制和分封制结合的模式，循序渐进的进行改革，直到汉武帝平定七国叛乱，最终实现中央集权在后世中国的深远影响。
书同文、车同轨其实就是中台要建立统一的标准、规范，这对于组织的协同，对于能力的复用都有帮助；按道理这对于企业管理来说，或者对于研发来说，都是一件好事情，为什么却有那么多人中伤中台呢？
我认为中台的建设中，始终存在着管控与自主，稳定与创新等矛盾，这就需要强大的组织领导力，能打破原有的组织关系，不怕动某些人的利益才能完成。
很多中台失败的案例大多数是只有变革之心，却无变革之力。
二、合理的研发组织是基础
中台架构一般是一些具备大型复杂生态系统的大公司在自主的前台和统一的后台寻求平衡的结果；对于大部分小公司来说，中台架构离我们还是比较远，所以我一直强调，对于中台架构要重其神而轻其行。
中台架构的成功的基础是中台组织的建立和保障，对于研发来说，一个合理的研发组织也是高效研发的基础。
笔者早几年负责一个互联网产品的技术团队，这是一个创业阶段的小团队，整个技术团队也就十几个人，业务也相对来说比较单一；所以组织架构相对来说就比较简单，分成了后端Java开发团队和APP开发团队，平时以产品迭代为主，偶尔也协调资源做一些和客户有关或者运营活动有关的项目。
此时职能团队是实线管理团队，而项目因为存在可变化性，是临时的虚线团队。
随着业务发展，前台出现两个业务团队的时候，两个业务团队为了更好的让技术团队服务业务团队，开始要求拆分技术团队到业务单元，以便更好的和业务绩效挂钩。
如果该项目业务稳定、资源充足，可以独立成更有自主性的项目团队，否则还是按照虚线的项目团队作为过渡。当时我们就过早的拆分了团队，不可避免的部门墙也导致了在一些新项目时资源协同性很差的问题；好在我还是作为公司的技术总监来统筹技术管理，这个影响还不是很大；所以小团队不要过早拆分，否则资源本身不充足的基础上，又更加难以利用！
一项新的业务，要尽量用现有的功能团队先进行项目初期的开发或者孵化，等项目上线或者成熟后，转由专门支持该项目的效率团队完成后续的迭代升级；所以最终形成如下图的研发组织，有侧重业务线，有侧重功能线。
为了便于更好的协同和技术体系的统一，CTO或者技术委员会将在技术管理中起到重要的作用。
在一个自我演化的团队，只要保证CTO或者技术委员会的统筹和统一的技术管理的作用，技术团队的拆分、裂变都是有序的，技术体系的统一，技术规范的统一，开发流程的一致都能得到有效的维护。
2019年初，我开始负责一个TO B业务的科技公司的整体研发，很不幸的是，之前的技术管理做得很不好，表现在存在5个事业部，研发分散在事业部，且技术路线不统一，光主流的后端开发语言就涵盖Java，net和PHP三种；所以后续业务整合、研发统一的过程中，系统和技术的整合也是一件非常头疼的事情；当时尝试了中台化的解决方案，以期通过中台架构实现柔性化的统一。
既然说到中台的柔性，我想对于当前阿里拆中台的猜测表达一下自己的想法，也许阿里是年底正常的架构调整，也许是有人说的中台强管控对于前台应用的制约；如果真是这个原因，我想这和我对中台的理解不同，中台不能做强管控的中台，而是要做柔性的中台，改革是一个循序渐进的过程。
另外，有人把阿里前台创新的不足归结于中台的制约，我认为也是比较牵强的；中台不是创新的方向标，它只是创新的加速器，创新是靠的企业文化和管理机制；如果建了中台就能让企业具备创新的能力，这无异于是对中台的不切实际的过高期望。
另外，对于自运营的互联网应用研发的企业和对外实现客户交付的偏软件应用研发的企业，对于研发组织的建设依然会有很大的不同。
互联网企业重运营，所以产品的迭代，对日常运营的支持就会更加的频繁，适合在前台建立全职能的研发团队，以提供更紧密的支持；而交付型的软件企业重销售，前台更侧重产品销售和项目交付，所以更倾向研发统一管理，让专业的人做专业的事，同时更能有效的利用进行技术积累和复用，提升产品研发的效率。
今年我们在部分领域实行了项目带产品的策略，但是由于研发既负责项目交付，又承担产品迭代，在资源紧缺的情况下，两边可能都会耽误，项目交付不能保证，产品研发也不顺畅。
这算是一次小小的教训，如何改变呢？如果团队规模较大，要把项目交付团队和研发团队做一个分离，各司其责，相互协同又不要相互影响。
对于TO B的企业，我们需要从能力线、产品线以及项目线上来建设技术团队，通过CTO或技术委员会保持在跨组织的技术管理，以保证技术战略、技术规范、开发流程的有效统一。
三、不可忽视的康威定律
很多老板看到中台架构很好也请来供应商帮着搞，但是就是搞不好，就感觉阿里宣传的中台是不是吹牛逼。
其实阿里的中台也不是一帆风顺的，没有组织的变革，没有自上而下的强力推动，也是寸步难行。
在钟华的《企业IT架构转型之道》一书中，他形象的给我们展现了，承接中台架构的业务组织–共享业务事业部的发展史，又一次告诉我们IT架构和组织架构密不可分的关系，这就是有名的“康威定律”！
康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”
通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
更直白的说，你想要什么样的系统，就搭建什么样的团队。
如果你的团队分成前端团队，Java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：
相反，如果你的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构。
架构不仅仅需要技术，在大公司尤其需要政治，所谓的架构的政治；所以康威定律一定是要熟悉并合理使用的第一定律，想想那些大公司的产品形态和他们的组织关系，就会发现这么有趣的联系。
所以一些传统企业想要数字化转型，如果还是依托传统的信息部这样的后台组织去搞，十有八九很难成功，需要一个全新的数字化部门大胆的改革。
同样作为产品研发，我们如果既要降本增效，又想保持创新，没有合理的匹配的研发组织，那也只是一场梦而已。
拓展阅读：
向左还是向右？中台建设才不止这点纠结事
半年中台实践的思考：落地中台，贵在其神，活用其形
