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

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

考虑到根据康威定律(设计系统的架构受制于产生这些设计的组织的沟通结构。)的指引,结构性的问题最好采用结构化的方式来改进,我们不难得出结论。想要更好的业务结果,需要沿着业务的交付方向建立利益相同的组织体系。而这与组织目前的结构往往都是有冲突的。

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

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

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

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

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

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

最后更新于