項(xiàng)目管理是產(chǎn)品經(jīng)理必須的技能，但也是很多年輕產(chǎn)品經(jīng)理的短板&硬傷。一起來(lái)聽聽前輩的建議，enjoy~

我有很多年輕的產(chǎn)品同事及朋友，每次和他們聊起來(lái)，都會(huì)和我抱怨，說(shuō)自己的項(xiàng)目計(jì)劃2個(gè)月，但是現(xiàn)在都遠(yuǎn)超兩個(gè)月了還沒上線，都怪那些業(yè)務(wù)、運(yùn)營(yíng)甚至老板不停改需求不斷加需求。但是從來(lái)沒有誰(shuí)和我說(shuō)項(xiàng)目延期，需求不定的問題源自自身。難道真的問題都在別人身上嗎？其實(shí)不然，所有類似問題，主要還是出在我們這些產(chǎn)品經(jīng)理身上。為什么呢？

我用倒推法來(lái)舉證：

這張圖是我歸納了所有與我有所交流的產(chǎn)品經(jīng)理所遇問題以后總結(jié)出的。

我在每一個(gè)步驟的流程中都加了一句話。這每一句話都代表一個(gè)看似平淡無(wú)奇，實(shí)則是相當(dāng)致命的錯(cuò)誤行為，而這些“小細(xì)節(jié)”也正是導(dǎo)致整個(gè)項(xiàng)目延期的罪魁禍?zhǔn)住?/p>

當(dāng)然，也有朋友和我說(shuō)：“我不去做需求評(píng)審，不做設(shè)計(jì)評(píng)審，不做XXX都是為了節(jié)約時(shí)間加速工期，但誰(shuí)知道那些業(yè)務(wù)方不靠譜，他們連自己要什么都不知道？一直提需求改需求，導(dǎo)致我們開發(fā)延期?！?/p>

可是！

正是因?yàn)槲覀冞@些產(chǎn)品經(jīng)理沒有去做這些評(píng)審，才會(huì)導(dǎo)致業(yè)務(wù)方不清楚自己要什么！

為什么那么說(shuō)呢？

如果業(yè)務(wù)很明確知道自己要什么，還要我們產(chǎn)品經(jīng)理做啥？（開個(gè)玩笑）

首先，我們要明確業(yè)務(wù)是做什么的

無(wú)論項(xiàng)目是ToB還是ToC，業(yè)務(wù)人員，大多是處在第一線的人員，銷售、運(yùn)營(yíng)、市場(chǎng)等等，那他們有什么共性嗎？有！而且很明顯！他們的工作面對(duì)的都是用戶，是以“人”為單位的。而人的不確定性特別大，這就導(dǎo)致了業(yè)務(wù)方的工作大多都是雜亂無(wú)章的，再加上工作崗位問題或者工作習(xí)慣問題，從而導(dǎo)致業(yè)務(wù)方在使用系統(tǒng)時(shí)遇到困難，經(jīng)常不能及時(shí)做記錄，最后導(dǎo)致業(yè)務(wù)方提供到產(chǎn)品的需求大多都是常見問題，而且是最近遇到什么就提什么，過(guò)段時(shí)間遇到另外一些，然后又提一些。從此循環(huán)反復(fù)，無(wú)窮無(wú)盡。（這也是為什么總有產(chǎn)品同學(xué)說(shuō)業(yè)務(wù)方都不知道自己要什么，我們只能跟著他們說(shuō)的改。）

既然現(xiàn)在我們知道了為什么業(yè)務(wù)總會(huì)循環(huán)反復(fù)提一些“很有道理，且無(wú)法反駁”的需求，那我們是否應(yīng)該去做些什么，去堵住他們的嘴，不讓他們?nèi)绱怂烈馔秊?？是的，而且很?jiǎn)單。

具體方式如下：去了解業(yè)務(wù)，而且要比業(yè)務(wù)還了解業(yè)務(wù)。

是不是覺得說(shuō)的很廢話，很沒必要？如果覺得很廢話，我贊同。但是如果覺得很沒必要，那只能說(shuō)：你錯(cuò)了！

了解業(yè)務(wù)，是產(chǎn)品經(jīng)理邁出第一步的重要前提

有多重要呢？重要到?jīng)Q定了產(chǎn)品接下來(lái)的走向！舉個(gè)不太恰當(dāng)?shù)睦踝樱腿缤瑑蓷l公共端點(diǎn)射線形成的夾角，哪怕起初角度只是一點(diǎn)點(diǎn)的偏差，但射線到了一定長(zhǎng)度以后，差距會(huì)變得非常明顯！

