第一章 多租户场景与RICE方法概论
1.1 适用场景
RICE排序方法在多租户场景中，适用于以下典型情况：
- 多个租户同时提出多个需求，需要统一评估优先级
- 平台级功能与租户定制功能之间出现资源抢占
- 一个租户的紧急需求与其他租户的长期需求冲突
- 从零开始构建多租户平台，需要确定首批功能集合
- 存量系统进行租户隔离改造时的功能排序
关键词： 排期冲突、资源受限、多维度权衡、公平性、透明决策。
1.2 前置条件
在开始RICE排序之前，必须完成以下准备工作：
- 已确认所有待排序需求均录入统一需求池（输入物1）
- 每个需求已至少包含租户影响范围、预计收益估算、开发工作量初评、信心度评级四项元数据
- 已确定至少3位评审人（产品负责人、技术负责人、租户代表）
- 评审团队已完成RICE方法的简短培训（约30分钟）
- 已准备好打分工具（支持多人同时打分电子表格或轻量协作工具）
常见陷阱： 前置条件不满足时强行排序，容易导致RICE分数无法对齐、评审过程反复返工。至少保证第2、3条具备，否则应推迟排序会议。
1.3 RICE方法定义与多租户特殊性
RICE是四个维度的首字母缩写：
- R - Reach（覆盖度） 在单租户体系中通常指用户数量；在多租户中必须调整为受影响的租户数量或受影响租户内活跃用户数，建议同时记录，最终按统一规则（如租户数×租户权重）折算
- I - Impact（影响力） 对每个租户业务价值的提升程度（1~5级），多租户中需考虑租户间公平性，一个只对少数租户影响巨大的功能，与对大多数租户影响中等的功能需要谨慎对比
- C - Confidence（信心度） 团队对Reach、Impact估算的信任程度（0%~100%），多租户下信心度往往更低，因为难以准确预测每个租户的实际采用率
- E - Effort（工作量） 实现该功能所需的人天或故事点，多租户中还应考虑租户隔离验证成本和回归测试范围的扩大
| 维度 | 单租户定义 | 多租户特殊调整 | 示意分值范围 |
|---|---|---|---|
| Reach | 活跃用户数量 | 受影响租户数 × 租户权重（可按付费金额、用户数、战略重要性计算） | 0~1000 |
| Impact | 对单一业务的提升程度 | 分租户类型取加权平均（参考1-5级） |
1~5 |
| Confidence | 团队对估算的把握 | 需考虑数据缺陷：若某租户数据样本不足，置信度自动降低 | 0%~100% |
| Effort | 纯开发工作量 | + 租户隔离验证 + 配置化测试 + 多环境部署适配 | 1~20人天 |
经验法则： 多租户RICE公式建议改为
R × I × C / (E × T)，其中T为租户额外验证因子（一般1.0~1.5），但本课程为保持方法通用性，先使用标准公式，在第5章专门讨论因子调整。
1.4 操作步骤
- 收集需求元数据： 为每个需求填写R、I、C、E四个字段的初评值（输入物2：需求元数据矩阵）
- 组建评审小组： 至少包含产品经理（负责R/I）、技术负责人（负责E）、租户运营代表（负责R/I实际验证）
- 进行第一轮独立打分： 每人独立填写需求元数据，不互相讨论
- 讨论差异点： 对评分差距超过阈值（如I值差≥2或C值差≥30%）的需求进行集中讨论
- 达成一致性： 调整评分后，使用公式
R * I * C / E计算每个需求的RICE分数 - 生成排序： 按分数从高到低排列，得到初始优先级队列（输出物1：RICE排序表）
关键产出： 第一章交付物——RICE排序初始表（含各维度分值）、评审会议纪要、评分差异分析报告。
1.5 输入输出物
| 类型 | 名称 | 格式/内容要求 | 责任方 |
|---|---|---|---|
| 输入物1 | 统一需求池 | Excel或协作列表，每条需求至少含编号、标题、租户范围、预期收益描述 | 产品经理 |
| 输入物2 | 需求元数据矩阵 | 包含R/I/C/E初评，建议用<pre><code>CSV或共享表格 |
产品经理+技术负责人 |
| 输出物1 | RICE排序表 | 排序后列表，含最终分数和决策说明 | 产品负责人（评审后确认） |
| 记录材料 | 评分差异分析报告 | 讨论记录，差异点截图，最终一致化结果 | QA或PMO |
1.6 责任边界
- 产品经理： 负责Reach、Impact的初评准确性，并解释每个需求对哪些租户产生何种影响
- 技术负责人： 负责Effort估算，并标注租户隔离复杂性（如共享数据模型变更需额外加工作量）
- 租户运营代表： 对实际租户覆盖面、使用习惯提供验证，修正Reach和信心度
- 评审主持人（通常由产品负责人担任）： 控制讨论时间，确保每个需求至少被3人评审，最终签字确认排序结果
责任盲区： 如果没有明确的租户运营代表，则Reach和C维度容易主观偏离。建议在小型多租户场景中至少让客服或客户成功经理参与打分。
1.7 异常处理
| 异常场景 | 处理方式 | 责任方 |
|---|---|---|
| 两个需求RICE分数相同 | 采用次级指标排序：优先选择C更高的需求，其次选择Impact更平均的需求 | 评审小组 |
| 评审小组成员缺席超过1人 | 推迟评审，或者缺席者预先填写电子版评分问卷（不参与差异讨论） | 主持人 |
| 某个需求无信心度（C=0） | 不直接移除，而是标记为“待验证”，加入待办列表，要求产品经理在下次迭代前补充数据 | 产品经理 |
| 租户代表提出“某个功能对所有租户都重要但R值低” | 检查Reach的统计口径：可能遗漏了“用户数”而非“租户数”，或需要引入租户权重重新核算 | 产品经理+运营代表 |
1.8 验收标准
完成本章内容后，应达到以下状态：
- 团队能准确背诵RICE定义及其在多租户下的特殊含义
- 已为至少5个待处理需求完成元数据填写，并生成第一版RICE排序表
- 评审会议记录完整，差异分析报告已归档到项目共享空间
- 所有参与成员理解RICE分数只是决策参考，不能机械套用，需结合业务战略和租户关系
1.9 记录材料归档要求
- 必存： 评审会议录音/录屏、邮件确认截图、打分原始数据（CSV/Excel）
- 归档周期： 每个季度复查一次，如有需求重新排序则追加新版本
- 命名规范：
YYYY-MM-DD_多租户RICE排序_v1.xlsx
本章小结： 多租户RICE不是把单租户方法简单复制，而是在四个维度中融入了“租户视角”的修正。掌握了本章的适用场景、前置条件和操作步骤，即可进入第二章节——RICE各维度量化细则（第二章）。