在産品叠代中，産品經理要負責相關産品開發周期和進度的把控，進行跨部門協調和溝通，最終保證新版本按時上線，這就需要産品經理具有項目管理能力。今天，我們就來聊一聊項目管理。

本文結構如下：

項目管理不單單是在産品開發過程中進行，在對一個項目進行管理時，開發前的需求傳達，項目排期，以及開發中的跟進開發，都是非常重要的，做好以上幾點，版本按時上線也就不難了。

由于程序猿們沒有經曆需求篩選，需求分析等步驟，因此當産品經理決定上一個新功能時，一定要和程序猿們進行完整的需求傳達。在需求傳達時，我們可以按照項目背景以及功能流程進行介紹。

1. 項目背景介紹

在進行項目背景介紹時，我們要清楚的告知程序猿這個新功能所針對的目标用戶是誰，使用場景是什麼，以及這個項目解決了用戶什麼需求，總結下來就是5w1h：who、when、where、what、how、why（誰，在什麼時候，在哪，解決什麼問題，如何解決的，為什麼去解決）。

為了形象而具體的講述以上幾點，我們用講故事的方式為程序猿進行講解，假設這次增加的是線上減肥課程的功能，我們可以這樣來描述：

“小明是一個26歲的白領，每天到了公司就是開會、敲鍵盤、趕項目，典型的脫發人群。小明每天下班就已經不早了，再加上地鐵和走路的時間，經常很晚才到家，長期勞累且缺乏鍛煉的生活使他體重上漲，為了健康，也為了找女朋友，小明痛下決心要減肥。

但是由于小明每天下班晚，回家的路程又遠，沒有整塊的時間去健身房，自己在家練吧又找不對方法，這使得小明非常苦惱。

而我們這次上的新功能呢，就是幫小明這種沒有時間去健身房，也不知道該如何減肥的人完成瘦身目标。你看：小明下班到家後，隻需要打開手機app，選擇适合自己的減肥教程，然後跟着教程進行訓練就好了，訓練完後還可以将系統生成的圖片進行分享，發送到朋友圈中讓大家來監督他減肥。所以我們這個功能不僅幫小明節省了往返健身房的時間，還幫他免去了請私教的錢，是一個真真切切服務用戶的功能。”

用講故事的方式來描述項目背景的好處是，可以更好地把對方帶入到使用場景之中，從而能感同身受的理解用戶的痛點。最後在說新功能好處的時候，可以稍稍誇大一點，這樣可以激發程序猿的工作熱情，讓程序猿覺得自己在做一件非常有意義的事。最好我們講的故事能讓程序猿産生“躍躍欲試”的心理。

2. 功能流程介紹

項目背景介紹完了，程序猿們對項目也有認同感了，接下來的就是功能流程介紹了。

功能流程介紹分為業務流程介紹和數據流程介紹，業務流程介紹是站在用戶的角度上來展示用戶是如何使用的，按照用戶的操作順序，對照流程圖進行講解。比如：小明到家後打開APP，根據自己的需要選擇相應的課程類别，選擇類别後出現屬于該類别的課程列表，然後再選擇具體的課程進行訓練，訓練結束後系統将生成的圖片供用戶分享。

如下圖所示（已忽略所有異常情況）：

業務流程介紹可以簡短一些，隻要讓程序猿了解功能點和頁面都有哪些就可以了。

需要詳細介紹的是數據流程，畢竟程序猿是天天跟數據打交道的，在介紹的時候要按照邏輯，以數據流為主線進行介紹，讓程序員們知道每一個數據都是哪裡來的。比如首先要在服務器存儲相關的課程數據，在用戶進入app選擇課程類别時，前端向服務器索要有關課程類别的數據并進行展示，這裡用UML序列圖展示：

在我們在按照數據流講解完之後，程序猿就能比較清楚的知道自己要做一個什麼功能了。到這裡，需求傳達就已經基本完成了，其實需求傳達屬于需求評審中講解的内容，需求評審結束後，我們就要着手準備項目排期了。

在進行項目排期前，我們一定要提前把原型和文檔等資料交給程序猿們，最好在需求評審之前就開始讓程序猿們提前熟悉，這樣可以盡快的明确開發工作量。

