人資充電

日期 |2019.12.04

文字 | 104人力銀行

觀看數 | 26211次觀看

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

人資充電

日期 |2019.12.04

文字 | 104人力銀行

觀看數 | 26211次觀看

文/ 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其實是為了想做出「對」的產品才會「快」,而上述可能會發生的慢與高,也應讓老闆先有個底,不然在一開始的「快」熱情過後,等老闆的耐心用盡之後,就是你由紅轉黑的時候了。

Close Menu