作為一名初級(jí)產(chǎn)品，面對(duì)需求方提供的混亂資料、大量的需求信息以及復(fù)雜的系統(tǒng)邏輯，你是否不知從何入手？

筆者根據(jù)自身經(jīng)歷，摸索出“數(shù)據(jù)-模塊-邏輯功能”的方法來梳理產(chǎn)品思路，解決這一難題。

方法

這種方法可以簡單概括為：整理全部信息數(shù)據(jù)；數(shù)據(jù)分類，劃分模塊；梳理數(shù)據(jù)之間、模塊之間的邏輯功能。

1. 羅列全部數(shù)據(jù)，并確保數(shù)據(jù)的完整性

數(shù)據(jù)的來源包括但不限于：

（1）需求對(duì)接的文件資料；

（2）需求方口述；

（3）頁面展示的信息。先把這些字段信息都列示到一個(gè)表格里，而我通常是用Xmind進(jìn)行整理。除了這些看得見的數(shù)據(jù)，接著還要了解數(shù)據(jù)之間的邏輯處理；

（4）列出邏輯處理后的數(shù)據(jù)。

舉個(gè)例子，下圖是根據(jù)簡化的進(jìn)銷存系統(tǒng)頁面列出的信息：

其中，看得見的數(shù)據(jù)如商品的屬性信息：名稱、規(guī)格；訂單信息：購買人昵稱、聯(lián)系方式、購買數(shù)量、下單時(shí)間等；而下單時(shí)長則是看不見的邏輯數(shù)據(jù)。當(dāng)訂單在30分鐘還沒付款，系統(tǒng)會(huì)主動(dòng)取消訂單，所以需要通過下單時(shí)間和系統(tǒng)當(dāng)前時(shí)間計(jì)算出下單時(shí)長，提供給系統(tǒng)判斷是否需要取消該筆訂單。

難點(diǎn)：要確保數(shù)據(jù)的完整性，盡可能地發(fā)揮小宇宙，把所有邏輯數(shù)據(jù)都列出來。

2. 對(duì)每個(gè)數(shù)據(jù)按模塊分類，且每個(gè)數(shù)據(jù)只能在唯一一個(gè)模塊中進(jìn)行維護(hù)

我一般會(huì)將模塊分為兩個(gè)大類：功能模塊和公共模塊，再根據(jù)實(shí)際項(xiàng)目功能劃分子類。最終，所有子類的集合就是整個(gè)系統(tǒng)的功能模塊。

功能模塊指的是系統(tǒng)功能性質(zhì)明顯的分類，如商品管理模塊、訂單管理模塊；而公共模塊更偏向于收納通用數(shù)據(jù)，如行政地區(qū)管理模塊。

功能模塊和公共模塊只是個(gè)人叫法，用于區(qū)分，其本質(zhì)都是一樣的。

舉個(gè)例子，沿用上例，下圖對(duì)各個(gè)數(shù)據(jù)進(jìn)行了模塊劃分：

首先對(duì)所有數(shù)據(jù)重新分類，新增如下模塊：

（1）廣告管理：提取了商品管理中與廣告相關(guān)的信息。

（2）商品上線管理：把商品管理中“商品組合”形成新商品的數(shù)據(jù)納入其中；原來在分銷商管理中“上線商品”和“銷售價(jià)格”也分類到商品上線管理，令分銷商管理的數(shù)據(jù)信息更加純粹。

（3）用戶管理：賬戶信息系統(tǒng)，管理與用戶身份相關(guān)的信息，如性別、名稱、聯(lián)系電話等。

（4）行政地區(qū)管理：用于專門管理國家、省份、城市的行政地區(qū)劃分。

按照我的劃分方法，功能模塊包括：商品管理、廣告管理、分銷商管理、商品上線管理、訂單管理；公共模塊包括：行政地區(qū)管理、用戶管理。全部模塊組合起來，就是一個(gè)完整的進(jìn)銷存系統(tǒng)。

商品管理模塊中的商品名稱、編號(hào)雖然會(huì)在商品上線管理模塊展示，也會(huì)在訂單管理模塊中展示，但只可以在商品信息管理中進(jìn)行維護(hù)；同樣，行政地區(qū)管理中的國家、省份、城市數(shù)據(jù)在商品管理模塊-商品屬性-生產(chǎn)地展示，也在用戶管理模塊-聯(lián)系地址中展示，但只可以在自己的模塊中維護(hù)。

