項(xiàng)目進(jìn)度把控肯定是每個(gè)PM的必修課，但這塊包括可能很多人都沒有足夠的重視和經(jīng)驗(yàn)。文章通過自身的梳理和目前所經(jīng)歷的情況，講述項(xiàng)目延期的原因及解決方法。希望能幫助到遇到同樣問題的你。

引——如何高效的交付項(xiàng)目

首先，談一談項(xiàng)目，大家對這個(gè)字眼應(yīng)該熟悉吧，不管是具體實(shí)操還是面試過程中，都會有項(xiàng)目這個(gè)詞匯出現(xiàn)，那什么是項(xiàng)目呢，其實(shí)很簡單，項(xiàng)目是為了創(chuàng)造獨(dú)特（或符合公司/市場需求）的產(chǎn)品、服務(wù)或成果，而進(jìn)行的臨時(shí)性工作。項(xiàng)目有清晰明確的開始和結(jié)束時(shí)間，在目標(biāo)時(shí)間內(nèi)，啟動——計(jì)劃&執(zhí)行&控制——收尾，就是一個(gè)項(xiàng)目的生命周期。

你是否有這樣的經(jīng)歷？

安身于一家中高型企業(yè)，畢竟不是大型或職能崗位建設(shè)很齊全的企業(yè)，職能并沒有那么細(xì)化，作為一個(gè)小小的PM?，擔(dān)著分配到自己的業(yè)務(wù)線，涉及具體項(xiàng)目領(lǐng)導(dǎo)找你對接詢問，但屢屢逾期呢，那種對上無奈，對下的無語且憤懣，中間對自己的小委屈，????~ 真是聞?wù)吆呛牵犝咝睦?，明明是開發(fā)過程中或測試過程中bug多或者各種非PM原因問題導(dǎo)致項(xiàng)目延期，但還是免不了領(lǐng)導(dǎo)一頓Bb……也難免，畢竟在這樣的環(huán)境下，PM是項(xiàng)目的發(fā)起同時(shí)也是領(lǐng)頭人，以結(jié)果為導(dǎo)向看待問題。

那……

如何高效的交付項(xiàng)目？

1. 明確協(xié)同職責(zé)
2. 統(tǒng)一迭代節(jié)奏
3. 過程有效透明
4. 站會三講：完結(jié)的內(nèi)容，存在的問題，怎么解決或需要哪些幫助
5. 過程高效決策

回歸文章主題，該如何有效防止項(xiàng)目延期？

首先需要明確可能造成項(xiàng)目延期的原因

1. UI圖未經(jīng)過評審或成品界面不達(dá)標(biāo)，造成返工導(dǎo)致延期

實(shí)際生產(chǎn)中存在這些問題，UI圖輸出后沒有經(jīng)過評審直接轉(zhuǎn)到技術(shù)進(jìn)行開發(fā)，過程中或成品后發(fā)覺此時(shí)再做調(diào)整修改，難免延誤時(shí)間導(dǎo)致延期。

這類操作一般出現(xiàn)于首次帶隊(duì)的產(chǎn)品小白，前期別埋坑，UI評審的意義不容小覷，助于團(tuán)隊(duì)成員加深需求理解，溝通交流，同時(shí)也能給設(shè)計(jì)提供更多不同思維的靈感源泉。

當(dāng)然，也可根據(jù)產(chǎn)品或公司領(lǐng)導(dǎo)對于項(xiàng)目流程的看法，不把UI出圖及評審調(diào)整的時(shí)間算在項(xiàng)目內(nèi)，單獨(dú)計(jì)算時(shí)間，正常流程是設(shè)計(jì)圖完成后是進(jìn)行UI評審，沒問題后轉(zhuǎn)接產(chǎn)品及開發(fā)測試團(tuán)隊(duì)，因UI圖的問題導(dǎo)致延期，解決方案如下：

（1）提高設(shè)計(jì)團(tuán)隊(duì)的專業(yè)度，UI圖產(chǎn)出后即時(shí)進(jìn)行評審

注：上圖的項(xiàng)目初期、中期、后期可譯為”第一感覺、相對來說、細(xì)節(jié)挑刺兒”

（2）明確設(shè)計(jì)圖可交付的時(shí)間

產(chǎn)品需要跟每個(gè)需要合作的部門或同事溝通好，如果項(xiàng)目包含UI設(shè)計(jì)出圖的流程，明確開始及最后的完成時(shí)間（即評審后調(diào)整完畢可交付的時(shí)間）

