我們接下來(lái)文章內(nèi)容都是基于以上原則與前提，接下來(lái)正文開(kāi)始~

二、需求文檔用啥寫(xiě)

我們以終為始，先看需求文檔的呈現(xiàn)方式。目前主要有以下2類(lèi)：

1. Axure一體化需求文檔

使用Axure將全部需求文檔，最終通過(guò)Axure打包提供出去。好處是方便查看，看原型的基礎(chǔ)上又能看文檔說(shuō)明。但有一種不是很“嚴(yán)肅”的感覺(jué)。

2. Word版

通過(guò)Word進(jìn)行需求描述，并統(tǒng)一提供。容易留存，也比較正規(guī)，在閱讀上以文字為主。

具體選擇那種方式，可以先看公司要求。

像我之前有公司要求，必須用word，就算是有大量原型的，也只能把頁(yè)面原型畫(huà)好，然后再?gòu)?fù)制到word里，在word寫(xiě)需求內(nèi)容。

如果沒(méi)有要求，具體采用的方式可以看不同的需求類(lèi)型：

如果只涉及到畫(huà)原型的，可以使用Axure。

如果只有偏后端需求的，邏輯相關(guān)的需求，比如說(shuō)是接口需求、算法需求，并不涉及到前端需求的，我們可以直接使用word寫(xiě)。

如果是做的大項(xiàng)目，同時(shí)有功能需求，又有接口需求、算法需求的，我建議都放在一起，比如說(shuō)都用Axure寫(xiě)需求。

我之前做新項(xiàng)目的時(shí)候，同時(shí)提供了功能需求的axure文檔+word版的接口需求，后來(lái)用例評(píng)審的時(shí)候，測(cè)試說(shuō)不知道word版接口需求，之后我就統(tǒng)一寫(xiě)在axure里了。

三、需求文檔包含哪些內(nèi)容

需求有大有小，同樣的需求文檔也有大有小，小到直接一句話(huà)描述，大到上百個(gè)原型頁(yè)面，好幾萬(wàn)個(gè)字。

一句話(huà)的需求我們?cè)谶@就不說(shuō)了，我們說(shuō)下正常的需求文檔。

不論是使用Axure還是word，也不論需求大小是什么，PRD文檔中一般需要包含以下內(nèi)容：

1. 文檔修改記錄

需求文檔在需求評(píng)審、研發(fā)、測(cè)試過(guò)程中一定會(huì)改的。

比如說(shuō)加個(gè)限制，補(bǔ)充個(gè)遺漏的邏輯等等，不過(guò)我們一定要記錄下修改內(nèi)容，并及時(shí)更新需求文檔、及時(shí)同步項(xiàng)目成員。

一般通過(guò)表格展示出以下內(nèi)容：

• 修改內(nèi)容：說(shuō)清楚修改的哪個(gè)模塊，哪個(gè)頁(yè)面、哪個(gè)功能點(diǎn)。當(dāng)然也可以分成修改模塊、修改頁(yè)面多個(gè)列。
• 修改原因：就是為啥要修改，比如說(shuō)邏輯缺失需要補(bǔ)充等等。
• 修改人：誰(shuí)改的。
• 修改日期：修改時(shí)間。

在使用Axure時(shí)，我們可以在文檔修改記錄中加上文本鏈接跳轉(zhuǎn)，項(xiàng)目成員點(diǎn)擊文字可直接進(jìn)入到對(duì)應(yīng)頁(yè)面查看。

對(duì)于word，也是同樣的，加個(gè)文檔修改記錄。

對(duì)于文檔修改記錄，不僅在PRD文檔中可以用到，在寫(xiě)其它文檔時(shí)都可以加上，比如操作手冊(cè)。

2. 項(xiàng)目背景 or 需求背景

背景同樣也是有大有小，對(duì)于新項(xiàng)目，則需要介紹下整個(gè)項(xiàng)目的大背景。對(duì)于每個(gè)需求，我們同樣也可以簡(jiǎn)單說(shuō)下需求背景。

參考格式如下：

當(dāng)前的現(xiàn)狀是什么，有哪些問(wèn)題/痛點(diǎn)，這些問(wèn)題導(dǎo)致了什么結(jié)果，為了解決這個(gè)問(wèn)題，我們需要采取什么動(dòng)作，達(dá)到什么目的，能夠獲取哪些收益，產(chǎn)生什么價(jià)值。

