把散落的經驗，變成團隊的共同語言

這頁聚焦三個層次：團隊如何自己運作、成員如何持續成長、跨職能如何共同理解需求。我想呈現的不是單一管理風格，而是我如何把模糊的團隊問題整理成可被使用、延續與擴大的工作系統。

Core leadership systems

這三個系統其實是在解同一件事的不同層次：先讓設計團隊的日常工作可以被查找與交接，再讓成員能在任務中累積判斷能力，最後把這套清楚化的方法延伸到 PM、設計與工程之間，降低跨職能理解落差。

1. Team Operating System：把設計團隊的日常知識系統化

問題

設計團隊變大後，真正的挑戰不是「多管理幾個人」，而是讓每個人都能用一致的方式工作、學習和交接。

在團隊早期，很多事情可以靠口頭同步：需求怎麼接、票怎麼開、檔案放哪裡、行銷或 DBC 的需求要怎麼處理、什麼情況要找誰確認。但當團隊成員增加、合作部門變多、設計需求類型也變複雜時，如果所有知識都只存在於資深成員或主管腦中，團隊就會很容易卡住。

我做了什麼

我把 Design Workspace 當成設計團隊的作業系統來整理，而不是單純的文件資料夾。它把設計團隊每天會用到的資訊集中成幾個入口：

• 工作入口：開票區、設計師量能、各部門需求、週會、每季任務與工作總覽
• 流程與 SOP：設計的工作流程、行銷合作流程、DBC 合作流程、印刷確認流程、請假與交接流程
• 新人 onboarding：新人必看懶人包、Onboard TODO、常用頁面、工具與資料庫使用說明
• 資源與素材：素材庫、字體、品牌素材、印刷廠商、帳號與付費資訊
• 學習與 workshop：Notion、WordPress、時間管理、作圖思維、產品設計、AI 工具、印刷完稿等分享與實作資源

我也把原本容易靠默契處理的工作流程，拆成具體步驟，例如：

• 每週設計週會前如何領票、估 Story Points、回報工作量
• 單週／雙週週會、Retro 和 Workshop 分別要如何進行
• 行銷、DBC、印刷等跨部門需求要如何開票與確認時程
• 檔案交付、歸檔、請假與職務代理人交接要如何處理
• 每季任務要如何拆成量能票追蹤

跨部門協作也不只靠臨時溝通，而是被整理成規則。例如行銷需求會定義開票時間、第一版期限、定稿期限、修提回覆時間；當修提超過一定次數，或第一版和需求落差過大時，就要從留言改成會議重新對齊，避免設計師陷入無限修改。

對新人與顧問教育訓練，我也把 training 拆成「入職前準備 → 當天實作 → 入職後 follow-up」：不是只講一次流程，而是讓對方實際開票、練習操作，後續再追蹤使用中遇到的問題。

改變

這套做法讓團隊不再只依賴口頭同步或資深成員帶路，而是有一套可以查找、可以訓練、可以交接的知識系統。

• 新人能更快 onboard：知道不同工作情境要去哪裡找答案，不需要每件事都從零問人。
• 既有成員能一致協作：接需求、開票、估量能、交付、歸檔都有共同做法。
• 跨部門合作更穩定：當需求不清楚、修改超出範圍、或時程不合理時，設計師有依據可以回到流程裡溝通。
• 團隊能持續學習：週會、Retro、Workshop 讓新工具與新方法不只是一次性教學，而是固定進入團隊節奏。
• 主管不再是所有問題的中繼站：我把複雜工作拆成清楚入口、流程、規則和學習資源，讓團隊能自己找到答案，也能把新的經驗補回系統裡。

當團隊日常工作有了共同入口後，我接著關注的，是成員如何不只照著流程完成任務，而是在每次任務裡累積自己的判斷能力。

2. Growth Conversation：把 1on1 變成成長對話

問題

