中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

引——如何高效的交付項目

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

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

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

那……

如何高效的交付項目？

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

回歸文章主題，該如何有效防止項目延期？

首先需要明確可能造成項目延期的原因

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

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

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

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

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

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

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

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

（3）UI評審時明確重點，不必太過糾結(jié)細節(jié)

標題概述很明了，如果單單因為頁面留白或者按鈕大小圓角與否之類相對無關(guān)緊要的問題爭辯不休遲遲敲定不下，此為因小失大，小問題后期優(yōu)化迭代，不占用團隊時間；

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）晨會

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

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

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

（1）需求拆解

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

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

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

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

大家一起討論需求難點時，適當回應、多聆聽、不打斷、不做任何個人感情色彩評價，全程采取開放性的提問，讓成員去思考，講出自己的想法。

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

4. 估期時間偏差，導致延期

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

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

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

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

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

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

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

適當”留一些余地”，或可替代性方案

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

對PM來說也是如此，作為帶隊者，應準備可替代性方案，防止因技術(shù)難點或其他原因可能造成的逾期及風險預警；

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

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

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

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

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

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

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

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

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

6. 需求變更或新增，導致延期

需求臨時變更或者新增應該是最常見的情況了吧?

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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