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

?項目進(jìn)度把控肯定是每個PM的必修課，但大多數(shù)產(chǎn)品經(jīng)理都沒有足夠的重視和經(jīng)驗。文章通過將結(jié)合筆者經(jīng)驗，概述項目延期的原因及解決方法。

首先，談一談項目，大家對這個字眼應(yīng)該熟悉吧，不管是具體實(shí)操還是面試過程中，都會有項目這個詞匯出現(xiàn)。

那什么是項目呢？

其實(shí)很簡單，項目是為了創(chuàng)造獨(dú)特（或符合公司/市場需求）的產(chǎn)品、服務(wù)或成果，而進(jìn)行的臨時性工作。項目有清晰明確的開始和結(jié)束時間，在目標(biāo)時間內(nèi)，啟動→計劃→執(zhí)行→控制——收尾，就是一個項目的生命周期。

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

安身于一家中高型企業(yè)，畢竟不是大型或職能崗位建設(shè)很齊全的企業(yè)，職能并沒有那么細(xì)化，作為一個小小的PM，擔(dān)著分配到自己的業(yè)務(wù)線，涉及具體項目領(lǐng)導(dǎo)找你對接詢問。

但是碰上項目屢屢預(yù)期的話，那種對上無奈，對下的無語且憤懣，中間對自己的小委屈， 真是聞?wù)吆呛?，聽者心累——明明是開發(fā)過程中或測試過程中bug多或者各種非PM原因問題導(dǎo)致項目延期，但還是免不了領(lǐng)導(dǎo)一頓bb。

不過也難免，畢竟在這樣的環(huán)境下，PM是項目的發(fā)起同時也是領(lǐng)頭人，以結(jié)果為導(dǎo)向看待問題。

那…我們該如何高效地交付項目呢？

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

回歸文章主題，該如何有效防止項目延期，首先需要明確可能造成項目延期的原因：

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

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

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

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

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

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

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

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

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

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

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

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

工作中這個點(diǎn)比較常復(fù)現(xiàn)，例如公司待久的一些技術(shù)員工難免輕視公司制度，尤其是在制度并不完善或者自認(rèn)為早已對公司業(yè)務(wù)輕車熟路的情況下，實(shí)際開發(fā)過程中如遇跨項目聯(lián)調(diào)受阻…臨近預(yù)計完結(jié)時間，加班加點(diǎn)熟悉其他項目組代碼尋求解決方案，或團(tuán)隊整體氛圍松散，導(dǎo)致項目延期。

況且前期輕松后期加班換調(diào)休 or money的類似行為，久而久之這種行為形成習(xí)慣，這也是很多企業(yè)定期換血，老員工數(shù)量占比較大的原因之一吧。

那么怎么解決呢：

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

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

2. 需求優(yōu)先級劃分

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

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

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

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

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

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

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

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

3. 晨會

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

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

如果僅僅關(guān)注自身的業(yè)務(wù)，那對自己來說不管是技術(shù)能力或項目全局的把控能力都不會有太大的提升，只有成長了才會有更大更好的平臺發(fā)光發(fā)熱。

再者，畢竟是大家一個團(tuán)隊，在同一家公司共事，共同努力做好一件事不香嘛~，期間的過程酸甜苦辣不都是一份經(jīng)歷一份成長嘛~，同時作為帶隊者：

1. 需求拆解

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

2. 各自評估，集中討論

開發(fā)人員拿到自己所需模塊后，進(jìn)行集中討論（類似頭腦風(fēng)暴），畢竟業(yè)務(wù)/功能相互之間難免存在耦合，規(guī)定時間內(nèi)理清業(yè)務(wù)，尋找與之前后是否存在相關(guān)聯(lián)性，避免后期埋雷。

當(dāng)然，需要開發(fā)人員熟練業(yè)務(wù)、自身能力及表達(dá)順暢，相互之間較快得出估期結(jié)論。

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

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

遇到邏輯問題或理解不通暢時不要爭論，盡量把說話和表現(xiàn)的機(jī)會讓給對方，聆聽中抓取問題，設(shè)身處地站在開發(fā)或測試的角度去想他們提出來的問題，善于運(yùn)用肯定式問句，引導(dǎo)對方思考，讓對方不斷認(rèn)同。

如“你把這個邏輯想的有些復(fù)雜了，其實(shí)很簡單，XXXX，你看這樣是不是好理解一些或者更順一些了呢？倒是你之前想的很不錯，可以作為下期的優(yōu)化點(diǎn)迭代一版”，如有好的想法加以肯定，每個人都需要被肯定。

