專案時間軸
2025 年 03 月
當時專案初步啟動,當時與 R 哥團隊配合,透過 R 哥團隊的資深 APP 開發經驗,希望能快速建立原型,以下為過程:
啟動會議開始
討論該產品方向、合作模式
- R 哥團隊負責前台
- Dash 團隊負責後台
中間規劃時,有一度朝著
自建版本,後來經過 Stanley 提醒使用Agora來作為核心聊天架構。survey
Agora過程出現分工分歧。- R 哥團隊希望
全墊API(除了 message ),保持架構整潔、專業分工 - 我希望
部分墊API,針對特殊需求,以求 MVP 原型為優先,後續迭代。
- R 哥團隊希望
當時答應以 R 哥
全墊API為方向。後續 3 月中旬,有交付一版 Android 原型。
- 當時有內部討論
R哥團隊,可能無法撥大量能在 Valo 身上,可能對於開發、專案角度上,更不好控管
- 當時有內部討論
bohengsurvey Flutter 開發,接手 APP 開發方向,後續在 3 月底開工。
boheng:
規劃核心的角度:
- 需要快速建立
原型產品 - 方便雙方
開發
以 Agora 為基底,當時有兩個方案可以走:
- 任何 API 都需要墊 API,都後端包裝過一層,能滿足
特殊需求 - 只針對需要
特殊需求而開立 API,其他都給 APP 串接Agora SDK
方案 1 的角度:
- 優勢: 乾淨的系統架構,所有事情&業務都包裝後端,後端再去墊
Agora。 - 劣勢:前期
快速可能就無法滿足,需要等後端完全開發好才能進入下階段。
方案 2 的角度:
- 優勢: 前台與後台分工進行,前台針對
Agora SDK文檔實現功能,後端針對無法滿足的需求提出 API。 - 劣勢: 前端複雜度會提高很多,不是一個好架構。
- debug 劣勢?:面對
Agora SDK文檔與全墊 API Server,我的角度,當時反而比較能相信Agora SDK文檔
- debug 劣勢?:面對
產品開發提醒
做產品時,開發們要時刻記住現況交付的價值、問題對象、個人程度、團隊資源,當下你面臨的周遭資源,去決策當下要做的事情,那就是合適的!
boheng 的開發心路歷程
過往開發時,會在開發時程與程式品質間做權衡,前期面臨到此情況,通常兩難,而當時的時空上,需要做出初步的 prototype,勢必犧牲了許多品質,但經由後續的產品測試與專案管理者,確認取得確定感後,2025 年 7 月後的思考模式會多加一些維持穩定的改善方式、維持功能平衡、收納競品的 idea,keep going!