---

本文章學習自：https://www.bilibili.com/video/BV1cf4y1x7HA

企業真實的研發流程，這個是半路轉行的準程序員和在校大學生都比較關心的問題以及小型公司的程序員也會好奇大廠的流程是怎么樣的。

---

如今互聯網大廠的開發流程，這些流程雖然好，但也不是一蹴而就的，每個公司的體量不一樣流程也不一樣。
從最簡單的流程來看一看這些環節是如何一步一步演進過來的：

---

階段一：

許多客戶只有一個簡單的需求場景：比如：用戶輸入一些數據 根據公式給出分析建議 開發人員直接根據描述完成功能即可;

這套流程弊端很明顯：那就是需求不明確，容易陷入到無限的扯皮中;

明確需求是軟件開發的大樹之根，這點沒有做好，后面所作的一切都沒有意義的。

---

階段二：

初創的外包公司和個人接私活常實行這套流程，最后確認好的需求會寫在合同中，一切按照合同中的需求項進行開發。
需求變更是開發人員最痛苦的事情，所以該環節會隨著流程的完善而不斷升級。

弊端：客戶的需求一般是只有文字描述，在這種情況下，開發人員只是憑借自己想象進行編碼，對需求的理解很容易產生偏差。

---

階段三：

原型圖設計：原型圖就是產品的預覽模型，用于展示產品的最終效果，可以有效的幫助開發人員理解需求。

? 小型的外包公司和個人接私活常實行這套流程，外包公司往往有一個設計師進行原型圖設計。個人接私活，很多客戶也會拿出原型圖，然后讓開發人員進行實現。

? 弊端：代碼編寫完畢后就直接將項目交付了，項目的各個BUG都是在客戶使用中發現的，這時候需要開發人員進行多次修改才能將項目完整交付，和客戶的溝通成本是非常高的，這種形式的交付往往非常耽誤時間。

---

階段四：

? 開發人員實現功能后交由專門的測試人員進行系統測試，測試完畢后由產品進行驗收，驗收無誤才能進行交付上線

• 外包公司：指沒有自己產品的公司，主要承接項目進行開發，需求都是從客戶那邊過來的。
• 產品公司：就是有自己的產品，會對自己的產品開發，運營，迭代，需求是業務部門和產品部門提出的。

這套流程麻雀雖小，五臟俱全，每項流程都有專門的人員負責：

• PM：產品經理。負責需求提出、產品設計
• UE：交互設計師。負責設計頁面布局交互
• UI：視覺設計師。負責產品的具體樣式設計
• RD：開發人員。負責功能實現
• QA：測試人員。負責產品的質量檢測
• OP：運維人員。負責上線審批、維護產品所需要的硬件狀態

各個人員各司其職，當前環節沒有問題后才會推進到下一環節，這時候流程的流轉和推進要進行工程化管理

? 弊端：很多環節在沒有準備充足的情況下就開始實施了，質量得不到有效的保障，不如：確定需求和原型就進行編碼開發，如果在編碼過程中發現技術方案不合理，此時變更會浪費大量的時間

---

階段五：

接下來的流程演進基本就是各個中大廠的流程了，每個環節各個公司的取舍不太一樣

?產品需求評審：需求提出后，產品會拉上各個崗位的人進行產品需求評審，產品經理會將需求項寫好，并且整理出低保真原型圖、產品流程等，讓大家能夠對產品和需求有個概念，PRD在原型圖上進行標注說明，大家根據原型圖進行評審，爭取弄清楚產品和需求的每個細節，并且提出自己的想法，各抒己見。

意見統一后，產品經理確定版本，然后各個崗位進行自己職責內的設計了。

開發人員：

? 概要設計完成后，就要對細節方面進行完善了，這個細節就是指功能的實現思路，比如一個簡單的登錄功能，編碼時就是看著圖開發了，這一塊設計得越詳細編碼時就越輕松，同時測試人員也要對測試進行設計和思考，不然會遺漏功能點。

測試人員：

? 測試要進行測試用例的設計，測試用例可以幫助測試人員理清需求，為后續的測試提供可參考的依據，在測試過程中也可以反應測試的進度。

測試用例：是指需要測試的功能點

設計師：

? 設計師也要進行交互設計和視覺設計，這個環節做出來的高保真原型圖，基本就是產品的最終樣貌。

---

階段六：

? 當開發人員、測試人員、設計師把自己的內容設計完畢后又會湊到一塊進行評審，看看互相對功能理解是否一致，產品經理也會看一下大家對需求的理解程度，避免理解產生偏差，這個環節就是對細節進行完善，改動一般不會太大，該環節完成后就是開發人員進行功能的實現，前后端也會進行聯調，聯調完畢后開發人員會自行測試一番，再交由測試人員進行測試。

? 弊端：再開發環節前做了充足的準備，但沒有在開發環節后做充分的測試驗收，產品上線后質量得不到保障。

---

階段七：

? 在開發完成后，大廠一般會做代碼review，組長和組員會對你的代碼進行審查，在業務和技術都會獲

得很多建議和意見，對開發人員成長最大的環節 。

? 開發人員提交測試申請，將代碼交給測試人員發布到測試環境進行測試，因為測試的周期比較長，測

試環境沒有問題后就可以將代碼分支合并然后由測試人員發布到預發/沙箱環境。

? 沙箱環境：將系統接入真實的數據，但是系統只能內部訪問，用戶無法直接訪問的，這個環節就是為

了保證上線前不出問題，所以模擬線上真實環境，看看系統能不能真的抗住真實數據，這一輪測試完成

后又可以將代碼分支合并一次然后讓產品經理驗收。

總結：

? 從需求提出到需求結束還是很不容易的，中途歷經多個環節要和多個部門崗位協調各種問題和難點都要面對，每個公司會根據自己的文化和人員配置業務方向以及需求大小做出調整，比如一些小的需求小的改動概要設計和詳細設計就不會做了。

? 流程的最終目的是為了節省時間成本和人力成本，并且提高產品的質量，符合公司實際情況的才是好流程，小公司盲目采用大公司的流程反而會增加溝通成本，大公司明明流程老舊也不進行改進和變動，技術負債就會越來越多。