3. 名詞解釋

如果有專(zhuān)業(yè)名詞，一定要寫(xiě)上。

在不同行業(yè)、不同公司、不同團(tuán)隊(duì)中都有專(zhuān)門(mén)的名詞，項(xiàng)目成員是不明白一些名詞的，這個(gè)時(shí)候一定要說(shuō)明。

比如說(shuō)抗菌藥物DDD值，絕對(duì)的專(zhuān)業(yè)名詞，不說(shuō)一般沒(méi)人知道。

另外在說(shuō)名詞解釋的時(shí)候，盡量加上示例說(shuō)明方便大家快速理解。

4. 流程圖

當(dāng)涉及跨角色、跨系統(tǒng)、跨模塊、多判斷邏輯時(shí)，我們一定要畫(huà)出來(lái)，讓各方更快地了解產(chǎn)品流程。

流程圖同樣有大有?。?/p>

包括整體產(chǎn)品業(yè)務(wù)流程圖、單個(gè)模塊的流程圖、單個(gè)功能的流程圖。

1）整體流程圖

為了將這個(gè)產(chǎn)品的功能業(yè)務(wù)串起來(lái)，可以不用畫(huà)的太詳細(xì)，畫(huà)出大的概覽圖，從大而全的角度將這個(gè)項(xiàng)目表達(dá)出來(lái)。

一般是在0-1的新項(xiàng)目中畫(huà)，日常迭代的需求中不需要。

2）單個(gè)模塊功能的流程圖

當(dāng)一個(gè)功能模塊功能很多時(shí)，為了將模塊內(nèi)的功能串起來(lái)，說(shuō)清楚單獨(dú)模塊的流程，這個(gè)就要畫(huà)的細(xì)致一點(diǎn)。

當(dāng)涉及到新的模塊時(shí)一定要畫(huà)。

3）單個(gè)功能的流程圖

對(duì)于復(fù)雜的單個(gè)功能，涉及到的處理邏輯比較多時(shí)，我們也需要畫(huà)出單獨(dú)的流程圖進(jìn)行說(shuō)明。

流程圖的類(lèi)型有很多種，像業(yè)務(wù)流程圖、頁(yè)面流程圖、泳道圖、uml里的時(shí)序圖、用例圖等等。

我們可以基于不同流程圖的特性去選擇不同的類(lèi)型，比如有多角色時(shí)，我們可以使用泳道圖。

對(duì)于UML，像用例圖、序列圖，在畫(huà)的時(shí)候有一定的門(mén)檻，同樣的一定會(huì)有團(tuán)隊(duì)成員看不懂。我是從來(lái)沒(méi)畫(huà)過(guò)，所以大家可以自行選擇學(xué)習(xí)與繪制。

對(duì)于頁(yè)面流程圖，是表達(dá)出頁(yè)面之間的跳轉(zhuǎn)邏輯，像移動(dòng)端的頁(yè)面，我們可以直接平鋪出每個(gè)頁(yè)面，展示出頁(yè)面間的跳轉(zhuǎn)邏輯。

對(duì)于PC端產(chǎn)品，頁(yè)面尺寸較大，我們可以通過(guò)頁(yè)面名稱(chēng)展示出頁(yè)面流程。

流程圖的能夠達(dá)到業(yè)務(wù)清楚，表明重點(diǎn)，項(xiàng)目成員能夠快速理解的目的就行。

5. 需求說(shuō)明

對(duì)需求的詳細(xì)說(shuō)明，這一點(diǎn)肯定是必須的，我們下邊單獨(dú)說(shuō)。

以上內(nèi)容是我認(rèn)為在寫(xiě)需求文檔時(shí)，需要包含的內(nèi)容，下邊的內(nèi)容我們則可以自行選擇~

1）產(chǎn)品架構(gòu)圖

在0-1產(chǎn)品搭建的時(shí)候進(jìn)行展示，將整個(gè)產(chǎn)品抽象化，通過(guò)數(shù)據(jù)層、服務(wù)層、應(yīng)用層、展現(xiàn)層等抽象層面表現(xiàn)出產(chǎn)品的整體架構(gòu)。

來(lái)自Processon

產(chǎn)品架構(gòu)圖是非常大的層面，當(dāng)你沒(méi)有獨(dú)立負(fù)責(zé)一條業(yè)務(wù)線(xiàn)的時(shí)候，很難有這種大的架構(gòu)概念。