（3）UI評審時(shí)明確重點(diǎn)，不必太過糾結(jié)細(xì)節(jié)

標(biāo)題概述很明了，如果單單因?yàn)轫撁媪舭谆蛘甙粹o大小圓角與否之類相對無關(guān)緊要的問題爭辯不休遲遲敲定不下，此為因小失大，小問題后期優(yōu)化迭代，不占用團(tuán)隊(duì)時(shí)間；

項(xiàng)目開發(fā)過程中按時(shí)間節(jié)點(diǎn)查閱UI效果，如有問題及時(shí)跟進(jìn)調(diào)整，避免成品不達(dá)標(biāo)導(dǎo)致最后返工。

2. 實(shí)際開發(fā)過程中前松后緊，沒hold住導(dǎo)致延期

工作中這個(gè)點(diǎn)比較常復(fù)現(xiàn)，例如公司待久的一些技術(shù)員工難免輕視公司制度，尤其是在制度并不完善或者自認(rèn)為早已對公司業(yè)務(wù)輕車熟路的情況下，實(shí)際開發(fā)過程中如遇跨項(xiàng)目聯(lián)調(diào)受阻……臨近預(yù)計(jì)完結(jié)時(shí)間，加班加點(diǎn)熟悉其他項(xiàng)目組代碼尋求解決方案，或團(tuán)隊(duì)整體氛圍松散，導(dǎo)致項(xiàng)目延期。況且前期輕松后期加班換調(diào)休 or money的類似行為，久而久之這種行為形成習(xí)慣，這也是很多企業(yè)定期換血，老員工數(shù)量占比較大的原因之一吧。怎么解決呢：

（1）使用燃盡圖節(jié)點(diǎn)設(shè)置，關(guān)注成員每個(gè)人的進(jìn)度

燃盡圖的縱軸可以是整個(gè)項(xiàng)目的剩余的任務(wù)，也可以是個(gè)人剩余的全部任務(wù)，用來觀察項(xiàng)目過程中完成的實(shí)際工作量與剩余時(shí)間的關(guān)系，關(guān)注節(jié)點(diǎn)進(jìn)度，如有異常及時(shí)溝通解決；

（2）核心價(jià)值需求，影響主流程的需求，優(yōu)化需求

例如本期項(xiàng)目核心就是優(yōu)化下單流程，那么即買即付這個(gè)功能就是核心，登錄注冊即為主流程需求，如果添加oauth，則屬于優(yōu)化需求，評審項(xiàng)目時(shí)間，如果優(yōu)化需求占用時(shí)間較多，即可迭代下一版；

需求優(yōu)先級劃分，一經(jīng)確定，將貫穿項(xiàng)目需求的整個(gè)生命周期，所有的資源將根據(jù)優(yōu)先級被安排。分享幾個(gè)劃分需求優(yōu)先級的方法如下

1）從開發(fā)及效果角度分析劃分

2）從使用頻次和用戶量分析劃分

3）根據(jù)業(yè)務(wù)或市場情況劃分

4）根據(jù)KANO模型劃分

• 必備型：如電商類App，購物車、下單及訂單管理流程則是必備型需求，最高優(yōu)先；
• 希望型：如oauth，便捷登錄注冊的方式，符合大眾用戶簡易使用操作的心理，屬二級優(yōu)先；
• 興奮型：如百度地圖語音功能，能觸發(fā)用戶感嘆的點(diǎn)即為興奮型需求；當(dāng)然，創(chuàng)新的需求點(diǎn)需投入大量的構(gòu)思、試驗(yàn)、研發(fā)成本，不鳴則已一鳴驚人，屬三級需求（視具體情景而定）；
• 無差異型：不論提供與否，對用戶體驗(yàn)無影響。針對這類需求，要避免投入，轉(zhuǎn)戰(zhàn)其他更有價(jià)值的需求；

（3）晨會

也稱為早會、站會等，說法不一罷了，及時(shí)匯報(bào)項(xiàng)目進(jìn)度，如有問題(產(chǎn)品邏輯or技術(shù)開發(fā))及時(shí)拋出調(diào)整解決；

3. 需求下發(fā)后只關(guān)注自己的模塊，協(xié)接故障導(dǎo)致延期

如果僅僅關(guān)注自身的業(yè)務(wù)，那對自己來說不管是技術(shù)能力或項(xiàng)目全局的把控能力都不會有太大的提升，只有成長了才會有更大更好的平臺發(fā)光發(fā)熱。再者，畢竟是大家一個(gè)團(tuán)隊(duì)，在同一家公司共事，共同努力做好一件事不香嘛?~，期間的過程酸甜苦辣不都是一份經(jīng)歷一份成長嘛?~，同時(shí)作為帶隊(duì)者?

