职能部门的组织方式适合数字化团队么？

#后数字化转型

#组织篇

今天的主题是关于团队组织方式的。

    后数字化时代，传统企业数字化部门早已经不止是最开始打江山的5、6个人的小团队。

    团队里的角色会更多样化：产品经理、业务分析师、测试工程师、数据工程师、前端开发、后端开发、运维人员、线上运营推广这些都是常见的角色。对于质量要求较高的团队，甚至测试工程师就会有几十个，还会分为技术测试和功能测试不同角色，如果规模更大，还会有专职的架构师团队，PMO团队，如果还有敏捷角色的话，还有敏捷教练，DevOps等角色，另外，可能需要再加上管理岗和协调岗……

    此外还有公司内部，因地制宜定义出来的岗位title。

    这么多的岗位和角色该怎么管理呢？如何更高效地组织呢？这是每个数字化部门领导都在思考的问题。

    有的岗位人数众多，管理工作繁重；

    有的岗位人数少，但需求又不稳定，不一定够饱和；

    有的岗位需要对接非常多的其他部门，信息非常集中，严重依赖一两个人成天“救火”；

    有的岗位交给了外包团队，有的岗位还是内部、外部和来自不同公司的外包团队混合编制。

   这些都是组织结构上经常遇到的问题。

    我们的第一反应是按岗位职能划分，建立职能部门，因为传统企业一直就是这么做的。

    于是就有了第一批基层领导。

    马上，我们会发现这些需要紧密协作的职能部门之间，扯皮打架、甩锅不断。

    于是我们再建立起第二批中层领导，来管理这些基层领导。

    随着业务或者组织越来越复杂，我们发现依然很吃力的时候，我们再添加一层管理层，来管理这些管理层。

    ……

    管理金字塔越搭越高，管理层离一线工作越来越远，管理成本占研发成本的比重越来越高，组织越来越重，直到一天我们决定推倒一切重组，但是换个方式搭金字塔是不是就没问题呢？

    有没有其他可以尝试的选项呢？

    老规矩，讨论解决方案之前。我们可以先聊一下，传统企业数字化部门的组织结构，都有哪些特点。

特点1 地盘不明确。

    在传统企业里，其他各部门已经成功运转了好久，每个部门都有自己稳定的“地盘”，制造，销售、市场、财务、法务、人事等等。一个企业运行了这么久，这些部门已经有了相对明确的边界、分工，在企业中肯定有自己明确的价值，否则早就不会存在了。

    而数字化部门像一个班级里的新生，最好是与其他人合作，也就是我们常说的内部赋能。

    但是，是数字化产品为传统产品赋能，还是传统业务为数字化产品赋能呢？坦率来讲，不同人心中肯定会有不同的答案。

    紧接着，问题来了，临界在业务领域和数字化领域之间的灰色地带，属于谁的地盘或者责任呢？

    这些新的领域，数字化与传统业务结合形成的新业务，根据项目而异，根据团队而异，根据各领导的性格而异。

    不同部门各自的职责边界，绝对不是一两句话就能划分得清楚的。即使分清楚了，也只能是暂时的，尤其在大企业中，更难做到一刀切。

特点2， 很容易变得臃肿。

    一个专业软件公司，开发一套软件，给成千上万、甚至数千万上亿的用户提供服务，是一个非常复杂的过程，需要非常严谨的工作流程，涉及到许多方面的专业知识。不是简单的做一个页面，做几个按钮，几个表单那么简单。

    要考虑的内容太多啦，产品是不是伪需求？界面交互是否人性化？系统架构是否合理，是不是小小的改动，就牵一发动全身？业务数据是否有归口统一治理？是不是经常数据显示不正确，各种数据对不上？有没有敏感数据泄露？说是测试了，是不是上线一堆bug？产品性能如何，是不是按一个按钮等好久，几个人用就很慢？系统是不是不知道为啥就崩了？最后产品上线了，有没有人用？产品到底是给人添麻烦了，还是带来便利了？

    这么多问题想想都头大。这都是专业活，需要专业软件角色的专业技能。

    在传统行业的数字化团队里，不会因为主营业务不是软件产品就降低要求，相反，要求会更高。当传统企业的数字化部门不得不支持一大堆老旧系统平台互相关联，一大堆新老数据，互相依赖又互相矛盾的时候。数字化团队的产品和组织常常会比一个正常的软件公司更臃肿，更复杂，需要考虑的因素，牵扯到的内部客户和外部客户只会更多。

    为了应对复杂的业务背景，怎么办？加人呗！一个不小心，组织就会变得很臃肿庞大。不加人也可以，十口锅，八个锅盖，哪里需要哪里盖。这种情况下，团队覆盖的业务又臃肿了，好像方方面面都涉及。

    最后，这么多人，这么多业务，谁在干什么都很难说得清楚，职责边界更难界定了。

