「白菜」「蘿蔔」的故事你推薦誰？

「白菜」「蘿蔔」的故事

---你推薦誰？

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

jack zhai

微軟msf

培訓書籍中提到乙個「白菜蘿蔔」的故事，說的是對做好本職工作的理解，體現了人的性格對工作的影響，同時作為專案管理人員，對不同性格的偏愛，也決定了整個團隊的工作風格。

故事說的是乙個軟體開發的專案組，有兩個都很優秀的員工，乙個叫「蘿蔔」，乙個叫「白菜」。蘿蔔做事快，是我們常說的「麻利」那種人；白菜則屬於「慢工出細活」的型別，做事謹慎，善於計畫。兩人各帶乙個小

team

，工作業績都不錯。在專案結束時，要評選優秀員工，當然是選最好的，該選誰呢？公司老總們有些爭議……

專案開始的時候，領導分配差不多的任務，各自開發乙個軟體模組，大家按計畫執行。蘿蔔很快就說做好了，而白菜還在吭哧吭哧地和產品

/測試人員討論。領導看到蘿蔔的工作進度很高興，就讓蘿蔔去做更多的事。等到開發階段結束的時候，蘿蔔負責的模組增加了許多功能，還幫助其他的小組做了一些開發工作。

專案進入到穩定階段，測試工作全面展開，大家發現蘿蔔負責的模組出了很多問題，白菜負責的模組比較穩定，

bug的數量很少。從統計的資料中看到，蘿蔔在團隊的暴光率很高，當然他也修復了很多的

bug。白菜結束了自己模組的工作，開始幫助其他人，但由於不熟悉其他人的模組，修復的

bug不多。

到穩定階段的後期，蘿蔔由於前期設計考慮的不周全，發現在設計上有一定的缺陷，導致模組實現非常複雜，他也成全面了解該模組唯一的開發人員，到了專案的最後階段，蘿蔔幾乎天天加班到最晚，在交付時間的前夕，最後修復了

bug。

領導看到蘿蔔小組的工作如此辛苦，也很感動，專案組形成一句口頭纏：「有問題，找蘿蔔」。

專案順利結束，開始績效考核。從統計的資料上看，蘿蔔完成的功能多，修補的

bug多，並且成為專案「不可或缺的員工」，工作努力是大家有目共睹的，模組也算按時交付；另一方面，白菜的模組也是按時交付，但各種統計資料較少，尤其是修復

bug的數量，他所帶的小組加班記錄也不多。有的領導認為：蘿蔔工作速度快，而且掌握複雜模組，他本人工作辛苦努力，應該成為優秀員工。對於白菜，領導沒有太多的印象，各種溝通、交流都比較順暢，工作嗎，好象就是按時完成了任務，質量不錯。

如果你是蘿蔔與白菜的領導，你推薦哪乙個呢？

其實，很多領導會推薦蘿蔔，乙個重要的原因是給領導的印象深刻，而白菜往往被忽略為「普通」的員工。我們先說乙個古老的故事：

古代的時候，有乙個韓昭侯，當然生活上比較奢侈

(連戴帽子與穿衣服都有不同的人專門負責，人家是領導，當然有權利嗎

)。一天他喝多了，沒有蓋被子就睡著了。負責戴帽子的**

(典冠者

)看見，就拿衣服給他蓋上

(還是很關心領導的

)。韓昭侯醒後問是誰蓋的，有人說是「典冠者」。韓昭侯首先懲罰了負責衣服的人

(典衣者

)，因為他工作失職，凍壞了領導是多麼重大的事故；同時他也懲罰了典冠者，原因是他越權，他的任務是先做好本職工作，而不是做其他人的工作。韓昭侯感慨地說了一句名言：「非不惡寒也，以為侵官之害甚於寒。」

這個故事表面上與白菜蘿蔔的故事沒什麼關係，但說明乙個道理：本職工作的質量是考核員工的根本，儘管韓昭侯有些迂腐地認為只能做本職工作，有些「過」了，但懲罰典衣者是對的。

其實，從員工的能力來講，白菜與蘿蔔都按時完成了任務，都是稱職的。推薦白菜作是從管理的角度審視：踏踏實實的完成工作，軟體質量很高，

bug數量少至少從乙個角度說明前期設計工作的充分，這應該是乙個軟體開發團隊所追求的。雖然蘿蔔的很多任務作辛苦，是他前期設計不充分的惡果，但他能積極面對，辛勞工作，最終完成工作也是值得讚賞的。

「白菜蘿蔔，各有所愛」。從前我可能也會推薦蘿蔔，但現在也許我會優先推薦白菜，再推薦蘿蔔。你呢？

「白菜」「蘿蔔」的故事 你推薦誰？