需求评审争议
拆评审会争议：技术风险、产品目标与资源约束的真实冲突
用这个方法分析
上传录音或转写文本即可，未登录会先引导登录
产出长什么样
示例下面是一段虚构场景的示例产出，用来说明形态。真实分析会锚定你自己录音里的原话。
需求评审争议拆解：个性化推荐2.0项目
场景：某科技公司产品部与技术部就“个性化推荐2.0”项目进行需求评审，时长45分钟，涉及产品经理、技术主管、市场负责人及CEO。
争议点与各方立场对照矩阵
| 争议点 | 产品经理立场 | 技术主管立场 | 风险评估 | 证据支撑强度 |
|---|---|---|---|---|
| 1. 核心功能：实时用户行为分析 | 必须上线，是核心卖点，能直接提升点击率。 | 需新建实时数据管道，团队需额外2个月学习，高风险延期。 | 项目延期，错过Q4营销窗口。 | 中：有竞品分析报告（点击率数据），但缺乏内部用户调研以确认此功能为刚需。 |
| 2. 资源冲突：算法专家被AI客服项目占用 | 人必须立刻调回，本项目优先级更高。 | AI客服是CEO督办项目，无法调配，可用初级工程师替代。 | 用初级人员将导致算法效果不达标，影响业务目标。 | 强：项目排期表、CEO邮件明确AI客服优先级。 |
| 3. 目标分歧：技术稳定性 vs 产品创新 | 允许功能存在小缺陷，快速上线抢占市场。 | 必须保证99.9%稳定，需增加全链路压测环节。 | 若追求稳定，上线时间将延至明年Q1，丧失先发优势。 | 强：技术风险评估文档、过往故障复盘记录。 |
裁决建议与代价分析
建议方案：将“实时分析”降级为“准实时（T+1）分析”，确保核心算法由现有团队主力负责，并完成基础压测。
- 代价1（产品侧）：核心卖点打折扣，市场宣传需调整话术。
- 代价2（技术侧）：仍需2周时间改造数据管道，但避免了引入新技术栈的长期风险。
- 最终支撑原话（CEO会议总结）：“今年的首要任务是活下去并占领市场，技术债可以下个季度再议。所以，按降级方案执行，产品部重新调整发布策略。”
注：关于“用户调研不足”为关键争议点的结论，在本次会议记录中原文无直接依据，系根据各方争论焦点推断得出。会议纪要中并未包含具体的用户调研数据讨论。
什么时候用它
用在内部会议这类录音上。当内容里出现下面这些信号时，它最派得上用场：
评审会有明显分歧
输出的 4 个模块
产出形态是对照矩阵，不是一段分析文字——有形态才能沉淀、才能被下游用。
- 1争议点清单
- 2各方论据强度
- 3被当作技术问题的目标分歧
- 4裁决建议与代价
它怎么保证不瞎说
亲证锚定
置信分层
约束与代价
证据不足时它会说「本场没有可供分析的对象，缺的是什么」，而不是编一个结论—— 这是硬要求，不是客套话。
常见问题
- 需求评审争议适合分析什么样的录音？
- 适用于内部会议。典型触发信号：评审会有明显分歧。一场录音即可。
- 用需求评审争议会拿到什么？
- 产出形态是对照矩阵，包含 4 个模块：争议点清单、各方论据强度、被当作技术问题的目标分歧、裁决建议与代价。
- 需求评审争议不做什么？
- 不得把单一用户的说法当成群体结论