編輯導(dǎo)語：在日常工作中，有接觸過需求文檔的人，想必都會(huì)遺漏掉一些細(xì)節(jié)問題，也有可能還有人不知道需求文檔是什么？該如何避免？本篇作者就分享了自己在輸出需求文檔時(shí)的經(jīng)驗(yàn)，以及為什么要正確的輸出需求文檔。推薦給產(chǎn)品經(jīng)理或在團(tuán)隊(duì)里需要輸出需求文檔的童鞋閱讀。

案例1:

錯(cuò)誤示范：公司名稱字段字符長(zhǎng)度限制為50個(gè)字符，不可為空。

正確示范：公司名稱字段長(zhǎng)度限制為50個(gè)字符；不可為空，異常提示：請(qǐng)輸入公司名稱。

問題解析：產(chǎn)品經(jīng)理在需求描述沒有給出恰當(dāng)?shù)漠惓Ｇ闆r提示，開發(fā)在需求實(shí)現(xiàn)過程中按自己的理解寫了一個(gè)錯(cuò)誤提示，測(cè)試環(huán)節(jié)或上線后，發(fā)現(xiàn)提示文案有問題然后返工，這樣的情況在我目前所在的公司是時(shí)有發(fā)生的。

案例2：

錯(cuò)誤示范：手機(jī)號(hào)字段字符長(zhǎng)度限制為11個(gè)字符，只能輸入數(shù)字；不可為空，異常提示：請(qǐng)輸入手機(jī)號(hào)；手機(jī)號(hào)格式校驗(yàn)，異常提示：手機(jī)號(hào)格式錯(cuò)誤，請(qǐng)重新輸入。

正確示范：手機(jī)號(hào)字段字符長(zhǎng)度限制為11個(gè)字符，只能輸入數(shù)字，文本框獲取焦點(diǎn)時(shí)彈出數(shù)字鍵盤；不可為空，異常提示：請(qǐng)輸入手機(jī)號(hào)；手機(jī)號(hào)格式校驗(yàn)，異常提示：手機(jī)號(hào)格式錯(cuò)誤，請(qǐng)重新輸入。

問題解析：類似場(chǎng)景2的情況，產(chǎn)品經(jīng)理在描述需求時(shí)，如果是移動(dòng)端產(chǎn)品且字段限制只能輸入數(shù)字，最好是能在需求描述上給出出在交互上的期望，否則開發(fā)實(shí)現(xiàn)的結(jié)果不符合期望，那么可能在測(cè)試環(huán)節(jié)或上線后需要返工。

案例3：

錯(cuò)誤示范：【刪除】按鈕默認(rèn)為不可點(diǎn)擊狀態(tài)，用戶選擇數(shù)據(jù)后，【刪除】按鈕為激活狀態(tài)；用戶點(diǎn)擊【刪除】按鈕，顯示操作確認(rèn)彈窗，用戶點(diǎn)擊確認(rèn)按鈕執(zhí)行數(shù)據(jù)刪除操作。

正確示范：【刪除】按鈕默認(rèn)為不可點(diǎn)擊狀態(tài)，用戶選擇數(shù)據(jù)后，【刪除】按鈕為激活狀態(tài)；用戶點(diǎn)擊【刪除】按鈕，顯示操作確認(rèn)彈窗，用戶點(diǎn)擊確認(rèn)按鈕執(zhí)行數(shù)據(jù)刪除操作；權(quán)限說明：僅XXXXX組的用戶有【刪除】按鈕權(quán)限。

問題解析：產(chǎn)品在為用戶提供增、刪、查、改、顯服務(wù)時(shí)，產(chǎn)品經(jīng)理需要考慮每一個(gè)動(dòng)作背后的權(quán)限問題，例如：不同賬號(hào)之間的數(shù)據(jù)查看權(quán)限。

以上三種場(chǎng)景，舉例說明我或團(tuán)隊(duì)成員輸出的需求文檔中出現(xiàn)的遺漏現(xiàn)象，這些遺漏可以概括為細(xì)節(jié)點(diǎn)和關(guān)鍵點(diǎn)的遺漏。

