項目管理

 

我有不少年輕的產品同事及朋友，每次和他們聊起來，都會和我抱怨，說本身的項目計劃2個月，可是如今都遠超兩個月了還沒上線，都怪那些業務、運營甚至老闆不停改需求不斷加需求。可是歷來沒有誰和我說項目延期，需求不定的問題源自自身。難道真的問題都在別人身上嗎？其實否則，全部相似問題，主要仍是出在咱們這些產品經理身上。爲何呢？

我用倒推法來舉證：

這張圖是我概括了全部與我有所交流的產品經理所遇問題之後總結出的。

我在每個步驟的流程中都加了一句話。這每一句話都表明一個看似平淡無奇，實則是至關致命的錯誤行爲，而這些「小細節」也正是致使整個項目延期的罪魁禍首。

固然，也有朋友和我說：「我不去作需求評審，不作設計評審，不作XXX都是爲了節約時間加速工期，但誰知道那些業務方不靠譜，他們連本身要什麼都不知道？一直提需求改需求，致使咱們開發延期。」

但是！

正是由於咱們這些產品經理沒有去作這些評審，纔會致使業務方不清楚本身要什麼！

爲何那麼說呢？

若是業務很明確知道本身要什麼，還要咱們產品經理作啥？（開個玩笑）

首先，咱們要明確業務是作什麼的

不管項目是ToB仍是ToC，業務人員，大可能是處在第一線的人員，銷售、運營、市場等等，那他們有什麼共性嗎？有！並且很明顯！他們的工做面對的都是用戶，是以「人」爲單位的。而人的不肯定性特別大，這就致使了業務方的工做大多都是雜亂無章的，再加上工做崗位問題或者工做習慣問題，從而致使業務方在使用系統時遇到困難，常常不能及時作記錄，最後致使業務方提供到產品的需求大多都是常見問題，並且是最近遇到什麼就提什麼，過段時間遇到另一些，而後又提一些。今後循環反覆，無窮無盡。（這也是爲何總有產品同窗說業務方都不知道本身要什麼，咱們只能跟着他們說的改。）

既然如今咱們知道了爲何業務總會循環反覆提一些「頗有道理，且沒法反駁」的需求，那咱們是否應該去作些什麼，去堵住他們的嘴，不讓他們如此肆意妄爲？是的，並且很簡單。

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

是否是以爲說的很廢話，很不必？若是以爲很廢話，我贊同。可是若是以爲很不必，那隻能說：你錯了！

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

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

那該怎麼作呢？其實也很簡單，就是問問問，化身爲十萬個爲何！千萬不要以爲很差意思問，否則等項目交付的時候，有你臉紅的時候。

如今知道要去問了，怎麼問，這個方法也很重要。

我這裏有四個步驟能夠參考：

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

若是很完美作到這四步的同窗仍是被業務無情追着加需求，那麼你可能還欠缺下面這一步。

需求整理及反饋

需求整理我想不須要多說，可是反饋這個行爲，在我身邊的年輕產品中不多有人作獲得。多是對業務方太有信心，也多是產品太害羞，總之就是需求只確認過一次。

其實大可沒必要去考慮太多，咱們是產品經理，目的是作一款人人誇的產品。如今爲業務方作服務，就是但願獲得他們的認同，而對他們來講，他們也很但願咱們能作出一款他們用着順心的產品，所以，他們是會竭力配合咱們的工做，而不是找咱們茬，故意給咱們使絆子。因此儘管放心去作反饋吧，哪怕業務近期沒時間，也要等到他們有時間，甚至讓他們擠時間。相比起未來需求反覆改的時間浪費來講，這點時間仍是等得起的。大不了這個項目不作了，緣由也是業務方不配合（輕鬆甩鍋）。

需求反饋之後，確定少不了一波補漏，這個時候，千萬不要抱怨業務沒有一次說清需求。由於換成你，你也不必定一次記得全。

