PM基本功 — 專案要爆炸延遲了,怎麼救?- PM三點下午茶#28

拯救delay的三步驟:簡單做、調資源、同步改

這是Evonne跟你一起PM三點下午茶的第28天(大家中秋節快樂,明天終於不用日更!)

這一篇文章是針對新手產品經理的「PM基本功」系列的第三篇文章:

專案要爆炸(延遲)了,怎麼救?

這個問題屬於商業思維學院 產品經理系列課程的 #PM基本功 #產品經理工作術 #專案管理 問題

Image for post
Image for post

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

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

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

這時的你,該怎麼做呢?

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

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

扁鵲是神醫,他們家有三兄弟,都是醫生。有天魏文王就問扁鵲說,你們三兄弟中,誰醫術最高明呀?

扁鵲說:「大哥最高!二哥第二,我最差」

魏文王:「那為什麼大家都叫你神醫,沒有這樣稱呼他們?」

扁鵲:「我大哥治病,光看一眼,就知道這個人快生病了,趕快幫他調理一下,還沒生病就治好了,所以大家都以為他不會治病

我二哥治病,只要稍微接觸一下病人,就能找出剛開始的病灶,趕緊趁擴大前消除,所以大家都以為他只會治小病

我看病,都是在病很嚴重的時候,要大刀闊斧,插針放血敷藥手術,所以救回來大家都以為是我高明,名滿天下,事實上我根本遠不及我兩個哥哥呀!」

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

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

我那時採取了三個步驟

  1. 簡單做

一、簡單做

一個版本內可能有很多功能要做,這些功能可能又有考慮多周詳、要覆蓋到什麼程度的問題,厲害的產品經理一開始在設計功能的時候,先盡量讓功能沒有相依性,不會一個功能卡一個功能,等到要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的三種做法,你還有什麼方法?歡迎跟我分享!

Written by

財金人,科技人,行銷人,商業思維學院產品課程主理人;十餘年產品行銷與管理經驗,商業思維學院社團:https://lihi1.cc/jC9rk;Hahow課程:https://hahow.in/cr/iwanttobeapm ;Mail: evonnetsai417@gmail.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store