那該怎么做呢？其實(shí)也很簡(jiǎn)單，就是問問問，化身為十萬(wàn)個(gè)為什么！千萬(wàn)不要覺得不好意思問，不然等項(xiàng)目交付的時(shí)候，有你臉紅的時(shí)候。

現(xiàn)在知道要去問了，怎么問，這個(gè)方法也很重要。

我這里有四個(gè)步驟可以參考：

1. 問前：去了解業(yè)務(wù)流程，即正常工作流。了解他們業(yè)務(wù)從哪開始，到哪結(jié)束，以及中途經(jīng)歷的正常的流程。（先不去考慮異常流程）
2. 提問：在了解工作流的前提下，針對(duì)性提出問題，問業(yè)務(wù)分別每一步都會(huì)遇到什么問題，且目前是如何處理的。（一定要目前！！不要去管他們期望的解決方案）
3. 反問：在前兩步都了解的前提下，提出自己的反問，可以針對(duì)現(xiàn)有的解決方式，可以針對(duì)他們提出的期望方式，也可以針對(duì)其他你想到的。記住，一定要反問，一可以加強(qiáng)記憶，二可以化被動(dòng)為主動(dòng)，避免業(yè)務(wù)提出過(guò)多無(wú)用需求。（當(dāng)然，業(yè)務(wù)提的所有需求都要記下，不要當(dāng)場(chǎng)反駁，節(jié)省時(shí)間）
4. 根據(jù)以上三點(diǎn)，畫出業(yè)務(wù)流程圖，即正常的業(yè)務(wù)流+每個(gè)環(huán)節(jié)可能出現(xiàn)的異常流，并附以業(yè)務(wù)方現(xiàn)有解決方案。

如果很完美做到這四步的同學(xué)還是被業(yè)務(wù)無(wú)情追著加需求，那么你可能還欠缺下面這一步。

需求整理及反饋

需求整理我想不需要多說(shuō)，但是反饋這個(gè)行為，在我身邊的年輕產(chǎn)品中很少有人做得到?？赡苁菍?duì)業(yè)務(wù)方太有信心，也可能是產(chǎn)品太害羞，總之就是需求只確認(rèn)過(guò)一次。

其實(shí)大可不必去考慮太多，我們是產(chǎn)品經(jīng)理，目的是做一款人人夸的產(chǎn)品?，F(xiàn)在為業(yè)務(wù)方做服務(wù)，就是希望得到他們的認(rèn)同，而對(duì)他們來(lái)說(shuō)，他們也很希望我們能做出一款他們用著順心的產(chǎn)品，因此，他們是會(huì)竭力配合我們的工作，而不是找我們茬，故意給我們使絆子。所以盡管放心去做反饋吧，哪怕業(yè)務(wù)近期沒時(shí)間，也要等到他們有時(shí)間，甚至讓他們擠時(shí)間。相比起將來(lái)需求反復(fù)改的時(shí)間浪費(fèi)來(lái)說(shuō)，這點(diǎn)時(shí)間還是等得起的。大不了這個(gè)項(xiàng)目不做了，原因也是業(yè)務(wù)方不配合（輕松甩鍋）。

需求反饋以后，肯定少不了一波補(bǔ)漏，這個(gè)時(shí)候，千萬(wàn)不要抱怨業(yè)務(wù)沒有一次說(shuō)清需求。因?yàn)閾Q成你，你也不一定一次記得全。

所以一定要把他們提的需求按照之前的四步再走一遍，但是有一個(gè)小前提，如果這次對(duì)接的需求與第一次總結(jié)后得出的業(yè)務(wù)流程圖不符，一定要問清楚為什么不一樣，具體以哪一次為主，而不是一味聽取他們的建議，還是那句話，業(yè)務(wù)自己也很混亂。

這一次反饋后，得出的需求以及業(yè)務(wù)流程圖，才是有參考價(jià)值的。

然后再根據(jù)整體業(yè)務(wù)走向去劃分可能存在的系統(tǒng)模塊，并用四象法則去判斷需求緊急度及重要度。

有了模塊，就有了系統(tǒng)的大致框架；有了需求，就有了功能，如何只需把功能填充到各個(gè)模塊中即可。當(dāng)你將整個(gè)系統(tǒng)的大致框架搭出來(lái)，并將內(nèi)部功能填充完時(shí)，你就會(huì)發(fā)現(xiàn)。做個(gè)系統(tǒng)真的好簡(jiǎn)單。不是嗎？

