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

案例1:

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

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

問題解析：產品經理在需求描述沒有給出恰當的異常情況提示，開發在需求實現過程中按自己的理解寫了一個錯誤提示，測試環節或上線后，發現提示文案有問題然后返工，這樣的情況在我目前所在的公司是時有發生的。

案例2：

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

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

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

案例3：

錯誤示范：【刪除】按鈕默認為不可點擊狀態，用戶選擇數據后，【刪除】按鈕為激活狀態；用戶點擊【刪除】按鈕，顯示操作確認彈窗，用戶點擊確認按鈕執行數據刪除操作。

正確示范：【刪除】按鈕默認為不可點擊狀態，用戶選擇數據后，【刪除】按鈕為激活狀態；用戶點擊【刪除】按鈕，顯示操作確認彈窗，用戶點擊確認按鈕執行數據刪除操作；權限說明：僅XXXXX組的用戶有【刪除】按鈕權限。

問題解析：產品在為用戶提供增、刪、查、改、顯服務時，產品經理需要考慮每一個動作背后的權限問題，例如：不同賬號之間的數據查看權限。

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

在最近一兩年的工作中，本人自身、項目團隊、公司內發生的這些現象，對我造成了很大的困擾?？此撇粐乐氐膯栴}的，但是久而久之對產品經理個人、對項目團隊、對公司會產生不可估量的影響，例如：

1. 需求文檔中頻繁出現的細節遺漏或關鍵性的遺漏，會給開發、測試造成不必要的困擾，久而久之可能導致開發、測試同事對產品經理專業性的質疑，從而影響產品經理在項目團隊中的公信力。
2. 需求文檔中的遺漏，必然會在需求開發階段、測試階段增加溝通的次數，這種因產品經理的造成的問題的溝通的過程中，有可能會發生摩擦，這種摩擦就有可能影響項目團隊的氛圍。

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

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

一、如何避免

1. 是如何發生的？

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

1) 經驗限制：例如剛入行的新人，由于自身經驗不足的限制，對需求里面涉及到相關點或對需求涉及的關鍵點分析不足，造成需求文檔遺漏，如此除了專業技能的加強與學習，可以多多參考團隊中前輩的方法與經驗。

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

2. 它們是什么？

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

產品是用戶與公司業務之間的橋梁，從用戶以及自身使用產品的過程來看，無論是常規的互聯網產品，還是B端的業務系統，從產品的實現層面來講，其實都是在為用戶提供增、刪、改、查、顯服務，例如：

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

既然可以機械化的將產品理解為是在為用戶提供增、刪、改、查、顯服務，那么在假設需求的真偽、需求的價值、解決方案的設計……一切都已OK的情況下，需求文檔功能部分的描述其實是在對增、刪、改、查、顯用戶界面中元素規則以及數據交互規則、權限規則等關鍵點的描述。

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

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

?

3. 我的嘗試？

如果將所有問題籠統的分類為經歷過的和未經歷過的或常見場景的問題和非常見場景的問題，那么針對那些經歷過的問題或常見場景的問題通過復盤總結：認識問題→ 設計解決方案→ 執行→ 修正→ 總結，是可以找出通用的解決方案的，例如各行業的軟/硬件產品的通用方案的解。

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

1）避免關鍵遺漏

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

2）避免細節遺漏

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

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

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

作者：汪童學；公眾號：汪童學

本文由@汪童學 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議