寫需求文檔對于產品經理而言是一個逃不掉的工作內容，只有多總結多反思，積累經驗教訓，才能更好的與開發(fā)探（si）討（bi）。

在互聯(lián)網行業(yè)，一個需求要得到實現，首先需要產品經理對需求進行評估和提煉，轉化為一個可實施的具體方案，然后拆解、細化方案，通過需求文檔描述清楚這個方案，再給到研發(fā)人員進行實施。

方案越細致，研發(fā)過程溝通成本就越低，實現的效率就越高。

然而寫需求文檔就像寫文章，沒有嚴格的標準，每個人寫的習慣不一樣，每個公司的要求也不一樣。所以需求方案到底需要拆解到什么程度？如何來衡量方案拆解的程度是否足夠細致？

一、提出這個問題的目的

一方面，從我個人工作經歷來看，在推進一個需求至上線的過程中，消耗時間最多環(huán)節(jié)的除了規(guī)劃階段，就是在開發(fā)測試階段，往往會由于對細節(jié)點描述不夠全面，在開發(fā)測試階段需要頻繁溝通。

對需求方案拆解這個問題的思考總結，希望可以鞭策自己在面對每一個需求的時候完善更多細節(jié)，提高需求質量，并思考每個細節(jié)實現背后的原因，從而提升對每個需求本質的理解深度。

另一方面，業(yè)務方如果能更加清晰的了解到產品經理在完成一個需求方案的時候具體的工作內容及流程，就可以在需求溝通時提供更完善的信息，以減少產品經理完善需求方案時與業(yè)務方的反復溝通確認，甚至避免由于理解業(yè)務偏差導致最后上線的產品不符合業(yè)務需求。

一個需求方案到底可以被拆解到什么程度，下面舉個例子來感受一下。

二、舉個例子

對于一個APP的個人中心，點擊頭像縮略圖查看大頭像的這個小功能，會涉及到哪些需求點？

我們可以飛速的思考幾秒鐘。

根據我們使用APP的多年經驗，這似乎是個很常見很小的功能點，點擊小圖看大圖，點擊大圖回到小圖就完事了，事實真的是這樣嗎？那么下面我來一一列舉一下。

▲個人中心頁

▲頭像大圖

基本需求說明

1. 默認展示頭像原圖的縮略圖；
2. 點擊縮略圖，全屏展示原圖；
3. 點擊原圖時，關閉全屏，返回個人中心頁。

看起來三個大點已經描述清楚了這個功能，但這只是用戶的操作主路徑，還不是一個需求說明該有的樣子，每一個點還有很多需要補充的內容。

對每個點的二級細化補充

1. 縮略圖的尺寸為原圖等比例縮放，縮略圖是以原圖的對角線中心為圓點切成的一個圓形，直徑大小為圖片的寬度；
2. 全屏展示原圖時，支持保存圖片，長按頁面彈出保存圖片按鈕，保存成功后提示，文案為“保存成功”；
3. 如保存圖片時，APP沒有相機權限，此時應先彈出獲取系統(tǒng)相機權限；
4. 支持更換頭像，并顯示修改頭像按鈕，點擊按鈕支持從相冊選擇及拍照上傳；
5. 點擊縮略圖進入展示原圖過程中，是否需要loading動畫，如果加載原圖失敗，如何展示？

似乎已經很完善了，還可以更細化嗎？

繼續(xù)增加三級細化補充

1. 全屏展示原圖時，手指捏合可以放大縮小圖片，放大到多大時無法再放大，手指捏合縮小時，圖片最小顯示寬度為圖片寬度；
2. APP是否支持橫屏顯示，橫屏時原圖是否根據橫屏的高度撐滿屏幕高度；
3. 上傳的新頭像時是否支持預覽，預覽頁面是否支持對圖片進行編輯，圖片是否需要壓縮上傳，壓縮比例如何？
4. 用戶是否需要查看歷史的頭像，是否需要還原上次頭像的功能？
5. 更換頭像、保持圖片的功能是做成集合按鈕，還是在長按彈出的組件中？

……

通過這個例子我們可以很直觀的感受到，一個看起來很簡單的需求，背后需要處理的邏輯是很多的。

