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

案例1:

錯誤示范：公司名稱字段字符長度限制為50個字符，不可為空。

正確示范：公司名稱字段長度限制為50個字符；不可為空，異常提示：請輸入公司名稱。

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

案例2：

錯誤示范：手機號字段字符長度限制為11個字符，只能輸入數(shù)字；不可為空，異常提示：請輸入手機號；手機號格式校驗，異常提示：手機號格式錯誤，請重新輸入。

正確示范：手機號字段字符長度限制為11個字符，只能輸入數(shù)字，文本框獲取焦點時彈出數(shù)字鍵盤；不可為空，異常提示：請輸入手機號；手機號格式校驗，異常提示：手機號格式錯誤，請重新輸入。

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

案例3：

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

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

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

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

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

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

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

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

一、如何避免

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

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

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

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

2. 它們是什么？

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

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

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

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

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

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

?

3. 我的嘗試？

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

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

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

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

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

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

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

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

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

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

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