ISO/IEC 33002过程评估执行要求：从22页标准到可落地的评估体系

简介：《ISO/IEC 33002:2015》是一份国际标准全文PDF，主要面向软件过程改进人员、过程评估师、质量管理及IT审计从业者，为组织实施过程评估提供了通用要求与操作指南，覆盖评估准备、数据收集、结果判定、报告编写与结果验证等环节，有助于提升评估的客观性、一致性与可重复性。资源共1个文件，文件类型为PDF，压缩包大小2.63MB，内容为完整的英文原版标准，共22页，包含范围、规范性引用文件、术语定义及“执行评估”等核心章节，可轻松检索与打印。目前已有199人学习下载，适合需要深入研读标准原文、制定评估方案或准备相关认证的人员使用。通过研读该标准，读者可以明确过程评估的规范化步骤与关键要求，理解评估模型和指标的运用逻辑，为组织持续改进过程能力提供可落地的依据。

1. 为什么一份22页的"要求"文件，比厚厚的方法论更容易让你翻车

第一次拿到《ISO IEC 33002：2015》完整英文版PDF，看到只有22页，很多人心里会冒出一句：就这么点？先别急着下结论。这份标准全名是Information technology - Process assessment - Requirements for performing process assessment，它只干一件事：定义一次可信的过程评估最低限度必须满足哪些要求。它不教你怎么访谈、不给你报告模板，正文里几乎全是shall。它适合正在搭评估体系的QA负责人、过程改进工程师、评估组长，以及想把内部评估做得经得起审计的团队。把这份要求当说明书读是最大的坑；把它当核对表用，评估才不会变成自说自话的表演。

2. 33002在过程评估体系里的定位：为什么"执行要求"值得单独成篇

2.1 从ISO/IEC 15504到ISO/IEC 330xx：评估标准的家谱与演进

如果你去查ISO/IEC 33002:2015，会发现它几乎总是和33001、33003、33004、33020一起出现。不是PDF打包发货，是标准家族的结构如此。330xx系列的前身是ISO/IEC 15504，早年间跟CMMI评估打交道的人更熟的是SPICE这个叫法。ISO在2015年前后把这套东西做了重新编号和拆分，拆完之后的分工非常清楚：33001管概念和术语；33002管评估执行要求；33003管过程能力测量框架的要求；33004管过程参考模型、过程评估模型和成熟度模型怎么建立；33020给出那套真正用来打分的测量框架本身，也就是六个能力等级和九个过程属性。

在这个家族里，33002的位置很特殊。33001是字典，33020是尺子，33004是造模型的规矩，而33002管的是"人怎么干活"：谁有权发起评估，评估组长要承担什么责任，证据要收集到什么程度，评级结果怎么被人信服。一句话概括：它是所有330xx标准里唯一直接指挥评估团队动作的标准。你按33020学会了打分，但怎么组织一场不打偏的评估，答案在33002里。

这里有个常见的误解：以为33002是给认证机构用的，跟普通企业没关系。实际恰恰相反——只要你的组织在做内部过程改进评估、在给供应商做过程能力评价，或者想在引入CMMI评估之前先搞一次"预评估"，33002就是那份兜底的质量底线。它不要求你对外发证，只要求你做的事能"自证"。

2.2 33002和CMMI评估方法的关系：规范与方法的分工

业内最常见的对照物是CMMI的SCAMPI方法。SCAMPI A、B、C这三级评估，和33002里的第一、二、三类评估能对得上；SCAMPI A在严谨性和独立性上的要求，和33002对第一类评估的要求是呼应的。这不是巧合：CMMI评估方法在设计和演进过程中，本来就是按ISO/IEC 33002这类执行标准的要求来对齐的。

两者的关系可以理解成"交通法规"和"驾驶技巧"：33002是法规，规定你出车必须具备哪些条件、要留哪些记录；SCAMPI是经过多年打磨的驾驶流程，告诉你在具体的一次评估里，启动会怎么开、访谈怎么排、证据怎么带。直接读33002，你会觉得它说得太原则；直接读SCAMPI，你又容易只学到动作、丢了对底线的判断。我一般是两者配合：用SCAMPI的节奏走流程，用33002的条款做验收。

2.3 为什么只有22页：要求型标准的读法和"不用读"的部分

第一次带团队读这份标准的人，十有八九会失望：没有案例，没有模板，没有推荐做法。前几章讲范围、引用文件和术语，后面每一章都长得很像——"评估应……""评估组长应……""评估记录应……"。这正是要求型标准（requirements standard）的写作方式：每句话是一个必须满足的条款，不是一段给你解释为什么的散文。

