工程師，世界上最偉大卻也最辛苦的職業(yè)。在外界看來，工程師是一個神秘的群體......

毋庸置疑，工程師在互聯(lián)網(wǎng)科技的歷史上扮演著極其重要的角色，如創(chuàng)立微軟的程序員比爾·蓋茨、依靠搜索算法創(chuàng)建 Google 的佩奇和布林、構(gòu)建 Facebook 社交網(wǎng)絡(luò)的黑客馬克·扎克伯格，無數(shù)大名鼎鼎互聯(lián)網(wǎng)公司都是由工程師所創(chuàng)立。

對于技術(shù)人員來說，到底有沒有自己特定的文化？什么才是真正的工程師文化？

今天，我想在這里再談一下工程師文化，一方面是因為我又有了一些想法和體會；另一方面，因為我也正走在創(chuàng)業(yè)的路上。

我認為，建立一個有濃重的工程師文化的團隊或公司，有必要把自己的想法形成白底黑字的“字據(jù)”，以供以后打自己的臉：

“要是未來沒有做到，這篇文章就打我未來的臉” 或者 “這篇文章太幼稚了，未來的我會打我現(xiàn)在的臉”。當然，如果非要打臉，我希望是前者。

為什么要工程師文化？

看看最近二十年來社會的發(fā)展，計算機和互聯(lián)網(wǎng)已經(jīng)滲透到了這個社會的每一個角落，各式各樣的計算機技術(shù)成為了整個世界發(fā)展的強大引擎。

無論是業(yè)務(wù)創(chuàng)新還是技術(shù)創(chuàng)新，都依托于技術(shù)的快速演進，技術(shù)成了解放生產(chǎn)力、提高社會運作效率的中堅力量。

今天，每個從事計算機行業(yè)的技術(shù)人員都應(yīng)該感到幸運，因為，我們不但選對了行業(yè)，也出生在了正確的時代，可以感受到前所未有的刺激和變化。

此時我們只需要思考一個問題，那就是，我們是否處在正確的地方并用正確的方式做事？

在我看來，這個世界上有三種類型的商業(yè)公司：

運營或銷售驅(qū)動型公司

這類的公司以運營和營銷見長，技術(shù)對于它們來說更多的只是為了支持大規(guī)模的營銷活動，以及成本上的控制，所以，基本上來說不太需要技術(shù)創(chuàng)新。這類公司非常缺乏安全感。

產(chǎn)品驅(qū)動型公司

這類公司以產(chǎn)品見長，創(chuàng)造能提升用戶生活體驗的產(chǎn)品，技術(shù)對于它們來說，除了支持大規(guī)模的在線用戶之外，更重要的是增強用戶體驗，提高整個業(yè)務(wù)流程效率的技術(shù)創(chuàng)新，比如在 UI 交互和業(yè)務(wù)流程方面。

這類公司最大的問題，就是容易被別人模仿和抄襲。

技術(shù)驅(qū)動型公司

這類的公司相信技術(shù)能改變世界，它們更多的是用強大的工程技術(shù)來創(chuàng)造顛覆性的產(chǎn)品，用各種自動化的技術(shù)取代人類工作。

比如：近代蒸汽機技術(shù)取代了大量的人工勞動，數(shù)字技術(shù)取代了大量信息傳遞的人工勞動，未來它們還希望通過人工智能來代替人類做更多的決定。這類公司最大的問題就是可能做出叫好不叫座的產(chǎn)品。

這三種公司都可能成功，也都有問題，但是，無一例外，他們都需要強大的技術(shù)支撐，只不過，他們把技術(shù)所放在的位置不一樣。

無論你有多么的看不起技術(shù)人員，你都無法否認，你今天的生活相當?shù)囊蕾囘@幫工程師，沒有他們，你恐怕都不知道怎么生活了。

***幾十年前就說過——“科學技術(shù)是第一生產(chǎn)力” ，無論什么樣的科學技術(shù)的理論要落地都會依賴于工程技術(shù)有多先進。

所以，在今天，作為一個 IT 或互聯(lián)網(wǎng)公司，“工程師文化”不是一個問題，而是一個常識！

工程師文化的“兩大法寶”

簡單來說，我把這么多的工程師文化總結(jié)成兩大類：“自由” 和 “效率”。

本來還應(yīng)該有個“創(chuàng)新”，但我個人認為，創(chuàng)新的前提是——在自由的環(huán)境下對提高效率的癡迷，就一定會發(fā)生創(chuàng)新。

