管理的误区(2):只有专家才能做这事

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

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

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

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

别让专家独自工作

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

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

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

抛弃不可替代的专家

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

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

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

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

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

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

把需要专家的项目错开

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

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

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

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

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

雇用更多的专家

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

了解根本原因

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

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

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

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

1 收藏 评论

关于作者:豆巴陆其明

《DirectShow开发指南》之作者;《代码之道》《高效能程序员的修炼》《程序员的修炼:从优秀到卓越》之译者。 个人主页 · 我的文章 · 8 ·  

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部