編輯導語：作為一名產(chǎn)品經(jīng)理，在日常工作中需要面對多方的問題，需要有把控全局的能力、準確的判斷能力等等，也要有足夠的經(jīng)驗；本文是作者分享的關于新人產(chǎn)品經(jīng)理在做項目管理時遇到的問題，我們一起來看一下。

產(chǎn)品經(jīng)理是一個講究綜合素質(zhì)的崗位，產(chǎn)品經(jīng)理會被領導、開發(fā)、運營人員不斷地挑戰(zhàn)，期間充斥著被懷疑與自我懷疑；新手產(chǎn)品經(jīng)理需要積極培養(yǎng)個人的逆商，并不斷學習總結(jié)復盤，減少重復性犯錯的可能，總結(jié)優(yōu)秀經(jīng)驗，才能逐步成長，成為一名優(yōu)秀的產(chǎn)品經(jīng)理。

公司的一套較為完善的人工智能產(chǎn)品，個人在做相關產(chǎn)品規(guī)劃工作，通過在整個系統(tǒng)流程上引入某系統(tǒng)產(chǎn)品A，進而實現(xiàn)整個流程的智能化；我作為整個方案的設計方及需求方，同時也是其中某個系統(tǒng)的產(chǎn)品經(jīng)理，身份比較復雜，但整體上我是承擔需求方、方案設計產(chǎn)品經(jīng)理、項目推動項目經(jīng)理，三個角色。

因為個人做產(chǎn)品經(jīng)理時間不是很長，所以經(jīng)驗明顯不足，在整個項目過程中主要暴露了作為產(chǎn)品經(jīng)理的方案設計問題以及作為項目經(jīng)理的項目管理問題，作為記錄也作為經(jīng)驗共享，分享給新人。

一、項目背景

項目涉及系統(tǒng)：前端H5、前端SDK、兩個中間系統(tǒng)、系統(tǒng)A、系統(tǒng)B。

項目涉及人員：6個系統(tǒng)各一位產(chǎn)品，各系統(tǒng)對應開發(fā)及測試12人（每個系統(tǒng)至少1位開發(fā)一位測試人員），業(yè)務需求方（2位），整個項目涉及至少20人。

項目整體趨勢：兩個中間系統(tǒng)準備重新劃分職責，整個流程推進智能化，整體趨勢向好。

二、項目過程

項目起初利于提升某運營指標實現(xiàn)降本增效，經(jīng)過一段時間的調(diào)研與產(chǎn)品設計，計劃在該流程中引入現(xiàn)有策略產(chǎn)品，從而實現(xiàn)整個流程的智能化；個人在此項工作中承擔產(chǎn)品經(jīng)理的角色。

需求實現(xiàn)自始至終出現(xiàn)了以下問題，嚴格意義上，這是個人第一次承擔比較大的產(chǎn)品規(guī)劃管理工作。

1. 需求方案討論階段

在需求方案討論階段，未充分了解各系統(tǒng)間調(diào)用流程，導致在方案制定時，一方面導致被其他部門人員引導進行，產(chǎn)生不利于原產(chǎn)品定位的問題；另一方面在方案最終敲定上搖擺不定，期間多次反復討論，差點上升至領導決策層面，（最終互相讓步了）導致整體項目歷時延長。

個人經(jīng)驗：新手們在進行方案探討前一定記得把需求涉及的系統(tǒng)能力、系統(tǒng)調(diào)用邏輯調(diào)研了解清楚，這樣對后續(xù)方案的討論和敲定都會起到積極有效的作用；如果是嚴格意義上的需求方盡可能把業(yè)務流程梳理清楚，如果是產(chǎn)品經(jīng)理的話需要把產(chǎn)品邏輯梳理清楚。

2. 方案評審階段

在初步方案評審階段，出現(xiàn)相關方未到位的情況，出現(xiàn)這個事情的原因是個人不清楚本次系統(tǒng)改造還涉及這樣一個系統(tǒng)，因而很順利地導致第一次需求評審流產(chǎn)。

個人經(jīng)驗：這個說起來真的很痛心，但是新人們一定要注意避免，不要因為不清楚就想當然的認為拉齊了相關方，可私下向其他系統(tǒng)同事請教了解一下，真的很有必要，尤其是在新接手某個涵蓋不太了解的系統(tǒng)任務。

需求評審拉起相關方！需求評審拉起相關方??！需求評審拉起相關方?。?！重要的事情說三遍。

3. 需求提交階段

在需求溝通階段未郵件留痕，方案評審完成后未盡快提交正式需求，導致在中間出現(xiàn)變動時無法有效找到證據(jù)進行項目推動；因此導致整體項目歷時有所延長，約3-4個工作日。

個人經(jīng)驗：在以下幾個階段，建議通過郵件的方式進行留痕：

• 方案討論階段達成的方案共識，以會議紀要形式同步各方，一方面證據(jù)留痕，另一方面周知各方，避免遺忘或信息不同步。
• 需求提交留痕，可以通過工單系統(tǒng)或者郵件留痕，有其一即可。

4. 需求實現(xiàn)階段

1）特殊場景未窮盡——設計方案時只考慮主流形式

