MediaTek Cloud Sandbox Design Share
物聯網裝置的雲端資料服務平台
嗨，大家今天過得好嗎？好久不見了MediaTek Cloud Sandbox（簡稱 MCS）是我進 MTK 第一個負責的專案。目前已累積了12000+ 位的開發者，並衍伸出許多 Side projects。每完成一個階段後總是想好好介紹它，但專案不斷的成長，總是找不到好的切入點。目前專案已達到成熟的階段，加上這份工作滿四年多了，決心要好好記錄一下這個過程。而這篇文章其實早在去年六月就已經寫完 80% 了，無奈後來人生開始一連串的忙碌，一直延宕。本來也想放棄不寫了，但每次收到 Medium 通知說有人開始追蹤的時候，內心還是無比激動，沒想到自己的經驗可以持續引起別人的共鳴，也或許能帶給別人一點幫助？誰知道呢？於是又整理了一下，分享給大家。
好久好久以前，在我加入團隊前，團隊裡並沒有設計師的角色。工程師們先買了一套 UI Kit 後將功能套上。隨著功能越來越多、需求越來越複雜，需要有設計師針對客製化功能設計 UI、掌握整體使用流程，並提供使用者良好的操作體驗，我才加入團隊 😉
MCS 對我來說是一個很重要的專案，除了它是我第一個設計的 Console 類型網站外，也包含了 Landing page、Desktop app、Mobile app 以及各類 Marketing 文宣的設計。經歷了 MCS 專案後，提升了我對網站各類元件的熟悉度、敏銳度，也讓我設計了第一套 Design system，衍生出屬於我們的 UI Kit: MTK UI，並應用在公司內外部各個 Project 中。
由於專案運行已久，很久以前的想法或是決定的過程現在已經無法考究，所以主要會以介紹 MCS ，以及如何開發各項功能的過程及方法，來記錄它。
What is MCS？
MediaTek Cloud Sandbox (MCS) 提供您打造準備商業化的穿戴式和物聯網裝置，所需要的數據和裝置管理服務。它支持您專心的開發產品原型，不必煩惱建立一套自己的雲端基礎設施。
您可以在我們提供的強大的網頁儀表板介面上，看到使用我們提供的 RESTful API 從裝置蒐集回來的圖形化的資料。之後，您可以通過從儀表板發出命令控制您的穿戴式和物聯網裝置。此外，我們提供附屬的手機應用程式讓您能查看蒐集到的數據，並從任何地方控制您的裝置。
讓開發者可以專注在開發上是 MCS 的核心價值
精簡的說，MCS 是開發者的雲平台，讓開發者可以將裝置的數據收集到平台上，提供視覺化的呈現，並且利用平台遠端操控自己的裝置以及管理裝置。
Why do we develop MCS?
MTK 本身是晶片設計公司，前幾年物聯網當道，站在巨人肩膀上的我們思索著除了晶片本身外，有沒有額外的附加價值可以嘗試。於是我們一邊觀察市面上已有的產品或類似服務，一邊接觸各類小型開發團隊，從中摸索出 MCS 的初步型態。接著透過 MVP（ Minimum Viable Product 最小可行產品）的發佈，累積使用者後，再從使用者身上得到更多使用需求，陸續發展出 MCS Lite 以及 MCS Enterprise。
Who is our target user?
最一開始設定的使用者是獨立開發者以及開發團隊 → MCS
針對小型私人場域所設計輕量的 → MCS Lite
目前已推出適合企業用的 → MCS Enterprise
When to use?
當，想專注於開發產品原型，不想煩惱如何建立自己的雲端基礎設施時
當，開發過程中，想要即時驗證並且快速測試時
當，開發完成，想要產品化並作管理時
Where to use?
可以在我們的雲上使用 MCS
在私人網域使用 MCS Lite
或是在自己的雲上使用 MCS Enterprise。
How do we develop MCS?
專案運行方法：Scrum，為期兩週一次的 Sprint
團隊成員：PO、BD、Scrum Master、Backend Developers、Front-end Developers、Designer、QA
Step 1: PO 與 BD 收集需求後，寫 User Story
工具：Confluence
需求由誰決定、如何決定，我們試過很多方法。例如在最一開始專案剛起步的階段，為了快速擁有 MVP，PO 或內部成員會直接提出自己的想法與團隊討論 。當擁有了 MVP 後，隨著團隊人數的增加與經驗的累積，我們大致發展出下方的做法：
PO 與 BD 拜訪用戶談進一步的需求、Designer 做使用者訪談與觀察發現需求、QA 測試後發現 bug 需要改進等等，將這些需求通通收集起來放進 Confluence 的 Backlog 裡，再由 PO 整理寫出完整的 User Story。
As a (role of user), I want (some feature) so that (some business value).
Step 2: Scrum master 與 PO 與 BD 排定開發時程，與團隊討論 User Story
工具：Confluence、Jira
Scrum master 最了解團隊目前的開發進度與狀況，所以擁有了 User Story 後到底哪個要先做？Scrum master 會與 PO 與 BD 進行討論，依據需求的緊急度做規劃，同時也提供 PO 與 BD 這項新功能團隊何時可以完成的資訊。
接著 PO 與 BD 會跟整個團隊進行 User Story 的說明與討論，Designer 與Developer 可以在這階段提出各自的疑問與建議。直到團隊成員都了解 User Story 實作的意義、大致實作的方向、已經預想到的問題互相確認後，才開始實作。這時候就會利用 Jira 這套工具，列出各自有多少 Task 需要完成，Scrum master 也會用這套工具來追蹤個別的進度。
我們曾經使用估點數 (Planning Poker) 的方法來排定每個 Sprint 每個人要完成多少 Task，但使用一段時間後，估出來的點數差距越來越小，代表的意義不大，到最後流於形式，就不再採用了。
不再採用後，就是採用自由心證法，自己寫上預計完成的時間。
Step 3: Designer 畫草圖或 Wireframe 確認使用流程與大致畫面配置
工具：紙筆或 Balsamiq 或任何工具
每個 Designer 習慣的工具不同，我個人還是最喜歡紙筆：）除了喜歡筆刷在紙張上的觸感外，這樣修改是最快速的。但如果是已經很確定的內容，例如既有功能的延伸，或是要在比較正式的場合上露出，也有可能直接用 Sketch 或是像 Balsamiq 這樣的軟體繪製。
圖畫完掃描後會歸檔到 Confluence 上讓團隊成員審閱，通常在畫圖的過程中可能會發現當初沒有設想到的問題，一並列出讓大家可以在同一個空間上討論並記錄最後討論的結論。
有經驗的設計師會在這階段體現他的價值，甚至在一開始聽到 Story 後，就可以預先設想到設計上會遇到哪些問題、有哪些事情必須先跟前後端討論好，大幅減少後續溝通以及修改的次數。如果 Step 2 和 3 做得很好，例如大家都很認真開會、通靈能力大增能預知到會發生什麼問題提出並解決，那這一階段會很有效率的結束，不然就會陷入無限修改的輪迴中。
Step 4: Designer 畫 Mockup，Developer 做基礎工程
工具：Sketch、React.js、Node.js、Go
如何避免無限修改的輪迴呢？坦白說沒有一定可以避免的辦法。專案的複雜度不一樣、合作的人不一樣、對專案的理解不一樣，多少會影響到。修改是無法避免的，所以前兩個步驟更為重要，它能有效降低修改的次數，盡量在 畫 Mockup 階段前，凝聚好大家的共識。
Designer 畫 Mockup 的同時，Developer 可以先架設環境或先開發一些基礎工程。畫 Mockup 我覺得是相對單純的階段，除了事前視覺提案外，確定風格後，這是我在執行上花最少時間的階段。
當然，有時也會遇到某些元件或圖片一直決定不了要如何呈現，也可以先將既有的 Mockup 提交給 Developer，讓對方先開工確定的部分，避免延誤到對方的開發時間，自己再慢慢刻畫。簡單來說，要記得這是團隊合作，不是自己個人作品秀，不是每一次都能將作品做到一百分才提出，有時必須做出取捨，對於團隊來說，開發時程是最重要的。
Step 5: Designer 提交 Mockup、Spec & Assets，Developer 進行開發
工具：Sketch Measure
Designer 的工作不是交付完設計檔案後就結束了。除了交付設計外，也要協助 Developer 解決開發上遇到的設計問題。例如一些平面圖無法呈現的互動效果，Designer 需要找些範例或是準備 prototype 來說明要達到怎樣的效果，而不是讓 Developer 自己通靈。
有時也會遇到提交的設計圖，Developer 在有限的時間無法完成的情況。這時我們會先討論其必要性及重要性。是不是真的必要？是不是有其他方式可以取代？開發後能否重複利用？如果沒有結論，再請 PO 來做出決定。
Step 6: Developer 開發完後推到 io 環境， QA 測試，Designer 協助檢查操作流程及介面完成度
開發完成後自己一定要使用看看，看看自已的設計是否合理、使用流程是否流暢，這也是對自己的設計負責任的態度。
噢對，Designer 的眼睛跟別人不一樣，這是真的，你看得到別人看不到得細節，相信自己。自己把關後的產出一定加一百分喔 💯
Step 7: 發佈新功能到 .com 正式環境
在正式發佈新功能的前後，我們會準備好相對應的文案做宣傳的準備。例如發佈電子報通知目前用戶、臉書粉絲團發佈消息，如果剛好有遇到參展需求，也會準備海報、宣傳單等等。
以上就是我們開發的大致流程。
後記
經歷這個專案後，除了提升自己的專業技能、對網站各類元件的熟悉度、敏銳度外，還有一點值得提出的是：學會問對問題
關於這一點，我想起了我之前看到的一篇文章，裡頭分享：
『從一位 UX 設計師的角度來看，對產品經理問對的問題，能幫助你的設計，確切滿足商業目標；對工程師問對的問題，能幫助你在已知的技術限制下，提出創新的方案；對使用者問對的問題，能幫助你深入了解使用者的渴望，提出不僅可用（Usable）且有用（Useful）的產品。』
我當時看到這篇文章時，點頭如搗蒜，非常建議大家看看。除了設計專業的培養，問問題也是很重要的技能：
如何清楚地表達自己的問題
如何在對的時機點問問題
如何找到對的人問對的問題
最後最後，因為這個專案我認識了很多好朋友、好同事。這些年有些人離開，也持續有人加入。謝謝參與過此專案的大家，我真的從大家身上學到非常多東西：）
僅以此文紀念那些年，我們曾經開發的 MCS（怎麼這麼悲傷的結束XD）
