2. 需求定义：明确评估目标、界定评估范围、梳理关键指标（KPI），输出《评估需求说明书》
好，咱们进入第二个关键环节——需求定义。
说实话，我见过太多项目栽在这一步。甲方自己都没想清楚要评什么，就急着发标书。结果呢？评估机构来了，双方扯皮三个月，最后出来的报告跟废纸一样。嗯，咱们不能犯这个错。
2.1 明确评估目标：你到底想解决什么问题？
我个人习惯，做任何评估前先问自己三个问题：
- 这次评估是为了验证什么？ 是验证供应商的技术能力？还是验证产品的合规性？
- 评估结果给谁用？ 给老板拍板用？给技术团队改进用？还是给客户看？
- 评估的底线是什么？ 哪些问题绝对不能放过？
我在项目中遇到过一家公司，他们想评估一个AI算法供应商。一开始目标写的是“评估算法性能”。这太模糊了。我追问了一句：“具体是评估识别准确率，还是响应速度，还是模型可解释性？”对方愣住了。后来我们重新梳理，把目标拆成了三条：
- 验证算法在极端光照条件下的识别准确率不低于95%
- 评估模型推理延迟在边缘设备上不超过200ms
- 确认供应商具备模型迭代和持续优化的能力
你看，目标一明确，后面所有工作都顺了。
核心原则：评估目标必须可量化、可验证、与业务强相关。别写“提升效率”这种空话，要写“将审批流程从3天缩短到1天”。
2.2 界定评估范围：哪些该评，哪些不该评？
范围界定是门艺术。评得太宽，成本失控；评得太窄，风险漏网。
我建议用“四象限法”来画边界：
| 维度 | 包含在内 | 排除在外 |
|---|---|---|
| 技术范围 | 核心算法、数据管道、模型部署 | 非核心UI界面、文档格式 |
| 时间范围 | 近6个月的迭代版本 | 3年前的历史遗留代码 |
| 地域范围 | 中国区业务线 | 海外子公司的独立系统 |
| 组织范围 | 供应商的研发团队 | 供应商的财务、HR部门 |
为什么要这么细？我曾经吃过亏。有一次评估一个大数据平台，我们没明确说“不评硬件”。结果供应商把服务器机房的空调能耗都算进评估范围了，白白浪费了两周时间。你想想看，这多冤。
小技巧：在范围说明里加一句“明确不包含的内容”。这能帮你挡掉80%的后期扯皮。
2.3 梳理关键指标（KPI）：用数据说话
指标不是越多越好。我见过一份评估需求书，列了47个KPI。说实话，评估机构看到这种清单，第一反应就是加价。为什么？因为大部分指标根本测不了，或者测了也没意义。
我个人习惯，每个评估目标配2-3个核心KPI，最多不超过5个。举个例子：
| 评估目标 | 核心KPI | 验收标准 |
|---|---|---|
| 验证算法准确性 | Top-1准确率、召回率 | ≥95% |
| 评估系统稳定性 | 99.9%可用性、平均故障恢复时间 | MTTR ≤ 30分钟 |
| 确认数据安全性 | 数据加密覆盖率、漏洞扫描通过率 | 100%加密，高危漏洞0个 |
这里要注意一个坑：KPI必须可测量。什么叫“用户体验好”？这没法测。要改成“页面加载时间≤2秒”或“用户操作完成率≥98%”。
避坑指南：我曾经遇到一个项目，甲方要求“评估供应商的创新能力”。我们问怎么量化？对方说“看感觉”。这没法评。最后我们把它拆成了“近两年专利申请数量”和“研发投入占比”两个硬指标。记住，感觉不能当KPI。
2.4 输出《评估需求说明书》：把一切写下来
好了，前面三步做完，最后一步就是输出文档。这份文档是后面所有工作的宪法，谁都不能随便改。
我建议的文档结构如下：
- 项目背景 —— 为什么要做这次评估？
- 评估目标 —— 清晰列出3-5个核心目标
- 评估范围 —— 包含什么，不包含什么
- 关键指标（KPI） —— 每个目标的量化指标和验收标准
- 交付物要求 —— 报告格式、数据原始记录、演示视频等
- 时间计划 —— 关键里程碑和截止日期
- 变更管理 —— 需求变更的流程和审批人
说白了，这份说明书就是你和评估机构之间的“合同”。写得越细，后面吵架越少。我习惯在文档最后加一页签字页，双方项目经理签字确认。别嫌麻烦，这是保护自己的最好方式。
我的经验：《评估需求说明书》至少需要内部评审两轮。第一轮拉技术团队，确认指标可测；第二轮拉业务团队，确认目标有价值。两轮都过了，再发给评估机构。
嗯，需求定义这块就讲到这里。记住一句话：需求定义花的时间，会在评估执行阶段十倍地省回来。别急着往下走，把这一步做扎实了，后面都是顺水推舟的事。