最近跟一位朋友吃飯，席間聊到他十年十多萬公里的老車，保養貴得不得了，於是他認真地研究了一下各廠新車的性能和配備，準備要換車，結果看來看去，只有日系Ｌ牌房車的性價比和妥善率最合他的胃口。
決策錯誤後悔厭惡
以他的習慣，新車大概也會再開個十年以上，所以當然希望配備和性能能夠稍微高檔一些，沒想到入門款車種缺東缺西的，於是只好把目標往上升了兩級。
後來繼續評估了一下自己的開車習慣，覺得油電車應該會比燃油車來得合適，於是又把目標從燃油車升級到油電車，而且也是直接跳到中階油電車款。
最後去試駕的時候，試到最高級的旗艦油電車，其豪華內裝和頂級音響再度把我朋友打敗，讓他把目標又升級到這款最高級的油電旗艦車款（口袋真的深啊．．．）。
本來都準備下訂了，結果車用晶片短缺，交車要等３到６個月，這根本就等同於「未享受先折舊」。朋友想想，反正也不急於一時換車，何必在這節骨眼上跟大家一起搶車？折讓也沒有比較優，因此便暫時打住觀望。
反正橫豎都得等，朋友乾脆就研究一下各廠的純電動車，沒想到這麼一認真研究下來，發現純電動車的十年十萬公里的能源和維護成本，竟然比燃油車要少了一半到 2/3，剩下的問題也是最重要的問題就是「里程焦慮」，目前電動車的續航里程普遍不足，充電速度也太慢，根本還沒辦法跟同級的燃油車相匹敵。
等著等著，沒想到朋友心儀的某Ａ牌歐洲大廠，發表了一款純電 SUV，續航里程大幅躍進到五百多公里，又過了約莫一個月，這廠再度發表一款純電 Sedan 概念車，且預計 2022 年就可在歐美先上市，續航里程再度推升到七百多公里，這下可讓朋友鐵了心，再也不回頭考慮油電車了（ㄜ，誰知道他會不會再變．．．）。
我稱上面的故事是「決策錯誤後悔厭惡」，我這朋友平常做事都蠻謹慎的，這次想換車也不例外，他害怕買錯廠牌、害怕買錯規格、害怕買貴了、害怕未享受先折舊的損失，說到底就是「害怕以後會後悔」，因此研究一做再做，決策一延再延。
買台兩三百萬的好車準備開個十年，這樣小心翼翼的決策方式並沒什麼不好，愈晚下決策，通常也的確愈能買到性價比更好的車款，不過，不管你是在哪個時候做決策，決策之後的未來，肯定還是會有更好的選擇出現，尤其是電動車這種技術和市場都還在突飛猛進階段的新產品。
然而專案管理中的決策，卻萬萬不可如此。
敏捷方法的本質，就是要你不怕做錯決策
最近課堂上，有位學員這麼提問，「老師，我們的產品負責人（Product Owner）相當優柔寡斷，決策常常很慢，請問老師，有甚麼辦法可以解決這樣的問題啊？」
「是哪些決策很慢呢？」
「比方說，常常到衝刺規劃會議（Sprint Planning Meeting）都還無法決定到底哪些用戶故事（User Story）要先排進衝刺來做，導致開會都要開很久，甚至有時候還要開上兩天會才能做出決定…」
我們知道，導入敏捷方法的目的之一，就是想快速得到市場（或客戶／試用戶）的回饋，以確認產品的設計是否恰當，若不恰當又可以如何來修正。
開發過程中，團隊總不免會踩到一些大大小小的雷，不過這根本就不是問題，因為敏捷方法就是要你快速去踩「小雷」，快速學到經驗教訓，然後快速修正，這樣的快實驗做多了，成功達標的速度也就變快了。
你有沒有發現，上面這段文字有很多「快速」的字眼？沒錯，敏捷方法就是要你在方方面面上都盡量「快速」，包括決策要快速、實作要快速，取得回饋也要夠快速。
產品負責人是要對產品負全責的人，會害怕做錯決策，害怕被客戶或老闆嫌棄做出來的成果，本就自然，換成是你我，可能也會是一樣。你一直叫他不用怕，快點做決策，這樣是不夠有說服力的。誰不知道，愈晚下決策，後果可能會愈慘，因為時間是不等人的呢？
敏捷框架可以怎麼變化，幫產品負責人加速決策
如果一個專案的衝刺週期（Sprint Duration）是四週，那麼衝刺會議上做出的決策，開發團隊（Development Team）得投資四週的時間才能取得回饋，產品負責人也許就是因為這樣的投資過鉅，所以才會心存恐懼，害怕出錯被客戶Ｋ、被老闆Ｋ，被開發團隊嫌。那我們可以怎麼辦呢？
假設開發團隊實作產出成果不是問題，那麼方法之一就可以考慮看看「縮短衝刺週期」。
如果四週的衝刺週期可以縮短為兩週，那麼衝刺會議上做出的決策，開發團隊便只需投資一半的時間就能夠取得回饋，產品負責人也許就不會這麼害怕做決策了。
產品負責人在對用戶故事優先序做決策時，考慮的不僅僅是用戶故事對用戶的價值而已，還得同時考慮重要利害關係人的特殊偏好、開發團隊的開發時間成本，以及設備和材料的成本等（如果專案含有硬體產出的話，例如，機構件的模具開模成本）。要在這麼多因子之間做出最佳平衡，其實並沒我們想像的那麼輕鬆簡單，我們也真的必須體諒一下這一點。
那麼開發團隊這邊，又能如何幫上產品負責人的忙呢？
團隊可以怎麼做，幫產品負責人加速決策
比方說，當一個用戶故事過於龐大，開發的時間成本太高時，開發團隊就可以和產品負責人一起合作，把該用戶故事拆解，開發團隊從技術層面考量，產品負責人從用戶使用面考量，兩者合作，就有機會把原本「大」用戶故事中的重要成分，先獨立萃取成為一個「小」用戶故事來排入衝刺內實作，而其他較次要的成分，就可以丟回產品待辦事項清單（Product Backlog）內去重新排序，如此一來，就無需再糾結於原本的「大」用戶故事之上了。
如果某個用戶故事的開發時間成本過高，例如，要建立完整的資料庫資料才能做測試，那麼開發團隊也可以思考一下，有沒有簡單一點的方法，少一點資料，就可以大致模擬出這個用戶故事的最後操作體驗。這種「減少驗證時間成本」的做法，也同樣可以協助產品負責人提高信心，加速決策。
有家知名咖啡連鎖店企業，早期就曾經僅用 Microsoft Power Point，就製作出一個成本極低，足以模擬出實際使用者體驗的網站，快速取得回饋。該公司並沒有在一開始就花大錢，雇用一大群工程師，花很多時間去把網站實作出來，可是後來卻依然能夠快速抓對方向，快速將網站打造完成，推出市場，一炮而紅。
敏捷團隊要能不分彼此，榮辱與共
因此，當我們看到產品負責人有「決策錯誤後悔厭惡」的狀況時，千萬別再只是想著去責備他／她，或只是消極地認為事不關己，您不妨試試上述方法，看看能否能幫你的產品負責人加速決策，又或許，你還可以想出更多更好的辦法也說不定呢。敏捷方法要成功，還得靠敏捷團隊（Scrum Team）不分彼此，齊心努力才行，您說是嗎？
圖片來源：pixabay.com