作為一名初級產(chǎn)品，面對需求方提供的混亂資料、大量的需求信息以及復(fù)雜的系統(tǒng)邏輯，你是否不知從何入手？
筆者根據(jù)自身經(jīng)歷，摸索出“數(shù)據(jù)-模塊-邏輯功能”的方法來梳理產(chǎn)品思路，解決這一難題。
方法
這種方法可以簡單概括為：整理全部信息數(shù)據(jù)；數(shù)據(jù)分類，劃分模塊；梳理數(shù)據(jù)之間、模塊之間的邏輯功能。
1. 羅列全部數(shù)據(jù)，并確保數(shù)據(jù)的完整性
數(shù)據(jù)的來源包括但不限于：
（1）需求對接的文件資料；
（2）需求方口述；
（3）頁面展示的信息。先把這些字段信息都列示到一個表格里，而我通常是用Xmind進行整理。除了這些看得見的數(shù)據(jù)，接著還要了解數(shù)據(jù)之間的邏輯處理；
（4）列出邏輯處理后的數(shù)據(jù)。
舉個例子，下圖是根據(jù)簡化的進銷存系統(tǒng)頁面列出的信息：
其中，看得見的數(shù)據(jù)如商品的屬性信息：名稱、規(guī)格；訂單信息：購買人昵稱、聯(lián)系方式、購買數(shù)量、下單時間等；而下單時長則是看不見的邏輯數(shù)據(jù)。當(dāng)訂單在30分鐘還沒付款，系統(tǒng)會主動取消訂單，所以需要通過下單時間和系統(tǒng)當(dāng)前時間計算出下單時長，提供給系統(tǒng)判斷是否需要取消該筆訂單。
難點：要確保數(shù)據(jù)的完整性，盡可能地發(fā)揮小宇宙，把所有邏輯數(shù)據(jù)都列出來。
2. 對每個數(shù)據(jù)按模塊分類，且每個數(shù)據(jù)只能在唯一一個模塊中進行維護
我一般會將模塊分為兩個大類：功能模塊和公共模塊，再根據(jù)實際項目功能劃分子類。最終，所有子類的集合就是整個系統(tǒng)的功能模塊。
功能模塊指的是系統(tǒng)功能性質(zhì)明顯的分類，如商品管理模塊、訂單管理模塊；而公共模塊更偏向于收納通用數(shù)據(jù)，如行政地區(qū)管理模塊。
功能模塊和公共模塊只是個人叫法，用于區(qū)分，其本質(zhì)都是一樣的。
舉個例子，沿用上例，下圖對各個數(shù)據(jù)進行了模塊劃分：
首先對所有數(shù)據(jù)重新分類，新增如下模塊：
（1）廣告管理：提取了商品管理中與廣告相關(guān)的信息。
（2）商品上線管理：把商品管理中“商品組合”形成新商品的數(shù)據(jù)納入其中；原來在分銷商管理中“上線商品”和“銷售價格”也分類到商品上線管理，令分銷商管理的數(shù)據(jù)信息更加純粹。
（3）用戶管理：賬戶信息系統(tǒng)，管理與用戶身份相關(guān)的信息，如性別、名稱、聯(lián)系電話等。
（4）行政地區(qū)管理：用于專門管理國家、省份、城市的行政地區(qū)劃分。
按照我的劃分方法，功能模塊包括：商品管理、廣告管理、分銷商管理、商品上線管理、訂單管理；公共模塊包括：行政地區(qū)管理、用戶管理。全部模塊組合起來，就是一個完整的進銷存系統(tǒng)。
商品管理模塊中的商品名稱、編號雖然會在商品上線管理模塊展示，也會在訂單管理模塊中展示，但只可以在商品信息管理中進行維護；同樣，行政地區(qū)管理中的國家、省份、城市數(shù)據(jù)在商品管理模塊-商品屬性-生產(chǎn)地展示，也在用戶管理模塊-聯(lián)系地址中展示，但只可以在自己的模塊中維護。
3. 對每個模塊整理功能邏輯
包括模塊內(nèi)部的功能邏輯和模塊對其他兄弟模塊提供的功能邏輯。
3.1 內(nèi)部的功能邏輯
功能涉及的所有數(shù)據(jù)，只會在該模塊里進行讀寫和運算。
舉個例子：根據(jù)訂單號查詢訂單，訂單號是訂單模塊里的數(shù)據(jù)，而查詢后的訂單列表也是訂單模塊里的數(shù)據(jù)，因此查詢就是內(nèi)部的功能邏輯。
難點：在整理內(nèi)部邏輯時，同樣要發(fā)揮小宇宙，把所有內(nèi)部邏輯列完整。
3.2 對外提供的功能邏輯
數(shù)據(jù)在A功能模塊中維護，但B功能模塊需要調(diào)用或展示；或者A功能模塊的數(shù)據(jù)經(jīng)過一定運算后得到的數(shù)據(jù)X，提供給B功能模塊，而A功能模塊本身可能并不需要數(shù)據(jù)X。
舉個例子：
以訂單管理模塊的數(shù)據(jù)為例，從上圖中可以看到訂單里顯示的商品編號、商品名稱是由商品管理模塊提供的，那么這屬于是商品管理對外提供的功能邏輯（提供數(shù)據(jù)），而不屬于訂單管理模塊的功能邏輯。
用稍微復(fù)雜的訂單價格和企業(yè)的實際收益的流程來解釋內(nèi)部的功能邏輯：
首先，由商品上線管理提供的銷售價格乘以購買的商品數(shù)量運算，得到訂單價格；該運算過程是由訂單管理模塊進行，因此是訂單管理模塊內(nèi)部的功能邏輯。
接著，再用訂單價格乘以分銷商管理模塊提供的結(jié)算費率（計算企業(yè)分成后所得），算出該筆訂單歸屬到企業(yè)的收益。這個運算過程也是訂單管理模塊內(nèi)部的功能邏輯。
而對于訂單管理模塊來說，其中一個對外提供的功能邏輯就是向用戶端提供其消費明細。
難點
（1）整理功能邏輯，實際就是分析每個數(shù)據(jù)的來源和歸屬模塊。在這個過程中，可能會發(fā)現(xiàn)最初的數(shù)據(jù)分類有誤，實際的邏輯運算應(yīng)該在另一個模塊里完成。不用覺得自己沒考慮周全，多分析幾次，積累實踐經(jīng)驗后，就能迅速準(zhǔn)確地判斷每一個數(shù)據(jù)到底來自于哪個模塊。
（2）其次，也可能會發(fā)現(xiàn)數(shù)據(jù)羅列不完整而需要后續(xù)進行補充。因為數(shù)據(jù)的完整性能一定程度保證功能邏輯的完整，而功能邏輯完整了，才能保證系統(tǒng)的業(yè)務(wù)流程形成閉環(huán)。這也是為什么一直強調(diào)要把數(shù)據(jù)列完整的原因。
結(jié)語
處理完上述的過程，得到的就是一份信息和功能架構(gòu)圖了。根據(jù)這圖進行原型設(shè)計，有助于避免數(shù)據(jù)和功能的遺漏。
以上便是個人歸納的其中一種需求整理方法。后來在項目對接中也經(jīng)常使用，對梳理項目思路起到了很好的輔助，希望能給剛?cè)胄胁痪玫漠a(chǎn)品們一點點啟發(fā)，同時歡迎各位前輩指導(dǎo)和分享。
愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導(dǎo)、進階學(xué)習(xí)的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）
【轉(zhuǎn)載說明】 若上述素材出現(xiàn)侵權(quán)，請及時聯(lián)系我們刪除及進行處理：[email protected]