現(xiàn)在有了一條清晰的業(yè)務(wù)流程，也有了一個(gè)明確的系統(tǒng)雛形，接下來(lái)是什么呢？當(dāng)然肯定不是畫原型圖啦！遠(yuǎn)遠(yuǎn)沒到這一步呢！

接下來(lái)要做的是與業(yè)務(wù)的功能評(píng)審！?。?/h2>

這時(shí)應(yīng)該拉上業(yè)務(wù)負(fù)責(zé)人，拉上一線業(yè)務(wù)代表，對(duì)你的模塊劃分，你的模塊內(nèi)擁有的功能進(jìn)行評(píng)審，去了解是否缺少功能（即不做就影響業(yè)務(wù)正常流轉(zhuǎn)的需求），是否有多余的不必要功能（大多是產(chǎn)品經(jīng)理單方面覺得很有必要的偽需求），當(dāng)然如果此時(shí)業(yè)務(wù)方提出一些期望性需求，記錄下來(lái)，但要和他們明確表示，這一期是不做的。

如果與業(yè)務(wù)方的需求評(píng)審沒過(guò)，請(qǐng)繼續(xù)上述過(guò)程。當(dāng)然，如果前期基礎(chǔ)打得好，基本上不需要太久的調(diào)整就能搞定。

再然后應(yīng)該怎么做呢？原型？別慌！快了，但還沒！這時(shí)應(yīng)該是再去找業(yè)務(wù)聊，不過(guò)這一次不需要開會(huì)，只需要當(dāng)面確定一下之前的內(nèi)容即可。

等需求都完全確定下來(lái)以后，我相信，如果你按照上面的步驟走過(guò)來(lái)，你心里已經(jīng)知道自己要做什么東西了。這時(shí)，應(yīng)該是把你整理出來(lái)的功能都梳理一遍。以業(yè)務(wù)流為核心，以模塊為單位進(jìn)行梳理。等打好這些基礎(chǔ)以后，再去畫原型圖才是最合適的。

但是！??！到了原型圖，就有朋友開始考慮什么用戶體驗(yàn)，什么交互設(shè)計(jì)。千萬(wàn)別！！切記！！

因?yàn)榈阶詈竽銜?huì)慶幸，還好一開始沒有想那么多?。?！

正確應(yīng)該怎么做呢？畫幾張簡(jiǎn)單的圖，附上應(yīng)該包含的功能即可，最多最多也就是稍微排得好看點(diǎn)，顯得態(tài)度比較端正的低保真，怎么交互怎么跳轉(zhuǎn)都不需要畫出來(lái)！！

然后下一步，就是

拉上你項(xiàng)目組內(nèi)的設(shè)計(jì)&開發(fā)，來(lái)一波功能評(píng)審

在功能評(píng)審之前，你要知道一個(gè)前提，他們不是業(yè)務(wù)，但他們要了解業(yè)務(wù)，要讓他們知道接下來(lái)要做什么，為什么而做。大家是一個(gè)項(xiàng)目組的成員，有同一個(gè)目標(biāo)，只不過(guò)是用各自不同的專業(yè)技能去合作，共同實(shí)現(xiàn)這個(gè)目標(biāo)。

有了這個(gè)前提以后，你就知道，你不能對(duì)他們有任何隱瞞，把自己知道的關(guān)于這個(gè)項(xiàng)目的業(yè)務(wù)內(nèi)容完完全全告訴大家，讓大家一同參與到項(xiàng)目中。

那么問題來(lái)了，評(píng)審會(huì)上，除了產(chǎn)品經(jīng)理，其他人完全不了解業(yè)務(wù)，如何讓他們迅速了解業(yè)務(wù)呢？很簡(jiǎn)單，拿出你之前做好的項(xiàng)目流程圖，跟著流程圖和他們逐一介紹流程，并介紹現(xiàn)在業(yè)務(wù)是怎么做的，我們應(yīng)該怎么實(shí)現(xiàn)去為業(yè)務(wù)提高效率（或者其他），只有這樣，大家才會(huì)站在一個(gè)角度去思考同一件事。介紹完業(yè)務(wù)以后，把你的系統(tǒng)架構(gòu)拿出來(lái)，把你的功能列表拿出來(lái)，把你的原型圖拿出來(lái)（其實(shí)整理在一起就差不多是PRD雛形了），讓他們知道你是怎么去考慮的，讓大家看看你考慮的是否齊全，并鼓勵(lì)大家集思廣益。去參考大家的建議，在會(huì)議上，把有爭(zhēng)議的點(diǎn)記錄下來(lái)，然后把沒有爭(zhēng)議的點(diǎn)進(jìn)行分工，先一步安排下去，讓后臺(tái)開發(fā)先開始搭架構(gòu)、準(zhǔn)備數(shù)據(jù)庫(kù)等。至于那些有爭(zhēng)議的點(diǎn)，可以回頭去問業(yè)務(wù)，確認(rèn)以后回來(lái)與設(shè)計(jì)&開發(fā)針對(duì)性的開一個(gè)小評(píng)審會(huì)，解決這些問題。然后就是讓設(shè)計(jì)去準(zhǔn)備素材（競(jìng)品截圖等）。

