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

科技和业务的关系在软件开发的领域里一直是个讨论多多的话题。我们在敏捷研发组织中经常遇到科技业务、业务科技相互之间纠葛。受限于敏捷转型过程的组织范围，两边夹边的情况还是缕有出现的。虽然我无比认可的是想要达成目的最好的方式就是一伙的，不过先天的部门分隔还是会让群体自然处于相互独立、相互推脱和扯皮的状态。
考虑到根据康威定律（设计系统的架构受制于产生这些设计的组织的沟通结构。）的指引，结构性的问题最好采用结构化的方式来改进，我们不难得出结论。想要更好的业务结果，需要沿着业务的交付方向建立利益相同的组织体系。而这与组织目前的结构往往都是有冲突的。
最常用的解决之道，是矩阵制组织结构。在敏捷导入过程是，经常采用的策略之一部落制也是这样一种结构。矩阵组织好不好用，未必。比如近期就有人在说：“被全球过度炒作的Spotify敏捷部落制，连Spotify公司自己都不用 | IDCF”。这当然也是一家之言，我就不怎么认同。俗话说得好：每一个模型都是错误的，每一个模型都是有用的。
矩阵化了试图解决什么问题呢？我们来看一下：
所有的维度都是矢量的，水平方向是项目维度，垂直方向是管理维度。传统的方式大致是项目是临时的，人员不确定，需要的时候从职能团队抽取。主要的管理在智能部门。这样有时候就成为了筒仓。为了部门利益，各个团队优化自己的管理，从而忽视了交付。或者强调部门KPI，让团队的管理者缺失了大局意识。
有了两个维度，剩下的其实就是如何平衡。某一个方向太强，就会阻碍另一个方向的进展。不过在某一个时间，对于组织来说总是会有某方面的诉求。我们在回到开始的讨论，如果我们关注在科技和业务两个交付矢量，让我们回顾一下历史，看看不同时期有什么变化：
1 业务手工很多，IT交付后会对业务的提升巨大。这个阶段在优化IT的效率。我们可以理解为优化科技方向；
2 业务已经全面IT化，IT交付主要集中在优化和新需求。这个阶段在优化业务的效率。而前期形成的科技方向的优化，可能就会因为筒仓效应影响到这个方向；
3 科技积累到一定程度，已经不仅对业务交付产生影响，还可能挖掘出新的业务，甚至的业务本身产生革命性影响。这是又会去做一部分科技的优化。
所以即便是我认为所有的开发活动不过是业务运营（BizOps）的一部分，我们还是会在发展的过程中遇到探索和稳定的问题。每一次探索意味着一次优化，为了更好的稳定状态。
这个过程就像是在做一个平衡，一会在某一个区域，不会稳定不变。至于如何对策，那就是另一个话题了。当然，还会有其他维度，那也是我们需要考虑的一部分，甚至是重要的策略，那也是另一个话题了。

最近更新 1yr ago

复制链接