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

項目延期在產(chǎn)品經(jīng)理的工作生涯中是再常見不過的問題，但延期意味著某項環(huán)節(jié)出現(xiàn)問題，對后續(xù)的運營等動作也會有影響。如何能盡量避免項目延期呢？本文作者對此進行了分析，希望對你有幫助。

一、項目為什么容易延期？

1. 軟件研發(fā)是一項創(chuàng)造性工作

項目延期是一種普遍現(xiàn)象，管理者最為頭疼的一個問題。但是外人并不理解。明明是你們自己做的計劃，怎么總會出現(xiàn)這么多問題。說到底，這是由于我們的工作特性決定的。我們做的是一個創(chuàng)造性的工作，他不像建房子，有特定的步驟。我們實現(xiàn)一個功能，怎么寫，有多少行代碼，我們在寫之前是不知道的。

基于我自己的經(jīng)驗，我覺得項目延期還有以下兩個方面的原因：

?2. 工作中的突發(fā)事件多

我們在評估工作量的時候，都是基于過往的經(jīng)驗。這種經(jīng)驗性評估在真實環(huán)境中并不可靠，你無法應(yīng)對突發(fā)問題，而我們真實開發(fā)的過程中突發(fā)問題太多了。

3. 協(xié)作之間的耦合性高

技術(shù)人員工作的耦合性太高。從最開始產(chǎn)品經(jīng)理提出需求、UI設(shè)計原型、UE設(shè)計體驗、程序員做系統(tǒng)設(shè)計，寫代碼、測試人員編寫測試用例。環(huán)環(huán)相扣，其中一個環(huán)節(jié)出了“意外”，時間就得往后延。

二、工作中常見的延期原因

我這里列了工作中常見的延期原因：

• 需求變更，一般指新增需求或者需求細節(jié)一直在變；
• 需求評估的工作量不足，低估了功能實現(xiàn)的難度；
• 需求理解不對，功能做錯了。等最后測試或?qū)拥臅r候才發(fā)現(xiàn)；
• 有臨時需求插入。比如線上突然出現(xiàn)了一個bug，需要修復；
• 新需求本身存在邏輯問題，做之前都沒發(fā)現(xiàn)，在做的過程中才發(fā)現(xiàn)。
• 自測不仔細，測試發(fā)現(xiàn)問題太多，bug越改越多；
• 臨時人員變動；
• 偏離計劃后沒有做好應(yīng)對措施；
• 技術(shù)難點調(diào)研出了問題，實現(xiàn)方案得改；
• ……

那是不是我們就沒辦法了呢？也并不是。方法總比問題多，只要所有出現(xiàn)的問題都有應(yīng)對方案，準時上線也是可能的。當然面對復雜問題，想一次性解決很難，但好在我們可以迭代。每一次項目結(jié)束都應(yīng)該對項目做一次復盤。

三、如何解決項目延期問題？

這是我應(yīng)對項目延期的解決方案：復盤 —— 找問題 —— 拆解問題 —— 制定解決方案 —— 迭代 —— 復盤。

1. 復盤，找問題

復盤：上一次我們延期的原因是什么？把問題原因找出來。比如上次是需求變動導致的。

2. 拆解問題，制定解決方案

接著就是拆解問題。為什么需要變動？因為這個功能更重要。這是答案是真的嗎？這個功能真的很重要嗎？好，是真的。那么評判標準是什么？如果沒有。那么我需要制定出來。有了標準，下次遇到新增需求，我們就能很快決定是否加入到這個版本里。好，我們還可以繼續(xù)拆，是新增需求導致的延期？對，因為新增需求而且并沒有修改上線時間。那我們下一次面對新增需求是不是可以對外爭取更長一點的開發(fā)時間？

這個方法的優(yōu)點是，每次進步都能感受的到。缺點是，時間周期太長。但好在，我們別人的經(jīng)驗是可以學習的。別人趟過的坑，我們沒有必要再趟一次。

四、解決項目延期的關(guān)鍵三要素

基于我多年的項目管理經(jīng)驗，我認為要解決項目延期問題，必須做好三件事。

1. 項目開始前：需求管理

項目開始前的需求管理有四個關(guān)鍵步驟。

1）達成需求優(yōu)先級排序的共識

首先，我們要達成給需求優(yōu)先級排序的一個共識。什么樣的需求是最重要的，一定要完成的？每個公司可能不一樣。我自己是基于商業(yè)價值和用戶價值兩個維度來排序的。

商業(yè)價值，就是那些直接給公司帶來利潤，能夠降低運營成本、完成公司長期戰(zhàn)略目標等功能。而用戶價值是，那些能夠提升用戶體驗、提高用戶使用效率，解決用戶痛點問題的功能。

