太多的產品新人，甚至于工作一兩年的產品汪，在開發階段往往出現很多對接問題，影響上線進度。在此，我將程序開發階段總結為一下4個階段，并以故事的形式，分流程介紹我們該如何與開發對接。因內容較多，且需要與實際工作結合進行考慮，所以建議大家收藏下來，慢慢看。

下圖為此系列內容的大綱：

今天我們說說第3部分，也是最關鍵的一部分——跟進項目開發。如果沒有看過前兩篇文章的同學， 請點擊下面的傳送門：

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（2）》

故事背景：

小明：某IT公司的一名產品新人。

老王：某IT公司的產品總監。

項目進度：產品開發階段。

經過老王的細心指導與小明的不懈努力，終于在2周內確定了開發進度排期與項目的關鍵節點。雖然最后勉強算完成了階段性工作。但對于剛做產品的新人來說，還是挺不錯的。

看著一步一步成長起來的小明，老王決定，是時候再幫他一把了。

老王：翠蘭（老王秘書），叫小明來趟辦公室來。

翠花：好來!

5分鐘后，小明走進老王辦公室：王總，您找我？

老王：坐，今天找你，是想跟你聊聊最近工作的問題。

小明：王總，我最近沒犯什么錯誤吧？

老王：別激動，沒事，就是隨便聊聊。

小明送了一口氣，道：王總，最近我感覺工作重心明顯有焦點了，知道該做什么，不該做什么了。做起事情來得心應手，這都是您教的好。我能有今天的進步，都歸功與您的細心教導······（此處省略1000字）

老王：行了，行了。就知道拍馬屁。有這功夫還不如給我買包煙來的實在。

小明一臉黑線~~~

老王：好了，說正事。前兩周我觀察了一下你的日常工作。還不錯，能打70分。但是在溝通協調這塊，你還是要注意一些，盡量放低一些姿態。讓程序猿們在輕松的環境下表達自己的想法與見解，這個你還需要加強。

小明：嗯，虛心聽從領導教誨。

老王無奈道：在整個產品開發過程中，主力軍還是程序猿們。但是作為整個產品的負責人，我們也應該在里面做一些力所能及的事情，幫助項目順利開發與上線，我把這些整理成了三個部分，今天我們就聊聊這個。

需求變更與需求再確認

老王：還記得之前讓你去確定項開發順序嗎？

小明：嗯，記得。都已經完成了。

老王：好，那在接下來的階段，我們就會用到這張開發順序表。老張你知道吧，就是技術部門的主管，他跟我關系很好，我們周末經常一起喝酒聊天。我之前有問過他，在項目開發過程中最煩什么事？他對我說“最煩的就是產品改需求，本來好好的功能都做的差不多了。產品非要說產品需求有問題，要變更需求，甚至有時候要砍掉需求。多少次因為這個問題，哥連夜刪代碼，一次次的shift+delet，都是在割肉??！”我對這句話印象很深。后來我反省為什么會出現這種問題的時候?？偨Y出的答案就是因為需求未確認與修改需求不慎重導致的。至于要解決這個問題，有3種途徑解決：

在開發之前，確認哪些需求需要變更，并提供變更方案

老張經常對我說的一句話“程序猿都是一群性格溫順的食草動物，如果你把他惹火了，那你肯定做了令他特別不能容忍的事”。而更改需求往往最容易惹惱這批溫順的程序猿們，且耽誤了項目開發進度。當然，在開發階段也不是不能改需求。而頻繁改需求，本質上的原因是因為這個產品經理的能力不夠，能力不夠的話，我們就用努力來湊。所以項目開發之前，我們需求將需求再從頭到尾梳理一遍。明確每個需求都能走通，且每個需求是具有實際價值的需求。這時候需要用到你整理關鍵節點表了，你只要這個順序，在程序猿開發前，將修改的需求與開發確認一遍就可以了。但是在確認的時候，不要光口頭溝通，要有落地的方案。

同時在修改需求的時候，需要在產品說明文檔中同步進行修改，并記錄好版本號，同時確認好程序猿手中拿到的版本就是最新的版本。

每次開發前需要進行需求再確認，明確自己要的與開發理解的是否一致

老王突然問道：小明，你喜歡吃米飯還是喜歡吃饅頭??？

小明：我們廣東人喜歡吃米飯。

老王又問：那如果你讓你女朋友做米飯吃，她給你端上了一碗粥，你是感覺？

小明：王總，我沒女朋友~但是如果發生這種情況的話，我心里肯定是非常惱火的，讓她再去做一份。

老王：嗯，產品經理與程序猿就好比你與你女朋友，如果你沒有跟程序猿說清楚，你要吃“米飯”，那最后很大可能會給你端來一碗粥。這個時候你又讓他重新做。既耽誤了開發時間，又造成程序猿心態爆炸，嚴重耽誤項目正常開展。

