寫給同事的一封信

親愛的同事，

轉眼我在這個團隊工做已有一年的時光，這一年也完成了我從通信行業轉入互聯網圈的過渡。過去的一年給了我不少觀察（團隊）的機會，也帶給了我很多思考，從我過去一年的寥寥幾篇博文你應當能看到部分。

今天，我想借這篇文章與你們聊一些內容，以便你更加明白：爲何我在工做中對本身和你們的要求都那麼高？爲何我強調責任與重視培養工做好習慣？爲何我會直接批評和積極表揚人與事？但願你的其它「爲何」也能在這裏找到答案的線索！

現實與虛擬

現實社會中有不少讓人惱火的事：想排隊按序辦事，卻總有些人插隊；想維護家裏樓梯走道的衛生，卻發現總有人亂扔垃圾和隨地吐痰；車禍明明緣於對方過失，但他卻百般否定與狡辯；想喝上乾淨的自來水，不求助於淨水器彷佛沒有可能；等等。林林總總！

對於一名構建虛擬世界的軟件工程師，咱們不得不變得「性格分裂」，由於咱們不能將現實中的髒、亂、差帶到咱們所構建的虛擬世界裏。這種「不能」並不是咱們一廂情願，而是現實所迫，由於「髒亂差」的虛擬軟件世界必定會給用戶帶來糟糕的產品使用體驗，也會爲咱們的工做生活增長額外的成本（加班等）。一旦明白這一點，你就會理解我爲何在工做中的要求會那麼高，並且是多方位的！

面對現實與虛擬，咱們不得不適時進行模式切換。在社會生活中，不要過於較真而影響本身的健康；在工做生活中，咱們應力求構建完美的虛擬軟件世界。

剛加入團隊之時，發現你們所寫代碼多了些隨意，團隊知識管理也沒有「官方」途徑而是各自寫在本身的文檔或記在頭腦中（那時做爲新人的我仍是爲此經歷了沒必要的痛苦）。爲了改變編碼隨意這種現狀，幾個月前我決定着手實施編碼規範。坦白說，這是個人職業生涯中首次大張旗鼓地推行編碼規範，之前我一直認爲寫出有質量的代碼（和文檔）是軟件工程師所應作的本份之事，無需過於強調。當時決定推廣的另外一大主因是，咱們產品所基於的開源項目的根基很是好，除了自身代碼就是一個優秀的參照外，更有着完備的編碼規範和規範檢查工具。然而，編碼規範的最高境界並不是「格式」，而是咱們的「態度」，由於規範解決的只能是形式問題，而沒法規避不恰當命名等非形式問題。也正因如此，大家所寫的大部分代碼我都會走查，經過不斷指出問題並幫助改善的方式培養你們的認真態度。最近，每當我看到代碼中存在大家改善質量的痕跡時，都會會心一笑；面對你們指出我所寫代碼中所存在的改善點時，我更加高興並給予確定和感謝，由於我堅信這是咱們團隊所應倡導的文化。你們回頭看一看，過去的幾個月咱們團隊在這方面取得了質的進步。

談及團隊知識管理，不得不說到我所帶頭編寫的《軟件開發指南》和《技術白皮書》。《軟件開發指南》中的內容一方面很好地指導了咱們的工程實踐（涵蓋軟件設計、流程等大大小小的各方面），另外一方面爲新人上手起到了積極做用。前者從目前咱們的項目中基本杜絕了模塊混亂、加速了新版本合併速度和使得軟件開發活動更規範化能夠看出，後者則從最近WL在晨會上說「《指南》寫得很好」得以佐證。

值得強調的是，全部這些進步都是咱們共同創造的，沒有大家的積極參與和快速跟進根本不能取得現有成績，也很難輕鬆走得更遠。還記得我在項目總結會上所說的「我爲人人，人人爲我」嗎？

現實如此不完美，咱們可否從構建的虛擬軟件世界多找到些完美呢？！

面子與責任

面子的重要性無需多言，「捍衛面子」的意識也深刻了咱們的骨髓。然而，正如我曾在郵件中所提到的，以我在外企工做時的觀察發現，美國的工程師之因此更富質效在於他們不是將面子放在首位，取而代之的倒是責任。也正因如此，美國的工程師很喜歡發問且有時的問題讓人以爲 「尖銳」，這一特質不管他們是面對同行、仍是「領導」都一致。

我堅信，一個講面子與一個講責任的團隊將造成大相徑庭的兩極。講面子的團隊大多低效並頗有可能集體無能，而講責任的團隊將運做得務實、高效；重視面子的團隊看到問題採用的是迴避態度，講責任的團隊看到問題會指出並較真甚至承擔。責任之因此重要，是由於它會促使咱們在工做中有所做爲——用心按時、按質完成工做。一個講責任的團隊也不容易出現「技術軍閥」和「管理官僚」，這二者對於團隊的殺傷力均可稱爲是「核武級」。

重面子的團隊還有另外一個突出表現：團隊成員很「聽話」，上級說什麼就作什麼，不想不問，但承擔不良後果。這種團隊每每會凸顯出「領導」的「重要性」，由於沒有「領導」團隊就不知要幹什麼、要向哪走。與之相反的是，重責任的團隊即使短時沒有領導者也能有序運做，甚至倒逼管理者有所做爲。

