導入 AI 開發後，下一個瓶頸在哪裡？
老闆說：「我們現在有 AI 了，你覺得產品開發速度可以快多少？」
我通常反問：「你現在產品從想到上線，哪個環節最慢？」
大部分人停頓一下，說：「應該是開發吧。」
其實不是。開發早就被 Claude, Codex 這些工具補上去了，RD 寫程式的速度蠻快的，問題不在這。
我問過蠻多 PM，他們真正的瓶頸是兩個地方：第一，把 idea 轉成 RD 看得懂的需求；第二，東西做完之後，要怎麼確認它對了。
說穿了，就是「轉譯」跟「驗收」，這兩個環節還卡著。
做一個產品功能，其實是一串循環，不是一條直線
我在產品營常跟同學說一件事：做一個東西，它的真實樣子不是瀑布，是一個循環。
想 → 轉譯 → 做 → 檢查找問題 → 轉譯 → 做 → 檢查找問題 → 轉譯 → 做……
你看，「轉譯」跟「檢查找問題」出現了不只一次，出現了好幾輪。
在這個循環裡，AI 能幫到的地方，其實已經蠻清楚了，「做」這件事，AI 幫很多。但「想」，加速不了，這是 PM 的核心工作；「轉譯」，現在還是瓶頸；「檢查找問題」，也還是瓶頸。
GWT 就是用來同時拆這兩個瓶頸的工具
轉譯為什麼是瓶頸？因為 PM 腦袋裡的 idea，跟 RD 收到的需求，中間有一個巨大的 gap。
PM 說「要讓用戶感覺結帳很快」，RD 心裡想：「這到底是要改後端速度？改動畫？還是改步驟數？」
沒有人知道。大家靠會議、靠猜、靠 RD 問、靠 PM 再講一次，把這個 gap 慢慢縮小，這個過程蠻費時間的。
其實有一個東西可以解這件事，叫做 GWT，也就是 Given-When-Then。
Given（在什麼情境下），When（當使用者做了什麼），Then（應該出現什麼結果）。
這個格式搭配 Example Mapping 深入挖掘細節，確保團隊能對齊。
一旦有了 GWT 後，搭配工具和一些初期建設，RD 就可以直接把它轉成自動化測試，也就是 TDD 的做法。「驗收」這件事就不再靠人工一個個 case 點，RD 跑測試，通過了就是通過了。
這樣就把轉譯和驗收這兩個瓶頸，同時拆掉。
GWT 庫不是每次重生，是要累積的資產
這裡有一個細節很重要，就是 GWT 不應該每次從零重寫。
功能有新有舊，很多 GWT 其實是重複的，或者是在原來的基礎上修一兩條。每次都重新產，其實是在浪費時間。
所以正確的做法，是維護一個 GWT 庫，舊的功能有自己的 GWT，新功能做完加進去，修改的功能去更新對應的條目。時間久了，這個庫本身就是系統文件，也是測試基礎。
再加一個 skill 幫助快速產 GWT，讓 PM 不需要從白紙開始想格式，來幫助 PM 從 user story 產出符合公司框架、避開常踩的坑，產出 GWT 交給 RD。
這樣 PM 在轉譯這個環節花的時間，就可以拆掉瓶頸，品質更高。
PM 不是要一條龍，是要把自己的「供料角色」做對
我蠻常看到一個迷思：覺得「自己一條龍可以從需求到驗收全部搞定」的 PM，是厲害的 PM。
但其實這個想法，跟工廠老闆說「我找一個人從採購到包裝全包」是一樣的邏輯，量出不來的。
要量，就是要建系統，拆瓶頸。
方法A：一個人一條龍做完，這樣沒有交接的瓶頸，但可以一條龍做完的人，本來就是少數，不太可能用這種方法規模化。
方法B：把不同職能的人組合，但是有人和人之間的瓶頸，但可以修流程，拆瓶頸，最重要的是可以複製。
PM 在這個系統裡，其實是「供料」的角色，供好的需求給 RD，讓 RD 可以快速做、快速測、快速跑。
如果 PM 供的料是模糊的描述，RD 就要花很多時間跟 PM 對齊，做完還要等 PM 一個個功能點進去按，才知道對不對，這個流程產能就一直卡著。
換個做法：PM 供的料是 GWT，RD 拿去跑自動化測試，出問題的 case 才需要 PM 進來看。PM 的時間就可以集中在真正重要的一件事：這個功能做出來，是不是用戶真正要的東西？體驗好不好？品質夠不夠？
這才是 PM 應該花時間的地方。
The post 導入 AI 開發後，下一個瓶頸在哪裡？ first appeared on Mr. PM 下午先生.
