關于需求管理文檔和產品經理的腳手架思維

關于需求管理文檔和產品經理的腳手架思維今天和大家分享的文章主題是：關于需求管理文檔和產品經理的腳手架思維。顧名思義文章分為兩個部分：第一部分分享一個重要的需求管理文檔模板；第二個部分介紹一種在工作和學習過程中一種很重要的思維方式：腳手架思維。一、關于項目管理過程中一個重要的文檔好用的工具和規(guī)范的文檔讓我們所有的需求、計劃、目標以及問題都可視化的羅列，有序的處理和解決。之前的兩篇文章《產品設計規(guī)范與關乎“秩序和混亂”的人生算法》&《基于Axure的移動端APP產品設計規(guī)范》主要分享了關于Axure的工具使用規(guī)范。今天分享的是項目需求管理過程中一個重要的文檔：需求管理文檔1.需求管理文檔需求管理文檔的目的是明確項目進行過程中各個階段的任務安排和研發(fā)周期，能讓產品研發(fā)過程中的每個角色明確自己的任務以及時間安排，同時方便產品經理把控項目整體的宏觀進度。如下圖是兩種適合不同研發(fā)流程的需求管理文檔。第一種模板比較適合大公司的產品研發(fā)流程：需求設計→需求評審→UI設計/技術開發(fā)→產品測試→測試驗收→產品上線，每一個環(huán)節(jié)都有明確的負責人和執(zhí)行者以及任務的計劃時間。第二種模板比較靈活，產品研發(fā)流程中，需要哪個模塊增加哪個模塊，不需要的可以折疊或者刪除。所謂模板&工具最大的意義是提高我們的工作效率，以上提供的兩種需求管理文檔模板，大家可以根據(jù)自己日常工作中的實際需求去修改調整成適合自己的，適合的才是最好的。二、產品經理的腳手架思維之前的公司產品團隊比較大，產品研發(fā)遵循典型的瀑布型研發(fā)流程。很多時候在業(yè)務邏輯產品化的過程中，產品存在的問題都會在評審會上被其它產品經理和相關部門同事糾正，到真正開發(fā)的時候，基本不會出現(xiàn)太大的問題。但后來去了創(chuàng)業(yè)公司，一個人來設計產品，沒有標準的評審會去審視你的設計和邏輯，很多問題往往都是在已經開發(fā)的過程中暴露的，程序猿無奈，自己也很無奈。業(yè)務邏輯產品化的核心部分是：形成業(yè)務邏輯的閉環(huán)。在業(yè)務邏輯復雜的產品設計過程中，個人的思考往往很難窮盡所有的邏輯閉環(huán)。原因是當我們思考業(yè)務邏輯的時候，思維往往是發(fā)散的（想到什么就先確定是什么，然后在拼接成閉環(huán)），這樣思考方式難免會存在遺漏的地方。所以我們需要一套思考的規(guī)范，用規(guī)范來彌補大腦本身的缺陷，盡可能的幫助我們窮盡所有的業(yè)務邏輯形成閉環(huán)，這樣的“思考規(guī)范”可以稱之為“思維的腳手架”。1.窮盡業(yè)務邏輯閉環(huán)的思維腳手架：1）拆分功能模塊—實現(xiàn)模塊功能閉環(huán)：將一個大的業(yè)務需求拆分成若干個明確的功能模塊，保證每個功能模塊形成最小的模塊功能閉環(huán)。當然一些功能模塊獨立閉環(huán)，有的需要多個功能模塊共同形成邏輯閉環(huán)。2）串聯(lián)閉合的功能模塊——高內聚，低耦合，可拓展：將每個功能模塊串聯(lián)起來，保證每個功能模塊足夠的獨立，各功能模塊之間耦合度盡可能的低，不會因為一個功能模塊的修改，牽一發(fā)而動全身；其次還要保證各個功能模塊的可拓展性。3）查驗-MECE（相互獨立，完全窮盡）：根據(jù)MECE分析法，對每個功能模塊進行查驗，窮盡模塊功能閉環(huán)后，串聯(lián)起來再查驗整體的業(yè)務邏輯閉環(huán)；然后再進行產品可視化設計。2.產品可視化設計的查驗腳手架：以上基本是思維導圖和產品流程圖的設計階段，業(yè)務邏輯閉環(huán)后，開始進行產品原型的設計以及PRD文檔的輸出。這個時候，我們同樣需要一套查驗機制去彌補我們思維的局限性，這套機制或者模板足夠的窮盡和高階幫助我們修正沒有考慮到的設計和交互。如下圖：三、腳手架思維總結綜上所述，腳手架思維是一種思維方式：這種思維方式讓我們在思考和解決問題的時候能主動的去尋找并運用有效的腳手架（包括但不限于某種工具、模板、套路、原則、道理、方法論&思維方式），從而提高解決問題的效率，甚至達到事半功倍的效果。腳手架思維帶給我們的啟示是：當我們遇到問題的時候，不要僅僅局限于處理自己問題的本身