能力度等级2：已管理的过程、管理实践、工作产品管理

好，我们进入能力度等级2。说实话，很多团队卡在等级1上不去，就是没搞懂等级2到底要什么。等级1是「做了」，等级2是「管好了」。你想想看，一个项目做完，代码能跑，但过程一团乱麻——这能叫成熟吗？

我个人习惯把等级2拆成两个维度来看：过程管理和工作产品管理。今天我们就重点聊这两个。

什么是「已管理的过程」？

说白了，就是你的过程不再是「随缘」的。有明确的计划，有资源分配，有责任分工，出了问题还能追溯。我在项目中遇到过一种典型情况：开发人员自己觉得「我按流程走了」，但审计一问三不知——计划在哪？评审记录在哪？变更记录在哪？全凭记忆。

嗯，这里要注意。ASPICE说的「已管理」，不是让你写一堆文档。而是让你能回答三个问题：

• 谁在做什么？（角色和职责明确）
• 什么时候做？（有进度计划）
• 做得怎么样？（有监控和纠偏）

管理实践（Management Practices）

ASPICE的PA2.1和PA2.2分别对应过程管理和工作产品管理。我们先看管理实践。

PA2.1：过程管理

这个实践要求你：

1. 建立过程目标——比如「需求分析阶段要在2周内完成，且评审通过率≥90%」
2. 分配资源——谁负责需求？谁负责评审？工具链到位了吗？
3. 监控执行——每周看进度偏差，及时调整
4. 采取纠正措施——发现偏离计划，立刻拉警报

我曾经在一个项目里，项目经理觉得「进度没问题」，结果到集成阶段才发现需求漏了30%。为什么？因为没有阶段性的监控点。后来我们强制要求每两周做一次「过程健康检查」，问题早暴露早解决。

PA2.2：工作产品管理

这个更具体。工作产品包括：需求文档、设计文档、代码、测试用例、评审记录……所有过程产出物。

管理要求是什么？

• 版本控制——谁改了？什么时候改的？改了什么？
• 配置管理——不同版本之间能否追溯？
• 评审和批准——工作产品发布前，有没有经过正式评审？
• 变更管理——改了之后，相关方知不知道？

我记得有一次审计，对方问：「你们的需求文档第2.3节是谁改的？」我们翻半天版本记录，发现是某位工程师直接在生产分支上改的，没走评审。嗯，这就是典型的工作产品管理失控。

工作产品管理的具体实践

我们展开说说。工作产品管理不是一句空话，它落地到具体操作上，有这几个关键点：

管理维度	具体要求	常见问题
标识	每个工作产品有唯一ID，可追溯	文档编号混乱，找不到对应关系
版本控制	基线管理，变更历史可查	多人同时修改，覆盖了别人的内容
评审	正式评审，有记录、有结论	评审走过场，签字了事
发布管理	只有经过批准的工作产品才能发布	开发人员直接拿未评审的代码去集成
变更管理	变更请求、影响分析、批准流程	改了需求，但测试用例没同步更新

你想想看，如果这些维度都管好了，审计来查的时候，你心里是有底的。而不是临时抱佛脚去补记录。

等级2的「证据链」思维

我个人觉得，等级2最核心的转变是：从「做事」到「留痕」。不是让你做表面功夫，而是让过程可追溯、可复现。

举个例子。你在等级1的时候，可能写了一段代码，测试通过了就完事。但在等级2，你需要：

• 代码有对应的需求编号
• 代码经过了同行评审
• 评审意见被记录并关闭
• 代码纳入了版本管理
• 测试用例覆盖了这段代码
• 测试结果被记录并关联到需求

这一串下来，就是一条完整的证据链。审计人员顺着这条链，能从需求一路追到代码、测试、发布。

常见误区

我带过不少团队做ASPICE改进，发现几个典型误区：

1. 过度文档化——为了满足等级2，写一堆没人看的文档。其实ASPICE要的是「必要的信息」，不是「所有的信息」。
2. 工具依赖症——上了Jira、上了Polarion就觉得万事大吉。工具只是辅助，流程设计不合理，工具也救不了你。
3. 重过程轻结果——过程管理做得很漂亮，但产品还是一堆bug。记住，过程是为结果服务的。

我曾经见过一个团队，为了满足PA2.2，给每个文档都加了5个审批节点。结果一个简单的需求变更，审批流程走了两周。嗯，这就是典型的「管理过度」。适度管理，才是等级2的精髓。

小结

能力度等级2，说白了就是让你的过程「有章可循、有据可查」。管理实践关注过程的计划、执行、监控和纠偏；工作产品管理关注产出物的版本、评审、变更和发布。

下一章我们会聊等级3——已定义的过程。到时候你会发现，等级2是「管好自己」，等级3是「管好组织」。一步步来，别急。