所以读法要反过来。不要问"这条是什么意思"，要问"这条在我们的评估文件里对应哪个位置"。比如标准里写评估输入应事先约定并获得批准，你就该问：我们的评估委托书上，有没有发起人和组长双方的签字？再比如写评估数据应经过验证，你就该问：我们访谈完的信息，有没有和文档证据交叉核对过？我习惯把22页逐条转成一份问题清单，每条条款后面跟着填证据文件名和责任人，这份清单后来就成了内部评估的骨架。

22页还有一个好处：它逼着你去读配套标准。33002不会告诉你N、P、L、F四个评级怎么定，那是33020的事；不会告诉你过程评估模型怎么建，那是33004的事。22页只负责给评估过程的每个环节设一道"最低护栏"。想明白这一点，你看到"要求"两个字就不会嫌它空洞，反而会觉得它写得很克制，一句废话都没有。

3. 读懂33002正文前，先弄懂五个关键概念

3.1 评估类别：第一、二、三类评估的适用边界

33002正文里的第一个关键分叉是评估类别。很多团队把一份评估报告捧出来，却说不出它属于哪一类，后面的独立性、证据链要求就全乱了。评估类别不是按组织大小定的，是按"评估输出的用途"定的：输出是要拿出去跟别人比，还是只给自己看。

我见过最典型的翻车是把第二类的报告当成第一类的用：内部评估员拿着自己写的一份报告，去跟供应商谈判说"我们的过程能力已经达到XX级"。对方只要问一句"你们的评估员是谁、独立性怎么证明"，这场对话就进行不下去。反过来也有：内部做个改进摸底，非要按第一类标准请外部评估员、做全套证据链，钱花了不少，结论却没有更多增量。选类别之前，先问自己一个问题：这份评估结果，除了我们自己，还有没有人会拿它做决策？有人，就按更高类别准备。

3.2 评估输入：目的、范围、约束、标识，缺一项就站不住

标准里把评估输入分成几类，我习惯把它记成四件套：评估目的、评估范围、评估约束、评估标识。这四样东西必须在评估启动前定清楚，并且得到发起人的批准。

范围这条最容易写飘。"研发过程"四个字等于没写，因为研发过程能拆出十几个过程域。我会按过程域列表逐项勾选，并写清时间窗口是看最近十二个月还是某个版本迭代；组织单元也要落到具体团队，比如"北京研发中心-移动客户端团队"而不是"研发部"。原因很实际：范围不收敛，后面采证阶段就会面临"这个项目的材料要不要看"的反复讨论，每讨论一次都是在烧评估人日。

3.3 评估中的三类角色：发起人、评估组长、评估员各负什么责

33002对评估责任的定义是评估结果能不能立住的第二根柱子。三个角色不能互相兼：发起人出钱出资源、批范围、最后接收报告；评估组长对评估全过程负责，包括确保按33002执行、组织评级、把关报告；评估员负责采集数据、验证数据、参与评级并对自己签字的结论负责。

独立性是这章的重点。第一类评估要求组长独立于被评估组织；第二类评估组长可以来自组织内部，但必须独立于被评估的项目，不能是项目负责人、不能是该项目直接汇报链上的人。我每次组队都会让每个评估员签一份独立性声明，写明自己和被评团队之间有没有利益关系；这份声明进评估记录，以后被审计时拿得出来。很多人觉得第三类评估就可以完全不讲独立性，标准里的确放宽了，但评估目的、评估输入这些基本要求仍然在，别把宽松当成不用守规矩。

3.4 评估输出和记录保留：哪些产物必须留、留多久

评估做完，不是交了一份报告就结束了。33002要求评估过程留下足够让第三方复核的记录。按我自己的归档习惯，一次完整评估至少要留下五类东西：批准过的评估输入、评估计划、数据采集记录、评级决策记录、评估报告。

数据采集记录是里面最容易被忽略的。访谈笔记、文档清单、观察记录，都要在当天整理、由采集人签字，放进归档目录。不要觉得访谈笔记难看就不收进正式记录——没有它，评估报告里的每一个评级都成了无源之水，复评时只能吃后悔药。保留期限标准里不硬性写死，但要由发起人和组长在评估输入中约定；我的建议是最少保留到下一轮评估完成，涉及商务或合同场景的，按合同保留年限执行。

提示：评估记录的归档格式要预先统一。一个项目一套记法、一个评估员一种笔记模板，归档时就是灾难。

4. 按33002组织一次完整的过程评估：从委托到报告的分步做法

4.1 启动与准备：把评估输入固化成一份双方签字的委托书

第一步是发起人启动。通常是组织里的质量总监或改进负责人提出需求，目标是年度改进或部门间比较。这个阶段最容易出的问题，是目的还没说清就急着排日程。

