1. 认识AI功能优先级划分的价值
AI功能优先级划分是产品团队在资源有限、需求爆炸的环境下，将功能请求按照业务影响、技术成本、战略对齐度进行排序的系统化决策过程。本章建立优先级划分的底层认知框架，明确其解决的核心矛盾、适用边界和常见陷阱，为后续章节的实操方法奠定基础。
1.1 适用场景
优先级划分并非所有场景都需要，以下四类典型场景必须启动正式划分流程：
- 版本规划周期开启：每季度/每月版本启动时，功能需求池超过当前产能3倍以上。
- 资源冲突僵局：多个业务方同时要求上线各自功能，且无法通过简单协商达成一致。
- 战略方向调整：公司年度目标或市场策略发生重大变化，需要重新对齐功能投资方向。
- AI模型能力边界评估：新AI能力（如多模态、Agent）引入时，需要判断哪些功能值得优先接入。
判断信号：当团队连续两次出现“所有需求都是P0”或“上线后核心指标未改善”时，说明优先级划分机制已缺失。
1.2 前置条件
开始优先级划分前，必须完成以下三项准备：
- 功能需求池已结构化归档：每个功能至少包含描述、预期收益、估算人天、关联方、状态标签。
- 核心决策角色已确认：产品负责人、技术负责人、业务方代表各自明确，且具备决策权重。
- 统一评分维度已对齐：团队对“价值”的定义达成共识（如用户覆盖度、营收影响、技术风险降低等）。
1.3 操作步骤（认知建立）
本步骤帮助团队建立优先级划分的底层共识，而非具体操作流程：
- 盘点当前决策痛点：回顾最近2个版本中，因优先级不清导致返工、延期或上线后效果不及预期的功能列表。
- 学习价值评估维度：掌握至少3种常用维度（业务价值、技术成本、战略对齐度、风险等级），并理解其权重含义。
- 对标典型场景：将自身团队现状与1.1中的四类场景逐一比对，确认当前处于哪种触发条件。
- 识别认知盲区：对照1.8中的常见误区清单，检查团队是否存在“老板说了算”“谁声音大谁优先”等偏差。
- 形成团队价值主张：用一句话总结“我们为什么需要优先级划分”，并写入团队工作章程。
1.4 输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 信息类 | 功能需求池（原始列表） | 优先级划分认知报告（含痛点分析、场景匹配、误区自查） |
| 决策类 | 团队当前决策流程说明 | 优先级划分启动决议（含决策角色、评分维度、时间计划） |
| 模板类 | 无 | 功能优先级信息登记模板（结构化YAML） |
关键产出物示例：功能优先级信息登记模板（YAML），用于后续章节的实操录入。
# 功能优先级信息登记模板
features:
- id: "F001"
name: "智能客服自动升级"
desc: "当AI无法解决时自动转人工，并附带上下文"
expected_benefit: "客服效率提升30%，用户满意度+5%"
effort_days: 18
stakeholder: "客服部 / 产品部"
status: "待评估"
- id: "F002"
name: "多语言实时翻译"
desc: "在对话中自动检测并翻译为指定语言"
expected_benefit: "海外用户覆盖率+15%"
effort_days: 45
stakeholder: "国际化团队 / 工程部"
status: "待评估"1.5 责任边界
| 角色 | 责任内容 | 决策权重 |
|---|---|---|
| 产品负责人 | 组织认知建立会议、输出认知报告、发起启动决议 | 有召集权与解释权，无单方面否决权 |
| 技术负责人 | 提供功能技术成本估算、识别技术依赖风险 | 对成本维度拥有最终解释权 |
| 业务方代表 | 提供业务收益数据、确认用户场景真实性 | 对业务价值维度拥有最终解释权 |
| 团队全体 | 参与认知对齐、反馈历史痛点、承诺遵守后续划分结果 | 无单独决策权，但拥有异议申诉通道 |
1.6 记录材料
本章需归档以下材料，作为后续章节的输入基线：
- 《优先级划分认知报告》：包含痛点清单、场景匹配表、误区自查结果。
- 《功能需求池原始快照》：从需求管理工具导出的当前全量功能列表（含状态、提出方、预估人天）。
- 《优先级划分启动决议》：由产品负责人、技术负责人、业务方代表共同签字的启动文件，包含决策角色、评分维度、时间计划。
- 《功能优先级信息登记模板》：上述YAML格式模板，已填充至少2个示例功能。
1.7 异常处理
| 异常场景 | 表现 | 处理措施 |
|---|---|---|
| 决策角色缺位 | 业务方代表无法确认，或技术负责人拒绝提供成本估算 | 升级至项目发起人，明确各方参与义务；若仍缺位，暂停认知流程 |
| 需求池未结构化 | 功能描述缺失、收益无法量化、估算人天空白 | 启动需求池治理子任务，补充必要字段后再进入认知步骤 |
| 团队对“价值”定义分歧 | 产品侧重用户体验、业务侧侧重营收、技术侧重稳定性，无法对齐 | 引用公司级OKR或年度战略目标作为价值锚点，强制统一到2～3个核心维度 |
| 历史决策创伤 | 团队曾因优先级划分流于形式导致失败，产生抵触情绪 | 安排专场回顾会，复盘失败原因；本教程的SOP流程可作为改进契约，逐步重建信任 |
注意：异常处理并非只在第1章执行，而是贯穿整个教程的30个章节。本章重点解决“认知建立阶段”的典型阻滞，后续章节会针对各实操环节定义专属异常处理。
1.8 验收标准
完成本章学习后，团队或学员应能通过以下验收检查：
- ✅ 能列出至少3个因优先级不清导致的项目损失案例（来自自身或行业）。
- ✅ 能准确判断当前团队是否处于“需要启动优先级划分”的触发状态。
- ✅ 能说出优先级划分的3个核心价值维度，并解释每个维度的含义。
- ✅ 能对照常见误区清单，识别出团队当前存在的至少1个认知偏差。
- ✅ 已完成《优先级划分认知报告》并归档至指定知识库。
- ✅ 已填充《功能优先级信息登记模板》并提交至版本管理仓库。