企業研發流程演進之路

前言

不管是半路轉行的準程序員，仍是正在讀書的大學生，你們都比較關心一個問題：「企業中真實的研發流程是怎樣的」。有一些在小公司的程序員，也會好奇大廠的研發流程。

爲何這麼多人關心研發流程呢，由於一個合理完善的流程表明着穩定、高效。一個公司有了好的流程，就能極大節約人力成本和時間成本；一名開發人員體會了好的流程，就能極大鍛鍊本身的項目 / 代碼掌控能力。

本文就和你們分享一下，現在互聯網大廠的研發流程。

大廠流程雖好，但也不是一蹴而成。每一個公司體量不同，流程也不同，咱們就從最簡單的流程講起，看看這些環節是如何一步一步演進過來的。

流程演進

草臺班子

這套流程很是簡單，從需求提出到需求結束就只有一個「開發」環節。

該流程能夠說是沒有流程，每每只會在「我的接私活」中這樣作。我曾經接私活，許多客戶只有一個簡單的需求場景，好比「用戶輸入一些數據，根據必定公式給出分析建議」，像這種程序，開發人員直接根據描述完成功能便可。

流程弊端：

需求不明確，容易陷入無盡的「扯皮」中。

用戶一開始要的是 A 功能，你作出來後，客戶改口說要的是 B，那麼你以前作的就白費了。

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

明確需求

「初創的外包公司」或者「我的接私活」常實行這套流程。

該流程多了一個「需求確認與分析」環節，顧名思義，這一環節主要是對用戶提出的需求進行確認和分析，最後肯定好需求是會寫在合同中的，後續一切按照合同中的需求項進行開發。

這個環節上限極高，下限也極低。作得好，天然可以很大程度上避免用戶反覆無常；作得差，需求不明確，依然會讓開發人員返工。

需求變動是程序員最痛苦的事情，因此該環節會隨着流程的完善而不斷升級。

流程弊端：

客戶的需求通常就只有文字描述。這種狀況下，開發人員只是憑藉本身的想象進行開發，對需求的理解容易產生誤差。

原型

原型圖就是產品的預覽模型，用於展現產品的最終效果。

原型圖分爲低保真原型和高保真原型。

低保真原型就像草圖，用於快速向客戶或者開發人員展現產品效果，方便修改和調整。

高保真原型基本就是產品的最終效果了，並且還會有交互效果（就是頁面能夠點擊等操做），前端開發人員能夠直接按照原型圖進行頁面開發。

「小型的外包公司」和「我的接私活」常實行這套流程。

外包公司的話每每會有一個設計師進行原型圖設計。

我的接私活的話，不少客戶會直接給你原型圖，他們通常是請外包設計師畫出效果圖，而後再請咱們開發人員進行開發。

流程弊端：

開發完畢後就直接將項目交付了。

項目的各個Bug都是客戶在使用過程當中發現的，這時候須要開發人員修改不少趟，才能將項目徹底交付出去。

要知道，客戶不是專業人士也不是你的同事，溝通起來成本是很是高的，這種形式的交付會極其耽誤時間。

曾經我接的一個私活，工期是一個月，可是來來回回更改細節和缺陷，拖了三四個月，身心俱疲。

測試驗收

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

「中小型的外包公司」和「小型的產品公司」會實行這套流程。

外包公司，就是指沒有本身產品的公司，主要承接項目進行開發。需求都是從客戶那邊來的。

產品公司，就是指有本身產品的公司，會對本身的產品進行開發、運營、迭代。需求是業務部門、產品部門提出的。

這套流程麻雀雖但也小五臟俱全，各個環節都有對應的人員負責：

• PM：產品經理。負責需求提出、產品設計；
• UE：交互設計師。負責設計頁面佈局和交互（交互就是產品的操做邏輯，好比點擊這個按鈕會彈出什麼提示框）；
• UI：視覺設計師。負責產品的具體樣式設計（視覺就是產品的現實效果，好比這個圖標長什麼樣），UE 和 UI 不少時候是一我的；
• RD：開發人員。負責功能實現，主要分後端、前端、客戶端開發人員；
• QA：測試人員。負責產品的質量檢測；
• OP：運維人員。負責上線審批、維護產品所須要的硬件狀態。

每一個人員都各司其職，對本身所處的環節會進行把控，當前環節沒問題後纔會推動到下一個環節。

這時候流程的扭轉與推動，不是口頭上說一下就好了，而是要進行工程化管理，每一個環節都要通過特定步驟才能推動到下一步，好比發送郵件。

如今有許多協做工具/平臺，可讓咱們很是方便地管理流程。好比騰訊推出的 TAPD：

流程弊端：

雖然該流程已初具規模，但仍是很粗糙，每一個環節都有完善的餘地。

不少環節在沒有準備充足的狀況下就開始實施了，質量得不到有效的保障。

好比肯定需求和原型後，開發就直接編碼，若是在編碼過程當中發現技術方案不合理，此時要變動，就會浪費大量的時間。

因此，在實現功能前，應該進行一系列的設計與評審。

開發前的準備

接下來的流程演進，基本就是各互聯網中大廠的流程了，每一個環節可能各個公司的取捨不太同樣，不過差異不是太大。

這套流程主要體現了功能實現前的一系列環節，這些環節作得越好，功能實現得也就越快越好。

產品需求評審

需求提出後，產品會拉上各個崗位的人進行產品需求評審，交互/視覺設計、開發、測試都會拉上。

產品經理會將需求項寫好，而且整理出低保真原型圖、產品流程等，讓你們可以對產品和需求有個概念。

這時產品經理整理出來的叫作 PRD 文檔，內容大概以下：

