在產品迭代中，產品經理要負責相關產品開發週期和進度的把控，進行跨部門協調和溝通，最終保證新版本按時上線，這就需要產品經理具有項目管理能力。今天，我們就來聊一聊項目管理。
本文結構如下：
項目管理不單單是在產品開發過程中進行，在對一個項目進行管理時，開發前的需求傳達，項目排期，以及開發中的跟進開發，都是非常重要的，做好以上幾點，版本按時上線也就不難了。
一、需求傳達
由於程序猿們沒有經歷需求篩選，需求分析等步驟，因此當產品經理決定上一個新功能時，一定要和程序猿們進行完整的需求傳達。在需求傳達時，我們可以按照項目背景以及功能流程進行介紹。
1. 項目背景介紹
在進行項目背景介紹時，我們要清楚的告知程序猿這個新功能所針對的目標用戶是誰，使用場景是什麼，以及這個項目解決了用戶什麼需求，總結下來就是5w1h：who、when、where、what、how、why（誰，在什麼時候，在哪，解決什麼問題，如何解決的，為什麼去解決）。
為了形象而具體的講述以上幾點，我們用講故事的方式為程序猿進行講解，假設這次增加的是線上減肥課程的功能，我們可以這樣來描述：
“小明是一個26歲的白領，每天到了公司就是開會、敲鍵盤、趕項目，典型的脫髮人群。小明每天下班就已經不早了，再加上地鐵和走路的時間，經常很晚才到家，長期勞累且缺乏鍛鍊的生活使他體重上漲，為了健康，也為了找女朋友，小明痛下決心要減肥。
但是由於小明每天下班晚，回家的路程又遠，沒有整塊的時間去健身房，自己在家練吧又找不對方法，這使得小明非常苦惱。
而我們這次上的新功能呢，就是幫小明這種沒有時間去健身房，也不知道該如何減肥的人完成瘦身目標。你看：小明下班到家後，只需要打開手機app，選擇適合自己的減肥教程，然後跟著教程進行訓練就好了，訓練完後還可以將系統生成的圖片進行分享，發送到朋友圈中讓大家來監督他減肥。所以我們這個功能不僅幫小明節省了往返健身房的時間，還幫他免去了請私教的錢，是一個真真切切服務用戶的功能。”
用講故事的方式來描述項目背景的好處是，可以更好地把對方帶入到使用場景之中，從而能感同身受的理解用戶的痛點。最後在說新功能好處的時候，可以稍稍誇大一點，這樣可以激發程序猿的工作熱情，讓程序猿覺得自己在做一件非常有意義的事。最好我們講的故事能讓程序猿產生“躍躍欲試”的心理。
2. 功能流程介紹
項目背景介紹完了，程序猿們對項目也有認同感了，接下來的就是功能流程介紹了。
功能流程介紹分為業務流程介紹和數據流程介紹，業務流程介紹是站在用戶的角度上來展示用戶是如何使用的，按照用戶的操作順序，對照流程圖進行講解。比如：小明到家後打開APP，根據自己的需要選擇相應的課程類別，選擇類別後出現屬於該類別的課程列表，然後再選擇具體的課程進行訓練，訓練結束後系統將生成的圖片供用戶分享。
如下圖所示（已忽略所有異常情況）：
業務流程介紹可以簡短一些，只要讓程序猿瞭解功能點和頁面都有哪些就可以了。
需要詳細介紹的是數據流程，畢竟程序猿是天天跟數據打交道的，在介紹的時候要按照邏輯，以數據流為主線進行介紹，讓程序員們知道每一個數據都是哪裡來的。比如首先要在服務器存儲相關的課程數據，在用戶進入app選擇課程類別時，前端向服務器索要有關課程類別的數據並進行展示，這裡用UML序列圖展示：
在我們在按照數據流講解完之後，程序猿就能比較清楚的知道自己要做一個什麼功能了。到這裡，需求傳達就已經基本完成了，其實需求傳達屬於需求評審中講解的內容，需求評審結束後，我們就要著手準備項目排期了。
二、項目排期
在進行項目排期前，我們一定要提前把原型和文檔等資料交給程序猿們，最好在需求評審之前就開始讓程序猿們提前熟悉，這樣可以儘快的明確開發工作量。
1. 明確工作量
在這個階段我們的主要任務就是和項目經理進行溝通，確認什麼時候可以進行項目排期。因為在需求評審後需要給程序猿們一段緩衝期，程序猿們會利用這段緩衝期更仔細的瞭解需求，並思考開發方法；緩衝期結束後再進行項目排期。緩衝期的時間儘量讓項目經理來定，我們不要太多的干預，程序猿對需求研究的越透徹，思考的越全面，在後面的開發中才會越順利。
在經過緩衝期後，程序猿們基本已經對項目的工作量了然於胸了，這時程序猿往往會提出一些建議，出現最多的情況有以下兩種：
- 程序猿希望對需求提出異議（比如頁面交互，以及部分流程）；
- 程序猿希望砍掉部分需求。
針對第一點，我們一定要耐心聽完程序猿修改需求的理由，千萬不要覺得需求分析是自己的職能，他們提建議是在多管閒事，想把一件事做到面面俱到是很難的，有時候程序猿提的點子正好是你沒想到的地方。當出現這種情況時，不要著急給答覆，回去將程序猿給出的方案和之前自己的方案仔細對比一下，選出一個最優的。如果你覺得程序猿給出的建議更好，那麼就採納程序猿的建議，同時更新文檔並告知其他團隊人員。
如果是第二點，那麼就要分情況討論了，如果是不那麼重要的需求，可以放在下個版本，如果是自己本身也模稜兩可的需求，那麼直接砍掉就好了。但如果是核心需求，那麼堅決不砍，絕不讓步，核心需求是下個版本最重要的部分，是萬萬砍不得的。
當把工作量弄清楚以後，下一步就是確認開發順序和開發時間。
2. 確認開發順序
這裡主要需要確認的就是先開發哪些功能模塊，後開發哪些功能模塊，這裡注意，有了開發順序才能進行項目排期。
在確認開發順序的時候，我們仍然要和項目經理進行充分溝通，明確本次開發中有溢出風險的模塊，也就是說出了問題會嚴重影響其他模塊乃至整個產品上線的地方。
舉個栗子：假如我這次做的是一個智能穿戴設備的APP，那麼最有溢出風險的模塊是哪個呢？
不是註冊登錄，也不是數據顯示，而是設備與手機進行藍牙連接的模塊：註冊登錄我們可以用第三方登錄來解決，如果數據展示因為工期問題做不完，我們也可以砍掉部分展示數據以保證按時上線。但藍牙設備連接是不可能砍的，這是智能穿戴設備功能的基礎。
所以說，藍牙設備連接就是有溢出風險的模塊，在開發順序中一定要放在前面，這樣我們就可以先對藍牙連接模塊進行測試，這樣出現問題時可以提前解決，不會影響其他功能。
3. 確認開發時間
當確定好開發順序後，我們就可以根據開發順序來確認每個模塊的完成時間了，用甘特圖是一個不錯的選擇，製作甘特圖的時候，我們需要定任務，確職責。所以在表中我們要寫明任務，負責人，起止時間，以避免後期的扯皮。
而在開發過程中，前端在進行框架選取及頁面開發的時候，是不需要後端提供數據的，在後端進行數據庫設計以及編寫接口的時候，也是不需要UI設計師切圖的。因此前端開發和後端開發是可以並行的，如下圖所示：後端的橫向柱狀圖空缺的部分，是留給他們進行接口調試和bug修改的。
上圖這張甘特圖只是舉例，在實際的工作中，可以按每個模塊來劃分，將核心的、高風險的模塊向程序猿重點說明，在開發的過程中也要更細緻的跟進 。
如果項目有明確的截止時間，那麼我們就根據截止時間來倒推每個模塊的完成時間，如果時間實在不夠，砍需求吧，程序猿們會感激你的。
三、項目跟進
經過前期的工作，我們終於把事情推進到開發階段了，那麼產品經理在開發過程中會很輕鬆麼？當然不是，我們要對產品的結果負責，當然要對項目進行跟進。
1. 鱒魚和橋樑
在項目跟進的過程中，我們雖然對敲代碼沒有發言權，但是我們要時刻清楚地知道項目動態，並作為程序猿們溝通的橋樑，遇到問題時要協調相關人員進行溝通，像鱒魚一樣提高團隊的積極性和效率。
項目動態我們可以用每日站立會的方法來進行，站立會表面聽起來是開會，但是實際上我們不需要拘泥於開會的地點和形式，我們可以在每天早晨剛到公司的時候和程序猿溝通，也可以午休後在工位上進行，甚至一起上廁所的時候也可以。
開會的內容主要是昨天都做了什麼，今天要做什麼，遇到或者可能會遇到哪些問題。然後我們要積極的去協調，來幫助程序員解決問題。最好在程序猿開發某個模塊之前與他進行需求再確認，以確保最終開發出來的東西是我們心中所想的那樣。
在這個過程中，需要我們自身有主人翁意識，靈活而又勤快的去推動項目的進行。
2. 異常情況處理
雖然做足了準備，但還是經常會有異常情況出現，可能出現的異常情況有：
（1）程序員對需求理解有偏差
在項目的開發過程中，經常會出現這個問題，但這不能怪程序猿，畢竟寫的再詳細的文檔，不同的人看也可能會產生不同的理解，還有可能是我們的文檔寫的不夠詳細。
針對這個問題，我們應該把主要精力要放在預防上面：
在程序猿開發某一個小模塊前，尤其是新出現的或者是重點模塊，主動去找程序猿進行需求再確認，再和程序猿講明需求，也可以讓程序猿口述一下需求，我們來聽。最終目的就是要確認程序猿已經完全理解了需求，避免後續的更改與返工。
如果在開發過程中仍然出現了對需求的理解問題，比如前端和後端對接口的理解不一，如果你此時不去協調，那麼這個問題可能會被擱置，後期還是會爆發出來。還有可能是理解錯誤的一方將另一方說服，從而造成後期的返工和改動，這是很傷的。
當發現雙方有理解上的偏差時，一定要把雙方叫在一起討論，確保前端和後端都能正確的理解需求，再進行開發。在項目開始前一定和程序猿講明，對需求有任何分歧一定要找你，大家商議解決，而不要私下討論。
（2）出現需求變更
需求變更，無論是產品經理還是程序猿，看到這個詞都會覺得頭疼。
出現需求變更的原因主要有三個：
- 產品經理自己沒有思考全面，比如對異常情況的處理不夠細膩等等。我們應該儘量避免這種情況的發生，如果總出現這個問題，說明我們的工作是有疏忽的，程序猿也會對你產生不信任感。如果因為這個原因出現了需求變更，去找程序猿大爺說明吧，回來後對自己進行充分反思，並爭取在下一次做得更好。
- 老闆要求改需求，這種情況我們看似無能為力，但實際上也是有操作空間的。對於老闆的要求，我們首先要仔細的思考利弊，如果仍然覺得之前的方案好，拿出證據向老闆說明。如果老闆的方案更好，那麼我們就要有技巧的向程序猿說明。同樣可以利用講故事的方式，向程序猿說明更改需求的原因與必要性。這時就是考驗你和程序猿關係的時候了，沒事的時候記得和程序猿們打好關係哦。
- 自己腦袋中突然靈光一閃，覺得某個功能點有更好的方案。如果是這種情況，哪怕這個方案真的好，哪怕它能提升50%的轉化率，我還是建議放在下個版本進行優化，如果我們站在程序猿的角度上想：“需求是你定的，我代碼都寫一半了，你突然有了更好的點子，然後就讓我刪除自己辛辛苦苦敲出來的代碼，憑什麼？”
人非聖賢，誰也不能保證自己第一個方案就是完美的，當有了更好的點子時，我們不妨再增加一個優化版本，反正版本上線後我們也要收集用戶反饋，把這個點子放在優化版本里不是更好麼？
（3）項目進度延期
當發現項目進度已經落後的時候，我們首先要分析原因，根據原因來尋找解決辦法。可能的原因有以下幾個：
①團隊溝通不暢
如果前期做好了預防，一般是不會出現這個問題的。但真出現了這個問題怎麼辦呢？此時我們就需要找到溝通不暢的當事人，詢問原因，是成員之間不能正確理解對方的意思呢，還是互相不認可對方的觀點。
如果是溝通不暢的雙方沒有辦法正確理解對方的意思，那此時我們要做雙方的“翻譯機”，確保成員之間理解統一；如果是互相不認可對方的觀點，那麼此時，抓上項目經理或開發主管，一起來商量誰的解決辦法更好。總而言之，一定要確保團隊成員對項目理解的統一，大家帶著同一個目標前進。
②程序猿能力不夠
之前也遇到過這種問題，程序猿小A難以完成分配給他任務，這時我們就要叫上技術的大佬，然後讓程序猿小A去敘述他遇到了什麼難題，讓大家一起解決，解決問題的方法我們就不摻和了，做好團隊之間的橋樑就好。
③程序猿因為生活上的事導致情緒低落，開發積極性低
我們都是人， 是有情感的動物，難免會因為生活上的的事情影響到工作，這時候，我們要從同事的身份中脫離出來，作為朋友，帶著程序猿去吃點小菜，喝掉小酒，聊聊人生，看看美女，沒事再給程序猿買點零食，送點溫暖。此時對待程序猿要向對待自己女朋友一樣溫柔，幫他從情緒低谷中走出來，重新振作開始工作，這樣無論是對於團隊，還是對於他自己，都是有好處的。
④對工期預估過於樂觀，項目排期出現了問題
項目排期，其實也是一個預估的時間，誰也不能保證一定可以準時完成，如果是項目排期出現了問題，一般項目經理會讓大家用出神技：加班！！
當然此時我們也不能眼睜睜的看著程序猿們加班，我們可以發揮自己的價值：砍！需！求！雖然心很痛，但是看著程序猿們日益稀疏的頭髮，還是咬咬牙把需求砍掉吧，找機會再加。
如果砍無可砍，趕緊重新評估時間並向老大報告，避免因為自己項目的延期影響到整條產品線。
總結
目前我個人對項目的理解就是這些了，在最後做個總結，要想做好項目管理，產品經理要有以下幾個意識：
（1）主次意識
在一個項目裡，一定要分清主次，知道哪些是主要的、核心的，要時刻關注的，哪些是可有可無的，可以砍掉的。
（2）風險意識
在項目開始前，我們就要知道哪些模塊是有溢出風險的，或者可控性不強的，比如想做智能穿戴設備，如果不打通藍牙模塊，後面的檢測心跳，記錄步數等各功能都是沒有意義的。再比如我們把一部分外包給其他公司，這就屬於可控性低的情況下。
因為我們自己公司可以通過加強溝通，加班等方式來解決的問題，可能外包項目就解決不了，出現問題時雙方的溝通效率就是比自己公司內部低。如果到項目結尾才開始驗收外包部分，此時出了問題很大可能會影響項目的按時上線。
對於高風險部分，我們應該提前做好預案，並在項目過程中對有風險的部分多加關注，將問題殺死在萌芽狀態。
（3）時間意識
項目管理，無非就是通過資源的調動來達成目標。資源可以是人員，也可以是時間，而作為重要資源的時間，我們必須時刻關注，一旦失控可能會造成連鎖反應。
在時間的管控上面，我們不僅要做好項目時間管理，同時也要做好自己的時間管理，這樣我們才能在項目中游刃有餘的去應對難題。
（4）溝通意識
其實溝通在本文已經出現很多次了，我們要做團隊溝通的橋樑，就要站在對方的角度，用對方能理解的方式和他進行溝通，多用舉例進行說明，很多事情直接說可能說不明白，舉個例子大家就很容易懂了。
（5）主人翁意識
在項目推進中，是需要我們產品經理和項目經理一起牽頭的，我們要把自己當成老闆，出現意外時多向下想一步，思考一下表象下真正的原因，然後去解決。
我的訣竅就是：先假設這個問題不是偶然問題，然後站在更高層次去思考解決辦法，這樣就可以避免日後再發生此類問題。
經常問一問自己：“這是問題的真正原因麼？這樣去解決以後還會發生麼？”要儘自己最大努力，去做好團隊中的“發動機”。
本文由 @撒野的氧氣 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
