第2章：看板目标与受众——角色、场景与诉求
在动手拖拽任何图表组件之前，我们必须回答一个根本性问题：这个看板为谁而建，解决什么决策问题？很多看板项目失败，并非因为技术实现难度高，而是因为目标与受众模糊——不清楚给谁用、解决什么场景、满足什么分析诉求。本章将系统梳理这四个层次，确保后续可视化设计不偏航。
📐 指标定义先行： 在确定受众之前，你至少需要明确 RICE 四个核心指标（Reach, Impact, Confidence, Effort）的业务含义。例如，“Impact”是衡量用户满意度提升，还是衡量 revenue 增长？口径不一致，后续所有分析诉求都无法得到满足。本章假定你对 RICE 各维度已有基本认知，具体数据口径将在第3章展开。
2.1 看板使用角色 (Who)
不同角色对 RICE 评分的关注视角截然不同。一份好的看板应该为不同角色提供“千人千面”的数据视图，或在同一页面中清晰地划分信息层级。
| 角色 | 核心关注点 | 典型看板交互 |
|---|---|---|
| 产品经理 (PM) | 功能优先级排序、资源分配合理性 | 频繁排序、筛选、调整 RICE 参数做假设分析 |
| 项目负责人 (PO) | 项目进度、团队工作负载、依赖管理 | 查看状态分类堆积图、导出数据做资源规划 |
| 设计师 / 工程师 | 具体功能的评分准确性、技术可行性 | 下钻到单功能明细卡，检视各维度得分来源 |
| 高管 / 决策者 | 项目组合 ROI、战略对齐度 | 查看汇总 KPI 卡片、项目组合健康度概览 |
🚨 常见陷阱： 试图构建一个“万能”看板，试图满足所有人的所有需求，结果往往是谁都不满意。在启动看板项目之前，必须明确界定前3位核心受众及其刚需场景。可以先从 PM 视角切入，后续再迭代扩展。
2.2 决策场景 (When)
分析诉求总是在特定的决策场景中被激活。脱离场景谈看板设计，容易做成“数据花瓶”。
- 每周优先计划会议（高频）： 需要快速比对功能想法，输出本周要推进的 Top 3 事项。看板此时应提供极速排序与临时参数调整能力。
- 迭代/发布规划（中频）： 评估团队容量能否覆盖高优先级需求。看板需提供工作负载分析及状态分类视图。
- 季度业务复盘（QBR）（低频）： 审视项目组合健康度，调整战略方向。此时需要趋势对比与跨项目组合评分概览。
- 项目复盘 / 后评估（异步）： 回顾 RICE 评分预测的准确性，校准打分尺度。需要单功能影像链及评分偏差分析。
💡 调研技巧： 在访谈干系人时，使用“用户故事”框架来精准捕捉诉求。
“作为 产品经理，我希望 看到按 RICE 总分排序的功能列表，以便我在 每周优先级会议上能做出客观决策。”
这直接决定了看板上应该放什么组件（排名表）、以及该组件的交互方式（支持排序）。
“作为 产品经理，我希望 看到按 RICE 总分排序的功能列表，以便我在 每周优先级会议上能做出客观决策。”
这直接决定了看板上应该放什么组件（排名表）、以及该组件的交互方式（支持排序）。
2.3 分析诉求 (Why)
分析诉求是连接“决策场景”与“交付物”的桥梁。常见的分析诉求可归纳为以下几类：
- 数据信任： “评分数据来源可靠吗？口径是否一致？” 这要求看板具备数据血缘说明与更新日志。
- 客观排名： “综合评分最高的功能是哪个？” 需要 RICE 总分排名表，支持按各维度得分排序。
- 假设分析： “如果我们将 Confidence 得分调低一级，排名会如何变化？” 看板组件需支持 实时参数调整 或 并列对比。
- 维度拆解： “为什么这个功能的 Reach 得分这么高？影响范围具体是什么？” 需要 明细下钻 与 评论备注 功能。
- 管线健康度： “我们是否积压了太多‘高努力、低影响’的项目？” 需要 散点图（努力值 vs 影响力） 来识别“低垂果实”和“资源黑洞”。
【干系人访谈脚本框架】
1. 自我介绍：__________
2. 业务背景：__________
3. 核心目标：您每周需要做的最重要的决策是什么？
4. 分析诉求：您目前获取数据支持最痛苦的点是什么？
5. 期望结果：如果看板只能做一件事，您希望是什么？
2.4 输出交付物清单 (What)
基于前3节的分析，我们可以定义看板必须包含的交付物。这些交付物将直接指导后续的看板结构设计。
| 分析诉求 | 交付物组件 | 组件类型 | 建议看板位置 |
|---|---|---|---|
| 查看评分排名 | RICE 总分排名表（支持多维排序） | 表格 | 看板顶部 / 左侧 |
| 识别“低垂果实” | 影响力 vs 努力值散点图 | 图表 | 看板中部 |
| 透视项目管线 | 待办/进行中/已完成堆积柱状图 | 图表 | 看板右侧 |
| 数据溯源与复查 | 单功能 RICE 得分明细卡（弹窗） | 卡片 / 弹窗 | 点击排名表行时触发 |
| 假设分析 / 即时调整 | 参数调节滑块（Impact 权重等） | 交互组件 | 看板过滤区 |
🔍 维度拆解思路： 分析诉求驱动维度的选择。如果高管想看项目组合健康度，你需要按“项目”或“产品线”维度拆解；如果 PM 想看团队工作负载，你需要按“负责人”或“团队”维度拆解。维度拆解颗粒度直接决定看板的实用价值。
2.5 本章小结：从目标到看板结构的映射
截至本章结束，你已经完成了看板搭建前最关键的调研阶段。记住以下三条原则，它将帮你避开80%的返工坑：
- 受众决定视角： 不同角色看同一指标，理解可能完全不同。设计时必须在看板标题、提示文字中明确语境。
- 场景驱动交互： 周