（1）需求拆解

PM前期開需求評審會議的時(shí)候，就做好需求的拆分，按具體模塊、功能劃分，每一部分事無巨細(xì)講述，邏輯清晰易懂、循序漸進(jìn)貫穿本期需求/項(xiàng)目，如有與別的項(xiàng)目耦合關(guān)系或邏輯判斷，著重講述，讓團(tuán)隊(duì)成員明白整體流程，以及最后需實(shí)現(xiàn)的成果，而后技術(shù)負(fù)責(zé)人按模塊/功能安排具體開發(fā)人員；

（2）各自評估，集中討論

開發(fā)人員拿到自己所需模塊后，進(jìn)行集中討論（類似頭腦風(fēng)暴），畢竟業(yè)務(wù)/功能相互之間難免存在耦合，規(guī)定時(shí)間內(nèi)理清業(yè)務(wù)，尋找與之前后是否存在相關(guān)聯(lián)性，避免后期埋雷，當(dāng)然，需要開發(fā)人員熟練業(yè)務(wù)、自身能力及表達(dá)順暢，相互之間較快得出估期結(jié)論；

（3）促進(jìn)組內(nèi)成員相互之間多交流溝通

大家一起討論需求難點(diǎn)時(shí)，適當(dāng)回應(yīng)、多聆聽、不打斷、不做任何個(gè)人感情色彩評價(jià)，全程采取開放性的提問，讓成員去思考，講出自己的想法。

遇到邏輯問題或理解不通暢時(shí)不要爭論，盡量把說話和表現(xiàn)的機(jī)會讓給對方，聆聽中抓取問題，設(shè)身處地站在開發(fā)或測試的角度去想他們提出來的問題，善于運(yùn)用肯定式問句，引導(dǎo)對方思考，讓對方不斷認(rèn)同，如“你把這個(gè)邏輯想的有些復(fù)雜了，其實(shí)很簡單，XXXX，你看這樣是不是好理解一些或者更順一些了呢？倒是你之前想的很不錯(cuò)，可以作為下期的優(yōu)化點(diǎn)迭代一版”，如有好的想法加以肯定，每個(gè)人都需要被肯定；

4. 估期時(shí)間偏差，導(dǎo)致延期

這是最重點(diǎn)的一個(gè)問題，百分之六十以上的項(xiàng)目延期就是因?yàn)轭A(yù)估時(shí)間出現(xiàn)問題，從而造成項(xiàng)目延期。需求評審?fù)活A(yù)估了理想狀態(tài)下的開發(fā)時(shí)間、聯(lián)調(diào)時(shí)間、測試時(shí)間，忽略了一些開發(fā)上可能存在的一些難點(diǎn)，攻克、聯(lián)調(diào)，再到測試或者測試出bug，修復(fù)半天找不到原因所在或修復(fù)所需的時(shí)間；如涉及到B端產(chǎn)品，B端一般涉及到的數(shù)據(jù)流轉(zhuǎn)非常復(fù)雜，有時(shí)候還需要與其他項(xiàng)目進(jìn)行對接或接口的聯(lián)調(diào)。針對這種問題比較好的解決方法：

（1）可采用Excel甘特圖表記錄時(shí)間節(jié)點(diǎn)以及具體每人按時(shí)間段需完成的需求點(diǎn)

清晰展現(xiàn)估期時(shí)間段，一但發(fā)現(xiàn)某個(gè)需求在既定時(shí)間內(nèi)延期，及時(shí)找出問題解決并判斷后面的需求是否可能遇到類似的問題；

（2）需熟悉業(yè)務(wù)流程及邏輯

項(xiàng)目完結(jié)后，每人提交一份輸出報(bào)告（類型可以是文檔、版本代碼、原型等），目的是讓團(tuán)隊(duì)成員明確每個(gè)部分/需求/項(xiàng)目之間的關(guān)聯(lián)，對現(xiàn)有邏輯有較清楚的認(rèn)識；

（3）不可忽略聯(lián)調(diào)及測試改bug時(shí)間

技術(shù)難點(diǎn)不可控，so 適當(dāng)預(yù)留時(shí)間，便于及時(shí)調(diào)整解決；

適當(dāng)”留一些余地”，或可替代性方案

