者：Johanna Rothman

你須要做一件特定的事情。比方設計一個新的數據庫或者一個特別的用戶界面。或者你須要一位公布project師，或者須要一位UI設計師，或者你想測試系統的某個部分，可是，尋常做那個工作的人偏偏不在——在你的項目里，你碰到過多少次這樣的情況？你的項目受到什么影響？是不是僅僅能等著那位專家回來？

在項目等待專家的情況出現時，非常多管理者感覺還是能夠掄上三板斧的。他們能夠讓項目等一等，也能夠請專家多任務并行?；蛘咚麄冏磉€有一位專家頂上。

畢竟，在不論什么項目里，你并非時時刻刻都須要專家。三板斧還是挺管用的，不是嗎？不論什么數據庫管理員、高級測試人員或公布project師難道不都一樣嘛（隨到隨用），即使他們對你的項目的過去和未來一無所知？

不正確。全然不是那么回事！在項目須要的人沒有著落之前啟動項目是不妥的。

讓一個人多任務并行也是不妥的。并且，不了解你的項目的人在你的項目里事實上也不能算專家。

你還能夠有別的做法。那就是，通過多種方式來減少對專家的須要。你能夠讓專家與其它人配對工作；你也能夠在你的項目里全然不用專家；或者進行項目組合管理，使得真正須要專門技能的項目錯開；你還能夠雇用很多其它的專家。

別讓專家獨自工作

有時候，項目須要的專門技能是能夠讓團隊里的其它人學會的。舉個樣例，或許僅僅有一個人精通構建系統。但一個項目里的全部人都須要知道怎么使用那個構建系統。在那種情況下。我會讓精通構建系統的那個人與團隊里的每一個人逐一配對工作，直到每一個團隊成員都像那個專家一樣熟悉構建系統。

千萬別讓專家獨自工作！通過這樣的方式，你能夠讓專業技能在團隊里傳播。

依據技能的詳細情況，你可能首先須要召集一個研討會。以使全部人對那個工具或技術都有一個基本一致的了解。有時候。確實有必要讓公布project師開一個講習班，花幾個小時解說一下構建系統的內部工作原理，然后讓他與每一個人一一配對，確保全部人都明確怎么使用那個系統。在數據庫管理方面，非常多時候你也能夠採用同樣的模式。

假設專業技能主要是工具使用方面的?；蛘呤桥c其它團隊成員現有技能相似的一種技能。上述這樣的方法是非常有效的。但假設你處在一個須要關鍵領域的專業知識才干解決這個問題的場合下（這時候人們必須深入代碼庫的“心臟”），你就要採取其它方法了。比方內部拋棄。

拋棄不可替代的專家

有些人看起來是不可替代的。

假設他們正在做其它項目，而你想要動一下“他們的代碼”，你的項目必須等他們有空。

那是非常荒謬的，千萬別落到那種境界！拋棄他們吧！

或者，假設他們正在參與你的項目。讓他們做別的項目去吧。無論你採取什么方法，你得立即把他們從你的項目里請走。

假設那個專家在做其它項目，但僅僅要他還留在公司。你仍然有機會求助于他。將來有一天，那個專家會退休。然后在加勒比海揚帆起航，在下午4點就喝起了美味的朗姆酒。你將再也找不到他。

你想讓你的團隊成員什么時候鍛煉他們的專業技能呢？我想讓團隊在專家還在的時候就開始。

團隊對專家有一種不健康的心理依賴，而專家對團隊是一種互惠關系。我不是心理醫生，我也不想扮演電視里的那種心理醫生，但在項目管理領域，這是非常糟糕的！

為了專家的自尊，整個團隊都在撫慰他。

這還阻礙了團隊里的其它成員了解自己的產品。

假設你在一個大公司里工作，作為管理者，你能夠安排把專家轉入還有一個項目。假設是在一個小公司，你能夠讓專家去做一個特殊項目。

確保那個特殊項目有足夠多的成果要交付，這樣的話，專家就會非常忙。讓他無暇顧及之前的老項目。

團隊將學會如何一起進步。一旦你將專家排除在外，團隊有機會成為一支真正的團隊。由于如今團隊成員有了一個共同的目標。

一旦專家被排除在外。團隊成員就要團結起來，高速發現他們所不知道的東西。他們會把各自知道的東西拿出來分享。然而，你必須同意專家每周花一點時間來支持團隊。起初能夠是一個小時，然后，僅僅有當團隊走投無路的時候才干去找專家。為了搞明確產品的工作原理，你要鼓舞團隊動手去試驗，而不總是問問題。

把須要專家的項目錯開

或許你的專家沒有自尊問題?；蛟S你確實有幾個安全方面的專家。你須要他們全然專注在一個項目上?；蛟S你期望A項目如今能完畢，然后你就能夠啟動B項目?？墒?#xff0c;A項目還沒做完呢。

好吧，這個問題easy解決。假設A項目比B項目更有價值。別啟動B項目。

假設B項目比A項目更有價值。把A停了去做B。

是的，就這么簡單。

只是，你會說，我們還沒把A項目公布出去呢。

好吧。假設你在A項目上使用了敏捷開發方法，或許你已經攢夠了有價值的東西去公布。但也未必。那就太糟糕了！本質上來說，項目組合管理是一種零和游戲。因此，你須要為整個組織選擇最佳方案。

你確實想讓組織取得成功，對吧？

項目組合管理事實上就是在組織級別上進行艱難的討論，避免同一時候做兩個項目，要不然會把兩個項目都拖累了。

A項目和B項目，哪個更有價值呢？哪個項目會推動組織前進？你如何能以最小的代價做一次有價值的公布？這就是你須要問的一些問題。

假設你還沒有在A項目上採用敏捷方法，如今開始也不算太遲。

把快要做完的功能趕緊做完，然后評定剩下的各個功能的重要程度。我們希望，你開始以功能的重要程度依次開展工作。

雇用很多其它的專家

假設你真的想要同步推進A項目和B項目。你就必須雇用很多其它的專家了。即使是這樣。招到人并促使他們產生效能還是要費些時間的。只是。雇用很多其它的人確實有效。

了解根本原因

我們的組織里之所以有這么多并行任務。當中一個原因就是我們的非常多專家的知識面都非常窄。

他們的專業技能越局限，項目就越少能用到他們。但當你須要那種人的時候，你真的是非他不可。

關于專家以及僅僅有專家才干做特定的工作的傳說有非常多。

確實有些工作僅僅有專家才干做。真正的問題是：這類工作有多少？我不指望開發人員變成測試人員。反之亦然。我也不期望UI設計師變成安全專家。但作為一個管理者。我希望項目里的每一個人都能對項目充分了解。乃至對整個項目都非通常精通。

最重要的是。我期待著與其他專家工作，為了促進知識共享。

在產品開發上，我們可以用更通用的方法多的人，你的項目更多的靈活性。然后，當我說。“在工作隊和流過?！蹦憧湮?#xff0c;說，“當然。否則怎么行？”

你不必排除專家。

你所要做的就是。減少自己的需要，而且每個人在組織，提高技術能力。

轉載于:https://www.cnblogs.com/blfshiye/p/4665328.html

總結

以上是生活随笔為你收集整理的管理神话2：专家只有权这样做的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。