3. 對(duì)每個(gè)模塊整理功能邏輯

包括模塊內(nèi)部的功能邏輯和模塊對(duì)其他兄弟模塊提供的功能邏輯。

3.1 內(nèi)部的功能邏輯
功能涉及的所有數(shù)據(jù)，只會(huì)在該模塊里進(jìn)行讀寫和運(yùn)算。

舉個(gè)例子：根據(jù)訂單號(hào)查詢訂單，訂單號(hào)是訂單模塊里的數(shù)據(jù)，而查詢后的訂單列表也是訂單模塊里的數(shù)據(jù)，因此查詢就是內(nèi)部的功能邏輯。

難點(diǎn)：在整理內(nèi)部邏輯時(shí)，同樣要發(fā)揮小宇宙，把所有內(nèi)部邏輯列完整。

3.2 對(duì)外提供的功能邏輯
數(shù)據(jù)在A功能模塊中維護(hù)，但B功能模塊需要調(diào)用或展示；或者A功能模塊的數(shù)據(jù)經(jīng)過一定運(yùn)算后得到的數(shù)據(jù)X，提供給B功能模塊，而A功能模塊本身可能并不需要數(shù)據(jù)X。

舉個(gè)例子：

以訂單管理模塊的數(shù)據(jù)為例，從上圖中可以看到訂單里顯示的商品編號(hào)、商品名稱是由商品管理模塊提供的，那么這屬于是商品管理對(duì)外提供的功能邏輯（提供數(shù)據(jù)），而不屬于訂單管理模塊的功能邏輯。

用稍微復(fù)雜的訂單價(jià)格和企業(yè)的實(shí)際收益的流程來解釋內(nèi)部的功能邏輯：

首先，由商品上線管理提供的銷售價(jià)格乘以購買的商品數(shù)量運(yùn)算，得到訂單價(jià)格；該運(yùn)算過程是由訂單管理模塊進(jìn)行，因此是訂單管理模塊內(nèi)部的功能邏輯。

接著，再用訂單價(jià)格乘以分銷商管理模塊提供的結(jié)算費(fèi)率（計(jì)算企業(yè)分成后所得），算出該筆訂單歸屬到企業(yè)的收益。這個(gè)運(yùn)算過程也是訂單管理模塊內(nèi)部的功能邏輯。

而對(duì)于訂單管理模塊來說，其中一個(gè)對(duì)外提供的功能邏輯就是向用戶端提供其消費(fèi)明細(xì)。

難點(diǎn)

（1）整理功能邏輯，實(shí)際就是分析每個(gè)數(shù)據(jù)的來源和歸屬模塊。在這個(gè)過程中，可能會(huì)發(fā)現(xiàn)最初的數(shù)據(jù)分類有誤，實(shí)際的邏輯運(yùn)算應(yīng)該在另一個(gè)模塊里完成。不用覺得自己沒考慮周全，多分析幾次，積累實(shí)踐經(jīng)驗(yàn)后，就能迅速準(zhǔn)確地判斷每一個(gè)數(shù)據(jù)到底來自于哪個(gè)模塊。

（2）其次，也可能會(huì)發(fā)現(xiàn)數(shù)據(jù)羅列不完整而需要后續(xù)進(jìn)行補(bǔ)充。因?yàn)閿?shù)據(jù)的完整性能一定程度保證功能邏輯的完整，而功能邏輯完整了，才能保證系統(tǒng)的業(yè)務(wù)流程形成閉環(huán)。這也是為什么一直強(qiáng)調(diào)要把數(shù)據(jù)列完整的原因。

結(jié)語

處理完上述的過程，得到的就是一份信息和功能架構(gòu)圖了。根據(jù)這圖進(jìn)行原型設(shè)計(jì)，有助于避免數(shù)據(jù)和功能的遺漏。

以上便是個(gè)人歸納的其中一種需求整理方法。后來在項(xiàng)目對(duì)接中也經(jīng)常使用，對(duì)梳理項(xiàng)目思路起到了很好的輔助，希望能給剛?cè)胄胁痪玫漠a(chǎn)品們一點(diǎn)點(diǎn)啟發(fā)，同時(shí)歡迎各位前輩指導(dǎo)和分享。

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

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