這個時候，我們就需要在開發之前，明確我們要的是什么。而在確認需求的時候，可以通過兩個維度進行確定（或者說是再次強調）。第一種是用概括的語言，再次強調某個模塊的主要作用，關鍵的功能。這個主要的目的是讓程序猿的主要方向不走偏，不會出現要“米飯”卻上了“饅頭”的情況。第二個是把產品說明文檔中描述不清楚的語言再重新組織，并提交給開發。這個也是需要在程序開發之前進行確定的。

小明：王總，那這個需求變更與需求再確認的時間，需要提前多少??？

老王：這個不是固定的，通常提前一兩天就可以了。

充分了解需求變更的成本，盡量降低修改（增加）需求的欲望

“我有個非常好的idea，放在這個版本最少能給我們增加20%用戶，你看下這個版本就給做出來吧”。程序猿聽到這種話的時候，通常腦里會有1w只馬奔騰而過。確實，在開發過程中增加需求，會大大增加開發的時間成本，同時會打亂程序猿的開發節奏。在這個時候，克制住自己更改（增加）需求的欲望是非常關鍵的，除非按照原來的需求確實會造成嚴重影響，要不就盡量不去更改（增加）需求吧。

小明：那如果新增的需求確實很好，確實能帶來很好的效果，這時候是不是可以放在這個版本中同步開發呢？

老王：那也不行，這種需求，統一放在下一個版本里面進行開發。這種增加需求的快感，會令你陷入新增需求的死循環中。那項目什么時候能上線??？

小明：哦，明白了。

站立會與周例會

老王掏出了煙，點了一根（現在才點煙，是不是不符合老王的性格?。簞偛耪f了那幾點你記下來了嗎？

小明：嗯，都記下來了。

老王：那我們繼續往下說。上面說的那些方法，都是需要開會進行確定的，而在開發過程中，程序猿的時間又很寶貴，那在這個時候開會，我們就需要用到站立會與周例會這兩種會議形式。

站立會，聽表面的意思就是站著開會，實際也是差不多的。他是一種不局限于地點的開會形式，大家可以在電腦前開會，也可以湊在一個角落里“偷偷摸摸”的開會，甚至于你們一起去廁所開會也是可以的。這個會議主要是由項目經理主導，在上班前，每個成員用1到2分鐘，簡單介紹下昨天具體干了些什么，遇到了些什么問題，今天要處理什么。而作為產品經理的你，主要的任務就是記錄，記錄各程序猿們遇到的問題。至于發言，還是算了吧。

而周例會，一周通常會召開兩次，一次是在周一上班前，大家聚在一起說明一下上周工作的完成情況、是否按時完成、沒完成是因為什么原因、遇到了哪些問題、這個周的計劃是什么。而做為產品經理的你，這個時候就需要將這個周需要開發的需求再強調一遍（這個不是必須要說的，可以根據功能重要程度的不同，選擇是否需要再次強調）、需求變更的地方說明一下（可簡答說明改了那些地方，細節的部分可會后對接）、同時做好記錄（主要記錄現階段的程序猿開發遇到的問題）。

小明：王總，花時間記錄這么多問題有什么用??？好費時間啊

老王：這些問題大部分都是需要你去幫他們解決的，你以為開發階段產品經理很輕松啊。

小明：啊，不會吧。

支持與協調

老王：有什么好驚訝的，就是一些支持、協調的工作，沒什么難的。關鍵是要情商高且勤快。剛才跟你說的，產品經理在周例會與站立會的時候，大部分的工作是記錄一些產品開發的問題，而這些問題，不是記錄下來就不管了，都是需要你來提供支持并協調其他同事來解決問題的。下面就列舉幾個常見的問題，說說該怎么辦：

需求不明確與需求不合理

關于需求的變更與確認，在整個項目開發階段中都是一直存在的，不會因為項目評估的仔細，就可以避免。所以在這個階段，開發找你確定需求的時候，不要有抵觸心理，要細心的去講解一些需求的邏輯，如果不是特別的邏輯問題，盡量不要修改bug。再重復一下之前多次說過的一句話：變更過的需求，一定要有切實可行的落地方案，并記錄在PRD文檔中。

其他項目突然插進來，影響開發進度

像我們這種小公司，大多數的程序猿都是身兼多個項目的，所以開發中，很容易碰到需要緊急處理的事情。這種情況就會導致項目延期。而要完全去避免這種情況的發生，也是不現實的。所以在遇到其他項目需求插進來的時候，一定要確定這個需求的優先級與嚴重程度。通常較緊急的bug需要立即處理，一些緊急的活動需求，也是需要安排進行的，優化類型的需求可以暫時放一下。當然插進來的工作耗費了多少時間你需要記錄下來，可以作為后面項目延期的理由。

