我理想的情況是，

事前planing好API(req、res)，完成每隻api估時，妥善把開發過程分配在每週

API 開發，採開完就交付，交棒FE串接，讓PM達成在預期時間，可以測試預期功能

事實情況是

BE開發前置時間耗時過久(建立entity、開module、建立DB)、需求變更與討論(異動DB schema level )、BE開發意外情況（技術研究(GoogleStorage)、需求意外地無法達成）、邏輯規劃不完全等因素，導致

1. api 雖然準時交付、但是品質不佳、規格不清，提升FE的溝通成本(確認用法、錯誤回報)
2. 自身程式碼雜亂不彰，易讀性差、嚴謹度不夠

針對以上情況，我採取措施

1. 以準時交付約定的API 為原則，完成度70%就可先上，至少讓FE可以先接、先測
2. 阻礙夥伴開發的問題，優先解決
3. api 錯誤回報、需求變更，訂定優先度，利用當周完成進度的 buffer time 進行處理
4. 需求變更部分，另外開卡紀錄變更，也另外估時，便於回顧時檢視是否可以優化部分

這次做得好的部分

1. api 都有如期交付
2. 任務優先度安排，以交付api 優先，錯誤處理、需求異動次之

這次做得差的部分

1. 重要文件缺乏完整性，讓文件使用者不易理解、取得必要資訊
2. 交付api 品質不佳、程式碼雜亂，需要再花時間修整

如果再來一次，我可以怎麼樣做得更好（交付品質好API \ 去除不必要溝通成本）?

1. 優先產出 API DOC
   1. swagger 用來提供完整的 api 串接（url \ req \ res \ error Exception \ 參數使用方式 ）
   2. google doc 用來給FE report api bug 、error 、欄位異動告知，於上版後淘汰
2. api 邏輯plaining 時候，應該再更細緻（api 資料流的flow \ 例外處理 \ 需要儲存的欄位 ）
3. plaining 時候，應該包含 module 架構、預計會產生的 dto 、enum 、config ，盤查哪些可能後續有效能問題
4. 盡可能盤點所需之範例資源（要開權限的名單、資料匯出匯入格式、檔案上傳範例檔案、需分析欄位）