业务服务化给团队、技术带来的影响

业务服务化开发模式，有别于传统的开发，其对技术、团队协作有一定的影响。这种影响是多面的，有不利的，更有有利的一面。随着现代化应用系统规模的不断扩大，传统开发模式面临挑战，为此，通过“服务化”开发模式，从“团队协同”和“技术选型”两个层面对研发体系进行解耦。

我在这里简要说明“服务化”开发给技术选型、团队协同带来的有利影响：

技术选型

服务化要求业务以“服务”的方式对外提供，而“服务”本身不仅在功能方面做出了约定，更在“协议”层做出了约定。服务要站在“业务功能”的角度对外提供一致的服务，业务功能主要靠系统设计者根据具体的业务需求对服务进行有效、合理的规划和切分；服务的一致性则由“协议”来保证，即：所有的服务必须遵循一定的业务规范和协议标准提供服务。如：在本团队中，采用基于阿里巴巴dubbo的服务治理体系作为服务的发布和管理平台，基于该平台的所有服务必须遵循Java RPC和dubbo通信协议。如果服务要实现不同终端的调用，如：手机端、微信端直接访问服务，甚至是其他异构系统的访问，服务还必须具备支持多种通信协议的能力。
基于统一的协议和业务接口，服务本身的实现方式就可以不受技术的约束和团队的约束，即：团队可以根据实际的需要，选择最有力的工具来构建服务，只需要服务遵循统一的协议和规范，就能够实现服务的集成。由于“服务化”，团队在技术选型上就具有了更好的弹性，能够最大化地发挥自己的能力水平和技术经验，而不是受限于“管理”的需要降低“生产力”。

团队协同

服务化提供技术弹性的同时，也为团队协同带来了更多的操控空间。原来，一个项目多个团队之间需要在同一个“框架”下工作，这就要求通过项目前期、项目中期乃至项目后期的技术管理工作和项目管理工作抹平团队之间的差异，要求所有人在“无差异”的环境下进行协同。此种愿景的实现是很难的，现实中想要所有人都变成一样的人不具有可操作性（特别是在规模较大的组织中，这种理想化的管理理念往往造成巨大的资源消耗和成本浪费）。因此，从实操层面考虑团队协同，就必须建立一套具有“弹性”的协作机制，来整合不同团队的“生产力”，以便最终集成不同团队的“产出成果”。这里的产出成果就是各个团队构建的系统的不同功能，要求以“服务”的形式提供这些功能，根据上面的阐述，基于统一的协议和业务接口，可以方便地集成服务，即：实现了对不同团队工作成果的集成。服务可以集成，本质上就意味着服务可以“复用”。而高度复用是软件研发所追求的效率目标之一。由于协作的目标落在了“最终的集成”而不是过程的整合，也就给各个团队带来了更多的工作空间，团队可以在“最终目标”的统一引导下，在“统一协议和接口规范”的框架下，因地制宜地开展工作，实现团队自身的“高内聚”和团队之间的“低耦合”！

服务化的现状

