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