特点3， 变数大，不稳定

    首先是业务内容的变数就会很大，之前几期也说了，数字化部门想做什么往往并不由自己全权决定。公司层面的战略，客户的需要，政策的引导，以及公司经济财务状况都直接影响数字化部门的业务活动，在这些事情都考虑完了之后，还会考虑数字化部门自己内部想做的创新尝试，可能成功也可能失败。所有这些因素都是不定性的，数字化部门只能接受这一点。

    其次，项目周期自身也会带来变化，一个软件项目，最开始可能只是几个人去验证方向，建设期需要大量投入人力，产品成功上线，进入维护期，又不需要那么多人了。而且经常需求要的很急，终止的也很快。项目或者产品的正常生命周期就是这样，那么这些人从哪里来，到哪里去呢？

    人员的变动也是常态，一方面是离职，以我的观察，传统企业数字化团队的离职率一般是高于稳定的产品开发团队的。另一方面，数字化团队的成员常常会被当成“资源”，资源是随着需求走的，“我是一块砖，哪里需要哪里搬。” 很难做到让小伙伴们专注在一个项目或产品上，甚至短期专注都很难做到。

    不同事项之间优先级和紧迫性会不停的变化，管理层会承担很大的压力，只能协调这些“资源”，在不同的事项上来回切换。

    “一会做一下这个项目，一会做一下那个产品，感觉自己是个打杂的。”这句话我听过无数次了。

    无论是人员在项目之间来回切换还是人员离职，组织的稳定性肯定是会低的，带来一系列坏处不用我多说。

    上面说了传统行业数字化部门的组织结构的三个特点，

    1.地盘不明确

    2.很容易变得臃肿

    3.变数很大，不稳定

    按老规矩，肯定还有其他的特点，今天只列出来三个。

    这些特点与其他部门会有很大反差，以销售或者商务部门为例，不可能今天让这个销售跟这个客户，明天让他对接那个客户，大家都知道蜻蜓点水出不了业绩。产品或者市场需要做的边界也很清晰，相对来说都会比较专注。

    所以数字化部门必须琢磨出自己的一套管理体系和组织方法，并不能照搬其他部门的方式，其中职能部门的建立，就是一个例子。

    明确一下，我们说的职能部门，指的是：测试部门，开发部门，设计部门，等等各种根据岗位角色划分的部门。

    合理的职能部门需要有明确的职责边界，负责的工作与资源能够合理匹配，人员和业务相对稳定、专注。

总之一句话，“打杂”从来不能是一个职能部门的主营业务。

    当这个职能部门招聘的JD，也就是岗位说明，很难用几句话说清楚，或者JD和具体工作内容大相径庭的时候，就应该知道职能部门已经不好用了。

推荐实践：

    如果不专注和不稳定已经成为困扰团队的一个重要因素的话，有几个可以尝试的实践：

1. 围绕业务建立全功能小队，提升专注度。

围绕不同业务领域建立多个小而轻的全功能团队，尽可能让每个团队在一段时间内专注于一个业务领域。

专注的时间越长，业务领域越纯粹，越可以增加团队的专注度，更关注产品，关注业务，这个条件下，团队把上下游分工理顺，积累业务知识，提升产品质量，都会是很有利的。

2. 建立“救火小队”，限制突发需求和杂事的影响范围。

在实践中，难免会有一些突发的杂事、必须要应付的，优先级又高的短期项目，尤其是一两个星期或者几天内就要满足的需求。像这种突发性强的杂事，难啃的骨头，可以统一归口到一个特定的小组里面来。把不稳定性和突发事情限制在这个“救火小组”里，而不去搅乱整个组织。

得让大家知道，这个小组为了大家的专注，而牺牲了自己的稳定。同时这个救火小组里的成员，需要他们的性格匹配这个岗位，喜欢接受挑战，希望尝试不同的内容，最后公司内部升迁或者加薪要注重考虑这些救火小组里的消防员们，也应当重点关注他们的情绪。

如果实在没有合适的人选组成这个小组，那么就采取不同小组轮值当“救火小组”的方式，起码让大家有一个心理预期，在这段时间内，我们会去处理一些杂事，其他的事情我们会放一放，突发的要求会很正常，但是下个时间段，我们会回归到专注上来。

同样是做事，建立心理预期之后，大家的心态会好很多。

3. 建立社群

想必大家也想到了，围绕着不同的业务线建立全功能团队也会有一些问题。比方说，重复造轮子的问题，业务孤岛的问题等等……

这些可以通过社群的方式来优化或者解决，我们将来在另外一期专门来聊一聊社群的好处和玩法，有些时候能够代替职能部门起到很好的收效。

    总而言之，数字化部门的组织架构有自己的独特性，并不能照搬其他部门的管理方式。

    并且，数字化部门的组织架构是一门综合学科，并不是某个敏捷实践或者采用一个JIRA工具就万事大吉，需要一系列的实践和组织方式来不断优化。

    从根本上来说，组织架构的根本出发点，是应该去创造足够的条件，让团队能够自己去解决他们所面对的问题。

    除了人力资源，预算这些刚性的需求之外，更多的专注，更多的稳定性，应该是组织上能够给到团队最大的帮助了。

    今天聊了数字化部门里面的组织结构，并不是推销什么万能解药，而是思考，组织如何能够更好帮助到团队。

    还有什么是组织应该给到团队的帮助呢？欢迎大家留言讨论。