在最近一兩年的工作中，本人自身、項(xiàng)目團(tuán)隊(duì)、公司內(nèi)發(fā)生的這些現(xiàn)象，對(duì)我造成了很大的困擾?？此撇粐?yán)重的問題的，但是久而久之對(duì)產(chǎn)品經(jīng)理個(gè)人、對(duì)項(xiàng)目團(tuán)隊(duì)、對(duì)公司會(huì)產(chǎn)生不可估量的影響，例如：

1. 需求文檔中頻繁出現(xiàn)的細(xì)節(jié)遺漏或關(guān)鍵性的遺漏，會(huì)給開發(fā)、測(cè)試造成不必要的困擾，久而久之可能導(dǎo)致開發(fā)、測(cè)試同事對(duì)產(chǎn)品經(jīng)理專業(yè)性的質(zhì)疑，從而影響產(chǎn)品經(jīng)理在項(xiàng)目團(tuán)隊(duì)中的公信力。
2. 需求文檔中的遺漏，必然會(huì)在需求開發(fā)階段、測(cè)試階段增加溝通的次數(shù)，這種因產(chǎn)品經(jīng)理的造成的問題的溝通的過程中，有可能會(huì)發(fā)生摩擦，這種摩擦就有可能影響項(xiàng)目團(tuán)隊(duì)的氛圍。

以上兩點(diǎn)分別從產(chǎn)品經(jīng)理個(gè)人和項(xiàng)目團(tuán)隊(duì)的角度，闡述了需求文檔的遺漏可能造成的影響，從這個(gè)因果關(guān)系當(dāng)中，不難推出，如這種現(xiàn)象得不到控制并減少，最終影響的公司的經(jīng)濟(jì)與效率。

各位同道中的人，你或你們的同事，在輸出需求文檔的過程中，是否遇到過類似的情況，你們是怎么解決看待并解決類似問的呢？

一、如何避免

1. 是如何發(fā)生的？

基于發(fā)生在自己和同事身上的案例來看，造成以上種種現(xiàn)象的原因主要有兩方面：

1) 經(jīng)驗(yàn)限制：例如剛?cè)胄械男氯?，由于自身?jīng)驗(yàn)不足的限制，對(duì)需求里面涉及到相關(guān)點(diǎn)或?qū)π枨笊婕暗年P(guān)鍵點(diǎn)分析不足，造成需求文檔遺漏，如此除了專業(yè)技能的加強(qiáng)與學(xué)習(xí)，可以多多參考團(tuán)隊(duì)中前輩的方法與經(jīng)驗(yàn)。

2) 細(xì)節(jié)執(zhí)行：生活、工作中，總有人聲稱自己十分注重細(xì)節(jié)，但是在實(shí)際工作執(zhí)行中時(shí)不時(shí)犯細(xì)節(jié)上的問題，例如本文開篇舉例的三個(gè)場(chǎng)景的現(xiàn)象，這里面的原因包含很多的主觀或客觀因素，在這里不展開去闡述。

2. 它們是什么？

需求文檔是產(chǎn)品經(jīng)理以“產(chǎn)品”作為描述對(duì)象產(chǎn)出的文檔，主要的組成部分包括：文檔變更歷史、背景&目標(biāo)、文檔約定、系統(tǒng)概述、功能描述、非功能需求……等，其中功能描述是最重要的組成部分之一，那么我們?cè)趯?duì)產(chǎn)品的功能進(jìn)行需求描述時(shí)，究竟在描述些什么東西呢？

產(chǎn)品是用戶與公司業(yè)務(wù)之間的橋梁，從用戶以及自身使用產(chǎn)品的過程來看，無論是常規(guī)的互聯(lián)網(wǎng)產(chǎn)品，還是B端的業(yè)務(wù)系統(tǒng)，從產(chǎn)品的實(shí)現(xiàn)層面來講，其實(shí)都是在為用戶提供增、刪、改、查、顯服務(wù)，例如：

• 用戶填寫并提交賬號(hào)注冊(cè)表單，這屬于新增。
• 用戶刪除過去已經(jīng)發(fā)表微博或朋友圈，這屬于刪除。
• 吃瓜群眾在微博中搜索“吳簽”的信息，這屬于查詢。
• 微信→發(fā)現(xiàn)→朋友圈，可以查看朋友和自己發(fā)的朋友圈內(nèi)容，這屬于顯（反饋）。
• 修改微信綁定的手機(jī)號(hào)，這屬于修改。

