19、如何兼顾团队分工的稳定性和灵活性？

前面两篇文章，我们探讨了如何提升团队中每个个体的战斗力。那接下来的问题是，每个个体的战斗力都很强了，整个团队的战斗力就会很强大吗？凡是学过中学力学的同学都能脱口而出：“并不一定！”为什么呢？因为只有在大家努力方向一致的时候，团队的合力才会最大。

这个道理用马车模型来打比方会更加易懂。当拉车的各匹马用力方向不一致的时候，马车甚至都会一动不动，所以需要用一个“联动结构”来保证每匹马用力的方向是一致的。关于一群马的“联动结构”的设计，对应到团队管理中，就是如何做好人员安排和工作划分，以实现最高效的合作。我们把这个要素称为“分工”。

当团队个体间的分工和协作都很良好的时候，就可以将个体战斗力凝聚成强大的合力了。

关于如何提升员工协作水平和团队凝聚力的问题，我们会在下一篇文章中专门探讨。今天，我们就先来聊聊团队分工这个话题。

说起分工似乎大家都懂，不过，你是否真的清楚分工的目的呢？越是司空见惯、习以为常的东西，就越容易被忽略，所以很少有管理者深入地思考过这个问题，很多人第一反应的答案是为了追求更高的效率。

我想说的是，如果你要追求高效率的话，就应该减少分工，合作的人越少越好。我们时不时就会听说，某个团队裁掉一批人后业绩不降反增，为什么呢？抛开激励因素之外，还有一个原因是，如果协作不好的话，分工只会让效率变低。

那么，究竟为什么要分工？分工能带来什么收益呢？在我看起来，主要有如下三点：

第一，为了实现规模化，通俗点说，就是为了干大事。因为干大事需要很多人，当有很多人一起做事的时候，就得有一种方式来容纳这么多的人，这个容纳方式就是分工。所以，分工不是为了高效，而是为了能容纳更多的人来一起干更大、更复杂的事情，做简单的小事情，是不需要分工的。因此，要把整个社会的人都容纳进来，就需要分工为 360 行、3600 行甚至 36000 行。这样，整个社会才能做很宏伟的事业。

第二，为了实现协作。到底是因为分工了才需要协作，还是因为需要协作才必须分工呢？我认为是先有协作的需求，才有分工。换句话说，分工是手段，协作是目的，分工和协作是不能割裂开的。所以，如果你有一个分工方案对协作不利，就本末倒置了。

你可能会很惊讶：“还有分工会妨碍协作的吗？”有，而且还很多！因为很多管理者分工并不是为了协作，而是想当然地认为该分工，或者分工是为了让大家都有活干，或者是为了平衡团队成员利益关系，等等。我倒是不反对这些做法，但前提需要你很清楚分工是为了更好地协作，如果伤害了协作关系，那你就需要掂量掂量了。

第三，为了实现专精。时代发展需要全才，也需要专精人才，分工为这类人才的成长提供了很好的条件。他们可以把时间、精力和长期的练习都聚焦到某个点上，从而更容易实现对于某项技能或某个领域的精细掌控。而且，由于精细化分工只需要每个员工关心单一工作内容，所以管理者更容易从整体上用人之长、避人之短，让专业的人更专业。

所以，我们是出于规模化、协作和专精的目的来进行分工的，在做分工的时候不能忘记了这个初衷。

但是并不意味着分工就只能带来这几个效果，它其实还会引发很多延伸效果的。协作好的分工可以带来除“规模化、协作和专精”以外的其他好的结果，比如人力资源配置优化、人才获取成本降低、员工工作积极性提升、执行效率变高等。而协作不好的分工也会带来很多负面，比如视野狭窄、能力单一、恶性竞争、推诿扯皮，等等。

因此，并不能简单地认为分工一定是件好事。分工是不是好事取决于协作水平，协作水平又受限于管理者的管理水平。所以，管理者的工作意义重大。

上面，我们探讨了分工的目的。那么常见的分工形式有哪些呢？

从一个业务所涉及的各个角色的分工情况来看，互联网领域最常见的组织结构有两类，一类是矩阵式的，一类是 BU（BUSINESS UNIT）式的。

所谓矩阵式结构，可以这样简单地理解：员工按照角色被划分到不同的团队，每个团队都有自己的负责人。要做项目的时候，会有专门的项目经理来向各个角色的 leader 协调人力，然后把申请到的各个角色的人组织在一起去完成这个特定项目。一旦项目完成之后，人员将回归各自团队去迎接新的项目。

这样一来，人力资源是按照角色“横向”来组织的，而项目执行是按照任务“纵向”来推动的，就形成了一个纵横交错的矩阵式结构，所以叫矩阵式组织结构。这类组织架构的好处是各个角色团队的专业度都会很高，而且角色归属感比较强，资源调配灵活；但不足之处是项目执行起来较为低效，因为每次都要重新申请人力，而且每次的项目团队都需要重新磨合。

IBM、微软的很多部门都是类似的组织方式，他们也都有一个专门做项目管理的职位叫“项目经理”，和互联网公司既带人又做事的“项目经理”不同的是，他们主要聚焦于项目交付，而不对人的发展负责。

所谓 BU 式结构，直译过来就是“业务单元”式，也叫事业部制，是指做某项业务所有的人员和资源都统一调配，无论这个事业部是大是小，都角色齐全。这样做的好处是团队长期合作磨合充分，协作效率高，执行速度快；不足是各种角色自己都要有，资源冗余和浪费比较多。另外，由于某些角色不在业务主干上，团队规模比较小，能力要求也不高，所以其角色专业度很难提升。

