學術界有着許多關于個性、如何對個人進行分類以及如何管理個性的理論。在這些理論中，邁爾斯和布裡格斯的工作值得花一些時間來理解，他們倆在1942～1962年間建立了個性測試的理論基礎，并提出了對個性進行分類的體系。邁爾斯-布裡格斯類型指标（Myers-Briggs Type Indicator，MBTI）個性清單的作用是，使C. G. Jung描述的心理類型理論易于理解，在生活中更實用。他們的工作在1984年出版的《請理解我》（Please Understand Me）一書中得到了推廣，該書以一種易于理解的形式介紹了邁爾斯-布裡格斯方法。

Jung最初描述的類型是外向（extroversion，E）/内向（introversion，I）、感覺（sensation，S）/直覺（intuition，N）、思考（thinking，T）/感覺（feeling，F）和感知（perceiving，P）/判斷（judging，J）。值得注意的是，研究表明相當一部分程序員屬于INTJ（内向/直覺/思維/判斷）類型，Mickey和Ron也都具有這一個性特點。

然而，用這種公式化的方法來應對多樣化的技術個性特點是充滿危險的，我們也沒有發現它在團隊管理方面特别有用。我們建議你避開公式化的個性分類，而把精力放在已知個性特點的管理方面。

根據自身的經驗，我們給出了一些你在管理程序員時可能會碰到的個性特點類型。這個清單并不詳盡，但我們基本上解釋了你可能會管理到的不同個性類型，并給出了一些辨别方面的建議。

右腦理論與左腦理論源于Roger W. Sperry的工作，他的研究表明，大腦的左半球和右半球具有針對不同任務的專門功能。左腦通常專用于分析任務和語言表達任務。左腦的表達能力比右腦強得多，而右腦主要用于空間感知任務、音樂等。

如果你是一名程序員或者技術人員，你很可能屬于“左腦型”，這意味着語言、邏輯和分析使用得更多，也更客觀。其實稱為“左腦為主型”更恰當，因為我們隻有一個大腦，兩個半球始終是同時工作的。因此，你既可以是“左腦型”的人，又可以具有非語言交流、直覺、想象力較多且更主觀等強烈的“右腦型”傾向——這些傾向通常更多地與音樂家、作家、藝術家等創新型人才相關聯。

對于一名優秀的程序員來說，強大的左腦分析能力是必不可少的。不過，與右腦相關的活動往往也同樣重要，這是因為程序設計是一門很有創意的藝術。事實上，我們（和其他人一樣）發現，一些最頂尖的程序員同時也是音樂家。Mickey在大學一年級剛接觸程序設計時就是一名專職音樂家。“我剛開始做程序設計時，就對媒體很有興趣，那時我已經是一名音樂家了。音樂理論都是基于數學的，長時間的練習需要專注和紀律。我發現演奏和/或作曲時的創造性部分與設計并實現程序時的創造性部分非常相似。令人驚訝的是，甚至程序調試也在某些方面類似于歌曲的演奏學習——你需要一遍又一遍地演奏歌曲中的某一部分直至完全正确，這就如同反複運行程序直到能夠正确運行一樣。我甚至發現自己在做程序設計的時候完全沒有時間概念，這與我練吉他的情形非常相似。從那時起，盡管我還在繼續演奏音樂、作曲和作詞，但程序設計已變成了我的主要創新活動。”

在我們認識的衆多程序員中，這樣的故事并不是唯一的。事實上，音樂已經成了對有希望的候選人進行第一次面試時的常見問題。如果候選人是音樂家，那麼讨論他們喜歡什麼樣的音樂、演奏什麼樣的音樂、音樂理論以及音樂在他們生活中的地位，不但可以展現深刻的見解，而且有助于使他們在面試的開始階段保持放松。成為音樂家不是成為優秀程序員的必要條件，但我們也從來不将其視為成為優秀程序員的障礙！

