Agile Meetup 首次在假日有聚會 (2014/8/31), 這次除了小弟上去代打外, 最重要的是要聽聽日本朋友的分享. 這次日本朋友(Someda Takashi, 染田貴志)分享的題目是”如何在反覆試用中開發更好的產品”. 主要的重點是如何早點確定產品是有用的. 以下是這次演講的摘要:
講者一開始介紹的他們公司的資訊, 以及當初為什麼會有這些改善. NuLab 是一家以敏捷方法來進行軟體開發的公司, 致力提供能改善及培養協同工作的軟體工具, 目前擁有『貝格樂專案管理工具』和『Cacoo線上繪圖工具』Typetalk 等產品. 這家公司非常相信, 在溝通順暢與愉快的工作環境中才能創造成功.
官網: https://cacoo.com/lang/zh_tw/
Facebook: https://www.facebook.com/CacooTW?fref=nf
他們在 2011 年時, 開發產品一上線, 客戶就遇到了很大的問題, 當天下午就希望他們下架, 可以回到上一個版本. 因此他們就思考要做些什麼, 才能改變這樣的窘境. 以下就是他們改善的方法:
1. Service 產品開發方法的趨勢
他們結合了 Lean Startup 和 Agile (Scrum) 的方法來進行產品開發. Lean Startup的觀念讓我們知道, 回饋的迴圈要運轉的越快越好. 因此要縮小所要建立的部分, 才可以讓你可以更快去驗證和學習.
2. 每個人都要思考產品的 UI
"The design of everyday things” 一書的作者 Don Norman 說過:
It it the duty of machines and those who design them to understand people. It is not our duty to understand the arbitrary, meaningless dictates of machines
因此, NUlab 認為每個人都要了解自己的產品好不好用, 所以要求每個工程師要自己去設計 UI 流程, 而不是讓 UI 設計師去設計畫面, 這樣你才會有感, 知道自己的產品要怎麼用.
另外他們也藉由先設計 UI, 以提早得到使用者的回饋, 因為畫畫面一定比開發系統所花費的代價少; 而且用文字或是口頭來確認需求, 一定也沒有比用 UI 解釋來得好.
雖然大家都可以對 UI 提出意見, 但是最後只會有一個人決定要怎麼改, 因為這樣才能維持 UI 的一致性和特色.
3. 建立試用的環境
為了讓產品能夠及早被使用, Nulab 利用下面四種方法, 讓 Beta build 可以及早被試用:
(1) virtual host
(2) dispatch by cookie
(3) Switching resource
(4) feature flag
從他們嘗試這麼多種方法看來, Nulab 是真的花了很多心思, 企圖在功能一完成時, 就在真實的環境中使用. 更令人激賞的一點, 他們是用自己寫出來的產品, 在開發下一版的產品, 你說這產品怎能不好用? 如果真的很差的話, 應該是自己先崩潰吧 XDD
4. 建制持續交付的機制
持續交付 (Continuous Delivery) 這個機制, 我想大家應該很熟吧. 比較特別的是以下三點
1. 每個人都可以自己執行持續交付
2. 即使持續交付後的版本有問題, 他們也能很快 switch 到上個正確的版本繼續工作.
3. 持續交付的結果是每個人都看得到的
本來 NuLab 要現場 demo 他們持續交付的機制, 可惜他們的 CD agent 起不來只好作罷. 現場 demo 有時候需要很大的勇氣, 風險真的很大, 何況機器還在日本 XDD
5. 促進團隊間的溝通
最這一點是令我最激賞的, 我覺得他們的文化很棒, 他想要打造一個大家願意正向回饋, 願意把所有事情攤開下陽光下分享的.
此外, 他們也認為有問題, 這不是你的錯. 而可能是系統組織的錯, 並且應該是要大家一起來承擔, 一起來處理.
最後 speaker 留下的一個梗, 更是讓我激盪不已, 我想大家可以一起好好思考這句話.
If you want to go fast,
go alone.
If you want to go far,
go together.
加油, Nulab, 相信你們公司會大紅大紫的. 給你們一萬個👍
留言列表
