背景：我是一家 fintech 新創的初階產品設計師，我們的 app 帳號設定流程流失率高達 60%。舊流程有七個畫面，還要求使用者上傳多份文件才能看到 app 能做什麼。產品團隊懷疑流程太長，但因為「蒐集資料並提供建議」正是 app 的價值主張，我們並不真的清楚使用者卡在哪、為什麼卡。

目錄：這個專案裡，我做了真實使用者研究、與工程密切合作處理技術限制，並基於數據（而非假設）為設計決策辯護。

行動：我提議先做使用者測試再重設計。我招募八位近期放棄流程的使用者，透過視訊做主持式可用性測試。結果出乎所有人意料——使用者不是因流程長而受挫，而是不清楚我們為何需要某些資訊、他們的文件會被如何處理。基於這些洞見，我用漸進揭露與各步驟的清楚說明重設計流程。我也和 iOS 工程師密切合作了解技術可行性：我最初設計假設某些欄位可自動帶入，但當時的 API 不支援，於是我們反覆迭代出兼顧體驗與技術限制的方案。當 PM 想直接砍畫面把流程變短時，我用錄下的使用者測試證明「說明不清」而非「太冗長」才是真問題。

結果：新流程把流失率從 60% 降到 45%，帳號設定相關的客服工單顯著減少，onboarding 體驗評分從 2.1 升到 3.8（滿分 5）。

學習：即使假設看似合理，關於使用者行為的假設常是錯的；展示真實使用者回饋，比設計論證更有說服力；及早讓工程參與設計，比交付完美 mockup 能得出更好的方案。

背景：我是客服平台的 PM，支援團隊被關於帳號設定、帳單、基本疑難排解的重複問題淹沒，每天超過 500 張工單，約 60% 理論上能用既有說明文件回答。領導層想加 AI 聊天機器人來分流、降低支援成本。

行動：我沒有立刻做完整聊天機器人，而是提議先做輕量原型驗證假設。我和一位工程師用既有知識庫做了簡單的規則式 bot，部署給一小群使用者當概念驗證。初步結果令人失望——只有 12% 使用者的問題被解決，許多人直接繞過它送工單。我意識到我們假設使用者會問直接的問題，但他們其實描述的是複雜情境，簡單的關鍵字比對無法處理。我於是和 ML 工程師改用能理解意圖與脈絡的 NLP 模型重建，這需要我協調工程、客服（協助歸類常見問題）與法務（擔心 AI 提供錯誤資訊）。我也建立回饋迴路：未解決的對話自動轉給真人客服，客服可標記 bot 漏掉的重點，這些數據持續改善模型。

結果：最終聊天機器人成功解決 45% 的詢問而無需真人介入，工單量降約 30%，快速解決的滿意度上升，支援團隊能專注複雜問題，這功能也成了對新客戶的重要賣點。

學習：AI 功能比傳統功能需要多得多的迭代，第一版做法很少如預期般奏效；從第一天就把回饋迴路建進 AI 產品至關重要，因為品質取決於持續學習；跨職能協作對 AI 功能格外關鍵，因為它牽涉太多不同專業。

背景：我在一家中型行銷分析 SaaS 的資料平台團隊。我們的客戶資料處理系統負責從各來源匯入、轉換並開放分析，約每天 200 萬筆、服務 5,000 個企業客戶。我主導把它從單體式 Rails 應用遷移到微服務架構。舊的單體造成嚴重業務問題：業務每季損失價值 400 萬美元的企業案（客戶無法匯入大型資料集，系統不是失敗就是要跑好幾天）；客戶成功每週花 30 小時處理資料相關的升級；已因可靠性流失兩個客戶；產品也因架構無法支援即時處理，做不出我們核心競爭策略的 AI 功能。

目錄：三個有趣的部分——(1) 發掘與關係人對齊：我如何界定業務衝擊並跨工程、業務、產品、客戶成功建立共識；(2) 技術執行與架構決策：有些取捨要駕馭；(3) 上線策略與風險緩解：如何零停機遷移。

行動（摘要）：我本在做 AI 功能的基礎設施支援時撞上效能問題，於是決定評估單體還造成哪些其他問題。我聯繫業務，得知近期流失四個企業案；分析半年工單，算出資料相關升級消耗 15% 工程產能加上直接客服時間，約每年 40 萬美元的浪費。我帶著數據去說服關係人：工程 VP 因技術限制明顯而容易說服；產品 VP 較難，我證明她 Q3 三個最高優先事項（含她向 CEO 承諾的 AI 功能）沒有這次遷移在技術上就不可能，最終協商出 60/40 產能分配（60% 遷移、40% 功能），並承諾第三個月就解鎖一個優先功能而非讓她等到最後。我把專案設計成每月交付漸進業務價值而非一次性大切換（第 1–2 月遷移匯入管線以支援企業 POC，第 3 月啟用即時處理解鎖產品功能，第 4 月遷移轉換以降低支援負擔，第 5 月遷移匯出以提升效能，第 6 月完成切換）。