我一般会让发起人先用一段话回答三个问题：这次评估给谁看、下次什么时间点要拿结果做什么决策、愿意投入多少人日。然后评估组长进场，把上一轮评估报告和过程资产先过一遍，再和发起人一起把评估目的、范围、约束、标识写进评估输入文档。这份文档双方签完字，就是整场评估的合同，后面所有争议都回到这份文件上对。

签字之后，组长做两件事：一是组建评估组并收齐独立性声明；二是出评估计划，把日程、人员分工、样本项目、要接触的文档和访谈对象排进去。评估计划不用写得很厚，但要具体到"哪天、谁、在哪个会议室、访谈哪个角色"，方便后续数据采集阶段逐项销号。

4.2 数据采集与数据验证：样本怎么选、证据怎么算"够"

数据采集是评估里最花时间的环节，33002不规定具体方法，但要求数据必须能追溯到原始出处。我常用的组合是三种：文档评审、访谈、直接观察。文档评审不是看文件有没有，而是看文件有没有被使用过——一份配置管理计划如果没有任何版本历史、没有变更记录、没有对应邮件或会议纪要，那它只是"存在"，不是"被执行"。这一点新手最容易栽，后文避坑章里还会专门展开。

访谈要覆盖角色的多样性。每个过程域至少访谈项目经理、一线工程师和QA三类角色各一人，单场访谈控制在四十五到九十分钟之间；只听一种角色的说法，很容易把局部体验当成全局事实。

数据验证是33002反复强调的环节，核心是三个问题：线索能否追溯到原始来源；不同来源之间有没有矛盾；评估员对同一份证据的理解是否一致。我一般在数据采集的中后期安排一次专门的验证会，把收集到的证据逐条过一遍，矛盾之处当场决定是补采还是降级使用。数据没验证就评级，等于拿没校准的秤称重量。

4.3 评级不是打分题：N/P/L/F的判定规则与一致性校准

评级是评估里最容易被误解成"投票"的环节。33020把每个过程属性的实现程度分为四级：N（不完整）、P（部分实现）、L（大部分实现）、F（完全实现）。33002不在正文里教你怎么定义这四个词，它要求的是：评估组必须有一套预先约定的评级规则，并且规则的执行结果是可复核的。

我自己的做法是给每个级别配上"证据表现"，评级时逐条对：

评级前必须做校准环节：每个评估员先独立给每个过程属性打分，再公开对照。两个人意见差一个级别以内，讨论后统一；差超过一级，说明两个人对"什么证据算数"的认知都没对齐，先别争论给几级，回去看证据清单，重新确认证据的定义。这个机制能有效避免"强势评估员带节奏"的问题。

提示：评级结论必须能指回具体证据。评委问你为什么是L不是F，你要能说出是哪个证据缺了，而不是说"感觉还差一点"。

4.4 评估报告：一份"可复评"的报告需要写清什么

报告是评估的终点，但很多人把它写成了"项目汇报"。33002视角下的评估报告，至少应包含六块：评估概述（目的、范围、类别）、评估组构成与独立性声明、评估方法（数据怎么采、怎么验证）、过程属性评级结果、评估限制与偏差、批准与分发信息。

前五块里最容易被低估的是"限制与偏差"。比如这次评估因疫情改为远程，视频访谈对现场工作氛围的观察不足；比如某个过程域样本只有两个项目。这些内容写进去，表面上是自曝短板，实际是保护自己：以后任何人对评估结论有争议，限制条件就是你的边界声明。最怕报告里只有评分表没有约束说明，被人问"你这次到底评了什么范围"时，回答就会变成一场事故。报告完成后由评估组长签发、发起人确认接收，归档才算了结。

5. 评估落地中常见的5个问题与排查：现象、原因、解决

这些坑不是标准写得不好，而是从"读懂了条款"到"做得到位"之间，隔着习惯和流程的落差。下面五条是我在自建评估体系、外部评审和复评中最常遇到的，按现象、原因、解决三个层次说透。

5.1 评估报告没人认：评级结果没跟上证据

现象：评估报告里一堆过程属性被打成F，评审会上却被人追问"依据在哪儿"——翻遍附录找不到对应的原始证据，会议气氛直接降到冰点。

原因：评级过程和证据采集是两条线，评级时凭整体印象打分，没有形成"每个评级指回一组证据"的映射。

解决：在评级结果表里加一列"证据引用"，每个属性对应的访谈记录编号、文档清单编号写清楚。这个引用必须在评级现场就填，事后补填等于二次编造。打补丁的方法虽然能用，但每次补都等于在给评估的可信度打折。

5.2 内部评估互相给面子：评级结果全线飘绿

现象：第二类内部评估做下来，所有过程域都是L和F，没有一条P或N。团队脸上好看，但改进无从下手。

