4. 能力等级0级(CL0)：不完整过程、特征与识别方法、改进方向
4.1 什么是CL0？说白了就是“没做”或“做了等于没做”
各位工程师朋友，咱们直接切入正题。
能力等级0级，在ASPICE里是最低的一档。它意味着什么？
我个人的理解很简单：这个过程要么根本没执行，要么执行了但完全看不出任何系统性的成果。
你想想看，一个项目团队如果连基本的需求分析都没做，或者做了但文档乱七八糟、评审记录全无，那在评估师眼里，这就是典型的CL0。
我记得有一次去一家供应商做预评估。他们的项目经理拍着胸脯说“我们肯定做了测试”。结果我一看，测试用例就写在餐巾纸上，连个版本号都没有。嗯，这就是CL0的典型症状——“有活动，无产出”。
核心定义：CL0表示过程未达到定义的任何过程属性。说白了，就是过程能力为“不完整”。
4.2 CL0的三大特征：一眼就能看出来
怎么快速识别一个过程是不是CL0？我总结了三个特征，你在项目里可以对照着看：
- 特征一：过程未执行
- 没有计划、没有活动、没有记录
- 我问你“这个需求怎么来的？”，你回答“凭经验”
- 特征二：执行了但无证据
- 团队说“我们评审过了”，但拿不出评审记录
- 代码改了，但没更新任何文档
- 特征三：产出物质量极差
- 文档内容前后矛盾
- 测试用例覆盖率为0%
- 配置管理库一片混乱
我曾经在一个项目里见过最离谱的情况：他们声称做了“单元测试”，但测试报告里写的测试结果和实际代码功能完全对不上。这比没做更可怕——因为它浪费了时间，还给了你虚假的安全感。
4.3 识别方法：评估师是怎么“抓现行”的？
作为评估师，我们有一套标准打法。这里我分享几个实战技巧：
| 检查项 | 具体方法 | CL0的典型表现 |
|---|---|---|
| 过程定义 | 查看是否有书面过程描述 | 完全没有，或者只有一句话“按公司流程走” |
| 执行证据 | 抽查3-5个工作产品 | 找不到、不完整、无签名、无日期 |
| 角色职责 | 询问谁负责、谁执行 | “大家都做”、“没人专门负责” |
| 工具支持 | 检查是否使用工具管理 | 全靠Excel甚至手写 |
这里有个避坑指南：我曾经见过一个团队，为了应付评估，临时补了一堆文档。结果呢？文档里的日期是未来的，签名是打印的。这种“造假”比CL0更糟糕，因为它涉及诚信问题。
个人建议：如果你发现团队有CL0的苗头，别急着补文档。先停下来，问三个问题：
- 我们到底需要什么过程？
- 谁来做？
- 怎么做才算“做完”？
想清楚再动手，比盲目补课强十倍。
4.4 改进方向：从0到1的“破冰”之路
CL0的改进，说白了就是从“无序”到“有序”。别想着一步到位到CL3，那不现实。我建议分三步走：
第一步：建立最基本的过程框架
- 定义过程的目标和输入输出
- 指定负责人（哪怕只是兼职）
- 确定最简单的模板（别搞复杂了）
第二步：强制执行并留下痕迹
- 要求每个活动必须有产出物
- 使用版本控制工具（Git、SVN都行）
- 建立简单的评审机制（哪怕只是邮件确认）
第三步：定期检查并反馈
- 每周花15分钟检查过程执行情况
- 发现问题及时纠正，别等到季度末
- 奖励那些认真执行的人
我记得有个项目，一开始连需求文档都没有。我建议他们先从“写一句话需求”开始。两周后，他们有了第一份需求列表。虽然只有10条，但每条都清晰可追溯。这就是进步。
注意：改进CL0时，最容易犯的错误是“过度设计”。
比如，一个只有5个人的小团队，非要搞个复杂的评审流程，结果没人愿意用。我的建议是：先跑起来，再优化。哪怕流程很粗糙，只要能用、能留下证据，就比CL0强。
4.5 实战案例：一个CL0到CL1的转变
最后，我分享一个真实案例。
某Tier 1供应商的“软件详细设计”过程被评估为CL0。他们的问题是：
- 没有设计模板
- 设计文档和代码严重脱节
- 没有设计评审
改进措施很简单：
- 制定了一个2页纸的设计模板（包含接口、数据结构、算法描述）
- 要求每个模块设计完成后，必须和代码对照检查
- 每周五下午做30分钟的设计走查
三个月后，再次评估时，他们已经达到了CL1。虽然离CL2还有距离，但至少不再是“不完整”了。
所以，别怕CL0。它只是起点，不是终点。只要方向对了，每一步都是进步。
下一章，我们会聊CL1（已执行过程）的特征和改进方法。到时候我会分享更多关于“如何让过程真正落地”的实战经验。