技術設計上，我與兩位資深工程師設計了六個微服務（匯入、驗證、轉換、儲存、匯出、監控）。最大爭論在資料一致性：我主張用 Kafka 做 event sourcing，一位資深工程師因 SRE 團隊 Kafka 經驗有限而反對；我提議兩種方案各做 POC，用模擬 5,000 萬筆匯入測試，結果 event sourcing 處理失敗更優雅、也給了我們需要的除錯能力，並安排 SRE 主管接受 Kafka 訓練以化解營運疑慮。舊系統是單一 PostgreSQL、200 多張表，我採「strangler fig」模式讓新服務先讀舊庫、寫自己的庫，再逐步切換讀取，並與 DBA 依外鍵依賴排序遷移，所有資料庫遷移排在半夜並附自動 rollback。

第四個月發現一個 event 排序的細微 bug 導致三個客戶資料損毀，我立即把他們回退到舊系統，除錯一週（問題出在用了應用時間戳而非 Kafka 內部排序），修好後建立對帳流程並親自致電每個受影響客戶道歉，其中兩個升級到工程 VP。我把它轉為改進機會：建 chaos testing 更早抓出競態、加自動完整性檢查在 15 分鐘內告警。上線階段我與客服規劃分層溝通（從內部帳號、技術型客戶、到逐步放大的區隔）。第二層上線時最大客戶回報匯出慢 3 倍、立即升級到高層，我除錯發現新匯出服務為中位數資料量優化、但該客戶量是 10 倍，當天熱修上線把匯出時間降到舊系統的 50%。最終階段我協調產品、SRE、客服，跑 pre-mortem 演練，成功遷移 100% 流量，舊系統觀察 30 天後除役。

結果：系統延遲降數秒，生產事故降 85%，基礎設施成本降 30%，工程速度顯著提升（原本 6 週的功能現在 2–3 週）。業務端隔季成交兩個逾 100 萬美元、原本不可能的企業案，客戶升級降 70%（約省每年 28 萬美元），架構也讓我們推出三個成為關鍵差異化的 AI 功能。

學習：建立關係人對齊和技術執行一樣重要；用業務價值（流失營收、支援成本、被卡的功能）而非技術優雅來框定專案，對取得支持與撞牆時維持支持至關重要；漸進遷移勝過一次性重寫；危機時跨職能關係至關重要——及早讓業務、產品、客服參與所建立的信任，讓資料損毀事件與客戶升級都好處理得多。因這次的範疇與影響，我被升為 Staff 工程師。

學校專案（校園食物銀行 web app）

背景：資深專題，四人團隊為校園食物銀行做一個讓學生找到並預約食物的 web app，取代造成長時間等待與庫存混亂的紙本系統。

行動：我主導需求蒐集，訪談志工與學生，發現單純的庫存顯示無法解決真問題（學生仍會為已被拿走的品項白跑一趟）。我提議用 React + Node.js/PostgreSQL 做預約系統，這與兩位想用 Django 的隊友起了衝突；我建議各花一週做原型比較，結果 React 版即時更新更順、對庫存追蹤很關鍵。我們接著寫了含輕量技術設計的 PRD，我設計資料庫 schema、用 WebSockets 建即時庫存系統、用 Heroku 設部署管線，並整合食物銀行既有的 Google Sheets 流程；多人併發測試出現效能問題時，我優化查詢並加基本快取。

結果：準時交付，員工回報等待更短、庫存更準，學生能看即時供應並提前預約，教授選我們的專案向新生示範。

學習：及早與真實使用者對話能避免做錯東西；技術衝突常靠做原型而非辯論來化解；我發現自己享受在限制下做架構決策的挑戰。

個人故事（社區 block party）

只有在你是初階候選人、且真的找不到工作相關故事時，才選擇講個人故事。

背景：我在公寓社區住了約一年，發現鄰居彼此幾乎不認識，還發生幾次包裹失竊與停車糾紛，我想把大家聚起來或許能自然改善。

行動：我先探詢幾位鄰居的意願，發現大家想連結卻沒人願意帶頭，我雖從沒辦過活動仍自願籌辦。我挨家挨戶了解需求（有孩子的家庭想要兒童活動、其他人只想有機會聊天）。卡在市府路權申請時，我研究替代方案，發現可改用社區交誼廳而非封街。

結果：約 40 位鄰居出席，包含住多年卻從沒見過面的家庭；之後固定每季聚會，包裹失竊問題大致消失，大家開始互相照看公寓、幫忙顧寵物。

學習：多數人想參與社區營造，但需要有人踏出第一步並處理後勤；從小而簡單開始，勝過想一次辦完美的活動。