人才是企業最重要的資源，但切勿為了某個天才顧此失彼。本文為medium上的一篇文章，作者是來自加利福尼亞大學洛杉磯分校的軟體工程師 Jonathan Solórzano-Hamilton。在文中， 他向讀者講述了自己的經歷：開除團隊中的頂級工程師何以成為他做出的最英明的決定。
這個故事是關於一個被形容為「天才」的團隊成員失寵的歷程。這位「天才」對於我們公司的產品結構有著深刻理解，能夠準確把握未來需求，且具備相當紮實的專業知識。
他是我們的頂級人才，是我們旗艦計畫的主導者。
我們暫且把他稱為 Rick。
Rick 被公認為是團隊的大神，他是我們軟體專案的首席開發者和架構師。
任何時候任何人都有關於程式碼的問題或需要某個任務需要幫助，他們會去找 Rick。Rick 在辦公室裡安裝了一個大白板，就只用於這個目的，上面總是有著過去討論時留下的雜七雜八的痕跡，不太能擦掉。
無論何時，只有有極具挑戰性的問題，Rick 都會去處理。Rick 在他辦公桌上安裝了一個跟我們生產伺服器規格相同的伺服器，他可以獨立執行整個應用程式堆疊，同時對每一層進行故障排除。
Rick 工作不需要別人，他寧願在做自己的私人工作空間裡獨自工作。
Rick 也不需要任何人建造的任何東西。他可以從頭構建他需要的一切東西，因為凡人給他提供的東西都太微不足道了。
很快，Rick 就不再參加會議，他沒時間開會，因為要寫的程式太多了。
Rick 關上了辦公室的門，白板也停下來了。他不再有時間幫別人培訓，他自己的問題都還解決不完。
Rick 身後的事情不斷積壓，他之前創建的工具不斷冒出 bug，這些使得他無暇預估新產品的開發。
當然這些 bug 出現是因為「用戶打開方式不對」。他的工作怎麼會出現問題？當然不會。
我們的工作進度表上，綠色標誌變成黃色， 黃色變成紅色，紅色開始一閃一閃亮晶晶了。我們的任務狀態一個接一個變成「受阻」，人人都在等在Rick出面。
不要擔心，Rick 會處理的。所有的他都會處理好的。
專案經理從贊助商那裡得到了半年的緩衝期。六個月之後，又拖了七個月，一年之後，又拖成了兩年。
Rick 敲程式碼的速度比以往更快，他一個星期工作七天，每天工作十二個小時。
每個人都知道，只有 Rick 才會拯救團隊於水火之中，人人都屏息以待，期望 Rick 能發明出靈丹妙藥，讓這個計畫起死回生。
Rick 日漸孤僻、焦躁不安。面具最終脫落下來，他化身成了邪惡博士。
比最初約定的發布日期晚了兩年之後，我和這個專案小組第一次會面。我聽說過這個計畫已經有一段時間了，因為這個計畫在我的公司中已經變得臭名昭著，但是當時我還沒有被派去處理參與該計畫。
我被公司派來看看這計畫還有沒有救。
我仔細查看了程式碼。Rick 說的沒錯：他造的東西確實沒人能理解，除了 Rick 之外。這就是他大腦工作方式的外在展現。有些相當聰明、有些則就是複製、貼上，所有這些都非常另類，完全無法記錄下來。
我帶著這份裁定結果去見了我們的CTO，告訴他，只有 Rick 能夠維持這個產品。並且，Rick 多在這個計畫上工作一天，結案的日期就多往後推一個星期。與其說他在創造這個計畫，他破壞這個計畫的速度更快。
我們跟 Rick 坐下來談了談他在這個計畫中的作用，說了說我們的顧慮。我們解釋了新的策略，這個團隊得通力合作，重新創建一個新產品。可以縮減一些不必要的功能，只提供用於生產的最基本的必須產品即可。但是整個團隊都要群策群力，不再有瓶頸出現。
Rick 什麼反應呢？
他還能有什麼反應？他暴走了。
Rick 說他不想成為這個鬧劇中的一部分。如果我們欣賞不了他的才華，那是我們的錯，而不是他的錯。他說，不出幾個月，我們都得哭著求他回來幫我們。
Rick 對我們怒目而視，叫囂著我們連最起碼欣賞天才的腦子都沒有。
在這之後，Rick 連續幾個月都拒絕領導層的主動示好。既不休假，也不讓把工作分配出去。我們多次試圖引入免費開放程式框架取代他那難以維護的「精心特製」工具，但統統遭到拒絕。
他將其他開發者修改的程式碼恢復原狀——包括已經測試過了漏洞修復。他堅持不為其他人的工作負責，繼續不斷在公開場合批評他的同事。
我們把 Rick 給開除了。
大約一個星期之後這事兒才塵埃落定。失去了讓他們歡喜讓他們憂的團隊領袖，整個團隊先是受到了震動，隨後花了一段時間才重整旗鼓。
之後，我便看到他們共同聚集在一塊白板面前。
合作。這是 Rick 從未見到過的場景。
他們通力合作，設計了一款新的產品，比之前簡單的多了。它沒有那麼多花俏的東西，也沒有達到五年前產品預期的要求。
Rick 開發的產品支援了超過15000種設想的動態工作流程。而在現實生活中，使用我們產品99%的情況，其實只會有500種不同的流程。我們的團隊便針對這些流程寫了程式，不再去思考那10000種可能，這便去除了 Rick 將近三分之一的工作。這也就去除了 Rick 上百小時的工作，但是也同樣避免了上千個小時的技術負債。
計畫贊助商也一致同意我們將用於某些極端情況下的功能去除掉。因為，這些極端狀況只為我們5%的潛在客戶服務，但是卻佔了該產品複雜程度的四分之一。
我們重新發行了這款產品，包括了 Rick最初的10%程式碼，這些程式碼相當穩定，還包括了幾千行新程式碼，代替了 Rick 之前15萬行的一些不知所云的東西。
這個團隊在半年的時間裡，完成了五年的工作。在接下來的幾個月裡，我們將該計畫從測試發展成完整的客戶版。
我們不只更換了 Rick 之前建造的東西，還超過了他，完整地發表了該產品。所有這些在一年的時間裡完成。我們最後的產品，不論是大小還是複雜性，都不到 Rick 當時構建的產品的五分之一。
完成速度是他的幾百倍，並且組合時間短，服務的客戶群是之前的十倍，卻幾乎沒有 bug 出現。
這個團隊又回過頭去研究 Rick 當時負責的其他產品了。他們同樣扔掉了他之前的舊程式碼。Rick 之前開發了一款產品，他花了三年時間都沒弄淸楚，他們團隊用了三個月，共同開發並發布了出來。
團隊裡雖然沒有 Rick 這種人了，我們也不再有「天才」來帶頭創建產品，但是我們的生產率卻節節高昇。
Rick 是個非常有天分的開發者，能夠解決複雜的商業邏輯問題，創建紛繁複雜的結構來支撐他那高級的設計，但是卻無法在解決在一個團隊中如何有效合作的問題。
Rick 的出現從以下幾個方面來說是具有破壞性意味的：
- 首先，他創建了一個必須依賴他的「邪教」：所有的問題在最後都會變成 Rick 的問題。助長了個人迷信色彩。開發者們不再嘗試自己解決，就那麼等著看 Rick要怎麼做。
- 第二，他不寫可讓大家維護的程式碼。從來不記錄也不測試，所以儘管天資聰穎，仍一敗塗地。他對自己才華的盲目自信戰勝了一切。
- 第三，他這人性格就帶有破壞性色彩。團隊成員不願向他坦誠自己的意見或建議，因為他動輒就會訓斥他們。Rick 尊重的人只有他自己，除此之外，他藐視一切。
- 第四，他缺乏責任意識。哪次失敗也不關他的事，他始終堅信這一點，所以無法從錯誤中汲取教訓。
我相信 Rick 不是一開始就這樣的，我見到的可能是他最差的一刻。這也是由於年復一年的加班工作、以及來自客戶和同事的各種批評指責造成的。Rick 墮落至此實在惋惜。他的上級有責任，事實上，最初的管理團隊都有責任：他們放任他而去。
不幸的是，Rick 走得太遠，他不能也不會被帶回正道了。苦口婆心勸說、讓他放假休息亦或是把他派到別的計畫上，對他來說都已於事無補了。
到了這點，整個團隊意識到他確實有毒。但是這個團隊成員對他依賴性太強，以至於人人都覺得他是他們唯一的選擇。
要記住，永遠都有別的選擇。
團隊的優勢不是在於個人的才華發揮作用，而在與整個團隊間通力合作、堅忍不拔、互相尊重。
團隊建設要注重彼此尊重、互相激發出最好的那面，做最好的自己。
眾志成城方可攻堅克難，互相幫助，遠比依靠一個 Rick 要走的遠。
請注意！留言要自負法律責任，相關案例層出不窮，請慎重發文！