點擊▲關注 “中生代技術” 給公衆號標星置頂
更多精彩技術內容 第一時間直達
本週連續做了兩場演講，基本思想都是從技術團隊的工程師文化入手，談談如何提升效率與度量價值。下文是我對演講內容的總結，限於篇幅，還有許多未盡之意，期待能和朋友們有更多的交流。
差不多在10天前，我受邀在極客時間部落發起了一個討論。
談到工程師文化，有的人說自由、有的人說協作、有的人說溝通，有的人說好的職業素養，有的人說是追求精益求精。其實這些都對，那麼什麼是工程師文化呢？
參考文章：如何打造高效團隊？
在理解這個問題之前，我們先看看時代的變遷，以及行業的發展。在過去的200多年間，人類經歷了三次工業革命，如今正邁向第四次工業革命。
第一次工業革命，我們有了蒸汽機，開創了以機器代替手工勞動的時代；第二次工業革命，福特把流水線做出來了，有了流水線之後，人類正式進入了工業社會。中國在第三次工業革命（信息技術革命）中的表現是非常突出的。舉個金融科技的例子，現在大家出門都不帶現金。如果錢包被偷了沒關係，手機被偷了就很麻煩。
前幾次工業革命的意義在於極大地提高了生產力水平，從而改變了文化，經濟與生活。第四次工業革命則提供了無限可能：全新的思維方式；全新的生產力、生產方式；全新的生產者和全新的知識獲取途徑。數字化將會是這個時代的重要特徵之一。
我們再來看看行業的發展。
這個世界上有三種商業公司：
銷售驅動型的公司。這類公司以運營和營銷見長。技術對於他們來說，更多的是爲了支持大規模的營銷活動，以及成本上的控制。
產品驅動型的公司。這類公司以創造能提升用戶生活體驗的產品見長。技術對於他們來說，除了支持大規模的在線用戶之外，他們會更多地去尋找那些爲了增強用戶體驗，提高整個業務流程效率的技術創新。
技術驅動型的公司。這類公司希望通過強大的工程技術來創造有顛覆性的東西，用各種自動化的技術取代體力勞動。比如：近代的蒸汽機技術取代了大量的人工，數字技術讓線下走向了線上。
這三種公司都需要強大的技術支撐。我們今天的生活相當地依賴程序員，沒有程序員，我們恐怕都不知道如何生活了。
所以時至今日，每個從事軟件行業的技術人員都應該感到幸運。我們不但選對了行業，也生活在了正確的時代，可以感受到前所未有的刺激和變化。所以，我們只需要思考一個問題：我是否在正確的地方用正確的方式做事？在這個背景下，我們再來理解工程師文化，也許可以快速達成共識：工程師文化不是一個問題，而是一個常識。
簡單說來，我把工程師文化歸納爲兩個方面：“效率” 和 “價值”。
效率：建設團隊空間，提升團隊效率
Martin Fowler在他的博客（Team Room）中介紹了對敏捷開發團隊所應採用的“團隊空間”的觀點。在物理上，我們通過可視化的設備、Always On這樣的工具、以及大量的白板爲高效協作提供支持。設備、工具的推廣和使用，是“術”的層面。
除此之外，團隊契約的建立也很重要，比如PIPELINE的提交紀律。
利用團隊空間，鼓勵團隊更多地學習和分享也是提升效率行之有效的方式。下面舉兩個具體的例子:
Session牆：團隊初期，要求團隊成員頻繁地做session，在團隊內部逐步形成學習和分享的氛圍。一段時間後，不僅有人願意分享，而且有人主動喊出想要知道某方面的知識。於是爲了將知識分享的供需可視化，可以建立一個session牆，分成兩部分，一邊由團隊成員寫出來想要了解的技術知識，相當於是session的需求方；另一邊寫着根據需求而安排的session，相當於是session的提供方，這樣清楚明瞭，便於跟蹤。在項目不同階段，session的內容也會有差別：比如早期的session主要是關於項目中用到的技術，目的是爲了快速學習和掌握必要的技術以便順利進行開發。
成熟的學習型團隊還會通過“有意注入錯誤的方式”來有意識的進行組織學習。比如奈飛會注入“數據庫不可用或者雲環境不穩定等錯誤”到生產環境， 讓團隊從錯誤中學習。
技術能力雷達牆：可以利用“技術能力雷達牆”來標明項目相關的各種技術，評價當前的團隊技術能力狀態，並且設定每個里程碑的能力成長目標，到了一定階段再來評價團隊技術能力是否達到了目標。
參考閱讀：《團隊空間：敏捷團隊的辦公室設計》
建立團隊契約，利用Session牆和技術能力雷達牆來促進學習和分享，這是“法”的層面。
工程師天生是追求效率的。有人認爲程序員花大量的時間做自動化的工具，還不如人肉的效率高。比如，寫自動化的腳本花6個小時，而重複做這件事200次只需3個小時。有這樣想法的人根本不理解軟件工程。因爲一方面，這個工具可以共享重用，更多的人得以從中受益：這次我花6小時開發這個工具，下次只用1小時修改後就可以用在別的地方，這是着眼於未來而不是眼下的成本。
更爲重要的是，這是一種提升效率的文化，它會鼓勵和激發更多類似的事情發生。如果因爲一位程序員花大量的時間開發自動化的工具，而認爲這個程序員沒有效率，對之批評甚至懲罰，那麼我們就扼殺了提升效率的文化。塑造提升效率的工程師文化，這是“道”的層面。
價值：關注研發效能，保持技術精進
研發效能的本質是持續的價值流。在軟件開發中，價值流的直接體現是從想法和假設到軟件功能上線併產生客戶價值的過程。
從左到右的流水線這一理念來自於製造業，爲了讓流水線儘可能快，生產週期可預測，製造企業通常會聚焦在如何讓流水線更平滑，因此一些顯而易見的手法經常被使用：比如減少在製品（WIP)；儘可能早地發現次品，從而阻止對下游生產步驟的影響。很多理念和實踐在軟件行業也是通用的，然而一個巨大的區別是：製造業流水線是物理可見的，軟件開發活動則要抽象得多。軟件開發活動本質上是複雜的系統工程，複雜系統中的事務都是相互交織在一起的，帶來的問題是一個異常發生後很難界定其影響範圍並快速分析根因。
人類應對複雜系統最有效的手段是探索和反饋，因此，從左到右流水線的每一步反饋就尤爲重要：也就是說，我們不僅需要從左到右的流水線，還需要在這個流水線上構建從右到左的反饋，而每個環節的指標收集是從右到左反饋的基礎。
管理學之父德魯克曾經說過：“如果你無法度量它，就無法改進它。” 4 Key Metrics是行業內接受度很高的度量能效的指標：通過這樣的度量指標，使得從左到右流水線的每一步都能得到評價和預測。
部署頻率
對於您正研發的主要應用程序或服務, 您部署代碼的頻率如何？
交付前置時間
對於您正研發的主要應用程序或服務, 您的交付前置時間如何（即從代碼提交到代碼成功在生產環境中運行需要多長時間）？
平均恢復時間
對於您正研發的主要應用程序或服務, 在發生線上事故後（例如，計劃外宕機、服務受損）通常需要多長時間才能恢復服務？
變更失敗率
對於您正研發的主要應用程序或服務, 多大比例的變更會導致服務降級或變更後需要採取補救措施（例如，導致服務受損、服務中斷、需要部署修補程序、需要回滾變更）？
在DevOps橫空出世之前，開發團隊和運維團隊是對立的，其KPI也是對立的，這點在《鳳凰項目》中有很多生動的故事。對開發團隊來說，快是其KPI；對運維團隊來說，穩是其KPI。快和穩看起來是對立的，比如運維團隊爲了服務穩定，希望發佈的頻次儘可能低。因此4 Key Metrics給我們的第一個啓發是：打破研發和運維的“牆”，快和穩得以通盤考慮。
第二個啓發：4 Key Metrics能夠讓團隊的技術治理更有方向性，如果某項技術治理對於快和穩沒有幫助，那麼說明團隊投入的工作量沒有給客戶帶來價值。這樣的技術治理很有可能就是自嗨。
關注度量指標的變化，分析其變化的原因。通過持續不斷地設置更高的目標，以此來牽引團隊研發效能的提升。這是4 Key Metrics給我們的第三個啓發。
寫在後面：刻意練習
《一萬小時天才理論》一書中針對“刻意練習”講到了三個觀點：精深、激情、伯樂。第一，要想在某一方面有所成績，需要有精深的練習。這裏說的不是普通的練習，而是有效率的刻意練習；第二，有對這件事情持之以恆的激情，無論外界如何變化，激情一直都在；第三，要有賞識我們的教練給予指導，給予及時、精準的反饋，這樣可以讓練習更加高效。個人認爲，無論是提升團隊效率的“道、法、術”，還是以“4 Key Metrics”爲綱的效能度量，唯有堅持刻意練習，方能持續產生價值。
中生代技術社區提供內推服務，對應以上大廠，直接對接到用人部門，高效快捷
有需求請添加羣合夥人大白的微信
申請備註（姓名+公司+技術方向）才能通過哦！
一個思維習慣，讓你成爲架構師
END
#接力技術，鏈接價值#
轉發朋友圈，是對社區最大的支持。