大家好，今天給大家分享一下我在團(tuán)隊(duì)技術(shù)氛圍上的一些經(jīng)驗(yàn)和個(gè)人體會(huì)。

先簡單介紹一下我自己的經(jīng)歷，我2006年加入豆瓣，是豆瓣的第一位全職員工，從辦公室都沒有的狀態(tài)起步，經(jīng)歷了團(tuán)隊(duì)壯大的整個(gè)過程。一直到2014年離開豆瓣為止，我覺得豆瓣的技術(shù)文化是建立和保持得相當(dāng)不錯(cuò)的，是個(gè)典型的學(xué)習(xí)型團(tuán)隊(duì)。

2014年我加入了宜信大數(shù)據(jù)創(chuàng)新中心，這也是一個(gè)技術(shù)氛圍濃厚的團(tuán)隊(duì)，所有產(chǎn)品線的leader都是技術(shù)出身，在風(fēng)格上和豆瓣相比更強(qiáng)調(diào)產(chǎn)出，產(chǎn)品推進(jìn)速度非常快。

我會(huì)主要以豆瓣的情況為例來說明技術(shù)氛圍的建立和保持，也會(huì)穿插一些在宜信的做法。

有技術(shù)導(dǎo)向的價(jià)值觀，是保持好的技術(shù)氛圍的最關(guān)鍵的事情。一個(gè)公司要想有較好的技術(shù)氛圍，首先從最高層開始就需要重視技術(shù)，尊重工程師。如果連CEO都認(rèn)為工程師只不過是用來實(shí)現(xiàn)產(chǎn)品需求的資源，那么技術(shù)團(tuán)隊(duì)的負(fù)責(zé)人不管怎么做，也不可能保持住技術(shù)氛圍的。

這里說的尊重工程師，不是說給高薪之類的，而是說理解工程師的思維方式和做事方法，用客觀的、有邏輯性的方式來帶領(lǐng)團(tuán)隊(duì)。比如重視數(shù)據(jù)、使用 A/B test 等方式來輔助決策、信息公開透明、不隨意更改需求、開發(fā)周期主導(dǎo)權(quán)由工程師把握等。鼓勵(lì)工程師對(duì)產(chǎn)品發(fā)表意見甚至介入決策過程也是很好的實(shí)踐。

自上而下的推行技術(shù)平臺(tái)化建設(shè)、推行DevOps、推行自動(dòng)化構(gòu)建、測試和部署流程。這幾樣事情雖然不直接產(chǎn)出產(chǎn)品，但可以顯著提高團(tuán)隊(duì)的開發(fā)效率和技術(shù)水平，以及能夠提升開發(fā)者為自己的產(chǎn)出物質(zhì)量負(fù)責(zé)的意識(shí)，這也是一個(gè)好的技術(shù)團(tuán)隊(duì)必要的素質(zhì)。但是如果沒有管理者的大力支持，靠平級(jí)推廣，難度就要大很多。

在豆瓣的一個(gè)很好的實(shí)踐就是很早就建立了技術(shù)平臺(tái)團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)從被產(chǎn)品推著跑的重壓下解脫出來，專注于技術(shù)能力的升級(jí)和基礎(chǔ)組件的維護(hù)。因?yàn)橛羞@個(gè)團(tuán)隊(duì)的存在，各個(gè)產(chǎn)品線可以保持相似的技術(shù)棧和開發(fā)方式，在基礎(chǔ)組件升級(jí)換代的過程中也可以避免出現(xiàn)新舊版本混亂的情況。同時(shí)，由于脫離了產(chǎn)品壓力，這個(gè)團(tuán)隊(duì)可以有更多的時(shí)間來考慮精益求精的技術(shù)問題，可以持續(xù)不斷的推動(dòng)整個(gè)公司的技術(shù)氛圍。

管理者不斷向團(tuán)隊(duì)提出更高的技術(shù)要求，提高技術(shù)挑戰(zhàn)度，可以促進(jìn)技術(shù)氛圍。對(duì)于性能提升、對(duì)于成本控制、對(duì)于效率優(yōu)化、對(duì)于運(yùn)維友好度，這些技術(shù)要求會(huì)持續(xù)不斷的激勵(lì)團(tuán)隊(duì)向更高的地方走，從而帶動(dòng)整個(gè)團(tuán)隊(duì)技術(shù)水平的不斷提升。

分享是快速交流思想的一種手段。鼓勵(lì)分享可以使得技術(shù)討論的氣氛活躍起來，碰撞出新的想法，也能更容易讓優(yōu)秀的人脫穎而出，成為團(tuán)隊(duì)中的hero。

