深入了解誰使用 TaskFlow 以及為什麼
概覽
TaskFlow 服務三個主要使用者角色。了解這些角色對產品決策至關重要 - 每個功能都應該至少服務一個角色的核心需求。
角色 1：Sarah（企業管理員）
快速資訊
姓名： Sarah Chen 年齡： 38 角色： IT 營運副總裁 公司： TechCorp（800 名員工，Series C） 地點： 德州奧斯汀（遠端團隊遍布美國） TaskFlow 方案： 企業版
背景
Sarah 領導一家快速成長的 SaaS 公司的 IT 營運。她的團隊支援 800 名員工使用 15 種工具。她向 CTO 報告並負責 IT 預算（每年 $2M）。
職涯路徑：
- 從 IT 支援專員開始
- 成長為 IT 經理
- 現在是 IT 營運副總裁（6 位直屬部屬）
- 在 IT 領域 12 年，在目前公司 8 年
教育背景：
- 資訊系統學士
- CISSP 認證（安全性）
目標與動機
主要目標：
- 減少工具蔓延 - 目前使用 25+ 種工具，希望整合到 10-12 種
- 改善安全態勢 - 通過 SOC 2 稽核，滿足企業客戶要求
- 控制成本 - $2M 預算，需要展示每個工具的 ROI
- 賦能團隊 - 在不妥協安全性的情況下為員工提供好工具
成功指標：
- 使用中的工具數量（減少）
- 安全事件（零）
- 員工對工具的滿意度（提升）
- 每位員工的工具成本（降低）
痛點與挫折
1. 工具蔓延失控
- 工程團隊使用 Linear
- 行銷團隊使用 Monday.com
- 業務團隊使用 Salesforce + Asana
- 設計團隊使用 Notion
- 沒有集中的地方可以看到正在發生的事情
2. 安全性噩夢
- 影子 IT（團隊未經批准購買工具）
- 無法看到誰有權存取什麼
- 前員工仍然可以存取工具
- 被要求時無法提供稽核日誌
3. 引導/離職混亂
- 新員工？需要手動建立 25 個帳號
- 有人離職？需要撤銷 25 個存取權
- 完全配置一個人需要 2 天
4. 無可見性
- 看不到團隊在做什麼
- 無法向高層報告
- 無法預測資源需求
待完成工作
當…
- …新員工加入 → 在一個地方自動配置所有工具存取權
- …有人離職 → 立即且有信心地撤銷所有存取權
- …稽核人員要求日誌 → 提供全面的稽核軌跡而不必手忙腳亂
- …評估新工具 → 在購買前確保它們符合安全標準
- …CFO 詢問工具成本 → 展示每個工具的 ROI 和使用指標
- …發生安全事件 → 識別存取範圍並立即撤銷
他們關心的 TaskFlow 功能
必備功能：
- ✅ SSO（單一登入）透過 SAML - 不可妥協
- ✅ 稽核日誌 - 誰做了什麼、何時、為什麼
- ✅ 進階權限 - 基於角色的存取控制
- ✅ 批次使用者管理 - 一次新增/移除多位使用者
- ✅ 管理儀表板 - 組織級可見性
加分功能：
- 自訂使用者欄位（部門、地點、成本中心）
- 使用分析（誰在使用、誰沒在使用）
- 資料匯出（擁有你的資料）
- 99.9% 正常運行時間 SLA
不關心：
- 花俏的 UI 動畫
- 社交功能
- 公開看板
- 行動應用程式（以桌面為主的角色）
行為與偏好
工作方式：
- 深度專注：專注工作的時段（無持續干擾）
- 溝通：電子郵件 > Slack（偏好非同步）
- 決策制定：資料驅動、規避風險
- 工具：喜歡儀表板、報表、分析
技術精通度： 高
- 熟悉技術概念
- 閱讀安全白皮書
- 嚴格評估工具
採購流程：
- 進行廣泛研究（數週）
- 需要安全審查
- 需要法務審查合約
- 在全面推出前先用 50 位使用者試點
- 典型銷售週期：3-6 個月
引言
「我需要一個地方可以看到誰有權存取什麼，並在需要時立即撤銷。」
「安全性不可妥協。如果你沒有 SSO 和稽核日誌，我們甚至無法考慮你。」
「我厭倦了成為每個工具評估的瓶頸。我需要能正常運作並符合我們標準的工具。」
「當員工離職時，我會失眠，擔心我們是否已撤銷他們所有的存取權。這不應該這麼困難。」
角色 2：Mike（個人貢獻者工程師）
快速資訊
姓名： Mike Rodriguez 年齡： 29 角色： 資深軟體工程師 公司： GrowthLabs（150 名員工，Series B） 地點： 俄勒岡州波特蘭（完全遠端） TaskFlow 方案： Pro（全公司使用）
背景
Mike 是一位專注於後端系統的資深工程師。他每天編碼 6-8 小時，每週參加 2-3 次會議，與跨 4 個時區的分散式團隊合作。
職涯路徑：
- 程式訓練營畢業生（2018）
- 初級 → 中級 → 資深工程師（5 年）
- 專精於 Node.js、PostgreSQL、AWS
教育背景：
- 程式訓練營（Hack Reactor）
- 自學（訓練營之前）
目標與動機
主要目標：
- 深度工作 - 長時間、不受干擾的專注時間來解決複雜問題
- 明確優先順序 - 確切知道要做什麼，無需猜測
- 最小化情境切換 - 更少的工具、更少的跳轉
- 交付高品質程式碼 - 對工藝的自豪
成功指標：
- 每個 sprint 交付的功能
- 錯誤數量（低）
- 程式碼審查周轉時間（快）
- 專注時間（每天 6+ 小時）
痛點與挫折
1. 優先順序混亂
- 多個真相來源（Slack、電子郵件、站立會議、任務工具）
- 來自不同利害關係人的衝突優先順序
- 不清楚「緊急」實際意味著什麼
- 浪費時間詢問「我應該做什麼？」
2. 情境不足
- 任務標題：「修復登入錯誤」（哪個錯誤？在哪裡？為什麼？）
- 需求中缺乏技術細節
- 產品規格缺少邊緣案例
- 必須尋找背景資訊
3. 會議過載
- 站立會議可以非同步進行
- 狀態更新打斷專注
- 會議安排在高峰專注時間
- 時區使排程更糟
4. 緩慢、臃腫的工具
- 頁面載入時間 > 3 秒
- 沉重、延遲的介面
- 做簡單的事情需要太多點擊
- 行動網頁無法使用
待完成工作
當…
- …開始工作 → 立即看到最高優先順序的任務，包含完整情境
- …被某事阻擋 → 無需安排會議即可溝通阻礙
- …完成任務 → 無需詢問即可知道下一步是什麼
- …審查 PR → 無需離開 GitHub 即可看到連結的任務情境
- …規劃容量 → 看到即將到來的工作並估算工作量
他們關心的 TaskFlow 功能
必備功能：
- ✅ 鍵盤快捷鍵 - 無需滑鼠導航（Cmd+K、j/k 導航）
- ✅ 快速效能 - 次秒級頁面載入、無旋轉圖示
- ✅ GitHub 整合 - PR 連結到任務、自動狀態更新
- ✅ 豐富的 markdown - 程式碼區塊、語法高亮
- ✅ 任務上的情境 - 清楚的「為什麼」，而不只是「什麼」
加分功能：
- 深色模式（深夜編碼）
- 離線模式（在飛機上工作）
- API 存取（自動化）
- CLI 工具
不關心：
- 視覺化專案看板（偏好清單檢視）
- 圖表和圖形
- 社交功能
- 視訊通話
行為與偏好
工作方式：
- 深度專注：2-3 小時不受干擾的編碼時段
- 溝通：非同步 > 即時（專注時關閉 Slack）
- 決策制定：技術優點、效率
- 工具：鍵盤 > 滑鼠、CLI > GUI
技術精通度： 非常高
- 開發者工具的高級使用者
- 撰寫腳本來自動化工作流程
- 客製化所有東西
工作時間：
- 彈性（遠端）
- 高峰生產力：早上（6am-12pm）
- 中午前避免會議
- 如果早些時候被阻擋，經常在晚上工作
引言
「只要告訴我要建構什麼，給我情境，然後讓我編碼。不要讓我尋找資訊或坐在會議中。」
「如果你的工具很慢，我不會使用它。我會找到更快的替代方案或自己建構。」
「我需要所有東西都有鍵盤快捷鍵。如果我必須使用滑鼠，我已經很煩了。」
「最好的站立會議是不發生的會議。只要讓我非同步閱讀更新。」
角色 3：Alex（團隊主管）
快速資訊
姓名： Alex Rivera 年齡： 35 角色： 工程經理 公司： DataFlow（200 名員工，Series B） 地點： 加州舊金山（遠端團隊橫跨 5 個時區） TaskFlow 方案： Pro 團隊規模： 8 位工程師（3 位資深、5 位中級）
背景
Alex 管理一個分散式工程團隊。前資深工程師，2 年前晉升為經理。仍然偶爾編碼（約 20% 時間），但主要專注於團隊生產力、招聘和交付。
職涯路徑：
- 工程師（5 年）
- 技術主管（2 年）
- 工程經理（2 年）
- 目標：工程總監
教育背景：
- 電腦科學學士
- MBA（夜間課程，進行中）
目標與動機
主要目標：
- 團隊成功 - 團隊準時交付、有品質、無倦怠
- 清楚可見性 - 無需詢問即可知道狀態、及早識別阻礙
- 平衡工作負載 - 無人過載、無人利用不足
- 職涯成長 - 培養團隊成員、招聘 A 級人才、成長為總監
成功指標：
- Sprint 速度（一致、可預測）
- 團隊幸福感（留存、參與）
- 準時交付率
- 程式碼品質（低錯誤率）
痛點與挫折
1. 無需詢問就無可見性
- 必須詢問團隊成員：「你的狀態是什麼？」
- 站立會議是狀態更新（應該是非同步的）
- 等到阻礙浮現時，它們已經很嚴重了
- 在為時已晚之前看不到工作負載平衡
2. 持續情境切換
- 檢查 5 種工具來了解狀態
- GitHub（程式碼）、TaskFlow（任務）、Slack（溝通）、Figma（設計）、Notion（文件）
- 難以獲得全局
- 浪費時間彙總資訊
3. 向上報告很痛苦
- 領導層問：「我們在正軌上嗎？」
- 需要 2 小時來收集資料並建立更新
- 等我報告時，資料已經過時
- 應該自動化的手動工作
4. 團隊平衡問題
- 一些工程師過載（晚上工作）
- 其他人利用不足（等待任務）
- 難以一目了然地看到容量
- 任務分配是猜測
待完成工作
當…
- …規劃 sprint → 查看團隊容量、公平分配工作
- …有人被阻擋 → 無需每日站立會議即可識別阻礙
- …向領導層報告 → 清楚快速地展示團隊進度
- …與工程師 1:1 → 在情境中查看他們的工作、提供回饋
- …出現招聘需求 → 向領導層展示我們已達容量（需要人力）
他們關心的 TaskFlow 功能
必備功能：
- ✅ 團隊儀表板 - 一目了然的每個人任務
- ✅ 工作負載檢視 - 誰過載、誰有容量
- ✅ 被阻擋任務可見性 - 紅旗、緊急關注
- ✅ Sprint 報表 - 速度、燃盡圖、可預測性
- ✅ 評論摘要 - 無需閱讀所有內容即可了解討論
加分功能：
- 預測分析（「團隊將以目前速度延遲 2 天完成」）
- 歷史速度（比較 sprint）
- 個人績效追蹤（用於審查）
- 與日曆整合（查看誰休假、誰有空）
不關心：
- 細緻的任務細節（信任團隊處理）
- 花俏的動畫
- 社交功能
行為與偏好
工作方式：
- 管理時間：會議、1:1、規劃（50%）
- 編碼時間：偶爾的 IC 工作（20%）
- 策略時間：招聘、路線圖、團隊發展（30%）
- 溝通：同步（1:1）與非同步（更新）的混合
技術精通度： 高
- 前工程師（了解技術細節）
- 熟悉資料和分析
- 欣賞自動化
工作時間：
- 彈性（遠端）
- 會議：9am-5pm
- 編碼：清晨或深夜（無干擾）
- 可用性：跨時區（一些深夜通話）
引言
「我需要知道我的團隊是否在正軌上，而不必每天單獨詢問他們。這無法擴展。」
「當我整天都在連續會議中時，我需要在 5 分鐘內了解團隊進度，而不是 2 小時。」
「我信任我的團隊，但我需要可見性。如果有人被阻擋而我不知道，那是我的責任。」
「向上報告不應該是手動過程。資料就在那裡 - 只要以我可以分享的格式顯示給我。」
角色比較矩陣
| 屬性 | Sarah（企業管理員） | Mike（IC 工程師） | Alex（團隊主管） |
|---|---|---|---|
| 主要目標 | 安全性與合規性 | 深度工作與交付程式碼 | 團隊生產力與交付 |
| 成功指標 | 零安全事件 | 交付的功能 | Sprint 速度 |
| 關鍵痛點 | 工具蔓延、無可見性 | 情境切換、不明確優先順序 | 無團隊可見性 |
| 溝通風格 | 電子郵件、正式 | 非同步、最小化 | 同步/非同步混合 |
| 技術精通度 | 高（IT 背景） | 非常高（工程師） | 高（前工程師） |
| 決策制定 | 規避風險、資料驅動 | 效率優先 | 團隊優先、資料導向 |
| TaskFlow 優先事項 | SSO、稽核日誌、權限 | 速度、鍵盤快捷鍵、GitHub | 儀表板、工作負載檢視、報表 |
| 採購影響力 | 最終決策（預算擁有者） | 推薦者（影響選擇） | 影響者（需要成功） |
角色如何影響產品決策
範例：深色模式功能
Sarah 的觀點：
- 不關心（以桌面為主的角色、正常工作時間）
- 不是阻礙，但也不是驅動因素
Mike 的觀點：
- 非常喜歡（深夜編碼、減少眼睛疲勞）
- 會因為這個功能積極倡導 TaskFlow
- 與競爭對手的差異化因素
Alex 的觀點：
- 加分功能（一些工程師工作到很晚）
- 對團隊成功不是關鍵
- 會讓團隊開心
決策： 推出深色模式
- 對 Mike 角色高價值（留存 + 倡導）
- 建構成本低
- 向市場發出正面信號（現代工具）
範例：進階權限
Sarah 的觀點：
- 必備功能（沒有這個無法購買）
- 企業交易的阻礙
- 願意支付溢價
Mike 的觀點：
- 不關心（不是他們的工作）
- 只要不減慢工具速度
Alex 的觀點：
- 有用（控制團隊看到什麼）
- 不是關鍵
決策： 推出進階權限
- 企業市場的阻礙（高營收）
- 基本功能
- 向上市場擴張所需
角色驅動的路線圖優先順序
2025 Q1 優先事項：
-
行動應用程式 → 所有角色受益
- Sarah：團隊在外出時使用行動裝置
- Mike：通勤時審查任務
- Alex：旅行時檢查團隊狀態
-
SSO 與企業功能 → Sarah 的阻礙
- 對企業市場至關重要
- 高營收影響
- 競爭要求
-
啟動改進 → Mike 的第一次體驗
- 更快的價值實現時間
- 更好的引導
- 減少流失
-
深色模式 → Mike 的愉悅因素
- 高度要求
- 差異化
- 工程團隊士氣
在整個課程中撰寫 PRD、規劃功能和做產品決策時使用這些角色。每個決策都應該考慮：「這如何服務我們的角色？」