因此必定要把他們提的需求按照以前的四步再走一遍，可是有一個小前提，若是此次對接的需求與第一次總結後得出的業務流程圖不符，必定要問清楚爲何不同，具體以哪一次爲主，而不是一味聽取他們的建議，仍是那句話，業務本身也很混亂。

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

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

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

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

接下來要作的是與業務的功能評審！！！

這時應該拉上業務負責人，拉上一線業務表明，對你的模塊劃分，你的模塊內擁有的功能進行評審，去了解是否缺乏功能（即不作就影響業務正常流轉的需求），是否有多餘的沒必要要功能（大可能是產品經理單方面以爲頗有必要的僞需求），固然若是此時業務方提出一些指望性需求，記錄下來，但要和他們明確表示，這一期是不作的。

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

再而後應該怎麼作呢？原型？別慌！快了，但還沒！這時應該是再去找業務聊，不過這一次不須要開會，只須要當面肯定一下以前的內容便可。

等需求都徹底肯定下來之後，我相信，若是你按照上面的步驟走過來，你內心已經知道本身要作什麼東西了。這時，應該是把你整理出來的功能都梳理一遍。以業務流爲核心，以模塊爲單位進行梳理。等打好這些基礎之後，再去畫原型圖纔是最合適的。

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

由於到最後你會慶幸，還好一開始沒有想那麼多！！！

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

而後下一步，就是

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

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

有了這個前提之後，你就知道，你不能對他們有任何隱瞞，把本身知道的關於這個項目的業務內容完徹底全告訴你們，讓你們一同參與到項目中。

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

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

那到了這裏，產品就要開始催設計催開發了嗎？並非！

這時候產品經理應該拿着交互流程圖屁顛屁顛去找業務方，去和他們領導，和他們的一線表明開個評審會，固然，這個會就是產品經理的我的表演秀了，和業務介紹咱們根據以前肯定的業務流程，作出點交互流程，分別有哪些模塊，模塊有哪些功能等等。若是業務以爲沒問題，那麼恭喜，這個版本一直到測試階段之前你都會很順利。若是有問題怎麼辦？也沒關係，和他們談，只要不是有悖於業務流程圖的，都談，至於一些業務的奇思妙想去不去實現，那已是咱們一句話的事情了！固然，一般來講，爲了知足業務的操做需求，產品們一般會答應作一些微調，但這些微調根本不會影響到後臺的架構開發和設計的設計規範，因此隨他們去吧！！

二次業務評審結束之後，第一時間將反饋內容通知給項目組內全部成員，包括存在感特低的前端，和他們說咱們改了哪裏，哪裏沒改。說實話，哪怕是大改也沒關係，項目初期這些坑仍是能承受的。

再而後，產品經理應該怎麼作呢？

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

爲何是demo而不是所有呢？由於怕挨刀子……（開個玩笑）由於要提升效率就要少作。只須要把幾個特定頁面作出2-3種風格便可。（風格本身把控）

等出圖之後，糾集業務方領導、我方領導去挑風格，只有他們本身選的，纔是他們喜歡的。（固然也可能都不符合他們要求，那就重複該操做）。等風格肯定之後，再由設計去按照這個風格去全面設計，同時把UI圖按期打包反饋至業務，固然，若是他們認爲很滿意不須要看，那另說。

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

再而後，產品須要作什麼呢？閒着沒事幹啦？其實否則，這個時候纔是真正產品展示實力的時候了。要保證這個項目如期上線，不是說前面作的好就搞定了，還須要持續的項目管理。畢竟不能有始無終。

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

那若是實在不行怎麼辦，能夠跳過相關人員，直接請教項目組內的資歷比較深的開發，請他們指點一二。

項目管理這一塊不建議自學，容易給本身挖坑，仍是多多請教有經驗的大牛或者多看看人家寫的文章吧！！能夠參考這篇文章《在高級產品經理眼中，好的項目管理流程是怎樣的（上）》

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

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

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

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