曾經有學員向我提出這個問題，「老師，不管我們的專案時程評估得多有道理，老闆總是不分青紅皂白，就先砍掉 20% 的時間，我該怎麼辦啊？」
我聽過不少學員訴說這類的困擾，可是，我們回頭想一下，第一，為什麼會有不少的主管和客戶都這樣幾近無理取鬧地（至少從團隊的角度看是這樣的）壓縮專案的時程呢？第二，如果這就是短期無法改變的現實，那麼我們又能如何因應呢？尤其是，敏捷方法到底能不能幫上忙呢？
一、競爭對手產品時程的考量
許多人都有品牌情結，例如，非 iPhone 不買的果粉們。對於這種粉絲級顧客，我們通常很難用「比對手提早推出類似等級產品」來吸引他們叛逃。不過，相較於這些粉絲們，我們還有其他廣大的消費者們可以照顧，對這些人而言，同樣是 Android 手機，如果規格、性能、價位都大致相當，那麼，「比對手提早推出類似等級產品」就影響很大了。
道理很簡單，一般人大約兩、三年才會換一次手機，對於新手機用戶以及品牌情結不深的人來說，廠商每兩、三年才能有一次機會向他們銷售產品，誰先搶得先機成交，他的競爭對手就輸掉這兩、三年才一次的生意。
所以，我們在管理產品專案的時候，一定要對競爭對手的產品專案時程有所掌握，不管用什麼方法，都得比對手提早推出產品一到兩個月，這樣才能掌握較多的潛在客戶和成交的機會。
運作良好的敏捷式專案管理方法與專案團隊，可以在每個固定的衝刺（Sprint）週期之後，完成一個可以，或幾乎可以，推出上市的產品（MVP，Minimal Viable Product），這樣有什麼好處呢？
簡單地說，即便我們無法早早就掌握競爭對手的產品開發時程，上述這種能力也會讓組織在一旦獲悉對手的產品開發時程之後，就馬上敏捷應變，及時對進行中的專案快速打磨、拋光、收尾，及時跟上對手的腳步，推出產品，而這是傳統式專案管理所難以達成的境界。
二、重要機會點的考量
一些世界知名的重大秀展，如 CES、MWC、Computex、IFA 等，參觀人數動輒十幾二十萬人，是跟大批潛在客戶接觸的好時機。而這些秀展，通常都有固定的舉辦地點和時間，如果錯過了，往往就得再等上一年。問題是，我們為什麼要拚老命地，把還不完善的產品推出去參展呢？
除了潛在的商品成交機會之外，其實我們還有另外一個重要的目的，那就是，「試水溫！」
也許你的公司正在開發一個使用方式很前衛的新產品（例如，用手指取代觸控筆等），也許該產品所使用的技術還很新、還不夠成熟（例如，5Ｇ 車聯網應用等），因此我們就需要把原型機（Prototype）帶到秀展上，盡速讓那些對這個新產品或新應用有興趣的人們給給意見。
這些秀展上被動蒐集來的回饋，以及我們主動去探索對手動態所得來的資訊，都是我們接下來變更或修正產品功能的重要指引。尤其是，那些願意給我們產品回饋的人們，更會是將來我們產品改進之後的潛在試用戶。
所以，不論是給回饋的人或是回饋意見本身，或是對手動態，都是參展才能得到的寶貴資訊。而且這些看展的人們，來自世界各地的各行各業，觀點多元廣泛，你絕對無法以這種參展低成本，取得如此多樣且大量的寶貴資產。
敏捷式專案管理方法非常鼓勵這種「直接和終端用戶面對面溝通」的互動模式，良好的用戶故事（User Story）撰寫技巧，可以大幅提升在展場上與用戶溝通的效率與效果，讓新需求的蒐集和產品的使用回饋都能更加地精準無誤，使產品最終提供的功能更加貼近用戶的真實需求。
三、公司營收的考量
從我過去管理的眾多專案，以及向眾多企業授課和輔導的經驗當中歸納，幾乎所有專案的時程規劃都與公司的月度、季度、年度營收結算時間有些相關性，也往往跟一些重要的節日都有關，例如，寒暑假前夕、農曆春節前夕，以及聖誕節前夕得結案、量產、上市開賣等。
為了能夠趕上這些採購旺季，並讓這些營收金額做進某月度、季度，或年度的帳，產品專案的時程規劃就不得不從這些重要的時間點往前回推來開案，如果這已明顯不可行，那也就只好壓縮專案的時程，以提早結案來因應。
敏捷式專案管理方法以用戶故事地圖（User Story Map）來對用戶的需求做優先順序的排行與動態調整，同時，我們當然也可以把公司對專案的需求也一併考量進來，這樣專案團隊於每個衝刺所執行的工作，就會是針對當下最重要的那些需求，無論是對公司而言，或是對用戶來說。
如此一來，就算專案團隊真的有意外，來不及做完全部的專案需求，我們也能夠確定，專案團隊已經把所有的精力，都貢獻在當下相對重要的需求之上了，也因此能視專案已為公司創造最大化營收了。
四、團隊信譽的考量
不過，天下沒有白吃的午餐，所有的東西都是換來的，尤其是「時間」。事實上，我們根本無法「生」得出時間，時間永遠都是上帝給的。
上段故事有個前提，那就是公司高層或客戶必須能接受敏捷式專案管理方法的精神和邏輯，願意「犧牲相對不重要的需求」來換取「能提早上市，同時兼顧好品質的時程壓縮」。不幸的是，多數專案面臨的狀況常常是「一個功能都不可少」且「品質也要顧到好」。
像這樣把專案團隊逼上絕路，專案團隊就會自己找出路，而這出路，對組織和客戶，甚至是用戶而言，都不會比較好。
坦白講，在這樣的情況之下，專案團隊除了加班之外還是只能加班，加班加到了極限，團隊也只好「偷偷犧牲掉」品質，並且做到「沒人能及早發現品質被犧牲」。然而，這樣就會導致極為不良的後果，你我對此都不陌生，那就是大量的瑕疵（Bugs or Issues），加上，解完一個瑕疵就倒送你兩個瑕疵的窘境。
舉個例子來說，軟體工程師就常常會因此被迫倉促寫完程式碼，草草測試，然後趕緊「現在」宣稱「完工」，這樣就不會因為抵累（delay）而被主管或客戶Ｋ，反正之後會有品保人員測試，把瑕疵記錄到跟催系統上，日後工程師再一個個去解決它們就好，反正那是「以後」的事。
主管和客戶愈是不合理地去壓縮專案時程，團隊愈是會偷雞摸狗地犧牲品質，最後導致團隊需要更多、更難以預測的時間去解決更大量的瑕疵。根據經驗，這樣專案終究還是會延誤，品質依舊得不到保障，絕對是偷雞不著蝕把米。
換個角度看，團隊愈是常無法守住專案的時程和品質，主管和客戶就愈無法相信團隊的能力和信用，於是就愈想要壓縮專案的時程，以為這樣就可以保留更多的緩衝時間（buffer）以因應團隊可能的抵累，如此一來就造成了「完美惡性循環。」
敏捷式專案管理方法的設計強調「高層下放授權」、「團隊高度自我管理與承諾」、「個人發展多樣職能」、「隊友互相備援」、「鼓勵團隊成功遠過於個人成功」等，這些在在正是破除完美惡性循環的良方妙藥。
相對於被主管或客戶逼迫，更基於面子，團隊絕對更能堅守自己所承諾出來的工時和品質標準。此外，敏捷式專案管理方法的設計，更巧妙地融入了一些可以制約人性黑暗和怠惰面的機制，讓團隊的凝聚力可以自然而然地逐漸茁壯強大，產生出１＋１＞２的績效。
追本溯源才是硬道理
回到文章一開始學員的提問，坦白說，我又不是神，怎麼可能會知道那位主管為什麼要這樣做，我唯一能做的就是「猜！」有沒有可能，跟上述四大原因或多或少都有些關係呢？當然了，我們也無法排除，這也有可能是客戶或是更高層主管的直接指示。
不過，我還是認為，最好的方法還是直接去問個清楚，有什麼好怕的呢？問問你老闆，為什麼是砍 20%，而不是 10% 或 30%？是上述四種原因中的哪一種，還是哪幾種，才導致老闆要這樣對付你和你的專案團隊？
切記，先想好，萬一主管直接跟你說，「好，那就砍個 30% 時間好了。」 你該怎麼回應？
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