基于這兩個維度，我們可以畫一個四象限圖，把我們所有的需求按照商業(yè)價值、用戶價值兩個維度給歸類到不同象限里。對于商業(yè)價值高、用戶價值高的產(chǎn)品。我們應(yīng)該馬上去做。至于優(yōu)先級排第二的是商業(yè)價值高、用戶價值低的需求；還是商業(yè)價值低、用戶價值高的需求，要根據(jù)公司實際情況來定。

為什么要給需求分優(yōu)先級？時間有限，要做的功能太多。如果根據(jù)商業(yè)價值和用戶價值拆解后，還有很多需求，我們還可以繼續(xù)用重要緊急兩個維度來拆。

2）弄清楚需求的目的

達成了共識后，第二步就是在需求評審時，要求產(chǎn)品先講解需求的目的。不只是說明我們要做什么，還要說明我們要達到什么目標。這樣做有兩個好處。

1. 讓所有人參與其中，發(fā)揮團隊所有人的價值，通過集體共創(chuàng)可以獲得更好的解決方案。
2. 在事后，我們可以很清晰的看到，我們做的功能是不是往目標更前進了一步。如果沒有。那么復盤的時候，能更有指向性的去找問題的原因。

3）弄清楚需求細節(jié)

第三步，就是開發(fā)者需要弄清楚需求細節(jié)。每一個開發(fā)人員都應(yīng)該養(yǎng)成這樣一個看透細節(jié)的能力。

代碼的世界里只有0和1，沒有隨便。產(chǎn)品在給我們講需求的時候，并不知道系統(tǒng)的具體實現(xiàn)。有些細節(jié)他也不知道。這會導致很多需求在做的過程中有很多細節(jié)需要反復確認，如果做的不好，很多細節(jié)問題都會在測試的時候體現(xiàn)出來。

舉個例子，當產(chǎn)品說我們這次做一個活動，用戶下單滿29包郵?？雌饋砗芎唵蔚囊粋€需求，但如果你系統(tǒng)足夠復雜，開發(fā)人員應(yīng)該要想到，跨店的情況怎么辦？含虛擬商品怎么辦？如果店家設(shè)置了其他活動，沖突了怎么辦？需求后期會不會變成49包郵？如果這些在評審的時候沒有想到，那么在做的過程中一定要和產(chǎn)品保持溝通。有些新人剛來的時候不好意思問，其實沒啥，每個人都是這么過來的。這種能力是需要時間積累的。

需求理清了也有兩個好處：

1. 評估的工作量會跟精準。
2. 更早的發(fā)現(xiàn)需求里潛藏的問題。

4）輸出完整的項目上線計劃表

第四步，就是上下同步需求，生成需求計劃表。首先我們拆解需求，大需求變成小需求。然后評估小需求的工作量。輸出自己的個人計劃表。然后部門內(nèi)部整合需求，輸出部門的計劃完成表。最后是與團隊其他成員生成整體的項目計劃表。一般會做成甘特圖。這樣在做的過程中更容易發(fā)現(xiàn)問題。

異常情況：

這四個關(guān)鍵步驟，說起來簡單，但要真正做好不容易。如果能做到，那需求管理基本不會存在大的問題了。當然也會有一些異常情況。比如需求確定后，能不能變動？一般需求確定下來后，最好不要做臨時變動。除非特殊情況。

那什么是特殊情況？這就是制定需求優(yōu)先級規(guī)則的好處了，如果確實有更緊急、成本低的高商業(yè)價值、高用戶價值的需求。我們可以變動。只要團隊內(nèi)成員都認可這個規(guī)則，做需求變動就會比較好實施。

那如果是領(lǐng)導不按規(guī)則變動需求怎么辦？

誰擔責誰決策。因為站的角度不一樣，我們認為的高價值任務(wù)不一定對。這是一條職場通用原則，在需求確定做不做之前，作為項目組成員，你可以表達自己的建議，但如果最終負責人拍板要做，那就堅決執(zhí)行。

2. 項目開始中：過程管理

過程管理的關(guān)鍵是要解決信息不同步的問題。我的解決方案是：

1）每天都開站立晨會

很多人說早上開晨會沒有用，是管理者沒有其他辦法，只能通過會議來推進工作的一種表現(xiàn)。我倒不覺得，晨會并不復雜，也不會花費很多時間，但正是因為有了這樣一個固定”溝通“事項，每個人心里都會想著這件事，自然會把當下的工作按計劃推進。這里我介紹一下我公司開站立晨會的具體步驟：

