roadmap-update
更新或重排產品 roadmap，含優先順序框架與產能規劃
中文翻譯
--- name: roadmap-update description: 更新、建立或重新排序你的產品 roadmap。在加入新的 initiative 並決定要挪動什麼來騰出空間、取得新資訊後調整優先順序、因為相依事項延遲而移動時程，或從零開始建立 Now/Next/Later 視圖時使用。 argument-hint: "<update description>" --- # Roadmap Update > 如果看到不認識的 placeholder，或需要確認目前連接了哪些工具，請看 [CONNECTORS.md](../../CONNECTORS.md)。 更新、建立或重新排序產品 roadmap。 ## 用法 ``` /roadmap-update $ARGUMENTS ``` ## 工作流程 ### 1. 了解目前狀態 如果有連接 **~~project tracker**： - 拉出目前的 roadmap 項目，連同它們的狀態、負責人和日期 - 找出逾期、有風險或最近完成的項目 - 挑出任何沒有明確負責人或日期的項目 如果沒有連接專案管理工具： - 請使用者描述目前的 roadmap，或貼上／上傳 - 接受任何格式：清單、表格、試算表、截圖或文字描述 ### 2. 判斷要做哪種操作 問使用者想做什麼： **新增項目**：把新功能、initiative 或工作項目加進 roadmap - 蒐集：名稱、描述、優先順序、預估工作量、目標時間範圍、負責人、相依事項 - 依目前的優先順序和產能，建議它適合放在哪裡 **更新狀態**：改變既有項目的狀態 - 選項：not started、in progress、at risk、blocked、completed、cut - 對於「at risk」或「blocked」：詢問卡關原因和緩解計畫 **重新排序**：改變項目的順序或優先順序 - 問是什麼改變了（新資訊、策略轉向、資源變化、客戶回饋） - 有幫助的話套用優先順序框架：RICE、MoSCoW、ICE 和 value-vs-effort 見下方的 **優先順序框架** - 顯示前後對照 **移動時程**：調整項目的日期 - 問原因（範圍變更、相依事項延遲、資源限制） - 找出對相依項目的下游影響 - 標出會超過硬性期限的項目 **建立新的 roadmap**：從零開始建立 roadmap - 問時間範圍（季、半年、年） - 問格式偏好（Now/Next/Later、季度欄位、對齊 OKR）：見下方的 **Roadmap 框架** - 蒐集要納入的 initiative 清單 ### 3. 產生 Roadmap 摘要 產出一份 roadmap 視圖，包含： #### 狀態總覽 快速摘要：X 個項目進行中、本期完成 Y 個、Z 個有風險。 #### Roadmap 項目 每個項目要顯示： - 名稱和一行描述 - 狀態指標（on track / at risk / blocked / completed / not started） - 目標時間範圍或日期 - 負責人 - 主要相依事項 項目依以下方式分組： - 時間範圍（Now / Next / Later）或季度，依格式而定 - 或者使用者偏好的話，依主題／目標 #### 風險與相依事項 - 被卡住或有風險的項目，附上細節 - 跨團隊的相依事項和它們的狀態 - 接近硬性期限的項目 #### 本次更新的變更 如果這是對既有 roadmap 的更新，摘要說明改了什麼： - 新增、移除或重新排序的項目 - 時程的移動 - 狀態的變化 ### 4. 後續追蹤 產生 roadmap 之後： - 提議針對特定對象調整格式（給主管的摘要、給工程的細節、給客戶看的版本） - 提議起草關於 roadmap 變更的溝通內容 - 如果有連接專案管理工具，提議更新 ticket 狀態 ## Roadmap 框架 ### Now / Next / Later 最簡單、而且常常最有效的 roadmap 格式： - **Now**（目前的 sprint／月）：已承諾的工作。對範圍和時程有高度信心。這些是團隊正在積極開發的東西。 - **Next**（接下來 1 到 3 個月）：已規劃的工作。對做什麼有不錯的信心，對確切什麼時候做信心較低。範圍和優先順序都訂了，但還沒開始。 - **Later**（3 到 6 個月以上）：方向性的。這些是我們打算追求的策略性押注和機會，但範圍和時間都有彈性。 何時使用：大多數團隊、大多數時候。對外溝通或對主管溝通特別好，因為它避免在日期上做出虛假的精準。 ### Quarterly Themes 把 roadmap 圍繞每季 2 到 3 個主題來組織： - 每個主題代表一個策略性的投資領域（例如「Enterprise readiness」、「Activation improvements」、「Platform extensibility」） - 在每個主題下，列出規劃中的具體 initiative - 主題應該對應到公司或團隊的 OKR - 這種格式讓你很容易解釋「為什麼」要做你正在做的東西 何時使用：需要展示策略一致性時。適合規劃會議和對主管的溝通。 ### 對齊 OKR 的 Roadmap 把 roadmap 項目直接對應到 Objective 和 Key Result： - 從該期間團隊的 OKR 開始 - 在每個 Key Result 之下，列出會推動那個指標的 initiative - 包含每個 initiative 預期對 Key Result 的影響 - 這在你做的東西和你衡量的東西之間，建立起明確的課責 何時使用：以 OKR 運作的組織。適合確保每個 initiative 都有明確、連結到可衡量成果的「為什麼」。 ### Timeline / Gantt 視圖 以日曆為基礎、把項目放在時間軸上的視圖： - 顯示開始日期、結束日期和期間 - 視覺化平行與先後順序 - 適合找出資源衝突 - 顯示項目之間的相依關係 何時使用：和工程一起做執行規劃。找出排程衝突。**不**適合對外溝通（會造成虛假精準的期待）。 ## 優先順序框架 ### RICE 分數 針對四個面向替每個 initiative 評分，然後計算 RICE = (Reach x Impact x Confidence) / Effort - **Reach**：在特定時間內，這會影響多少使用者／客戶？用具體數字（例如「每季 500 位使用者」）。 - **Impact**：對每一個被觸及的人，這能推動多少？用量表評分：3 = 巨大、2 = 高、1 = 中、0.5 = 低、0.25 = 極小。 - **Confidence**：我們對 reach 和 impact 估計有多少信心？100% = 高信心（有資料支持）、80% = 中（有一些證據）、50% = 低（憑直覺）。 - **Effort**：需要多少人月的工作？包含工程、設計和任何其他職能。 何時使用：需要量化、站得住腳的優先排序時。適合比較大量的 initiative backlog。不太適合難以估計影響的策略性押注。 ### MoSCoW 把項目分類為 Must have、Should have、Could have、Won't have： - **Must have**：沒有這些，roadmap 就是失敗。不可妥協的承諾。 - **Should have**：重要而且被期待，但沒有它們也能交付。 - **Could have**：想要，但明顯優先順序較低。只有在產能允許時才納入。 - **Won't have**：明確排除在這個期間的範圍之外。為了清楚起見，列出來很重要。 何時使用：界定一個 release 或一個季度的範圍。和利害關係人協商什麼放得進去。適合逼出優先順序的對話。 ### ICE 分數 比 RICE 簡單。針對三個面向，每個項目評 1 到 10 分： - **Impact**：這會推動目標指標多少？ - **Confidence**：我們對影響的估計有多少信心？ - **Ease**：實作有多容易？（工作量的反面，越高 = 越容易） ICE Score = Impact x Confidence x Ease 何時使用：快速替功能 backlog 排優先順序。適合早期產品，或沒有足夠資料做 RICE 時。 ### Value vs Effort 矩陣 把 initiative 畫在 2x2 矩陣上： - **高價值、低工作量**（速贏）：先做這些。 - **高價值、高工作量**（大型押注）：謹慎規劃。值得投資，但需要適當界定範圍。 - **低價值、低工作量**（填空）：有閒置產能時再做。 - **低價值、高工作量**（錢坑）：不要做。從 backlog 移除。 何時使用：團隊規劃會議中的視覺化優先排序。適合建立對取捨的共同理解。 ## 相依事項對應 ### 找出相依事項 在這些類別中尋找相依事項： - **技術相依**：功能 B 需要功能 A 的基礎建設工作 - **團隊相依**：功能需要另一個團隊的工作（設計、平台、資料） - **外部相依**：在等廠商、合作夥伴或第三方整合 - **知識相依**：開始之前需要研究或調查的結果 - **順序相依**：必須先 ship 功能 A 才能開始功能 B（共用程式碼、使用者流程） ### 管理相依事項 - 在 roadmap 裡明確列出所有相依事項 - 為每個相依事項指派負責人（誰負責解決它） - 設定「need by」日期：依賴它的項目最晚什麼時候需要它被解決 - 在相依事項周圍留緩衝：它們是任何 roadmap 上風險最高的項目 - 及早標出跨團隊界線的相依事項：這些需要協調 - 準備備案：如果相依事項延遲了，你要怎麼辦？ ### 降低相依事項 - 你能不能做一個比較簡單的版本，避開這個相依事項？ - 你能不能用介面約定或 mock 來平行進行？ - 你能不能換個順序，把相依事項提前？ - 你能不能把那項工作吸收進你的團隊，省掉跨團隊的協調？ ## 產能規劃 ### 估算產能 - 從工程師人數和時間期間開始 - 扣掉已知的雜務：會議、on-call 輪值、面試、假日、休假 - 常見的經驗法則：工程師花 60 到 70% 的時間在規劃好的功能工作上 - 把新成員的上手時間算進去 ### 分配產能 對大多數產品團隊來說，健康的分配： - **70% 規劃好的功能**：推進策略目標的 roadmap 項目 - **20% 技術健康**：技術債、可靠性、效能、開發者體驗 - **10% 計畫外**：留給緊急問題、速贏和其他團隊請求的緩衝 依團隊情況調整比例： - 新產品：更多功能工作，更少技術債 - 成熟產品：更多技術債和可靠性投資 - 事故之後：更多可靠性，更少功能 - 快速成長：更多可擴展性和效能 ### 產能對上野心 - 如果 roadmap 的承諾超過產能，一定有東西要讓步 - 不要靠假裝人們可以做更多來解決產能問題，要靠砍範圍來解決 - 往 roadmap 加東西時，一定要問：「什麼要拿掉？」 - 承諾少一點、可靠地交付，勝過過度承諾又讓人失望 ## 溝通 Roadmap 的變更 ### 當 Roadmap 改變時 Roadmap 變更的常見觸發： - 來自主管的新策略優先事項 - 改變優先順序的客戶回饋或研究 - 改變估計的技術發現 - 另一個團隊的相依事項延遲 - 資源變化（團隊擴編或縮編、關鍵人物離開） - 需要回應的競爭對手動作 ### 如何溝通變更 1. **承認變更**：直接說明什麼在改變、為什麼 2. **解釋原因**：什麼新資訊促成了這個決定？ 3. **展示取捨**：為了騰出空間，什麼被降低優先順序？或什麼在延後？ 4. **展示新計畫**：反映變更的更新後 roadmap 5. **承認影響**：誰受到影響、怎麼受影響？原本在期待被降低優先順序項目的利害關係人，需要直接聽到。 ### 避免 Roadmap 來回擺盪 - 不要每有一則新資訊就改 roadmap。要有改動的門檻。 - 除非真的緊急，否則在自然的節奏（每月、每季）批次做 roadmap 更新。 - 區分「roadmap 變更」（策略性的重新排序）和「範圍調整」（正常的執行細修）。 - 追蹤 roadmap 改變的頻率。頻繁的改變可能代表策略不清楚，而不是反應快。 ## 輸出格式 使用清楚、方便掃讀的格式。表格很適合 roadmap 項目。使用文字狀態標籤：**Done**、**On Track**、**At Risk**、**Blocked**、**Not Started**。 ## 小提醒 - Roadmap 是溝通工具，不是專案計畫。保持在正確的高度：主題和成果，不是任務。 - 重新排序時，一定要問是什麼改變了。優先順序的轉變應該由新資訊驅動，不是一時興起。 - 及早標出產能問題。如果 roadmap 的工作量超過團隊能處理的，就直說。 - 相依事項是 roadmap 最大的風險。要明確地浮現出來。 - 如果使用者要求加東西，一定要問什麼要拿掉或移動。Roadmap 相對於產能是零和的。
英文原文
--- name: roadmap-update description: Update, create, or reprioritize your product roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from scratch. argument-hint: "<update description>" --- # Roadmap Update > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Update, create, or reprioritize a product roadmap. ## Usage ``` /roadmap-update $ARGUMENTS ``` ## Workflow ### 1. Understand Current State If **~~project tracker** is connected: - Pull current roadmap items with their statuses, assignees, and dates - Identify items that are overdue, at risk, or recently completed - Surface any items without clear owners or dates If no project management tool is connected: - Ask the user to describe their current roadmap or paste/upload it - Accept any format: list, table, spreadsheet, screenshot, or prose description ### 2. Determine the Operation Ask what the user wants to do: **Add item**: New feature, initiative, or work item to the roadmap - Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies - Suggest where it fits based on current priorities and capacity **Update status**: Change status of existing items - Options: not started, in progress, at risk, blocked, completed, cut - For "at risk" or "blocked": ask for the blocker and mitigation plan **Reprioritize**: Change the order or priority of items - Ask what changed (new information, strategy shift, resource change, customer feedback) - Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort - Show before/after comparison **Move timeline**: Shift dates for items - Ask why (scope change, dependency slip, resource constraint) - Identify downstream impacts on dependent items - Flag items that move past hard deadlines **Create new roadmap**: Build a roadmap from scratch - Ask about timeframe (quarter, half, year) - Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below - Gather the list of initiatives to include ### 3. Generate Roadmap Summary Produce a roadmap view with: #### Status Overview Quick summary: X items in progress, Y completed this period, Z at risk. #### Roadmap Items For each item, show: - Name and one-line description - Status indicator (on track / at risk / blocked / completed / not started) - Target timeframe or date - Owner - Key dependencies Group items by: - Timeframe (Now / Next / Later) or quarter, depending on format - Or by theme/goal if the user prefers #### Risks and Dependencies - Items that are blocked or at risk, with details - Cross-team dependencies and their status - Items approaching hard deadlines #### Changes This Update If this is an update to an existing roadmap, summarize what changed: - Items added, removed, or reprioritized - Timeline shifts - Status changes ### 4. Follow Up After generating the roadmap: - Offer to format for a specific audience (executive summary, engineering detail, customer-facing) - Offer to draft communication about roadmap changes - If project management tool is connected, offer to update ticket statuses ## Roadmap Frameworks ### Now / Next / Later The simplest and often most effective roadmap format: - **Now** (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building. - **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started. - **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible. When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates. ### Quarterly Themes Organize the roadmap around 2-3 themes per quarter: - Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility") - Under each theme, list the specific initiatives planned - Themes should map to company or team OKRs - This format makes it easy to explain WHY you are building what you are building When to use: When you need to show strategic alignment. Good for planning meetings and executive communication. ### OKR-Aligned Roadmap Map roadmap items directly to Objectives and Key Results: - Start with the team's OKRs for the period - Under each Key Result, list the initiatives that will move that metric - Include the expected impact of each initiative on the Key Result - This creates clear accountability between what you build and what you measure When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes. ### Timeline / Gantt View Calendar-based view with items on a timeline: - Shows start dates, end dates, and durations - Visualizes parallelism and sequencing - Good for identifying resource conflicts - Shows dependencies between items When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations). ## Prioritization Frameworks ### RICE Score Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort - **Reach**: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter"). - **Impact**: How much will this move the needle for each person reached? Score on a scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal. - **Confidence**: How confident are we in the reach and impact estimates? 100% = high confidence (backed by data), 80% = medium (some evidence), 50% = low (gut feel). - **Effort**: How many person-months of work? Include engineering, design, and any other functions. When to use: When you need a quantitative, defensible prioritization. Good for comparing a large backlog of initiatives. Less good for strategic bets where impact is hard to estimate. ### MoSCoW Categorize items into Must have, Should have, Could have, Won't have: - **Must have**: The roadmap is a failure without these. Non-negotiable commitments. - **Should have**: Important and expected, but delivery is viable without them. - **Could have**: Desirable but clearly lower priority. Include only if capacity allows. - **Won't have**: Explicitly out of scope for this period. Important to list for clarity. When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations. ### ICE Score Simpler than RICE. Score each item 1-10 on three dimensions: - **Impact**: How much will this move the target metric? - **Confidence**: How confident are we in the impact estimate? - **Ease**: How easy is this to implement? (Inverse of effort — higher = easier) ICE Score = Impact x Confidence x Ease When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE. ### Value vs Effort Matrix Plot initiatives on a 2x2 matrix: - **High value, Low effort** (Quick wins): Do these first. - **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping. - **Low value, Low effort** (Fill-ins): Do these when you have spare capacity. - **Low value, High effort** (Money pits): Do not do these. Remove from the backlog. When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs. ## Dependency Mapping ### Identifying Dependencies Look for dependencies across these categories: - **Technical dependencies**: Feature B requires infrastructure work from Feature A - **Team dependencies**: Feature requires work from another team (design, platform, data) - **External dependencies**: Waiting on a vendor, partner, or third-party integration - **Knowledge dependencies**: Need research or investigation results before starting - **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow) ### Managing Dependencies - List all dependencies explicitly in the roadmap - Assign an owner to each dependency (who is responsible for resolving it) - Set a "need by" date: when does the depending item need this resolved - Build buffer around dependencies — they are the highest-risk items on any roadmap - Flag dependencies that cross team boundaries early — these require coordination - Have a contingency plan: what do you do if the dependency slips? ### Reducing Dependencies - Can you build a simpler version that avoids the dependency? - Can you parallelize by using an interface contract or mock? - Can you sequence differently to move the dependency earlier? - Can you absorb the work into your team to remove the cross-team coordination? ## Capacity Planning ### Estimating Capacity - Start with the number of engineers and the time period - Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO - A common rule of thumb: engineers spend 60-70% of time on planned feature work - Factor in team ramp time for new members ### Allocating Capacity A healthy allocation for most product teams: - **70% planned features**: Roadmap items that advance strategic goals - **20% technical health**: Tech debt, reliability, performance, developer experience - **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams Adjust ratios based on team context: - New product: more feature work, less tech debt - Mature product: more tech debt and reliability investment - Post-incident: more reliability, less features - Rapid growth: more scalability and performance ### Capacity vs Ambition - If roadmap commitments exceed capacity, something must give - Do not solve capacity problems by pretending people can do more — solve by cutting scope - When adding to the roadmap, always ask: "What comes off?" - Better to commit to fewer things and deliver reliably than to overcommit and disappoint ## Communicating Roadmap Changes ### When the Roadmap Changes Common triggers for roadmap changes: - New strategic priority from leadership - Customer feedback or research that changes priorities - Technical discovery that changes estimates - Dependency slip from another team - Resource change (team grows or shrinks, key person leaves) - Competitive move that requires response ### How to Communicate Changes 1. **Acknowledge the change**: Be direct about what is changing and why 2. **Explain the reason**: What new information drove this decision? 3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping? 4. **Show the new plan**: Updated roadmap with the changes reflected 5. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly. ### Avoiding Roadmap Whiplash - Do not change the roadmap for every piece of new information. Have a threshold for change. - Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent. - Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement). - Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness. ## Output Format Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**. ## Tips - A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks. - When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim. - Flag capacity issues early. If the roadmap has more work than the team can handle, say so. - Dependencies are the biggest risk to roadmaps. Surface them explicitly. - If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.