1. 明确工作量

在這個階段我們的主要任務就是和項目經理進行溝通，确認什麼時候可以進行項目排期。因為在需求評審後需要給程序猿們一段緩沖期，程序猿們會利用這段緩沖期更仔細的了解需求，并思考開發方法；緩沖期結束後再進行項目排期。緩沖期的時間盡量讓項目經理來定，我們不要太多的幹預，程序猿對需求研究的越透徹，思考的越全面，在後面的開發中才會越順利。

在經過緩沖期後，程序猿們基本已經對項目的工作量了然于胸了，這時程序猿往往會提出一些建議，出現最多的情況有以下兩種：

1. 程序猿希望對需求提出異議（比如頁面交互，以及部分流程）；
2. 程序猿希望砍掉部分需求。

針對第一點，我們一定要耐心聽完程序猿修改需求的理由，千萬不要覺得需求分析是自己的職能，他們提建議是在多管閑事，想把一件事做到面面俱到是很難的，有時候程序猿提的點子正好是你沒想到的地方。當出現這種情況時，不要着急給答複，回去将程序猿給出的方案和之前自己的方案仔細對比一下，選出一個最優的。如果你覺得程序猿給出的建議更好，那麼就采納程序猿的建議，同時更新文檔并告知其他團隊人員。

如果是第二點，那麼就要分情況讨論了，如果是不那麼重要的需求，可以放在下個版本，如果是自己本身也模棱兩可的需求，那麼直接砍掉就好了。但如果是核心需求，那麼堅決不砍，絕不讓步，核心需求是下個版本最重要的部分，是萬萬砍不得的。

當把工作量弄清楚以後，下一步就是确認開發順序和開發時間。

2. 确認開發順序

這裡主要需要确認的就是先開發哪些功能模塊，後開發哪些功能模塊，這裡注意，有了開發順序才能進行項目排期。

在确認開發順序的時候，我們仍然要和項目經理進行充分溝通，明确本次開發中有溢出風險的模塊，也就是說出了問題會嚴重影響其他模塊乃至整個産品上線的地方。

舉個栗子：假如我這次做的是一個智能穿戴設備的APP，那麼最有溢出風險的模塊是哪個呢？

不是注冊登錄，也不是數據顯示，而是設備與手機進行藍牙連接的模塊：注冊登錄我們可以用第三方登錄來解決，如果數據展示因為工期問題做不完，我們也可以砍掉部分展示數據以保證按時上線。但藍牙設備連接是不可能砍的，這是智能穿戴設備功能的基礎。

所以說，藍牙設備連接就是有溢出風險的模塊，在開發順序中一定要放在前面，這樣我們就可以先對藍牙連接模塊進行測試，這樣出現問題時可以提前解決，不會影響其他功能。

3. 确認開發時間

當确定好開發順序後，我們就可以根據開發順序來确認每個模塊的完成時間了，用甘特圖是一個不錯的選擇，制作甘特圖的時候，我們需要定任務，确職責。所以在表中我們要寫明任務，負責人，起止時間，以避免後期的扯皮。

而在開發過程中，前端在進行框架選取及頁面開發的時候，是不需要後端提供數據的，在後端進行數據庫設計以及編寫接口的時候，也是不需要UI設計師切圖的。因此前端開發和後端開發是可以并行的，如下圖所示：後端的橫向柱狀圖空缺的部分，是留給他們進行接口調試和bug修改的。

上圖這張甘特圖隻是舉例，在實際的工作中，可以按每個模塊來劃分，将核心的、高風險的模塊向程序猿重點說明，在開發的過程中也要更細緻的跟進。

如果項目有明确的截止時間，那麼我們就根據截止時間來倒推每個模塊的完成時間，如果時間實在不夠，砍需求吧，程序猿們會感激你的。

經過前期的工作，我們終于把事情推進到開發階段了，那麼産品經理在開發過程中會很輕松麼？當然不是，我們要對産品的結果負責，當然要對項目進行跟進。

1. 鳟魚和橋梁

