1. 前言

以前在不足百人的小公司待過(guò)，產(chǎn)品需求的研發(fā)并沒(méi)有什么正規(guī)的流程，通常是產(chǎn)品提了需求之后，技術(shù)部門(mén)簡(jiǎn)單評(píng)審一下就開(kāi)始寫(xiě)代碼，本地和測(cè)試環(huán)境沒(méi)問(wèn)題就直接發(fā)布線上了。

后來(lái)去了某二線互聯(lián)網(wǎng)公司，大概幾千人。雖然跟一線大廠還差很多，但需求的研發(fā)流程跟大廠大同小異。

前段時(shí)間運(yùn)營(yíng)小姐姐找我了解一些開(kāi)發(fā)相關(guān)的內(nèi)容，就跟她講到了我們的開(kāi)發(fā)流程。這里簡(jiǎn)單做個(gè)小結(jié)。

2. 整體概述

一個(gè)相對(duì)完整的需求研發(fā)流程大致如下圖所示：

PS: 該流程僅供參考，不同公司可能會(huì)有所不同，但主流程大體相似。

下面簡(jiǎn)要介紹各個(gè)環(huán)節(jié)的主要內(nèi)容。

3. 流程分析

0. 產(chǎn)品提出需求

產(chǎn)品通常是對(duì)接「運(yùn)營(yíng)」和「研發(fā)」的，是運(yùn)營(yíng)和研發(fā)之間的橋梁。

運(yùn)營(yíng)過(guò)程中產(chǎn)生的需求一般會(huì)反饋給產(chǎn)品，產(chǎn)品把需求的主要功能整理成需求文檔（Product Requirements Document, PRD），并畫(huà)出產(chǎn)品原型圖（常用工具：Axure）。

PRD 通常主要包含：

1. 需求背景。就是為什么要做這個(gè)需求？想要達(dá)成怎樣的目的？
2. 需求細(xì)節(jié)。各部分如何實(shí)現(xiàn)，包括業(yè)務(wù)邏輯以及如何交互等。

1. PRD 評(píng)審

PRD 完成之后，產(chǎn)品經(jīng)理（或者項(xiàng)目經(jīng)理）就約一個(gè)會(huì)議室，邀請(qǐng)開(kāi)發(fā)、測(cè)試、運(yùn)營(yíng)、交互設(shè)計(jì)師等人一起開(kāi)會(huì)，詳細(xì)說(shuō)明本次需求，主要是討論需求的可行性，比如技術(shù)能否實(shí)現(xiàn)、邏輯是否有問(wèn)題等。

2. 交互評(píng)審

產(chǎn)品給出的原型圖可能不夠具體，細(xì)節(jié)部分就要由交互設(shè)計(jì)師來(lái)出設(shè)計(jì)稿了（常用工具：Sketch、Figma 等）。

比如某個(gè)按鈕具體放到哪里、寬高多少、顏色值多少、點(diǎn)擊后如何跳轉(zhuǎn)，等等。然后設(shè)計(jì)師會(huì)根據(jù)設(shè)計(jì)稿切圖并給到前端開(kāi)發(fā)人員。

3. 技術(shù)評(píng)審

就是確定技術(shù)方案，這部分工作就要由我們開(kāi)發(fā)人員來(lái)主導(dǎo)了。主要包括如下部分：

• 需求整體可以分為哪幾個(gè)模塊？

• 需要哪些業(yè)務(wù)方配合？是否需要對(duì)接二方、三方？各業(yè)務(wù)方之間是如何交互的？

• 表結(jié)構(gòu)如何設(shè)計(jì)？接口如何定義？

• 有沒(méi)有技術(shù)難點(diǎn)？

主要是開(kāi)發(fā)同學(xué)向大家闡述詳細(xì)的技術(shù)實(shí)現(xiàn)方案，評(píng)估一下是否有不合理之處。

對(duì)于架構(gòu)圖、流程圖和時(shí)序圖，常用畫(huà)圖工具有 ProcessOn、draw.io、OmniGraffle、StarUML 等。

4. 開(kāi)發(fā)測(cè)試排期

經(jīng)過(guò)技術(shù)評(píng)審，一個(gè)需求具體有多少工作量大致就可以確定了。此時(shí)就要給出一個(gè)比較詳細(xì)的排期了，主要包括：

• 開(kāi)發(fā)時(shí)間：?jiǎn)渭兊拈_(kāi)發(fā)「總?cè)藭r(shí)」需要多久（時(shí)間通常以 0.5 天/人、或者 0.25 天/人為單位）

• 聯(lián)調(diào)時(shí)間：前后端聯(lián)調(diào)、后端跟其他第二方、第三方聯(lián)調(diào)需要多久

• 提測(cè)時(shí)間：哪天可以交付測(cè)試同學(xué)進(jìn)行測(cè)試（如果需求比較緊急，可以分批提測(cè)，也就是拆分成不同的功能模塊提測(cè)）

• 測(cè)試時(shí)間：通常包括測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境回歸測(cè)試，這幾個(gè)時(shí)間都要算上

通常「開(kāi)發(fā)排期 + 聯(lián)調(diào)排期 + 測(cè)試排期」就是這個(gè)需求的實(shí)施時(shí)間，這幾個(gè)時(shí)間確定之后需求的發(fā)布上線時(shí)間基本就定了。但也要考慮到期間可能產(chǎn)生的一些意外情況。

5. 輸出技術(shù)文檔

技術(shù)評(píng)審需要輸出技術(shù)文檔，把此次需求使用哪些技術(shù)、增加哪些配置、設(shè)計(jì)哪些表記錄下來(lái)，涉及到流程圖、架構(gòu)圖也要形成文檔，以便過(guò)段時(shí)間之后再看，或者后面交接給其他人維護(hù)。