無論在豆瓣還是在宜信，我都會(huì)要求團(tuán)隊(duì)成員每周輪流做一次技術(shù)分享，話題不限，但必須是技術(shù)相關(guān)。這是強(qiáng)制的，會(huì)迫使每個(gè)成員都意識(shí)到不能只滿足于完成工作內(nèi)容，學(xué)習(xí)也是非常重要的。這可以使得團(tuán)隊(duì)主動(dòng)的去跟隨技術(shù)趨勢，同時(shí)一個(gè)人的研究方向可以在分享時(shí)傳達(dá)到團(tuán)隊(duì)成員，形成討論，甚至直接可以應(yīng)用到工作中。

除了這種比較重的強(qiáng)制分享機(jī)制，還需要為團(tuán)隊(duì)成員提供輕量通暢的分享交流渠道，當(dāng)任何人發(fā)現(xiàn)一個(gè)有點(diǎn)意思的信息時(shí)，都可以沒有心理包袱的分享出來。在豆瓣我們用的是自建IRC，在宜信使用Slack和Bearychat。這種基于主題聚合的聊天頻道的設(shè)計(jì)，可以鼓勵(lì)交流，同時(shí)不會(huì)對(duì)正在專心工作的人產(chǎn)生干擾。

代碼也需要分享，分享的手段就是 code review。早期豆瓣采用的是投影代碼到墻上講解這種比較重的手段做 code review ，雖然由于效率問題只能 review 部分代碼，但是所幸的是我們一直堅(jiān)持了下來，并且不斷設(shè)法提高效率，嘗試了各種工具。在把代碼倉庫從 svn 切換到 git 之后，幾乎所有團(tuán)隊(duì)都立刻接受了 github flow 的工作方式，采用 pull request 作為 code review 的手段，迅速提高了 code review 的效率和流程通暢，基本可以做到覆蓋所有代碼變更了。

code review 的好處非常多，對(duì)技術(shù)氛圍而言，最大的作用就是培養(yǎng)每個(gè)工程師對(duì)代碼質(zhì)量的追求。寫得很丑的代碼在 review 時(shí)是會(huì)被無情抨擊的，在來來回回的 comment 的過程中，整個(gè)團(tuán)隊(duì)對(duì)于什么是好的代碼會(huì)慢慢達(dá)成一致，大家也會(huì)以寫出好代碼為榮。

多說一句，pull request 這種方式還有一個(gè)好處，就是打破團(tuán)隊(duì)間的壁壘。每個(gè)團(tuán)隊(duì)的代碼都是公開的，如果你的工作需要?jiǎng)e的團(tuán)隊(duì)修改代碼，你可以直接 fork 一份改完發(fā) pull request 過去要求 review 。這對(duì)促進(jìn)團(tuán)隊(duì)間交流，提高跨團(tuán)隊(duì)工作效率，避免大公司病是很有益處的。

上面說的都是內(nèi)部分享，對(duì)外的分享包括公司間交流、技術(shù)大會(huì)分享、代碼開源等等。這些相信大家都已經(jīng)深刻理解了可以帶來的益處，就不多說了。

在一個(gè)工程師團(tuán)隊(duì)內(nèi)，榮譽(yù)激勵(lì)要比經(jīng)濟(jì)激勵(lì)要有效的多，工程師最大的成就感就來自與自己的水平被同行認(rèn)可。分享正是提供了榮譽(yù)感的來源。

對(duì)于架構(gòu)師，在技術(shù)選型上有兩種傾向：偏保守或者偏激進(jìn)。偏保守的，會(huì)多選擇已經(jīng)經(jīng)過多年使用，成熟穩(wěn)定的技術(shù)，這樣不確定性因素少，掉坑機(jī)率小。偏激進(jìn)的，會(huì)多選擇新出現(xiàn)的技術(shù)，因?yàn)樾录夹g(shù)往往功能和性能上都更佳，可以更好更快的滿足需求。

兩種傾向各有優(yōu)劣，我無意從技術(shù)層面上討論哪種更好。但如果要打造一個(gè)有濃厚技術(shù)氛圍的團(tuán)隊(duì)，那么最好是能將天平向激進(jìn)一端傾斜一些。過于保守追求穩(wěn)妥的技術(shù)團(tuán)隊(duì)是很難形成學(xué)習(xí)型氛圍的。

在豆瓣，我們的傾向是非常偏向激進(jìn)一邊的，幾乎對(duì)于新技術(shù)的引入是無保留的鼓勵(lì)。任何工程師希望引入一個(gè)新技術(shù)，除非看到明顯的問題（比如從現(xiàn)有技術(shù)無法平滑的切換過去），都會(huì)鼓勵(lì)工程師進(jìn)行嘗試，用數(shù)據(jù)和效果來證明新技術(shù)的價(jià)值。一旦證明新技術(shù)可用且有效，就會(huì)進(jìn)行全面的技術(shù)升級(jí)。嘗試失敗了，對(duì)工程師也不會(huì)有任何懲罰。

