Blog 266/365：【學新知】除了流程圖、Mockup、DOD之外，PM還可以寫什麼在Spec上

🤔為什麼要寫這篇小記？

每一家軟體公司的開發流程都會因為團隊的習慣而有所不同，在Spec (規格書)的撰寫上也會有所差別。

就目前累積的工作經驗下來，我自己在寫軟體功能開發的Spec一定會包含以下項目：

  • 流程圖
  • UI Flow Chart
  • Wireframe 或 Mockup
  • Definition of Done (DOD, 根據每個畫面)
  • 其他系統邏輯 (例如交易手續費、點數...等，需要特別系統處理)

但在今天和工程師的討論中，我發現這樣還是沒有根本上解決工程師想看到的文件，就差在「API」的整理。

以一個畫面開發來說，前端工程師需要了解這個畫面需要幾隻API、每隻API分別提供哪些資料。當這兩個問題釐清之後，就可以請後端工程師加入討論，針對API的內容設計給予回饋，例如是否有現行API可以使用、哪些資料無法透過API給予...等。

在討論過程中，我感覺以上每項工具想達成的目的分別是：

  • 流程圖：了解功能基本流程
  • UI Flow Chart：實際看畫面在流程中的樣子
  • Wireframe 或 Mockup ：溝通畫面上的功能、呈現的資訊
  • Definition of Done (DOD, 根據每個畫面)：溝通畫面上每個功能的細部邏輯
  • 其他系統邏輯 (例如交易手續費、點數...等，需要特別系統處理)

這邊PM可以多學習使用Ｗireframe來進行溝通，原因是不會讓討論焦點聚焦在畫面上的UI，同時也可以討論需要的API有哪些，方便前後端工程師即早定義出Spec。

如果可以的話，學習去寫API的JSON格式，思考這個API需要傳送哪些參數、成功與失敗的狀態可能有哪些，會是讓自己的技術觀念進步的練習方法。