原因：评估员和被评项目之间有协作关系，甚至评估员本人就是被评团队的前成员。人对熟人挑毛病总是很难，这跟专业水平无关，是独立性没设防。

解决：组队时就把"独立性"当成硬条件——评估员不能来自被评项目，至少不能在被评项目的直接汇报链上。独立性声明必须在开工前签，归档备查；评级校准环节里，只要有人提出质疑，就给质疑留出正式的讨论记录。必要时把评级结果匿名化后再上报，减少面子压力。

5.3 证据全是补写的模板：拿"存在"冒充"被执行"

现象：证据清单里全是"XX流程说明""XX管理规范"，文件齐全，但没有任何版本历史、审批记录或使用痕迹。一查文件属性的创建日期，全是评估前两周新建的。

原因：把"文档存在"等同于"过程被执行"。很多团队习惯为了评估临时补一套制度文件，这些文件在真实项目里从未被用过。

解决：采集证据时对每份文档提三个问题：有没有版本历史？有没有审批签字？内容中被引用过吗？三个都答不上来的文件，一律按"演示材料"处理，不进评级证据。评估员在访谈时也可以顺势抽查：让项目经理当场演示一次走流程的记录，比翻十份PPT都管用。

5.4 访谈做完没留痕：复评时翻不出原始记录

现象：评估结束三个月后做复评或审计，发现访谈记录只有笔记本上的几行字，或者是聊天软件的零散截图，无法还原当时访谈的完整结论。

原因：数据采集阶段没有规定统一的记录模板和归档动作，访谈记录被当成个人工作笔记，没纳入评估档案。

解决：统一访谈记录模板，包含时间、地点、访谈对象、在场评估员、问题清单、访谈要点、后续待办；访谈当天整理并经采集评估员签字。归档时按"评估计划-证据清单-访谈记录"的结构放好，确保任何一个第三者打开目录就能找到对应材料。

5.5 把能力等级宣传成成熟度等级：对外口径翻车

现象：评估报告写的是"某过程域达到能力等级2（CL2）"，宣传材料里却变成"我们通过评估达到成熟度2级"。有经验的客户过来一追问，当场露馅。

原因：能力等级（capability level）和成熟度等级（maturity level）是两个框架的概念。33002配合33020评出的是过程属性级别的能力等级，成熟度等级需要带成熟度模型的做法来支撑，输出也不一样。

解决：对外材料统一措辞。如果只做了33002式的过程评估，就写"按ISO/IEC 33020评定，XX过程能力等级为2级"；要宣传成熟度等级，就必须走包含成熟度模型的评估方案。这个口径问题最好在评估启动时就写进评估输入，别等宣传稿都发出去了再来做危机公关。

6. 从22页到可执行：把33002逐条改写成你组织的评估规程

6.1 四步把标准条款转成内部核对表

把33002落到自家流程里，不需要把PDF翻译一遍然后贴在质量手册里，那样只会落灰。我做过的有效方式，是四步改写。

第一步，把每一条shall翻译成一个问题：标准写"评估输入应得到批准"，就改成"我们的评估输入有发起人签字确认吗"。第二步，给每个问题指定责任角色和落点文件：这个问题归发起人还是组长，答案写在哪个文档里。第三步，按评估阶段分组：准备、采证、验证、评级、报告，让每个阶段有自己的检查页。第四步，用一次模拟评估检验这张表，凡是找不到答案落点的问题，就是流程里缺的环节，补齐它。

这套核对表用起来之后，评估就不依赖某个人的经验了：换一个评估组长，照着表走，结果依然稳。这也是33002这份标准最有价值的地方——它把评估从"看人下菜"变成了"有章可循"。

6.2 给评估组长的预评估自检六问

每次正式评估开始前，我会拿着核对表做一次自检，六问全过才开工。第一问：评估目的和范围有没有人签字？没有就回头。第二问：评估员的独立性声明齐了没有？第三问：每个过程域的样本项目是否达到3个以上？第四问：访谈记录模板统一了吗，归档责任人定了吗？第五问：评级规则有没有在评估组内过一遍，校准会议排进日程了吗？第六问：报告的限制与偏差章节，准备怎么写，谁来审？这六问问下来，基本能拦住我在一线见过的大多数翻车。

我早年第一次独立带评估时，报告里只有结论没有依据，客户在验收会上问我某个过程域为什么是F，我在会议室翻了半小时也没找到支撑那条评级的证据。那是我做评估以来最尴尬的一场交付，也让我彻底改了习惯：评估报告先让一个没参与评估的同事当"杠精"读一遍，专挑"为什么"打问号；这个习惯帮我避掉了后续很多次返工。希望帮到你。

本文还有配套的精品资源，点击获取