為了加深EGO會員之間的相互了解，同時也為更多的技術人提供相互學習交流的機會，EGO開展了線上分享活動。本文是根據(jù)洪強寧線上分享的內(nèi)容整理而成。
大家好，今天給大家分享一下我在團隊技術氛圍上的一些經(jīng)驗和個人體會。
先簡單介紹一下我自己的經(jīng)歷，我2006年加入豆瓣，是豆瓣的第一位全職員工，從辦公室都沒有的狀態(tài)起步，經(jīng)歷了團隊壯大的整個過程。一直到2014年離開豆瓣為止，我覺得豆瓣的技術文化是建立和保持得相當不錯的，是個典型的學習型團隊。
2014年我加入了宜信大數(shù)據(jù)創(chuàng)新中心，這也是一個技術氛圍濃厚的團隊，所有產(chǎn)品線的leader都是技術出身，在風格上和豆瓣相比更強調產(chǎn)出，產(chǎn)品推進速度非?？臁?/span>
我會主要以豆瓣的情況為例來說明技術氛圍的建立和保持，也會穿插一些在宜信的做法。
有技術導向的價值觀，是保持好的技術氛圍的最關鍵的事情。一個公司要想有較好的技術氛圍，首先從最高層開始就需要重視技術，尊重工程師。如果連CEO都認為工程師只不過是用來實現(xiàn)產(chǎn)品需求的資源，那么技術團隊的負責人不管怎么做，也不可能保持住技術氛圍的。
這里說的尊重工程師，不是說給高薪之類的，而是說理解工程師的思維方式和做事方法，用客觀的、有邏輯性的方式來帶領團隊。比如重視數(shù)據(jù)、使用 A/B test 等方式來輔助決策、信息公開透明、不隨意更改需求、開發(fā)周期主導權由工程師把握等。鼓勵工程師對產(chǎn)品發(fā)表意見甚至介入決策過程也是很好的實踐。
自上而下的推行技術平臺化建設、推行DevOps、推行自動化構建、測試和部署流程。這幾樣事情雖然不直接產(chǎn)出產(chǎn)品，但可以顯著提高團隊的開發(fā)效率和技術水平，以及能夠提升開發(fā)者為自己的產(chǎn)出物質量負責的意識，這也是一個好的技術團隊必要的素質。但是如果沒有管理者的大力支持，靠平級推廣，難度就要大很多。
在豆瓣的一個很好的實踐就是很早就建立了技術平臺團隊，這個團隊從被產(chǎn)品推著跑的重壓下解脫出來，專注于技術能力的升級和基礎組件的維護。因為有這個團隊的存在，各個產(chǎn)品線可以保持相似的技術棧和開發(fā)方式，在基礎組件升級換代的過程中也可以避免出現(xiàn)新舊版本混亂的情況。同時，由于脫離了產(chǎn)品壓力，這個團隊可以有更多的時間來考慮精益求精的技術問題，可以持續(xù)不斷的推動整個公司的技術氛圍。
管理者不斷向團隊提出更高的技術要求，提高技術挑戰(zhàn)度，可以促進技術氛圍。對于性能提升、對于成本控制、對于效率優(yōu)化、對于運維友好度，這些技術要求會持續(xù)不斷的激勵團隊向更高的地方走，從而帶動整個團隊技術水平的不斷提升。
分享是快速交流思想的一種手段。鼓勵分享可以使得技術討論的氣氛活躍起來，碰撞出新的想法，也能更容易讓優(yōu)秀的人脫穎而出，成為團隊中的hero。
無論在豆瓣還是在宜信，我都會要求團隊成員每周輪流做一次技術分享，話題不限，但必須是技術相關。這是強制的，會迫使每個成員都意識到不能只滿足于完成工作內(nèi)容，學習也是非常重要的。這可以使得團隊主動的去跟隨技術趨勢，同時一個人的研究方向可以在分享時傳達到團隊成員，形成討論，甚至直接可以應用到工作中。
除了這種比較重的強制分享機制，還需要為團隊成員提供輕量通暢的分享交流渠道，當任何人發(fā)現(xiàn)一個有點意思的信息時，都可以沒有心理包袱的分享出來。在豆瓣我們用的是自建IRC，在宜信使用Slack和Bearychat。這種基于主題聚合的聊天頻道的設計，可以鼓勵交流，同時不會對正在專心工作的人產(chǎn)生干擾。
代碼也需要分享，分享的手段就是 code review。早期豆瓣采用的是投影代碼到墻上講解這種比較重的手段做 code review ，雖然由于效率問題只能 review 部分代碼，但是所幸的是我們一直堅持了下來，并且不斷設法提高效率，嘗試了各種工具。在把代碼倉庫從 svn 切換到 git 之后，幾乎所有團隊都立刻接受了 github flow 的工作方式，采用 pull request 作為 code review 的手段，迅速提高了 code review 的效率和流程通暢，基本可以做到覆蓋所有代碼變更了。
code review 的好處非常多，對技術氛圍而言，最大的作用就是培養(yǎng)每個工程師對代碼質量的追求。寫得很丑的代碼在 review 時是會被無情抨擊的，在來來回回的 comment 的過程中，整個團隊對于什么是好的代碼會慢慢達成一致，大家也會以寫出好代碼為榮。
多說一句，pull request 這種方式還有一個好處，就是打破團隊間的壁壘。每個團隊的代碼都是公開的，如果你的工作需要別的團隊修改代碼，你可以直接 fork 一份改完發(fā) pull request 過去要求 review 。這對促進團隊間交流，提高跨團隊工作效率，避免大公司病是很有益處的。
上面說的都是內(nèi)部分享，對外的分享包括公司間交流、技術大會分享、代碼開源等等。這些相信大家都已經(jīng)深刻理解了可以帶來的益處，就不多說了。
在一個工程師團隊內(nèi)，榮譽激勵要比經(jīng)濟激勵要有效的多，工程師最大的成就感就來自與自己的水平被同行認可。分享正是提供了榮譽感的來源。
對于架構師，在技術選型上有兩種傾向：偏保守或者偏激進。偏保守的，會多選擇已經(jīng)經(jīng)過多年使用，成熟穩(wěn)定的技術，這樣不確定性因素少，掉坑機率小。偏激進的，會多選擇新出現(xiàn)的技術，因為新技術往往功能和性能上都更佳，可以更好更快的滿足需求。
兩種傾向各有優(yōu)劣，我無意從技術層面上討論哪種更好。但如果要打造一個有濃厚技術氛圍的團隊，那么最好是能將天平向激進一端傾斜一些。過于保守追求穩(wěn)妥的技術團隊是很難形成學習型氛圍的。
在豆瓣，我們的傾向是非常偏向激進一邊的，幾乎對于新技術的引入是無保留的鼓勵。任何工程師希望引入一個新技術，除非看到明顯的問題（比如從現(xiàn)有技術無法平滑的切換過去），都會鼓勵工程師進行嘗試，用數(shù)據(jù)和效果來證明新技術的價值。一旦證明新技術可用且有效，就會進行全面的技術升級。嘗試失敗了，對工程師也不會有任何懲罰。
管理者對于創(chuàng)新需要有一個統(tǒng)一的認識：即創(chuàng)新都是有風險的。在豆瓣我們經(jīng)常會說，多做才多錯，不錯是因為沒做。要避免的是沒有在錯誤中成長，而不是犯錯本身。
當然，對新技術的選擇會有一個硬限制，即團隊擁有徹底掌握它的能力，出現(xiàn)問題時可以深入到底層進行修復。這會導致語言傾向，即優(yōu)先選擇使用本團隊熟悉的語言（在豆瓣是 Python ）編寫的組件。當然，如果一個其他語言編寫的組件非常有效，那么在團隊內(nèi)建設相應的語言能力，然后采納之，也是可行的。比如 Docker 技術的興起，我的建議是使用 Docker 的公司都應該擁有 Go 開發(fā)能力。
在招聘時，我們特別喜歡招聘喜歡“折騰”的人，即喜歡關注新技術，勇于嘗試，不畏懼失敗的人。這些人是真心喜歡技術的，團隊里這樣的人一多，管理者再給予鼓勵，自下而上的創(chuàng)新就會自然而然多起來。
另外，舉辦或者參加 Hackathon 也是工程師釋放創(chuàng)新動力的一個途徑，Hackathon 往往更偏重產(chǎn)品層面的創(chuàng)新，這里就不多說了。
好的工程師是無法容忍低效的，能用技術解決的問題就堅決不要用人解決。所以要營造和保持一個好的技術氛圍，管理者就需要鼓勵使用工具，鼓勵工程師引入工具或者創(chuàng)造工具。
比如各種工作流，能夠使用系統(tǒng)在線解決的，就不要讓工程師拿著單子跑來跑去找人。能夠做事后審核的，就不要做事前審批。能夠自動化的，就不要派個專人。繁瑣的流程一定會導致優(yōu)秀人才的流失和責任感的退化。
比如技術文檔，能用 git、wiki 或者 google docs 管理的，就不要用郵件發(fā)來發(fā)去了。
比如開發(fā)環(huán)境的建立，能夠做成一個一鍵建立的工具的，就不要再讓開發(fā)者對著文檔到處下載安裝了。
比如軟件上線發(fā)布，能夠做成一個發(fā)布系統(tǒng)的，就不要再寫發(fā)布文檔交給運維一步一步操作了。
現(xiàn)在隨著云計算和SaaS的興起，有非常多的云服務和第三方軟件可用，非常建議現(xiàn)在的管理者采購一些好用的工具，以及鼓勵工程師自研一些定制化的工具。在創(chuàng)造和使用工具上，工程師的熱情是高漲的，圍繞工具的討論也會促進技術氛圍的提升。
要建立和維護好團隊的技術氛圍，需要自上而下的技術導向，需要成員之間的分享精神，需要鼓勵自下而上的創(chuàng)新，需要建立效率優(yōu)先的工具文化。文化的建立和傳承是個潤物細無聲的過程，管理者自己需要真正認可技術文化，在工作中不斷打磨細節(jié)，才能起到效果。
EGO會員都是技術背景的管理者，相信大家對技術文化的認可一般不會有問題。但如果你的CEO或者合伙人還沒有形成這個認知，那么不斷的影響他們，給他們灌輸技術文化的重要性，讓他們真正把技術重視在心里而不是口頭上，這個可能其實是你最重要的工作之一。