適當(dāng)?shù)念A(yù)留一些時(shí)間，如上所說遇到一時(shí)難以攻克的問題，需要時(shí)間或及時(shí)尋求一些幫助去解決。

對PM來說也是如此，作為帶隊(duì)者，應(yīng)準(zhǔn)備可替代性方案，防止因技術(shù)難點(diǎn)或其他原因可能造成的逾期及風(fēng)險(xiǎn)預(yù)警；

5. 深入后發(fā)現(xiàn)對現(xiàn)有業(yè)務(wù)耦合或造成改動過大，開發(fā)時(shí)間不夠?qū)е卵悠?/h3>

這個(gè)問題跟上一個(gè)問題差不太多，前期盡量做好相應(yīng)的一些準(zhǔn)備，埋頭吭哧吭哧開發(fā)了半天，才發(fā)現(xiàn)和現(xiàn)有XX模塊對接不上！這個(gè)接口/方法導(dǎo)致現(xiàn)有H5頁面出問題等等情況！于是乎，又得重新搞，此時(shí)延期的警報(bào)即將吹響。。。

（1）項(xiàng)目前期可用魚骨圖分析一波，對項(xiàng)目正常完成可能產(chǎn)生威脅的因素進(jìn)行評估，以便逐個(gè)擊破解決問題

（2）PM對項(xiàng)目的熟悉程度，一定程度上決定項(xiàng)目是否能夠順利進(jìn)行，不了解的狀態(tài)盲目規(guī)劃制定需求，不是事倍功半就是夭折，延期還算輕的…

如果是新接手的項(xiàng)目，查閱PRD文檔及原型，或跟測試人員溝通，盡快熟悉項(xiàng)目內(nèi)容；

需求評審時(shí)應(yīng)及時(shí)提出相關(guān)的邏輯關(guān)聯(lián)輔助開發(fā)進(jìn)行判斷；

（3）做好需求拆分規(guī)劃，根據(jù)公司或市場情況，及時(shí)調(diào)整穩(wěn)步迭代

可根據(jù)上文需求優(yōu)先級劃分的方式進(jìn)行后續(xù)版本迭代規(guī)劃；

針對每期需求，擬可替代性方案，如一個(gè)連環(huán)相扣的判斷邏輯略復(fù)雜，實(shí)現(xiàn)較為繁瑣，占用時(shí)間較多，此時(shí)有一個(gè)簡化的方案可替代，既滿足使用，又不會導(dǎo)致延期，記錄當(dāng)前問題后期迭代調(diào)整也不失為一種解決方案；

6. 需求變更或新增，導(dǎo)致延期

需求臨時(shí)變更或者新增應(yīng)該是最常見的情況了吧?

案例情景：項(xiàng)目1期的整個(gè)周期為1個(gè)月，有3輪環(huán)境及功能測試。當(dāng)?shù)?輪測試結(jié)束時(shí)，即將進(jìn)入灰度發(fā)版階段，領(lǐng)導(dǎo)此時(shí)給出大客戶反饋并要求按客戶的反饋意見修改。技術(shù)了解后給出改動的地方涉及App端、H5及后端校驗(yàn)邏輯等方面，調(diào)整的話3個(gè)端均得做相應(yīng)改動，再投入時(shí)間及測試成本。。。

首先需PM進(jìn)行一波盡量帶動領(lǐng)導(dǎo)思維的冷靜分析，明確解決該問題所需要的成本及時(shí)間，是否屬于重要且緊急的bug，是否必須解決，如果僅僅是一個(gè)優(yōu)化并不影響大面積使用不會造成系統(tǒng)崩潰，可否延后到下版迭代，一波苦口婆心的勸說無果，那就轉(zhuǎn)身深呼吸，低喃一句佛曰：“阿米豆腐”，再來一波面向開發(fā)大佬們的演說~?

（1）冷靜判斷需求優(yōu)先級（上文第2點(diǎn)有具體闡述）

• 核心價(jià)值需求，影響主流程的需求，優(yōu)化需求
• 從開發(fā)及效果角度分析劃分
• 從使用頻次和用戶量分析劃分
• 根據(jù)業(yè)務(wù)或市場情況劃分
• 根據(jù)KANO模型劃分

（2）主動找開發(fā)溝通，產(chǎn)品崗在項(xiàng)目或團(tuán)隊(duì)中起的帶頭作用，做事態(tài)度積極，處好人際關(guān)系利于工作，當(dāng)然對自身做事也有益處