當(dāng)你需要規(guī)劃一條產(chǎn)品線(xiàn)的時(shí)候，可以畫(huà)出來(lái)產(chǎn)品架構(gòu)圖，讓之后的產(chǎn)品方向再這個(gè)大的框架下去走。

我也是在最近這2年，獨(dú)立負(fù)責(zé)產(chǎn)品線(xiàn)的時(shí)候才開(kāi)始繪制的，主要是和領(lǐng)導(dǎo)們匯報(bào)使用的。

具體怎么畫(huà)，大家可以在平臺(tái)上搜一下，有很多。

2）功能架構(gòu)圖 or 信息架構(gòu)圖

對(duì)于功能架構(gòu)圖，就是寫(xiě)清楚產(chǎn)品功能的層級(jí)架構(gòu)，簡(jiǎn)單說(shuō)就是一級(jí)菜單、二級(jí)菜單是什么，每個(gè)菜單里有哪些功能，展示出功能的層級(jí)關(guān)系。

我一次都沒(méi)有畫(huà)過(guò)。

對(duì)于功能架構(gòu)的展示，我一般在畫(huà)原型的時(shí)候規(guī)劃出來(lái)，然后直接畫(huà)原型。

當(dāng)然也可以通過(guò)思維導(dǎo)圖的方式畫(huà)出來(lái)，但是吧，畫(huà)出來(lái)也沒(méi)人看。

還有一個(gè)信息架構(gòu)圖，這個(gè)我也沒(méi)畫(huà)過(guò)。

我有很長(zhǎng)的一段時(shí)候都沒(méi)整明白功能架構(gòu)圖與信息架構(gòu)圖有啥區(qū)別~

現(xiàn)在我的理解是：

• 功能架構(gòu)圖是展示出功能層級(jí)關(guān)系，體現(xiàn)出菜單-功能的層級(jí)邏輯。
• 信息架構(gòu)圖是展示出每個(gè)功能頁(yè)面內(nèi)的展示字段內(nèi)容，主要用于研發(fā)設(shè)計(jì)表結(jié)構(gòu)與表字段。

對(duì)于功能架構(gòu)圖和信息架構(gòu)圖，一般是在產(chǎn)品0-1的時(shí)候畫(huà)，而且涉及到的內(nèi)容比較多，多的內(nèi)容一定沒(méi)人去看。

到底要不要畫(huà)是一方面，大家一定要知道功能結(jié)構(gòu)圖和信息架構(gòu)圖是個(gè)什么東西，具體畫(huà)不畫(huà)大家自行選擇。

四、畫(huà)原型寫(xiě)文檔

需求類(lèi)型里有一個(gè)功能需求，這個(gè)就是每個(gè)產(chǎn)品避免不了的，所以我們單獨(dú)說(shuō)下畫(huà)原型+寫(xiě)文檔~

1. 首先根據(jù)要做的需求范圍進(jìn)行分類(lèi)

當(dāng)有多個(gè)需求類(lèi)型時(shí)，按類(lèi)型進(jìn)行分類(lèi)，使用Axure時(shí)可以通過(guò)建立文件夾。

使用word則可以加個(gè)一級(jí)標(biāo)題。

目的是將需求有層級(jí)的依次展示出來(lái)。

然后在不同的文件夾下，在進(jìn)行分級(jí)。

比如「功能需求說(shuō)明」文件夾下有多個(gè)功能模塊，則按照模塊/菜單名稱(chēng)建立子文件夾，然后再在每個(gè)模塊下建立對(duì)應(yīng)頁(yè)面；

當(dāng)同一個(gè)頁(yè)面內(nèi)有多個(gè)tab頁(yè)/子頁(yè)面時(shí)：

對(duì)于PC端，我一般是分頁(yè)面說(shuō)明；APP的頁(yè)面尺寸小，我們可以在一個(gè)Axure頁(yè)面內(nèi)統(tǒng)一說(shuō)明。

然后再對(duì)每個(gè)頁(yè)面單獨(dú)畫(huà)原型，寫(xiě)文檔。

2. 需求文檔的表現(xiàn)方式

當(dāng)采用Axure寫(xiě)需求文檔的時(shí)候，常見(jiàn)的布局是：左圖右文。

左邊展示原型圖，右邊展示需求說(shuō)明。

