有時後數位產品,不會是因為使用狀況而停止運營維護,有時是考量整體商業策略,而進行的移轉調整其他開發團隊,繼續開發
如果有發生該情境時,要考量到如何讓其他開發團隊可以順利順利持續進行,因此儘可能附上,下列相關文件內容。
雖然個組織有不同的工作流程和文件,原則上盡可能將文件資訊備齊移轉至其他運營團隊。
移轉計畫流程,讓Sale或運營人員可以安心
Product document:說明該產品的發起的原因、市場屬性、使用者畫像、產品路線圖…等
Bug list:開發截至目前,仍有哪些Bug未修復或修復中,分出輕重緩急,利於後續團隊做資源上的安排
SPEC:說明每一個功能的規格及流程,利於後續團隊在開發中,可以隨時查找。
Internal Release Note:目前已發布的功能說明,其木的是為了讓開發團隊未來與運營團隊進行對接時,可以了解發布狀況。
UI flow/Mockup:提供開發的所有頁面流程、Mockup及Design system的文件內容,以利於開發元件可持續被運用。
Backend API Spec:提供後端資料庫與前端對接的API說明內容及註解,利於新開發團隊在開發中可以查找需要用到那些API
Training Book/User Guide:提供產品使用說明,團隊相關人員,均可了解各功能主要的操作方式,利於各團隊的溝通。
Membership information:提供使用者資料收集的相關欄位說明文件及目的,以利於法務團隊作為備查
Server access accounts:產品中各個環境的使用權限,包含人員名單、帳號、密碼,以作為人員管理使用。
清楚的文件和說明可以幫助團隊之間更有效地合作,減少溝通成本。
學會從經驗中吸取教訓,這有助於未來的決策和行動。
清楚的文件和規格書是團隊之間很有效的溝通橋樑
是的~但是有時候有種「人在江湖身不由及」,很難湊齊完整內容,很多時候都是打帶跑的概念XDDD