項目管理是產品經理必須的技能，但也是很多年輕產品經理的短板&硬傷。一起來聽聽前輩的建議，enjoy~

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

我用倒推法來舉證：

這張圖是我歸納了所有與我有所交流的產品經理所遇問題以后總結出的。

我在每一個步驟的流程中都加了一句話。這每一句話都代表一個看似平淡無奇，實則是相當致命的錯誤行為，而這些“小細節”也正是導致整個項目延期的罪魁禍首。

當然，也有朋友和我說：“我不去做需求評審，不做設計評審，不做XXX都是為了節約時間加速工期，但誰知道那些業務方不靠譜，他們連自己要什么都不知道？一直提需求改需求，導致我們開發延期?！?/p>

可是！

正是因為我們這些產品經理沒有去做這些評審，才會導致業務方不清楚自己要什么！

為什么那么說呢？

如果業務很明確知道自己要什么，還要我們產品經理做啥？（開個玩笑）

首先，我們要明確業務是做什么的

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

既然現在我們知道了為什么業務總會循環反復提一些“很有道理，且無法反駁”的需求，那我們是否應該去做些什么，去堵住他們的嘴，不讓他們如此肆意妄為？是的，而且很簡單。

具體方式如下：去了解業務，而且要比業務還了解業務。

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

了解業務，是產品經理邁出第一步的重要前提

有多重要呢？重要到決定了產品接下來的走向！舉個不太恰當的栗子，就如同兩條公共端點射線形成的夾角，哪怕起初角度只是一點點的偏差，但射線到了一定長度以后，差距會變得非常明顯！

那該怎么做呢？其實也很簡單，就是問問問，化身為十萬個為什么！千萬不要覺得不好意思問，不然等項目交付的時候，有你臉紅的時候。

現在知道要去問了，怎么問，這個方法也很重要。

我這里有四個步驟可以參考：

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

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

需求整理及反饋

需求整理我想不需要多說，但是反饋這個行為，在我身邊的年輕產品中很少有人做得到?？赡苁菍I務方太有信心，也可能是產品太害羞，總之就是需求只確認過一次。

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

需求反饋以后，肯定少不了一波補漏，這個時候，千萬不要抱怨業務沒有一次說清需求。因為換成你，你也不一定一次記得全。

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

這一次反饋后，得出的需求以及業務流程圖，才是有參考價值的。

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

有了模塊，就有了系統的大致框架；有了需求，就有了功能，如何只需把功能填充到各個模塊中即可。當你將整個系統的大致框架搭出來，并將內部功能填充完時，你就會發現。做個系統真的好簡單。不是嗎？

現在有了一條清晰的業務流程，也有了一個明確的系統雛形，接下來是什么呢？當然肯定不是畫原型圖啦！遠遠沒到這一步呢！

接下來要做的是與業務的功能評審?。?！

這時應該拉上業務負責人，拉上一線業務代表，對你的模塊劃分，你的模塊內擁有的功能進行評審，去了解是否缺少功能（即不做就影響業務正常流轉的需求），是否有多余的不必要功能（大多是產品經理單方面覺得很有必要的偽需求），當然如果此時業務方提出一些期望性需求，記錄下來，但要和他們明確表示，這一期是不做的。

如果與業務方的需求評審沒過，請繼續上述過程。當然，如果前期基礎打得好，基本上不需要太久的調整就能搞定。

再然后應該怎么做呢？原型？別慌！快了，但還沒！這時應該是再去找業務聊，不過這一次不需要開會，只需要當面確定一下之前的內容即可。

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

但是?。?！到了原型圖，就有朋友開始考慮什么用戶體驗，什么交互設計。千萬別??！切記??！

因為到最后你會慶幸，還好一開始沒有想那么多?。?！

正確應該怎么做呢？畫幾張簡單的圖，附上應該包含的功能即可，最多最多也就是稍微排得好看點，顯得態度比較端正的低保真，怎么交互怎么跳轉都不需要畫出來??！

然后下一步，就是

拉上你項目組內的設計&開發，來一波功能評審

在功能評審之前，你要知道一個前提，他們不是業務，但他們要了解業務，要讓他們知道接下來要做什么，為什么而做。大家是一個項目組的成員，有同一個目標，只不過是用各自不同的專業技能去合作，共同實現這個目標。

有了這個前提以后，你就知道，你不能對他們有任何隱瞞，把自己知道的關于這個項目的業務內容完完全全告訴大家，讓大家一同參與到項目中。

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

那接下來產品經理要做什么呢？這時候才是真正的原型圖，中低保真+交互流程。等產出交互流程圖以后，第一時間丟給開發和設計，同時將PRD中一些不合理的地方進行修改，生成一份完整的PRD，發給組內所有成員，包括自己領導和業務方領導（管他看不看，只是一個反饋）

