《從點子到產品》—— 劉飛老師

本書目錄

如何找到產品價值和用戶痛點——《從點子到產品》01筆記
從需求分析到功能設計——《從點子到產品》02筆記
PM如何管理好產品——《從點子到產品》03筆記

一、文檔管理

什么是好的文檔？

能夠減少甚至免除在開發過程中技術人員跟產品經理溝通的文檔就是好文檔。

好文檔的幾個條件：

1. 沒有邏輯硬傷
2. 沒有疏漏
3. 邏輯清晰
4. 可讀性強：盡量提供數據、信息、流程展示圖

文檔邏輯

功能框架邏輯

• 拆分：羅列所有要做的功能點
• 組合：根據模塊將功能重新組合

業務流程邏輯

• 面向事件：完成某個事件需要多部操作，一般使用流程圖來描述（用戶執行的操作流程）。
• 面向對象：在對象的整個生命周期里，涉及所有完整的功能的使用（某個功能的完整流轉，例如訂單）。

描述功能時注意事項

• 完整：盡可能列舉所有的情況，關注功能可能產生的變化，如果描述內容比較復雜，可以用表格來展示。
• 考慮所有的影響點：增加/修改某些功能，可能會對其他的功能產生影響，盡力排查。
• 條件判斷清晰：什么條件下產生/觸發什么功能，需要羅列清晰，參考if/else、while、switch
• 含義明確：盡量不使用縮寫和特殊詞匯，保證高效溝通。
• 敘述場景：敘述功能的背景及達到的目的。

需求用例模板

| 用例名 | 描述 |
| :---------------: |:-- --:|
| 場景 | 當前使用的場景 |
| 用戶需求 | 具體解決用戶什么問題 |
| 前置條件 | 完成該功能點的前提條件 |
| 需求詳述 | 描述該功能點所能實現的業務功能 |
| 后置條件 | 完成該功能點產生的結果 |
| 補充說明 | 如有例外或特殊情況補充說明 |

二、需求管理

獲取需求階段

1. 判斷需求

• 判斷需求重要性
• 考慮需求來源
• 了解需求背景

2. 記錄需求

• 記錄格式：“來源+問題（背景）+方案（需求描述）”建立需求池（Excel）。
• 不該記的需求：沒說清楚原因的需求，說不清邏輯的需求，不是實際遇到的需求。

討論和設計階段

1. 判斷需求的優先級

四象限法則（非書內原圖）

重要程度排序

• 不做，會造成嚴重的問題和惡劣的影響
• 做了，會產生巨大好處喝極佳效果
• 跟核心用戶利益有關
• 跟大部分用戶利益有關
• 跟效率或成本有關
• 跟用戶體驗有關

判斷緊急程度

• 不做，錯誤會持續的發生并造成嚴重影響
• 在一定時間內可控但長期會有糟糕的影響
• 做了，里可能解決很多問題、產生正面的影響
• 做了，在一段時間后可以由良好的效果

KANO模型簡化版

必要型需求
基本的“痛點”需求，如果功能存在，用戶沒有感覺，但是功能沒有，用戶會不開心。

期待型需求
功能存在用戶會開心，功能不存在用戶會不開心，屬于最直接、最明顯的用戶需求，實現后符合用戶的心理預期。

驚喜型需求
用戶沒有預期，功能不存在時，用戶沒有感覺，但功能存在用戶會很開心，超出用戶的預期。

2.方案草稿
針對待解決的問題，先討論方案，如果涉及到其他業務部門，達成共識后，繼續推進。

3.指定負責人
按照模塊進行分配，并設計職責的邊界。

4.劃定時間節點
設定Dealine，建議最長不超過一周的時間，同時將需求的狀態提供給需求的來源方。

待開發階段

1. 方案可行性評估：提出方案的實現細節，并評估是否有可行性。
2. 有沒有更好的方案：給技術部門灌輸需求背景，思考是否有跟多可行性方案或思路。
3. 涉及的產品和技術環節有哪些：如果涉及影響其他產品線，需要技術評估那些人需要知情或參與評估。
4. 方案的成本評估：除了評估人力、資源、時間等表面成本，也要考慮服務器、帶寬等隱性成本。
5. 討論結束：輸出嚴謹的可執行方案，如果沒有達成一致，也要確認下一次解決問題的時間節點。

開發階段

開發優先級排序
兩個維度：重要緊急程度、開發成本
開發順序：1-9

開發階段注意事項

• 提交開發后，關閉本次迭代需求
• 避免技術方案不完整、需求方主觀改動

復盤階段

需求完成生命周期之后執行，復盤需求管理中的故障及問題，防止下次再出現。

三、工作流管理

協作管理

與技術人員常規協作

• 確保產品要求傳遞給技術人員
• 確保技術部門的意見得到了表達
• 雙方共同認可的內容予以確認
• 比較復雜的功能，多進行幾次評審，拉長進入開發前的準備時間

與技術人員協作的臨時狀況（緊急新增、修改需求）

• 理解情緒
• 解釋原委
• 提出解決辦法
• 陪同加班

與需求來源方協作
重點是需求完成的準確度和完成度，需要努力同步信息。

協作素養

• 關于心態：追求雙贏，減少對抗和壓制。
• 關于開會：嚴格圍繞討論范圍和主題，并輸出結論。
• 關于記錄

1. 文檔記錄：再小的需求也要更新到文檔。
2. 會議記錄：主要記錄討論節點和結論，以最終發出的郵件為準。
3. 想法和思路：主要用于備忘。

流程管理

協作標準化和流程化

1. 所有需求由郵件提出，記錄需求并明確負責人。
2. 對接多個業務方時，固定接口人，防止未達成一致的需求、重復設計需求等。
3. 需求狀態固定時間發布，讓需求方放心，并了解當前推進的狀態。
4. 有延期的需求，需要告知需求方，并告知原委。

減少手工勞動
使用協作軟件，解決需求協同管理的問題。

讓一些工作可復用

1. 原型交互做成模塊化，可復用，遵循視覺和邏輯的統一。
2. 話術、文案根據不同的場景（警告、提醒、解釋說明），統一規范表達。

避免重復犯錯
通過找到犯錯的原因，加強管控。

1. 由于疏漏導致。
2. 由于信息不全、知識不完備導致。
3. 由于沒有責任心導致。
4. 由于無法勝任導致。

個人管理

任務管理
常見的陷阱

1. 把焦急當做任務的緊急程度。
2. 把充實感當做完成任務。
3. 眼光不夠長遠，只做半衰期短的事情。
4. 不設置截止日期。
5. 不檢視效果。

知識管理
通過在線筆記儲備知識（參考筆記術）

團隊管理

1. 提升專業技能服眾
2. 提升管理技能