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

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

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

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

一、提出這個問題的目的

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

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

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

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

二、舉個例子

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

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

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

▲個人中心頁

▲頭像大圖

基本需求說明

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

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

對每個點的二級細化補充

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

似乎已經(jīng)很完善了，還可以更細化嗎？

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

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

……

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

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

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

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

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

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

1. 頁面拆解

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

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

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

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

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

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

2. 整體需求自查

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

3. MECE原則檢查

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

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

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

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

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

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

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

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

四、總結與思考

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

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

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

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

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