結合實踐,談談進度管理
在推動實際業務的發展進程中,產品經理有時會需要做好進度管理的工作,即在“速度”和“進展”等維度上進行把控,以推動業務的實際落地。那么,進度管理應該怎么做,才更加有效和高效?在本篇文章里,作者便結合實踐經驗,針對進度管理這件事進行了解讀,一起來看。
在明確項目范圍的階段,項目經理或產品經理承擔著“領頭羊”的角色,告訴大家應該做些什么事情,保證大方向不走偏;而在正式Kick Off后,團隊成員開始干活了,項目經理就搖身一變,成為確保團隊不走歪路,時刻提振團隊士氣的“牧羊犬”了。在這個階段,項目的進度管理尤其重要。下面我將結合切身實踐,與大家一起探討進度管理應該怎么做好。
一、什么是項目進度
“進度”,顧名思義即為工作進展的速度。本質上,項目的進度管理就是對時間進行管理。重點落在“速度”和“進展”上:
- 速度,即為時間節點。時間是不可再生的,也是非常容易衡量的一個指標。時間節點能很清晰的定義,是否延誤一目了然;
- 進展,即為工作成果。這是項目是否在往前推進的衡量指標,有可交付的工作成果,那就是有進展,項目就能正常推下去。
如果你是一位項目經理或產品經理,肯定思考過項目的整體工期需要多久,在哪個階段該完成哪部分的工作;如果你是一位研發或測試,也肯定被質問過估算的項目工期是否合理,是怎么估算出來的,有沒有壓縮的空間…這些,都是項目進度的體現。
1. 進度延誤的原因
造成進度延誤的原因有很多,我從自身的經驗出發,將其分為兩類。
主觀原因:
- 團隊銜接不緊密,前置工作沒有妥善的交付給下一環節;
- 沒有提前準備好軟硬件的開發環境,導致被迫等待;
- 產品策略沒有想清楚,導致后期出現重大bug;
- 產品設計出現bug,導致返工;
- 團隊人員休婚假/產假/陪產假/病假去了;
- ……
客觀原因:
- 因物流原因,設備來晚了/損壞了;
- 因疫情原因,需現場施工的人員被封控了;
- 因大雨/臺風/大雪導致測試場地無法被使用;
- 協調預約好的場地、人員被鴿了;
- 地震了
- ……
還有一種情況,叫”老板覺得你慢了”??赡芾习暹h見卓識、高屋建瓴的意識到未來可能存在的某種風險,讓你安排加快進度,還給了一個死節點。
看到這里是不是有些上火,別急,只要思想不滑坡,方法總比困難多。
2. 進度管理的意義何在
很多人都聽說過”帕金森病”,病人會在靜止的時候手抖,行動遲緩,難以保持姿勢平衡,多發于老年人。但是你知道另一種“帕金森綜合癥”嗎,這種“病”可是無論男女老幼,只要身在組織內就有可能發作。
帕金森定律,是指工作會自動地“膨脹”占滿所有可用的時間。如果安排給一個任務的時間有富余,人們就會放慢節奏并消耗掉所有的富余。聽起來有點拗口,但是拿你學生時期趕暑假作業來做個對比,你的感受就非常深刻了。
在放假伊始,你給自己制定了非常詳細的計劃,要求自己每天都做一部分作業,爭取提前一個月完成,并在剩下的一個月里提升自己,下個學期要驚艷所有人!
前兩三天還可以嚴格執行,越往后生活中的小誘惑就不斷干擾著你,今天要陪朋友打球,明天要去看望外公,后天要逛公園…時間越來越少,deadline越來越近,平均每天要完成的作業越來越多。直到還剩最后兩三天,只好把同學的作業借來抄抄敷衍了事。
工作中也常常如此,一個任務交付下來,無論是否簡單,往往也只會在deadline前完成,甚至產生延誤。而項目的工作是環環相扣緊密連接的,你的交付產生延誤往往就會對其他人甚至項目的整體進度產生影響。這就是項目進度管理的意義所在,保障進度,防止延誤。按照時間軸進行延展,一個詳細的進度計劃,能安排好團隊人員的具體工作,方便計算成本和跟蹤項目進度。
二、進度管理的方法路徑
項目進度管理的核心在于“拆解”,我們要盡可能細致的拆分出工作的活動清單、所需資源及活動歷時。圍繞這個核心理念,我們將項目進度管理拆分成七個步驟。
總的來說,第②到第⑥步屬于進度管理的核心動作。
第①步規劃進度管理,和規劃范圍管理一樣,屬于為項目甚至企業制定標準。這一過程的輸出,也就是“進度管理計劃”。進度管理計劃是項目工作開展的指導文件,也是企業經驗的一部分,但并不會對具體的項目工作有指導作用。規劃范圍管理的宗旨在于“滾動式規劃”,就是提醒項目管理人員在制定項目實際計劃時遵循以下原則:
- 只對近期需完成的工作進行詳細規劃;
- 對長期的工作暫時只在較高層次進行粗略規劃;
- 從時間長度看,項目的計劃必然是漸進明細,從粗到細的。
那么項目的實際計劃應該如何制定,工作中又該如何控制項目進度呢?讓我和你一起,細細琢磨這兩個問題。
三、定義活動及排列活動順序
1. 定義活動
在項目的范圍管理一文中,我們談到了要創建工作分解結構(WBS),把項目可交付成果和項目工作分解成較小的且更易管理的單元,這些單元又叫“工作包”。其實,定義活動就是對WBS的進一步細化。所謂的活動,就是為完成工作包所必須開展的工作?;顒邮琼椖抗ぷ鞑鸾獾淖钚☆w粒度。
舉個簡單的例子深化理解,一個智能音箱的研發項目可以拆解為ID設計、結構設計、硬件設計、嵌入式開發、語音識別算法開發等多個環節。硬件設計可以進一步拆解為電源管理模塊設計、無線通信模塊設計、MCU及外圍設計、喇叭及拾音器設計等多個版塊內容。一般而言,工作分解結構拆分到這個層級就可以了,即為工作包。
而針對無線通信模塊設計這一個工作包,可以進一步細化,包括元器件選型,原理圖設計、layout設計、單板測試、性能測試等。這些就是需要項目成員具體落地的具體行動,也叫活動。這些具體而微的活動,就是我們今天重點討論的對象。
經過工作分解和活動細化,我們可以得到一份清單,包含了項目所需的全部活動,且對活動內容有著詳細描述,這就是活動清單?;顒蛹毣倪^程是需要項目群體成員共同參與的,而非一言堂。整合形成活動清單的過程,也是項目成員漸進明細的了解應做哪些事情的過程。活動清單應該至少包含活動編號、名稱、用時、責任人、活動描述、成果描述這些內容。
2. 排列活動順序
活動清單乍看上去是零散而龐雜的,無法清晰看出哪些是影響項目整體進度的關鍵環節,需要對其進行梳理。梳理的第一步,就是將活動的先后順序排列出來。
先給大家出一個小學三年級數學題:媽媽讓小明招待客人,洗茶杯2分鐘,拿茶葉1分鐘,買水果10分鐘,水果擺盤要3分鐘,茶水泡開要8分鐘,問最快多長時間客人可以喝上熱茶吃上點心?
能同時做的事要盡量同時做,可以節省時間。我們可以教小明先去洗茶杯,再去拿茶葉然后給客人沏茶,在等待茶葉泡開的時候去買水果,回來后進行水果擺盤。這樣最快16分鐘就可以招待上客人了。
這個生活例子揭示了項目活動之間的四種依賴關系:
- 強制依賴關系:工作中固有的依賴,是強制性的規律。如茶杯沒洗好就不能泡茶,又如軟件需求分析必須在對應的軟件設計之前完成;
- 可自由處理的依賴關系:根據項目組的經驗或偏好定義的依賴關系。如水果擺盤和洗茶杯無所謂先后,又如嵌入式開發和電氣設計無所謂誰先誰后,可以同時開始;
- 外部依賴關系:通常是項目組與項目組外之間的活動關系。水果需要從水果店買,物料需要外部供應商供貨都是外部依賴關系;
- 內部依賴關系:是受項目組控制的,項目內部活動的緊前關系。茶杯沒洗好就不能泡茶同樣也是內部依賴關系;又如硬件環境沒準備好就無法進行嵌入式開發
知曉這四種依賴關系還不夠,還需要有具體的方法來對活動關系進行表達,可以借助“網絡圖”,使用圖形方式直觀地描述項目活動的依賴關系,判斷項目流程中的關鍵路徑在哪里,并確認完成項目所需的最短時間。
繪制網絡圖時,需要使用帶線箭頭將各個活動連接起來。以下是一個簡單的app項目進度網絡圖,不考慮返工的情況下,需要14個活動。
在繪制網絡圖時,需要注意以下原則:
- 必須正確表達項目中活動之間的邏輯關系;
- 不能出現循環回路,不能出現判斷邏輯。注意和流程圖之間的區分;
- 箭頭都是從左往右單向的,表示時間的流逝。不能出現雙向箭頭;
- 只能有一個起始點和一個終點。
四、估算活動資源及持續時間
項目上所說的資源,常常指代各項活動所需的材料、人員、設備。在活動定義清楚后,就要對所需的資源進行估算。資源的估算與成本的估算緊密相關。
在純軟件的開發項目上,資源往往就是電腦和人,還是以app的開發為例:
- 用戶需求調研、用戶需求分析、可行性分析、產品驗收:產品經理;
- 數據庫設計、軟件概要設計:軟件架構師;
- 源代碼編寫、程序單元測試:安卓開發工程師、蘋果開發工程師、前端工程師;
- UI設計、切圖:UI設計師;
- UI還原度測試、系統測試:測試工程師。
在明確所需資源后,就需要對活動的持續時間進行估算,這一步應由團隊中最熟悉具體活動的個人或小組來執行。活動持續時間的計量單位是“人天”,2個人一起干3天才能做完,那這項活動就需6人天。需要注意,具體的開發工作量及測試工作量的評估,需要在需求導入成功后才可進行。
常見的估算活動持續時間的方法有三種:
- 專家判斷:請本領域經驗豐富的人來判斷;
- 類比估算:借鑒相似活動或項目的歷史數據,來估算當前活動或項目的持續時間。注意類比引用的項目,其復雜度和規模需要和本項目接近;
- 參數估算:基于工作量和生產率的概念進行估算。如測試一個模塊需要用時2天,那測試7個模塊大約用時14天。
估算畢竟存在準確度的問題,有些時候還會采用加權的思想對估算結果進行修正。首先需要估算出該項活動的樂觀時間、最可能時間、悲觀時間,那期望的工期就是(樂觀+悲觀+4X最可能)/6。
需要注意,大家在估算活動持續時間時往往比較保守,會增加一定的安全冗余時間。這一點要有心理預期。
在各項活動的持續時間估算完成后,需更新在活動清單和網絡圖上。需將耗時最長的環節標注出來,這就是本項目的關鍵路徑。
五、制定進度計劃
很多人覺得制定進度計劃就是畫一個甘特圖,或者覺得計劃趕不上變化,干脆就不列計劃了,這些都是常見的誤解。其實制定進度計劃的核心思想在于“規避風險”。
我們在繪制網絡圖時,有一個隱含的假設條件,那就是資源可以無限調用,人員也都是萬能的。而實際情況往往是資源捉襟見肘,總有優先級更高的項目把你的人薅走;你的研發也都是新手,程序一跑就報錯還找不到原因…
我給你推薦兩個方法,留緩沖和做假設:
- 留緩沖:所有的活動都是越早開始約好,不給靈活機動的時間。同時將每個活動的安全冗余時間全部砍掉,集中到關鍵路徑的末段作為緩沖。簡單、粗暴、有效;
- 做假設:基于已有的進度計劃,預置各種可能的場景,來評估項目進度計劃在各種不利條件下的可行性,并準備應急預案。這種方法適用于風險可預見時,只能盡可能的減輕意外情況對項目的影響,用起來比較費腦子。
在調整好各項活動的持續時間后,需以甘特圖的形式將計劃整理公布出來。
六、在工作中控制項目進度
控制進度屬于項目長期活動的一部分,并不是某種刻板僵硬的動作,而是需要結合項目實際靈活采用不同手段,來對項目的實際進展情況進行控制,使項目能夠按時完成??刂七M度的依據,就是項目進度計劃。
1. 進度控制的步驟
項目管理工程師或項目經理在實際工作中,需要定期收集項目完成情況的數據,將實際完成情況與計劃進行比較,若發現與計劃存在偏差,需要采取一些糾偏措施,以讓項目來到正常軌道上。進度控制的主要步驟如下:
- 分析進度,找出哪些地方需要糾偏。無論是進度延后還是進度提前,其實都應考慮糾偏??偟膩碚f就是“調撥資源”,讓項目的發展符合預期。但是進度提前的情況很少見,若真的發生可以考慮將人力調用到其他關鍵活動上,以規避風險,減少人力浪費;
- 確定應采取哪些具體的糾偏措施。方法很多,待會兒挨個來看;
- 將糾偏措施列入計劃,并修改計劃。糾偏措施也是一種動作,會對項目進度產生影響,因此需要在決定采取某種糾偏措施后及時更新項目計劃;
- 重新估算項目進度,評估糾偏措施的效果如何。糾偏措施執行一段時間后,需要對效果進行評估、回顧,并決定是否采取進一步措施。
2. 壓縮工期的方法
想要在有限的時間內完成被耽誤的事,我教給你“八字真經”,又稱“趙氏趕工箴言”,傳男也傳女。那就是:“搖人”、“加班”、“優化”、“躺平”。
- 所謂“搖人”,其實就是調撥更多的資源,人力也是一種資源。可以將團隊成員替換為經驗更加豐富的人,俗稱“換老桿子”;也可以增加人手,安排趕工。會增加成本;
- “加班”很常見,但是不能為了壓榨員工盲目的安排加班。一般是在關鍵路徑上的關鍵節點產生延誤風險時,安排周末或節假日加班;會影響情緒;
- 所謂“優化”,是指對工作環節和工作效率的優化。可以將關鍵路徑上原來是先后順序的活動調整為至少部分并行。會增加風險;
- 所謂“躺平”,當然不是真的兩手一攤無所作為,而是適度的妥協與放棄。可以選擇降低要求,或者縮減活動范圍。可能會被客戶罵。
一句話總結,項目的進度控制,就是拆解活動、做好預期、及時調整。項目就像是一艘小船,想要安全及時的到達彼岸,需要項目經理時刻保駕護航。當你制定好“航線圖”,帶領大副二副水手長向著黃金海岸靠攏時,記著盯緊羅盤、把穩船舵,時刻準備著調整風帆的朝向。
#專欄作家#
Smile,微信公眾號:明日編年史,人人都是產品經理專欄作家。專注智能硬件產品,現負責年銷1w臺以上汽車輔助駕駛產品。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
和光環的PMP課程里說的一樣,不知道算不算抄襲。。。
本文參考了PMBOOK第6版的教材。PMP、軟考、NPDP等很多種標準考試,都有引用這本書,算是官方的項目管理教材啦