科普一下正式的大廠需求開發流程

大多數人認為的程序員，也就是很多人眼中的技術開發人員（前端或者后端），他們就是整個項目開發過程中的主力人員，此外就沒什么其余人了。

但其實，一個需求從提出到開發再到測試，直到最后上線，是需要幾波人共同努力的，而不是像很多外行理解的只需要程序員這種個角色就可以搞定的。

今天阿秀就根據在前司字節以及現司SAP的工作經歷科普一下互聯網公司一般常見的需求開發流程有哪些？會有哪些人參與到？

新手朋友們可以稍微了解下大致流程有哪些，尤其是一些在校的學生粉絲們提前了解了解。

先科普一下常規的互聯網公司的需求開發中的三種角色以及三種環境：

三種角色分別是產品經理、研發和測試，在下文中也會使用PM、RD、QA來做簡稱；

而三種環境依次是開發環境、測試環境和生產環境，有的還會在測試環境和生產環境中再加一個模擬生產環境做數據隔離和真實演練。

三種角色

1、產品經理(Product Manager/Project Manager)，縮寫為PM：產品經理是在產品的研發過程中，負責調查并根據用戶的需求制定出一套方案的相關人員。

2、研發(Research and Development engineer)，縮寫為RD：研發一般分為前端開發工程師或者后端開發工程師，比如C++后端開發工程師、Java后端開發工程師、Golang后端開發工程師等都屬于RD，他們是把功能具體實現出來的一撥人，也是網上各種程序員相關段子調侃的主要對象。

3、測試(Qualtiy Assurance)，縮寫為QA：QA的主要職責就是質量保證工作，也就是很多人口中俗稱的測試，負責對RD實現的功能進行檢測，保證該功能在上線后能夠正常使用。

三種環境

1、開發環境

開發環境主要指研發進行功能開發的環境，其實就如同大家在自己的筆記本或者臺式機上寫程序一樣，這就是開發環境。

而大廠中用什么工具開發要看具體的組了，有些組選擇用統一型號的筆記本進行開發；也有些組會選擇使用開發機來進行開發。

這里一般是要求組員的開發環境都是一致的，比如大家都使用Window來進行開發，或者都用Mac進行開發或者開發機的型號也是一致的，為的就是減少可能因開發環境不一致而引發的BUG。

不要小看這個環境問題，很多莫名其妙出現的問題，最后排查下來都是由于環境不一致導致的。

2、測試環境

測試環境主要指的是測試人員進行功能驗收和檢測的環境，在正式上線前都會在這個環境中進行模擬功能的檢測。

這個環境一般臟數據會比較多，有時候為了模擬真實的線上環境，甚至要從線上數據庫copy數據到測試環境中去。

3、生產環境

生產環境就是廣大真實用戶使用的場景，也有的管它叫線上環境。這個環境是最重要的，因為一旦出事就是線上生產事故，需要立馬進行處理的。很多人看到的"程序員需要24小時 on call"的段子就是為了防止生產環境出問題。

不過有的比較講究的部門會在測試和生產環境之間再加一個生產隔離環境，比如涉及到支付、電商這樣跟錢強相關的部門。測試人員在測試環境中將需求測完無誤后，再發生產環境之前會現在生產隔離環境中走一遍，確認無誤后再正式上線。

下面我用一個很常規的功能：網站的登錄功能，來介紹下一個需求的正常開發流程是怎樣的，是如何從構思到實現再到最終上線的，而在這其中又會使用哪些工具？涉及到哪些人？

需要說明的是不用公司流程可能有略微差別，這里主要介紹的是比較常見的需求開發迭代過程。

1、產品調研

一個需求的起點應該是產品經理，也就是PM。

產品把調研結論寫成一頁紙"決策記錄"，附原型圖和指標公式，拉研發、測試、設計、運營、法務五方會審。

通過標準：指標可量化、技術風險可控、法務無否決。

評審表全員電子簽名后，需求池上鎖，任何人再加需求必須走"變更流程"，否則研發有權說"不"。

2、技術方案與評估

研發負責人3-7天內給出技術方案：

• 時序圖：用戶→網關→登錄服務→風控→消息中心，每一步超時閾值標清楚；

• 接口定義：字段、碼值、限流閾值、降級邏輯；

• 數據變更：索引新增、歷史數據遷移腳本；

• 灰度策略：按用戶尾號分批，開關在配置中心，秒級回滾。

技術方案評審需要安全、性能、測試三方拍桌子，問題全部落地，研發才準開工，否則打回重新進行。

3、測試用例

測試同學拿到產品和技術組長的文檔后寫出"用例腦圖"，分功能、異常、性能、兼容四類，一鍵導入自動化平臺，等待研發人員將項目上線到測試環境中再開工。

4、正式開發

研發組長重新起一個會，簡單過一下需求，將需求分給組員，每個人負責1-2個需求。

其中研發人員統一用公司鏡像，本地一鍵起 Redis、MySQL、網關；

在代碼主分支上重新拉分支，一般是從master或者main分支重新開分支。

分支合并請求必須滿足以下下三條：

• 單測覆蓋率≥90%

• 靜態掃描零阻斷

• Code Review 兩人及其以上同意才可以發布。

每日晨會 15 分鐘，對齊需求進度，如果延期以及無法按時交付的話，組長需要馬上協調資源。

在組員全部開發完畢后，開發小組內部會約定一個時間一起合并代碼，簡單自測一下沒什么問題才會發布到測試環境中。

然后通過測試人員開始測試。

5、開始測試

接口層用腳本壓 1 萬并發，UI 層用瀏覽器集群跑 20 條主流程； 同時把線上真實數據脫敏后灌入測試庫，造出 500 種"臟"組合，提前發現邊界 Bug。

嚴重 Bug 未清零，測試人員將版本打回，研發重新開工，直至全部功能確保無誤。

6、灰度發布

先推 10% 用戶，監控看三行數字：成功率、延遲、錯誤率，任一紅線飄升，自動觸發回滾，5 秒內切回老版本。

灰度 24 小時無異常，全量放開；期間運營在后臺看實時漏斗，確認指標達標才簽字畫押。

7、線上觀察與復盤

上線后 7 天持續監控，數據落到統一報表：登錄成功率從 71% 提到 89%，驗證碼攔截量下降 38%，算是達到預期。

若出現事故，按"1-5-15"原則處理：1 分鐘發現、5 分鐘定位、15 分鐘恢復；

事故等級定級后，48 小時內開復盤會，產出"教訓清單"，Wiki 永久留存，下次評審先檢查舊賬是否閉環。

上面7個流程是大多數稍微正規點的互聯網公司在開發新需求都會經歷的七個步驟，有的可能更復雜，有的可能會精簡某些環節。

像我就知道有個互聯網中廠某些部門都是野路子開發，產品全程就一句話，啥文檔都不提供的，研發有問題只能去問，就這樣口口相傳，出問題了就相互甩鍋。

不要覺得不可思議，這個世界確實是個草臺班子哈哈。

越是正規的公司，在上線新功能的時候就越嚴謹。需求不是簡單"寫代碼"，而是把"一個想法"拆成可驗證、可回滾、可量化的七步流水線，每步都有門禁和責任人；

流程是速度的朋友，不是敵人—它讓幾百人能在同一節奏里快跑而不翻車。

來源 | 拓跋阿秀（ID：coder_Axiu）

作者 | 阿秀 ; 編輯 | 呼呼大睡

內容僅代表作者獨立觀點，不代表早讀課立場