重新思考软件行业组织结构：从成本到业务响应能力转变

教练介绍

前言

在当今数字化时代，软件行业的快速发展使得组织结构的适应性变得至关重要。随着敏捷开发方法的流行，越来越多的公司开始重新思考他们的组织结构，以便更好地适应市场需求。本文邓志国分享了他在翻译《敏捷组织设计》一书时的经验，探讨了敏捷组织设计中的三个层面问题：个人实践、团队协作和组织适应性。

文章还深入分析了软件行业的组织结构，强调了传统的组织结构不太适合软件开发公司。最后，文章提供了一些思考，探讨了如何从成本到业务响应能力的转变，以实现快速响应市场需求。

软件行业组织结构多样性与敏捷组织适应性

我很荣幸能与大家分享我的咨询经验。去年我有机会翻译了一本书，名为《敏捷组织设计》。通过这本书，我认识到在敏捷组织中存在着三个层面的问题。

首先是个人实践层面，包括诸如TDD重构、极限编程等技术实践。其次是团队层面，包括持续集成、用户故事和迭代等团队协作。这些都是团队层面的问题，另外，更大一个层面的问题是——组织层面，即我们遇到的难题在组织层面上，我们的组织是否适合敏捷。

在软件行业中，我们的组织结构是如何形成的呢？事实上，由于软件行业是一个相对新兴的行业，其成熟度并不高，很多组织结构是直接从生产企业中借鉴而来，直接照搬了一些，比如我们的开发部门与生产部门对应，我们的QA部门与质检部门对应。另外，一些企业还设有架构组，其实对应的是原来的设计部门。

这些组织结构是为生产型企业设计的，而软件行业与生产型企业最大的不同之处在于，软件开发不是一个生产过程，它本身就是一个设计过程。我们生产的是代码的设计蓝图，而不是最终产品，软件的生产是由计算机自动完成，当我们把软件部署到环境里时，软件把写好的编码自动编译出来，自动运行起来，最终用户在使用软件时生产就完成了。软件的生产过程几乎是零成本的，最重要的是我们的工作在于设计这一部分。因此，传统的生产组织结构不太适合我们的软件开发公司。

业务响应能力为导向重新思考软件行业组织形式

在软件行业中，我们追求的是市场响应能力，而不是像生产企业一样追求低成本。市场响应能力决定了我们的生存之道。软件企业的目标是快速响应市场需求，而成本只是我们必须降低的一个约束条件。如果我们以追求成本为目标，最终结果肯定是无法盈利。

我也注意到了其他团队的组织情况，通常我们的团队可以分为三种类型：项目型、产品型和能力型。从成本角度来看，项目型团队的成本最低，公司可以采用散装的方式组建项目团队，有项目时组建团队，没有项目时解散，这样可以最大限度地利用人员，人员利用率很高，所有人都在忙碌。然而，这种团队会导致响应速度下降，因为每次做事都需要重新组建团队，需要时间来磨合和沟通。

如果我们的目标是业务响应能力，我们应该更倾向于组建能力团队。比如，在软件研发中，我们可以组建一个拥有各种技能的团队，让他们长时间地一起工作。即使某些成员暂时没有任务，我们也不应该将他们拆散，因为这会降低团队的能力。就像之前分享的小伙伴所展示的，团队输出会呈现波浪形，而非可持续的，一旦改变，输出就会导致下降。

在产品的生命周期较长的情况下，产品团队近似于能力团队。但是，能力团队的成本最高，如果没有任务，这些人员也必须留在团队中，不能做其他事情这可能会让一些管理人员觉得不舒服，觉得员工工作”不饱和“。在这种心态影响下，会逐渐去追求人员的”复用“，进而像项目制形式蜕变。

如果我们基于成本考虑，通常会采用传统的组织形式，例如我们的组织会被设计成筒仓式的组织结构，将产品、研发、测试和运维等部门分开管理。我们在交付的过程中，任务就会存在从一个部门到另一个部门的交接，价值流的交付在跨部门之间发生，交接成本就会比在一个团队内急剧上升。而在软件开发中，敏捷开发的目标是快速反馈，但是在跨部门的交互中，反馈周期会很长，可能需要几周甚至几个月。这样一来，最终交付会变成瀑布式的。

为了实现快速响应市场需求，我们需要面向交付，成立跨职能团队，一个团队具备面向交付的技能，把这些人放在一起，这样的团队对业务的响应才能达到最大化。

除此之外，还存在一些组织层面上的约束，比如预算限制、外包服务的采购、沟通汇报方式、办公室座位的布局（如外包人员隔离分开座位、格子间的布局）都为成为一些组织敏捷的障碍。

为了达到业务敏捷，不仅仅是需要开发团队进行改进。而是从组织结构就要开始进行重构，从组织层面就要适应敏捷。更多关于敏捷组织设计的内容，请参考《敏捷组织设计》这本书。