對(duì)于word版，常為：原型頁(yè)面展示，單獨(dú)寫(xiě)文檔說(shuō)明。

3. 提取公共邏輯，放入全局說(shuō)明

在畫(huà)原型、寫(xiě)文檔的時(shí)候，一定會(huì)有相同的功能邏輯、相同的需求邏輯。

例如說(shuō)后臺(tái)系統(tǒng)，會(huì)有一堆的列表，列表就涉及到分頁(yè)數(shù)量、默認(rèn)排序等。

我們可以直接統(tǒng)一使用全局說(shuō)明。

將相同的功能邏輯、需求內(nèi)容當(dāng)在一個(gè)單獨(dú)的全局說(shuō)明里，在全局說(shuō)明里進(jìn)行單獨(dú)說(shuō)明。

當(dāng)在某個(gè)頁(yè)面中需要說(shuō)明的功能點(diǎn)已經(jīng)在「全局說(shuō)明」里存在時(shí)，可以加個(gè)說(shuō)明：請(qǐng)見(jiàn)全局說(shuō)明。

同時(shí)對(duì)文字添加文字跳轉(zhuǎn)鏈接，閱讀者點(diǎn)擊可直接跳轉(zhuǎn)到對(duì)應(yīng)的全局說(shuō)明頁(yè)面。

3. 功能點(diǎn)序號(hào)標(biāo)注

先畫(huà)出原型圖，在原型中標(biāo)注「序號(hào)」，然后在右側(cè)按照相同的序號(hào)進(jìn)行功能需求描述。

• 標(biāo)注順序：一般按照從左到右，從上到下的順序。
• 標(biāo)注哪些點(diǎn)：需要進(jìn)行功能說(shuō)明的功能點(diǎn)，但是并不意味著每一個(gè)點(diǎn)都要進(jìn)行標(biāo)注。

我一般按照從大到小，按照模塊化的方式。

以下方的表單頁(yè)面為例：

當(dāng)原型畫(huà)出后，在頁(yè)面上標(biāo)個(gè)序號(hào)[1]，對(duì)頁(yè)面進(jìn)行下簡(jiǎn)介，一般說(shuō)明頁(yè)面是什么，使用角色是誰(shuí)。

然后繼續(xù)標(biāo)注「返回」，對(duì)「返回」進(jìn)行說(shuō)明。

因?yàn)辄c(diǎn)擊返回時(shí)，沒(méi)有添加其它判斷邏輯（如是否二次確認(rèn)），所以直接描述交互邏輯即可。

然后接著對(duì)下方的「患者信息」進(jìn)行標(biāo)注。

我們可以看到「患者信息」里有很多字段，我不建議對(duì)每個(gè)字段進(jìn)行說(shuō)明。

我們直接對(duì)「患者信息」整個(gè)模塊進(jìn)行標(biāo)注，然后對(duì)每個(gè)字段進(jìn)行說(shuō)明。

由于只是表單輸入，我們需要說(shuō)明是否必填、采用什么組件、是能輸入文字、還是數(shù)字輸入框，數(shù)字范圍限制、數(shù)字小數(shù)點(diǎn)限制（如最多2位小數(shù)）、輸入小數(shù)點(diǎn)超過(guò)如何處理（是直接限制輸入，還是能四舍五入）、字符長(zhǎng)度限制、當(dāng)字符輸入超長(zhǎng)如何處理。

如果是采用選擇框，選擇框里的值是寫(xiě)死的，還是從哪里取值。

……

這就是對(duì)需求的描述，我們需要盡可能的寫(xiě)全，就是盡可能的把考慮到的限制加上，你寫(xiě)的越全，在評(píng)審的時(shí)候，才會(huì)少挨懟。之后的需求變更才會(huì)少。

（現(xiàn)在看其實(shí)上邊的需求描述還是不全，比如漏了小數(shù)點(diǎn)位數(shù)說(shuō)明，文本輸入框內(nèi)能不能輸入表情emoji符號(hào)等等）

當(dāng)頁(yè)面內(nèi)出現(xiàn)彈窗時(shí)，我們需要對(duì)彈窗里的內(nèi)容進(jìn)行說(shuō)明，單獨(dú)對(duì)彈窗里功能點(diǎn)進(jìn)行標(biāo)注，然后再下方繼續(xù)對(duì)需求進(jìn)行說(shuō)明。

