加快了速度，少了回饋
2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。
在這堂課程中我繪製了一張軟體開發過程管理的架構，這張圖我從公司策略->產品策略->需求管理，一路到開發過程管理、交付、市場回饋，最後再回到產品需求管理。
當年我曾說過，軟體開發最重要的其實不是程式開發本身，而是 align 公司策略與產品策略，同時兼顧好短期需求，將需求管理做好。
但我們也可以看到產品需求管理是上述架構中最主要的節點，上承策略，下接短期需求，右邊則是成為所以開發計畫的起頭，同時還要承接來自市場回饋，並能持續優化管理過程與技術債務管理。
簡單的說，決定做什麼，決定了產品定位，決定先做什麼，則決定了策略重心。但要做出決定，除了對目標有清晰的認知外，更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。
這陣子透入 AI 開發後我對這張架構圖有一些新的想法：
首先，是生產力過剩。
因為 AI 不用休息，生產力幾乎沒上限，唯一的限制應該是人腦思考的速度。這意味著，開發的生產力可能遠多於人腦能負擔的範圍，你只要給了需求，AI 就能完成 PRD 跟設計稿，接著就能進入開發。
這是我看見的第一個問題。而一旦出現生產力過剩的問題，硬塞不需要的工作給 AI 就成了一種常態。
而硬塞會出現什麼問題呢？那就是過度設計，而過度設計所衍生的問題一來是技術債，二來是將系統變得愈來愈複雜，定位開始偏離，使用體驗愈來愈差。
第二，缺乏足夠的回饋。
我在最近一個月完成了三個 production level 的系統，其中一個已經上線在全公司使用，另外兩個也將在兩週內正式上線使用。除了第一個系統我花了比較多個時間外(約兩週)，其他兩個系統我從構想到完成我預定的功能範圍，大約只花了一週的時間。
而且這並不是只有在本地端 run 好，而是連整個 stage / prod 都是完全自動佈署，backup 也都已經處置好，且一定跑 test & review。
如果用過去的開發經驗來預估，我覺得大概比過去快了 10 倍左右。
過去我必須跟設計師合作，也必需訪談許多內外部使用者，做架構設計，然後才進入前後端開發，測試、部署。這過程，我能獲得大量的回饋，包含對需求的理解，技術債的評估，時程壓力下的妥協等。這些回饋，不見得每個都是加分項，但其中仍有部分可協助我們校正自己的想法。
如果你的使用者是 Agent，那可能就簡單多了。前幾天有看到一些團隊專門開發了 Agent 來模擬使用者，而且將這些 Agent 設定好各種背景、角色、能力。
目前看起來挺合理的，但想想這往往只針對產品本身，但一個人對產品的需求其實是多層面的。包含 KPI、主管、客戶、同事、個人需求等等，絕不單純是一個好用的功能這麼簡單。
現在開發的速度太快，使用者可能還沒來得及給回饋，下兩個版本可能又出了。功能愈做愈多，但收到的回饋深入度可能遠遠不足。
第三，對回饋的深度思考減少。
因為 AI 幫忙分析跟總結太方便了，所以現在我也會把發回饋跟收回饋的動作外包給 AI。但每隔一段時間就會發現，AI 做的方向跟自己原先預期的有明顯的落差。
幾次復盤後我的檢討都是，我對回饋的深度思考太少了。
以前我在收到每個回饋時都會思考「使用者為什麼這麼想？」、「他想解決什麼問題？」、「他的數據脈絡是什麼？」、「這件事會有多少使用者受惠？」、「這是我們系統要做的事嗎？」、「這件事的優先緊急程度高嗎？」
但因為生產力高，所以我很容易告訴 AI：「你幫我整理並排序，然後根據你的權限範圍內盡可能做，做完後就發佈到測試環境測試，然後接著開發下一個 sprint。」
我比較少過濾需求，也沒有花太多心思去排優先順序。反正，AI 會全部搞定。
過去這一個月，我踩過幾次這樣的雷，所以三個系統中，有兩個我砍掉重來過，因為我把需求無限制的膨脹了。讓本來好用的東西變得太複雜，或者 AI 設計出連我都難以理解的東西。與其修，我情願整個重來。
回饋，其實是協助我們重新思考與校正方向的重要活動。一旦習慣外包給 AI，那我們其實就脫離了產品面向市場的真實聲音。
上述三個變化，影響到的其實都是產品需求管理。
短時間內做三個系統，讓我有機會再次反思，在 AI 時代產品開發過程最重要也最容易被忽略的任務。
上禮拜開始，我把產品需求管理變成一個重要的節點，所以我將系統定位寫進整個系統決策檔案中，也將產品開發的計劃分 Phase 設定好。哪些做，哪些不做，哪些先做，哪些會比較晚做，這都有清楚的規劃。
一旦我違反了這些原則與計畫，AI 就會提醒我，並要我確認是否跳過原則或調整計畫。這讓我多了時間好好思考。
如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報
也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。