但是在執行的時候，可能就會遇到一些的問題。（1）例如其他產品的產品經理覺得這個需求比較緊急，而你認為也就那么回事。（2）項目經理覺得你過度插手他的日常管理工作。所以在處理這些問題上，就要考察我們的溝通協調能力。

小明：王總，那遇到這些問題，要咋辦呢？

老王翻了個白眼：你就不會動動腦子想想？既然項目經理覺得你插手他們的日常工作，那你就提前跟他說一下這些問題是由他出面進行處理還是你進行處理？不過最好還是你親手處理，因為項目經理對需求的分析能力還是沒有產品在行，不過你就算了，新人還是多聽聽項目經理的建議吧。至于與其他產品經理確定需求是否緊急與重要的時候，可以參考之前提到過的需求四大類：核心功能（bug）、輔助功能（bug）、意淫需求、模棱兩可的需求。在這個階段，基本上只會處理核心功能（bug）。如果你跟其他產品經理無法達成一致意見的時候，可以來找我，老大我幫你出頭。

小明：謝謝王總。

項目開發進度滯后，進度評估出現問題

每個人做事情的時候，都不是完美的，所以程序猿評估的項目周期，也不會說一定是準確無誤的，總是會因為一個功能沒有考慮清楚，而耽誤了項目開發進度。這時候項目經理通常會要求程序猿們加班趕進度。但是作為產品經理，在這個階段也需要出一份力。而我們會做的就是“砍需求”。

當產品延期的時候不超過1周，通常通過加班，能將項目進度追回來。這種情況下，最好是讓程序員們加加班，將進度問題解決掉。但是有時進度延期太長，通過加班無法挽救項目的時間，這就需要我們忍痛砍掉一部分無關主流程的需求。保證項目按期上面，并且上線后，再盡快著手安排這些需求的開發。如果你這樣做了，我相信程序員們會愛上你的。

還有一種嚴重的情況，就是通過砍需求也解決不了問題，遇到這種情況你就要盡快告訴我。我好去跟公司層面反應這個問題，看是否能將再進行一定的延期。至于你，就等著扣工資吧。

小明：這么嚴重？

老王：你以為鬧著玩呢？

后端數據接口經常變動，影響前端開發

這個問題非常常見，通常在站立會與周例會的時候，都會提到這種問題。作為喜歡追求事物本質的產品經理，我們一定要發現這些問題的根本原因，這邊我也總結了幾個點，你好好聽下：

（1）后端程序猿與前端程序猿對某一需求的理解不一致，導致需要頻繁修改后端數據接口。

這種不一致，通常是這兩種情況：

• 后端程序猿理解的需求有偏差，被前端發現，要求改接口；
• 前端對需求理解有偏差，并說服了將正確的接口改為錯誤的。

（2）后端程序猿本身能力就不足，寫的代碼經常出現漏洞。

（3）后端程序猿心態崩了，就是不想好好寫。

小明：那遇到這些問題，都該怎么做？

老王翻了個白眼：這么簡單的問題你自己去想想就好了，別總是讓我給你出方案。如果這些問題你處理不好。就白白浪費了我交你的東西了。

人員變動（調離項目、離職、請假），導致項目延期

這個問題就比較嚴重了，如果人員變動是長期的。你需要找項目經理溝通，找尋項目的代替人。并評估耽誤的項目時間，并提出延期。同時在新的程序猿進入項目之前，你還需要將項目的需求再重新對接一遍。

小明：······

程序猿積極性不足，情緒低落

程序猿們也是人，偶爾也會鬧鬧小情緒。所以在整個開發過程中，我們需要給他們最好的愛，最細致的關懷。

• 多請程序猿們吃吃飯，喝點小酒。程序猿普遍都是很單純的，試著跟他們交朋友，不是很難。
• 程序猿加班的時候，試著買點喝的給他們，紅?？墒撬麄兊淖類?。
• 當程序猿加班的時候，盡量不要按時下班，即使你沒事情做，在公司看看電影也是可以的。主要是讓他們感覺不是一個人在奮斗。你們是一個team。（當然，有家室需要照顧的除外）
• 給程序猿訂餐，一起吃工作餐，一起聊美女。你要學會向照顧你女朋友一樣照顧程序猿。

小明：我對我女朋友都沒有這么好，這也太難了吧。

老王：你有女朋友嗎？

小明：之前有啊。

老王：怪不得分手了

小明：······

老王：好了，今天就到這，老規矩，記得關門。

看著走遠的小明，老王發出了一聲嘆息：這！就是一個！毫無保留的我！

小結

開發跟進階段是產品事情最多的時候人，讓自己忙起來，讓程序猿靜下來。

相關閱讀

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（2）》

作者：李英杰，二一教育高級產品經理，主要負責題庫類產品的規劃與運營工作。

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

題圖來自 Pexels，基于 CC0 協議