虽然各团队都开始采用dubbo服务治理框架，但在实际研发过程中，存在“服务落地”的差异，导致最终的服务仍旧不能很好地在dubbo中实现集成，主要体现在一下几个方面：
1. 业务服务的规划和切分不够合理。由于研发团队往往关注的是技术实现，忽略了系统的“业务性”，在规划服务的时候没有充分站在业务角度考虑。而在服务切分的时候，又受到“数据库结构”的影响，服务切分太过技术化，服务的用例不够明确、粒度不够精准。如：很多时候，团队把某种业务简单地切分成对某些数据的增删改查“动作”，导致服务的操作难度增加，把业务逻辑的整合丢给了“用户”。如：企业微贷申请，金融机构要对企业贷款的目的、应用途径、企业现状进行审查，还要根据企业现状的不同对企业信用进行审查，甚至还要审查社会评级。对企业微贷申请业务而言，只需要关注“申请”，而无须关注“申请”之下的逻辑。如果服务粒度切分过细，把一个服务拆分为三个甚至更多个，就导致业务服务内部复杂多变的逻辑暴露给“用户”。而业务内在逻辑的复杂度本就是“计算机和软件”该解决的问题，暴露给用户的应该是简洁明确的业务事务。
2. 由于问题1的存在，团队在协同开发时，就面临服务无法复用的问题。“复用”有以下几种方式：
a. 代码级复用
b. 组件级复用
c. 服务级复用
d. 产品（即：系统）级复用
服务化的核心目标之一就是实现“服务级”复用。但是，由于服务规划和切分存在诸多不合理性，导致服务的内容——业务——与构建技术紧密地捆绑在一起，业务要想集成，技术就必须“完全一致”。技术一致的主要表现是：开发所采用的框架、框架中各组件的版本要完全一致（最起码必须是兼容的），同时也要求团队的开发方式、编码规范也要保持一定程度的一致性。技术一致，基本上就要求各个团队要完全一样，而这就会碰到“抹平团队差异”的问题。因此，不具有可操作性。
另外，团队之间在“复用”的概念上存在差异，服务化是共同的目标，但在落地的过程中却退化为“代码复用”或“组件复用”，如此，就必然考虑“统一技术”，也就引发了“谁向谁统一，谁向谁妥协”的矛盾，而这种矛盾恰恰体现为团队之间的差异。同理，如果想从这个层面解决问题，就必须“统一团队”。研发一体化是很多公司用来实现“统一”的常用手段，但客观结果是“统一”的过程漫长且充满各种矛盾，造成相当的内耗以及资源流失。国内著名企业阿里巴巴，也恰恰是dubbo的创造者，直到今天也未能实现“研发一体化”，而是采用了“弹性机制”有效地整合了组织内所有的研发力量。

“研发一体化”的挑战

1. 在实施“研发一体化”过程中，如何解决“团队差异”的问题？（目前未感觉到有策略来处理这个问题，在多团队管理的过程中，必然要正视这个问题，而这也是“研发管理”的根本所在。处理不好这个问题，就如果中国处理不好“一国两制”的问题一样，其结果可能不仅没有实现“研发一体化”，反而让团队本来各自具备的能力和资源被分解，形成一盘散沙的局面）
2. 在实施“研发一体化”过程中，如何促进团队的发展，是“百花齐放”，还是“灰化成堆”？
3. 在实施“研发一体化”过程中，如何建立组织“核心技术”体系，实现技术横向和纵向的可扩展性？

“弹性机制”的优势

“弹性机制”首先是一套机制，而非一套事无巨细规章制度。该机制的核心是“弹性”。在一个具有“弹性”承诺的空间中，位于不同层次的团队都能找到自己的生存空间，更能找到自己的发展空间。“弹性”承诺团队都可以积极发展，虽然前进的速度有所不同，但允许存在适度的差距。在这样的机制下，传统的KPI也能有适用之地，采取“优胜劣汰”对太过落后的团队进行裁撤，推动优势资源不断向前发展。在整个“弹性”空间中，后面的团队可以参考其他团队的发展轨迹，寻找适合自身的发展路径；而处于前面的团队则需要投入更多的精力和能力，通过不断创新，实现团队的新突破。基于这样的一种模式，整个组织都在向前稳步发展。
其次，“弹性机制”不存在“技术性”硬性要求，这就给各团队提供了主动探索的动力和可能性。作为软件研发团队，技术永远是发展的“第一生产力”。软件研发更是技术的一种直接体现。无论是客户的需求，还是业务发展的需要，都要求技术具备灵活可扩展的能力。这种能力完全需要“人”（即：软件研发人员）来承载。如果在一个封闭的、桎梏的空间中，即便原来拥有很强的技术，这种技术也基本停滞不前了。只有突破这层封闭，才能扩展见识，不断丰富“人”的头脑，建立丰富的知识能力体系。但同时，作为组织的构成要素，为了确保组织的“整体性”，需要通过一种机制来保证这种能力体系在一个有序的模式下进行（当然，有人会要求在一个“可控”的模式下运行，我个人认为“有序”比“可控”更具有实际意义），这样的知识能力才具有可继承性、传播性和延续性。所以，“弹性机制”下，团队、技术可以在有序的环境下实现自主发展，同时“机制”也保证了组织的整体性，让组织的管理者在一个可控的范围内实施团队治理。