創(chuàng)新不是憑空出現(xiàn)新的東西，其實，觀察一下人類的發(fā)展史不難發(fā)現(xiàn)，幾乎所有的創(chuàng)新基本上是“跳出原來的思維模式用新的思維模式對原有問題的效率進行質(zhì)的提升”。

比如：通信、交通、醫(yī)療、教育、生活……幾乎全都是在優(yōu)化效率。

所以，如果精神不自由，就很難跳出老的思維模式，如果不是對效率的提升，這個創(chuàng)新可能會不接地氣。因此，我認為，工程師文化就是自由加效率！

以上列舉的這些特征，來源于：Google 的《重新定義公司》（How Google Works）、我在 Amazon 的工作經(jīng)歷、37Signals 的"Rework"、Quora 上的" What Makes Good Engineering Culture? "、 Slideshare 上的 “What Makes Good Engineering Culture”，以及我最近這半年來的一些實踐。

由前 Google CEO 施密特編寫的《重新定義公司》（How Google Works）一書

自由

工程師文化首先意味著創(chuàng)新文化。因為工程師都是有創(chuàng)新沖動的人，而創(chuàng)新的源泉來源于精神的解放，精神自由才會引發(fā)各式各樣的奇思怪想。

因此他們才會有常人覺得不可能的瘋狂想法和想象力，而這些想法和想象力導致了創(chuàng)新。

精神上的自由具體表現(xiàn)在以下六個方面：

1. 自我驅(qū)動。自己管理自己是最好的管理，最失敗的管理是家長和保姆式的管理，從興趣出發(fā)的工作才可能迸發(fā)出真正的動力。

2. 靈活的工作時間和地點。工程師們的工作更多的是腦力工作，而不是體力工作，工作上時間和地點的自由安排可以讓工程師們的腦力工作更有效。

Remote（遠程辦公）是一個很不錯的工作方式，開源社區(qū)基本上都是使用這鐘方式。

3. 信息平等。這意味著，全體員工得到的是原始信息，而不是被管理者們層層加工消化后的信息，信息的屏蔽很容易造成誤解和完全錯誤的行為。

信息的平等，既包括戰(zhàn)略、方向、目標、財務(wù)等大信息，也包括文檔、代碼和知識的共享等小信息。

同樣，平等也表現(xiàn)在意見表達上，任何人都有表達自己的意見和建議的平等機會，這樣才會激發(fā)出更多的思路和思辯，從而才會有更多更好的思路出現(xiàn)。

在 Google，除了代碼全員共享，還有 Thanks God, It’s Friday 的文化，每周五高管們會和員工在一起，面對面回答員工提出的各種尖銳問題；在 Amazon，代碼和文檔基本上對全員開放，包括財務(wù)報表也對員工開放。

另外，亞馬遜所有最牛的 Principle SDE（資深技術(shù)專家）隔三岔五都會有一個 Principle Talk（有很多 Talk 相當令人開腦洞）。

還有 Amazon 內(nèi)部每年會選出一批公司最聰明最有想法的人開會，討論公司下一步的發(fā)展戰(zhàn)略，并可以把相應(yīng)的 KPI 直接傳遞給 Senior VP。

4. 不害怕錯誤。處理錯誤的正確姿勢是分析和總結(jié)教訓，而不是懲罰犯錯人。前者讓人改善進步，后者讓人萎縮不前。工程師最大的錯誤就是不敢犯錯，最大的問題就是不敢直面問題。

5. 寬松的審批系統(tǒng)甚至沒有審批系統(tǒng)。

審批通常暗示著三件事：

對人的不完全信任

繁瑣的流程

思維上的束縛

這些都是創(chuàng)新和想象力的天敵。一個公司的監(jiān)管、審批、流程越重，這個公司的活力也就越差。

6. 20% 的自由時間。這是 Google 提出來的，員工有 20% 自由的時間做自己想做的項目，Gmail 就是這么誕生的。

效率

工程師天生是追求效率的。有人說認為程序員花大量的時間做自動化的工具，還不如人肉的效率高。

比如寫自動化的腳本花 5 個小時，而重復(fù)做這件事 200 次只花 3 個小時。有這樣的理解的人根本不懂工程師和工程。

一方面，這個工具可以共享重復(fù)使用，更多的人可以從中受益。更重要的是，這是一種提高效率的文化，它會鼓勵和激發(fā)出更多這樣的事情發(fā)生。