既然可以機(jī)械化的將產(chǎn)品理解為是在為用戶提供增、刪、改、查、顯服務(wù)，那么在假設(shè)需求的真?zhèn)?、需求的價(jià)值、解決方案的設(shè)計(jì)……一切都已OK的情況下，需求文檔功能部分的描述其實(shí)是在對(duì)增、刪、改、查、顯用戶界面中元素規(guī)則以及數(shù)據(jù)交互規(guī)則、權(quán)限規(guī)則等關(guān)鍵點(diǎn)的描述。

以上圖“創(chuàng)建企業(yè)”表單為例：需求文檔需分別描述：企業(yè)名稱、公司對(duì)外聯(lián)系郵箱、所屬行業(yè)三個(gè)字段的規(guī)則和按鈕規(guī)則，例如：

1. 企業(yè)名稱字段是否必填，字符長(zhǎng)度限制是多少，是否允許輸入特殊字符，異常提示是什么。
2. 用戶點(diǎn)擊完成按鈕時(shí)，需校驗(yàn)表單的合法性，合法則允許提交表單，不合法則限制提交數(shù)據(jù)，并顯示異常提示。
3. 數(shù)據(jù)唯一性?：提交數(shù)據(jù)時(shí)，需校驗(yàn)是否存在名稱相同的數(shù)據(jù)，如存在則限制提交數(shù)據(jù)，并?提示異常。

?

3. 我的嘗試？

如果將所有問題籠統(tǒng)的分類為經(jīng)歷過的和未經(jīng)歷過的或常見場(chǎng)景的問題和非常見場(chǎng)景的問題，那么針對(duì)那些經(jīng)歷過的問題或常見場(chǎng)景的問題通過復(fù)盤總結(jié)：認(rèn)識(shí)問題→ 設(shè)計(jì)解決方案→ 執(zhí)行→ 修正→ 總結(jié)，是可以找出通用的解決方案的，例如各行業(yè)的軟/硬件產(chǎn)品的通用方案的解。

在解決自身需求文檔遺漏問題的過程中，我利用以下思路將需求描述用通用的模板去規(guī)范自己的需求描述，避免需求文檔在關(guān)鍵點(diǎn)或細(xì)節(jié)上的遺漏。

1）避免關(guān)鍵遺漏

在輸出需求文檔的過程中，要避免關(guān)鍵部分的遺漏，就需要了解一份完整的需求文檔包含哪些關(guān)鍵部分。上圖是我們團(tuán)隊(duì)使用的標(biāo)準(zhǔn)的需求文檔框架，每次寫需求前和在需求文檔完成后，都會(huì)基于自用的標(biāo)準(zhǔn)進(jìn)行自查，看看是不是有哪個(gè)關(guān)鍵部分的內(nèi)容被遺漏。

2）避免細(xì)節(jié)遺漏

由產(chǎn)品是在為用戶提供增、刪、改、查、顯服務(wù)，可以得出需求文檔中，具體的功能需求描述其實(shí)是在增、刪、改、查、顯規(guī)則的描述。

基于自身和團(tuán)隊(duì)成員的情況，以及根據(jù)增、刪、改、查、顯動(dòng)作涉及到的關(guān)鍵需求點(diǎn)，將需求描述模板化。

這樣的模板對(duì)于自身而言：一方面可以讓我清晰的知道，一個(gè)新增表單的需求描述有哪些關(guān)鍵點(diǎn)需要注意、需要描述，例如：企業(yè)名稱字段，在需求描述時(shí)要描述字段的編輯規(guī)則、交互規(guī)則、校驗(yàn)規(guī)則等；另外，在文檔輸出的過程中，只需要根據(jù)模板要求，將相應(yīng)的需求描述填充上去即可，可以在一定程度上避免細(xì)節(jié)點(diǎn)的遺漏。

作者：汪童學(xué)；公眾號(hào)：汪童學(xué)

本文由@汪童學(xué) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議