那到了這里，產品就要開始催設計催開發了嗎？并不是！

這時候產品經理應該拿著交互流程圖屁顛屁顛去找業務方，去和他們領導，和他們的一線代表開個評審會，當然，這個會就是產品經理的個人表演秀了，和業務介紹我們根據之前確定的業務流程，做出點交互流程，分別有哪些模塊，模塊有哪些功能等等。如果業務覺得沒問題，那么恭喜，這個版本一直到測試階段以前你都會很順利。如果有問題怎么辦？也不要緊，和他們談，只要不是有悖于業務流程圖的，都談，至于一些業務的奇思妙想去不去實現，那已經是我們一句話的事情了！當然，通常來說，為了滿足業務的操作需求，產品們通常會答應做一些微調，但這些微調根本不會影響到后臺的架構開發和設計的設計規范，所以隨他們去吧??！

二次業務評審結束以后，第一時間將反饋內容通知給項目組內所有成員，包括存在感特低的前端，和他們說我們改了哪里，哪里沒改。說實話，哪怕是大改也不要緊，項目初期這些坑還是能承受的。

再然后，產品經理應該怎么做呢？

完善文檔，跟進設計，一定要讓設計做2-3個風格的demo

為什么是demo而不是全部呢？因為怕挨刀子……（開個玩笑）因為要提高效率就要少做。只需要把幾個特定頁面做出2-3種風格即可。（風格自己把控）

等出圖以后，糾集業務方領導、我方領導去挑風格，只有他們自己選的，才是他們喜歡的。（當然也可能都不符合他們要求，那就重復該操作）。等風格確定以后，再由設計去按照這個風格去全面設計，同時把UI圖定期打包反饋至業務，當然，如果他們認為很滿意不需要看，那另說。

等UI全部完成以后，嘗試做一套以UI圖為基礎的高保真交互稿，拿去與業務方領導及我方領導做確認，認為沒問題，就全部丟給前&amp后臺兩組開發。別問為什么還要給后臺開發，他們寫接口有用的。

再然后，產品需要做什么呢？閑著沒事干啦？其實不然，這個時候才是真正產品展現實力的時候了。要保證這個項目如期上線，不是說前面做的好就搞定了，還需要持續的項目管理。畢竟不能虎頭蛇尾。

項目管理是產品經理必須的技能，但也是很多年輕產品經理的短&amp硬傷。沒有學過相關知識的產品可能很難掌握，但是我可以給大家提一個簡單的方法，可以應急。比如說，不了解工期如何去判斷，那就去問相關人員，讓他們自行給出工期，然后拿著工期去請教領導or經驗比較足的其他同事是否合理。當然，這種方法比較局限，就不細說了。

那如果實在不行怎么辦，可以跳過相關人員，直接請教項目組內的資歷比較深的開發，請他們指點一二。

項目管理這一塊不建議自學，容易給自己挖坑，還是多多請教有經驗的大?；蛘叨嗫纯慈思覍懙奈恼掳桑?！可以參考這篇文章《在高級產品經理眼中，好的項目管理流程是怎樣的（上）》

項目管理只是一項把控項目進度，并保證項目在一定限度內不會延期的能力。除此之外，很有可能導致項目延期的另一因素，那就是測試。哪怕前期規劃得再好，項目管理得再好，最終逃不過存在BUG得命運。

那如何能保證開發在開發過程中盡量快地寫出更多功能，而產生更少的BUG呢？

用我個人不專業的話來說，就是只要保證他們的開發邏輯不要亂，基本上的BUG都是小BUG，無傷大雅且不會占用太多工期（特殊情況不議），基本上是不會出現致命性的BUG。那如何做到保證開發邏輯沒問題呢？只需要保證開發架構不要亂，只需要保證產品規劃不亂，只需要保證需求規劃清晰。說到底，還是前期的鋪墊很重要。切忌不要前期為了所謂的“快”，而不去梳理邏輯，導致開發末期，很多需求以補丁形式臨時加上，最后出現一點點問題，造成無法輕易修改或者直接大改，導致幾個小BUG花費大量工期。

當一款產品經歷過了發現需求 → 需求收集/整理 → ?需求轉化為功能 → ?功能開發完成 → ?測試確保無誤 → 上線的過程，才算是從0-1的過程。也是產品經理真正邁出第一步的過程，接下來，道阻且長，但是做到事情不過就是這些循環，至于考慮一款產品以后的趨勢，走向，只有等產品經理到了一定高度才會去考慮，在這篇文章中就不贅述了。

本文由 @RonT 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議