者：johanna rothman
你須要做一件特定的事情。比方設計乙個新的資料庫或者乙個特別的使用者介面。或者你須要一位公布project師，或者須要一位ui設計師，或者你想測試系統的某個部分，可是，尋常做那個工作的人偏偏不在——在你的專案裡，你碰到過多少次這樣的情況？你的專案受到什麼影響？是不是僅僅能等著那位專家回來？
在專案等待專家的情況出現時，非常多管理者感覺還是能夠掄上三板斧的。他們能夠讓專案等一等，也能夠請專家多工並行。或者他們拽來還有一位專家頂上。
畢竟，在不論什麼專案裡，你並非時時刻刻都須要專家。三板斧還是挺管用的，不是嗎？不論什麼資料庫管理員、高階測試人員或公布project師難道不都一樣嘛（隨到隨用），即使他們對你的專案的過去和未來一無所知？
不正確。全然不是那麼回事！在專案須要的人沒有著落之前啟動專案是不妥的。
讓乙個人多工並行也是不妥的。並且，不了解你的專案的人在你的專案裡事實上也不能算專家。
你還能夠有別的做法。那就是，通過多種方式來減少對專家的須要。你能夠讓專家與其它人配對工作；你也能夠在你的專案裡全然不用專家；或者進行專案組合管理，使得真正須要專門技能的專案錯開；你還能夠雇用很多其它的專家。
別讓專家獨自工作
有時候，專案須要的專門技能是能夠讓團隊裡的其它人學會的。舉個樣例，或許僅僅有乙個人精通構建系統。但乙個專案裡的全部人都須要知道怎麼使用那個構建系統。在那種情況下。我會讓精通構建系統的那個人與團隊裡的每乙個人逐一配對工作，直到每乙個團隊成員都像那個專家一樣熟悉構建系統。
千萬別讓專家獨自工作！通過這樣的方式，你能夠讓專業技能在團隊裡傳播。
依據技能的詳細情況，你可能首先須要召集乙個研討會。以使全部人對那個工具或技術都有乙個基本一致的了解。有時候。確實有必要讓公布project師開乙個講習班，花幾個小時解說一下構建系統的內部工作原理，然後讓他與每乙個人一一配對，確保全部人都明確怎麼使用那個系統。在資料庫管理方面，非常多時候你也能夠採用同樣的模式。
假設專業技能主要是工具使用方面的。或者是與其它團隊成員現有技能相似的一種技能。上述這樣的方法是非常有效的。但假設你處在乙個須要關鍵領域的專業知識才幹解決這個問題的場合下（這時候人們必須深入**庫的「心臟」），你就要採取其它方法了。比方內部拋棄。
拋棄不可替代的專家
有些人看起來是不可替代的。
假設他們正在做其它專案，而你想要動一下「他們的**」，你的專案必須等他們有空。
那是非常荒謬的，千萬別落到那種境界！拋棄他們吧！
或者，假設他們正在參與你的專案。讓他們做別的專案去吧。無論你採取什麼方法，你得立即把他們從你的專案裡請走。
假設那個專家在做其它專案，但僅僅要他還留在公司。你仍然有機會求助於他。將來有一天，那個專家會退休。然後在加勒比海揚帆起航，在下午4點就喝起了美味的朗姆酒。你將再也找不到他。
你想讓你的團隊成員什麼時候鍛鍊他們的專業技能呢？我想讓團隊在專家還在的時候就開始。
團隊對專家有一種不健康的心理依賴，而專家對團隊是一種互惠關係。我不是心理醫生，我也不想扮演電視裡的那種心理醫生，但在專案管理領域，這是非常糟糕的！
為了專家的自尊，整個團隊都在撫慰他。
這還阻礙了團隊裡的其它成員了解自己的產品。
假設你在乙個大公司裡工作，作為管理者，你能夠安排把專家轉入還有乙個專案。假設是在乙個小公司，你能夠讓專家去做乙個特殊專案。
確保那個特殊專案有足夠多的成果要交付，這樣的話，專家就會非常忙。讓他無暇顧及之前的老專案。
團隊將學會如何一起進步。一旦你將專家排除在外，團隊有機會成為一支真正的團隊。由於如今團隊成員有了乙個共同的目標。
一旦專家被排除在外。團隊成員就要團結起來，高速發現他們所不知道的東西。他們會把各自知道的東西拿出來分享。然而，你必須同意專家每週花一點時間來支援團隊。起初能夠是乙個小時，然後，僅僅有當團隊走投無路的時候才幹去找專家。為了搞明確產品的工作原理，你要鼓舞團隊動手去試驗，而不總是問問題。
把須要專家的專案錯開
或許你的專家沒有自尊問題。或許你確實有幾個安全方面的專家。你須要他們全然專注在乙個專案上。或許你期望a專案如今能完畢，然後你就能夠啟動b專案。可是，a專案還沒做完呢。
好吧，這個問題easy解決。假設a專案比b專案更有價值。別啟動b專案。
假設b專案比a專案更有價值。把a停了去做b。
是的，就這麼簡單。
只是，你會說，我們還沒把a專案公布出去呢。
好吧。假設你在a專案上使用了敏捷開發方法，或許你已經攢夠了有價值的東西去公布。但也未必。那就太糟糕了！本質上來說，專案組合管理是一種零和遊戲。因此，你須要為整個組織選擇最佳方案。
你確實想讓組織取得成功，對吧？
專案組合管理事實上就是在組織級別上進行艱難的討論，避免同一時候做兩個專案，要不然會把兩個專案都拖累了。
a專案和b專案，哪個更有價值呢？哪個專案會推動組織前進？你如何能以最小的代價做一次有價值的公布？這就是你須要問的一些問題。
假設你還沒有在a專案上採用敏捷方法，如今開始也不算太遲。
把快要做完的功能趕緊做完，然後評定剩下的各個功能的重要程度。我們希望，你開始以功能的重要程度依次開展工作。
雇用很多其它的專家
假設你真的想要同步推進a專案和b專案。你就必須雇用很多其它的專家了。即使是這樣。招到人並促使他們產生效能還是要費些時間的。只是。雇用很多其它的人確實有效。
了解根本原因
我們的組織裡之所以有這麼多並行任務。當中乙個原因就是我們的非常多專家的知識面都非常窄。
他們的專業技能越侷限，專案就越少能用到他們。但當你須要那種人的時候，你真的是非他不可。
關於專家以及僅僅有專家才幹做特定的工作的傳說有非常多。
確實有些工作僅僅有專家才幹做。真正的問題是：這類工作有多少？我不指望開發人員變成測試人員。反之亦然。我也不期望ui設計師變成安全專家。但作為乙個管理者。我希望專案裡的每乙個人都能對專案充分了解。乃至對整個專案都非通常精通。
最重要的是。我期待著與其他專家工作，為了促進知識共享。
在產品開發上，我們可以用更通用的方法多的人，你的專案更多的靈活性。然後，當我說。「在工作隊和流過。」你誇我，說，「當然。否則怎麼行？」
你不必排除專家。
你所要做的就是。減少自己的需要，而且每個人在組織，提高技術能力。
管理的誤區（2） 只有專家才能做這事
在專案等待專家的情況出現時，很多管理者感覺還是可以掄上三板斧的。他們可以讓專案等一等，也可以請專家多工並行，或者他們拽來另一位專家頂上。畢竟，在任何專案裡，你並不是時時刻刻都需要專家。三板斧還是挺管用的，不是嗎？任何資料庫管理員 高階測試人員或發布工程師難道不都一樣嘛 隨到隨用 即使他們對你的專案的...
《人月神話》2
人月神話 讀後感 開啟 人月神話 進入眼簾的是作者1975 年版獻辭，我很詫異老師這麼推崇這書，居然有這麼悠久的歷史 在日新月異的軟體界，還真有30多年經久不衰的 神話 抑或是一本 預言 對於沒有大型軟體編寫經驗的人來說，讀這本 人月神話 書更多的不是感受而是學習，由於時間緊張，對這本書之前只是囫圇...
專案管理 專家權
專案管理中，管理者會運用各種各樣的權力來管理專案，其中最常用也最有效的權力就是專家權。專家權，是指因為掌握某一領域的專業知識 專業技能，或者在這個領域裡具有豐富的實踐經驗，而具有這個領域裡的話語權。這種話語權，包括對這一領域的介紹 例如組織裡的分享 推廣 控制 改進等活動的得心應手的把握。這既能令人...