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



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

    決策錯誤後悔厭惡

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

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

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

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

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

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

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

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

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

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

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

    「是哪些決策很慢呢?」

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

    我們知道,導入敏捷方法的目的之一,就是想快速得到市場(或客戶/試用戶)的回饋,以確認產品的設計是否恰當,若不恰當又可以如何來修正,在開發的過程當中,團隊不免一定會踩到大大小小的雷,例如,做出來的東西不符客戶的預期。

    不過這根本就不是問題,因為敏捷方法就是要你快速去踩雷,快速學到經驗教訓,然後快速修正,這樣的快實驗做多了,成功達標的速度也就變快了。

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

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

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

    如果一個專案的衝刺週期Sprint Duration是四週,那麼衝刺會議上做出的決策,開發團隊Development Team)便得投資四週的時間才能取得回饋,以確認當初的決策是否恰當,產品負責人也許就是因為這樣的投資過鉅才會心存恐懼,因為如果衝刺成果不如預期,他/她可能不只會被客戶和老闆嫌棄,也會被開發團隊嫌棄啊!那可以怎麼辦呢?

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

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

    產品負責人在做用戶故事優先序決策的時候,要考慮的不僅僅只是用戶故事對用戶的價值本身而已,還得同時考慮到重要利害關係人的特殊偏好、開發團隊的開發時間成本,以及設備和材料的成本(如果專案含有硬體產出的話,例如,機構件的模具開模成本)。

    要在這麼多因子之間做出最佳的平衡,其實並沒有我們想像的這麼輕鬆簡單,所以我們也真的必須體諒一下這一點。那麼開發團隊可以幫上產品負責人什麼忙嗎?當然是有的。

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

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

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

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

    例如,有人僅僅使用 Microsoft Power Point,就能製作出一個成本極低,卻足以模擬出實際使用經驗的網站,以快速取得回饋,沒有一開始就雇用一群工程師,真的花大把時間去實作出這個網站。

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

    因此,當我們看到產品負責人有「決策錯誤後悔厭惡」的狀況時,千萬不要只想著責備他/她,或消極地認為這是他/她的責任,不關自己的事。不妨試著想一下,上述提到的各種作法,是不是能幫得上產品負責人,加速其決策,也許你也還可以想得出更多更好的辦法。

    敏捷方法要成功,得靠敏捷團隊Scrum Team)不分彼此,齊心努力,您說是嗎?

    圖片來源:pixabay.com

    相關文章

  • 非軟體產業也能掌握的敏捷式團隊工作術公開班報名
  • 《EZ敏捷專案管理》兩日班課程簡章
  • 敏捷方法的成功密技》系列文章總覽