的越全面，在后面的開發(fā)中才會越順利。
在經(jīng)過緩沖期后，程序猿們基本已經(jīng)對項目的工作量了然于胸了，這時程序猿往往會提出一些建議，出現(xiàn)最多的情況有以下兩種：
程序猿希望對需求提出異議（比如頁面交互，以及部分流程）；
程序猿希望砍掉部分需求。
針對第一點，我們一定要耐心聽完程序猿修改需求的理由。
千萬不要覺得需求分析是自己的職能，他們提建議是在多管閑事；想把一件事做到面面俱到是很難的，有時候程序猿提的點子正好是你沒想到的地方。
當出現(xiàn)這種情況時，不要著急給答復；回去將程序猿給出的方案和之前自己的方案仔細對比一下，選出一個最優(yōu)的。
如果你覺得程序猿給出的建議更好，那么就采納程序猿的建議，同時更新文檔并告知其他團隊人員。
如果是第二點，那么就要分情況討論了：
如果是不那么重要的需求，可以放在下個版本，如果是自己本身也模棱兩可的需求，那么直接砍掉就好了；
但如果是核心需求，那么堅決不砍，絕不讓步，核心需求是下個版本最重要的部分，是萬萬砍不得的。
當把工作量弄清楚以后，下一步就是確認開發(fā)順序和開發(fā)時間。
2. 確認開發(fā)順序
這里主要需要確認的就是先開發(fā)哪些功能模塊，后開發(fā)哪些功能模塊，這里注意，有了開發(fā)順序才能進行項目排期。
在確認開發(fā)順序的時候，我們?nèi)匀灰晚椖拷?jīng)理進行充分溝通，明確本次開發(fā)中有溢出風險的模塊，也就是說出了問題會嚴重影響其他模塊乃至整個產(chǎn)品上線的地方。
舉個栗子：
假如我這次做的是一個智能穿戴設備的APP，那么最有溢出風險的模塊是哪個呢？
不是注冊登錄，也不是數(shù)據(jù)顯示，而是設備與手機進行藍牙連接的模塊：
注冊登錄我們可以用第三方登錄來解決，如果數(shù)據(jù)展示因為工期問題做不完，我們也可以砍掉部分展示數(shù)據(jù)以保證按時上線；但藍牙設備連接是不可能砍的，這是智能穿戴設備功能的基礎。
所以說，藍牙設備連接就是有溢出風險的模塊；在開發(fā)順序中一定要放在前面，這樣我們就可以先對藍牙連接模塊進行測試，這樣出現(xiàn)問題時可以提前解決，不會影響其他功能。
3. 確認開發(fā)時間
當確定好開發(fā)順序后，我們就可以根據(jù)開發(fā)順序來確認每個模塊的完成時間了。
用甘特圖是一個不錯的選擇——制作甘特圖的時候，我們需要定任務，確職責；在表中我們要寫明任務，負責人，起止時間，以避免后期的扯皮。
而在開發(fā)過程中，前端在進行框架選取及頁面開發(fā)的時候，是不需要后端提供數(shù)據(jù)的，在后端進行數(shù)據(jù)庫設計以及編寫接口的時候，也是不需要UI設計師切圖的——因此，前端開發(fā)和后端開發(fā)是可以并行的。
如下圖所示：后端的橫向柱狀圖空缺的部分，是留給他們進行接口調(diào)試和bug修改的。
上圖這張甘特圖只是舉例，在實際的工作中，可以按每個模塊來劃分，將核心的、高風險的模塊向程序猿重點說明，在開發(fā)的過程中也要更細致的跟進。
如果項目有明確的截止時間，那么我們就根據(jù)截止時間來倒推每個模塊的完成時間。
如果時間實在不夠，砍需求吧，程序猿們會感激你的。
三、項目跟進
經(jīng)過前期的工作，我們終于把事情推進到開發(fā)階段了，那么產(chǎn)品經(jīng)理在開發(fā)過程中會很輕松么？
當然不是，我們要對產(chǎn)品的結(jié)果負責，當然要對項目進行跟進。
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）程序員對需求理解有
