[敏捷內湖] Agile UX interaction

在內湖敏捷的第四次活動，我公器私用的請到了 Jerromy 來分享 UX、UI 跟工程實踐上的態度。

Jerromy 很厲害，2005 年 (好像吧?) 自幹出我覺得很像是 PS 二代的等級的遊戲，然後又用數位與程式的技巧在各個藝術展裡面展出人機互動的作品，現在在 App 上，不管是 iOS、Android 都很有自己的想法與實作經驗。

時間市集：http://timemart.friday.tw/home/

為了 UI 上的細節與效果，Jerromy 會去調、客製化那些元件，而這包括很多不同的平台，據他所說，好像有 Flash、Unity、Android、iOS 與 Node.js，我覺得光是這種 put into practice 的能力就是值得大大讚賞的。

在這次的分享中，我首先對尊重專業特別有感覺，每次大家都在說，要以 User 為導向，可是我們常常做的事情是， UI 差不多就好，先把功能做出來，這不尊重設計師的專業！一樣的，PM 也會覺得，功能差不多就好，deadline 內就先上了，不然老闆、客戶會幹樵，這也不尊重 programmer、QA 的專業。

那怎麼辦呢？就是要有 Shared goal 啊，大家的目標要一樣，真的要把事情做好，而不是交差了事會動就好。

所以，團隊管理就不會是一層一層的經理、副理、工程師、資深工程師等等了，那是一個榮辱與共的團隊，不是上對下的、而是我們一起把事情做好的團隊感。

我常看到 Jerromy 的團隊的工作方法，是設計師、工程師、藝術家(沒錯，他們的團隊裡有藝術家!) 跟 PM 站在電腦前面一直反覆地反覆地反覆地反覆地調整，我覺得這是真正敏捷的實踐，沒有什麼框架沒有什麼原則了，就是大家一起做一個作品 (works) 出來，這是 collaborate，不是 cowork，也不只是 cooperate了。

這張投影片可以看到，他的方法大概是找到核心技術、做一點點實驗、給予挑戰，克服了以後，團隊的每一位都會有成就感。我覺得這完全就是 MVP 的概念，我也相信，如果不小心實驗失敗了，他們也會做出適當的調整， 不會整個部門都投下去半年八個月，然後做出一個沒有人要用的東西。

這不也是 fail early、fail fast 嗎！

傳統的做法是，UX、UI 與 GUI 設計師做了好多 prototype ，或是去做使用者調查等等，得到一個 idea 以後... 居然是去告訴 PM，由 PM 寫成 spec，然後反覆的用email、檔案分享交流，來回一個月以後，才丟給 programmer 施工，然後施工三個月以後，所有設計上的細節與巧思都不見了，因為 deadline 到了，就先把功能做出來就好... 而且使用者喜歡的東西或功能，在這四個月裡面，可能早就變了... 然後大家真的有把事情做好嗎？

所以我們這派 agilist，使用了各種敏捷的框架，試圖拉近使用者與需求端 (設計端) 的距離，持續的交付，持續的探索使用者要什麼。

但我覺得 Jerromy 的方法才是最對的，由專業的設計師的美感開始，加上他們自己又會寫 code，然後與 PM、programmer 們坐在一起，反覆的把事情做好，什麼 scrum、什麼 planning、什麼文件、什麼 scrummaster，還需要嗎？

所以，我的感想是：

• 跨界是很重要的

設計師要去學寫程式，不用那麼懂，但至少要懂一點點。programmer 要去懂 UX、UI，不用那麼懂，但至少要懂一點點。甚至是像 Jerromy 說的，物理、數學、AI 都要去懂一點點。Cross-functional team 嘛！

• 不要再吃老本了

你 programmer 資工所畢業又怎麼樣、你 designer 畢業專案拿到紅點設計獎又怎麼樣？站在使用者前面，我們都是平等的，使用者不會因為你的學歷、經歷與名片上的頭銜，就買你的產品。過了一個年紀後，公司也不會因為你的學歷、經歷與名片上的頭銜，就給你高薪。

• 真正的敏捷才是真正的敏捷

敏捷不是照著 scrum guide、不是去翻發明某個做法的大師的書，然後照著做，才叫做敏捷，那是 do agile。而是要 be agile，在各種限制下，在各式的變化下，大家能夠萬眾一心的去面對挑戰，並且克服它，我覺得才是最棒的團隊。

某些網友、鄉民說敏捷要實事求是，我在 Jerromy 的身上看到了不實事求是的敏捷是怎麼樣的了...

草木竹石均可為劍。
自此精修，漸進於無劍勝有劍之境。

from wiki: 獨孤求敗：https://zh.wikipedia.org/wiki/%E7%8D%A8%E5%AD%A4%E6%B1%82%E6%95%97

你懂了嗎？反正我是懂了！