前言
無論是半路轉行的準程序員，還是正在讀書的大學生，大家都比較關心一個問題：「企業中真實的研發流程是怎樣的」。有一些在小公司的程序員，也會好奇大廠的研發流程。
為什么這么多人關心研發流程呢，因為一個合理完善的流程代表著穩定、高效。一個公司有了好的流程，就能極大節約人力成本和時間成本；一名開發人員體會了好的流程，就能極大鍛煉自己的項目 / 代碼掌控能力。
本文就和大家分享一下，如今互聯網大廠的研發流程。
大廠流程雖好，但也不是一蹴而成。每個公司體量不一樣，流程也不一樣，我們就從最簡單的流程講起，看看這些環節是如何一步一步演進過來的。
流程演進
草臺班子
這套流程非常簡單，從需求提出到需求結束就只有一個「開發」環節。
該流程可以說是沒有流程，往往只會在「個人接私活」中這樣做。我曾經接私活，許多客戶只有一個簡單的需求場景，比如「用戶輸入一些數據，根據一定公式給出分析建議」，像這種程序，開發人員直接根據描述完成功能即可。
流程弊端：
需求不明確，容易陷入無盡的「扯皮」中。
用戶一開始要的是 A 功能，你做出來后，客戶改口說要的是 B，那么你之前做的就白費了。
所以，明確需求是軟件開發的大樹之根，這一點沒做好，后面所做的一切都沒有意義。
明確需求
「初創的外包公司」或者「個人接私活」常實行這套流程。
該流程多了一個「需求確認與分析」環節，顧名思義，這一環節主要是對用戶提出的需求進行確認和分析，最后確定好需求是會寫在合同中的，后續一切按照合同中的需求項進行開發。
這個環節上限極高，下限也極低。做得好，自然能夠很大程度上避免用戶反復無常；做得差，需求不明確，依然會讓開發人員返工。
需求變更是程序員最痛苦的事情，所以該環節會隨著流程的完善而不斷升級。
流程弊端：
客戶的需求一般就只有文字描述。這種情況下，開發人員只是憑借自己的想象進行開發，對需求的理解容易產生偏差。
原型
原型圖就是產品的預覽模型，用于展示產品的最終效果。
原型圖分為低保真原型和高保真原型。
低保真原型就像草圖，用于快速向客戶或者開發人員展示產品效果，方便修改和調整。
高保真原型基本就是產品的最終效果了，而且還會有交互效果（就是頁面可以點擊等操作），前端開發人員可以直接按照原型圖進行頁面開發。
「小型的外包公司」和「個人接私活」常實行這套流程。
外包公司的話往往會有一個設計師進行原型圖設計。
個人接私活的話，很多客戶會直接給你原型圖，他們一般是請外包設計師畫出效果圖，然后再請我們開發人員進行開發。
流程弊端：
開發完畢后就直接將項目交付了。
項目的各個Bug都是客戶在使用過程中發現的，這時候需要開發人員修改很多趟，才能將項目完全交付出去。
要知道，客戶不是專業人士也不是你的同事，溝通起來成本是非常高的，這種形式的交付會極其耽誤時間。
曾經我接的一個私活，工期是一個月，但是來來回回更改細節和缺陷，拖了三四個月，身心俱疲。
測試驗收
開發人員實現功能后，就會交由專門的測試人員進行系統測試，測試完畢后由產品進行驗收，驗收無誤才能交付/上線。
「中小型的外包公司」和「小型的產品公司」會實行這套流程。
外包公司，就是指沒有自己產品的公司，主要承接項目進行開發。需求都是從客戶那邊來的。
產品公司，就是指有自己產品的公司，會對自己的產品進行開發、運營、迭代。需求是業務部門、產品部門提出的。
這套流程麻雀雖小但也五臟俱全，各個環節都有對應的人員負責：
- PM：產品經理。負責需求提出、產品設計；
- UE：交互設計師。負責設計頁面布局和交互（交互就是產品的操作邏輯，比如點擊這個按鈕會彈出什么提示框）；
- UI：視覺設計師。負責產品的具體樣式設計（視覺就是產品的現實效果，比如這個圖標長什么樣），UE 和 UI 很多時候是一個人；
- RD：開發人員。負責功能實現，主要分后端、前端、客戶端開發人員；
- QA：測試人員。負責產品的質量檢測；
- OP：運維人員。負責上線審批、維護產品所需要的硬件狀態。
每個人員都各司其職，對自己所處的環節會進行把控，當前環節沒問題后才會推進到下一個環節。
這時候流程的扭轉與推進，不是口頭上說一下就行了，而是要進行工程化管理，每個環節都要經過特定步驟才能推進到下一步，比如發送郵件。
現在有許多協作工具/平臺，可以讓我們非常方便地管理流程。比如騰訊推出的 TAPD：
流程弊端：
雖然該流程已初具規模，但還是很粗糙，每個環節都有完善的余地。
很多環節在沒有準備充足的情況下就開始實施了，質量得不到有效的保障。
比如確定需求和原型后，開發就直接編碼，如果在編碼過程中發現技術方案不合理，此時要變更，就會浪費大量的時間。
所以，在實現功能前，應該進行一系列的設計與評審。
開發前的準備
接下來的流程演進，基本就是各互聯網中大廠的流程了，每個環節可能各個公司的取舍不太一樣，不過差別不是太大。
這套流程主要體現了功能實現前的一系列環節，這些環節做得越好，功能實現得也就越快越好。
產品需求評審
需求提出后，產品會拉上各個崗位的人進行產品需求評審，交互/視覺設計、開發、測試都會拉上。
產品經理會將需求項寫好，并且整理出低保真原型圖、產品流程等，讓大家能夠對產品和需求有個概念。
這時產品經理整理出來的叫做 PRD 文檔，內容大概如下：
每個公司都不一樣，也不一定要寫出文檔一條條列出來，現在許多時候是直接在原型圖上進行標注說明，然后大家根據原型圖評審。
各個崗位會爭取弄清楚產品和需求的每個細節，并且提示自己的想法，各抒己見。比如某個需求實現成本太高需要重新考慮、某個需求不合理需要改進等。
這個過程會花費比較長的時間，意見統一后產品經理會確定版本，然后各崗位就要開始進行自己職責內的設計了。
首先是開發人員，要進行概要和詳細設計。
概要設計
概要設計就是開發方案設計，比如模塊怎么劃分、技術如何選型、數據模型如何設計等。
這一塊主要是對整個項目進行一個大概的設計，切記在該階段對業務流程、細節實現過多糾結，這些都是詳細設計的事。
詳細設計
概要設計完成后，接下來就可以對細節方面進行設計了。
這個細節就是指功能的實現思路，比如一個非常簡單的登錄功能是這樣的：
編碼時基本上就是看著圖開發了，設計得越詳細，編碼時就越輕松。
測試用例設計
開發人員需要對編碼進行思考和設計，測試人員也要對測試進行思考和設計，不然到時候想到哪測哪，容易遺漏功能點。
測試用例就是指需要測試的功能點詳情，這個功能點應該怎樣測試、前置條件是什么、預期結果是什么，等等。
測試用例可以幫助測試人員理清需求，為后續的測試提供可參考的依據，在測試過程中也可以反映測試進度。
交互/視覺設計
同時，設計師也要進行交互和視覺設計。
這個環節做出來的高保真原型圖，基本就是產品的最終樣貌了。
綜合評審
當開發人員、測試人員、設計師把自己的內容設計完畢后，大家又會湊到一塊進行一番評審，來看看各自的設計有沒有問題。
比如開發人員和測試人員會看下互相對功能的理解是否一致，不然到時候測試起來，測試說這個有問題，開發說這樣是對的，就會浪費時間。
產品也會看下大家對需求的理解程度，避免理解偏差。
這個環節就是對細節方面的修改，改動一般不會太大，不會花太多時間。
該環節完成后，就是開發人員進行功能實現，前后端也會進行聯調，聯調完畢后開發人員會自行測試一番，沒問題了再交由測試人員測試。
流程弊端：
該流程是在開發環節前做了充足的準備，但沒有在開發環節后做充分的測試驗收，產品上線后質量得不到保障，容易出問題。
所以，在開發完成后還需要進行一系列的測試驗收工作。
開發后的保障
可以看到，開發完成后還有一大堆的事要做。
代碼Review
首先，大廠一般會做代碼 Review，即由組長或者組員審查你的代碼，無論是業務上還是技術上，在這個環節都能收獲許多建議，這個對開發人員可以說是成長最快的環節。
提測&第一輪測試
代碼沒問題后，開發人員就要提交測試申請，然后測試人員將代碼發布到測試環境進行測試。
為什么開發人員在這一步還要提交一個申請呢，直接將代碼發布不就得了。
這是因為測試周期比較長，測試人員還在測呢，你擅自發布，會影響測試人員的工作。
所以，測試環境只能由測試人員發布代碼。
測試環境沒問題后，就可以將代碼分支合并，然后由測試人員發布到預發/沙箱環境。
預發/沙箱&第二輪測試
沙箱環境就是指將系統接入真實的數據，但系統只能內部訪問，用戶是無法訪問的。
這個環節就是為了保證上線前不出問題，所以模擬線上真實環境，看系統能不能在真實數據下抗得住。
這一輪測試沒問題后，又可以將代碼分支合并一次，然后讓產品經理進行驗收。
產品第一輪驗收&上線申請&上線
產品經理會看看現在完成的功能是否和需求一致。
驗收無誤后，就會發起上線申請，然后就要將代碼發布到線上真實環境了。
上線這個事是“神圣又莊嚴”的，每個人巴不得焚香沐浴，深怕在線上出問題。
上線前要準備許多工作，比如要列出上線的服務有哪些、參與的相關人員、上線服務配置的變化、部署步驟、回滾方案等。
發布時間也有講究，一般不會在周五發布，怕出問題后周末不好調整；同理，一般也不會接近晚上發布，怕下班后不好處理。
有些公司還會發布灰度版本，即給部分用戶發送新版升級，這部分用戶體驗沒問題后，才全量發布。
回測&產品第二輪驗收
上線之后，測試人員還會進行一次回歸測試（第三輪測試了），測試無誤后產品會再次驗收。
都沒問題了，這個需求才算結束。
總結
從需求提出到需求結束，還是挺不容易的，中途歷經多個環節，要和多個部門/崗位協調，各種問題和難點都要面對。
這些流程，各個公司可能會有些出入，不過差不了太多。
每個公司會根據自己的公司文化、人員配比、業務方向以及需求大小做出調整，比如一些小的需求小的改動，概要/詳細設計就不會做了；再比如一些公司會將產品驗收環節放在第一輪測試之后……
流程的最終目的是節省人力成本和時間成本并且提高產品質量，符合公司實際情況的才是好流程。
小公司盲目采用大公司的流程，反而增加溝通成本；大公司明明流程老舊也不愿意改進，技術負債就會越來越多。
無論是公司還是開發人員，我們都應當保持學習、時刻進步，這樣才不會被這個時代拋下！
本文到這里就結束了，我是「RudeCrab」，一只粗魯的螃蟹，我們下篇文章再見。
關注「RudeCrab」微信公眾號，和螃蟹一起橫行霸道。