1. 首先團隊之間達成共識。明確晨會的目的是協(xié)同，而非匯報。每個人時間就2分鐘?？刂瓢l(fā)言時間。
2. 確定匯報的內(nèi)容。每個人講講當天的計劃和實際進度是否一致。是否遇到了什么問題，是否需要什么支持。
3. 固定發(fā)言順序，發(fā)言過程中，其他人不評論，不解答。具體的問題等到會后在找相關(guān)人員一起討論。
4. 晨會的主持人很關(guān)鍵，他需要控制流程和時間，對于偏離主題的發(fā)言要給予提醒。
5. 最后就是要做會議紀要，只記錄某人遇到的問題或請求以及整個項目的進度是否正常。

開會時間推薦在正式上班時間30分鐘后，比如9點上班。9點30開始。10點前結(jié)束。備注：我公司彈性上班可以9點半到公司。

晨會能很好的解決團隊內(nèi)部信息不對稱的問題，大家能更好地了解到彼此的項目進度并做好配合。而且人都要面子的，如果自己制定的計劃未完成，還要自己當眾說出來沒按計劃完成的原因，是很有壓力的，這種壓力會在潛意識里影響到自己每天任務(wù)的完成度以及專注度。

很多公司把晨會開成了匯報會，最后就變成了一個沒有太多信息量的務(wù)虛會議。并不是這個工具不好用，而是你沒有用對方法。記住上面我說的幾個原則，相信你能組織好一場適合團隊的晨會。

2）如果是跨部門協(xié)作，每日要進行“對表”

如果是跨部門協(xié)作。我們每天也要進行”對表“，也就是同步信息。

3）關(guān)鍵節(jié)點的跟進

千萬不要等到上線了在來看項目進展，這樣即使發(fā)現(xiàn)問題，你也沒有時間來解決。

4）制定異常問題的處理機制

所有的異常情況，都需要設(shè)計一個應(yīng)對的應(yīng)對方案，有了應(yīng)對方案，至少解決問題的流程有了，心理就不會慌。解決起來就容易很多。

5）建立自己的問題清單庫

很多大公司都有這樣一個產(chǎn)品問題清單庫?？头略谔幚碛脩魡栴}時候，通過關(guān)鍵字搜索就能找到通用的解決方案。這極大地提高了客服處理問題的效率。同樣的方式其實也可以用在開發(fā)上。也許很久之前某個同事遇到的問題，其他同事也能遇到。這種情況下，通過關(guān)鍵字搜索，原來要花半天才能解決的問題，可能一分鐘就給解決了。需要注意的是在做這個問題清單庫的時候，一定要先定義好格式。這樣才好管理。

那是不是做到上面這些就能保證項目能準時上線了？也不一定。因為這里面最關(guān)鍵的是執(zhí)行的人。人的管理是一門藝術(shù)。這里以后再詳細講。

3. 項目結(jié)束后：對項目做復盤

復盤會：全員參與。

做的好的，要想辦法將其標準化、可復制。

做的不好的，要想辦法制定應(yīng)對的方案。

五、防止項目延期的幾個方案

最后，說一下我在防止項目延期上的個人經(jīng)驗。

1. 大項目要分階段轉(zhuǎn)測試

不要把測試和設(shè)計工作都集中在一個時間段。版本迭代的時長也不要超過一個月。

2. 預留測試時間

開發(fā)人員每次做完一個任務(wù)后，都要預留測試時間。同時和開發(fā)人員要達成一個共識，如果開過程中出現(xiàn)延期，要自己通過加班時間趕上進度，不能影響其他同事的進度。

3. 制定常見異常情況的處理標準

也就是最開始講到的，如果真的有需求變更，那么就一定要做好變更需求的標準。需求可以變，變了之后如何處理。這個也需要明確。有些是可以直接放到版本里通過加班解決，有些可以舍棄掉一些需求。盡量不在要發(fā)布的時候做變更。

4. 做好PLAN B計劃

遇到一些突發(fā)時間的預案是什么。比如有人員臨時請求，怎么辦？有技術(shù)難點攻克不了怎么辦？作為管理者需要提前想好備選方案。

5. 制定兩個發(fā)布計劃

一個計劃是對內(nèi)的，根據(jù)大家工作計劃整合之后的發(fā)布時間，還有一個是對外上線的計劃。我們團隊要追求對內(nèi)時間上線。但如果出現(xiàn)問題，預留出的時間就是我們的緩沖帶。當然也可以對外給出一個模糊的上線時間，比如對內(nèi)9月10號上線，對外9月中旬上線。

以上，是我應(yīng)對項目延期的一些經(jīng)驗。希望給大家?guī)硪恍﹩l(fā)。