简介《ISO/IEC 33002:2015》是一份国际标准全文PDF主要面向软件过程改进人员、过程评估师、质量管理及IT审计从业者为组织实施过程评估提供了通用要求与操作指南覆盖评估准备、数据收集、结果判定、报告编写与结果验证等环节有助于提升评估的客观性、一致性与可重复性。资源共1个文件文件类型为PDF压缩包大小2.63MB内容为完整的英文原版标准共22页包含范围、规范性引用文件、术语定义及“执行评估”等核心章节可轻松检索与打印。目前已有199人学习下载适合需要深入研读标准原文、制定评估方案或准备相关认证的人员使用。通过研读该标准读者可以明确过程评估的规范化步骤与关键要求理解评估模型和指标的运用逻辑为组织持续改进过程能力提供可落地的依据。1. 为什么一份22页的要求文件比厚厚的方法论更容易让你翻车第一次拿到《ISO IEC 330022015》完整英文版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三类角色各一人单场访谈控制在四十五到九十分钟之间只听一种角色的说法很容易把局部体验当成全局事实。参数项常用取值说明每个过程域的样本项目数3-5个少于3个无法覆盖项目差异每个样本的工件数至少2类如计划记录或规范实例单场访谈时长45-90分钟太短问不透太长效率低每个过程属性的证据来源至少2个独立来源防止单一信息源失真数据验证是33002反复强调的环节核心是三个问题线索能否追溯到原始来源不同来源之间有没有矛盾评估员对同一份证据的理解是否一致。我一般在数据采集的中后期安排一次专门的验证会把收集到的证据逐条过一遍矛盾之处当场决定是补采还是降级使用。数据没验证就评级等于拿没校准的秤称重量。4.3 评级不是打分题N/P/L/F的判定规则与一致性校准评级是评估里最容易被误解成投票的环节。33020把每个过程属性的实现程度分为四级N不完整、P部分实现、L大部分实现、F完全实现。33002不在正文里教你怎么定义这四个词它要求的是评估组必须有一套预先约定的评级规则并且规则的执行结果是可复核的。我自己的做法是给每个级别配上证据表现评级时逐条对评级实现程度典型证据表现N0-15%没有制度或执行记录访谈对象也说不清P15-50%有零散实践但未制度化执行不稳定L50-85%主要活动有制度、有执行、有监督偶有缺口F85-100%制度、执行、监督三种证据齐备无明显缺口评级前必须做校准环节每个评估员先独立给每个过程属性打分再公开对照。两个人意见差一个级别以内讨论后统一差超过一级说明两个人对什么证据算数的认知都没对齐先别争论给几级回去看证据清单重新确认证据的定义。这个机制能有效避免强势评估员带节奏的问题。提示评级结论必须能指回具体证据。评委问你为什么是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 把能力等级宣传成成熟度等级对外口径翻车现象评估报告写的是某过程域达到能力等级2CL2宣传材料里却变成我们通过评估达到成熟度2级。有经验的客户过来一追问当场露馅。原因能力等级capability level和成熟度等级maturity level是两个框架的概念。33002配合33020评出的是过程属性级别的能力等级成熟度等级需要带成熟度模型的做法来支撑输出也不一样。解决对外材料统一措辞。如果只做了33002式的过程评估就写按ISO/IEC 33020评定XX过程能力等级为2级要宣传成熟度等级就必须走包含成熟度模型的评估方案。这个口径问题最好在评估启动时就写进评估输入别等宣传稿都发出去了再来做危机公关。6. 从22页到可执行把33002逐条改写成你组织的评估规程6.1 四步把标准条款转成内部核对表把33002落到自家流程里不需要把PDF翻译一遍然后贴在质量手册里那样只会落灰。我做过的有效方式是四步改写。第一步把每一条shall翻译成一个问题标准写评估输入应得到批准就改成我们的评估输入有发起人签字确认吗。第二步给每个问题指定责任角色和落点文件这个问题归发起人还是组长答案写在哪个文档里。第三步按评估阶段分组准备、采证、验证、评级、报告让每个阶段有自己的检查页。第四步用一次模拟评估检验这张表凡是找不到答案落点的问题就是流程里缺的环节补齐它。条款来源改写后的问题责任角色落点文件常见失败模式评估输入目的、范围、约束双方签了吗发起人组长评估委托书口头约定没签字数据采集每个过程域有3个以上样本吗组长评估计划样本数不足数据验证证据来源可追溯吗全体评估员证据清单只收不验评级规则评级结论能指回证据吗组长评级记录凭印象打分这套核对表用起来之后评估就不依赖某个人的经验了换一个评估组长照着表走结果依然稳。这也是33002这份标准最有价值的地方——它把评估从看人下菜变成了有章可循。6.2 给评估组长的预评估自检六问每次正式评估开始前我会拿着核对表做一次自检六问全过才开工。第一问评估目的和范围有没有人签字没有就回头。第二问评估员的独立性声明齐了没有第三问每个过程域的样本项目是否达到3个以上第四问访谈记录模板统一了吗归档责任人定了吗第五问评级规则有没有在评估组内过一遍校准会议排进日程了吗第六问报告的限制与偏差章节准备怎么写谁来审这六问问下来基本能拦住我在一线见过的大多数翻车。我早年第一次独立带评估时报告里只有结论没有依据客户在验收会上问我某个过程域为什么是F我在会议室翻了半小时也没找到支撑那条评级的证据。那是我做评估以来最尴尬的一场交付也让我彻底改了习惯评估报告先让一个没参与评估的同事当杠精读一遍专挑为什么打问号这个习惯帮我避掉了后续很多次返工。希望帮到你。本文还有配套的精品资源点击获取