對(duì)于彈窗里的內(nèi)容，我一般從「1」開(kāi)始重新編號(hào)。不把序號(hào)順序和其他頁(yè)面夾雜在一起。當(dāng)調(diào)整一個(gè)功能點(diǎn)后，需要重新編號(hào)，增加了多余的工作量。

4. 需求詳細(xì)書(shū)寫(xiě)

對(duì)需求的詳細(xì)描述，是最核心的內(nèi)容，我們可以按照下方的格式來(lái)寫(xiě)：

• 標(biāo)題：功能點(diǎn)名稱(chēng)。
• 角色權(quán)限：如當(dāng)前登錄用戶(hù)角色為管理員時(shí)，則顯示此按鈕。
• 規(guī)則邏輯：主要有校驗(yàn)邏輯、前置條件、觸發(fā)時(shí)機(jī)等，當(dāng)涉及到的校驗(yàn)邏輯太多時(shí)，可以采用分行分段、添加序號(hào)、使用表格等方式，將每個(gè)邏輯有條理的全部說(shuō)明清楚。

比如：確定按鈕。

當(dāng)角色為「管理員」時(shí)，展示出確認(rèn)按鈕；

1. 當(dāng)XX未填寫(xiě)時(shí)，按鈕顯示為禁用狀態(tài)，點(diǎn)擊時(shí)出現(xiàn)toast提示：請(qǐng)?zhí)顚?xiě)XXX。
2. 當(dāng)XXX、XXX全部填寫(xiě)后，按鈕置為可點(diǎn)擊狀態(tài)，點(diǎn)擊后跳轉(zhuǎn)至XXX頁(yè)面。

極值說(shuō)明：如輸入框輸入字符的長(zhǎng)度，數(shù)字輸入的范圍值。

交互說(shuō)明：如點(diǎn)擊調(diào)整至XXX頁(yè)面。

在寫(xiě)需求時(shí)，根據(jù)不同的需求內(nèi)容，盡可能的將全部?jī)?nèi)容寫(xiě)清楚。

這個(gè)時(shí)候一定會(huì)有一個(gè)問(wèn)題：寫(xiě)不全。

我們可以明確一點(diǎn)，沒(méi)有產(chǎn)品經(jīng)理把所有情況都考慮到，喬布斯、張小龍也考慮不了那么全。

我們需要做的是盡可能的考慮全，盡可能是個(gè)很虛的詞，受行業(yè)經(jīng)驗(yàn)、項(xiàng)目經(jīng)驗(yàn)等影響，不同級(jí)別的產(chǎn)品經(jīng)理的需求文檔寫(xiě)的水平很顯而易見(jiàn)，當(dāng)然你考慮的越全面，產(chǎn)品能力可以說(shuō)就越強(qiáng)。

我們可以在需求評(píng)審前，先和研發(fā)提前碰下，避免有大的遺漏。

也可以借助「需求自查表」來(lái)輔助，自查出遺漏的說(shuō)明。

5. 其它

1）文字描述言簡(jiǎn)意賅，避免口語(yǔ)化，別使用模棱兩可的文字。需求文檔里的內(nèi)容必須明確，別寫(xiě)「盡量」「盡快」。

2）添加示例：被誤解是表達(dá)者的宿命，文字說(shuō)明都會(huì)有一定的片面理解，對(duì)于比較復(fù)雜的內(nèi)容，我們可以添加示例說(shuō)明：

同時(shí)在原型上，盡量使用貼合實(shí)際場(chǎng)景的內(nèi)容。比如說(shuō)時(shí)間別寫(xiě)出：13:88:99。

3）為了便于閱讀，可以采用多分段，多分行，加序號(hào)的方式。

4）使用標(biāo)點(diǎn)符號(hào)，將內(nèi)容說(shuō)清楚，如：點(diǎn)擊「確認(rèn)」按鈕，跳轉(zhuǎn)至【XXX頁(yè)面】。

關(guān)于標(biāo)點(diǎn)符號(hào)，大家可以看這個(gè)文章：https://zhuanlan.zhihu.com/p/359255980

5）結(jié)合axure的特性，添加文字鏈接，便于閱讀者快速跳轉(zhuǎn)查看，不用自己找。

