有鹿 阿裡巴巴 產品經理 昨天 12:02
優秀的產品框架能夠為產品的反覆運算和發展預留最高的自由度和可能性， 並且可以讓很多看似不同的需求以一種通用的方式被解決掉， 從而降低產品複用和推廣的成本， 增加產品調整和試錯的空間。
如果說排優先順序是對開發資源的合理利用， 那麼設計一個合理的產品框架則是為你的產品創造了一個效能更高的驅動能源。
作為探討這個課題的系列之一， 本篇分享的是產品設計早期應該注意的一個主題：「提升產品的靈活度」。
提升產品的靈活度， 核心要解決的問題是：在開發成本不明顯升高的前提下， 設計出靈活度高的功能， 使產品滿足盡可能多的使用場景。
這需要產品經理能夠預判產品的發展方向、理解技術實現的成本、抽象總結出需求中需要靈活設計的部分。 大概花費了兩年時間探索和嘗試， 我總結出了以下幾個有效的方法：
一、看三做一不要孤立的看待某次改版和某個接到的需求， 在思考當前需求時， 對下個版本（甚至接下來三個版本）的需求要有比較清晰的預判和認知。 然後去將後續版本中可能調整的地方在本期的需求裡預留可拓展性。
如何操作：
可以通過預設一些框架性的問題， 去幫助自己實現這一點。
問題示例如：當前版本上線後， 資料大概會有幾種可能？→各種可能下， 產品的應對策略應該是什麼？→屆時會產生哪些優化點？→哪些優化點是出現的概率比較高的？哪些優化點是對產品目標説明較大的？→這些優化點對當前的需求的改動有多大？→當前需求做什麼調整可以相容後續的需求？
鍛煉方法：
每次提需求前都做上述問題的預設， 然後在上線後， 認真對自己的預設進行複盤， 觀察自己容易遺漏的情況是什麼。
多參與其他同事的分享和討論， 理解其他產品的反覆運算思路， 培養對各種產品優化方向的基本感知。
關注、保留一些優秀產品的各版本截圖， 以及查看它們的 App Store 更新說明， 思考為什麼它們在某個版本做了某些功能。
除了實現自己的規劃和方向外， 在進行產品設計前， 還要兼顧其他項目角色可能會產生的需求。 要學會站在其他角色的視角給自己提需求， 去試圖列舉運營、老闆、合作業務方， 在不同的時間、場景、目標下， 對同一個產品上線後的反應和後續的需求會是什麼。 一旦你對其他角色對產品的需求理解的比他們自己更深入， 就不會再經常面臨「被動接需求」的局面。
如何操作：
最好的方式是親自去那個崗位工作一小段時間， 如果沒條件實現， 依然可以通過預設一些框架性的問題， 去幫助自己實現這一點。
問題示例如：他出於什麼動機提出的這個需求？→如果當前需求的資料結果不能滿足他的動機， 他可能會提出什麼需求？→這個動機下，
鍛煉方法：
扮演其他角色的back up， 站在對方的視角去思考日常要面臨的問題。
寫測試用例， 留意當前需求對邊緣情況的覆蓋度， 然後形成不忘記思考邊緣情況處理方式的思維習慣。
閱讀其他角色的週報， 留意各個角色工作的重點和目標， 説明理解對方的需求動機。
三、理解技術方案：如果不理解開發的技術方案， 產品經理提出的需求很容易是「需求量增加」而不是「靈活度增加」的方案， 會在PRD評審時遇到很大的阻力。
如何操作：
理解基本的前端、用戶端、服務端的交互關係；
評估出每一個功能的實現需要哪些角色， 其中由誰實現成本低、由誰實現更靈活；
甚至在技術方案評審時， 能夠抛磚引玉， 幫助開發提出靈活度更高的技術方案；
鍛煉方法：
向認識的每一個開發請教他設計的技術方案， 尤其是能夠擔當技術PM的那些， 邀請他們幫你理解整個產品在系統架構上的分佈關係。
認真參與技術評審， 理解每個開發之間的邊界、調用方式、交互關係。
閱讀開發文檔， 別怕難，代碼比你想像的要容易和簡潔，且通常會有注釋。
研究開發寫的系統架構圖的設計思路，對產品自己畫產品框架圖亦有好處。
常流覽技術相關論壇，瞭解解決一個常規的產品問題，最新的技術方案和思路是什麼。
四、抽象和正確組合按照上述步驟操作，你基本上可以收集到自己所負責的產品80%以上可能衍生的需求，並且能夠對每一個需求的實現成本有所預判。接下來，需要根據自己收集到需求的實際情況進行歸類，如：UI&文字改造的需求、資訊表達結構的需求、觸發－執行動作的邏輯等，然後去組合出需求的共性，將其中需要提供多種選擇的功能抽象出來，形成自己最終的產品需求。
如何操作：
將需求中「需要經常調整、配置的地方」設計成配置項，由後臺的某個開關來控制（可以邀請你的開發一起幫忙設計開關的方案）。通常UI/文案/展現邏輯等，均可做成配置項。記得在產品還沒開發前就儘量將所有需要抽離配置的地方預設好，此時是成本最低的，一旦產品框架確定後，要再抽離出配置項，複雜度就會上升。
將通用和基礎的部分抽離成一整個功能模組，個性化、定制、可變的部分抽離成另一個流程。通常來說，一個產品核心的主流程一定是邏輯相對固定的，在主流程上的分支流程需求變化較大，將主流程和分支流程分開設計、分別開發，會大大提高產品的靈活度。
在PRD中標明某處需要「預留擴展性」，在評審時提醒開發同學要注意技術方案的設計，要選擇對後續方向來說開發成本最低的方案，而不是當前需求下成本最低的方案。
鍛煉方法：
擴大自己對產品的理解，哪怕是使用者端產品，也要多去瞭解一些平臺型產品、B端產品、商業產品的產品設計思路和方案。
多參考被別人誇讚為「很靈活」的產品，或者仔細研究「有幾年歷史」的產品，通常這些產品會整合了眾多複雜的功能，並且在反覆運算中衍生出了合理的配置項和主流程、分支流程的設計。
親身實踐，吸取教訓，舉一反三。即使嚴格按照以上流程去思考和操作，也一定有自己預期外的情況出現，好的產品經理是必然花費諸多金錢和時間才能在實踐中鍛煉出來的。
千萬別忘記，停留在「排優先順序」層面的產品經理多如牛毛，在「產品框架設計」層面上的競爭才是產品經理的核心戰場。當你發現80%的意外情況（跟自己產品相關的突發事件/老闆心血來潮提的新idea……等）下，自己的產品不需要額外開發即可解決問題，那麼恭喜你，這一課你畢業了。
——————
關於作者：
（知了Club）
（現在就去搜索添加關注！）
出於對PMCAFF用戶的尊重，任何在PMCAFF產品經理社區發佈的內容，在未經允許的情況下，不得在任何平臺被直接或間接發佈使用或被用於其他任何商業目的。如有違反上述聲明者本網站將追究其相關法律責任。
投稿郵箱：tougao@pmcaff.com
Greated by PMCAFF產品經理社區 - www.pmcaff.com
別怕難，代碼比你想像的要容易和簡潔，且通常會有注釋。研究開發寫的系統架構圖的設計思路，對產品自己畫產品框架圖亦有好處。
常流覽技術相關論壇，瞭解解決一個常規的產品問題，最新的技術方案和思路是什麼。
四、抽象和正確組合按照上述步驟操作，你基本上可以收集到自己所負責的產品80%以上可能衍生的需求，並且能夠對每一個需求的實現成本有所預判。接下來，需要根據自己收集到需求的實際情況進行歸類，如：UI&文字改造的需求、資訊表達結構的需求、觸發－執行動作的邏輯等，然後去組合出需求的共性，將其中需要提供多種選擇的功能抽象出來，形成自己最終的產品需求。
如何操作：
將需求中「需要經常調整、配置的地方」設計成配置項，由後臺的某個開關來控制（可以邀請你的開發一起幫忙設計開關的方案）。通常UI/文案/展現邏輯等，均可做成配置項。記得在產品還沒開發前就儘量將所有需要抽離配置的地方預設好，此時是成本最低的，一旦產品框架確定後，要再抽離出配置項，複雜度就會上升。
將通用和基礎的部分抽離成一整個功能模組，個性化、定制、可變的部分抽離成另一個流程。通常來說，一個產品核心的主流程一定是邏輯相對固定的，在主流程上的分支流程需求變化較大，將主流程和分支流程分開設計、分別開發，會大大提高產品的靈活度。
在PRD中標明某處需要「預留擴展性」，在評審時提醒開發同學要注意技術方案的設計，要選擇對後續方向來說開發成本最低的方案，而不是當前需求下成本最低的方案。
鍛煉方法：
擴大自己對產品的理解，哪怕是使用者端產品，也要多去瞭解一些平臺型產品、B端產品、商業產品的產品設計思路和方案。
多參考被別人誇讚為「很靈活」的產品，或者仔細研究「有幾年歷史」的產品，通常這些產品會整合了眾多複雜的功能，並且在反覆運算中衍生出了合理的配置項和主流程、分支流程的設計。
親身實踐，吸取教訓，舉一反三。即使嚴格按照以上流程去思考和操作，也一定有自己預期外的情況出現，好的產品經理是必然花費諸多金錢和時間才能在實踐中鍛煉出來的。
千萬別忘記，停留在「排優先順序」層面的產品經理多如牛毛，在「產品框架設計」層面上的競爭才是產品經理的核心戰場。當你發現80%的意外情況（跟自己產品相關的突發事件/老闆心血來潮提的新idea……等）下，自己的產品不需要額外開發即可解決問題，那麼恭喜你，這一課你畢業了。
——————
關於作者：
（知了Club）
（現在就去搜索添加關注！）
出於對PMCAFF用戶的尊重，任何在PMCAFF產品經理社區發佈的內容，在未經允許的情況下，不得在任何平臺被直接或間接發佈使用或被用於其他任何商業目的。如有違反上述聲明者本網站將追究其相關法律責任。
投稿郵箱：tougao@pmcaff.com
Greated by PMCAFF產品經理社區 - www.pmcaff.com