你须要做一件特定的事情。比方设计一个新的数据库或者一个特别的用户界面。或者你须要一位公布project师，或者须要一位UI设计师，或者你想測试系统的某个部分，可是，寻常做那个工作的人偏偏不在——在你的项目里，你碰到过多少次这样的情况？你的项目受到什么影响？是不是仅仅能等着那位专家回来？
在项目等待专家的情况出现时，非常多管理者感觉还是能够抡上三板斧的。他们能够让项目等一等，也能够请专家多任务并行。或者他们拽来还有一位专家顶上。
毕竟，在不论什么项目里，你并非时时刻刻都须要专家。三板斧还是挺管用的，不是吗？不论什么数据库管理员、高级測试人员或公布project师难道不都一样嘛（随到随用），即使他们对你的项目的过去和未来一无所知？
不正确。全然不是那么回事！在项目须要的人没有着落之前启动项目是不妥的。
让一个人多任务并行也是不妥的。并且，不了解你的项目的人在你的项目里事实上也不能算专家。
你还能够有别的做法。那就是，通过多种方式来减少对专家的须要。你能够让专家与其它人配对工作；你也能够在你的项目里全然不用专家；或者进行项目组合管理，使得真正须要专门技能的项目错开；你还能够雇用很多其它的专家。
别让专家独自工作
有时候，项目须要的专门技能是能够让团队里的其它人学会的。举个样例，或许仅仅有一个人精通构建系统。但一个项目里的全部人都须要知道怎么使用那个构建系统。在那种情况下。我会让精通构建系统的那个人与团队里的每一个人逐一配对工作，直到每一个团队成员都像那个专家一样熟悉构建系统。
千万别让专家独自工作！通过这样的方式，你能够让专业技能在团队里传播。
依据技能的详细情况，你可能首先须要召集一个研讨会。以使全部人对那个工具或技术都有一个基本一致的了解。有时候。确实有必要让公布project师开一个讲习班，花几个小时解说一下构建系统的内部工作原理，然后让他与每一个人一一配对，确保全部人都明确怎么使用那个系统。在数据库管理方面，非常多时候你也能够採用同样的模式。
假设专业技能主要是工具使用方面的。或者是与其它团队成员现有技能相似的一种技能。上述这样的方法是非常有效的。但假设你处在一个须要关键领域的专业知识才干解决这个问题的场合下（这时候人们必须深入代码库的“心脏”），你就要採取其它方法了。比方内部抛弃。
抛弃不可替代的专家
有些人看起来是不可替代的。
假设他们正在做其它项目，而你想要动一下“他们的代码”，你的项目必须等他们有空。
那是非常荒谬的，千万别落到那种境界！抛弃他们吧！
或者，假设他们正在參与你的项目。让他们做别的项目去吧。无论你採取什么方法，你得立即把他们从你的项目里请走。
假设那个专家在做其它项目，但仅仅要他还留在公司。你仍然有机会求助于他。将来有一天，那个专家会退休。然后在加勒比海扬帆起航，在下午4点就喝起了美味的朗姆酒。你将再也找不到他。
你想让你的团队成员什么时候锻炼他们的专业技能呢？我想让团队在专家还在的时候就開始。
团队对专家有一种不健康的心理依赖，而专家对团队是一种互惠关系。我不是心理医生，我也不想扮演电视里的那种心理医生，但在项目管理领域，这是非常糟糕的！
为了专家的自尊，整个团队都在抚慰他。
这还阻碍了团队里的其它成员了解自己的产品。
假设你在一个大公司里工作，作为管理者，你能够安排把专家转入还有一个项目。假设是在一个小公司，你能够让专家去做一个特殊项目。
确保那个特殊项目有足够多的成果要交付，这样的话，专家就会非常忙。让他无暇顾及之前的老项目。
团队将学会如何一起进步。一旦你将专家排除在外，团队有机会成为一支真正的团队。由于如今团队成员有了一个共同的目标。
一旦专家被排除在外。团队成员就要团结起来，高速发现他们所不知道的东西。他们会把各自知道的东西拿出来分享。然而，你必须同意专家每周花一点时间来支持团队。起初能够是一个小时，然后，仅仅有当团队走投无路的时候才干去找专家。为了搞明确产品的工作原理，你要鼓舞团队动手去试验，而不总是问问题。
把须要专家的项目错开
或许你的专家没有自尊问题。或许你确实有几个安全方面的专家。你须要他们全然专注在一个项目上。或许你期望A项目如今能完毕，然后你就能够启动B项目。可是，A项目还没做完呢。
好吧，这个问题easy解决。假设A项目比B项目更有价值。别启动B项目。
假设B项目比A项目更有价值。把A停了去做B。
是的，就这么简单。
只是，你会说，我们还没把A项目公布出去呢。
好吧。假设你在A项目上使用了敏捷开发方法，或许你已经攒够了有价值的东西去公布。但也未必。那就太糟糕了！本质上来说，项目组合管理是一种零和游戏。因此，你须要为整个组织选择最佳方案。
你确实想让组织取得成功，对吧？
项目组合管理事实上就是在组织级别上进行艰难的讨论，避免同一时候做两个项目，要不然会把两个项目都拖累了。
A项目和B项目，哪个更有价值呢？哪个项目会推动组织前进？你如何能以最小的代价做一次有价值的公布？这就是你须要问的一些问题。
假设你还没有在A项目上採用敏捷方法，如今開始也不算太迟。
把快要做完的功能赶紧做完，然后评定剩下的各个功能的重要程度。我们希望，你開始以功能的重要程度依次开展工作。
雇用很多其它的专家
假设你真的想要同步推进A项目和B项目。你就必须雇用很多其它的专家了。即使是这样。招到人并促使他们产生效能还是要费些时间的。只是。雇用很多其它的人确实有效。
了解根本原因
我们的组织里之所以有这么多并行任务。当中一个原因就是我们的非常多专家的知识面都非常窄。
他们的专业技能越局限，项目就越少能用到他们。但当你须要那种人的时候，你真的是非他不可。
关于专家以及仅仅有专家才干做特定的工作的传说有非常多。
确实有些工作仅仅有专家才干做。真正的问题是：这类工作有多少？我不指望开发人员变成測试人员。反之亦然。我也不期望UI设计师变成安全专家。但作为一个管理者。我希望项目里的每一个人都能对项目充分了解。乃至对整个项目都非通常精通。
最重要的是。我期待着与其他专家工作，为了促进知识共享。
在产品开发上，我们可以用更通用的方法多的人，你的项目更多的灵活性。然后，当我说。“在工作队和流过。”你夸我，说，“当然。否则怎么行？”
你不必排除专家。
你所要做的就是。减少自己的需要，而且每个人在组织，提高技术能力。