034 · 找對問題比寫程式更值錢
寫程式不再是瓶頸,讀懂客戶需求才稀缺;用故事地圖、價值架構設計找回分析師工具箱,才能打造真正值得做的東西。
原標題:You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs
重點摘要
- 內部黑客松的教訓年初的內部黑客松做出約 21 個 agent 提案,其中 17 個後來被放棄,原因是做不出實際商業價值,或根本拿不到需要的資料存取權限。
- 瓶頸從寫程式移到讀懂需求過去兩三年,取得程式碼與開發能力已經不再是門檻,真正稀缺的是能不能接觸到利害關係人、把需求問清楚。
- 分析師工具箱重新變重要故事地圖(story mapping)、商業模式圖、價值圖這些老工具,重新成為打造好產品的關鍵能力。
- 把需求包裝成使用者故事每個 user story 都要有 persona、需求、原因與驗收標準;AI 本身就是照這種結構訓練出來的,用它熟悉的格式餵資訊,結果會更好。
- 先想價值再做設計講者把這套思考流程稱為 VAD(Value Architecture Design)——先搞懂價值怎麼產生、流程怎麼走、底層架構長什麼樣子,才開始做設計。
- 辨識做錯東西的訊號功能出貨速度很快但採用率低、demo 好看卻沒人真正在用、只看上線功能數而不看使用頻率,都是警訊。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場破題 | 講者自我介紹,主題是:在寫程式不再是瓶頸之後,真正稀缺的能力是搞清楚該打造什麼。 |
| 00:31 | 黑客松案例 | 年初內部黑客松做出約 21 個 agent 提案,其中 17 個後來被放棄,因為做不出商業價值或拿不到資料存取權限。 |
| 01:16 | 講者背景 | 過去 13 年講者都在商業與 IT 之間當橋樑,過去把需求寫成規格給開發者與顧問,現在同樣的技能拿來寫給 AI。 |
| 02:20 | 瓶頸轉移 | 過去兩三年,寫程式碼、取得開發能力已經不是瓶頸;真正的瓶頸變成能不能接觸到利害關係人、把需求問清楚。 |
| 03:15 | 福特的類比 | 若只問顧客要什麼,顧客只會說想要更快的馬;AI 也一樣容易只給出最常見的答案,重點是要跳脫這個平均值。 |
| 04:16 | 分析師工具箱 | 真正重要的技能變成故事地圖、商業模式圖、價值圖這些老工具。 |
| 04:39 | 故事地圖示範 | 以客服系統為例,用故事地圖的骨幹拆出聯繫、分流、解決、結案等階段,先看懂大方向,再決定第一版該做哪些使用者故事。 |
| 07:08 | 使用者故事結構 | 每個 user story 都該有 persona、需求、原因、驗收標準;AI 本身就是照這種結構訓練出來的,用熟悉的格式餵資訊會有更好結果。 |
| 08:04 | 四個提問 | 提出釐清需求的四個問題:這是誰的問題、贏的樣子是什麼、能不能幫對方更快更安全達成,以及這件事會不會改變一個決策。 |
| 09:53 | VAD 思考流程 | 提出 VAD(Value Architecture Design):先搞懂價值怎麼產生、流程怎麼走、底層架構是什麼,才開始做設計。 |
| 10:29 | 新的護城河 | 大家都能用一樣的模型寫程式,差異在於誰更懂業務需求;這是老技能,但變成新的經濟價值。 |
| 11:11 | 做錯東西的訊號 | 功能出貨速度很快但採用率低、demo 好看卻沒人真正在用、PR 沒經過真實使用者測試,都是警訊。 |
| 13:06 | 週一就能做的事 | 建議先盤點現在追蹤的指標對不對,捨棄「上一季出了幾個功能」,改看「用超過兩次的功能有幾個」。 |
| 13:46 | 讓專家貼近決策 | 把真正懂業務的資深人員往客戶端移動,讓他們參與決定該打造什麼,而不是要求每個人都變成產品經理。 |
| 15:02 | 結語與建議 | 建議挑一個真正想做的案子,先用使用者故事做一次、再不用使用者故事做一次,比較兩者差異,就能感受到差別。 |
值得記的話
名詞與人物
| VisualLabs | 講者創辦的公司,訓練顧問與團隊如何做需求訪談,把構想轉成可執行的規格。 |
|---|---|
| Story Mapping | 用骨幹拆解使用者在流程中每一步在做什麼的視覺化工具,這場演講用它示範客服系統該先做哪些功能。 |
| Business Model Canvas | 講者提到的另一項分析師工具,跟故事地圖一起被歸類為「分析師工具箱」。 |
| VAD(Value Architecture Design) | 講者自己命名的思考流程,主張先搞懂價值、流程、架構,再開始做系統設計。 |
| User Story | 有 persona、需求、原因、驗收標準的固定結構,因為 AI 本身是照這種格式訓練的,用這種結構寫需求能拿到更好的結果。 |
| Henry Ford | 講者引用的歷史類比:只問顧客要什麼,顧客只會說要更快的馬,藉此說明不能只照使用者字面上的話做事。 |
| vibe coding | 講者用來形容「直接讓 AI 生成程式碼、快速做出東西」的做法,提醒這樣做出來的東西不代表真的有人會用。 |
延伸
- Value Canvas:演講中跟故事地圖、商業模式圖並列提到,但沒有進一步說明它的用法。
- Design Thinking:講者提到故事地圖這類工具原本就是 design thinking 常用的東西,但沒有展開說明其他相關方法。