鄭昀 創建於2014/11/10
關鍵詞：財富觀、對題集、一票否決、業務收斂、持續集成、預研、培訓、公開演講、傳承
本文檔適用人員：研發幹部
提綱：
- 研發財富觀——問題和事故都是財富
- 擠出人力做預研課題
- 減少痛苦和抱怨——持續集成
- QA一票否決
- 風險收斂——關鍵業務邏輯收斂到業務中心
- 技術分享和職場培訓並行
0x00，我們一定做對了什麼，當然，也做錯了很多
話說曾鳴教授曾曰過，
什麼叫戰略？
——做對了一定會有好結果。
什麼叫執行？
——中間的苦，一步也少不了。
對於我們而言，經歷了多年的血雨腥風，勉強算是屹立不倒，肯定是做對了某些事情，當然做錯的可能更多。
對於事故處理，航天有二十字訣：定位準確、機理清楚、可以復現、措施有效、舉一反三。
我們從 2011 年開始，一直堅持每錯必查、錯了又錯就整改、每錯必寫，用身體力行告訴每一個新員工直面錯誤、公開技術細節、分享給所有人，長此以往，每一次事故和線上漏測都會變爲我們的財富。這就是我們的 RCA（Root Cause Analysis）制度，截止到目前已經收集整理了近兩百個詳盡的 RCA 報告。
54chen 曾經說過：
如果在你的公司裏，故障報告與工資是掛鉤的，恭喜你，制度用錯了。 故障報告的本意，是讓發生的故障告訴所有的人，讓所有的工程師都學到，這次故障的起因是什麼、如何避免。 故障報告絕對不是用來懲罰和警告你犯錯了。
是的，熟知一千零一種死法，還會讓我們變得每逢大事有靜氣：靠，老子什麼沒見過。
0x02，擠出人力做預研課題
職場潛規則裏我講過，一定要低頭拉車擡頭看路。
最開始我們怎麼擡頭看路呢，那就是看淘寶等技術團隊這麼多年都怎麼過來的，他們在不同階段都在解決什麼問題。
馮侖說過，我們要把別人的歷史當作自己的未來，這樣，才能知道過去人家在做什麼，我們現在應該怎麼做。
於是，從2013年開始，我們抽調寶貴的研發人力，去做 JobCenter、NotifyServer、Tracing 等研發解決方案或中間件，花精力去改造 Dubbo、Cobar 等開源系統，做完這些還需要見縫插針地分批分期內部推廣。
但這些提前量都是值得做的，否則我們很可能做着做着就“死做做死”了。
0x03，減少痛苦和抱怨——持續集成
每逢業務大躍進，就會欠下一屁股技術債。
是債就要還。
酷殼陳浩說過，技術債是不能欠的，要殘酷無情地還債。很多事情，一開始不會有，那麼就永遠不會有。一旦一個事情爛了，後面只能跟着一起爛，爛得越多，就越沒有人敢去還債。
首當其衝的就是線下多套環境和線上多套環境的維護和發佈，大把大把的時間浪費在這上面，一代又一代的工程師在離職時表達了憤懣情緒。
於是，從2012年開始，我們開始了持續集成第一季整改，萬事開頭難，這一干就是一年。第二季 CI 做完後，至此，主營業務線做到了線下自動化編譯、自動化部署、自動化測試（日檢），做到了線上自動化上線和回退。
第三季 CI 主要是讓前端（CSS/JS/Images）也接入自動化上線體系，2014年年內完成。
當然，這些還不夠，離我的研發哲學所言"Don't make me think"還有很長的路要走，還得跟隨容器虛擬化鬧革命。
0x04，QA一票否決
在這裏，QA 的話語權很大，說你質量不達標，就是不能上線。線上運維部對接 QA 的配置管理組（CM）。
當然，最開始可不是這樣，在業務部門的壓力之下，在業務部門爲我們鎖定了 Deadline 的情況下，即使版本帶着傷，也得上。忘了從 2011 年哪天開始，終於撥亂反正：QA 的 CM 規劃版本，QA 對線上質量保障負責，上線日期以 CM 輸出爲準，業務部門可以提出意見建議，但無權要求上線日期。
這樣，CM、DBA、SA 作爲上線發佈的看門人，用非黑即白的規則倒逼上游的研發、產品、需求方改變。
0x05，風險收斂——關鍵業務邏輯收斂到業務中心
可能本來就該這麼做，業務收斂，避免不同 IT 系統對數據增刪改查，引入髒數據風險，埋下各種隱患。
當然，因此會導致中心化，會讓一些業務中心變爲整個系統的瓶頸，非常容易導致系統雪崩。歷史上也確實多次發生過此類災難性場景，某個業務中心阻塞，導致上游工程受影響，全站被迫業務降級。
在2011年年底，趁着一個大項目，我們把業務收斂的重構需求揉進去，導致了項目進度的嚴重不可控。但現在看來，這也是躲不開的苦。
54chen 曾就 Java 的積重難返曰過：
曾在一處見到，淘寶在長期使用 java 構建 web 項目後，得出一個結論：積重難返。
實際工作經驗得到的結論，積重難返的原因，往往不是 java 本身的緣故，而是團隊成員基礎積累參差不齊，許多次的“一不小心”積累成了最終的結果。到了悔之晚矣的時候自然就積重難返了。如何避免 java 使用自傷，最關鍵在於，統一團隊成員的 code 入口，框下可能發生的事情，避開不能發生的事情。
對於一個快速發展起來的技術團隊，統一團隊成員的 code 入口，框下可能發生的事情，最簡單的就是業務收斂，商品、門店、商戶、用戶、訂單、支付、庫存、積分、評價、優惠……，甚至有時候連查詢都框起來。
0x06，技術分享和職場培訓並行
首先，一個所謂有技術傳承的技術團隊，註定需要大量的定期的技術分享講座，爲什麼呢？
因爲企業的研發管理應該注重建立一個良性的循環：- 研發能力的提升，有助於促進研發效率的改善；
- 研發效率的提升，使得研發人員可以有更多的空餘時間，進而激發更多的研發活力；
- 研發活力的提升，研發人員積極交流與分享，有助於提升研發人員的總體能力。
過去的軟件開發方法論，往往只是注重了研發管理中的一兩個方面，缺乏整體視角，常常期望以一套方法論包打天下。事實上，真實情況下的研發管理，需要至少三套方法論：
- 提升研發能力，主要依靠經驗積累，建立企業內部的知識庫與傳承體系（促進交流與協作，藉助研發活力促進研發能力提升，也很重要）；
- 提升研發效率，主要依靠科學的數據分析，建立或引進一系列的研發工具，建立合理的流程與制度（通過提升研發人員能力，激發他們不斷改進效率，也很重要）；
- 提升研發活力，主要靠多種社會化的溝通機制，促進分享與交流（給研發人員鬆綁，讓他們有足夠的空餘時間，也很重要）。
（注：以上闡述來自於莊表偉）
綜上，爲了激發研發活力，需要多管齊下，至少我們應該做到：
- 定期舉辦技術分享講座，當研發人員足夠多，方向足夠廣時，Topic 還是很多的；
- 爲了開講座，需要給主講人預留出一定的準備時間；
- 爲了讓大家有研究有思考有實踐，不能把人全陷在具體業務邏輯開發上，不要過分追求低費率和性價比，明明10個人的活兒非讓5個人幹，最後活兒也屢屢延期，一年到頭開發組織也沒進步。
其次，研發工程師要能夠清晰表達。別人聽不懂，多半是因爲你講不清楚，你講不清楚，往往是因爲你本來就沒想明白沒聽懂，自然也就沒邏輯。
所以，我們需要從入職之後就有意識地訓練大家，讓大家能夠公開陳述、清晰表達。所以，試用期內，新人必須做一次技術分享和一次技術評審，面對各方的 challenge。
第三，面向中層幹部，我們不定期做職場培訓，截止到目前已做了十期培訓。
純銀曾曰過：一家公司戰鬥力的強弱，取決於中層裏邊，有多少業務精英，而且是本部門核心業務的精英出身，不是其他業務領域的精英升中層然後調動過來。這是一個相當粗暴的判斷，中層本人的業務技能水平極大地影響整個部門的戰鬥力。
本部門業務精英也是從五湖四海彙集來的，工作習慣、方式、話術、意識不盡相同，所以需要通過重複重複再重複、CheckCheck再Check，來矯正錯誤行爲，並指明什麼是正確的行爲。
最後，我們的中層幹部終究有一天將成爲領軍者，組隊單幹，還有不少員工離開後成爲創業公司的技術合夥人。這些人需要用技術分享來構建專業技術形象。再引申一層，我們的幹部在大公司裏也千萬不要放棄對自己核心技能持續磨練。什麼是核心技能？談商務，公衆演講，出方案，畫原型，寫代碼，部署，維護，培訓員工……
小結：對題集
我們不能只是爲了不白交學費而整理錯題集，還需要梳理過去幾年我們做對了哪些事情，讓正確的行爲一代一代傳承下去。
-EOF-