多數企業中的多數雇員屬于白天型的人，與他們不同，多數程序員屬于夜晚型的人。他們往往在正常上班時間過了好久之後才到單位，并且工作到下班以後很久，當關鍵性的項目或者自己感興趣的項目進展到中途時常常能工作到深夜。一般說來，如果你關注的是結果，而這些起床很晚的人能給出符合或者超出你預期的結果，那就不是什麼問題。然而，溝通經常是個問題；也就是說，他們需要出席會議并交流信息。

在《編程之道》（The Tao of Programming）中，Geoffrey James提到：

經理走到程序員們跟前說：“關于工作時間：你們必須上午9點到，下午5點走。”聽到這裡，所有的程序員都很生氣，有幾個當場就提出辭職。

于是經理說到：“好吧，隻要你們能按計劃完成項目，可以自己安排工作時間。”程序員們這才感到滿意，從此每天中午來上班，一直幹到第二天淩晨。 為了避免這樣的問題，我們強烈建議你别要求夜晚型的人早上9點就到。我們的建議是，你設定一些希望所有人都遵守的“核心時間”，以确保整個團隊之中能有最低限度的合理溝通**。商定核心時間可以幫每個人節省大量的時間，且易于避免苦悶。注意，隔一段時間就要重申一下核心時間，因為程序員會感覺到日程的變化，他們對核心時間的遵守會漸漸不那麼嚴格。

還有一個問題需要解決，那就是公司其他部門對你的團隊的看法。在我們倆工作過的每個企業，我們都聽到過“你的手下直到中午才來上班”這樣的批評。針對這樣的話，你需要主動突出強調你的團隊投入了多少時間，他們寫完并提交代碼的時間有多晚。确保把那些最有名的夜貓子挑出來，讓大家都看到他們按自己的工作習慣所做出的業績。這一切都要主動去做，不要等到出現批評之後才着手。

3 “牧童”與“農民”

大多數程序員傾向于當“牧童”而不是當“農民”。也就是說，當問題出現時，他們的第一反應是“跳上馬離開”去獨自解決問題。他們常常跳過規劃，最終得到一次性的解決方案。實際上，可以在标準、實踐和團隊之間取得更好的平衡。

我們希望軟件開發更像種地。農民會有條不紊地了解地形、研究土地的化學組成、種植、澆水、除草，最後收獲。可靠、可擴展、可維護的軟件就是這樣有條不紊地開發出來的。

因此，識别出牧童，并确保他們受到限制而不能快速沖出去是很關鍵的。這樣開發出來的解決方案最終才能用于解決其他問題。

很多程序員都有牧童傾向，因此更高的要求是營造以下的軟件開發文化：禁止牧童行為，所有的主要項目都遵循系統的軟件開發生命周期。

不過，有時候，你還真的想要一個“牧童”而不是想要一個“農民”，這些時候需要做的通常是小型的、一個程序員就能完成的概念驗證項目或者原型項目。我們發現，如果身邊有一個能解決這種問題的“槍手”，對他對你都很有利。把你的需求和程序員的基本個性匹配起來，雙方都會更開心，結果也會更好。

許多“牧童”都是優秀的程序員，但你必須小心地對他們進行管理，以獲得想要的結果。他們有着當主角和引起紛争的傾向，所以務必對他們保持密切關注，一旦出現問題要馬上采取措施。

隻能當“牧童”的程序員通常都不會在企業待太久。要麼是你對他們總是自顧自地向前沖感到厭煩而辭退他們，要麼是他們對長期受限制感到厭煩而主動辭職。

4　英雄

英雄指的是承擔需要超人的努力才能完成的任務，并最終取得成功的人。在付出超人的努力方面，英雄與牧童是相似的。但英雄能夠在團隊工作和開發過程中獲得成果。英雄是培養出來的，通常會在企業中崛起為超級明星。

管理英雄的挑戰是：如果你總是期望他們付出超人的努力，很容易就毀了他們。偶爾期望一下是可以的，總是這樣期望就不行了。認真關注他們的福利，把他們選擇性地用于重要的舉措或者關鍵的項目。

