系统制约

W.Edwards Deming 曾指出 [附录 9]，It is the system, not the people working in the system that determines a systems performance，系统的性能主要由系统本身决定的，而不是系统中工作的个人。

Deming 认为，在给定的上下文 (系统组织) 中，个人一般会自激励尽最大努力做到最好。但如果系统本身设置是有问题，则会极大制约系统内部个人的发挥。所以，针对上述困局，我们不能简单责备系统中的个人，而是应该跳出来从系统组织纬度去思考和调整，才可能找到根本性的解决之道。

所以说，如果组织架构不合理，就无法建立一个高效的交付团队。一般在组织架构调整时，要提前酝酿和关注每一个核心成员的准备度，让他们理解与开始拥抱变化，两边联动才能产生效果。

强化反馈环

每一次架构调整就像一台手术，需要谨慎做体检与评估，基于不同的数据抽丝剥茧，多个方面分析了解问题的根源，最后判断与决策是否要做怎样做。在这个过程中，能将团队核心同事融入进来，以开放的心态表达自己的理解与建议，并在后续的预期上同步一致, 是达到成功彼岸的首要条件。因此在调整组织架构调整前的很长的一段时间，我在不同的组会上，反复的灌输了以下几个预期：

1. 市场越来越有挑战性，因此业务在做组织架构调整，来支持新一年的战略目标达成。

2. 给业务赋能是科技的使命，整个银行都需要配合业务的新战略布局

3. 研发中心需要的是金融业务 IT 人才而不是某个系统的 IT

这个过程改进通过加强反馈环来达成，每次一对一沟通的时候我都会开诚布公的说我们现在的挑战，了解每一个人对于架构调整的想法，同时甄选第一个调整的试点小组成员。逐渐的，在日常的沟通中，每个人已经有预期后续会有调整，且已经有部分同事表达了他们未来的职业方向，希望可以在架构调整中得以契合上。

架构调整思考

当前我们研发中心是端到端的跨职能产品研发项目经理，如下图，如果是自研管理形式，这种组织模式是非常有效率的，能够在团队内形成反馈闭环，交互沟通开销小。但是基于外包管理就不太使用，整个端到端行内只有一个成员，同时在完整业务架构上，这里所谓的端到端仅仅是整条业务架构链条上的其中一个系统，根据康威法则，组织架构和系统架构不匹配，就无法避免单块交付模式必然存在的跨团队协作沟通（例如多团队协调集成回归测试）和交付件传递 (hand-offs) 问题，整体效率仍然受限，无法达成真正的敏捷。并且有着巨大的 Key man risk。

相比之下，在整个业务架构上系统群的基础上，按照划分职能的方式来拓宽 SIC 对于业务的全流程理解，同时可以让每个人的工作量能有个自动调节机制，是初步的调整的想法。其中的弊端可能会比原来增加整个流程上各种跨职能小组的会议与协调的开销，也是需要平衡的。

下一篇我会继续介绍调整后的结果和遇到的问题。