如果公司管理者因為一個程序員花大量的時間開發(fā)自動化的工具，而認為這個程序員沒有效率，并且對他批評甚至懲罰的話，那么這個管理者就完全扼殺了提高效率的文化。

人類之所以比別的動物聰明就是會使用和發(fā)明工具，而古語也有云：“工欲善其事，必先利其器”。

看看美軍的裝備你就知道戰(zhàn)爭工具的好壞有多重要了，一個公司的強大之處在執(zhí)行力，而執(zhí)行力的強大之處在于你有什么樣的支持工具。這些，已經(jīng)不是工程師文化，而是人類發(fā)展的文化。

對于工程師文化來說，尤其是在軟件工程領(lǐng)域，提升工程效率具體表現(xiàn)在如下七個方面：

1. 簡化。簡化不是簡陋，簡單的東西通常意味著用戶更好理解，也意味著更容易的維護和運維。

就像阿里推行的“小而美”、喬布期推崇的“沒有產(chǎn)品手冊簡單易用的產(chǎn)品”、Amazon 推行的 Working Backwards 里說的那樣。

一個新的產(chǎn)品或功能，產(chǎn)品經(jīng)理需要寫三個文檔：媒體公關(guān)文、用戶手冊、常見問題，三個文檔總共加起來不超過兩頁 A4 紙，且不準用任何圖片說明，目的就是為了讓產(chǎn)品簡化和容易使用。

2. 殘酷無情的推行自動化。編寫程序的最本質(zhì)的目的就是自動化，對于自動化來說，不僅僅只是消除人肉的重復(fù)勞動，更重要的是，很多事情人的力量完全比不上機器。

比如：增加一臺機器，程序運算在秒級就可以完成，而人是永遠不可能達到這樣的速度。

再比如：電商中用程序管理數(shù)量巨大的訂單自動化系統(tǒng)，增加再多的人都不可能像機器那樣完成的又好又快。

自動化需要大力開發(fā)提高生產(chǎn)力的工具，比如：持續(xù)集成，持續(xù)部署，自動化運維，基礎(chǔ)自動化運維，甚至自動化的運營工具。

3.避免無效率的組織架構(gòu)和無效率的管理。

這體現(xiàn)在以下這些方面：

扁平化的組織架構(gòu)。

努力用自動化工具取代支持型的工作。

不超過 10 個人的全棧小團隊。

不按人員的技能分工而是按其負責的產(chǎn)品或功能分工。

開會不是解決問題，開會是表決提案。

通過產(chǎn)品的目標或信條來減少溝通和決策過程。

比如，Amazon 里的每個部門、每個團隊、每個產(chǎn)品都有自己的信條，這個信條標明了要什么不要什么，這樣可以避免很多扯皮和難纏的選擇。

我們來看看 AWS 的幾個信條：運維是最高優(yōu)級的——這意味著只要是會讓運維變得復(fù)雜的需求都可能被工程團隊拒掉。

Throughput & Latency（吞吐量和延遲）不能更差——這意味著功能要為性能讓路，因為性能變差了，用戶就要購買更多的資源。

4.正確的組件抽象。抽象是簡化的一部份，最重要的是，抽象意味著技術(shù)能力的輸出，無論是內(nèi)部的其他團隊還是外部的團隊。

比如：Google 的 MapReduce/BigTable/ProtoBuffer，F(xiàn)aceBook 的 Thrift，還有 Amazon 內(nèi)部的 Web Service 框架 Coral Service、處理日志監(jiān)控的 Timber，以及全線 AWS 產(chǎn)品都用到的 Amazon Lock Framework（一個分布式鎖框架）……

5.開發(fā)高質(zhì)量的產(chǎn)品。因為高質(zhì)量的代碼，不但可以易于修改和維護，還可以因為較少處理線上故障，從而有更多的時間去為未來做更多創(chuàng)造性的工作。

這意味著需要有非常嚴謹?shù)?Design Review，Code Review，以及測試。

6.不斷的提高標準以及招聘最好的人。如果一個公司或一個團隊想變得越來越好、越來越強大的話，就必須要不斷提高自己的工作標準。

提高工作標準意味著要不斷地培養(yǎng)和招聘更好的人才。在 Amazon 和 Google 的招聘系統(tǒng)中都有一個叫 Bar Rasier 的職位，這個職位就是為了提高招聘標準而設(shè)立的。

7.創(chuàng)建一個持續(xù)改善的文化。一個好的組織和團隊，需要全體員工一起不斷反思前進。