針對80%用戶會采用的形式進行的方案規(guī)劃設計，但針對特殊的20%的場景未進行方案設計，如沒有用戶ID的場景、沒有手機號碼的用戶、接口超時問題、緩存時長未定義等；在前期對業(yè)務未充分了解，對場景未充分窮舉的情況下，趕時間出方案特別容易出現(xiàn)該問題；雖不是大問題，可以通過后期補救的方式，但總是這樣會影響開發(fā)等對產(chǎn)品的評價。

2）動態(tài)配置內(nèi)容做在系統(tǒng)流程上（大忌）

針對某一渠道，用戶進線不攜帶ID，初次拉著相關產(chǎn)品和開發(fā)討論時，竟決定做在系統(tǒng)流程上；后期得虧緩過神來，馬上拉著開發(fā)探討，后續(xù)將該場景做在了動態(tài)策略上，方便后續(xù)靈活變動。

在此自我反思，后期需要變動的內(nèi)容盡可能不要做在系統(tǒng)流程上，讓做動態(tài)的系統(tǒng)專門做動態(tài)；如果讓主流程去判斷個性化且后期大概率變動的內(nèi)容，在后期變動時開發(fā)難度大，且容易引起不穩(wěn)定的情況。

3）你認為不是他認為的

此項目中，在跟開發(fā)溝通需求時，通過文字+口頭表述的方式傳達需求，開發(fā)當場表示明白了，沒問題。

到了實現(xiàn)階段各種需求對不齊，很多情況下出現(xiàn)這種問題，也就是“產(chǎn)品想的是100%，產(chǎn)品說出來的可能是80%，開發(fā)理解完大概率只剩60%了”；這個一方面需要產(chǎn)品與開發(fā)在溝通需求時反復確認，盡可能讓開發(fā)自己表述一遍，然后指明理解不一致的地方；另一方面產(chǎn)品需要在開發(fā)過程中隨時溝通查驗，盡可能減少溝通與理解導致的信息缺失問題，避免產(chǎn)生大的風險。

5. 指標定義階段

前期認為指標一可作為評估指標，也是一開始的提升目標，但指標一為宏觀指標，同時還受其他因素影響；指標一雖能部分程度表示策略結(jié)果，但不能清晰表示具體上線內(nèi)容的效果，故在功能實現(xiàn)后又重新定義了指標二，慚愧慚愧。

指標應該是一開始就定義好的東西，不管產(chǎn)品還是開發(fā)，或者其他系統(tǒng)的同事，其實大家都比較關心這次開發(fā)實現(xiàn)了什么，提升了什么指標，自己述職寫周報時也好寫；指標定義應該是前提，指標都沒定義好，特別容易出現(xiàn)忘記一開始為什么做這個需求的情況，以此為戒。

當然也不全是問題，LZ也在其中也有處理好的方面。

1）及時發(fā)現(xiàn)問題重新定義方案

面對某一渠道不能同步改造，無法傳遞ID時，一開始拉著一眾產(chǎn)品和開發(fā)竟然要把策略做在系統(tǒng)流程上；還好后面懸崖勒馬，及時發(fā)現(xiàn)問題，把動態(tài)化的東西做成可調(diào)配的策略，最終避免了悲劇的發(fā)生，也獲得了兩個對接系統(tǒng)的相關開發(fā)人員認可。

2）項目管理之延期風險

H5前端因遲遲未進行開發(fā)排期，短期內(nèi)未進行有效推動。通過以下方法有效降低風險：

• 協(xié)同各系統(tǒng)進行信息同步并明確前端不能同步上線的可行性及風險。
• 討論前端二次上線，第一次保證流程改造同步上線，保證系統(tǒng)能力；第二次上線實現(xiàn)具體功能細節(jié)等上線，通過此避免了大面積風險的產(chǎn)生。

3）項目管理之擔當

面對某系統(tǒng)（非個人負責系統(tǒng)）數(shù)據(jù)表獲取困難時，及時出面協(xié)調(diào)解決；項目經(jīng)理在此應該有所擔當，幫助處理部分協(xié)調(diào)問題。

三、后續(xù)進展說明

有了本文所述項目的進行，LZ一方面理清了系統(tǒng)流程；也開啟了和其他系統(tǒng)的對接模式，緩和了關系（原各部門間關系比較緊張）；同時也學習到了各種在產(chǎn)品設計、項目管理中出現(xiàn)的問題和解決的方法。

LZ在2.0版本的設計與方案討論中做的比1.0版本游刃有余地多。

四、總結(jié)分析

1）產(chǎn)品經(jīng)理在做產(chǎn)品規(guī)劃時，首先是調(diào)研清楚項目的業(yè)務價值以及其具體的衡量指標；第二步要學著把自己的故事講好，讓開發(fā)、相關系統(tǒng)認為接下來要做的是一件有價值的事情（但是杜絕忽悠，忽悠得了一時，忽悠不了二時）；第三步跟進開發(fā)進度，隨時解決可能出現(xiàn)的延期風險。

2）產(chǎn)品經(jīng)理需要補充一下此類能力：項目管理能力、溝通協(xié)作能力、對細節(jié)的極致追求。

初次記錄總結(jié)，請多指教。

本文由@張伯倫 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議