小紅書重視技術(shù)氛圍和工程師文化的塑造，關(guān)于上述問題的答案，聽聽小紅書社區(qū)技術(shù)負(fù)責(zé)人風(fēng)笛怎么說。
1024 程序員節(jié)前夕，小紅書社區(qū)技術(shù)負(fù)責(zé)人風(fēng)笛受邀出席中國計算機學(xué)會舉辦的“第二屆 1024 中國工程師文化日” ，在大會上分享了自己對工程師文化的思考。當(dāng)天包括 CCF 理事長梅宏院士、CCF 前理事長鄭緯民院士、CCF 副理事長周明、航天科技集團五院“天問一號”火星探測器總設(shè)計師孫澤州等 20 多位國內(nèi)外技術(shù)大咖，也分享了對工程師文化的看法。
大家好，非常感謝 CCF 的邀請，能跟大家在1024的前一天，一起交流和討論“如何在互聯(lián)網(wǎng)企業(yè)中打造一支卓越的工程師團隊”。
一、技術(shù)人不能自high，首先要快速交付用戶和企業(yè)價值
對于互聯(lián)網(wǎng)企業(yè)原生的增長驅(qū)動力，不同的公司也有不同的基因，大致可以分為三類：業(yè)務(wù)、產(chǎn)品和技術(shù)的驅(qū)動。
不論哪種模式，技術(shù)都是互聯(lián)網(wǎng)公司背后的強大支撐——技術(shù)團隊都在其中扮演著非常重要的角色。縱觀高增長的公司，往往會看到其中工程師團隊在員工總數(shù)里面大約占到一半甚至以上，由此也可以看出在互聯(lián)網(wǎng)行業(yè)中工程師團隊的重要性。
當(dāng)然現(xiàn)實世界中，不論是哪種增長原動力，也都會受到一定程度的制約。比如對于技術(shù)創(chuàng)業(yè)者而言，經(jīng)常會出現(xiàn)技術(shù)很好但市場反響遇冷，這里面很大的陷阱就是技術(shù)自嗨。
中國絕大多數(shù)互聯(lián)網(wǎng)公司中都更偏業(yè)務(wù)驅(qū)動。有人說在整個世界互聯(lián)網(wǎng)行業(yè)中，中國企業(yè)是業(yè)務(wù)創(chuàng)新最快的，甚至比灣區(qū)業(yè)務(wù)創(chuàng)新速度都要快。
過去十年是中國互聯(lián)網(wǎng)產(chǎn)業(yè)發(fā)展非?？斓氖辏@十年中走出來的企業(yè)，不管它有什么樣的特點，工程師團隊都有如出一轍的特點：快。這個快并不僅僅是說交付效率快，更是交付用戶價值，交付企業(yè)價值的速度要快。
二、卓越工程師團隊的三大文化特征：熱情、自由和效率
我自己心目中卓越的工程師團隊?wèi)?yīng)該具備這三大文化特質(zhì)，我們在小紅書技術(shù)團隊中也正努力實踐傳遞這種文化。
熱情：對生活有熱情，對技術(shù)有追求，對同學(xué)有感情、對目標(biāo)有激情
小紅書1024程序員日
衡量一個工程師團隊是否是卓越，最終是以結(jié)果為導(dǎo)向——這個團隊是否能做出卓越的技術(shù)或者是產(chǎn)品?
這些東西離開了熱情，離開了熱愛是很難做出來的，熱愛會驅(qū)使我們孜孜以求。不論是對于技術(shù)能力還是對于產(chǎn)品迭代的目標(biāo)，都需要有非常深度的熱情才能把事情做好。
自由：信息平等流動、Peer Review、不做流程的奴隸
“自由”是工程師同學(xué)非常喜歡的一個詞，工程師不喜歡被各種各樣的東西約束。比如說在計算機領(lǐng)域里，有一類文化稱為極客文化，極客文化也是對自由非常強的追求。
對于工程師團隊而言什么才能夠帶來真正的自由?
·真誠表達(dá)
·自我驅(qū)動
·Peer Review
·信息平等
·不害怕犯錯
·不做流程的奴隸
不僅是工程師團隊，不論什么樣的團隊，當(dāng)人數(shù)增多層級增加的時候，就會出現(xiàn)信息傳遞上的路由節(jié)點。舉例來說，假如有500位工程師，一個人的最佳管理半徑是7~8人，500個工程師就要分好幾層。在這些層級之間，如果信息不能自由流動，就會有人吃信息差，這會導(dǎo)致團隊低效。真正工作在研發(fā)一線的工程師，如果沒有完整的信息，很難做出最好的選型和決定。
“Peer Review”和“沒有權(quán)威”，這對一個工程師團隊來說也是非常重要的，工程師團隊中層級是最不重要的東西，當(dāng)我們面對具體的產(chǎn)品或者是技術(shù)問題時候，誰擁有最多的信息，誰有最多可能的執(zhí)行路徑或者點子，誰就是這個問題的 owner。與聲音大小、高低，資深與否并不直接相關(guān)，而是與誰掌握更多的信息相關(guān)，和前面的自由是相互呼應(yīng)的。
最后一點是不做流程的奴隸，大家可能看過德國工程師換下水道蓋子的過程，其中的流程非常嚴(yán)密，甚至包括貼瓷磚等等的SOP。但是流程是為人而服務(wù)的，目的是解決問題，而不是把人安裝到流程上成為了“螺絲釘”。
效率：簡化不是簡陋，是正確的抽象和高質(zhì)量的交付
工程師更傾向于去做那些具有創(chuàng)造性的事，而對于機械的、流程化的，持續(xù)執(zhí)行的，換句話說就是做久了會使人的腦子很僵化的東西，會自動簡化。這對于提高團隊效率，產(chǎn)出更高水平的工作非常重要。
這里也會誕生一種亞文化，工程師團隊對于工具的重視度。
工程師團隊技術(shù)水平高還是低，非常重要的一個度量指標(biāo)是這個團隊是否能夠持續(xù)產(chǎn)生可以提升效率的工具，是否能夠不斷把頻繁發(fā)生的事情自動化掉。有個玩笑說是懶惰推動了技術(shù)的進(jìn)步，其實我們今天更多的更加先進(jìn)、更加高階的技術(shù)都是想著怎么簡化，怎么節(jié)省更多的時間和步驟。
三、業(yè)務(wù)研發(fā)面臨的困難
在“永遠(yuǎn)做不完的需求”面前如何溝通和取舍?
在互聯(lián)網(wǎng)做研發(fā)會有一個像魔咒一樣的東西，叫做“永遠(yuǎn)做不完的需求”。這和整個中國的應(yīng)用創(chuàng)新環(huán)境有關(guān)，這種情況下，產(chǎn)品和研發(fā)的比例有 1:3 、1:5，甚至有 1:2 的，這里會發(fā)現(xiàn)一個特別的現(xiàn)象，想要交付掉所有的需求幾乎是不可能的，需求永遠(yuǎn)都在排隊，這時候就必然要做排序和取舍。
可以看到在整個研發(fā)的流程中，隨著軟件復(fù)雜度的增加和軟件生存周期的變長，呈現(xiàn)出兩極的態(tài)勢。
其中一類軟件會持續(xù)使用下去，規(guī)模也越來越大，另外一些模塊跟功能可能只存在一天，最短的甚至只有幾個小時。以馬上到來的“雙十一”為例，比如搶紅包雨可能只存在一小時，之后這個功能就下線了。對于這樣的功能如何提升它的研發(fā)速度，怎樣做質(zhì)量保障?這是擺在不同企業(yè)面前的問題。
如何避免團隊越大，實際做事的人越來越少?
團隊越來越大，人越來越多時，會出來很多新的工種，甚至專門有人來做組織流程優(yōu)化?？墒俏覀儠l(fā)現(xiàn)流程越來越重，看著工程師做事情的人越來越多，實際做事情的人卻越來越少。真正在一線做事情的就是在土上挖溝的人，其他的人是來層層監(jiān)督，看他有沒有按照流程設(shè)計的時間點把溝挖好，所以這里會產(chǎn)生大量的內(nèi)耗，這和一個高效卓越工程師團隊追求的初心和理念有非常大的 gap。
對于工程師而言，有一類不好的趨勢就是隨著技能的分類，工程師團隊也越來越細(xì)分。比如說連前端工程師都會區(qū)分我是寫 review 的還是寫別的，我是寫 vue 的還是 react 的，做 A 的就不能做 B，更別說其中的流程監(jiān)控和質(zhì)量保障。
對工程師而言我們會更提倡技能盡可能全，我們需要更多的“T形”人才。他在某一個領(lǐng)域里需要足夠精深，但是這一“橫”也要足夠?qū)?，?cover 到我們的常用技能，能看到在構(gòu)建軟件中相同的部分，而不是不同的部分。
技能“全”的同時，也要能做“小”事。一個團隊開始臃腫起來就是因為那些看似不起眼，沒那么重要，卻非常影響團隊運轉(zhuǎn)的“小”事沒有人做。
四、打造工程師團隊要面臨的幾個核心矛盾
接下來分享幾個針對于工程師團隊從小到大，在逐漸變化中面臨的矛盾，這個幾乎是所有團隊負(fù)責(zé)人，特別是到中高階技術(shù)負(fù)責(zé)人面臨的挑戰(zhàn)。
產(chǎn)品 VS 技術(shù)：業(yè)務(wù)需求的持續(xù)增長與團隊有限交付能力之間的矛盾
在互聯(lián)網(wǎng)行業(yè)里有個笑話，說產(chǎn)品經(jīng)理和研發(fā)工程師是一對永遠(yuǎn)解不開的死疙瘩。剛才提到一個觀點，就是需求是永遠(yuǎn)做不完的，但如果是技術(shù)完全拿到?jīng)Q定權(quán)在業(yè)務(wù)側(cè)也會帶來災(zāi)難。這一對矛盾在不同的企業(yè)里有不同的解決方式，但是有一條非常重要，就是技術(shù)首先要守住自己的本職工作，能夠在關(guān)鍵的技術(shù)方案中判斷什么行和什么不行，以及在技術(shù)條件實現(xiàn)的邊界和可持續(xù)性上能夠給出自己的明確判斷，避免過度承諾。
同時技術(shù)和產(chǎn)品要有比較好的互動方式，其中就需要有非常清晰的決策流程。每家公司不一樣，比如業(yè)務(wù)驅(qū)動型公司在解決沖突的時候，充分把信息對齊，把問題和矛盾表露清楚，最后由業(yè)務(wù)做決定，這是很重要的解決分歧的過程。
算法 VS 工程：如何客觀看待算法這個新工種的價值
算法是大概從2009年、2010年之后在互聯(lián)網(wǎng)行當(dāng)研發(fā)序列中逐漸出現(xiàn)一個新的工種，曾經(jīng)也是高薪的代名詞。在很多研發(fā)團隊的構(gòu)建中，到底需要少而精還是人數(shù)多，存在著一定的矛盾。我們應(yīng)當(dāng)更加客觀的看待算法和工程的投入，不能厚此薄彼，好的系統(tǒng)實現(xiàn)也是非常重要的。
特別是和人工智能相關(guān)的算法，也有著很多應(yīng)用的邊界。比如說在信息分發(fā)的場景下，我們以大家熟悉的今日頭條、抖音、小紅書信息流為例，從過去的編輯推薦走向全自動化、智能化的推薦算法分發(fā)，可能會帶來幾倍、十倍以上的效率增長，從0到1有非常大的提升。但是這時也會有邊際遞減，基本上紅利一年到兩年就吃完了。這時候?qū)τ谒惴?，對?a href="http://ygpos.cn/AI_1.html" target="_blank" class="keylink">AI技術(shù)的投入，在整個技術(shù)團隊視角就要能夠看到它的邊際效益點，更多的投入不見得比整個工程系統(tǒng)的升級帶來的收益要多很多。
算法工程很多從業(yè)者來自于非計算機科班專業(yè)，比如數(shù)學(xué)、物理、自動化等等理工類專業(yè)的同學(xué)。所以這里非常重要的一點就是，當(dāng)更多非科班非計算機系的工程師入行后，他們同樣需要有很好的系統(tǒng)架構(gòu)的視角。尤其是對于人工智能類的系統(tǒng)，很多都是“死”在了高并發(fā)和規(guī)模化的這條路上?？瓷先ソY(jié)果很美，但是一旦上規(guī)模就很難。
而且很多人在學(xué)校時，看到的更多是那些新的模型和新的演算方法的提出，對于加入企業(yè)會存在很多不切實際的幻想，覺得自己80%的工作是在改造這個世界。而實際上場景中80%的工作是在建設(shè)底層系統(tǒng)，解決數(shù)據(jù)流、數(shù)據(jù)一致性等方面的問題。所以理性的看待團隊中不同技術(shù)類型工種，特別是近年新興起的算法和工程之間的差異也是一個重要的矛盾視角。
研發(fā) VS 測試：維持“1:10”的測試研發(fā)比還是逐漸走向無測試
以往我們會看到不同公司都有測試工程師，最奢華的公司測試工程師和研發(fā)工程師的比值可以做到 1:1。在互聯(lián)網(wǎng)行當(dāng)里，基本上 1:3 到 1:5 是比較合理的數(shù)字，1:5 比例的公司更多是做APP，是直接有用戶 UI 界面的真正偏后端的團隊，沒有直接 UI 交互的團隊會達(dá)到 1:10 甚至 1:15。
在軟件工程領(lǐng)域做得非?？壳暗模热缯f谷歌這樣的公司，甚至能做到工程師只需要把代碼寫完提交上去，后面就不用管了，現(xiàn)場出了故障基本不會追責(zé)到工程師。因為他們已經(jīng)完全把測試工具化、流程化掉了，甚至有測試驅(qū)動開發(fā)的人員在里面。所以如何在團隊里設(shè)置質(zhì)量團隊、QA 工程師的數(shù)量，以及他們的定位到底是偏測開還是偏功能測試，也有全自動化的在云上的測試。今天在小紅書的技術(shù)團隊里，已經(jīng)可以進(jìn)展到可以對幾十種甚至上百種機型做到自動化的 UI 測試。
五、我理解的工程師文化以及如何建立工程師文化
我理解的工程師文化：
·它不是“衣著休閑、時間自由、不修邊幅、免費三餐與工位裝修”
·它不是“自high文化，完全由技術(shù)說了算，喊著技術(shù)驅(qū)動業(yè)務(wù)”
·它是“以共同解決實際問題為目標(biāo)的團隊文化”
·它是“內(nèi)心欲望和恐懼的外在表達(dá)，因欲望而創(chuàng)造，因恐懼而改造”
這其中的核心是以共同解決實際問題為目標(biāo)的團隊文化，更多是構(gòu)建工具、解決未知，能持續(xù)提升效率這樣的一種欲望，驅(qū)動我們不斷對技術(shù)，對團隊內(nèi)部流程工具去改造。
那么如何建立工程師文化?
自己和團隊一起工作，要能做自己-2的事情。
·我自己對于團隊中的技術(shù) lead 會有一個要求，就是這是一個蠻高的要求，也是從陸奇老師這邊借鑒的：能做自己-2的事情。其實能做自己-1就已經(jīng)很了不起了，做自己-2的事情，而且要求團隊里的 lead 都做到，是更有挑戰(zhàn)的事情。
·沒有 Leader，只有 Owner
·一切以數(shù)據(jù)說話，分析數(shù)據(jù)的本質(zhì)
·可以加班，但拒絕無意義的加班
·工程師團隊很簡單也很單純，更多的人每天是兢兢業(yè)業(yè)的坐在那里貢獻(xiàn)著自己的代碼，貢獻(xiàn)著自己的力量，希望每一位技術(shù) lead，每一家公司都有一支屬于自己的卓越的工程師團隊，我的分享就到這里，謝謝大家!
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
