通常來說 前後端會一起先討論出 api 的內容 有了規格之後 前後端就可以分別各自開發 最後再串起來就好
或者是後端直接先設計好 api 把文件交給前端 接著前後端就可各自開發
比較需要前後端共同確認設計細節的 api 可以開個 hackmd 或者 google doc 同步編輯 都看過之後再各自開發
更多人協作的場景 可以考慮用 Swagger 之類的工具 先產生文件與 fake api 串接
如果有足夠經驗 使用 GraphQL 技術也會很好 文件、測試面板 都會同步自動生成
其實 你的狀況 聽起來是團隊彼此是否互相尊重的文化問題：後端成員普遍懶得理前端人員 懶得管你工作方不方便。因此 你需要讓技術主管知道這個情況 並且協助改善工作流程 不然的話 很沒效率
如果團隊真的有互相卸責的文化 那麼在你發現有 api 缺漏之類的狀況時 請用 email CC 多人的方式 或是在聊天群組 @多人的方式 留下紀錄 證明時程的延誤不是你的問題。並且 出包的當事人 之後也許會自動改善合作態度
大家都是專業人士 將心比心的話 其實通常不會讓人有難合作、溝通沒效率的感覺。不過 你也要盡量反應狀況 讓人知道你遇到問題或者有某些需求 否則 說不定大家都很滿意 只有你覺得有問題
如果已經回報狀況 但是技術主管拒絕協助改善 那麼這個團隊的工作效率低落 並且主管沒有能力改善 可以考慮離職
以上 參考看看
精選技術文章、免費程式設計資源、以及業界重要新聞！
通常來說 前後端會一起先討論出 api 的內容 有了規格之後 前後端就可以分別各自開發 最後再串起來就好
或者是後端直接先設計好 api 把文件交給前端 接著前後端就可各自開發
比較需要前後端共同確認設計細節的 api 可以開個 hackmd 或者 google doc 同步編輯 都看過之後再各自開發
更多人協作的場景 可以考慮用 Swagger 之類的工具 先產生文件與 fake api 串接
如果有足夠經驗 使用 GraphQL 技術也會很好 文件、測試面板 都會同步自動生成
其實 你的狀況 聽起來是團隊彼此是否互相尊重的文化問題：後端成員普遍懶得理前端人員 懶得管你工作方不方便。因此 你需要讓技術主管知道這個情況 並且協助改善工作流程 不然的話 很沒效率
如果團隊真的有互相卸責的文化 那麼在你發現有 api 缺漏之類的狀況時 請用 email CC 多人的方式 或是在聊天群組 @多人的方式 留下紀錄 證明時程的延誤不是你的問題。並且 出包的當事人 之後也許會自動改善合作態度
大家都是專業人士 將心比心的話 其實通常不會讓人有難合作、溝通沒效率的感覺。不過 你也要盡量反應狀況 讓人知道你遇到問題或者有某些需求 否則 說不定大家都很滿意 只有你覺得有問題
如果已經回報狀況 但是技術主管拒絕協助改善 那麼這個團隊的工作效率低落 並且主管沒有能力改善 可以考慮離職
以上 參考看看