說了那么多謙虛、尊敬、信任的東西，聽起來都像是紙上談兵。既然這樣，我們現在來看看它們和現實是怎么聯系起來的。既然我們追求的是實際可操作的建議，所以下面會給出一系列特定的場景實例。其中很多看起來似乎都是顯而易見的，可一旦開始仔細思考，你就會發現自己（和同僚們）犯錯的頻率有多高了。 ### 放下自負 好吧，說得更直白一點，就是讓某些缺乏謙遜的人收斂一點兒。沒人喜歡和總是以自我為中心的人合作。哪怕你真的是會議室里最聰明的那個，你也沒必要到處炫耀。例如，你是不是總是覺得自己對于每個話題都要搶先發表意見，或是要作總結性發言？你是不是覺得自己需要在一項議案或是討論中對每個細節發表評論？或是你總是要知道誰在干什么？ 注意，“表現得謙遜一點”和人見人踩的懦弱完全不是一回事：自信并沒有錯。只是不要過了頭，非要弄得自己好像無所不知一樣。其實更好的思路是想辦法促成“集體”榮譽感。不要去擔心你的個人形象是不是高大，而應努力去營造一種團隊和集體榮譽感。Apache軟件基金會在圍繞軟件項目經營社區上已經有很長的歷史了。這些社區對自己都有很強的認同感，根本不歡迎對那些只關心自己往上爬的人。 自負這個東西有很多種解釋，就看你怎么理解，但很多時候它都會妨礙你的工作，讓你進步緩慢。這里從海明的演講里再摘取一段小故事來證明我們的觀點： “約翰·圖基幾乎總是不修邊幅的模樣。每次他參加重要會議的時候，對方總是要好一會兒才反應過來原來這是位大人物，應該認真聽他說。有好長一段時間約翰都要面對這種麻煩。這實在是太浪費時間了！我不是說你應該屈服，我說的是，‘作出妥協的樣子能給你帶來很多好處’。如果非要由著自己的性子來，‘我就是我行我素的人’，那么你就在整個職業生涯里不斷地付出一些不大但是很討厭的代價。日積月累就會變成原本沒必要的大麻煩。……通過使用系統并研究如何讓系統幫你做事，你就學會了調整系統，讓它按照你的意愿工作。不然的話，你就得終其一生去和這種潛規則作斗爭。” ### 學會批評和接受批評 喬是一名程序員，他最近找到了一份新工作。在上了一星期的班以后，他開始深入地學習了解團隊的代碼。出于責任心，他開始以溫和的方式對同事的代碼提出疑問。他通過E-mail的方式發出代碼審查，禮貌地詢問設計初衷或是指出邏輯上可以改進的地方。兩個星期后他被叫到了主管辦公室。“出什么事了？”喬問道，“我是不是什么地方做錯了？”主管看起來不太高興：“喬，最近有很多人投訴你，說你對同事太苛刻了，把他們說得左也不是右也不是。大家都很不爽，你最好低調一點。”喬因此大受打擊。若是在一個完全以H RT為基礎的環境里，喬的代碼審查應該是可以被接受的，同事們也會認同這種做法。但是在這個例子里，喬就應該對團隊里彌漫的不安全感多加小心，在引入代碼審查的時候應該更謹慎一點。 在職業程序員這個行當里，人身攻擊是相當罕見的——批評通常都是為了產品好。其中的訣竅就是要確保你（和你周圍的人）認識到對某人的創造性工作提出建設性批評和人身攻擊之間的區別。后者是毫無意義的——這種攻擊不但顯得小氣，而且幾乎不可能有什么建設性。而前者通常都是有益的，對改進具備指導性。最重要的是，它蘊含著對對方的尊重：只有真正關心對方的人才會提出建設性意見，希望對方在自身或是工作上有所進步。所以學著尊重對方，禮貌地給出建設性批評吧。如果你真的尊重一個人，那你就會自發地選擇有技巧有幫助的措辭——這種技巧需要很多練習才能學會。 作為談話的另一方，你也應該學會接受批評。這不是說你在技術上要謙虛，而是說你要信任對方，相信他是從心底為你好（當然還有你的項目），完全沒有把你當傻瓜的念頭。編程和所有技能一樣，都需要熟能生巧。如果你的同事提出的做法比你現在的好，你會把它當成是對你的性格或是人生價值觀的攻擊嗎？我們真心希望你不會。同樣，你的自尊和你的代碼不應該有什么聯系。換句話說，你和你寫的代碼是兩回事。你應該不斷地告誡自己，你和你寫的代碼是兩回事。不但你自己要相信這個觀點，還要讓你的同事也認同它。  別把你的自尊和你的代碼等同起來 舉個例子，假如你有一個比較敏感的同事，那么下面這樣的話是萬萬不能說的：“老兄，你完全把這個方法的控制流程給弄錯啦。你應該和大家一樣用標準的xyzzy代碼模式才對。”這段話全是反模式的東西：首先你告訴他，他“錯了”（好像這個世界非黑即白一樣），然后要求他作出修改，最后還指責他寫的東西和所有人都不一樣（讓他覺得自己很傻）。可以預見，這樣會讓對方變得很抵觸，得到的回應也肯定是沒有什么理智的成分。 好一點的版本可以是這樣“：嗨～我有點看不懂這段代碼的控制流程。要是用xyzzy代碼模式的話會不會更清楚一點？維護起來也方便？”注意這里，你謙虛地把問題歸到自己頭上，而不是他。他沒有錯，只是你理解代碼有困難而已。另外提出的建議也只是提供了一種方法讓可憐的你能理解代碼，或許還能在項目長期維護上有所助益。你也沒有提出任何要求——你的同事完全可以謝絕這個建議。討論的范圍被限定在代碼上，沒有涉及任何人的價值觀或是編程技術。 ### 快速失敗；學習；迭代 商業界里有一個著名的（也是說爛了的）段子，說是曾經有一個經理因為犯下大錯損失了上千萬美金。第二天他非常沮喪地回到辦公室開始整理桌子，這時他接到了預料之中的通知，“CEO想要見你”，于是他步履沉重地走進CEO的辦公室，默默地遞上一張紙。 “這是什么？”CEO問道。 “我的辭呈，”這位高管答道，“你叫我來就是要炒我魷魚的吧。” “炒魷魚？”CEO一臉狐疑地答道“，我為什么要炒你魷魚？我剛剛才花了一千萬來培訓你！”¹ 當然，這個段子很極端，但是故事里的CEO心里明白，就算炒魷魚也不能挽回這一千萬的損失，而且還要損失一名很有價值的高管，因為他以后肯定不會再犯這種錯誤了。 我們倆都在Google工作，而我們最喜歡的Google的格言之一就是“失敗是可以接受的”。廣泛的認識是如果沒有經歷過失敗的話，就說明你的創新還不夠，或者你承擔的風險還太小。失敗是更上一層樓的絕佳機會。事實上，托馬斯·愛迪生曾經說過：“即便我找到了一萬種行不通的辦法，也不代表我失敗了。我并不會因此而泄氣，因為每次試錯都是在前進。” Google通常都采用這樣一種（我們之前討論過的）理念，“不要等到完美的時候再出來”：只要產品大致可用，就立刻把它按照原樣公開給大眾。這就是Google Labs的使命。這種辦法使得成功和失敗的地方得以立即顯現出來，這樣編程團隊就可以盡快從中學習，迭代，然后發布新版本。它的缺點是Google常常會被揶揄說他家的產品總是在“beta”階段，比如Gmail就“測試”了四年多。而它的優點在于可以迅速做出調整以適應變化，在很短的時間內就能做出驚艷的產品。所有的這一切都要求謙虛的特質——把不完美的軟件展示給用戶是可以接受的，另外還需要一些信任，即用戶真的會認同你的努力，并且期望迅速看到改進。 從錯誤中學習的訣竅是要記住自己摔倒的地方，按商業用語來說就是“事后檢討”。但是要特別小心，千萬不能把事后檢討的文件變成一堆無用的道歉和借口——這不是它的目的。真正的事后檢討應該包含有關“學到了什么”以及“怎么改正”等經驗教訓的詳細注解。然后要保證把它放在一個隨手可及的地方，并且認認真真地按照上面所寫來實施改進。記住，正確地記錄錯誤還能讓其他人（不管現在還是將來）方便地了解事情的原委，以避免重復歷史。不要抹掉自己的足跡——像跑道一樣點亮它們，為后來人指路吧！ 一份出色的事后檢討應該包含以下內容： * 簡要 * 事件的時間線，從發現到調查，再到最終結果 * 事件發生的主因 * 影響和損失評估 * 立即修正問題的步驟 * 防止事件再次發生的步驟 * 得到的教訓 ### 為學習預留時間 辛蒂曾經是超級巨星——在她的領域里她絕對是大師級的程序員。被提升為技術指導后，責任隨之變大，而她也接受了這個挑戰。很快她就能領導周圍的每個人并指導他們工作了。她出席各種大會并就自己的領域作演講，不久之后她已經能掌管好幾個團隊了，她也非常享受“專家”這個頭銜。但是她卻開始厭倦這種生活了，不知不覺地她不再學習新東西，成為所有人之中最聰明、經驗最豐富的專家的這種新鮮感開始褪去。盡管表面上光鮮亮麗，但是總好像缺了點什么似的。直到有一天她終于意識到自己的領域不再尖端，人們開始轉向其他更有興趣的課題。她到底出了什么問題？ 我們來分析一下：成為人群中最睿智的人的確很讓人高興，而且能夠指導別人絕對可以帶來了不起的成就感。但是問題在于一旦攀至頂峰，人們往往就會停止學習了。而當一個人不再學習的時候，她就會開始覺得厭倦，一不小心還會變得落伍。雖然當領導很過癮，但是只要能放下一點驕傲，你就能開闊眼界，接觸新鮮事物。這說穿了其實還是謙遜的問題和是不是愿意像指導別人一樣接受別人的指導。偶爾應該跳出自己的舒適區，在更大的舞臺上接受各種挑戰。這樣你才能長久地保持愉快的心情。 ### 學習保持耐心 傅攀勃在多年前寫過一個把CSV倉庫轉到Subversion（以及后來的Git）上去的工具，由于RCS和CSV的行為異常古怪，他不斷地發現各種詭異的bug，比如 CVS會默默地吃掉明明是非法的RCS文件。而他的老朋友和同事卡爾對CVS和RCS都非常了解，他們決定一起來修復這些bug。 可是就在他們開始結對編程的時候發生了一個問題：傅攀勃喜歡自底向上的工作方式，他會深入項目，通過快速嘗試各種情況來梳理細節。而卡爾卻是喜歡自頂向下工作方式的工程師，他會先搭好框架，構建好調用棧里每個方法的實現后才會考慮bug的問題。這就引發了兩人之間巨大的沖突和分歧，有時甚至會產生激烈的爭執。傅攀勃和卡爾盡了極大的努力和專注，還恪守了 HRT 的原則才得以完成這項任務。HRT 最終不但拯救了項目，也保住了他們之間的友誼。 ### 對影響保持開放的態度 你越是容易受影響，你就越能影響別人；你越是示弱，你就越強壯。這兩句話看起來有點自相矛盾。但是每個人都碰到過某個同事，固執到叫人惱火。無論怎么試圖說服他都沒用，越勸越不聽。最后怎么樣？就我們的經驗來講，大家最后就會自然而然地把他當成障礙物“繞道而行”，再也不會有人聽取他們的觀點或反駁。沒人希望這種事情發生在自己身上吧？所以請記住這一點：接受意見改變自己沒什么大不了的。不要隨意挑起爭斗。不要忘了，要別人聽你說話，首先是要學會當一個聽眾。注意在被影響的時候，如果你要聽取意見，一定要在你下定決心或是確定宣布你已經做好決定之前——要是你的主意老是改來改去的，別人會覺得你這個人沒什么立場。 說到示弱，初看之下也有點奇怪。如果一個人承認自己對某個東西一無所知，不知道要怎么解決問題，那他還能得到多少團隊的信任么？示弱就是暴露弱點，這不是在摧毀自己的自信嗎？ 其實不是。承認自己犯錯或是無知從長遠來講其實能提升你的形象。事實上它蘊含了HRT的全部方面：它對外表示了“謙虛”，這是有責任心、負責的態度，這也是表示“信任”別人意見的態度，同時作為回報，別人也會因為你的誠實和堅強而“尊重”你。所以有時候最好的答案就是：“我不知道。”  誠實和謙虛不是氪氣石 想想那些政客吧。這幫人之所以討厭是因為無論他們錯得多離譜，或是對件事物表現得有多無知，他們也從來不會承認，所以很多人都覺得政客的話是不可信的。這種現象主要是因為政客經常暴露在對手的攻擊下。但是寫軟件的時候就用不著總是抱著防備的心態了——你的同事是合作者，不是競爭者。 * * * * * > ¹這個段子在網絡上有無數版本，曾經被套在好多著名經理人的頭上。