每個職務都有一條從原本專長出發、往兩端延伸的路，終點是能把一個問題從頭到尾變成可以運作的產品
週二早上九點，設計師怡君在晨會提到，會員反映收藏過的節目總是找不到。午餐前，她已經用 AI 開發工具做出一個可以點擊、接上測試資料的收藏清單原型，貼在團隊頻道請大家試用。產品經理承翰沒有另外寫需求文件，他補上三條判斷「這樣算不算解決問題」的驗收標準；前端工程師家豪看了生成的程式碼，指出兩個在舊款手機上會卡頓的地方；後端架構師志明確認資料存取都走既有的權限規則後，讓功能在下班前進入小範圍測試。
這樣的一天，在越來越多團隊裡已經不稀奇。過去的產品流程像接力賽，研究、需求、設計、切版、串接、上線，每一棒交給下一棒，等待與誤解都藏在交接的地方。當 AI 能在幾分鐘內產出畫面與程式碼，交接本身反而成了整個流程裡最慢的環節，大家開始期待每個人都能把一件事從頭推到尾。
常見的說法是：AI-Native 就是讓所有人都去學寫程式。這個說法只對了一半。如果人人都能做出畫面、寫出程式，工程師的價值在哪裡？設計師又剩下什麼？答案其實就藏在那個週二早上：每個人都參與了完整的一件事，但每個人出手的地方，仍然帶著自己原本的專長。
AI-Native 時代的職務轉型，是讓每個人從原本最強的能力出發，往上游的問題定義與下游的實作驗證延伸，直到能獨力完成一個完整循環，同時讓原本的專長，成為團隊裡其他人可以倚賴的品質關卡。
獨當一面，指的是能完成一個完整循環
談轉型之前，先釐清終點長什麼樣子。所謂獨當一面的 AI-native 開發者，指的是能帶著 AI，把一個模糊的問題走完四個環節：先把問題定義清楚，再判斷什麼樣的體驗才算好，接著把畫面、資料與服務組裝成可以運作的東西，最後確認它真的正確、安全、穩定。
這四種能力，過去分散在不同職務身上。產品經理擅長定義問題，設計師擅長判斷體驗，前端與後端工程師負責組裝與把關。AI 工具大幅降低了「組裝」的門檻，於是原本卡在組裝這一關的人，突然可以往前走；原本只負責組裝的人，則必須往前補上定義與判斷的能力，否則容易被困在越來越小的範圍裡。
這也是轉型路徑因人而異的原因。每個人的起點不同，缺口也不同，但終點都是同一個：拿到一個問題，就能交出一個可以讓使用者試用的成果，並且清楚知道它哪裡還需要別人幫忙確認。
UX 設計師：從交付畫面，到交付可以被使用的體驗
回到怡君。過去她的工作成果是一組精緻的設計稿，交出去之後，最終上線的樣子往往和原稿有落差，她也很少有機會看到真實資料塞進畫面時的狀況。現在她可以直接做出能運作的原型，第一次發現「收藏清單有三百筆時要怎麼呈現」這類問題，在設計稿階段根本不會出現。
設計師的優勢在於對使用者情境的敏感度，以及對一致性的堅持。缺口通常在於狀態與資料：載入中、沒有資料、網路中斷、權限不足，這些情境在靜態畫面裡很容易被忽略，在真實產品裡卻是體驗好壞的關鍵。
可以開始的練習有三個。第一步，下一個專案改用接上真實或擬真資料的可互動原型取代靜態設計稿，讓自己面對邊界情境。第二步，學會看懂並微調生成出來的元件程式碼，至少理解設計規範如何對應到程式裡的顏色、字級與間距設定。第三步，主動認領一個小功能，從研究、設計到做出可試用版本都自己完成，再請工程師協助檢查效能與安全。
不妨問問自己：上一次親眼看到自己的設計被使用者實際操作，是什麼時候？
產品經理：從撰寫需求，到定義「什麼叫做對」
承翰過去花最多時間的工作，是寫需求文件、開會解釋需求、再確認做出來的東西符合需求。在 AI-Native 的流程裡，他發現寫得再完整的文件，都比不上一個能操作的原型更快對齊大家的理解，於是他的重心移到了更前面與更後面的兩個地方。
前面的地方，是把問題講清楚。AI 能快速產出各種方案，但它需要有人說明要解決誰的什麼問題、哪些限制不能違反。後面的地方，是定義怎樣才算成功。**當產出變得便宜，判斷產出是否正確，就成為產品經理最有價值的工作。**這包括寫下可以驗證的驗收標準，也包括親手操作、親手比對資料，不再等工程師回報。
練習可以這樣開始。第一步，把下一份需求文件改寫成「情境、限制、驗收標準」三段式的規格，讓 AI 與工程師都能直接依此工作。第二步，自己用 AI 工具做出至少一個簡單原型，親身體會哪些需求寫得模糊。第三步，學會讀懂基本的資料查詢與數據儀表板，上線後由自己判斷功能是否達成目標。
可以想想：目前寫的需求，有多少是在描述問題，又有多少是在替別人決定解法？
前端工程師：往上長出判斷力，往後接上服務
家豪是四個人裡最早感受到變化的。畫面切版與元件實作，正是 AI 最擅長的工作之一，他一度擔心自己的位置。後來他發現，那天他指出的卡頓問題，是生成的程式碼最容易出錯、也最難被其他人察覺的地方：效能、無障礙、跨裝置相容、複雜的互動狀態。
前端工程師的轉型方向有兩個。往上，是長出對產品與體驗的判斷力，從「依照工單實作」轉為「理解這個畫面要解決什麼問題，並提出更好的做法」。往後，是補上資料與服務的能力，能自己串接 API、處理資料格式、部署簡單的後端服務，讓一個功能不必等待別人就能完整運作。
具體的練習包括：第一步，請產品經理或設計師直接帶著使用者問題來找自己，先把設計稿放一邊，練習從問題開始思考。第二步，選一個需要後端支援的小功能，自己完成資料讀寫與部署，熟悉團隊的服務架構。第三步，整理一份前端品質檢查清單，讓設計師與產品經理生成的程式碼，在合併前都能經過這道關卡。
值得自問的是：如果明天所有的切版工作都交給 AI，自己最想把多出來的時間花在哪裡？
後端架構師：從親手建置，到設計讓別人安全前進的軌道
志明的轉變最安靜，影響卻最深遠。當設計師與產品經理都開始自己做出可運作的功能，系統裡出現程式碼的速度變快了，來源也變多了。他的工作重心從親手寫出每一支服務，移到確保大家在加速時不會出事。
這代表後端架構師要把腦袋裡的經驗，轉化為其他人與 AI 都能遵循的規則：資料怎麼存取、權限怎麼檢查、敏感資訊怎麼處理、服務怎麼監控、成本怎麼控制。架構師的價值，從「自己能做出多穩固的系統」，轉為「讓多少人能在這套系統上安全地自行開發」。
可以開始的練習有三步。第一步，把團隊最常見的開發模式整理成可以直接套用的範本與規則文件，讓 AI 生成的程式碼一開始就符合架構規範。第二步，建立一個安全的實驗環境，讓非工程背景的同事可以在裡面放心嘗試，不會碰到正式資料。第三步，往上游參與產品討論，在功能構想階段就提出資料與架構上的可能性，而非等到最後才把關。
可以想想：團隊裡有多少架構知識，目前只存在少數幾個人的腦袋裡？
同一個功能，四種人會怎麼完成
把四條路徑放在一起看，會更清楚它們的差異與交會。假設現在要做一個「依觀看紀錄推薦相關節目」的小功能，並且交給其中一個人獨力完成。
如果交給怡君，她會先花時間想清楚推薦結果要出現在哪裡、使用者不感興趣時怎麼回饋，原型的體驗會最細緻，但她會請志明確認觀看紀錄的使用方式是否符合隱私規範。如果交給承翰，他會先定義「推薦得好」要用什麼指標衡量，做出的版本也許畫面樸素，但上線後最快知道成效。
如果交給家豪，功能會在各種裝置上都流暢，資料串接也乾淨俐落，他需要補強的是推薦邏輯背後的產品判斷，於是會先找承翰聊聊目標。如果交給志明，資料處理與效能會最穩固，還會順手把推薦服務設計成其他功能也能重複使用的元件，但他會請怡君幫忙看看介面是否好用。
四個版本都能上線，也都還不完美。獨當一面的意思，是每個人都能交出完整的成果，同時清楚知道該在哪個環節請誰來看一眼。轉型之後，團隊合作的方式從依序交接，變成彼此互相檢查。
給帶領團隊的人：把轉型放進日常
對主管與決策者來說，最容易犯的錯，是把轉型當成一次性的訓練專案：辦幾場工作坊、發一批工具帳號，然後期待大家自然改變。真正有效的做法，是調整日常工作的設計。
第一，讓每個人都有機會負責一個從頭到尾的小題目，範圍小到失敗也不痛，但完整到能練習所有環節。第二，刻意安排跨職務的搭檔，讓設計師與後端工程師一起完成一個功能，彼此的專長會在過程中自然流動。第三，重新定義「完成」的標準與審查流程，讓品質把關從最後一道關卡，變成每個環節都有人負責的習慣。
轉型的過程裡，每個人都會經歷一段做得比以前慢、也比以前不安的時期。團隊成員都留在原本的團隊裡，只是每個職務的內容被重新設計，這個訊息需要被清楚說出來。給予嘗試的空間、容許初期的錯誤，比任何工具導入都更能決定轉型的成敗。
回頭看那個週二早上，怡君、承翰、家豪與志明都沒有放棄自己的專長，他們只是把專長放到更前面或更後面的位置，讓一個問題在同一天內就變成可以試用的產品。每一條路徑的起點不同，需要補上的能力也不同，但方向都一樣：往問題靠近，往成果靠近，並且成為別人可以信任的那一道關卡。
AI 讓每個人都有機會獨當一面，而讓團隊真正變強的，是每個人都願意從自己的專長出發，多走那一段原本屬於別人的路。
發佈留言