此外，后端開(kāi)發(fā)通常還要先給出接口定義、入?yún)⒊鰠⒌龋ㄔ撨^(guò)程可以前后端討論確定），以便前端同學(xué) Mock 數(shù)據(jù)。

6. 測(cè)試用例評(píng)審

測(cè)試同學(xué)把本期需求的功能點(diǎn)全部列出來(lái)，向大家說(shuō)明自己如何去測(cè)試、期望得到怎樣的結(jié)果等。如果有的接口對(duì) QPS、RT 等要求較高，一般會(huì)進(jìn)行「壓測(cè)」來(lái)確定是否滿足要求。

有點(diǎn)類(lèi)似測(cè)試的“技術(shù)評(píng)審”。

7. 前后端各自開(kāi)發(fā)

這時(shí)候總算可以擼代碼了！

前后端按照之前的接口定義各自開(kāi)發(fā)。

8. 前后端聯(lián)調(diào)

開(kāi)發(fā)分別在本地自測(cè)以后，前后端一起走下整體流程。

PS: 有時(shí)候提測(cè)之前測(cè)試同學(xué)會(huì)給出一個(gè)冒煙測(cè)試用例（非必須），通常是主流程和一些核心部分邏輯，當(dāng)這些地方都沒(méi)問(wèn)題時(shí)，才可以提測(cè)。

9. 提測(cè)

提測(cè)就是正式告訴測(cè)試同學(xué)這個(gè)需求已經(jīng)初步開(kāi)發(fā)完成，可以進(jìn)行測(cè)試了。

一般以郵件的形式告知，包含相關(guān)測(cè)試同學(xué)、項(xiàng)目經(jīng)理、開(kāi)發(fā)、產(chǎn)品等人，以便各方了解項(xiàng)目進(jìn)度。

PS:?如有特殊情況導(dǎo)致延期，需要提前發(fā)郵件告知各需求方延期的原因。

10. 測(cè)試環(huán)境測(cè)試

測(cè)試同學(xué)在測(cè)試環(huán)境按照之前的測(cè)試用例各種測(cè)、各種找 bug……改 bug……找 bug……改 bug……

bug 整體改完之后，會(huì)叫產(chǎn)品經(jīng)理初步驗(yàn)收一下是否符合預(yù)期。

11. 預(yù)發(fā)布環(huán)境測(cè)試

測(cè)試環(huán)境的數(shù)據(jù)可能不夠正式，主要是用來(lái)測(cè)試各個(gè)流程能夠走通。而到了預(yù)發(fā)布環(huán)境，各種配置和數(shù)據(jù)庫(kù)就跟生產(chǎn)環(huán)境基本一致了。

如果預(yù)發(fā)布環(huán)境沒(méi)問(wèn)題，就準(zhǔn)備發(fā)布生產(chǎn)環(huán)境了。

12. 發(fā)布生產(chǎn)環(huán)境

發(fā)布生產(chǎn)環(huán)境之前，通常是需要做些準(zhǔn)備工作的：比如創(chuàng)建數(shù)據(jù)表、新增配置等，通常要運(yùn)維同學(xué)配合添加和修改（因?yàn)殚_(kāi)發(fā)通常沒(méi)這個(gè)權(quán)限）。

13. 線上回歸測(cè)試

發(fā)布成功之后，測(cè)試同學(xué)需要進(jìn)行回歸測(cè)試，也就是在生產(chǎn)環(huán)境把需求再驗(yàn)證一次。

全部通過(guò)之后，就叫產(chǎn)品正式驗(yàn)收了，產(chǎn)品覺(jué)得 OK，才能說(shuō)明這次需求 OK 的。產(chǎn)品點(diǎn)頭之后，這個(gè)需求才算真正開(kāi)發(fā)完成。之后可能還會(huì)有些其他收尾工作，但非必須。

14. 項(xiàng)目復(fù)盤(pán)總結(jié)

這部分并非必須。

一般在需求過(guò)程中問(wèn)題比較多時(shí)，會(huì)復(fù)盤(pán)一下問(wèn)題主要出在哪里，以后如何規(guī)避等。

15. 需求完成

至此，一個(gè)比較完整的需求研發(fā)流程就結(jié)束了。

4. 補(bǔ)充說(shuō)明

1. Code Review

通常的 Code Review 在測(cè)試環(huán)境流程通過(guò)之后。

雖然經(jīng)過(guò)測(cè)試功能上沒(méi)問(wèn)題了，但代碼中可能潛藏一些問(wèn)題難以測(cè)出來(lái)。此時(shí)可以叫幾個(gè)開(kāi)發(fā)小哥還有老大，一起找個(gè)地方把關(guān)鍵部分的代碼 Review 一下，看是否有潛在的漏洞，或者代碼在哪部分寫(xiě)得不夠合理。

這部分做好的話其實(shí)對(duì)個(gè)人成長(zhǎng)幫助挺大的，但有些公司可能會(huì)忽略這部分，尤其是排期緊張的時(shí)候。

2. 說(shuō)明

上述流程只是根據(jù)個(gè)人平時(shí)開(kāi)發(fā)經(jīng)歷總結(jié)的，僅供參考。

若需求比較簡(jiǎn)單，可能會(huì)把一些步驟省略掉。

PS: 運(yùn)營(yíng)小姐姐說(shuō)此前還覺(jué)得我們做需求應(yīng)該很快，不明白為啥開(kāi)發(fā)一個(gè)需求要這么久，待我跟她講完開(kāi)發(fā)流程，她保證以后再也不催我們了。