3. ASPICE模型结构
评估计划，说白了就是一张作战地图。没有它，你连评估从哪下手都不知道。
我见过不少团队，上来就找项目组要文档、约访谈，结果三天后发现范围没对齐，干系人也不配合，整个评估卡在半路。嗯，这就是计划没做透的典型症状。
这一章，咱们把评估计划的四个核心动作拆开揉碎讲清楚。
3.1 确定评估范围与目标
范围定得太大，评估做不完；定得太小，又看不出问题。我个人的习惯是：先画边界，再定深度。
范围定义三要素：
- 组织边界：是整个事业部，还是某个产品线？
- 过程域边界：覆盖CMMI的哪几个PA？还是只评需求管理和项目管理？
- 时间边界：看最近6个月的项目，还是看全年？
目标要符合SMART原则。举个例子，别写“提升过程能力”，这太虚了。要写成：
- 识别需求管理过程中3个以上的主要缺陷
- 确认项目估算偏差是否控制在±15%以内
- 输出一份可操作的改进建议清单（至少5条）
我在一家金融科技公司做评估时，客户一开始说“想看看研发流程哪里有问题”。我追问了两轮，最后把目标锁定在“需求变更流程的合规性与效率”。范围一收窄，评估只用了4天就出了结果，客户非常满意。
小技巧：用“评估范围说明书”把边界写清楚，让项目组和评估组双方签字确认。这能省掉后面80%的扯皮。
3.2 组建评估团队
团队不是凑人头，是搭结构。一个标准的评估团队，至少需要这几类角色：
| 角色 | 职责 | 建议人数 |
|---|---|---|
| 评估组长 | 统筹计划、把控节奏、裁决争议 | 1人 |
| 过程专家 | 负责过程域访谈、文档审查 | 2-3人 |
| 数据采集员 | 收集度量数据、整理证据 | 1-2人 |
| 记录员 | 做会议纪要、记录发现项 | 1人 |
| 协调员 | 对接项目组、安排日程 | 1人（可兼职） |
选人时要注意：评估组长不能是项目组的直属领导，否则客观性会打折扣。我曾经遇到一个案例，组长是研发总监，评估时下属都不敢说真话，最后评出来的结果全是“良好”。后来换了一个独立部门的专家重新评，才挖出真实问题。
避坑指南：我曾经见过一个团队，评估组里全是技术大牛，但没有一个人懂过程模型。结果访谈时问的全是技术细节，过程域的覆盖度一塌糊涂。记住：评估组需要的是“过程视角”，不是“技术视角”。
3.3 制定评估时间表
时间表要分阶段排。我一般把评估分成四个阶段：
- 准备期（1-2周）：文档预审、问卷发放、日程确认
- 现场期（3-5天）：访谈、文档抽查、数据验证
- 分析期（1周）：证据整理、发现项分类、初步结论
- 报告期（3-5天）：撰写报告、评审、正式发布
你想想看，如果现场期只有2天，你根本来不及深入访谈。我个人的经验是：现场期至少留3天，第一天做高层访谈和项目组访谈，第二天做文档审查和交叉验证，第三天做补充访谈和初步反馈。
时间表模板（示例）：
第1周：准备期
- 周一：发布评估通知，收集项目文档
- 周三：评估组内部预审文档
- 周五：确认访谈名单与日程
第2周：现场期
- 周一：启动会 + 高层访谈
- 周二：项目组访谈 + 文档抽查
- 周三：补充访谈 + 数据验证
- 周四：评估组内部合议
- 周五：初步反馈会
第3周：分析期
- 周一至周三：证据整理与分类
- 周四：发现项评审
第4周：报告期
- 周一至周二：撰写评估报告
- 周三：报告内部评审
- 周四：正式发布3.4 识别关键干系人
干系人没找对，评估寸步难行。我习惯用权力-利益矩阵来分类：
| 权力/利益 | 高利益 | 低利益 |
|---|---|---|
| 高权力 | 重点管理（如：CTO、质量总监） | 保持满意（如：财务总监） |
| 低权力 | 保持知情（如：项目经理、QA） | 最低关注（如：行政人员） |
关键干系人至少包括：
- 决策层：能拍板改进资源的人（如VP、CTO）
- 执行层：被评估的项目经理、开发组长
- 支持层：QA、配置管理员、测试经理
- 客户代表：如果评估涉及需求管理，最好拉上产品经理
我记得有一次评估，我漏掉了产品经理。结果访谈时发现需求变更流程的问题，产品经理根本不认账，说“我们没参与过这个流程”。后来只好补了一次访谈，多花了半天时间。从那以后，我每次都会把干系人清单列出来，让项目组确认一遍。
实操建议：干系人识别后，给每个人发一份“评估参与说明”，写清楚他们需要配合什么、投入多少时间。提前沟通，能减少很多临时冲突。
本章知识结构图
下面这张图，把评估计划制定的四个核心步骤串起来了。你可以把它贴在墙上，做评估时对照着走。
小结
评估计划不是走形式，它是整个评估的骨架。范围定清楚、团队搭合理、时间排紧凑、干系人找齐全，后面执行起来就顺了。
我个人最深的体会是：计划阶段多花1天，执行阶段能省3天。别急着冲进现场，先把这四件事做扎实。