管理者對(duì)于創(chuàng)新需要有一個(gè)統(tǒng)一的認(rèn)識(shí)：即創(chuàng)新都是有風(fēng)險(xiǎn)的。在豆瓣我們經(jīng)常會(huì)說，多做才多錯(cuò)，不錯(cuò)是因?yàn)闆]做。要避免的是沒有在錯(cuò)誤中成長，而不是犯錯(cuò)本身。

當(dāng)然，對(duì)新技術(shù)的選擇會(huì)有一個(gè)硬限制，即團(tuán)隊(duì)擁有徹底掌握它的能力，出現(xiàn)問題時(shí)可以深入到底層進(jìn)行修復(fù)。這會(huì)導(dǎo)致語言傾向，即優(yōu)先選擇使用本團(tuán)隊(duì)熟悉的語言（在豆瓣是 Python ）編寫的組件。當(dāng)然，如果一個(gè)其他語言編寫的組件非常有效，那么在團(tuán)隊(duì)內(nèi)建設(shè)相應(yīng)的語言能力，然后采納之，也是可行的。比如 Docker 技術(shù)的興起，我的建議是使用 Docker 的公司都應(yīng)該擁有 Go 開發(fā)能力。

在招聘時(shí)，我們特別喜歡招聘喜歡“折騰”的人，即喜歡關(guān)注新技術(shù)，勇于嘗試，不畏懼失敗的人。這些人是真心喜歡技術(shù)的，團(tuán)隊(duì)里這樣的人一多，管理者再給予鼓勵(lì)，自下而上的創(chuàng)新就會(huì)自然而然多起來。

另外，舉辦或者參加 Hackathon 也是工程師釋放創(chuàng)新動(dòng)力的一個(gè)途徑，Hackathon 往往更偏重產(chǎn)品層面的創(chuàng)新，這里就不多說了。

好的工程師是無法容忍低效的，能用技術(shù)解決的問題就堅(jiān)決不要用人解決。所以要營造和保持一個(gè)好的技術(shù)氛圍，管理者就需要鼓勵(lì)使用工具，鼓勵(lì)工程師引入工具或者創(chuàng)造工具。

比如各種工作流，能夠使用系統(tǒng)在線解決的，就不要讓工程師拿著單子跑來跑去找人。能夠做事后審核的，就不要做事前審批。能夠自動(dòng)化的，就不要派個(gè)專人。繁瑣的流程一定會(huì)導(dǎo)致優(yōu)秀人才的流失和責(zé)任感的退化。

比如技術(shù)文檔，能用 git、wiki 或者 google docs 管理的，就不要用郵件發(fā)來發(fā)去了。

比如開發(fā)環(huán)境的建立，能夠做成一個(gè)一鍵建立的工具的，就不要再讓開發(fā)者對(duì)著文檔到處下載安裝了。

比如軟件上線發(fā)布，能夠做成一個(gè)發(fā)布系統(tǒng)的，就不要再寫發(fā)布文檔交給運(yùn)維一步一步操作了。

現(xiàn)在隨著云計(jì)算和SaaS的興起，有非常多的云服務(wù)和第三方軟件可用，非常建議現(xiàn)在的管理者采購一些好用的工具，以及鼓勵(lì)工程師自研一些定制化的工具。在創(chuàng)造和使用工具上，工程師的熱情是高漲的，圍繞工具的討論也會(huì)促進(jìn)技術(shù)氛圍的提升。

要建立和維護(hù)好團(tuán)隊(duì)的技術(shù)氛圍，需要自上而下的技術(shù)導(dǎo)向，需要成員之間的分享精神，需要鼓勵(lì)自下而上的創(chuàng)新，需要建立效率優(yōu)先的工具文化。文化的建立和傳承是個(gè)潤物細(xì)無聲的過程，管理者自己需要真正認(rèn)可技術(shù)文化，在工作中不斷打磨細(xì)節(jié)，才能起到效果。

EGO會(huì)員都是技術(shù)背景的管理者，相信大家對(duì)技術(shù)文化的認(rèn)可一般不會(huì)有問題。但如果你的CEO或者合伙人還沒有形成這個(gè)認(rèn)知，那么不斷的影響他們，給他們灌輸技術(shù)文化的重要性，讓他們真正把技術(shù)重視在心里而不是口頭上，這個(gè)可能其實(shí)是你最重要的工作之一。