在微觀層面上，在項目做完后需要有一個總結(jié)會分析項目中的得失，在故障出現(xiàn)后，需要有故障分析會。

在 Amazon，嚴重的故障需要寫一個 COE（Correction of Errors）的文檔，其中有一節(jié)叫“Ask 5 Whys”，讓你問自己關(guān)于這個故障至少 5 個為什么。

在宏觀層面上，一家公司每年都應(yīng)該做一定的工作數(shù)據(jù)分析或是員工調(diào)查。比如，是否招聘到了不錯的人、工作的投入產(chǎn)出比、員工在哪些地方花費時間等等，然后不斷的用技術(shù)手段來改善。

Amazon 每年的工程師員工調(diào)查表是我見過的最細的調(diào)查表了， 表中的問題除了針對公司、管理層、文化等方面。

還包括日常工作、開發(fā)環(huán)境、持續(xù)集成、測試自動化、產(chǎn)品質(zhì)量、軟件架構(gòu)、軟件維護、線上問題處理、年度計劃、數(shù)據(jù)倉庫建設(shè)、通用工具投票……這個員工調(diào)查直接導致公司對工程的投資方向。

工程師文化如何落地？

如果你要讓一種企業(yè)文化在公司內(nèi)得到執(zhí)行，有下面幾個手段可以選擇：

“政治”手段

招聘、績效考核和升職。比如，你要落地工程師文化中的簡化和自動化，那你在招聘的時候，需要把懂簡化和喜歡自動化的人招進來。

然后在績效考核和升職的地方設(shè)置上一條硬性指標——你今年簡化了什么？自動化了什么？如果沒有，不但不能升職，績效還可能不達標。

“經(jīng)濟”手段

讓不做這件事的成本 > 要做這件事的成本。然后，正常的人類都會選擇成本低的方案。

比如，如果你要推行 Design/Code Review/UT 以提高質(zhì)量，你就把 QA 和 Ops團隊全挪到一邊去，讓 Dev 團隊自己測試，自己負責。

這樣等這些 Dev 重復(fù)多次手動測試，處理多次線上的弱智故障，他們就會自然而然的寫自動化測試和做 Code Review 了。

而 QA 和 Ops團隊只是幫 Dev 你做工具罷了，而測試和運維的事全是你 Dev的 Ownership，出了故障也是 Dev 自己負責。

于是，他們就會發(fā)現(xiàn)，不做 Code Review 和 UT 的成本遠遠大于做 Code Review/UT 的成本，他們就會去做成本低的事了。

最后，工程師文化要落地，還有幾個小條件：

團隊要小，Ownership 很重要，Eat Your Own Dog Food。 沒有人幫你擦屁股，自己的屎自己吃，沒有痛苦，不會產(chǎn)生想進步的動力。

熱愛學習和嘗試。學習嘗試新的技術(shù)，開拓眼界，學習嘗試新的思維方式。否則，原有的思維方式只會讓你在原地打轉(zhuǎn)。

老板更多的相信技術(shù)而不是管理。相信技術(shù)會用技術(shù)來解決問題，而只相信管理，那就只會用制度、流程和價值觀來解決問題。

其他

以上這些是我這么多年經(jīng)歷過或看到的工程師文化，最后說說我的幾個觀點。

996 和加班這件事，對于工程師來說從來都不是問題。在解決技術(shù)問題或是創(chuàng)造的時候，工程師是個很自覺的群體，基本不需要他人驅(qū)動。

我相信幾乎對于所有走上編程這條道路的工程師，基本上都是興趣所至，他們覺得編程很有趣。

但很多工程師卻被一些公司的 996 搞得對編程毫無興趣，為什么？這些公司就是通過考試/KPI/996這些東西把工程師的興趣一點一點的磨滅掉、對學習和工作產(chǎn)生了厭倦和討厭。

另外，文章中我說的這些文化，并不是什么理想主義，而是已經(jīng)被很多成功的公司使用了很多年。

還有人說，因為中國國情不同所以這些方法并不實用，這更讓我費解。中國有全世界數(shù)一數(shù)二的互聯(lián)網(wǎng)用戶，也有全世界數(shù)一數(shù)二的市場，不再是以前那個一窮二白的年代，中國的國情到底有哪些不同呢？

我不知道各位工程師為什么而活著？但我覺得，我們選擇了一個刺激的職業(yè)，也趕上了這個行業(yè)大發(fā)展的時代。

我們不妨捫心自問一下，你是否愿意讓自己的能力、青春和熱情就這樣被磨滅掉？