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