上面这两种组织结构各有利弊，在很多互联网公司都在并行使用，甚至嵌套使用，并不冲突。不过，你还是要根据自己的业务特点、公司规模、发展阶段去选择合适的组织形式。

你可能会说，“我作为一个一线经理，团队规模小，角色单一，涉及不到上面说的组织结构的问题，对我来说团队分工主要是内部人员的工作安排问题，有什么建议吗？”

那接下来，我们就把视角从组织外拉近到组织内来看。

其实，对于一个具体的团队来说呢，工作安排分工是没有一定之规的，因为这和你的业务情况、人员状态、团队目标都紧密相关，而且很多事为了应急还会临时调整，所以怎么分派工作，还是以你的实际情况为准。

不过我可以分享几个常见的误区、问题和建议原则。

首先，最常见的一个分工误区，就是分工模糊。而且有些管理者为了能够让大家互相补位、主动承担、增强互助，还会刻意去模糊边界。朋友圈里也时不时就会有一篇文章倡导“去边界化”或者“边界模糊化”。我非常理解这种做法的初衷和期待。

但是我想说的是，任何不以分工清晰为前提的边界模糊化，结果都会事与愿违。为什么呢？因为只有明确的分工，才能让员工清楚和认同自己的本职职责，产生归属感，并愿意主动付出多做一些。所谓“多做一些”是什么含义呢？就是在清楚自己该做什么的基础之上，又多做了一些，这是所谓主动积极的体现。

如果没有职责边界，却又总是催促员工要积极主动，员工可能就会质疑：到底做了什么才叫积极主动呢？你可能就无法回答。作为 leader，此时你如果只是随便列举几个做法，是不能令人信服的。因此，我不是反对去边界化，我只是强调，在“边界模糊”之前，要加上“分工明确”这四个字。

接下来，我们来聊聊分工稳定性的问题。分工需要尽可能稳定，因为只有稳定的分工才能体现出分工的价值，比如对某项工作的专精、员工的归属感等，所以，分工能稳定的话，就最好稳定。

但是也有两个因素会让分工稳定不下来。一个因素是来自外部的业务调整，团队组织结构不得已随之而变，管理者就需要对团队成员进行工作再分工。此时就要遵循“尽可能稳定”的原则，因为变量越多，不确定性就越大。

除了这种被动调整之外，还有一个因素是作为管理者的你想主动调整分工。你调整的原因可能很多，但是其中需要有一个原因是你意识到了长期稳定的分工带来的局限和怠惰。因为分工能带来专精，同时也带来了割裂的视野，所以很多管理者会通过“轮岗”的方式来提升员工的能力和全局观。我认为这种主动求变的意识非常好，因为主动求变就意味着这种变化是在你的掌控之内。

最后，我们再来聊聊虚拟组织。虚拟组织又叫虚拟团队，是为了某一个特定的目的和工作内容把大家组织到一起的。有的时候是为了一项临时性工作，工作做完之后就解散了，叫临时性虚拟组织；而有的时候是为了一项长期的工作，会一直持续很久，就会变成一个长期存在的虚拟团队。

为什么要组建虚拟团队？虚拟团队有哪些好处呢？我觉得至少有如下三点：

1. 高效执行。虚拟团队组建的初衷一般都是为了专人专事，聚焦目标，高效执行。所以虚拟团队比一般的联合项目组，在执行上要更高效。
2. 资源配置。对于很多工作来说，专门组建一个团队不值得，但是又时不时需要立项新项目，虚拟团队就为这类需求提供了解决方案。大家可以因为做事走到一起，但不是一个独立预算的团队。
3. 保持归属感。为了做一些紧急项目，管理者往往会随意抽调员工，这样的事情出现的多了，员工的归属感会减弱，边界感会消失。慢慢地员工就认为自己是在“打杂”了，因为他找不到自己的位置在哪里了。而虚拟团队本身就带有“借调”的味道，并不影响员工认定自己“本应”的位置在哪里，所以，不会影响员工的归属感。

你可能会说，“既然虚拟组织这么好，那我就多用这种方式吧！”好，接下来我就说说，使用虚拟团队这种方式需要注意的几个原则：

1. 专人专事，不宜太多。虚拟组织往往是专人专事的，代表着足够高的重视和足够高的要求，所以对应也要有足够多的资源投入。但你不可能把所有的事情都列为重要的事情，也不可能所有的事情都专人专事。所以，“好钢用在刀刃上”，虚拟团队不宜太多。
2. 认同员工价值。虚拟团队除了专人专事，还往往出现在跨团队的合作中。既然你同意你的员工加入这个虚拟组织，无论做出来的业绩是不是你最看重的，都要认可他的价值。常见的一个问题是，管理者常常以员工的产出对自己团队价值不大为理由压低员工绩效，这是典型的让员工背负管理者的决策后果，很不可取。
3. 目标明确，职责冠名。每个虚拟组织建立起来都是为了特定的目标，所以你组建每个虚拟团队的目标要非常清晰，并且和团队每个人都要传达到位。为了进一步提升责任感和归属感，很多 leader 会把职责冠在团队名字上，我认为非常好。比如“100 天战队”“用户体验优化小分队”“架构迁移大队”等，很是生动形象。

当然，还有一些学习型虚拟组织，比如技术交流小组、项目负责人小组等，这些虚拟组织出于学习，不涉及工作分工，所以，不在我们今天讨论的范围内。

通过今天的文章，对于分工，你是否有了更深的理解？对于如何平衡团队分工的稳定性及灵活性，你是否有了更多的思路呢？欢迎你给我留言，我们继续交流。