04 估期時間偏差，導(dǎo)致延期

這是最重點(diǎn)的一個問題，百分之六十以上的項目延期就是因為預(yù)估時間出現(xiàn)問題，從而造成項目延期。

需求評審?fù)活A(yù)估了理想狀態(tài)下的開發(fā)時間、聯(lián)調(diào)時間、測試時間，忽略了一些開發(fā)上可能存在的一些難點(diǎn)，攻克、聯(lián)調(diào)，再到測試或者測試出bug，修復(fù)半天找不到原因所在或修復(fù)所需的時間。

如涉及到B端產(chǎn)品，B端一般涉及到的數(shù)據(jù)流轉(zhuǎn)非常復(fù)雜，有時候還需要與其他項目進(jìn)行對接或接口的聯(lián)調(diào)。

針對這種問題比較好的解決方法：

1. 采用Excel甘特圖表

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

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

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

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

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

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

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

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

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

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

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

1. 用魚骨圖分析潛在問題

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

2. PM需要足夠熟悉項目

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

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

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

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

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

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

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

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

案例情景：

項目1期的整個周期為1個月，有3輪環(huán)境及功能測試。

當(dāng)?shù)?輪測試結(jié)束時，即將進(jìn)入灰度發(fā)版階段，領(lǐng)導(dǎo)此時給出大客戶反饋并要求按客戶的反饋意見修改。

技術(shù)了解后給出改動的地方涉及App端、H5及后端校驗邏輯等方面，調(diào)整的話3個端均得做相應(yīng)改動，再投入時間及測試成本……

首先需PM進(jìn)行一波盡量帶動領(lǐng)導(dǎo)思維的冷靜分析，明確解決該問題所需要的成本及時間，是否屬于重要且緊急的bug，是否必須解決。

如果僅僅是一個優(yōu)化并不影響大面積使用不會造成系統(tǒng)崩潰，可否延后到下版迭代。

一波苦口婆心的勸說無果，那就轉(zhuǎn)身深呼吸，低喃一句佛曰：“阿米豆腐”，再來一波面向開發(fā)大佬們的演說~

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

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

2. 主要跟開發(fā)做好溝通

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

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

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

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

溝通在任何團(tuán)隊任何項目中都是重大問題，自認(rèn)為一個小的邏輯上的理解偏差可能就會造成實(shí)現(xiàn)的成果截然不同——開發(fā)記得是這樣的，測試記得好像是那樣的，造成項目在成品的時候出現(xiàn)偏差。

情況好的是測試?yán)斫獠粶?zhǔn)確，不好的話那就得返工重新投入開發(fā)、測試時間成本。

同時也會造成團(tuán)隊成員之間相處的矛盾障礙，對之后的交流溝通埋雷。so~

1. 仔細(xì)講明需求，保證團(tuán)隊對需求認(rèn)知一致

需求講述清晰明了，目的明確，評審時帶動團(tuán)隊成員，從核心出發(fā)，按模塊，邏輯，細(xì)節(jié)逐步講述。

只有團(tuán)隊所有成員對需求認(rèn)知一致時，才能保證工作高效的完成，達(dá)到事半功倍的效果，同時也有助于團(tuán)隊協(xié)作氛圍提升。

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

2. 溝通

溝通 —— 溝通能增進(jìn)團(tuán)隊彼此的感情，消除誤解，增進(jìn)團(tuán)隊彼此之間的了解，同時也讓我們學(xué)會換位思考。

人與人的交往，就是一個反復(fù)溝通的過程——

溝通好了，就容易建立起良好的團(tuán)隊氛圍，積極上進(jìn)；溝通不好，鬧點(diǎn)笑話倒沒什么，但因此得罪人，導(dǎo)致工作處處受阻，就得不償失了。

溝通的幾種方式如下：

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

總結(jié)

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

前輩大大們曾說過產(chǎn)品要有節(jié)奏感，這句話我十分認(rèn)同?，F(xiàn)在業(yè)內(nèi)比較推崇的方式是敏捷開發(fā)，小步快跑，快速迭代的模式，把項目分成足夠細(xì)的粒度并設(shè)置時間截點(diǎn)可以有效避免項目受到大的影響或經(jīng)常性延期。

但在項目過程中隨著進(jìn)度的調(diào)整去做出一些需求上的調(diào)整也是很有必要的，人挪活樹挪死，仍需不斷努力。?

?

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

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