添加「返回」按鈕，比如閱讀者跳轉(zhuǎn)到【全局說(shuō)明頁(yè)面】，看完后，想在回到來(lái)源頁(yè)繼續(xù)看需求，我們可以在【全局說(shuō)明頁(yè)面】中添加個(gè)「返回來(lái)源頁(yè)」按鈕，加個(gè)返回上一頁(yè)的交互，直接能返回。

6）對(duì)于變量值，使用特殊符號(hào)標(biāo)記下

對(duì)于會(huì)變化的值，我一般使用用兩個(gè)百分號(hào)，如下方的‘科室名稱(chēng)’，會(huì)根據(jù)不同的選擇展示不同的名稱(chēng)，所以我就通過(guò)‘%科室名稱(chēng)%’進(jìn)行表示，然后單獨(dú)說(shuō)明，并舉例說(shuō)明。

7）重要內(nèi)容進(jìn)行標(biāo)記

可以通過(guò)加粗、換個(gè)顏色等方式進(jìn)行提醒，當(dāng)內(nèi)容較多的時(shí)候，大家很容易忽略掉，所以很有必要進(jìn)行加粗加大標(biāo)色提醒。

8）涉及到邏輯時(shí)，可以使用公式進(jìn)行說(shuō)明

如：當(dāng)A+B≥100時(shí)，則XXXX。

9）寫(xiě)完后自己再過(guò)一遍

就像上學(xué)做題后，自己zai再驗(yàn)算一遍，在寫(xiě)文檔的時(shí)候，自己肯定會(huì)有抽風(fēng)的時(shí)候，不知道哪個(gè)地方就給寫(xiě)錯(cuò)了。

10、對(duì)外提供時(shí)，對(duì)于Axure，可以打包出html提供。

如果是word版本，可以提供出pdf版。

以上是對(duì)功能需求的說(shuō)明，對(duì)于接口需求、性能需求、埋點(diǎn)需求等非功能性需求，當(dāng)涉及到的時(shí)候，一定要寫(xiě)上，不然就是需求遺漏了。

我之前一直以為產(chǎn)品經(jīng)理只需要寫(xiě)功能需求就夠了。

有一次讓我寫(xiě)接口需求，我就很郁悶，這明明是技術(shù)的活，干嘛產(chǎn)品寫(xiě)。后來(lái)，我明白了一件事，產(chǎn)品經(jīng)理不往前站，之后就會(huì)是一堆坑。

除了接口需求，還是像研發(fā)數(shù)據(jù)庫(kù)建表時(shí)，這些我也建議產(chǎn)品經(jīng)理去介入，因?yàn)楸砝镉心男┳侄危侄巫畲箝L(zhǎng)度是多少，需要建哪些字段等等，都是和業(yè)務(wù)有關(guān)系的。

舉個(gè)示例，藥品的「規(guī)格」這個(gè)字段，研發(fā)把最大長(zhǎng)度設(shè)置成250個(gè)字符，但是在實(shí)際業(yè)務(wù)上，「規(guī)格」會(huì)有2000個(gè)字的情況。

研發(fā)絕對(duì)是不理解的，所以最清楚這個(gè)情況的是產(chǎn)品，就需要提醒研發(fā)關(guān)注下。避免上線(xiàn)后，字?jǐn)?shù)超長(zhǎng)導(dǎo)致保存錯(cuò)誤。

對(duì)于性能需求怎么寫(xiě)，大家可以看這篇：《5000字詳解性能需求》。

對(duì)于接口需求、埋點(diǎn)需求等大家可以在平臺(tái)上搜一下，接口需求可以看：http://www.theventurebank.com/pmd/2297401.html

總結(jié)

寫(xiě)出好的需求文檔受很多方面的影響，從前期的需求分析，當(dāng)確定業(yè)務(wù)流程，然后再到畫(huà)原型，最終把PRD寫(xiě)出來(lái)，這里邊涉及到的內(nèi)容非常非常多。

這篇文章是給大家提供的概述，大家可以在日常中總結(jié)積累，多和項(xiàng)目成員溝通，每一次需求評(píng)審就是一次淬煉，挨個(gè)一次懟后就總結(jié)，下次別再犯。

另外，當(dāng)你把一篇完美的需求文檔交付后，一定會(huì)有研發(fā)、測(cè)試不看的，只會(huì)問(wèn)，就不看文檔。我一般是“微笑服務(wù)”，把文檔內(nèi)容截個(gè)圖發(fā)過(guò)去。