ATPM : PRD的重要性
ATPM : PRD的重要性
如果說 ATPM / Spec driven Development ， 跟一般軟體開發流程最大的不同，就是
ATPM 是以 PRD 為中心的，不是以人為中心的
一開始所有訪談的資料必須都落地到 PRD ，不能留在你的腦中。工程師開發到一半，發現有 PRD 寫錯了，就直接回 Feedback 回去 PRD ，QA 到發現真實流程跟合約不同，跟現場營運人員確認無誤後，也直接 feedback 回去 PRD
實務上 PRD 迭代的頻率
在我們開發當中，這樣的PRD 的迭代反饋幾乎每天都在發生，而且通常都發生在 Dev 跟 QA階段，很多時候第一次 PM訪談幾乎只能正確 60% ~ 80% 。
原因是這是一個真實已經運行數年的運輸業務帳務系統，不是外面的 POC 系統，這是真的在營運運送真實的東西
- 每一個業務裡面的商業邏輯非常的複雜，每一個業務跟其他業務都不太一樣。送便利商店的流程，合約，派車邏輯，計價邏輯，跟常溫的家用品，跟某知名五金百貨的走法算錢方式都不同。裡面的各業務記帳共性幾乎只有 50% ，開發一個系統加上10個業務，裡面難度就跟開發10個帳務系統一樣複雜
- 在現實的物流界，現場的流程幾乎每幾天都會調整一次，甚至很多時候，為了某些特別狀況有所謂的約定俗成的加定條款(不在合約裡面) ，頻率高到現場的人自己也不一定清楚細節，更別說詳實反饋給後面 back office 的財務，或是法務的合約補上。
舉一個極端的例子，根據 git log , 某個上市日用品的運輸業務計價的 PRD，在一開始撰寫前，我們就已經跟財務跟前線計價同事開了 8 次會議（每個會議都是 1hr 起跳) ，才弄出第一版 PRD 。就算已經那麼努力了在開發跟QA期間，PRD 一共改了 24 次，幾乎每個團隊成員都有過。
所以很多時候，我們 QA 幾乎才是最了解前線記帳邏輯的人，因為我們用大量的時間去測試真實記帳資料有沒有跟所有的文件 aligned , 所以也變成現行系統的糾錯者。這麼複雜的商務場景，一定要寫下來，不會有任何一個人可以腦袋記下來的。
人性的考驗
但是問題在於，在專案壓力很緊張的情況下人之常情都是先做好工作，未來再寫文件。
“文件為主” 是一個反人性的做法
唯一可以確保 PRD 是所有人資訊中心可能性，就是每個業務的每個環節，都是不同人，而且我瘋狂的輪替每個人
每個業務都是不同人做不同的事情。nano banana 生出的圖
以那張圖為例，你是河馬，你昨天做業務 B 的Dev ，但是你今天就要做業務 C 的 QA ，當你幾乎每天遇到的合作上下游都是不同夥伴時，你唯一也只能信任 PRD 了，這時候 PRD 的正確性跟填寫的積極性就可以保證了，因為你一但偷懶不 update PRD，上下游會幹譙過來。
組織的優勢
這裡有一個我團隊組織上的優勢，大家可能知道我被商周採訪的原因是因為我大量啟用 AI + 工讀生
很害羞的照片
我們團隊一開始建立就是一堆工讀生的前提下。因為工讀生一週來的時間不固定，所以每天處理某個業務的人都會換來換去的，時間一久大家都習慣了這樣的快速換手。在做這個帳務系統的當下，不論大家的興趣跟意願如何，我都要求每個人都是 PM + Engineer + QA ，唯一的差別只有工作的比例差別，舉例
- 一個比較適合 PM 的 A : 60% PM , 20% Eng , 20% QA
- 另一個比較適合 Eng 的 B : 30% PM , 60% Eng , 10% QA
也因為如此，全部的人都習慣工作內容換來換去，業務換手是 “文件導向” 而非 “老手導向” 。
所以開發那個帳務系統的時候，明顯的優勢在於每天會隨著有空的人的不同，每天大家都會安排不同的業務的不同模塊，不會因為某人今天請假，他負責的環節就會卡關。
PRD 的實戰
到目前為止，我們都還沒講 PRD 要怎麼寫，其實我覺得這裡竅門很多，但是都很貼近大家的習慣，有點見仁見智，我就不講太多細節，我建議大家沒事可以找我們聊天比較能夠盡快找到最佳策略。
對我來說，PRD 的目的是讓兩個受眾看得懂，人跟AI 。
受眾是人
維護一個統一的 PRD 章節框架很重要，不然大家自己用自己的 template ，大家換手的時候就暈了。這是一個虛擬 PRD 供大家參考
基本上就是一個簡單的專案背景，角色跟責任，流程描述，範圍 (In / Out) ，user story ，功能需求 ，data source ，milestone ，驗收標準…etc 。在實際 Dev 開發時，流程描述 , 計價邏輯, data source 是最重要，因為我們 dev 也會做初步的 QA ，這時候驗收標準也會需要
在 QA 階段，流程描述 , 功能需求 ，data source 加上驗收標準是主要需要 PRD 的部分，但是我們會配上另外一個 QA Framework Prompt MD 提供 QA (等談到 QA章節會提) 。
受眾是 AI
為了讓 AI 也看得懂，可以盡快 Dev 或是 QA 。我們最後發現要提供一些技術程度細節描述，對 AI Dev 很有幫助。
舉例，上面的虛擬 PRD 通常這樣的描寫對一般簡單跟中等 use case就足以負擔了， 雖然做不到 one shot 就可以寫出完全正確 SQL Code ，但是簡單業務 90% 正確，中等任務 70% 正確是沒問題的。
但是為了寫我上面說的改 24次的複雜業務，我們進化到 PRD V2.0 ，才搞定
PRD V2.0 虛擬業務
上面依舊是虛擬業務，但是用 PRD V2.0 標準來寫，這裡 PRD 顆粒度已經有一點點介於 PRD 跟 Pseudo Code 中間了，裡面連寫入的 table 或是 join 的 key 都提供了。簡單來說，寫的人需要懂一點點程式了。通常這樣等級的 PRD 產出的 Dev or QA 代碼，就算複雜業務，也 85% 接近正確SQL 。
所以到最後，我們意識到
在新世代的軟體工程師，其實就是交付 PRD ，而 Code 只是 PRD 另外一種的表達方式而已
在這個帳務系統當中，一共產生 9211 行 PRD ，但是最後主要的業務邏輯 Code 一共 13022 行，大概是 一行 PRD 產生 1.4 行 Code 的比例 。其中PRD幾乎都是人寫的， Code 全部都是 AI寫的 , 使用 Claude 4 Sonnet + GPT O3 , 不同人有不同喜好
5分鐘產生近乎完美的結案報告
我們這個 Project 當初是預計 4個多月上線，後來導入 ATPM 流程，最後大概提前 一個多月。我還記得 7/31 那天 5PM ，我們剛做好這個專案。我當下覺得如果花個一天整理一下結案報告，隔天再寄出報告給其他管理階層，email timestamp 就是八月不好看，但是如果7/31當天寄出結案報告，這個專案就是 7月完成很棒。
所以我問了一下其中一位 PM 妹子，現在 5PM ，可不可以用 30分鐘寫一個結案報告趕快寄出，我以為她會給我其中一個結果
- 人寫的 , 但是就是 半頁 A4 左右的文件
- AI 寫的，但是空泛沒內容，一眼看出有問題
但是5分鐘之後，我收到一個超過 10頁的報告，裡面文之有物，並且每個環節都有大量的本專案資訊佐證，用到技術細節跟業務用詞都很貼近我們，幾乎沒有人看出來不是人寫的
我就問她「我知道是 AI寫的，但是你怎麼做到那麼精確的用詞？」
她說「我們不是寫一堆 PRD嗎？我把 PRD 全丟給 Claude 4 ，3分鐘他就給我這個文件了!」
我驚呆了 !
PRD = 知識結晶體
在現代學習理論，有一個東西叫做「知識結晶體」。用來描述個人如何有系統地建立知識結構，就像晶體從原子鍵結成一個有機的、連貫的整體一樣。這個概念強調將零散的知識點透過邏輯連結（如層級、關聯、因果關係），形成有組織的知識體系，從而增強理解力和應用能力。可以看這篇知乎文章獲取更多
人類的學習，如果可以將一個一個課程從扁平的文字，變成知識結晶體，那人腦等於學會並且不會忘記！
用 nano banana 生成的知識結晶體圖
我發現到這些經過大量 QA驗證過的 PRD ，就是所謂的 “知識結晶體” ，沒有太多贅字，都是真正的業務邏輯跟知識。既然可以用 PRD 寫出沒有錯誤的 Code ，PRD 也可以寫出幾乎沒有錯誤的結案報告。
還記得上面的那句話嗎？
在新世代的軟體工程師，其實就是交付 PRD ，而 Code 只是 PRD 另外一種的表達方式而已
經過這個事件，我要修正為
在新世代的軟體工程師，其實就是交付 PRD ，而 Code 或是 專案報告 只是 PRD 另外一種的表達方式而已