上一篇文章討論了一下工程師的成長，不斷提升工程師們的效率。但是工程師是否能安心，順利的成長，依賴於公司或者部門這個大環境，依託於研發體系這片土地是否具備足夠的營養來滋潤。萬丈高樓平地起，建設一支充滿戰鬥力的研發團隊的前提是，我們的技術生態是健康和可持續的。本文就根據我過去多個團隊積累的一些經驗，來嘗試梳理一下。
為了讓這個問題的討論能有一個可視的畫面感，我就先對比列舉一下，低效研發體系 VS 高效研發體系之間的區別，大家都可以腦補一下你所在公司或者團隊的情況是否和以下的情況一致：
•低效研發體系：把技術團隊簡單當資源使用，簡單的任務派發。為什麼要做這個需求，需求的價值是什麼一概不知。
•高效研發體系：讓技術團隊覺得是在一起做一件有價值的事, 討論清楚需求的前因後果。每次需求上線後，需求的效果有完整的資料跟蹤，根據資料來總結本次專案的得失。
•低效研發體系：業務，產品和技術的觀點不在一個維度上：業務的觀點在業務擴充、收益上；產品的觀點在需求、產品功能上；技術的觀點又在產品特性，功能實現上。
•高效研發體系： 大家都聚焦在一個點上：”SHOW ME THE MONEY”，大家的溝通思路都圍繞在提升產品收益或者降低營收成本，技術的所有工作都應該緊密圍繞“提升收益”和“降低成本”這兩個方向。
•低效研發體系： 需求評審會上，業務和產品唱“獨角戲”，技術同學沒有自己的想法。
•高效研發體系： 在需求評審會上，產品和技術會明確需求是否完整，確認產品功能的正常場景，是否形成閉環；異常場景的處理流程；產品細節是否考慮周全。
相信大家看過後，心裡都會有自己的一份感受，當然，這和你所在的公司的文化和背景有關，更與技術所對應的業務有緊密的聯絡。簡單來說，一個高效研發體系是否能完整的落地，一方面是技術團隊內部的不斷建設和演進，另一方面也需要大環境和各個團隊的配合和支援。
拋開外部環境不談，對於一個高效的研發體系，我們可以做一些什麼，在這裡，我列舉一些共通的基本特徵，為了清楚明瞭，按照一個標準專案的流程來談：
•在需求階段，深入討論為什麼做這個需求，這個需求的價值是什麼？最終配合產品產出一份滿意的需求評審文件。
•在開發階段，開發和測試小組，並行輸出技術方案和測試用例，技術方案中，包含系統的互動協議和介面定義，所涉及系統的一個overview, 並梳理開發對業務的理解，確保和需求一致。建立提測標準，測試產出核心用例交給開發自測。開發完成自測，再提測，避免普通體系中，開發寫完程式碼就提測，再被測試打回，反覆多次。
•在測試階段，建立自動化釋出，測試和迴歸是有時間約定的，形成節奏感。每天執行2~3 輪測試，開發專注於修復bug，測試集中測試，減少了不斷提測、部署環境浪費的時間；至少建立介面級別的自動化迴歸測試，確保所有的API都能正常執行。
•在釋出階段，建立預釋出環境、分批發布和灰度釋出，釋出完成後，開發和測試會線上上進行必要功能的驗證，並持續觀察線上訪問日誌，確保上線後功能完成沒問題。如果有問題，可以迅速回滾到上一版本，避免造成線上故障。
研發團隊的建設圍繞著人來展開，通過研發體系這片土壤讓工程師們能高速成長，反過來，“成熟”的工程師們再不斷耕耘這片土壤，讓土壤更加的肥沃，形成一個完美的生態。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