在項目跟進的過程中，我們雖然對敲代碼沒有發言權，但是我們要時刻清楚地知道項目動态，并作為程序猿們溝通的橋梁，遇到問題時要協調相關人員進行溝通，像鳟魚一樣提高團隊的積極性和效率。

項目動态我們可以用每日站立會的方法來進行，站立會表面聽起來是開會，但是實際上我們不需要拘泥于開會的地點和形式，我們可以在每天早晨剛到公司的時候和程序猿溝通，也可以午休後在工位上進行，甚至一起上廁所的時候也可以。

開會的内容主要是昨天都做了什麼，今天要做什麼，遇到或者可能會遇到哪些問題。然後我們要積極的去協調，來幫助程序員解決問題。最好在程序猿開發某個模塊之前與他進行需求再确認，以确保最終開發出來的東西是我們心中所想的那樣。

在這個過程中，需要我們自身有主人翁意識，靈活而又勤快的去推動項目的進行。

2. 異常情況處理

雖然做足了準備，但還是經常會有異常情況出現，可能出現的異常情況有：

（1）程序員對需求理解有偏差

在項目的開發過程中，經常會出現這個問題，但這不能怪程序猿，畢竟寫的再詳細的文檔，不同的人看也可能會産生不同的理解，還有可能是我們的文檔寫的不夠詳細。

針對這個問題，我們應該把主要精力要放在預防上面：

在程序猿開發某一個小模塊前，尤其是新出現的或者是重點模塊，主動去找程序猿進行需求再确認，再和程序猿講明需求，也可以讓程序猿口述一下需求，我們來聽。最終目的就是要确認程序猿已經完全理解了需求，避免後續的更改與返工。

如果在開發過程中仍然出現了對需求的理解問題，比如前端和後端對接口的理解不一，如果你此時不去協調，那麼這個問題可能會被擱置，後期還是會爆發出來。還有可能是理解錯誤的一方将另一方說服，從而造成後期的返工和改動，這是很傷的。

當發現雙方有理解上的偏差時，一定要把雙方叫在一起讨論，确保前端和後端都能正确的理解需求，再進行開發。在項目開始前一定和程序猿講明，對需求有任何分歧一定要找你，大家商議解決，而不要私下讨論。

（2）出現需求變更

需求變更，無論是産品經理還是程序猿，看到這個詞都會覺得頭疼。

出現需求變更的原因主要有三個：

1. 産品經理自己沒有思考全面，比如對異常情況的處理不夠細膩等等。我們應該盡量避免這種情況的發生，如果總出現這個問題，說明我們的工作是有疏忽的，程序猿也會對你産生不信任感。如果因為這個原因出現了需求變更，去找程序猿大爺說明吧，回來後對自己進行充分反思，并争取在下一次做得更好。
2. 老闆要求改需求，這種情況我們看似無能為力，但實際上也是有操作空間的。對于老闆的要求，我們首先要仔細的思考利弊，如果仍然覺得之前的方案好，拿出證據向老闆說明。如果老闆的方案更好，那麼我們就要有技巧的向程序猿說明。同樣可以利用講故事的方式，向程序猿說明更改需求的原因與必要性。這時就是考驗你和程序猿關系的時候了，沒事的時候記得和程序猿們打好關系哦。
3. 自己腦袋中突然靈光一閃，覺得某個功能點有更好的方案。如果是這種情況，哪怕這個方案真的好，哪怕它能提升50%的轉化率，我還是建議放在下個版本進行優化，如果我們站在程序猿的角度上想：“需求是你定的，我代碼都寫一半了，你突然有了更好的點子，然後就讓我删除自己辛辛苦苦敲出來的代碼，憑什麼？”

人非聖賢，誰也不能保證自己第一個方案就是完美的，當有了更好的點子時，我們不妨再增加一個優化版本，反正版本上線後我們也要收集用戶反饋，把這個點子放在優化版本裡不是更好麼？

（3）項目進度延期

當發現項目進度已經落後的時候，我們首先要分析原因，根據原因來尋找解決辦法。可能的原因有以下幾個：

①團隊溝通不暢

如果前期做好了預防，一般是不會出現這個問題的。但真出現了這個問題怎麼辦呢？此時我們就需要找到溝通不暢的當事人，詢問原因，是成員之間不能正确理解對方的意思呢，還是互相不認可對方的觀點。

