很多時(shí)候程序在排期的時(shí)候，都會給自己預(yù)留一定的時(shí)間以免工期過于緊張，但是實(shí)際上研發(fā)過程中延期總是不可避免。那么在項(xiàng)目延期的時(shí)候，產(chǎn)品應(yīng)該做什么？

梳理需要實(shí)現(xiàn)的每個(gè)功能點(diǎn)，是否存在誤解或者盲點(diǎn)

很多時(shí)候，對功能或業(yè)務(wù)流程的錯誤的理解是最終導(dǎo)致在開發(fā)上花費(fèi)過多時(shí)間的根本原因。Coding最大的敵人是：自己認(rèn)為自己懂了，然后死命按照自己的思路去實(shí)現(xiàn)，也許一切本不該如此。在這點(diǎn)上，盡情的和PM溝通，明確每一個(gè)需求。了解后，最好能用自己的理解在口述回去，以達(dá)到雙重確認(rèn)。

明確現(xiàn)有進(jìn)度，重新安排優(yōu)先級

PM需要考慮，客戶/用戶最想在這個(gè)版本看到什么，最想體驗(yàn)?zāi)男┕δ?。按照模塊重新排定優(yōu)先級，然后用剩下的時(shí)間全力去滿足客戶最關(guān)心的功能點(diǎn)需求。另外，個(gè)人建議可以通過在UI上展現(xiàn)一定的專業(yè)性和產(chǎn)品價(jià)值，用于彌補(bǔ)功能上的缺失。另外，做好空白或者屋內(nèi)的默認(rèn)頁面，也會另人感到專業(yè)許多。

了解各模塊進(jìn)度慢的原因

是否因?yàn)榉潜匾?0%功能而導(dǎo)致了90%功能的延誤；或者存在功能的誤解（同1），是否在實(shí)現(xiàn)中發(fā)現(xiàn)了更好的解決方案？是否是實(shí)力所致？是否有生活中消極的因素影響？找到真正的原因，才有助于問題的解決。

勇于砍砍砍

放棄一次性打造完美產(chǎn)品的念頭。要勇于扔下阻止前進(jìn)甚至關(guān)乎生存的一件件“貨物”。在做這個(gè)艱難的決定前，至少你已經(jīng)通過第2點(diǎn)里面提出的方式有了明確的優(yōu)先級排期，大膽的“砍掉”那些優(yōu)先級不高的功能吧。

保持文檔/代碼的一致性

世界上最遺憾的事情，就是在Coder按照功能大干數(shù)個(gè)小時(shí)候卻被告知，這個(gè)功能已經(jīng)改變/取消了。此時(shí)出現(xiàn)“人命”也不足為奇了。保持步調(diào)和戰(zhàn)略的統(tǒng)一，是走向勝利的基本要素。各種文件版本的變動一定要保持一致，并且最好有更新記錄。Coding中利用Git可以很容易做到這一點(diǎn)，但文檔的更新恐怕就要多費(fèi)一些功夫和口舌了。

和客戶真誠的溝通

不要瞞到最后一天，項(xiàng)目預(yù)警機(jī)制的存在不能是擺設(shè)。良好的商務(wù)合作前提是彼此尊重和理解，在當(dāng)今社會各種情況導(dǎo)致項(xiàng)目延期其實(shí)都是可被接受的。客戶可以接受延期，但不可接受遙遙無期的延期和臨近末尾的恍然大悟。及時(shí)的溝通可以始終讓客戶和自己站在一起。當(dāng)然，預(yù)警也要講究方式方法，只說壞消息也會讓客戶崩潰，一定要給出明確的時(shí)間節(jié)點(diǎn)和解決方案，讓客戶心中有數(shù)。要讓人給耐心，先給耐心一個(gè)落腳點(diǎn)。

本文由 @cloudxiao 原創(chuàng)投稿，并經(jīng)人人都是產(chǎn)品經(jīng)理編輯。未經(jīng)許可，禁止轉(zhuǎn)載。