推荐购买《中台战略-中台建设与数字商业》正版纸质书籍阅读
4.5.1 经验：持续迭代完善
企业要快速成长，需打造以面向交互对象为核心的特种部队型前台、交互作战单元，以快速响应、迭代交互。事实上，中台组织就是前台交互作战单元的航空母舰，它以聚合的方式帮助前台快速匹配所需的能力及资源，进而实现敏捷响应用户快速变化的需求。同时中台能帮助领先企业将现有核心能力产品化、业务化，在中长期延展现有业务生态，开拓全新的收入及利润来源。
4.5.2 教训1：团队组织错误
某个项目的研发团队进行了两次调整。研发团队最初分成三大项目组，其中一个项目组负责大中台的所有服务与前台应用的开发；另一个项目组负责采购、仓储等供应链体系的开发，与SAP关系紧密；还有一个项目组负责测试。每个项目组内又按职能细分为若干个小组，如Java小组、H5小组、App小组等。而产品小组是一个独立中心项目组，他们设计好产品原型后直接交由技术部门评估、开发并实施。产品组负责整体项目的进度，并验收成果。
第一次调整，将各职能全部打散，划分两个大的项目组——数字供应链项目组与数字商城项目组，各项目组是一个完成的实施主体，包含了各种职能，产品小组负责将产品的《需求规格说明书》提交到两大项目组，统一由项目组进行项目管控。
第二次调整，按产品线分为6个小组，每个小组由7人左右的敏捷团队组成。其中，中台是敏捷开发组之一，2周上线一个迭代版本。当一个迭代在开发时，原则上不允许需求变更，若有需求，放到下一个迭代版本完善。业务架构师们负责迭代规划、原型设计以及《需求规格说明书》的编写。所有产品线统一测试，由测试人员宣布迭代上线的时间点。经过这一次的调整，无论是项目进度还是效果都将得到大幅提升。敏捷开发这种小组作战的形式，以及谁开发谁负责的原则，能培养每个小团队成员的主人翁意识和积极主动的精神，打造目标一致而又松耦合的、快速响应的团队。
许多管理人和领导者都陷入一种迷思，认为增加更多的人力是好的，因为人是最宝贵的资产，所以投入人力应该是提升整体效能的最好方法。但事实是，大规模组织让人们变得过度自信。这是因为人们倾向于在团体规模扩张时，低估完成工作的时间。有这样一个实验，当被要求完成相同的乐高模型时，两人小组花费了36分钟的时间，四人小组却花了52分钟，比两人小组所花的时间整整多出44%。
4.5.3 教训2：业务拆分不清
对业务理解不透，导致业务梳理和系统规划的时候抓不住重点，设计出的系统不能满足实际需求。例如，某企业的业务复杂度高，同时存在各种销售模式，有直销、经销、预售等；存在多业态，有商业地产、泊寓、教育、酒店；存在多种会员类别，有家庭会员、个人会员。在业务设计之初为了能够快速响应业务需求，将用户中心与会员中心的服务进行了整合，但随着业务的发展，在迭代开发过程中造成了大量的混乱信息，使团队的管理和维护成本大大增加。后续还是将用户中心与会员中心分开才解决问题，过程中走了很多弯路。
4.5.4 教训3：微服务被滥用
中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业的。中台的建设过程虽然可以自下而上、由点及面，但驱动力一定是自上而下、从全局出发的，并且需要一定的顶层设计。
企业级也是区分企业中台化与应用系统服务化的关键点，简而言之，中台化是企业级、全局视角的，微服务化更多是系统级、局部视角的。从组织架构模式的角度，“中台”突出的是规划控制和协调的能力，而“前台”强调的是创新和灵活多变。微服务不是越多越好，一定要根据实际的业务做相应的匹配，设置一个独立的业务单元，单独提供一个系统服务。
某个项目中台设计之初，整体拆分出了80个微服务，16个共同组件，需要应用服务器86台，人员维护成本相当高。优化以后，微服务缩减到了26个，应用服务器只需要33台。
4.5.5 教训4：系统过度设计
大部分微服务案例只能看到微服务架构的“演进结果”，而看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰，却看不到攀登高峰的路径。这就给很多架构师一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。在中台建设过程中，往往也会陷入这样的误区。软件架构的最基本规律是解决当前的需求和痛点，无法对没有出现的问题和痛点进行设计。因此，一步到位的整体的微服务架构设计完全没有必要。况且一个集中化的设计很难体现微服务的轻量级优势，因此也违背了创新工作法的原则，结果会导致业务真正需要创新的时候，把之前设计的内容又推翻重来。
