在產(chǎn)品迭代中，產(chǎn)品經(jīng)理要負責(zé)相關(guān)產(chǎn)品開發(fā)周期和進度的把控，進行跨部門協(xié)調(diào)和溝通，最終保證新版本按時上線，這就需要產(chǎn)品經(jīng)理具有項目管理能力。今天，我們就來聊一聊項目管理。

本文結(jié)構(gòu)如下：

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

一、需求傳達

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

1. 項目背景介紹

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

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

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

但是由于小明每天下班晚，回家的路程又遠，沒有整塊的時間去健身房，自己在家練吧又找不對方法，這使得小明非?？鄲馈?/p>

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

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

2. 功能流程介紹

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

功能流程介紹分為業(yè)務(wù)流程介紹和數(shù)據(jù)流程介紹，業(yè)務(wù)流程介紹是站在用戶的角度上來展示用戶是如何使用的，按照用戶的操作順序，對照流程圖進行講解。比如：小明到家后打開APP，根據(jù)自己的需要選擇相應(yīng)的課程類別，選擇類別后出現(xiàn)屬于該類別的課程列表，然后再選擇具體的課程進行訓(xùn)練，訓(xùn)練結(jié)束后系統(tǒng)將生成的圖片供用戶分享。

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

業(yè)務(wù)流程介紹可以簡短一些，只要讓程序猿了解功能點和頁面都有哪些就可以了。

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

在我們在按照數(shù)據(jù)流講解完之后，程序猿就能比較清楚的知道自己要做一個什么功能了。到這里，需求傳達就已經(jīng)基本完成了，其實需求傳達屬于需求評審中講解的內(nèi)容，需求評審結(jié)束后，我們就要著手準備項目排期了。

二、項目排期

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

1. 明確工作量

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

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

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

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

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

當把工作量弄清楚以后，下一步就是確認開發(fā)順序和開發(fā)時間。

2. 確認開發(fā)順序

這里主要需要確認的就是先開發(fā)哪些功能模塊，后開發(fā)哪些功能模塊，這里注意，有了開發(fā)順序才能進行項目排期。

在確認開發(fā)順序的時候，我們?nèi)匀灰晚椖拷?jīng)理進行充分溝通，明確本次開發(fā)中有溢出風(fēng)險的模塊，也就是說出了問題會嚴重影響其他模塊乃至整個產(chǎn)品上線的地方。

舉個栗子：假如我這次做的是一個智能穿戴設(shè)備的APP，那么最有溢出風(fēng)險的模塊是哪個呢？

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

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

3. 確認開發(fā)時間

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

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

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

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

三、項目跟進

經(jīng)過前期的工作，我們終于把事情推進到開發(fā)階段了，那么產(chǎn)品經(jīng)理在開發(fā)過程中會很輕松么？當然不是，我們要對產(chǎn)品的結(jié)果負責(zé)，當然要對項目進行跟進。

1. 鱒魚和橋梁

在項目跟進的過程中，我們雖然對敲代碼沒有發(fā)言權(quán)，但是我們要時刻清楚地知道項目動態(tài)，并作為程序猿們溝通的橋梁，遇到問題時要協(xié)調(diào)相關(guān)人員進行溝通，像鱒魚一樣提高團隊的積極性和效率。

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

開會的內(nèi)容主要是昨天都做了什么，今天要做什么，遇到或者可能會遇到哪些問題。然后我們要積極的去協(xié)調(diào)，來幫助程序員解決問題。最好在程序猿開發(fā)某個模塊之前與他進行需求再確認，以確保最終開發(fā)出來的東西是我們心中所想的那樣。

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

2. 異常情況處理

雖然做足了準備，但還是經(jīng)常會有異常情況出現(xiàn)，可能出現(xiàn)的異常情況有：

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

在項目的開發(fā)過程中，經(jīng)常會出現(xiàn)這個問題，但這不能怪程序猿，畢竟寫的再詳細的文檔，不同的人看也可能會產(chǎn)生不同的理解，還有可能是我們的文檔寫的不夠詳細。

針對這個問題，我們應(yīng)該把主要精力要放在預(yù)防上面：

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

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

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

（2）出現(xiàn)需求變更

需求變更，無論是產(chǎn)品經(jīng)理還是程序猿，看到這個詞都會覺得頭疼。

出現(xiàn)需求變更的原因主要有三個：

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

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

（3）項目進度延期

當發(fā)現(xiàn)項目進度已經(jīng)落后的時候，我們首先要分析原因，根據(jù)原因來尋找解決辦法?？赡艿脑蛴幸韵聨讉€：

①團隊溝通不暢

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

如果是溝通不暢的雙方?jīng)]有辦法正確理解對方的意思，那此時我們要做雙方的“翻譯機”，確保成員之間理解統(tǒng)一；如果是互相不認可對方的觀點，那么此時，抓上項目經(jīng)理或開發(fā)主管，一起來商量誰的解決辦法更好。總而言之，一定要確保團隊成員對項目理解的統(tǒng)一，大家?guī)е粋€目標前進。

②程序猿能力不夠

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

③程序猿因為生活上的事導(dǎo)致情緒低落，開發(fā)積極性低

我們都是人， 是有情感的動物，難免會因為生活上的的事情影響到工作，這時候，我們要從同事的身份中脫離出來，作為朋友，帶著程序猿去吃點小菜，喝掉小酒，聊聊人生，看看美女，沒事再給程序猿買點零食，送點溫暖。此時對待程序猿要向?qū)Υ约号笥岩粯訙厝幔瑤退麖那榫w低谷中走出來，重新振作開始工作，這樣無論是對于團隊，還是對于他自己，都是有好處的。

④對工期預(yù)估過于樂觀，項目排期出現(xiàn)了問題

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

當然此時我們也不能眼睜睜的看著程序猿們加班，我們可以發(fā)揮自己的價值：砍！需！求！雖然心很痛，但是看著程序猿們?nèi)找嫦∈璧念^發(fā)，還是咬咬牙把需求砍掉吧，找機會再加。

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

總結(jié)

目前我個人對項目的理解就是這些了，在最后做個總結(jié)，要想做好項目管理，產(chǎn)品經(jīng)理要有以下幾個意識：

（1）主次意識

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

（2）風(fēng)險意識

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

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

對于高風(fēng)險部分，我們應(yīng)該提前做好預(yù)案，并在項目過程中對有風(fēng)險的部分多加關(guān)注，將問題殺死在萌芽狀態(tài)。

（3）時間意識

項目管理，無非就是通過資源的調(diào)動來達成目標。資源可以是人員，也可以是時間，而作為重要資源的時間，我們必須時刻關(guān)注，一旦失控可能會造成連鎖反應(yīng)。

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

（4）溝通意識

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

（5）主人翁意識

在項目推進中，是需要我們產(chǎn)品經(jīng)理和項目經(jīng)理一起牽頭的，我們要把自己當成老板，出現(xiàn)意外時多向下想一步，思考一下表象下真正的原因，然后去解決。

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

經(jīng)常問一問自己：“這是問題的真正原因么？這樣去解決以后還會發(fā)生么？”要盡自己最大努力，去做好團隊中的“發(fā)動機”。

作者：撒野的氧氣，公眾號：產(chǎn)品汪的成長路

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

題圖來自Unsplash，基于CC0協(xié)議。