《從點(diǎn)子到產(chǎn)品》—— 劉飛老師

本書目錄

如何找到產(chǎn)品價(jià)值和用戶痛點(diǎn)——《從點(diǎn)子到產(chǎn)品》01筆記
從需求分析到功能設(shè)計(jì)——《從點(diǎn)子到產(chǎn)品》02筆記
PM如何管理好產(chǎn)品——《從點(diǎn)子到產(chǎn)品》03筆記

一、文檔管理

什么是好的文檔？

能夠減少甚至免除在開發(fā)過程中技術(shù)人員跟產(chǎn)品經(jīng)理溝通的文檔就是好文檔。

好文檔的幾個(gè)條件：

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

文檔邏輯

功能框架邏輯

• 拆分：羅列所有要做的功能點(diǎn)
• 組合：根據(jù)模塊將功能重新組合

業(yè)務(wù)流程邏輯

• 面向事件：完成某個(gè)事件需要多部操作，一般使用流程圖來描述（用戶執(zhí)行的操作流程）。
• 面向?qū)ο螅涸趯?duì)象的整個(gè)生命周期里，涉及所有完整的功能的使用（某個(gè)功能的完整流轉(zhuǎn)，例如訂單）。

描述功能時(shí)注意事項(xiàng)

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

需求用例模板

| 用例名 | 描述 |
| :---------------: |:-- --:|
| 場(chǎng)景 | 當(dāng)前使用的場(chǎng)景 |
| 用戶需求 | 具體解決用戶什么問題 |
| 前置條件 | 完成該功能點(diǎn)的前提條件 |
| 需求詳述 | 描述該功能點(diǎn)所能實(shí)現(xiàn)的業(yè)務(wù)功能 |
| 后置條件 | 完成該功能點(diǎn)產(chǎn)生的結(jié)果 |
| 補(bǔ)充說明 | 如有例外或特殊情況補(bǔ)充說明 |

二、需求管理

獲取需求階段

1. 判斷需求

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

2. 記錄需求

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

討論和設(shè)計(jì)階段

1. 判斷需求的優(yōu)先級(jí)

四象限法則（非書內(nèi)原圖）

重要程度排序

• 不做，會(huì)造成嚴(yán)重的問題和惡劣的影響
• 做了，會(huì)產(chǎn)生巨大好處喝極佳效果
• 跟核心用戶利益有關(guān)
• 跟大部分用戶利益有關(guān)
• 跟效率或成本有關(guān)
• 跟用戶體驗(yàn)有關(guān)

判斷緊急程度

• 不做，錯(cuò)誤會(huì)持續(xù)的發(fā)生并造成嚴(yán)重影響
• 在一定時(shí)間內(nèi)可控但長期會(huì)有糟糕的影響
• 做了，里可能解決很多問題、產(chǎn)生正面的影響
• 做了，在一段時(shí)間后可以由良好的效果

KANO模型簡(jiǎn)化版

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

期待型需求
功能存在用戶會(huì)開心，功能不存在用戶會(huì)不開心，屬于最直接、最明顯的用戶需求，實(shí)現(xiàn)后符合用戶的心理預(yù)期。

驚喜型需求
用戶沒有預(yù)期，功能不存在時(shí)，用戶沒有感覺，但功能存在用戶會(huì)很開心，超出用戶的預(yù)期。

2.方案草稿
針對(duì)待解決的問題，先討論方案，如果涉及到其他業(yè)務(wù)部門，達(dá)成共識(shí)后，繼續(xù)推進(jìn)。

3.指定負(fù)責(zé)人
按照模塊進(jìn)行分配，并設(shè)計(jì)職責(zé)的邊界。

4.劃定時(shí)間節(jié)點(diǎn)
設(shè)定Dealine，建議最長不超過一周的時(shí)間，同時(shí)將需求的狀態(tài)提供給需求的來源方。

待開發(fā)階段

