一直以來我們都很強調自己是技術導向導向（Technology Centric）的團隊，直到有一天敏捷發現了我們，我們才開始往使用者導向（User Centric）慢慢移動。
我自我感覺良好的認為，自己思維還算是夠使用者導向，直到最近才發現果然是自我感覺良好。
話說最近新開發了一個產品，上線後發現網頁開很慢。一個沒啥圖片的登入頁面，User first visit大約要5-10秒才能Load完。
結果兇手是一個500k 大的 JavaScript library。
原來是夥伴們把產品內會經常用到的JavaScript function 集中在一起，又沒有壓縮，就跑出跑出了個巨獸。
剛剛好我也在命案現場，當然要5 Whys一下問問事情怎麼發生的。
『為什麼要把JS都合在一起？』
「因為可以減少Request到到Server的次數，讓Bandwidth的花費減少。」
『我們網站最多不過十幾個JS，就算合併成五個以下好了，減少的Request也不到十個，有效益嗎？』
「除此之外，還讓Code比較Organized，找起來容易，還有。。」
（以下省略30分鐘的討論，這種討論應該在每個團隊都天天發生，請自行腦補）
到最後因為我是個專業只出嘴巴不會寫Code的Product Owner，沒辦法說服團隊這個做法是有問題的，除了先壓縮把檔案縮小後，就不了了之了。
到後來有個夥伴又提出IISLog 上，使用者下載速度還是很慢的問題。突然間我就像被棍子打到，發現之前的討論我也太豬頭了吧，竟然圍繞在技術問題上打轉，而且還想用嘴炮跟技術人員戰技術問題。這番討論是我骨子裡根本就還是技術導向的怪味道（Smell）啊。
如果我的想法是使用者導向，我的問題應該是『怎麼樣才能讓使用者更快看到頁面？』，然後我們才可以避免陷於技術的討論中，因為技術的做法很見仁見智，很多時候是環境限制取捨下的Trade Off，不但討論不完，而且對錯也很難驗證。
但使用者的體驗，很多都是可以反應在客觀的數據上。這個改變，使用者有什麼影響？他們有沒有更快登錄、買更多東西、結賬速度更快、更常回來？
而這些數據都是很簡單就可以取得的，馬上就可以依靠結果來分析改善。（附帶一提，提出之前產品改動對使用者的影響和分析，也是Sprint Review上非常重要的活動）
在Scrum跟Agile中，所有活動的中心都是圍繞著產品，目標都是從如何知道客戶要什麼，如何讓客戶最快用到產品，如何提升我們交付產品的能力。所以客戶（使用者）要什麼，在一個真正敏捷的團隊中，應該是常常被提到的問題。
看來，『這對使用者有什麼價值？』這問題被提出來的次數，也可以當做產品成功的領先指標。
在你的團隊中，有夠常聽到『這對使用者有什麼價值？』這句話嗎？
延伸閱讀：UX使用者經驗書單與學習資源
圖片來源：http://www.buzzhand.com/post_758533.html
