什麼樣的專案適合使用敏捷式專案管理


    前陣子有位學員來電,「老師,我是以前上過您敏捷式專案管理課程的學員,我在您的網站上有看到,您有在輔導企業導入敏捷式專案管理,我想邀請您到我們公司,輔導我們用 Scrum 敏捷方法來做專案...」

    對方向我介紹完他們公司後我才知道,原來他是這家新創軟體公司的共同創辦人。

    「請問一下,你們目前在專案管理上是有遇到什麼樣的痛點?為什麼會想用 Scrum 敏捷式方法來管理你們的專案呢?」我接著這樣提問。 

    「老師,不瞞您說,我們公司的專案,時間都很趕,不過這些也都還好,努力加加班大概都能撐過去,我覺得我們現在最大的問題是,我們不太清楚,下個階段到底該把人力投到哪個市場,該做哪種專案比較好。我知道敏捷方法很適合用來管理不確定性很高的專案,所以我想說,應該可以用敏捷方法來試試看,幫我們公司找到一些方向。」

    老實說,這位學員對敏捷方法的認知,其實只對了一半,這怎麼講呢?

    「敏捷方法適合不確定性很高的專案」這一句話基本上是對的,不過,這並不表示,你可以連「專案的目標」是什麼都不知道啊!

    專案目標

    舉一個出遊旅行的例子來說好了,如果你連為什麼想要去旅行(目標)、想去哪裡(範疇)、預算抓多少(成本)、什麼時候去(時間)、和誰一起去(利害關係人),這些你都不知道的話,那你這個旅行計畫到底是要怎麼開展呢? 

    任何一個專案,包括出遊旅行這個專案,都一定會先有個「初衷」,也就是你「為什麼」會想要做這個專案,對吧?到底是為了「解決某個特定的問題?」還是單純只是「它可以賺錢?」就算是為了公益,你也一定會先設定,這個專案是為了「環保救地球」,還是為了「濟貧扶弱?」 

    這個「初衷」其實就是專案的「目標」,也是專案結束之後,我們可以得到的具體成果和好處。就算專案一開始沒有辦法將之很具體明確地描述,至少也得要有個大致的方向才行。

    比方說,就算你要「亂槍打鳥」,其實你也已經先設定了目標是「打下幾隻鳥」,目的可能是自己食用或拿去銷售,儘管「亂槍」這個方法不是個有效率的好方法。 

    專案管理的本質

    「專案管理方法」,不論是傳統式(就是很多人常說的 PMP 或瀑布式)還是敏捷式,它們都只是一種「手段」,不是一種能無中生有的「魔法」。有專案目標, 專案管理方法才有著力點,有方向去「想辦法達成」專案的目標。而這兩種專案管理方法的主要差異,其實就是它們有各自不同的「辦法」來達成專案的目標,如此而已。

    所以不管是用哪一種方法,你終究都得面對以下的這些問題:專案的目標是什麼?什麼時候一定得完成(時間)?得在多少「預算」內完成(成本)?需要交付的成果有哪些(範疇)?這些成果該達到什麼品質標準才算數?需要哪些技能、人才和培訓才打造得出這些成果(人資)?過程中必須和哪些利害關係人做溝通?怎麼預防一些可能發生的風險等。任何專案管理方法基本上都無法逃脫這些「專案管理的本質」 。

    如果我們把全世界的專案分為兩類,我們可以這樣說,一類是「不確定性比較低的」,而另外一類則是「不確定性比較高的」。而所謂的「不確定性」則可以定義成,例如,發展快速的商業環境之下「市場需求的不確定性」和「技術的不確定性」,高通膨時代下「成本的不確定性」, 嚴重傳染病疫情封控時代下「物流的不確定性」和「人力的不確定性」等。

    低不確定性專案

    那麼,哪些專案是屬於「不確定性比較低的」呢?比方說,一般的集合式住宅建築專案就屬於這一類。怎麼說呢?

    首先,因為市場上很多人有買房的剛性需求,所以就會有很多的建築專案去滿足這些人,故這種市場的需求很明確,也就是沒有什麼「市場需求的不確定性」。

    其次,打造這類建築的技術工藝也已經相當成熟,所以,在這方面也沒有什麼「技術的不確定性」。

    第三,各類建築材料的成本,在高通膨時代下,的確會有一定的不確定性,不過,對於先建後售的建案來說,這種「成本的不確定性」其實也不會對建案的獲利目標造成太嚴重的影響,因為這種建案,總是可以在完工結算總成本之後,再決定房子的售價來決定想要的獲利。

    然而, 在新冠疫情爆發的時代,各類工班和機具操作員的「人力不確定性」確實對專案的時程造成了不小的影響。 不過總的來說,除了這種百年一見的特殊災難之外,這種集合式住宅專案,在絕大多數的人類歷史時間裡,都沒有什麼太大的不確定性,也正因為如此,專案的困難度也都不會太高。像這樣的專案,就非常適合用傳統式的方法來管理。

    高不確定性專案

    相反地,那些和新科技有強相關的專案,不確定性就明顯高得多了,困難度也因此比較高。比方說,太空船開發專案、衛星通訊開發專案、自動駕駛開發專案、半導體製程開發專案、生成式 AI 開發專案等。這些專案都有很大的「技術的不確定性」。

    完成這類專案所需要的技術,不是都還很新穎不成熟,不然就是都還掌握在少數人手裡,不夠普及。而這也意味著,專案團隊都必須花費較大的心力去持續摸索試誤,專案的失敗風險相對都比較高。像這一類的專案,就非常適合使用敏捷式方法來管理。

    我們再以「生成式 AI 開發專案」來舉例。現在我們看到的 ChatGPT 聊天機器人產品,基本上已經突破了「大型語言模型」的技術瓶頸,進入了實用、可用的階段,「技術的不確定性」對 Open AI 公司來說,已經從之前的「非常大」變成了現在的「非常小」。

    不過,接踵而來的問題卻是,這樣的技術,除了可以拿來跟你哈拉聊天之外,到底還可以用它來做什麼樣的其他應用,將之變現呢?這也就是前面所提過的「市場需求的不確定性」。

    所以我們看到,近來 Open AI 公司不斷快速推出新版本的 ChatGPT ,廣泛地讓市場參與測試,蒐集用戶們的真實使用情境和回饋,以做為日後的產品改善依據。當然,這些資料也必定會提供可行商業模式的重要線索。

    投資 Open AI 公司的科技巨象 Microsoft 現在也一樣開始狂奔,不僅光速推出結合 ChatGPT 之後的新版 Bing 搜尋引擎,而且結合 Office 等應用軟體的 Copilet 也馬上就被推出,同樣也是基於類似的目的。這些極為迅速敏捷的動作,都不是傳統式專案管理手法有辦法勝任得了的。

    結論

    從 Open AI 和 Microsoft 這兩個案例我們可以看到,如果你的產品專案遭遇到「技術的不確定性」,你可以使用敏捷式方法來管理你的專案,想辦法不斷快速實驗你的新技術,然後推出去讓更多的用戶參與你的實驗,取得更多的實驗數據,做為下次實驗的改進依據,這樣就能夠讓你的專案「比較快」突破技術上的瓶頸,不用急忙用不成熟的技術推出新產品去市場上當炮灰。

    如果你的團隊已經掌握了某種技術,可是卻遭遇「市場需求的不確定性」,不知道這種技術可以用來做什麼應用和變現,你同樣也可以使用敏捷式方法來管理你的專案,使用你所掌握的技術,快速打造出「你猜想用戶可能會喜歡的產品原型」,推出去讓更多的用戶實際試用,就像 ChatGPT 那樣,看看到底你的猜測準不準?不夠準的話,那又是差多少?看看蒐集來的使用數據,可以怎麼幫你改善產品,調整方向,讓用戶更喜歡你的產品,也讓他們心甘情願地幫你做口碑行銷,這樣就能讓你更快突破「市場需求的不確定性」瓶頸,不再是猜不出該做什麼產品,就猶豫再三而失去先機。

    至於敏捷式專案管理方法的實施有哪些細節,高階管理層主管們可以怎麼協助團隊,才能顯現出敏捷式專案管理方法真正巨大成效,有興趣的朋友們可以參考下方的相關文章連結,那裡有一系列探討這些主題的文章。 

    相關文章:


    後記:

    後來我和一位朋友聊起了這件事,沒想到竟然被酸「你笨耶!有錢賺就好啦,幹嘛不接這個案子?你是嫌錢賺太多了嗎?給我好了...」

    ㄘㄟˊ !錢我愛啊!我超愛的,好嗎?做生意要憑良心啦,不能讓客戶糊里糊塗花大錢卻沒有解決根本問題,正所謂「君子愛財,取之有道」,你說是吧!