# 科技、业务进化的维度化管理

科技和业务的关系在软件开发的领域里一直是个讨论多多的话题。我们在敏捷研发组织中经常遇到科技业务、业务科技相互之间纠葛。受限于敏捷转型过程的组织范围，两边夹边的情况还是缕有出现的。虽然我无比认可的是想要达成目的最好的方式就是一伙的，不过先天的部门分隔还是会让群体自然处于相互独立、相互推脱和扯皮的状态。

考虑到根据[康威定律](https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B)（设计系统的架构受制于产生这些设计的组织的沟通结构。）的指引，结构性的问题最好采用结构化的方式来改进，我们不难得出结论。想要更好的业务结果，需要沿着业务的交付方向建立利益相同的组织体系。而这与组织目前的结构往往都是有冲突的。

最常用的解决之道，是矩阵制组织结构。在敏捷导入过程是，经常采用的策略之一部落制也是这样一种结构。矩阵组织好不好用，未必。比如近期就有人在说：“[被全球过度炒作的Spotify敏捷部落制，连Spotify公司自己都不用 | IDCF](https://mp.weixin.qq.com/s/nsCuV0X75CQ8B3BuElq40A)”。这当然也是一家之言，我就不怎么认同。俗话说得好：每一个模型都是错误的，每一个模型都是有用的。

矩阵化了试图解决什么问题呢？我们来看一下：

![](https://385430918-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M8iFCzaIpXf8zXqpE6I%2F-MDIIHOgh_W593FcKS_e%2F-MDIJ3fRzDysfdk9AZIl%2FIMG_3718.jpeg?alt=media\&token=99b9e25d-e072-4a34-ace4-6585ef6ffbf1)

所有的维度都是矢量的，水平方向是项目维度，垂直方向是管理维度。传统的方式大致是项目是临时的，人员不确定，需要的时候从职能团队抽取。主要的管理在智能部门。这样有时候就成为了筒仓。为了部门利益，各个团队优化自己的管理，从而忽视了交付。或者强调部门KPI，让团队的管理者缺失了大局意识。

有了两个维度，剩下的其实就是如何平衡。某一个方向太强，就会阻碍另一个方向的进展。不过在某一个时间，对于组织来说总是会有某方面的诉求。我们在回到开始的讨论，如果我们关注在科技和业务两个交付矢量，让我们回顾一下历史，看看不同时期有什么变化：\
1 业务手工很多，IT交付后会对业务的提升巨大。这个阶段在优化IT的效率。我们可以理解为优化科技方向；\
2 业务已经全面IT化，IT交付主要集中在优化和新需求。这个阶段在优化业务的效率。而前期形成的科技方向的优化，可能就会因为筒仓效应影响到这个方向；\
3 科技积累到一定程度，已经不仅对业务交付产生影响，还可能挖掘出新的业务，甚至的业务本身产生革命性影响。这是又会去做一部分科技的优化。

![](https://385430918-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M8iFCzaIpXf8zXqpE6I%2F-MDIIHOgh_W593FcKS_e%2F-MDIJDHt85AJI1z5tD-D%2FIMG_3717.jpeg?alt=media\&token=168f23d3-62d3-4bda-9d06-1a605b574377)

所以即便是我认为所有的开发活动不过是业务运营（BizOps）的一部分，我们还是会在发展的过程中遇到探索和稳定的问题。每一次探索意味着一次优化，为了更好的稳定状态。

![](https://385430918-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M8iFCzaIpXf8zXqpE6I%2F-MDIIHOgh_W593FcKS_e%2F-MDIW668K8TTPqWTVoWz%2FIMG_3719.jpeg?alt=media\&token=12851385-e476-4d84-87c1-24e37befca83)

这个过程就像是在做一个平衡，一会在某一个区域，不会稳定不变。至于如何对策，那就是另一个话题了。当然，还会有其他维度，那也是我们需要考虑的一部分，甚至是重要的策略，那也是另一个话题了。