如果是溝通不暢的雙方沒有辦法正确理解對方的意思，那此時我們要做雙方的“翻譯機”，确保成員之間理解統一；如果是互相不認可對方的觀點，那麼此時，抓上項目經理或開發主管，一起來商量誰的解決辦法更好。總而言之，一定要确保團隊成員對項目理解的統一，大家帶着同一個目标前進。

②程序猿能力不夠

之前也遇到過這種問題，程序猿小A難以完成分配給他任務，這時我們就要叫上技術的大佬，然後讓程序猿小A去叙述他遇到了什麼難題，讓大家一起解決，解決問題的方法我們就不摻和了，做好團隊之間的橋梁就好。

③程序猿因為生活上的事導緻情緒低落，開發積極性低

我們都是人， 是有情感的動物，難免會因為生活上的的事情影響到工作，這時候，我們要從同事的身份中脫離出來，作為朋友，帶着程序猿去吃點小菜，喝掉小酒，聊聊人生，看看美女，沒事再給程序猿買點零食，送點溫暖。此時對待程序猿要向對待自己女朋友一樣溫柔，幫他從情緒低谷中走出來，重新振作開始工作，這樣無論是對于團隊，還是對于他自己，都是有好處的。

④對工期預估過于樂觀，項目排期出現了問題

項目排期，其實也是一個預估的時間，誰也不能保證一定可以準時完成，如果是項目排期出現了問題，一般項目經理會讓大家用出神技：加班！！

當然此時我們也不能眼睜睜的看着程序猿們加班，我們可以發揮自己的價值：砍！需！求！雖然心很痛，但是看着程序猿們日益稀疏的頭發，還是咬咬牙把需求砍掉吧，找機會再加。

如果砍無可砍，趕緊重新評估時間并向老大報告，避免因為自己項目的延期影響到整條産品線。

目前我個人對項目的理解就是這些了，在最後做個總結，要想做好項目管理，産品經理要有以下幾個意識：

（1）主次意識

在一個項目裡，一定要分清主次，知道哪些是主要的、核心的，要時刻關注的，哪些是可有可無的，可以砍掉的。

（2）風險意識

在項目開始前，我們就要知道哪些模塊是有溢出風險的，或者可控性不強的，比如想做智能穿戴設備，如果不打通藍牙模塊，後面的檢測心跳，記錄步數等各功能都是沒有意義的。再比如我們把一部分外包給其他公司，這就屬于可控性低的情況下。

因為我們自己公司可以通過加強溝通，加班等方式來解決的問題，可能外包項目就解決不了，出現問題時雙方的溝通效率就是比自己公司内部低。如果到項目結尾才開始驗收外包部分，此時出了問題很大可能會影響項目的按時上線。

對于高風險部分，我們應該提前做好預案，并在項目過程中對有風險的部分多加關注，将問題殺死在萌芽狀态。

（3）時間意識

項目管理，無非就是通過資源的調動來達成目标。資源可以是人員，也可以是時間，而作為重要資源的時間，我們必須時刻關注，一旦失控可能會造成連鎖反應。

在時間的管控上面，我們不僅要做好項目時間管理，同時也要做好自己的時間管理，這樣我們才能在項目中遊刃有餘的去應對難題。

（4）溝通意識

其實溝通在本文已經出現很多次了，我們要做團隊溝通的橋梁，就要站在對方的角度，用對方能理解的方式和他進行溝通，多用舉例進行說明，很多事情直接說可能說不明白，舉個例子大家就很容易懂了。

（5）主人翁意識

在項目推進中，是需要我們産品經理和項目經理一起牽頭的，我們要把自己當成老闆，出現意外時多向下想一步，思考一下表象下真正的原因，然後去解決。

我的訣竅就是：先假設這個問題不是偶然問題，然後站在更高層次去思考解決辦法，這樣就可以避免日後再發生此類問題。

經常問一問自己：“這是問題的真正原因麼？這樣去解決以後還會發生麼？”要盡自己最大努力，去做好團隊中的“發動機”。

作者：撒野的氧氣，公衆号：産品汪的成長路

本文由 @撒野的氧氣 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。