那接下來(lái)產(chǎn)品經(jīng)理要做什么呢？這時(shí)候才是真正的原型圖，中低保真+交互流程。等產(chǎn)出交互流程圖以后，第一時(shí)間丟給開發(fā)和設(shè)計(jì)，同時(shí)將PRD中一些不合理的地方進(jìn)行修改，生成一份完整的PRD，發(fā)給組內(nèi)所有成員，包括自己領(lǐng)導(dǎo)和業(yè)務(wù)方領(lǐng)導(dǎo)（管他看不看，只是一個(gè)反饋）

那到了這里，產(chǎn)品就要開始催設(shè)計(jì)催開發(fā)了嗎？并不是！

這時(shí)候產(chǎn)品經(jīng)理應(yīng)該拿著交互流程圖屁顛屁顛去找業(yè)務(wù)方，去和他們領(lǐng)導(dǎo)，和他們的一線代表開個(gè)評(píng)審會(huì)，當(dāng)然，這個(gè)會(huì)就是產(chǎn)品經(jīng)理的個(gè)人表演秀了，和業(yè)務(wù)介紹我們根據(jù)之前確定的業(yè)務(wù)流程，做出點(diǎn)交互流程，分別有哪些模塊，模塊有哪些功能等等。如果業(yè)務(wù)覺得沒問題，那么恭喜，這個(gè)版本一直到測(cè)試階段以前你都會(huì)很順利。如果有問題怎么辦？也不要緊，和他們談，只要不是有悖于業(yè)務(wù)流程圖的，都談，至于一些業(yè)務(wù)的奇思妙想去不去實(shí)現(xiàn)，那已經(jīng)是我們一句話的事情了！當(dāng)然，通常來(lái)說(shuō)，為了滿足業(yè)務(wù)的操作需求，產(chǎn)品們通常會(huì)答應(yīng)做一些微調(diào)，但這些微調(diào)根本不會(huì)影響到后臺(tái)的架構(gòu)開發(fā)和設(shè)計(jì)的設(shè)計(jì)規(guī)范，所以隨他們?nèi)グ桑。?/p>

二次業(yè)務(wù)評(píng)審結(jié)束以后，第一時(shí)間將反饋內(nèi)容通知給項(xiàng)目組內(nèi)所有成員，包括存在感特低的前端，和他們說(shuō)我們改了哪里，哪里沒改。說(shuō)實(shí)話，哪怕是大改也不要緊，項(xiàng)目初期這些坑還是能承受的。

再然后，產(chǎn)品經(jīng)理應(yīng)該怎么做呢？

完善文檔，跟進(jìn)設(shè)計(jì)，一定要讓設(shè)計(jì)做2-3個(gè)風(fēng)格的demo

為什么是demo而不是全部呢？因?yàn)榕掳さ蹲印ㄩ_個(gè)玩笑）因?yàn)橐岣咝示鸵僮?。只需要?b>幾個(gè)特定頁(yè)面做出2-3種風(fēng)格即可。（風(fēng)格自己把控）

等出圖以后，糾集業(yè)務(wù)方領(lǐng)導(dǎo)、我方領(lǐng)導(dǎo)去挑風(fēng)格，只有他們自己選的，才是他們喜歡的。（當(dāng)然也可能都不符合他們要求，那就重復(fù)該操作）。等風(fēng)格確定以后，再由設(shè)計(jì)去按照這個(gè)風(fēng)格去全面設(shè)計(jì)，同時(shí)把UI圖定期打包反饋至業(yè)務(wù)，當(dāng)然，如果他們認(rèn)為很滿意不需要看，那另說(shuō)。