與開發(fā)溝通心態(tài)平和，站在對方的角度給予一定程度的理解，但如果是緊急且必須修復(fù)的問題需合并上線，商討解決方案，盡量將延期時(shí)間壓到最低；

7. 開發(fā)/測試對需求理解有偏差，返工導(dǎo)致延期

可能你的成員是有不同小組或項(xiàng)目組臨時(shí)抽調(diào)出來組建的團(tuán)隊(duì)，團(tuán)隊(duì)成員之間也不熟悉，同樣，新同事進(jìn)入團(tuán)隊(duì)也需要一個(gè)熟悉的過程，此時(shí)，溝通顯得尤為重要！

溝通在任何團(tuán)隊(duì)任何項(xiàng)目中都是重大問題，自認(rèn)為一個(gè)小的邏輯上的理解偏差可能就會造成實(shí)現(xiàn)的成果截然不同，開發(fā)記得是這樣的，測試記得好像是那樣的，造成項(xiàng)目在成品的時(shí)候出現(xiàn)偏差，情況好的是測試?yán)斫獠粶?zhǔn)確，不好的話那就得返工重新投入開發(fā)、測試時(shí)間成本。。同時(shí)也會造成團(tuán)隊(duì)成員之間相處的矛盾障礙，對之后的交流溝通埋雷。so~

（1）需求講述清晰明了，目的明確，評審時(shí)帶動團(tuán)隊(duì)成員，從核心出發(fā)，按模塊，邏輯，細(xì)節(jié)逐步講述，只有團(tuán)隊(duì)所有成員對需求認(rèn)知一致時(shí)，才能保證工作高效的完成，達(dá)到事半功倍的效果，同時(shí)也有助于團(tuán)隊(duì)協(xié)作氛圍提升

PRD文檔整理詳細(xì)，邏輯清晰易懂，流程/結(jié)構(gòu)圖準(zhǔn)確無誤，應(yīng)包含的內(nèi)容：項(xiàng)目名稱、版本歷史、目錄、文檔介紹、需求目的、需求模塊概述、需求明細(xì)、相關(guān)結(jié)構(gòu)圖、邏輯說明、全局功能說明、詳細(xì)功能說明、影響范圍說明、非功能性需求、注意事項(xiàng)、上線流程等；

（2）溝通 —— 溝通能增進(jìn)團(tuán)隊(duì)彼此的感情，消除誤解，增進(jìn)團(tuán)隊(duì)彼此之間的了解，同時(shí)也讓我們學(xué)會換位思考；人與人的交往，就是一個(gè)反復(fù)溝通的過程，溝通好了，就容易建立起良好的團(tuán)隊(duì)氛圍，積極上進(jìn)；溝通不好，鬧點(diǎn)笑話倒沒什么，但因此得罪人，導(dǎo)致工作處處受阻，就得不償失了。溝通的幾種方式如下

• 項(xiàng)目組成員位置就近，降低溝通成本；
• 項(xiàng)目管理工具：如Jira、企業(yè)微信TAPD等，便于及時(shí)查閱文檔、問題，溝通及處理；
• 郵件的方式通知到項(xiàng)目每個(gè)成員及領(lǐng)導(dǎo)，也是一個(gè)查證依據(jù)；
• 站會及周會，匯報(bào)成果及問題，問題及時(shí)拋出及時(shí)處理；
• 建群，便于每天通報(bào)進(jìn)度；

總結(jié)

個(gè)人感悟，只要做好項(xiàng)目管理，需求排期，對應(yīng)功能時(shí)間節(jié)點(diǎn)，功能開發(fā)狀態(tài)，進(jìn)度達(dá)到多少時(shí)要開始預(yù)警，警報(bào)解除 ，評估風(fēng)險(xiǎn)，延期影響評估，是否存在可替代性方案，一波操作下來，大程度不會出現(xiàn)延期的情況。

前輩大大們曾說過產(chǎn)品要有節(jié)奏感，這句話我十分認(rèn)同?，F(xiàn)在業(yè)內(nèi)比較推崇的方式是敏捷開發(fā)，小步快跑，快速迭代的模式，把項(xiàng)目分成足夠細(xì)的粒度并設(shè)置時(shí)間截點(diǎn)可以有效避免項(xiàng)目受到大的影響或經(jīng)常性延期。但在項(xiàng)目過程中隨著進(jìn)度的調(diào)整去做出一些需求上的調(diào)整也是很有必要的，人挪活樹挪死，仍需不斷努力。

本文由 @時(shí)間怎么量 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

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