我没进去阿里之前，看过鲁肃写的一篇介绍支付宝技术架构的文章，击节赞叹。进去支付宝以后，发现这应该是一个规划中的架构，实际上下面落实的还是乱糟糟的，大部分支付宝工程师的日常都是在做一些非常繁琐，非常零碎的毫不重要的东西；而且是超负荷996的做……这么辛苦的原因是技术执行层面和规划层面是脱节的。

我观察过很多公司，你去理解他们PPT的宣传，思路和业务都是很清晰，但是你去观察他们的技术团队和代码实现就完全走样了——技术团队非常庞大——但是如此简单清晰的业务其实完全不需要这么多开发，代码实现更是地狱一般，随便一点业务改造都需要跨部门，跨团队，大量开发人员参与，并且很难保证质量和工期——但是这么简单和清晰的业务，其实不应该如此。

从观察的到的现象来看，这是任何组织的一个普遍现象。企业里做的和说的不一样，有多重原因

1，营销的需要
2，规划的需要
3，技术能力不行
4，管理能力不行

现在是一个营销的时代，对于很多互联网公司而言，技术能力其实是企业的核心能力之一，尤其技术是一个扩张成本很低的资产。具有好的技术资产，有利于更高的企业估值，有利于吸引更优秀的工程师，甚至有利于树立良好的个人形象。

有利益，必然蜂拥而上，必然沉渣泛起。
所以必然有不管内部实现如何，先忽悠了再说
所以必然有不管真真假假，PPT做的漂漂亮亮的，名词弄的潮潮的，个人形象弄的好好的
这种情况，对企业而言是需要的，合理的。但是对于听众来说，必须能区分这种情况，避免上当。

对于任何快速发展的企业来说，业务的发展一定是快于系统的规划的。
好的系统是在迭代中产生的，是随着业务发展而发展的，不可能设计阶段就面面俱到，必然有一定的业务滞后性。必然要随着业务发展到某个阶段以后，对业务架构重新进行梳理。而当前业务系统，也不可能完全符合系统架构
所以，规划性的技术架构对于企业而言，是不可避免的，是合理的。
对于听众而言，这是学习，对于员工而言，这是规范和指引。

还有一部分的情况，恐怕是技术能力和管理能力不行。
我常常看到PPT画的架构，和代码落实的完全是两回事——甚至是同一个人既做设计又做开发也是这样的。这种比例非常多非常多，UML彻底沦为交流和总结工具，而不是真正的设计工具。
在UML上，我强调流程图，对象图，时序图，状态图。这几个
流程图表达了业务流程
对象图表达了核心业务概念（实体对象，逻辑对象，值对象）的抽象
时序图是对象图+流程图的详细，状态图是流程的关键状态变化。
大部分开发不了解这几个图内在的关系，更不了解UML和DDD的关系，会忽略掉其中最关键的对象图——没有对象图就没有抽象，就不可能有值对象和逻辑对象的概念，就不可能DDD，就必然代码乱成一坨糟。
不能从开发角度要求，铁打营盘流水并，控制变化和不可控必然是没有结果的，这个要求必然是对核心开发和架构师的要求。

这同时意味着，核心开发和架构必然是要了解业务的。必然是要懂DDD的。不然不可能做好核心开发。
现实情况的架构和核心开发可能更多关注的是性能，懂多少高深的底层技术知识等——这 也是现实情况业务系统如此复杂，难以维护，需要如此多开发，测试，大量996的原因。
这是技术能力不行。

凡事读过人月神话的人大概都知道：向一个陷入焦油坑的项目中投入人员会造成更大的延误。同样的，向一个低效的团队中投入更多的人会造成更低效（参见组织熵）。
我们举个例子，某公司为提升效率开始推行KPI，然后技术部门负责人和自己团队开流程会议，要求以后技术团队接产品部门需求必须走XX流程，需求必须达到XX标准。
这是管理水平不行。