等UI全部完成以后，嘗試做一套以UI圖為基礎(chǔ)的高保真交互稿，拿去與業(yè)務(wù)方領(lǐng)導(dǎo)及我方領(lǐng)導(dǎo)做確認(rèn)，認(rèn)為沒問題，就全部丟給前&amp后臺(tái)兩組開發(fā)。別問為什么還要給后臺(tái)開發(fā)，他們寫接口有用的。

再然后，產(chǎn)品需要做什么呢？閑著沒事干啦？其實(shí)不然，這個(gè)時(shí)候才是真正產(chǎn)品展現(xiàn)實(shí)力的時(shí)候了。要保證這個(gè)項(xiàng)目如期上線，不是說(shuō)前面做的好就搞定了，還需要持續(xù)的項(xiàng)目管理。畢竟不能虎頭蛇尾。

項(xiàng)目管理是產(chǎn)品經(jīng)理必須的技能，但也是很多年輕產(chǎn)品經(jīng)理的短&amp硬傷。沒有學(xué)過(guò)相關(guān)知識(shí)的產(chǎn)品可能很難掌握，但是我可以給大家提一個(gè)簡(jiǎn)單的方法，可以應(yīng)急。比如說(shuō)，不了解工期如何去判斷，那就去問相關(guān)人員，讓他們自行給出工期，然后拿著工期去請(qǐng)教領(lǐng)導(dǎo)or經(jīng)驗(yàn)比較足的其他同事是否合理。當(dāng)然，這種方法比較局限，就不細(xì)說(shuō)了。

那如果實(shí)在不行怎么辦，可以跳過(guò)相關(guān)人員，直接請(qǐng)教項(xiàng)目組內(nèi)的資歷比較深的開發(fā)，請(qǐng)他們指點(diǎn)一二。

項(xiàng)目管理這一塊不建議自學(xué)，容易給自己挖坑，還是多多請(qǐng)教有經(jīng)驗(yàn)的大牛或者多看看人家寫的文章吧??！可以參考這篇文章《在高級(jí)產(chǎn)品經(jīng)理眼中，好的項(xiàng)目管理流程是怎樣的（上）》

項(xiàng)目管理只是一項(xiàng)把控項(xiàng)目進(jìn)度，并保證項(xiàng)目在一定限度內(nèi)不會(huì)延期的能力。除此之外，很有可能導(dǎo)致項(xiàng)目延期的另一因素，那就是測(cè)試。哪怕前期規(guī)劃得再好，項(xiàng)目管理得再好，最終逃不過(guò)存在BUG得命運(yùn)。

那如何能保證開發(fā)在開發(fā)過(guò)程中盡量快地寫出更多功能，而產(chǎn)生更少的BUG呢？

用我個(gè)人不專業(yè)的話來(lái)說(shuō)，就是只要保證他們的開發(fā)邏輯不要亂，基本上的BUG都是小BUG，無(wú)傷大雅且不會(huì)占用太多工期（特殊情況不議），基本上是不會(huì)出現(xiàn)致命性的BUG。那如何做到保證開發(fā)邏輯沒問題呢？只需要保證開發(fā)架構(gòu)不要亂，只需要保證產(chǎn)品規(guī)劃不亂，只需要保證需求規(guī)劃清晰。說(shuō)到底，還是前期的鋪墊很重要。切忌不要前期為了所謂的“快”，而不去梳理邏輯，導(dǎo)致開發(fā)末期，很多需求以補(bǔ)丁形式臨時(shí)加上，最后出現(xiàn)一點(diǎn)點(diǎn)問題，造成無(wú)法輕易修改或者直接大改，導(dǎo)致幾個(gè)小BUG花費(fèi)大量工期。

當(dāng)一款產(chǎn)品經(jīng)歷過(guò)了發(fā)現(xiàn)需求 → 需求收集/整理 → ?需求轉(zhuǎn)化為功能 → ?功能開發(fā)完成 → ?測(cè)試確保無(wú)誤 → 上線的過(guò)程，才算是從0-1的過(guò)程。也是產(chǎn)品經(jīng)理真正邁出第一步的過(guò)程，接下來(lái)，道阻且長(zhǎng)，但是做到事情不過(guò)就是這些循環(huán)，至于考慮一款產(chǎn)品以后的趨勢(shì)，走向，只有等產(chǎn)品經(jīng)理到了一定高度才會(huì)去考慮，在這篇文章中就不贅述了。

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

題圖來(lái)自 Pexels，基于 CC0 協(xié)議