管理神话之二：只有专家才能做这事

原文作者：Johanna Rothman

你需要做一件特定的事情，比如设计一个新的数据库或者一个特别的用户界面，或者你需要一位发布工程师，或者需要一位UI设计师，或者你想测试系统的某个部分，但是，平常做那个工作的人偏偏不在——在你的项目里，你碰到过多少次这种情况？你的项目受到什么影响？是不是只能等着那位专家回来？

在项目等待专家的情况出现时，很多管理者感觉还是可以抡上三板斧的。他们可以让项目等一等，也可以请专家多任务并行，或者他们拽来另一位专家顶上。毕竟，在任何项目里，你并不是时时刻刻都需要专家。三板斧还是挺管用的，不是吗？任何数据库管理员、高级测试人员或发布工程师难道不都一样嘛（随到随用），即使他们对你的项目的过去和未来一无所知？

不对，完全不是那么回事！在项目需要的人没有着落之前启动项目是不妥的。让一个人多任务并行也是不妥的。而且，不了解你的项目的人在你的项目里其实也不能算专家。

你还可以有别的做法。那就是，通过多种方式来降低对专家的需要。你可以让专家与其他人配对工作；你也可以在你的项目里完全不用专家；或者进行项目组合管理，使得真正需要专门技能的项目错开；你还可以雇用更多的专家。

别让专家独自工作

有时候，项目需要的专门技能是可以让团队里的其他人学会的。举个例子，也许只有一个人精通构建系统，但一个项目里的所有人都需要知道怎么使用那个构建系统。在那种情况下，我会让精通构建系统的那个人与团队里的每个人逐一配对工作，直到每个团队成员都像那个专家一样熟悉构建系统。

千万别让专家独自工作！通过这种方式，你可以让专业技能在团队里传播。根据技能的具体情况，你可能首先需要召集一个研讨会，以使所有人对那个工具或技术都有一个基本一致的了解。有时候，确实有必要让发布工程师开一个讲习班，花几个小时讲解一下构建系统的内部工作原理，然后让他与每个人一一配对，确保所有人都明白怎么使用那个系统。在数据库管理方面，很多时候你也可以采用相同的模式。

如果专业技能主要是工具使用方面的，或者是与其他团队成员现有技能类似的一种技能，上述这种方法是很有效的。但如果你处在一个需要关键领域的专业知识才能解决问题的场合下（这时候人们必须深入代码库的“心脏”），你就要采取其他方法了，比如内部抛弃。

抛弃不可替代的专家

有些人看起来是不可替代的。如果他们正在做其他项目，而你想要动一下“他们的代码”，你的项目必须等他们有空。

那是很荒谬的，千万别落到那种境地！抛弃他们吧！或者，如果他们正在参与你的项目，让他们做别的项目去吧。不管你采取什么方法，你得马上把他们从你的项目里请走。如果那个专家在做其他项目，但只要他还留在公司，你仍然有机会求助于他。将来有一天，那个专家会退休，然后在加勒比海扬帆起航，在下午4点就喝起了美味的朗姆酒，你将再也找不到他。你想让你的团队成员什么时候锻炼他们的专业技能呢？我想让团队在专家还在的时候就开始。

团队对专家有一种不健康的心理依赖，而专家对团队是一种互惠关系。我不是心理医生，我也不想扮演电视里的那种心理医生，但在项目管理领域，这是很糟糕的！为了专家的自尊，整个团队都在抚慰他。这还阻碍了团队里的其他成员了解自己的产品。

如果你在一个大公司里工作，作为管理者，你可以安排把专家转入另一个项目。如果是在一个小公司，你可以让专家去做一个特殊项目。确保那个特殊项目有足够多的成果要交付，这样的话，专家就会很忙，让他无暇顾及之前的老项目。

团队将学会如何一起进步。一旦你将专家排除在外，团队有机会成为一支真正的团队，因为现在团队成员有了一个共同的目标。

一旦专家被排除在外，团队成员就要团结起来，快速发现他们所不知道的东西。他们会把各自知道的东西拿出来分享。然而，你必须允许专家每周花一点时间来支持团队。起初可以是一个小时，然后，只有当团队走投无路的时候才能去找专家。为了搞明白产品的工作原理，你要鼓励团队动手去试验，而不总是问问题。

把需要专家的项目错开

也许你的专家没有自尊问题。也许你确实有几个安全方面的专家，你需要他们完全专注在一个项目上。也许你期望A项目现在能完成，然后你就可以启动B项目。但是，A项目还没做完呢。好吧，这个问题容易解决。如果A项目比B项目更有价值，别启动B项目。如果B项目比A项目更有价值，把A停了去做B。是的，就这么简单！

不过，你会说，我们还没把A项目发布出去呢。好吧，如果你在A项目上使用了敏捷开发方法，也许你已经攒够了有价值的东西去发布。但也未必。那就太糟糕了！本质上来说，项目组合管理是一种零和游戏。因此，你需要为整个组织选择最佳方案。你确实想让组织取得成功，对吧？

项目组合管理其实就是在组织级别上进行艰难的讨论，避免同时做两个项目，要不然会把两个项目都拖累了。

A项目和B项目，哪个更有价值呢？哪个项目会推动组织前进？你怎样能以最小的代价做一次有价值的发布？这就是你需要问的一些问题。

如果你还没有在A项目上采用敏捷方法，现在开始也不算太迟。把快要做完的功能赶紧做完，然后评定剩下的各个功能的重要程度。我们希望，你开始以功能的重要程度依次开展工作。

雇用更多的专家

如果你真的想要同步推进A项目和B项目，你就必须雇用更多的专家了。即使是这样，招到人并促使他们产生效能还是要费些时间的。不过，雇用更多的人确实有效。

了解根本原因

我们的组织里之所以有这么多并行任务，其中一个原因就是我们的很多专家的知识面都很窄。他们的专业技能越局限，项目就越少能用到他们。但当你需要那种人的时候，你真的是非他不可。

关于专家以及只有专家才能做特定的工作的传说有很多。确实有些工作只有专家才能做。真正的问题是：这类工作有多少？我不指望开发者变成测试人员，反之亦然。我也不期望UI设计师变成安全专家。但作为一个管理者，我希望项目里的每个人都能对项目充分了解，乃至对整个项目都很精通。最重要的是，我期望专家与其他人一起工作，以促成知识共享。

在产品开发中能够使用比较通用的方法的人越多，你的项目就越具有灵活性。于是，当我说，“工作在团队中流淌而过，”你赞许着对我说，“当然。要不然怎么行？”

你不必排除专家。你要做的是，降低对他们的需要，并且提高组织里的每个人的技术能力。