這是在某社區(qū)的一位前輩作出的總結(jié)窗轩，結(jié)合自己的產(chǎn)品經(jīng)歷進(jìn)行了一些補(bǔ)充和修改。

1. 需求來源部分

不同方向的需求來源略有不同岖瑰，總體來說布朦，產(chǎn)品經(jīng)理的需求來源有以下幾個方面：

業(yè)務(wù)需求：由業(yè)務(wù)方，比如 BD撩银、編審、運(yùn)營等，直接提出的業(yè)務(wù)需求荷愕；

數(shù)據(jù)挖掘：通過數(shù)據(jù)挖掘和分析，發(fā)現(xiàn)的問題或需求棍矛；

競對調(diào)研：通過分析競對的產(chǎn)品安疗，發(fā)現(xiàn)競對比我們有優(yōu)勢或值得學(xué)習(xí)借鑒的地方；

實(shí)地觀察：不論是 B 端產(chǎn)品還是 C 端產(chǎn)品够委，其實(shí)都有大量的機(jī)會實(shí)地觀察用戶行為荐类。比如直接陪訪城市運(yùn)營等；

戰(zhàn)略需要：俗話說「老大拍的」茁帽，這類是由公司 leader 直接安排的需求玉罐，通常表示公司未來發(fā)展方向或急需解決的關(guān)鍵問題；

其他還包括客服潘拨、商服反饋的問題吊输，通過在線渠道或用戶訪談獲得的需求，還有微博铁追、朋友圈吐槽等各種 SNS 途徑季蚂。不論哪種途徑獲取的需求，產(chǎn)品經(jīng)理都應(yīng)該有一個自己的需求池脂信，統(tǒng)一記錄各種想法癣蟋。

在不同需求來源中，最看重的產(chǎn)品經(jīng)理自己發(fā)現(xiàn)/評估的需求狰闪，這是評價產(chǎn)品經(jīng)理需求決策能力的重要指標(biāo)疯搅。

2. 收集和整理需求

收集和整理需求，就是將需求統(tǒng)一記錄到需求池埋泵，方便團(tuán)隊內(nèi)/間的傳播幔欧。每個團(tuán)隊建議維護(hù)自己的需求池地址。

需求池只是一個備忘丽声，記錄下來的需求不一定都要做礁蔗，也未必是值得做的需求才記錄下來。

及時維護(hù)

3. 立項審批

立項是產(chǎn)品流程中的第一個必要步驟雁社，在這個階段浴井，核心的是要確定項目的價值和目標(biāo)。

3.1 確定項目的價值

確定項目價值有三個核心要素：角色霉撵、場景和目標(biāo)磺浙。也就是洪囤，誰在什么情況下要解決什么問題（滿足什么需求）。三個要素必須齊備撕氧，才能做出基本的價值判斷瘤缩。

具備了三個要素，還需要從兩個維度去定義項目的價值伦泥。