有了團隊日常運作的系統後，我發現另一個挑戰是：流程可以讓人知道怎麼做事，但不一定會讓人成長。成員還需要有機會回頭理解自己如何判斷、哪裡卡住、下一步要練習什麼。

設計師的成長如果只靠主管印象，很容易變成模糊的感覺：最近表現不錯、好像還可以更主動、某些地方需要加強。這些說法聽起來合理，但對成員來說，不一定知道下一步要怎麼做。

所以我希望 1on1 不只是近況同步，也不是績效前才出現的回饋，而是能幫成員把「我最近卡住了」拆成更清楚的問題：是技能不熟、流程不懂、溝通對象不明確、工作量太滿，還是不知道怎麼判斷優先順序。

我做了什麼

我建立了五個維度的評核框架——任務目標達成、合作與溝通、專業技能與品質、自主性與貢獻、學習與成長——但我不希望它只是一張績效表，所以我把這些維度放進日常 1on1 裡。

在 1on1 中，我會先讓成員回顧自己的狀態：

• 最近哪個任務最有成就感？是因為成果好、過程順，還是自己有學到新東西？
• 哪個任務雖然完成了，但覺得還可以更好？如果重來一次，會怎麼做？
• 最近在哪個能力上有進步？你是怎麼發現的？
• 現在卡住的地方，是技能、流程、溝通，還是資源不足？
• 接下來幾個月，有沒有想挑戰或練習的能力？

不同階段的成員，我會用不同方式帶：

• 新人：先確認適應狀況、工具與流程是否理解，像是 Notion、票務、Design Workspace、顧問溝通方式。當新人提到不清楚截止日或修改票怎麼處理時，我會把問題拆成具體做法：怎麼開修改票、怎麼填量能、要找誰確認標準。
• 實習生：我會把學習任務拆小，讓對方不要只停在「熟悉產品」。例如把後台研究拆成診所櫃台情境、健保預約、自費預約、手機版操作等 user story，再拆成半小時可以完成的小票。
• 已能獨立負責專案的成員：我會帶他們回顧更高層次的能力，例如流程管理、跨部門協作、如何建立穩定系統，而不是只把手上的任務完成。
• 壓力較高的成員：我會先釐清工作負荷和壓力來源，再一起討論界線。例如當成員因為修改需求工作到凌晨，我會引導他們思考：哪些需求需要被重新對齊？哪些修改不該無限制承接？怎麼把討論放回群組，而不是私訊裡一直接球？

改變

這讓 1on1 從「主管問近況」變成一種成長練習。成員不是只回報自己做了什麼，而是開始學會分析自己的工作方法：哪裡做得好、哪裡卡住、下一次可以怎麼拆解。

對我來說，管理不是直接告訴成員答案，而是幫他們建立判斷能力。我會把模糊的感受拆成可以討論的問題，再把複雜的工作流程拆成可以練習的小步驟。這也是我經營團隊時最重視的事：讓每個人不只是完成任務，而是在每次任務裡累積新的能力。

3. Product Collaboration System：把需求變成跨職能能共用的產品語言

問題

當時公司仍處在新創快速成長階段，產品線、需求來源與跨職能協作模式都持續成形。這讓團隊能快速嘗試，但也讓需求討論容易停留在口頭共識與個人經驗。

當設計團隊內部的工作方式逐漸穩定後，我開始把同一套「把模糊經驗整理成共同語言」的方法，延伸到 PM、設計與工程的協作流程。產品開發最容易卡住的地方，通常不是單一角色做不好，而是 PM、設計、工程對「使用情境是什麼、現在推進到哪一步、什麼叫做完成」沒有共同理解。

如果需求只停在一句功能描述，設計容易太早進入 solution，工程也很難判斷 scope；最後常常到開發後期才發現，大家對使用情境、完成條件或優先順序的理解不同。

我做了什麼

我整理並建立 Product Workspace，把產品開發需要的資訊集中到同一個工作系統裡，讓需求從收集、拆解、設計到上線，都有清楚的流轉方式。對招募方來說，這裡的重點不是我多建立了一套文件，而是我把跨職能協作中最容易失焦的資訊，整理成團隊可以共同使用的產品語言。