如果產品經理在規(guī)劃階段沒有考慮到，就可能在開發(fā)測試階段暴露出來，產品經理需要在開發(fā)周期中補充方案，甚至有的問題是上線后才收到用戶的反饋，這種情況需要開發(fā)測試同學的返工或緊急發(fā)版修復，既影響用戶體驗，又浪費開發(fā)資源。

既然需求方案的細化程度如此重要，如何系統(tǒng)化的思考并拆解呢？

三、系統(tǒng)化拆解需求細節(jié)

一個大型項目的方案拆解是個很復雜的工作，需要豐富的項目經驗及結構化的思維。

以下僅針對在確定了整體方案的前提下，對涉及到頁面層面的需求拆解方法。

1. 頁面拆解

首先，每個頁面都有進入和跳出的條件，如登錄狀態(tài)、用戶身份、權限、網絡限制等，梳理與上一個、下一個頁面的邏輯關系，把每個頁面這樣的邏輯串起來其實就是整個系統(tǒng)的頁面流程圖。

其次，有哪些原始數據通過怎么的方式進入該頁面，數據在頁面是如何產生的，最后在該頁面如何提交與儲存。

數據就像頁面的血液，是時刻變化的動態(tài)量，但只要關心每個頁面進入時和跳出時的數據，就能掌握產品的整體動態(tài)數據。

最后是頁面本身的邏輯，靜態(tài)邏輯包含了用戶未進行交互操作時，展示給用戶的全部邏輯，如間距、字體、顏色、聲音、動畫等；

動態(tài)邏輯即用戶進行了某個操作后可能引發(fā)的頁面所有變化，如點擊、滑動、輸入等動作引起的頁面和控件變化；

邊界限制指的是作為頁面的載體本身的一些限制，比如同一個功能在安卓系統(tǒng)和iOS的區(qū)別，原生APP與微信小程序及H5的區(qū)別等。

2. 整體需求自查

通過上述三個層面的考慮，基本可以保證一個頁面的需求不遺漏，但是可能對很多異常流考慮程度不夠，還可以用一份詳細的需求自查表來check，驗證一下是否覆蓋了大部分異常情況。

3. MECE原則檢查

通過上述方法，也許已經將每個頁面的需求考慮得非常仔細了，但不能保證多個頁面之間描述的問題沒有重復或矛盾，這時可以通過MECE原則進行全盤檢查。

MECE原則是《金字塔原理》中提出的概念，全稱Mutually Exclusive Collectively Exhaustive，指的是“相互獨立，完全窮盡”。

對于同一層級的需求點進行描述時，必須保證這些需求點之間邏輯相互獨立，否則會讓整個方案邏輯混亂，難以理解。

比如把下圖的大矩形比作一個需求方案，小正方形比作拆解的需求點，那么這樣的形式來描述這個需求就不符合MECE原則，因為三個小正方形之間有交叉重疊部分，且組合起來沒有完全填滿整個矩形。

例如本文提到的查看頭像大圖的例子，從大的需求點來拆解，如果拆解成：

1. 默認顯示頭像的縮略圖，點擊可以在大圖和縮略圖之間切換；
2. 全屏顯示大圖時，顯示保存按鈕，點擊大圖回到個人中心頁。

可以發(fā)現，這兩個大的需求點，對點擊切換頁面顯示的內容進行了重復描述，即邏輯不互相獨立。

以下的拆解方法就是典型的符合MECE原則，同一層級的需求點之間沒有交叉，互相獨立，組合起來剛好覆蓋整個需求，沒有遺漏，每個大的需求點的下一級再按照同樣的方式進行列舉，最終是一個不斷逼近整體方案的過程。

四、總結與思考

本文簡單總結了我個人工作過程中對需求方案拆解的思考，僅適用于確定了產品整體結構的情況下，對詳細需求的細節(jié)層面拆解。

這些只是日常工作的基本功，我認為做產品除了要對需求各個細節(jié)充分思考，還是一個逐漸剝離事物表象，發(fā)現本質的過程，只有產品的大方向是滿足事物本質的，需求細節(jié)的完善才會讓產品變得更精致。

作者：haven，非典型工科中年男孩，云擼貓，愛做飯；歡迎關注公眾號交流：PM何小澤

本文由 @haven 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

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