第一個維度剥啤，是當(dāng)前業(yè)務(wù)/產(chǎn)品階段〔桓基于不同的業(yè)務(wù)階段(一般都是萌芽期府怯、成長期、發(fā)展期跨新、穩(wěn)定期富腊、衰退期），產(chǎn)品在戰(zhàn)術(shù)和戰(zhàn)略的打法各有不同域帐。比如某共享單車做Growth中的17年紅包大戰(zhàn)赘被，雖縱向來看不利生態(tài)循環(huán)，但橫向來看利于業(yè)務(wù)競爭肖揣。后面會另起一篇分享“業(yè)務(wù)型產(chǎn)品經(jīng)理賦能業(yè)務(wù)的邏輯與思考”

第二個維度民假，是影響范圍。拋開計量談毒性龙优，都是耍流氓羊异。前面我們提到了用戶第一個的標(biāo)準(zhǔn)，但是彤断，如果一個需求僅對 1000 個用戶有收益野舶，但對 50000 個商家有收益，那么優(yōu)先級的判斷也是不同的宰衙。影響范圍是大家日常工作中非常容易忽略的思考點(diǎn)平道，往往發(fā)現(xiàn)一個 badcase，就拼命想解決供炼，說好聽點(diǎn)叫偏執(zhí)一屋，說難聽點(diǎn)就是本末倒置。

思考項目價值袋哼，推薦用5 Why 分析法冀墨，對事情不斷追問，看看一個需求涛贯，是否還有成本更低的解決方案诽嘉，本質(zhì)收益到底是什么，到底會影響多少人。

3.2 確定項目目標(biāo)

價值說的是對什么有好處虫腋，目標(biāo)說的是有多少好處身冬。

制定目標(biāo)必須符合 SMART 原則 ，細(xì)節(jié)看鏈接岔乔，我這里舉個例子。

我的目標(biāo)是要變成瘦子滚躯；

我的目標(biāo)是要減肥 6 斤雏门；

我的目標(biāo)是要一個月減肥 6 斤；

我當(dāng)前體重是 75 公斤掸掏，以我的身高計算茁影，合理體重是 72 公斤，我希望在下個月 1 號前減重 1 公斤丧凤，3個月內(nèi)達(dá)到標(biāo)準(zhǔn)體重募闲。

上述四種描述目標(biāo)的方式：

第一種，典型的沒有任何意義的目標(biāo)愿待，沒有時間點(diǎn)浩螺、沒有量化目標(biāo)；

第二個仍侥，有了一個量化目標(biāo)要出，但是什么時候到達(dá)，沒有明說农渊。還記得我說過的拋開計量談毒性么患蹂？

第三個，有個一個時間點(diǎn)砸紊，但是幾乎不可能完成传于，即便能完成，也是以犧牲健康為代價醉顽。這就是不具備可完成性和與總體目標(biāo)的相關(guān)性沼溜；

第四個，相對比較合理徽鼎。首先說明了當(dāng)前的情況盛末，以及合理的目標(biāo)值。其次否淤，有明確的時間點(diǎn)和量化指標(biāo)悄但，還有相對長期的規(guī)劃。最后石抡，相比之下檐嚣，可行性也會更高一些。

3.3 如何進(jìn)行立項審批？

建議組/團(tuán)隊有一個立項表嚎京，其實(shí)核心就是確定價值和目標(biāo)嗡贺。表格填寫好以后，可以在**每周一**早上的例會上提出立項的要求鞍帝，leader確認(rèn)立項后會將立項**標(biāo)紅**诫睬。

任何口頭承諾都是無效的，只有立項表中的項目被標(biāo)紅帕涌，才說明立項成功摄凡。

價值描述是否清楚，價值優(yōu)先級是否足夠高蚓曼；

項目目標(biāo)是否 SMART亲澡；

項目主 R 是否有足夠的時間精力確保項目的質(zhì)量；

項目投入有多大纫版；

立項有三種結(jié)果：成功床绪、待定和放棄。需要嚴(yán)格把控需求其弊，以確保資源的最大利用化(切記不僅僅是研發(fā)資源)癞己。

4. 調(diào)研、寫方案和組內(nèi)評審

立項成功只是第一步梭伐，圍繞立項時確定的項目價值和目標(biāo)末秃，需要進(jìn)行深入的方案設(shè)計工作。

4.1 方案調(diào)研

所謂調(diào)研籽御，就是收集我們設(shè)計方案所需的背景信息和數(shù)據(jù)练慕。需要遵循以下原則：

有明確的調(diào)研范圍，不能太窄技掏，也不能無休止的調(diào)研铃将；

一定要調(diào)研第一手資料，不能偏信二手信息哑梳。比如綜運(yùn)反饋運(yùn)維師傅有需求或者有問題劲阎，我們就應(yīng)該直接調(diào)研運(yùn)維，了解商家的真實(shí)需求鸠真；

數(shù)據(jù)調(diào)研需要足夠的樣本量悯仙；

實(shí)地調(diào)研。如果是系統(tǒng)功能吠卷，就要自己測試锡垄；如果是需求，最好直接和需求方進(jìn)行面談祭隔；

要輸出調(diào)研報告货岭，尤其是調(diào)研結(jié)論；

4.2 方案編寫

這里不多講，需求文檔最重要/首先是講明白事千贯、拉齊認(rèn)知屯仗。后面會另起一篇分享“需求文檔編寫規(guī)范”

4.3 組內(nèi)評審

評審注意事項：

各組 leader 必須參加組內(nèi)評審；

所有需求必須經(jīng)過組內(nèi)評審搔谴；

評審需要輸出評審結(jié)果報告魁袜，記錄修改點(diǎn)、反饋和是否通過的結(jié)論敦第；

根據(jù)不同需求類型慌核，評審可以酌情邀請業(yè)務(wù)、RD申尼、UI/UE 和 QA 參加；

建議方案出來以后垫桂，PM 先和需求方或自己的 leader 進(jìn)行一對一溝通师幕，對方案要點(diǎn)進(jìn)行確認(rèn)；

組內(nèi)評審原則上不應(yīng)該超過 2 次诬滩；

如果評審次數(shù)過多霹粥，需要評估對應(yīng) PM 是否具備完成該項目的能力，如不勝任疼鸟，需要及時換人后控，確保項目進(jìn)展和質(zhì)量；

5. 項目評審

也可以叫做大組評審或正式評審空镜，評審要點(diǎn)如下：

大組評審必須邀請 RD浩淘、QA 、UI/UE吴攒、業(yè)務(wù)方和關(guān)聯(lián)方张抄，周知到業(yè)務(wù) leader 和各產(chǎn)品 leader；

評審形式洼怔，以主 R PM 講產(chǎn)品需求文檔為主署惯，講解過程中，盡量不要打斷陳述人镣隶，讓陳述人有機(jī)會完整表達(dá)方案极谊；

避免「釣魚評審」，不能出現(xiàn)大家寫需求安岂，PM 記錄的情況轻猖；

嚴(yán)格控制評審時間；

評審結(jié)果分為：重寫域那、修改和通過蜕依；

評審至少提前一天發(fā)出會議邀請

6. 技術(shù)評審

技術(shù)評審的重點(diǎn)是技術(shù)評估項目可行性，有以下要點(diǎn)：

技術(shù)評審也可以由 PM 發(fā)起，最好是 PM 發(fā)起样眠；

技術(shù)評審后必須拿到估時友瘤；

按照功能列表，如果能給出每個具體功能的估時最好檐束；

技術(shù)評審必須在排期會之前完成辫秧；

重點(diǎn)項目需要邀請 RD leader 參與；

多系統(tǒng)關(guān)聯(lián)項目被丧，需要邀請關(guān)聯(lián)方 RD 參與盟戏；

需要 UI/UE 參加的項目，技術(shù)評審前需要完成相關(guān)交互設(shè)計甥桂；

原則上柿究，進(jìn)入技術(shù)評審后，需求關(guān)閉黄选，不允許進(jìn)行需求增改蝇摸；

評審至少提前一天發(fā)出會議邀請，需帶文檔鏈接办陷，方便相關(guān)團(tuán)隊提前熟悉貌夕；

之所以需要按照功能列表進(jìn)行每個功能點(diǎn)的估時，同時也需要給每個功能點(diǎn)確定優(yōu)先級民镜，是因為在后續(xù)的排期中會用到啡专。

7. 排期會

所有開發(fā)資源都需要排期，一般來說制圈，后端和 FE 因為不依賴版本们童，可以在一個排期會進(jìn)行；客戶端由于需要跟版鲸鹦，有自己獨(dú)立的排期會病附。

這里不多闡述，每個團(tuán)隊有自己的節(jié)奏亥鬓，關(guān)鍵在于“嚴(yán)格執(zhí)行和優(yōu)化迭代”

8. Task 分解

項目排期成功后完沪，建議 PM 給相關(guān) RD 和 QA 創(chuàng)建 task。要求如下：

Task框架最好覆蓋“需求開發(fā)流程的各節(jié)點(diǎn)”嵌戈；

至少一個功能點(diǎn)要分拆一個 task覆积，或一個頁面也需要一個 task；

測試任務(wù)也需要開 task熟呛；

中大型項目宽档，或 task 數(shù)量超過10個的項目，需要創(chuàng)建 dashboard庵朝；

一個功能點(diǎn)吗冤，如涉及多個 RD又厉，每個都需要創(chuàng)建 task；

task 必須在開發(fā)之前創(chuàng)建椎瘟；

沒有開 task 的功能點(diǎn)或頁面需求覆致，RD 可以不做；

及時維護(hù)

9. 項目進(jìn)度跟蹤

項目開始開發(fā)后肺蔚，PM 不能做甩手掌柜煌妈，還需要對項目進(jìn)度進(jìn)行跟蹤。一些項目進(jìn)度管理方面的方法：

開發(fā)周期較短的項目宣羊，PM 需要每天 check task 的完成情況璧诵；

開發(fā)周期較長的項目，項目初期可以每兩天 check 一次 task 完成進(jìn)度仇冯，臨近 deadline 需要每天 check之宿；

根據(jù)項目要求，可以周期性與 RD 開項目溝通會苛坚，了解 RD 在項目進(jìn)度中的問題和困難比被。比如相關(guān)方響應(yīng)速度、需求理解炕婶、資源協(xié)調(diào)等；

重點(diǎn)項目或難度比較大的項目莱预，PM 可以酌情開每日站會柠掂。站會可以在早上，5-10分鐘依沮，溝通前日進(jìn)度或 todo涯贞；

項目跟進(jìn)過程中，要非常關(guān)注外部依賴危喉，需要明確依賴方和依賴順序宋渔，尤其是對外部資源的依賴；

優(yōu)先級比較高的要求辜限，可以每天匯總項目進(jìn)度皇拣，發(fā)送給相關(guān)方和需求方；

10. 功能驗收

功能驗收指的是確保項目完成了最基本的功能實(shí)現(xiàn)薄嫡，與 RD 一起確定項目是否達(dá)到提測需求氧急。

需要在編寫需求文檔的時候，就確定功能的驗收標(biāo)準(zhǔn)毫深，所以驗收環(huán)節(jié)就要嚴(yán)格按照驗收標(biāo)準(zhǔn)進(jìn)行驗收吩坝。

驗收完成后，可以發(fā)出一個正式的驗收結(jié)果哑蔫。但是钉寝，需要注意的是弧呐，驗收不代表項目達(dá)到上線標(biāo)準(zhǔn)，僅表示項目可以提測嵌纲。

為什么在提測前 PM 需要驗收俘枫？主要還是因為我們的 QA 資源非常緊張，希望 QA 用在更有價值的地方疹瘦，而不用去操心基本的功能完整性問題崩哩。

11. 項目提測

項目開發(fā)并進(jìn)行基本驗收后，由 RD 發(fā)提測郵件言沐。

測試之前邓嘹，其實(shí)在項目開發(fā)過程中，PM 需要與 QA 一起編寫測試用例险胰。原則上來說汹押，項目提測之后，PM 只需要與 QA 溝通測試進(jìn)度起便，了解測試中出現(xiàn)的問題棚贾。測試中的 bug，需要 PM 和 QA 來判斷是開發(fā) bug 還是產(chǎn)品設(shè)計的缺陷榆综。

如果提測過程中有產(chǎn)品設(shè)計缺陷妙痹，需要分情況討論。

如果是客戶端版本鼻疮，而產(chǎn)品設(shè)計缺陷并沒有很大的影響范圍怯伊，不會導(dǎo)致用戶體驗層面的 block 和太大傷害，原則上不在提測后修復(fù)產(chǎn)品邏輯的問題判沟」⑶郏可以將這些問題作為高優(yōu)先級的需求列入下次項目。這個判斷需要產(chǎn)品線 leader 來判斷挪哄。

如果是服務(wù)端需求吧秕，不存在嚴(yán)格的發(fā)版和上線時間，可以評估 bug 的影響范圍和嚴(yán)重程度迹炼，酌情進(jìn)行修復(fù)砸彬。

當(dāng)然，項目中出現(xiàn)產(chǎn)品邏輯 bug 屬于 PM 的嚴(yán)重失職斯入，需要我們避免拿霉。

在項目開發(fā)過程中，如果有 delay 的風(fēng)險咱扣，需要盡早發(fā)項目延期預(yù)警郵件绽淘，最好面對面周知到KP，如關(guān)聯(lián)方 RD闹伪、PM 和需求方沪铭。

測試過程中壮池，最終 PM 還要進(jìn)行一次產(chǎn)品上線驗收，在 QA 確保項目質(zhì)量的情況下對功能完整性和可用性進(jìn)行評估杀怠。并正式郵件發(fā)出椰憋。

12. 預(yù)上線與上線

項目開發(fā)并測試完成后，PM 需要先發(fā)預(yù)上線郵件赔退，并在相關(guān)渠道進(jìn)行周知橙依。之所以要發(fā)預(yù)上線郵件，是因為考慮到項目上線對各方可能帶來的影響硕旗，需要各方提前有所準(zhǔn)備窗骑。原則上，預(yù)上線郵件至少提前 1-2 天發(fā)出漆枚。

項目上線后也需要發(fā)正式郵件周知创译，注意事項如下：

原則上，周五和節(jié)假日前三天墙基，不能上線软族。如有特殊需求要上線，需要產(chǎn)品線 leader 和 RD leader 確認(rèn)残制；

預(yù)上線和上線郵件要發(fā)送全組立砸，包括業(yè)務(wù)、運(yùn)營初茶、PM颗祝、RD、UI/UE纺蛆、QA 等吐葵；

預(yù)上線郵件側(cè)重說明項目上線的影響范圍规揪；

上線郵件側(cè)重說明項目的價值桥氏、目標(biāo)和方案，郵件中需要明確說明上述內(nèi)容猛铅；

上線郵件中字支，不僅應(yīng)該包含項目的方案說明，還需要酌情考慮增加使用說明奸忽、運(yùn)營計劃堕伪、FAQ 等內(nèi)容；

上線郵件中栗菜，要說明項目上線后各方需要關(guān)注的數(shù)據(jù)和異常欠雌；

13. 項目總結(jié)評估

項目總結(jié)評估是整個項目中最重要的環(huán)節(jié)之一，有 PM 主導(dǎo)疙筹，主要做以下幾個事情富俄。

第一個禁炒，寫項目總結(jié)文檔。從以下幾個方面：

目標(biāo)完成統(tǒng)計（數(shù)據(jù)）

目標(biāo)完成情況的分析霍比，為什么完成得好幕袱，為什么完成不好

方案設(shè)計問題復(fù)盤

項目執(zhí)行問題復(fù)盤

開發(fā)測試問題復(fù)盤

產(chǎn)品運(yùn)營問題復(fù)盤

后續(xù)運(yùn)營推廣方案

下一步產(chǎn)品計劃

第二個，需要基于總結(jié)文檔開項目復(fù)盤會悠瞬。是否需要正式復(fù)盤會们豌，視項目情況絕對。大中型項目一定需要復(fù)盤會浅妆，效果突出或不能達(dá)到預(yù)期目標(biāo)的項目望迎，也需要專題復(fù)盤。

第三個狂打，將上述信息內(nèi)容擂煞，簡要填入項目總結(jié)表。