領導帶人 經營管理 行銷業務 工作術 自我管理 專題 近期活動
追蹤我們
工作術

專案大 delay,客戶要氣死了!3個方法提前布局,讓 PM 拿回時程主導權

產品人,現為商業思維學院《產品經理課程》主理人,商業思維學院社團

十餘年產品管理經驗,多次創建產品從零到一,與跨國產品行銷策略

Medium 創亞洲最多追蹤人數

看更多文章
重點摘要
  • 避免專案延遲的三個方法:簡單做、調資源、同步改。

「專案 delay」,應該是很多 PM 的惡夢,卻也是專案經理天天在面對的事情,跟大家分享一個我之前在商業思維學院分享過的案例。

那時,我負責一個公司重要客戶的專案,專案已經進行一段時間,公司當時採用瀑布式開發(所以你知道真的年代久遠)。

我們在專案預計要 release 前一個月時,我們發現有些功能趕不及, bug 也比預期的多,根本改不完,我當時請工程師重新估了一個時程,結果發現還要多六週左右才能完成,delay 一個半月!客戶根本不可能接受!

這時的你,該怎麼做呢?

首先我要先說,一開始就要減少 delay 的危機!雖然很幹話但是是事實,你需要預留緩衝,然後建立很多檢查點,一有風險的味道就毛豎起來趕緊處理,不要像我當時太菜,快 release 才發現,能夠做的事情就很少了。

大家有沒有聽過扁鵲三兄弟的故事?以下大致整理敘述跟大家分享:

扁鵲是神醫,他們家有三兄弟,都是醫生。有天魏文王就問扁鵲說,你們三兄弟中,誰醫術最高明呀?
扁鵲說:「大哥最高!二哥第二,我最差」
魏文王:「那為什麼大家都叫你神醫,沒有這樣稱呼他們?」
扁鵲:「我大哥治病,光看一眼,就知道這個人快生病了,趕快幫他調理一下,還沒生病就治好了,所以大家都以為他不會治病;
我二哥治病,只要稍微接觸一下病人,就能找出剛開始的病灶,趕緊趁擴大前消除,所以大家都以為他只會治小病;
我看病,都是在病很嚴重的時候,要大刀闊斧,插針放血敷藥手術,所以救回來大家都以為是我高明,名滿天下,事實上我根本遠不及我兩個哥哥呀!」

控 schedule 也是這種道理,厲害的 PM 根本不會讓 delay 這種事情,等到快爆炸才發現,有些產品開發方法也可以減少這種情況,例如 Agile 敏捷開發法。大家有興趣的話可以敲碗我整理出「delay 的原因和避免的方法」。

這篇文章講的是「在 Waterfall 的開發流程中,專案已經要爆炸了,專案經理的救火法」。

我那時採取了三個步驟:
1. 簡單做
2. 調資源
3. 同步改

一、簡單做

一個版本內可能有很多功能要做,這些功能可能又有考慮多周詳、要覆蓋到什麼程度的問題,厲害的產品經理一開始在設計功能的時候,先盡量讓功能沒有相依性,不會一個功能卡一個功能,等到要 delay 時,就可以把優先順序沒這麼高的功能先捨棄。這是最常見的做法。

還有一種簡單做的點,就是功能還是做,但是先不考慮某些少數人會碰到的狀況,少做一點 error handling,其實對工程師要考慮的事情就會少很多。不過要記得,這邊的減少要跟 QA 的測試項目同步一下,不然最後還是測出一堆 bug,還要釐清,也很花時間。測出這些 bug 如果早就知道不在重新定義的範疇內,不會改,還讓 QA 花時間規劃和測試,其實 QA 那邊很浪費時間,也很傷士氣。

另外一種簡單做的點,就是 bug 了,bug 當然要有優先順序,發生機率低,影響又小的,基本上就捨棄了,接著我會視情況捨棄「發生機率高但影響小的」以及「要特殊操作方法,才會發生的」,就是要一個個看還有討論的。

不過這邊要小心的是,現在的簡單做或是先不改的 bug,都有可能變成之後的技術債,就好像你在生活或工作上,一時沒時間沒精力把事情做好,先隨便做一下,結果後面補救要花很多時間,建議之後如果有下一個版本,還是多抓些時間把這些技術債清一清。

二、調資源

很多人聽到這個,就會說「猴!人月神話!加資源沒用還會花更多時間!」但我常說 PM 不要只記得教條,這其實要看狀況。

如果你的團隊不是只做你的案子的專案團隊(很常見),那「調資源」可以是「先把這些人在其他專案的資源 call 回來」,其他案子先不做,這也是一種調資源呀!這樣其實不會有加人帶來的問題。

或者是,工程師除了專案本身,其實有很多其他事要做,例如處理客服問題、一些定期會議、讀書會分享會,PM 幫忙能減的先減,讓大家把資源先花在衝刺上,也是一種調資源。

另外如果有一些比較獨立的功能或是 bug,還沒開始做的,就有機會找其他人支援,但的確要注意人月神話的問題,如果團隊還要花時間交接給這個人,還要跟他解釋一些邏輯和因果關係,那不如不加這個資源。

另外要注意的是,要先做完「簡單做」這個步驟,再去調資源,因為你把資源 call 回來,是會影響其他專案的,這需要老闆同意,否則你怎麼知道其他專案的商業價值或是優先順序,不是比你的專案高呢?

PM 要取得老闆協助,絕對不是一 delay 就去求老闆,這樣老闆第一個反應就是:「那我要你幹嘛」(很殘酷><)。所以要讓老闆知道,你已經能砍的都砍,能橋的都橋,資源都盤點好了,帶著解決方案直接請他協助,甚至你可能跟其他專案的PM都確認好影響了,再去找他,都能增加你爭取資源的成功機率。

三、同步改

我那時得知客戶拿到版本之後,自己還要測試一個月,才會正式上線,這個資訊就是 PM 的有力武器了!我們可以「偷」一點客人的時間!(所以我說,PM 不只要知道自己專案的 schedule,也要知道客戶的 schedule 呀!)

我當時就跟客戶說,既然他們也要一些時間做測試,測完如果有 bug 我們也要修改,目前我們有些 bug 還沒改完,能不能我先提供 beta 版本,我先列出 known issue,你們一邊測、一邊回報問題,我們這邊也同步修改呢?目標多兩週的時間把這些問題收斂,客戶還有兩週做最後驗收。

客戶因為我承諾他們回報的 bug 會改,他也想趕緊進他們 QA 的排程,這麼一來,我就偷到兩週的時間了。

另外一種做法是,假設專案有十個功能,先切幾個版本,前面幾個功能做完測完,就先給客人測試,在客人測試的時間,我們做下幾個功能,至少前面的功能是可以驗收出貨的,後面頂多剩下一兩個功能沒完成,或是 bug 沒改完,損害會比一整個版本都 delay 還要小。

至於要跟客戶協調哪一種做法,要看你對客戶的熟悉度,還有他們的驗收上線流程,所以我一直強調,資訊是PM最重要的武器,能對客戶瞭解越多,能掌握的調整空間就越大,誤踩客戶雷的機會也越大。

以上就是拯救專案 delay 的三種做法,你還有什麼方法?歡迎跟我分享!

mdi-tag-outline 時間管理 工作效率
延伸閱讀
加入經理人LINE好友