項目延期原因及應對之道

每個(gè)項目經(jīng)理都希望能有效地控制項目進(jìn)度。但這件看似簡(jiǎn)單的事情，實(shí)際操作起來(lái)卻常常不盡如人意。即使在成熟的大公司里，有著(zhù)完善的項目管理流程，配備著(zhù)一流的團隊，項目延期事件還是頻頻發(fā)生。這里分析主要的三個(gè)原因。
　　常見(jiàn)的原因之計劃不清
　　很多項目經(jīng)理，計劃做得很漂亮，卻總是計劃趕不上變化。原因在于，有些時(shí)候，按工作量預估的發(fā)布日期卻得不到領(lǐng)導的同意，領(lǐng)導有時(shí)會(huì )說(shuō)我們現在就是和時(shí)間賽跑，這個(gè)項目必須在某某時(shí)間發(fā)布。這將致使計劃推倒重來(lái)，一切都要趕進(jìn)度。而對于其他團隊成員來(lái)說(shuō)，這份計劃沒(méi)有同他們商量，無(wú)異于強壓任務(wù)。項目還沒(méi)開(kāi)始，抱怨聲就不絕于耳。因此，項目工具選得好、任務(wù)劃分細致清楚只是做好計劃的基礎，更重要的是項目計劃要得領(lǐng)導和團隊成員的認同，并愿意為之全力以赴。
　　總之，想做好項目計劃，要做好以下三點(diǎn)。
　　項目計劃前，先和產(chǎn)品經(jīng)理、上級領(lǐng)導溝通好，確定這個(gè)項目的輕重緩急。
　　團隊成員要達成一致意見(jiàn)，項目經(jīng)理不可獨斷專(zhuān)行。
　　項目計劃要細化到天、功能點(diǎn)要責任到人、確定里程碑點(diǎn)。
　　常見(jiàn)的原因之需求問(wèn)題
　　需求中的功能點(diǎn)要在PRD(產(chǎn)品需求文檔)中羅列清楚，業(yè)務(wù)流程要寫(xiě)得完整清晰，交互細節要體現在視覺(jué)稿中。要組織項目組所有成員參加PRD評審，評審時(shí)要針對具體的問(wèn)題，給出明確的處理意見(jiàn)。暫時(shí)不能確認的問(wèn)題，問(wèn)題跟進(jìn)人要在限定時(shí)間內給出反饋，項目經(jīng)理可以制定問(wèn)題跟進(jìn)表格。
　　項目進(jìn)行中的需求變更，盡量在前期提出。在項目管理的過(guò)程中，當前期的需求和計劃都確定后，項目經(jīng)理不能只顧著(zhù)跟進(jìn)開(kāi)發(fā)和測試的進(jìn)度，也要階段性地和需求方多溝通，讓他們及時(shí)反饋意見(jiàn)。不要等到臨發(fā)布時(shí)，產(chǎn)品經(jīng)理跑過(guò)來(lái)說(shuō)“我要的不是這樣的，這里要改一下”。永遠不要把問(wèn)題留到最后一分鐘，要超前一步，留有余地。下面是一個(gè)真實(shí)的案例。
　　案例情景：該項目的整個(gè)周期為2個(gè)月，有3輪功能測試。當第3輪功能測試結束時(shí)，也就是即將進(jìn)入預發(fā)布階段時(shí)，產(chǎn)品經(jīng)理才給出用戶(hù)反饋并要求按用戶(hù)的反饋修改。改動(dòng)的地方涉及到頁(yè)面的樣式、文案、SQL語(yǔ)句和校驗邏輯等，總共可能有20多個(gè)文件要被改動(dòng)。
　　項目經(jīng)理建議只改頁(yè)面的樣式和文案，其他部分先不要改，等下次升級維護時(shí)再改，否則可能會(huì )影響發(fā)布。而在多次交涉無(wú)果的情況下，開(kāi)發(fā)人員只能硬著(zhù)頭皮修改，測試人員只能再重新測一輪。雖然大家努力地按需求方的要求做了，但項目延期已不可避免了。
　　常見(jiàn)的原因之溝通不暢
　　為某項目臨時(shí)組建的團隊往往來(lái)自不同部門(mén)，團隊成員之間不熟悉，此時(shí)，要為團隊建立一個(gè)溝通通道，確保溝通順暢。常用方式為：
　　建立一個(gè)內部網(wǎng)絡(luò )空間，所有文檔資源統一存放，供團隊成員共享;
　　利用即時(shí)聊天工具，建立一個(gè)項目群，每天通報項目進(jìn)度;
　　建立項目郵件組，所有變更達成一致后，發(fā)送郵件確認;
　　每天要開(kāi)15分鐘晨會(huì )，每周一次周會(huì )，每周發(fā)送項目周報;
　　跨團隊項目，最好申請獨立的項目室，所有項目組成員坐在一起工作，降低溝通成本。