另外，責任不該只是對於本身和團隊，還有對於家庭的部分。好比，經過儘量少加班多與家人在一塊兒、陪伴孩子成長。意識到這種責任，你每每會花更多的時間去提升本身的能力和效率，而不會一味地想着加班是解決工做問題的萬能藥。我一直不能理解那些沒事卻在加班的人，他們對於家人如此，在工做中真的可靠嗎？在業務發展不須要的情形下，頻繁的加班不是我的能力有問題，就是管理出現了問題。

再者，講責任會促使團隊的成熟，使得成員重視承諾，這對項目的有序運做相當重要。重視承諾的含義是：咱們對於沒法定期完成的工做不承諾，而一旦承諾就要努力達成。

理解了我對面子與責任的見解後，相信你能明白爲何我會在晨會上不時提問，也能理解爲何我敢說且主動承擔非職務以內的（管理）工做、會私下找你聊工做上的事和不多加班。這一切都是責任使然，是我應該去作的！

批評與表揚

人追求完美是無極限的，不管咱們多麼有經驗、專業和職位多高，始終能作一個更好的本身而得到成長。顯然，成長的過程當中不可避免地會犯錯。矛盾地，在糾錯的過程當中咱們又有惰性而阻礙前行。面對自身錯誤惰於糾正的狀況下，咱們如何向前？須要來自他人的批評！

說到批評很容易讓人想到《人性的弱點》中所倡導的「不要批評他人」觀點，也很容易讓人浮想「說話的藝術」。我對於批評有着不同的見解和使用方法！

首先，咱們得對批評的反應調低一點敏感度，不要一聽到批評就什麼都聽不進，甚至出現邏輯混亂地狡辯的情況（好比，人家批評你的是事，但你說人家批評你時的態度不對。其實，只要人家事批評得對，即便態度有點不妥也得包容，能夠將之理解爲「我作錯了而致使別人的情緒」）。其次，碰到批評先深呼吸，以後想想所批評的問題確實存在嗎？在一個講責任的團隊中，批評不光不多出現，一旦出現你們也能日常心面對（注：批評出現多了極可能代表團隊管理出現了問題，不做爲的事多了。從團隊對於批評的態度能夠看出這個團隊是重面子的仍是講責任的）。在使用批評的方法上，我主張批評的目的不是讓人難堪，而是幫助他人改進，在實施批評以前先友好地提醒對方錯在什麼地方和如何改進。若是友好提醒還解決不了問題，那隻能實施批評了。被批評雖讓人難過，但也會讓人記憶深入而避免下次再犯一樣的錯。對於批評的藝術問題我並不想多談，由於工程師大多很單純、是非少，只要各自心態擺好真的無需複雜到將批評「藝術化」。

談及批評不得不說說表揚。表揚是一種對他人付出的確定與欣賞，但中國的工程師好象不大擅長使用這種方法去表達本身的情感。我發現表揚很容易出現「禮尚往來」的現象，你今天表揚了別人，過幾天可能也會收到對方的表揚回報。這種事情若是在團隊出現得多了就很容易帶來輕鬆的氛圍，也容易讓人體會到本身對於團隊的重要性，這樣很差嗎？

與表揚類似的是，咱們在工做中還能夠：當因本身的工做失誤而給人帶來麻煩時說聲「對不起」；得到別人的幫助後道聲「謝謝」；向他人諮詢問題時用「請教個問題」開頭。這些小細節作起來很容易，但對團隊建設的貢獻卻很大！

出色的團隊離不開批評，且是經過表揚而培養的！

質效與習慣

我在美國工做的（累計）半年時間裏，所涉項目週末從未見人加班，即便項目很是緊張依然如此。週末行駛在高速公路上，時不時能看到房車或被拉着的遊艇從車旁駛過，非常感嘆。人家不加班又何以如此高質效且過着豐富的週末生活呢？

在軟件行業，質量與效率是一個永恆的話題，但卻鮮有人真正瞭解它們從何而來。也每每迷失於SCRUM、CI、ET等諸多方法論中。

要作到有質效地工做，首先離不開各位承擔應有的責任，其次是良好的工做習慣。前者會促使咱們持續變得更專業、善於思考和較真，後者則使咱們高效，二者一結合質量也隨之有了。以個人觀點，中國的工程師只要沒有將責任和工做好習慣落實好，談其餘的方法論都沒用，談了也白談。

說到工做好習慣很容易讓人以爲發虛，有點看不見摸不着的感受。我也一時很難在這說清楚，須要你們在工做中多觀察，瞭解我是如何作和思考的。培養工做好習慣的另外一個值得一提的好處是，它有助於杜絕技術問題演變成管理問題，從而使得團隊更加輕量和高效。

精品產品是有氣質的，是團隊責任與工做好習慣的折射！

最後，過去的一年咱們一同收穫了很多，在這個偉大的開源項目上工做也讓我以爲頗有樂趣。謝謝你在碰到問題時主動與我討論、謝謝你曾經授予個人技術決定權，由於儘管大家有的不說，但我能感覺到你對我技術能力的確定和信任！同時，也謝謝大家曾經給予個人幫助！