具體來說，我把協作方式收斂成幾個關鍵設計：

1. 建立 Product Home 作為產品團隊入口：把 Product Board、Request Pool、各產品線資料、Roadmap、Release、PM / PD 使用說明書、產品開發流程指南集中在同一個地方，讓團隊知道產品資訊要去哪裡找。
2. 整理需求到上線的流程：將流程拆成 User Requirement → User Story → Backlog → PRD → Product Spec Lockdown → Design Spec Lockdown → Release / Rollout，讓每個階段要完成什麼、誰負責、下一步是什麼都更清楚。
3. 用 User Story、PRD 和 Acceptance Criteria 定義共同語言：我希望團隊不要一開始就跳進功能解法，而是先釐清誰在什麼情境下，需要完成什麼事，以及這件事為什麼重要。PRD 和 Acceptance Criteria 則用來定義完成條件，避免團隊只完成 task，卻沒有真正確認使用者問題是否被解決。
4. 設計 Product Spec / Design Spec lockdown 節點：Product Spec lockdown 用來確認需求、scope、staging deadline 與開發方向；Design Spec lockdown 則用來確認 UI、prototype、互動狀態與工程實作邊界。這讓產品開發不再只靠會議中的口頭共識，而是有明確的決策停靠點。

改變

這讓產品開發不再只是「大家開會對齊」，而是有一套可以被共用、追蹤與交接的產品語言。

User Story 讓團隊先確認使用者問題，而不是太早跳進解法；Backlog 和 PRD 讓需求、設計與工程任務可以被串連；Product Spec / Design Spec lockdown 則讓每個階段的決策有明確停靠點。

對我來說，產品流程設計的價值不是增加文件，而是降低跨職能理解落差。當 PM、PD 和工程都能在同一套資訊架構下工作，團隊就能更早發現問題、控制 scope，也更穩定地把需求推進到上線。

Supporting practices

除了三個核心系統，我也把同一套「把經驗轉成方法」的能力，用在不同的 leadership 場景裡。這些不是另外三個完整案例，而是補充我如何在使用者理解、AI 導入與知識分享中，持續把抽象經驗整理成可參與、可學習、可傳遞的形式。

• Product Culture：讓團隊重新靠近使用者——透過 Eat Your Own Dog Food「虛擬診所」跨部門競賽，讓設計、工程、業務不只是討論使用者，而是真的扮演診所經營者與病患。這讓團隊在親自遇到問題後更快形成共識，也開始在決策前多問一句：「這對使用者來說真的有幫助嗎？」
• AI Enablement：讓新工作方法進入團隊日常——我把 AI 導入變成團隊日常學習的一部分，不只介紹工具，而是用真實案例示範如何拆 MVP、驗證流程，讓新工作方法能被團隊實際採用。
• Knowledge Transfer：把方法轉譯給不同背景的人——我也把內部沉澱的方法帶到外部教學與社群分享，練習把抽象經驗轉成不同背景的人也能理解、學習和使用的知識。

Outcome從個人經驗，到團隊系統

這些案例共同指向同一種 leadership：不是把所有決策集中到主管身上，也不是要求每個人照著固定流程做事，而是建立一個能自己運作、自己學習，也能跨職能協作的團隊系統。

我把設計團隊的日常知識整理成可以查找與交接的 workspace，把 1on1 變成成員能拆解卡點與累積能力的成長對話，也把產品需求整理成 PM、設計與工程都能共用的產品語言。

最後形成的不是一套僵硬的管理制度，而是一個能持續變強的工作環境：新人能更快理解標準，成員能更清楚討論成長，跨職能協作能更穩定，團隊也能主動吸收新的工具與方法。這也是我作為設計管理者最想強調的能力：不只解決眼前問題，而是把一次次經驗沉澱成團隊之後仍然能使用的系統。