從需求分析到產品設計的思考框架

互聯網打工人肯定聽過這樣一句話：“既不會開發？又不會設計？又想當個經理？那隻能去做產品經理了”每天開開會、畫畫圖、寫寫文檔、讓程序猿乾乾活——總結一下就是“錢多事少有人管”。那產品經理的工作真像大家想象的這麼舒服嗎？

現實往往是方案做完之後，經常面臨無數輪的修改工作，甚至到了開發階段，才發現沒辦法實現需要推翻重來的尷尬情況。

下面介紹下由腦花總結的“從需求分析到產品設計的思考框架“，通過使用思考框架能夠在一定程度能避免上面出現的問題（反覆修改、推翻重來）。框架主要從方案的充分性、適當性、全面性進行搭建，希望能給各位同行帶來一定啓發，同時也邀請各位一起完善。

01 框架介紹

框架分為兩個階段：產品思考、產品方案。

產品思考階段，需要想清楚幾個問題：需求背景、需求目的、功能定位、限制條件。這些問題看着都很虛，實際上是在明確需求邊界，同時也是產品經理在設計產品方案階段的指導思想和第一原則。

產品方案階段，是指為達成需求目的所需要做的事及如何去做。此時輸出物的種類非常多，如產品原型、產品需求文檔、埋點表、數據需求等。主要作用是幫助項目成員更準確、全面的理解需求，以便更好的實現產品方案，同時也是幫助產品經理更全面的梳理需求，重新驗證方案自洽性。

1. 產品思考

1）需求背景及目的

這裏借用亨利·福特的“一匹更快的馬”故事做一個舉例，若用户分別在“着急趕路”和“賭馬”的場景下提出，所提供的方案是完全不一樣。針對趕路場景，用户希望的是最短時間內到達目的地，我們可以提供“汽車”、“高鐵”、“飛機”等比原方案更優的解決方案；針對賭馬場景，用户目的就是贏下比賽，僅需提供一匹快馬即可。

顯然相同描述在不同場景下的目的有可能是完全不一樣。產品經理在設計產品方案前一定要先明確背景（背景不僅限於具象化的場景，還有需求之外的“話外音”）及目標，這樣可有效避免產品方案的方向性錯誤。

另外在產品方案階段出現兩個設計方案爭議不下時，就要把“目標”拿來出，看看哪個方案對目標有更積極作用，否則堅決放棄該方案。

2）功能定位

很多人聽到“定位”這個詞會覺得很虛，摸不着頭腦。腦花查閲相關資料及請教大佬之後得到初步結論：定位包含兩個因素：目標用户和想要解決的問題。這裏以微信和陌陌兩款社交通訊產品舉例。兩款產品本質都屬於通訊工具產品，但由於產品定位的差異，兩款產品所呈現的調性是截然不同。

3）限制因素

任何需求都有一定限制因素，如上線時間、開發資源、技術架構、行業合規等因素限制。通過明確限制因素可以確保方案的可行性及適當性。

接着上面的“趕路場景”舉例説明：若用户是準備從深圳趕往北京，那可選擇“高鐵“、“飛機”等出行方式，如果不考慮成本因素，甚至可以選擇“私人飛機”的方式（這是不可能的）。

都説產品經理是CEO的學前班，那產品經理和CEO之間又有哪些異同點呢？首先共同點是兩個崗位都是重決策的崗位，他們做任何決策都會影響到全公司或項目組成員。差異點是在資源上的差異，老闆擁有全公司的資源，而產品經理只能是靠人格魅力去爭取資源了。所以説產品經理就是帶着枷鎖進行決策。

產品思考階段的工作對產品方案的具有指導意義，決定着產品方案是否能有效解決需求，脱離產品思考基礎行產品方案設計是沒有意義的。所以接到需求時，先不要着急動手去畫原型、寫文檔，而是先把需求背景、目的想清楚，確認功能的定位後，再開始原型和需求文檔的工作。

2. 產品方案

1）前提條件

1. 前置條件：觸發該流程的前提條件，如查看微信好友列表的前置條件為“註冊且登錄微信賬號”；
2. 數據來源：流程中數據來源，如審核功能中：審核人員審批審下級發起的審核單。審核人員的操作流程中，下部發起審核產生審批單就是審核人員的操作流程中的數據來源；數據來源通常是在發生數據流轉的場景下需要進行説明。
3. 角色及權限：即用户在系統中承擔的作用的抽象，C端角色通常是由產品經理和運營人員一起來定義的，並將角色和賬號進行綁定，B端業務相對複雜，往往是設定“超級管理員”賬號，然後將權限管理產品化，讓運營人員自定義角色。關於權限管理功能設計大家可自行查閲資料，這裏不過多贅述。

2）操作流程

1. 事件：主要是指功能的交互規則及邏輯判斷。這個模塊用來説明用户和系統之間發生的交互。交互規則是泛指的交互規則，包含功能的頁面佈局、觸發功能的動作及觸發後的交互效果；邏輯判斷則是指當用户在前端發生行為，系統對用户行為進行識別、判斷並返回相應的動作的過程。
2. 事件影響：指用户與系統完成交互後，用户和系統會得到什麼樣的反饋及產生什麼樣的數據和結果。
3. 異常流程：是對主流程補充，我們儘可能全的羅列並寫清楚異常流程時，可以有效避免在產品設計時的場景遺漏。異常流程的梳理建議是參考測試同事的正反例原則。

3）通用説明

1. 數據埋點：埋點就不多進行贅述，但不管是採用第三方系統還是自己的埋點體系，都要做好數據分類，後續提取數據時能減少很多功夫。
2. 數據需求：主要為業務方和產品經理在使用和運營提供決策依據，在設計產品方案時一定要規劃相對的監控數據指標，以便於後續運營和迭代時有數據進行支撐。

產品方案階段，主要是説明產品設計及需求文檔輸出階段需要考慮的因素，但更多是起到自檢的作用，一定程度上能減少產品經理在輸出原型和需求説明文檔時遺落邏輯及關鍵點。

通過對框架的整體説明，相信大家可以比較清晰認知兩個階段作用。在產品思考階段，是讓我們想清楚為什麼要做這個功能，應該往哪個方向去做；在產品方案階段，則是提供一個思路自查原型和需求文檔考慮是否全面，需求是否説清楚。

02 總結

可以發現，產品思考階段沒有明確的輸出物，也沒可量化的標準進行衡量，同時它又佔據產品經理的大量時間，而最終的工作成果又都是在產品方案階段才有所體現，也就導致不瞭解產品崗位的人，甚至產品“工具人”（曾經的腦花）也會產生這樣的認識：“產品經理接收到需求後，照着競品畫原型讓開發把功能實現就可以了”。

他們都忽略了產品最核心且無形的工作——思考。正如冰山效應一樣，大家只看到水面上的冰山，沒看到水面下的山體，但水面下的冰山確實表象上的數倍。

使用思考框架短期內不能給你帶來能力明顯的提升，甚至會影響工作效率；但從長期而言，它能從思維上幫助我們形成更加體系化、系統化的思考模式，以保證我們的工作是有意義的且相對全面的。

當然腦花整理的框架不一定適合所有人，但請一定要搭建自己的思考模型。因為搭建思考框架的過程本質上是對過往工作的抽象及總結，而這兩項能力也是產品經理最基礎及核心的能力之一。

本文由 @Jarrett 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。