【Agile UX】Agile其實並不快，但會變更好

文/ 104資訊科技互動設計師 李國銘

剛接觸Agile時，心裡一直存在著疑問：公司執行Agile或Scrum，專案就會變快嗎？成本真的就會降低嗎？

深入幾年後，我的答案是：先快而後慢，先低而後高。

為何先快而後慢？

傳統的專案管理是企畫將「全部需求」及「全部功能」一起規劃完成，再交給網頁設計師及程式設計師接續再各做一次「完整」作業。三、四段的完整作業下來，通常能夠上線已經是半年、一年，甚至更久以後。(分工越細的組織就越久)
注意哦，「完整」不一定是「完善」。即便現在覺得已經面面倶到的考量到各種需求，但半年後的使用者需求說改變就改變，當然就不一定「完善」了。

Agile或Scrum，則是先找出專案的「核心需求」(80%的人只會用到20%的功能)，先上線最重要的20%功能，這樣不用拖一大包，也可以比較快進巿場驗證，其他的則是邊調整使用者回饋的問題，邊上線其他的功能。所以「感覺」一開始會比較快，短期間就能看到東西。

不過隨著上線後的巿場驗證，原先做好的核心功能會一直做調整改善，以求滿足實際需求，但後面那80%的功能，也要陸續被規劃上線。所以常常一個Sprint要上線新的功能，還要一邊上線前幾個Sprint上線的使用回饋調整 (註：Scrum團隊用sprint來當一次上線週期，每週期可能是2~4週)。這樣的滾動循環下，用整體專案完成度來看，自然就變慢了，甚至可能很慢。
另外，有導入UX(使用者經驗設計)的團隊，為了確保產品往正確的方向前進，因此會做前後期的UR(使用者研究)及Usability test(使用性測試)等，那個所需花費的必要成本時間也不算短哦。

至於為何成本是先低而後高？

軟體及網路服務，除了硬體的佈建外，最大宗的還是「人」的成本，多以工時來計算。
傳統的專案管理，是計算「完整」的產品，所以每一階段 (企畫、網頁設計、系統分析、前端工程至後端工程) 都較能預估需時多久。假設耗時半年，再延誤3個月，那就用9個月內發生的工時來算，這樣整個串為一包當然看起來成本較高，但較不會差異太大。

而Agile初期因上線時間變快，工時成本自然感覺就低。但隨著功能越上越多，循環越來越多，整體的時程反而較長，成本自然也跟著高。
這種成本的落差來自於，傳統的專案管理在上線後，只要Bug除盡，即算結案，但Agile因為是不斷的在快速改善產品，所以上線後不只是除Bug，也一直在面對巿場調整功能，長度當然拉的比較長。另外，Agile講求溝通順利及團隊智慧，所以除了企畫外，原本屬於接受文件作業的網頁設計師及程式設計師們，都要往前推進至Workshop內團隊討論，會議及討論會佔去了很多的人力成本，專案長度也會因此拉長哦。

Agile的方法有快速反應巿場變化的特色，所以它用核心功能及Sprint來滿足「快」的需求；Agile的方法有貼近使用者需求的目的，所以它會花UX的時間來確保產品符合使用者需要的「準」。

「其實使用者自己也不清楚自己真正要的是什麼」，所以不如「狠」一點：快點上線，快點發現錯，快點改錯。總比把整個功能做完推出後，才發現巿場要的不是這個，反而要再經過一至二次長時間的改版專案，這樣天時地利人和早都跑光了，如何與對手競爭呢？以此觀點來看，Agile確實有比較快，但實際上不一定省成本。

快與慢，高與低其實存在著錯覺，一開始的「快」容易說服自己用Agile是對的，但接續的長期循環則很容易會讓主管及團隊由期待變為質疑。

如果您是公司的主事者，請想好您願意用長遠的眼光來看待Agile的好處；
如果您想說服老闆接受組織改用Agile的方法，那麼就應該要讓老闆知道Agile其實是為了想做出「對」的產品才會「快」，而上述可能會發生的慢與高，也應讓老闆先有個底，不然在一開始的「快」熱情過後，等老闆的耐心用盡之後，就是你由紅轉黑的時候了。