1. 方案可行性評(píng)估：提出方案的實(shí)現(xiàn)細(xì)節(jié)，并評(píng)估是否有可行性。
2. 有沒有更好的方案：給技術(shù)部門灌輸需求背景，思考是否有跟多可行性方案或思路。
3. 涉及的產(chǎn)品和技術(shù)環(huán)節(jié)有哪些：如果涉及影響其他產(chǎn)品線，需要技術(shù)評(píng)估那些人需要知情或參與評(píng)估。
4. 方案的成本評(píng)估：除了評(píng)估人力、資源、時(shí)間等表面成本，也要考慮服務(wù)器、帶寬等隱性成本。
5. 討論結(jié)束：輸出嚴(yán)謹(jǐn)?shù)目蓤?zhí)行方案，如果沒有達(dá)成一致，也要確認(rèn)下一次解決問題的時(shí)間節(jié)點(diǎn)。

開發(fā)階段

開發(fā)優(yōu)先級(jí)排序
兩個(gè)維度：重要緊急程度、開發(fā)成本
開發(fā)順序：1-9

開發(fā)階段注意事項(xiàng)

• 提交開發(fā)后，關(guān)閉本次迭代需求
• 避免技術(shù)方案不完整、需求方主觀改動(dòng)

復(fù)盤階段

需求完成生命周期之后執(zhí)行，復(fù)盤需求管理中的故障及問題，防止下次再出現(xiàn)。

三、工作流管理

協(xié)作管理

與技術(shù)人員常規(guī)協(xié)作

• 確保產(chǎn)品要求傳遞給技術(shù)人員
• 確保技術(shù)部門的意見得到了表達(dá)
• 雙方共同認(rèn)可的內(nèi)容予以確認(rèn)
• 比較復(fù)雜的功能，多進(jìn)行幾次評(píng)審，拉長進(jìn)入開發(fā)前的準(zhǔn)備時(shí)間

與技術(shù)人員協(xié)作的臨時(shí)狀況（緊急新增、修改需求）

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

與需求來源方協(xié)作
重點(diǎn)是需求完成的準(zhǔn)確度和完成度，需要努力同步信息。

協(xié)作素養(yǎng)

• 關(guān)于心態(tài)：追求雙贏，減少對(duì)抗和壓制。
• 關(guān)于開會(huì)：嚴(yán)格圍繞討論范圍和主題，并輸出結(jié)論。
• 關(guān)于記錄

1. 文檔記錄：再小的需求也要更新到文檔。
2. 會(huì)議記錄：主要記錄討論節(jié)點(diǎn)和結(jié)論，以最終發(fā)出的郵件為準(zhǔn)。
3. 想法和思路：主要用于備忘。

流程管理

協(xié)作標(biāo)準(zhǔn)化和流程化

1. 所有需求由郵件提出，記錄需求并明確負(fù)責(zé)人。
2. 對(duì)接多個(gè)業(yè)務(wù)方時(shí)，固定接口人，防止未達(dá)成一致的需求、重復(fù)設(shè)計(jì)需求等。
3. 需求狀態(tài)固定時(shí)間發(fā)布，讓需求方放心，并了解當(dāng)前推進(jìn)的狀態(tài)。
4. 有延期的需求，需要告知需求方，并告知原委。

減少手工勞動(dòng)
使用協(xié)作軟件，解決需求協(xié)同管理的問題。

讓一些工作可復(fù)用

1. 原型交互做成模塊化，可復(fù)用，遵循視覺和邏輯的統(tǒng)一。
2. 話術(shù)、文案根據(jù)不同的場(chǎng)景（警告、提醒、解釋說明），統(tǒng)一規(guī)范表達(dá)。

避免重復(fù)犯錯(cuò)
通過找到犯錯(cuò)的原因，加強(qiáng)管控。

1. 由于疏漏導(dǎo)致。
2. 由于信息不全、知識(shí)不完備導(dǎo)致。
3. 由于沒有責(zé)任心導(dǎo)致。
4. 由于無法勝任導(dǎo)致。

個(gè)人管理

任務(wù)管理
常見的陷阱

1. 把焦急當(dāng)做任務(wù)的緊急程度。
2. 把充實(shí)感當(dāng)做完成任務(wù)。
3. 眼光不夠長遠(yuǎn)，只做半衰期短的事情。
4. 不設(shè)置截止日期。
5. 不檢視效果。

知識(shí)管理
通過在線筆記儲(chǔ)備知識(shí)（參考筆記術(shù)）

團(tuán)隊(duì)管理

1. 提升專業(yè)技能服眾
2. 提升管理技能