Mickey和Ron在從事程序設計工作的時候，常常承擔難度較大的項目，并（在熬了若幹通宵或者進行馬拉松式的工作之後）出乎意料地完成任務。這對我們工作過的公司是很有益處的：為Kenway和E&S實現了關鍵産品的發布；完成了裡程碑式的蘋果電腦産品演示，這對于蘋果當時最新的計算機生産線是很關鍵的；為我們的公司儲備了專利技術；為了客戶和公司的利益，不斷挑戰我們自身的極限和已知的技術極限。在我們成為經理之後，這樣的經曆對于判定選擇性的超人努力與毀滅性的用人方式之間的界限是非常有用的。

5　内向的人

你的一些職員非常沉默、非常内斂，幾乎感覺不到他們的存在。他們可以把工作完成得很出色，但是對團隊動力或在會議上幾乎沒什麼貢獻。他們在一對一的時候能進行交流，但退回到人群裡以後就幾乎消失了。

在會議上讓他們發言時，當他們分享自己的意見或見解時，要給予正面的支持，這樣可以逐步幫助他們建立自信——自己對團隊是有貢獻的。找機會跟他們交談，當面認可他們的貢獻。與他們的交流要一個一個地進行。通過一些小事情與他們建立特殊的聯系，比如分享經驗或者一本書。總之，想方設法建立更緊密的聯系。

Mickey想起了Brøderbund公司的一名内向的技術作家。Mickey與這名作家是通過角色扮演遊戲建立聯系的。Mickey的鼓勵促使他進入了遊戲設計領域，最終成為了Brøderbund的遊戲設計經理，後來又在其他一些公司擔任小有名氣的出版作家和遊戲設計師。

多年來，這一聯系以及其他一些類似的聯系對我們倆來說也是一種回報，因為我們親眼看到了謙虛的人經過我們的鼓勵之後有所成長，并展現了自己的才華。

6　憤世嫉俗的人

盡量避免雇用心存極大憤懑的人。他們會通過挑撥離間和散布不滿情緒來毒害整個開發團隊，并對組織造成嚴重的破壞。如果沒有他們，那些情緒可能永遠不會出現。

憤世嫉俗的問題在于它是植根于現實的，但在組織内部的影響極大、極深。例如，“管理層不在乎程序員”可能是真的。但即便實際情況并非如此，憤世嫉俗的人們也會抓住每個機會來強調這句話的真實性。他們會把每一次非故意的怠慢（如辦公室冰箱中飲料的變化）說成是“管理層用來懲罰程序設計人員的密謀”。用最客氣的話說，這樣的言論是公然藐視真理和道德的。你甚至發現自己根本無法度假，如果不希望回來時發現自己的團隊處于混亂、脫軌甚至“造反”狀态的話。

7　奇葩

有些人隻不過是奇葩（jerk）。他們粗魯、刻薄、中毒不淺。當然，他們或許也有些可取之處。他們可能是很有才華、很有技術天賦的優秀程序員。但才華并不能匹配你雇用他們所需要付出的代價。離他們很近正是問題所在。

遵循“不招收奇葩”的法則。根據我們的經驗判斷，如果你不這樣做一定會後悔的。最好将該法則擴展到憤世嫉俗之人和傻瓜。你的職員會對此很贊賞，你的工作也會輕松很多。

我們列出了多種個性類型供大家了解，但強烈建議大家不要簡單地按這些類型對人進行分類。把每個人都作為不同的個體看待，你這位程序設計經理會更成功。

---

本文節選自《告别失控：軟件開發團隊管理必讀》

内容簡介

這是一本系統闡述面對混亂而容易失控的技術開發團隊時，如何管理、建設和強化團隊，成功交付開發成果的大作。兩位作者Mickey W. Mantle和Ron Lichty以合起來近70年的開發管理經驗為基礎，通過深刻的觀察和分析，找到了軟件開發管理的核心問題——人的管理，并圍繞如何真正理解程序員、找到合适的程序員、與程序員溝通這幾個核心話題，一步步展開，最終擴展到如何以人為本地進行團隊建設、管理和項目管理。

本書适合初級開發管理人員，可以說是一本從初級管理人員成長為高級管理人員的必備之書。同時，也适合有志于走向管理崗位的程序員、産品或其他技術公司員工。

,