Scrum,敏捷,專案管理,PMP,領導統御,甘特圖,排程軟體

    敏捷產品負責人發生「決策錯誤後悔厭惡」,你該怎麼辦?



    最近跟一位朋友吃飯,席間聊到他十年十多萬公里的老車,保養貴得不得了,於是他認真地研究了一下各廠新車的性能和配備,準備要換車,結果看來看去,只有日系L牌房車的性價比和妥善率最合他的胃口。

    決策錯誤後悔厭惡

    以他的習慣,新車大概也會再開個十年以上,所以當然希望配備和性能能夠稍微高檔一些,沒想到入門款車種缺東缺西的,於是只好把目標往上升了兩級。

    後來繼續評估了一下自己的開車習慣,覺得油電車應該會比燃油車來得合適,於是又把目標從燃油車升級到油電車,而且也是直接跳到中階油電車款。

    最後去試駕的時候,試到最高級的旗艦油電車,其豪華內裝和頂級音響再度把我朋友打敗,讓他把目標又升級到這款最高級的油電旗艦車款(口袋真的深啊...)。

    本來都準備下訂了,結果車用晶片短缺,交車要等3到6個月,這根本就等同於「未享受先折舊」。朋友想想,反正也不急於一時換車,何必在這節骨眼上跟大家一起搶車?折讓也沒有比較優,因此便暫時打住觀望。

    反正橫豎都得等,朋友乾脆就研究一下各廠的純電動車,沒想到這麼一認真研究下來,發現純電動車的十年十萬公里的能源和維護成本,竟然比燃油車要少了一半到 2/3,剩下的問題也是最重要的問題就是「里程焦慮」,目前電動車的續航里程普遍不足,充電速度也太慢,根本還沒辦法跟同級的燃油車相匹敵。

    等著等著,沒想到朋友心儀的某A牌歐洲大廠,發表了一款純電 SUV,續航里程大幅躍進到五百多公里,又過了約莫一個月,這廠再度發表一款純電 Sedan 概念車,且預計 2022 年就可在歐美先上市,續航里程再度推升到七百多公里,這下可讓朋友鐵了心,再也不回頭考慮油電車了(ㄜ,誰知道他會不會再變...)。

    我稱上面的故事是「決策錯誤後悔厭惡」,我這朋友平常做事都蠻謹慎的,這次想換車也不例外,他害怕買錯廠牌、害怕買錯規格、害怕買貴了、害怕未享受先折舊的損失,說到底就是「害怕以後會後悔」,因此研究一做再做,決策一延再延。

    買台兩三百萬的好車準備開個十年,這樣小心翼翼的決策方式並沒什麼不好,愈晚下決策,通常也的確愈能買到性價比更好的車款,不過,不管你是在哪個時候做決策,決策之後的未來,肯定還是會有更好的選擇出現,尤其是電動車這種技術和市場都還在突飛猛進階段的新產品。

    然而專案管理中的決策,卻萬萬不可如此。

    敏捷方法的本質,就是要你不怕做錯決策

    最近課堂上,有位學員這麼提問,「老師,我們的產品負責人Product Owner)相當優柔寡斷,決策常常很慢,請問老師,有甚麼辦法可以解決這樣的問題啊?」

    「是哪些決策很慢呢?」

    「比方說,常常到衝刺規劃會議Sprint Planning Meeting)都還無法決定到底哪些用戶故事User Story)要先排進衝刺來做,導致開會都要開很久,甚至有時候還要開上兩天會才能做出決定

    我們知道,導入敏捷方法的目的之一,就是想快速得到市場(或客戶/試用戶)的回饋,以確認產品的設計是否恰當,若不恰當又可以如何來修正。

    開發過程中,團隊總不免會踩到一些大大小小的雷,不過這根本就不是問題,因為敏捷方法就是要你快速去踩「小雷快速學到經驗教訓,然後快速修正,這樣的快實驗做多了,成功達標的速度也就變快了。

    你有沒有發現,上面這段文字有很多「快速」的字眼?沒錯,敏捷方法就是要你在方方面面上都盡量「快速」,包括決策要快速、實作要快速,取得回饋也要夠快速。

    產品負責人是要對產品負全責的人,會害怕做錯決策,害怕被客戶或老闆嫌棄做出來的成果,本就自然,換成是你我,可能也會是一樣。你一直叫他不用怕,快點做決策,這樣是不夠有說服力的。誰不知道,愈晚下決策,後果可能會愈慘,因為時間是不等人的呢?

    敏捷框架可以怎麼變化,幫產品負責人加速決策

    如果一個專案的衝刺週期Sprint Duration是四週,那麼衝刺會議上做出的決策,開發團隊Development Team)得投資四週的時間才能取得回饋,產品負責人也許就是因為這樣的投資過鉅,所以才會心存恐懼,害怕出錯被客戶K、被老闆K,被開發團隊嫌。那我們可以怎麼辦呢?

    假設開發團隊實作產出成果不是問題,那麼方法之一就可以考慮看看「縮短衝刺週期」。

    如果四週的衝刺週期可以縮短為兩週,那麼衝刺會議上做出的決策,開發團隊便只需投資一半的時間就能夠取得回饋,產品負責人也許就不會這麼害怕做決策了。

    產品負責人在對用戶故事優先序做決策時,考慮的不僅僅是用戶故事對用戶的價值而已,還得同時考慮重要利害關係人的特殊偏好、開發團隊的開發時間成本,以及設備和材料的成本等(如果專案含有硬體產出的話,例如,機構件的模具開模成本)。要在這麼多因子之間做出最佳平衡,其實並沒我們想像的那麼輕鬆簡單,我們也真的必須體諒一下這一點。

    那麼開發團隊這邊,又能如何幫上產品負責人的忙呢?

    團隊可以怎麼做,幫產品負責人加速決策

    比方說,當一個用戶故事過於龐大,開發的時間成本太高時,開發團隊就可以和產品負責人一起合作,把該用戶故事拆解,開發團隊從技術層面考量,產品負責人從用戶使用面考量,兩者合作,就有機會把原本「大用戶故事中的重要成分,先獨立萃取成為一個「小用戶故事來排入衝刺內實作,而其他較次要的成分,就可以丟回產品待辦事項清單Product Backlog)內去重新排序,如此一來,就無需再糾結於原本的「大用戶故事之上了。

    此外,開發團隊還可以再考慮做一件事,那就是「模擬」。

    如果某個用戶故事的開發時間成本過高,例如,要建立完整的資料庫資料才能做測試,那麼開發團隊也可以思考一下,有沒有簡單一點的方法,少一點資料,就可以大致模擬出這個用戶故事的最後操作體驗。這種「減少驗證時間成本」的做法,也同樣可以協助產品負責人提高信心,加速決策。

    有家知名咖啡連鎖店企業,早期就曾經僅用 Microsoft Power Point,就製作出一個成本極低,足以模擬出實際使用者體驗的網站,快速取得回饋。該公司並沒有在一開始就花大錢,雇用一大群工程師,花很多時間去把網站實作出來,可是後來卻依然能夠快速抓對方向,快速將網站打造完成,推出市場,一炮而紅。

    敏捷團隊要能不分彼此,榮辱與共

    因此,當我們看到產品負責人有「決策錯誤後悔厭惡」的狀況時,千萬別再只是想著去責備他/她,或只是消極地認為事不關己,您不妨試試上述方法,看看能否能幫你的產品負責人加速決策,又或許,你還可以想出更多更好的辦法也說不定呢。敏捷方法要成功,還得靠敏捷團隊Scrum Team)不分彼此,齊心努力才行,您說是嗎?

    圖片來源:pixabay.com

    相關文章

  • 《EZ敏捷專案管理》兩日班課程簡章
  • 敏捷方法的成功密技》系列文章總覽