每一個公司都不同，也不必定要寫出文檔一條條列出來，如今許多時候是直接在原型圖上進行標註說明，而後你們根據原型圖評審。

各個崗位會爭取弄清楚產品和需求的每一個細節，而且提示本身的想法，各抒己見。好比某個需求實現成本過高須要從新考慮、某個需求不合理須要改進等。

這個過程會花費比較長的時間，意見統一後產品經理會肯定版本，而後各崗位就要開始進行本身職責內的設計了。

首先是開發人員，要進行概要和詳細設計。

概要設計

概要設計就是開發方案設計，好比模塊怎麼劃分、技術如何選型、數據模型如何設計等。

這一塊主要是對整個項目進行一個大概的設計，切記在該階段對業務流程、細節實現過多糾結，這些都是詳細設計的事。

詳細設計

概要設計完成後，接下來就能夠對細節方面進行設計了。

這個細節就是指功能的實現思路，好比一個很是簡單的登陸功能是這樣的：

編碼時基本上就是看着圖開發了，設計得越詳細，編碼時就越輕鬆。

測試用例設計

開發人員須要對編碼進行思考和設計，測試人員也要對測試進行思考和設計，否則到時候想到哪測哪，容易遺漏功能點。

測試用例就是指須要測試的功能點詳情，這個功能點應該怎樣測試、前置條件是什麼、預期結果是什麼，等等。

測試用例能夠幫助測試人員理清需求，爲後續的測試提供可參考的依據，在測試過程當中也能夠反映測試進度。

交互/視覺設計

同時，設計師也要進行交互和視覺設計。

這個環節作出來的高保真原型圖，基本就是產品的最終樣貌了。

綜合評審

當開發人員、測試人員、設計師把本身的內容設計完畢後，你們又會湊到一塊進行一番評審，來看看各自的設計有沒有問題。

好比開發人員和測試人員會看下互相對功能的理解是否一致，否則到時候測試起來，測試說這個有問題，開發說這樣是對的，就會浪費時間。

產品也會看下你們對需求的理解程度，避免理解誤差。

這個環節就是對細節方面的修改，改動通常不會太大，不會花太多時間。

該環節完成後，就是開發人員進行功能實現，先後端也會進行聯調，聯調完畢後開發人員會自行測試一番，沒問題了再交由測試人員測試。

流程弊端：

該流程是在開發環節前作了充足的準備，但沒有在開發環節後作充分的測試驗收，產品上線後質量得不到保障，容易出問題。

因此，在開發完成後還須要進行一系列的測試驗收工做。

開發後的保障

能夠看到，開發完成後還有一大堆的事要作。

代碼Review

首先，大廠通常會作代碼 Review，即由組長或者組員審查你的代碼，不管是業務上仍是技術上，在這個環節都能收穫許多建議，這個對開發人員能夠說是成長最快的環節。

提測&第一輪測試

代碼沒問題後，開發人員就要提交測試申請，而後測試人員將代碼發佈到測試環境進行測試。

爲何開發人員在這一步還要提交一個申請呢，直接將代碼發佈不就得了。

這是由於測試周期比較長，測試人員還在測呢，你擅自發布，會影響測試人員的工做。

因此，測試環境只能由測試人員發佈代碼。

測試環境沒問題後，就能夠將代碼分支合併，而後由測試人員發佈到預發/沙箱環境。

預發/沙箱&第二輪測試

沙箱環境就是指將系統接入真實的數據，但系統只能內部訪問，用戶是沒法訪問的。

這個環節就是爲了保證上線前不出問題，因此模擬線上真實環境，看系統能不能在真實數據下抗得住。

這一輪測試沒問題後，又能夠將代碼分支合併一次，而後讓產品經理進行驗收。

產品第一輪驗收&上線申請&上線

產品經理會看看如今完成的功能是否和需求一致。

驗收無誤後，就會發起上線申請，而後就要將代碼發佈到線上真實環境了。

上線這個事是「神聖又莊嚴」的，每一個人恨不得焚香沐浴，深怕在線上出問題。

上線前要準備許多工做，好比要列出上線的服務有哪些、參與的相關人員、上線服務配置的變化、部署步驟、回滾方案等。

發佈時間也有講究，通常不會在週五發佈，怕出問題後周末很差調整；同理，通常也不會接近晚上發佈，怕下班後很差處理。

有些公司還會發布灰度版本，即給部分用戶發送新版升級，這部分用戶體驗沒問題後，才全量發佈。

回測&產品第二輪驗收

上線以後，測試人員還會進行一次迴歸測試（第三輪測試了），測試無誤後產品會再次驗收。

都沒問題了，這個需求才算結束。

總結

從需求提出到需求結束，仍是挺不容易的，中途歷經多個環節，要和多個部門/崗位協調，各類問題和難點都要面對。

這些流程，各個公司可能會有些出入，不過差不了太多。

每一個公司會根據本身的公司文化、人員配比、業務方向以及需求大小作出調整，好比一些小的需求小的改動，概要/詳細設計就不會作了；再好比一些公司會將產品驗收環節放在第一輪測試以後……

流程的最終目的是節省人力成本和時間成本而且提升產品質量，符合公司實際狀況的纔是好流程。

小公司盲目採用大公司的流程，反而增長溝通成本；大公司明明流程老舊也不肯意改進，技術負債就會愈來愈多。

不管是公司仍是開發人員，咱們都應當保持學習、時刻進步，這樣纔不會被這個時代拋下！

本文到這裏就結束了，我是「RudeCrab」，一隻粗魯的螃蟹，咱們下篇文章再見。

關注「RudeCrab」微信公衆號，和螃蟹一塊兒橫行霸道。