【全】CMMI3标准过程活动流程图
CMMI3级软件过程 第3章 立项管理
第3章立项管理立项管理（Project Initialization Management,PIM）的目的是：（1）采纳符合机构最大利益的立项建议被采纳，避免浪费机构的人力资源、资金、时间等。
立项管理是决策行为，其目标是“做正确的事情”（do right things）。
而立项之后的研发活动管理活动的目标是“正确的做事情”（do things right）。
只有“正确的决策”加上“正确地执行”才可能产生优秀的产品。
立项管理过程域是SPP模型的重要组成部分。
本规范阐述了立项管理过程域的三个主要规程：☆立项建议[SPP-PROC-PIM-PROPOSAL]。
☆立项审查[SPP-PROC-PIM-REVIEW]。
☆项目筹备[SPP-PROC-PIM-PREPARE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身的情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
3.1 介绍立项管理流程分为三个阶段：“立项建议阶段”、“立项评审阶段”和“项目筹备阶段”，如图3-1所示。
1．立项建议阶段立项建议小组应反复地进行立项调查，产品构思和可行性分析。
在深思熟虑之后，立项建议小组撰写《立项建议书》，并申请立项。
要注意的是，由于立项调查工作和可行性分析通常比较费时费力，往往被人忽视。
而草率撰写的《立项建议书》会有比较多的主观臆断，这对项目是有危害的。
产品构思通常不可能快速完成，切不可闭门造车。
深入地进行立项调查与可行性分析不仅对产品构思有帮助，而且对立项审查也有帮助。
2．立项审判阶段机构领导组织一个评审委员会进行立项评审。
评审委员会根据《立项建议书》、《立项调查报告书》以及立项建议小组的答辩，投票决定是否同意立项（按少数服从多数的原则）。
评审委员会根据机构的实际情况（发展战略、资金、人力资源等），对《立项建议书》提出改进意见。
(完整版)【全】CMMI3标准过程活动流程图
【EPG】组织过程定义与改进[OPD&OPF]组织发展战略规划《组织级方针》原有的组织过程资产【培训】组织培训[OT]过程开始《过程改进目标》 2.收集、汇总过程改进建议《过程改进建议表》原有的组织过程资产 3.评估组织现行过程《过程改进评估报告》或《差距分析报告》《过程改进建议表》《过程改进评估报告》或《差距分析报告》4.识别组织过程改进点《组织过程改进点列表》《过程改进目标》《过程改进评估报告》《组织过程改进点列表》5.制定过程改进计划并评审《组织过程改进计划》《组织过程改进进度表》《组织过程改进计划》原有的组织过程资产“ 6.建立和维护组织过程资产•J过程资产库（试用版）一过程资产库（试用版）《组织过程改进计划》7.在项目中试点改进后的组织过程资产《过程改进建议表》10.过程改进管理活动（跟踪和监控、配置管理、质量保证、度量等）过程资产库（试用版）《过程改进建议表》8.评估、部者新的组织过程资产过程资产库（正式版）过程资产库（正式版）•9.组织中全面实施推广+《过程改进建议表》《EP会议记录》《过程改进月报》《组织过程改进总结报告》《过程改进进展通告》《过程资产修订记录》i.确定组织过程改进目标《过程改进目标》过程结束【项目经理】立项过程[PIM]【项目经理】结项过程[PCM]------ ＞《项目已定义过程》------ A《项目估算报告》《项目计划》《风险管理计划及跟踪表》《质量保证计划》亠《配置管理计划》《项目进度表》《团队章程》-《项目计划评审报告》项目估算过程输入项目经理输出程过算估项目估算表结束【项目经理】项目监控[PMC]【项目经理】风险管理[RSKM]《组织风险列表库》《项目计划》过程开始1.风险识别2.风险分析3.风险处理尸4.风险跟踪■■5.更新《组织风险列表库》及通报风险状态I《风险管理计划及跟踪表》I过程结束【项目经理】度量分析[MA]4•收集和分析度量数据《项目进度表》《项目周报》《项目里程碑报告》《不一致项问题跟踪表》各类《评审报告》《测试报告》《项目变更记录》《项目问题跟踪表》《风险管理计划及跟踪表》过程开始3.制定《度量分析计划》【项目经理、需求】需求开发与管理[RDM]-需求开发过程《度量分析计划》5.存储和更新、通报度量结果项目度量库【项目经理、需求】需求开发与管理[RDM]-需求管理过程需求变更控制[VER]-同行评审过程-审查过程过程结束[VER]-同行评审过程-走查过程过程开始过程结束【项目经理、需求、设计、开发、测试、配置、QA】验证[VER]-同行评审过程-个人评审过程【项目经理、需求、设计】决策分析与解决方案[DAR]【设计】技术解决方案[TS]【开发】产品集成[PI]【测试】确认[VAL]【配置】配置管理[CM]过程开始【QA】质量保证[PPQA]《项目计划》《项目已定义过程》过程资产中的《组织过程检查列表》《组织产品检查列表》J 1.制定QA计划> 2.过程和产品质量检查r过程开始3.不一致项跟踪处理14.发布QA报告r过程结束《QA计划》《过程检查列表》《产品检查列表》《不一致问题跟踪表》E 《QA月报》「4《QA里程碑报告》《QA外部审计报告》。
CMMI3产品集成过程
产品集成过程XX公司变更记录修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（+删除说明）目录1. 引言 (1)1.1 目的 (1)1.2 适用范围 (1)1.3 名词术语 (1)2. 过程定义 (1)2.1 角色和职责 (1)2.2 入口准则 (2)2.3 输入 (2)2.4 过程活动 (3)2.4.1 制定产品集成计划 (3)2.4.2 审查接口的兼容性 (5)2.4.3 组装产品组件 (6)2.4.4 验证活动 (6)2.4.5 产品交付 (7)2.5 输出 (8)2.6 出口准则 (8)2.7 过程度量 (9)2.8 裁剪说明 (9)3. 相关指南 (9)1.引言1.1目的把产品构件集成成产品，确保所集成的产品恰当地发挥作用，确保交付产品。
1.2适用范围适用于项目实施过程中的软件集成阶段。
1.3名词术语✧EPG：Engineer Process Group（工程过程组）✧PP：Project Plan (项目计划)✧产品集成(Product Integration)：把产品组件组装成为更复杂的组件或者完整的产品，保证产品是被集成的、功能是完善的，并最终提交产品。
✧产品组件(Product Component）：产品组件通过集成“建造（build）”产品。
产品组件有很多层。
它是任何被工程化了（需求已定义、设计已开发并且已经实现）的工作产品，这些工作产品的需求、开发和实现是为了满足最终产品的功能，或者是为了交付给用户。
✧产品组件需求（Product-component Requirements）：对产品组件的一个完全的规格说明，包括应用范围、格式、功能、实现以及其他需求。
2.过程定义2.1角色和职责2.2入口准则✧《概要设计说明书》文档已经完成，并形成基线。
2.3输入✧《概要设计说明书》。
2.4过程活动图2-1过程管理活动流程图2.4.1制定产品集成计划项目经理指定合适的项目组成员负责产品集成工作，产品集成工作首先要制定产品集成计划，计划的内容包括：确定集成顺序、集成的环境、以及制定集成标准。
cmmi软件开发流程图
软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
➢对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。
➢关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
CMMI v1.3 流程图
过程与产品质量保证 (PPQA)
SG1 客观评估过程和工作产品 (Objectively evaluate processes and work products)
SG2 提供客观的洞察力 (Provide objective insight)
SP1.1 Objectively evaluate processes 客观评估过程 SP1.2 Objectively evaluate work products 客观评估工作产品 SP2.1 Communicate and resolve noncompliance issues 沟通并解决不符合项 SP2.2 Establish records 建立记录
CMMI
支 持 类 过 程 域
配置管理 (CM)
SG1 建立基线 (Establish baseline) SG2 跟踪和控制变更 (Track and control changes)
SG3 建立完整性 (Establish Integrity)
SP1.1 Identify configuration items 识别配置项 SP1.2 Establish a configuration management system 建立配置管理系统 SP1.3 Create or release baselines 建立或发布基线 SP2.1 Track change requests 跟踪变更请求 SP2.2 Control configuration items 控制配置项 SP3.1 Establish configuration management records 建立配置管理记录 SP3.2 Perform configuration audit 执行配置审计
CMMI3级软件过程 第17章 配置管理
第17章配置管理配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。
☆制定配置管理计划[SPP-PROC-CM-PLANNING]。
☆配置库管理[SPP－PROC－CM-LIB]。
☆配置项版本控制[SPP-PROC－CM－VERSION]。
☆配置项变更控制[SPP－PROC－CM－CHANGE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改规范，然后推广使用。
17.1 介绍项目研发和管理过程中会产生许许多多地工作成果。
例如文档、程序和数据等，它们都应当背保存起来，以便查阅和修改。
如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。
毫无疑问，人们应当将文件分类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主要有两大类：●属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。
●项目管理和机构支撑过程域产生的文档。
这些文档虽然不是产品的组成部分，但是是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。
所有配置项都被保存再配置库里，确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。
基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。
基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：名称、标识符、版本、日期等。
cmmispp各阶段流程图
CMMI SPP各阶段流程图:
•立项管理流程
•结项管理流程
•项目规划流程
4
•项目监控流程
•风险管理流程
•需求管理流程
*需求开发流程
*技术预研流程
工作咸果介鉛
技术评审
*系统设计流程
•实现与测试流程
複块微陷管理与改錯
代码审查
单元测试
软
件
系
蜒
«系统测试流程
甫批审批迭代
制
定
测
试
计
划
设
计
测
试
用
例
执
行
系
统
测
试
缺
陷
筲
理
与
改
错
• Beta测试流程
•客户验收流程
*技术评审流程
•配置管理流程
p------------------------------
3-
—
all
™
—
-
配
置
审
计
------------------------------
*质量保证流程
*外包与采购管理流程
•培训管理流程
•服务与维护流程
客户服务堆备—►接收客户要求—►响应客户要求
产品维护准备一►接收并吏爛錐护要或一►执行维护工作。
CMMISPP各阶段的流程图
CMMI SPP各阶段流程图：•立项管理流程•结项管理流程•项目规划流程•项目监控流程•风险管理流程•需求管理流程•需求开发流程•技术预研流程•系统设计流程•实现与测试流程•系统测试流程•Beta测试流程•客户验收流程•技术评审流程•配置管理流程•质量保证流程•外包与采购管理流程•培训管理流程•服务与维护流程CRM系统培训讲座提纲：•CRM产生的背景•CRM的概念•CRM的组成部分•CRM的作用•CRM的主要功能模块•CRM的现状和前景•CRM的战略•呼叫中心与CRM•如何实施CRM•CRM 产生背景1990年前后，许多美国企业为了满足日益竞争的市场需要，开始开发销售力量自动化系统(SFA)，随后又着力发展客户服务系统(CSS)。
1996年后一些公司开始把SFA和CSS两个系统合并起来，再加上营销策划(Marketing)、现场服务(Field service)，在此基础上再集成CTI（计算机电话集成技术）形成集销售(Sales)和服务(Service)于一体的呼叫中心(CallCenter)。
这样就逐步形成了我们今天熟知的CRM。
特别是Gartner Group正式提出CRM（Customer Relationship Management）的概念，也加速了CRM的产生和发展。
狭义来讲，CRM客户关系管理的技术载体就是Call Center,1998年以后随着电子商务的兴起，CRM向eBRM/eCRM方向发展。
二、CRM的概念什么是客户关系管理（CRM）？简单定义，CRM是一个获取、保持和增加可获利客户的过程。
CRM是首先是一套先进的管理思想及技术手段，它通过将人力资源、业务流程与专业技术进行有效的整合，最终为企业涉及到客户或消费者的各个领域提供了完美的集成，使得企业可以更低成本、更高效率地满足客户的需求，并与客户建立起基于学习型关系基础上的一对一营销模式，从而让企业可以最大程度的提高客户满意度及忠诚度，挽回失去的客户，保留现有的客户，不断发展新的客户，发掘并牢牢地把握住能给企业带来最大价值的客户群。
CMMI3培训
CMMI3培训组织培训规程主讲人：主讲人：张海葵杭州中软安人网络通信有限公司二○○五年十月1.目的和范围 1.目的和范围2..目标 2..目标3.角色与职责3.角色与职责4.进入条件与输入4.进入条件与输入4.1 进入条件 4.2 有效输入5.组织培训总体流程图 5.组织培训总体流程图6。
培训计划阶段6.1 培训需求调查 6.2 培训需求分析 6.3 制定年度培训计划7。
实施培训阶段7.1 准备培训工作7.2 实施培训步骤8。
总结评估阶段8.1 维护培训记录8.2 评估培训效果8.3 改进培训8.4培训资料入库8.4培训资料入库9. 输出与退出条件9.1 输出9.2 退出条件021.目的和范围 1.目的和范围企业要在高度竞争的市场经济中获胜，一定要拥有高素质的人才，而员工培训与开发是提高素质必不可少的一环。
从某种意义上说，一个企业是否重视员工培训与开发可以预见其未来的竞争潜力。
为了适应环境变化，满足市场竞争的需要，满足员工自身发展的需要，最终达到提高企业效益的目的，制定本规程的目的是为中软安人所有组织培训管理提供指导。
为确保组织培训工作能够稳健有序的得到执行，所有项目应遵照本程序，加以执行。
032.目标2.目标―明确组织培训需求，确保培训需求与公司商业目标相一致―寻求并提供满足需求的培训―建立组织培训能力―建立组织培训记录3.角色与职责角色高层领导(包括总经理和副总经理) 培训组以上的高层领导培训组(包括培训经理和培训成员) 培训经理职建立组织的商业目标提供培训资源责批准组织培训计划评审培训过程的执行检查培训过程改进执行培训过程分配培训任务检查培训的成果和进步培训需求调研根据组织的商业目标，识别组织今后所需要的培训制订公司培训计划并监督执行按期向公司领导汇报培训进程和状态与相关部门协商培训任务的分配以及培训讲师的安排按计划组织并实施培训活动将培训过程状态及时向培训经理反馈管理并更新培训记录和培训教材培训成员项目经理编写项目培训计划并加以执行分派项目培训任务提供项目培训记录给培训组评审公司培训计划，并检查计划的执行批准项目培训计划并为项目培训提供支持参加培训，填写《培训评估反馈表》提建议改进培训过程检验项目培训记录客观评价培训组的培训活动和产品部门经理参加培训者SQA4..进入条件与输入 4..进入条件与输入4.1 进入条件―指定培训负责人和培训人员―培训组成员经过特殊培训―有足够的人力，足够的资金和适当的工具来实施培训程序 4.2 有效输入―培训程序规则―软件相关的角色技能矩阵―项目任务分解和项目组计划表5.组织培训总体流程图5.组织培训总体流程图开始培训计划阶段确定培训需求制订培训计划否审批是培训准备阶段培训实施阶段培训总结评估阶段准备培训实施培训建立培训记录评价总结培训效果培训资料存入财富库结束6. 培训计划阶段年初，培训组需要制订公司的培训计划以确保培训能够有计划的实施，该阶段就描述了组织培训计划的过程。
CMMI3级软件过程 第21章 服务与维护
第21章服务与维护服务与维护（Service and Maintenance, SM）是指产品销售之后的客户服务和产品维护。
客户服务和产品维护的宗旨就是提高客户对产品以及对开发方的满意度。
服务与维护过程域是SPP模型的重要组成部分。
本规范阐述了服务与维护过程域的两个主要规范：☆客户服务[SPP-PROC-SM-CS]。
☆产品维护[SPP-PROC-SM-PM]。
上述每个过程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力）适当的修改本规范，然后推广使用。
21.1 介绍当产品开发完成并开始销售时，原开发小组应当解散，以便人力资源重新分配。
其中大部分的开发人员将参加新的项目，只需要留一小部分人员从事客户服务和产品维修工作。
对于合同项目，客户服务和产品维护的周期、费用等在合同中决定。
对于自主研发的产品而言，一般的，客户服务和产品维护工作将持续到产品退役。
客户服务和产品维护的流程如图21-1所示。
图21－1 客户服务于产品维护流程客户服务的重点是为客户服务与产品相关的服务(如技术咨询)，快速响应客户的要求，给客户一个满意的解答。
产品维护可分为两大类：☆纠错性维护。
由于软件产品过程中的测试不可能揭露所有的错误，用户在使用软件时仍会遇到错误，诊断和改正这些错误的过程称为纠错性维护。
☆完善性维护。
在软件产品正常使用的过程中，客户还会提出新的要求。
为了满足客户的需求而不断改善产品功能和质量的活动称为完善性维护。
如果需求变更比较大，那么完善性维护将转变为新版本的开发（即新的项目）。
纠错性维护是必需的、强制的，而完善性维护则要根据产品开发战略、开发方财力和资源等因素而定。
服务与维护过程域的主要文档有：☆《客户服务计划》，模板见[SPP-TEMP-SM-CS-PLAN]。
☆《客户服务报告》，模板见[SPP-TEMP-SM-CS-REPORT]。
CMMI3项目过程表——精简后
1. 用户需求规格说明书； 1、规模估算表（功能点） 2. 架构设计说明书 2、项目工作量估算表 《项目章程》 《立项评审会议记录》 启动阶段审计报告 启动阶段总结报告 项目配置库、《项目配置库 相关信息》
1-6 1-7 2-1
编写项目章程 项目章程评审 启动阶段审计 启动阶段总结 创建项目配置库
启动阶段所有的工作产品 N/A 《项目配置管理计划》
1、《项目里程碑总结检查 单》 2、项目该阶段运行情况， 如： 3-13 里程碑总结与里程碑总结会议 《项目里程碑总结报告》 •《项目度量与分析报告》 •《质量审计报告》 •《风险列表》 •项目经验教训总结结果 当以下情况发生时，需进行 重新估算： 1、项目的需求变更时； 2、项目阶段总结会之后； 3、或根据项目进展情况需 要重新估算时。 需要提供： 1、《用户需求规格说明书 》 2、《架构设计说明书》 3、历史项目数据
3-6
项目度量与分析
3-7
变更控制
3-8 3-9
风险管理 版本控制及基线管理
3-10 配置状态统计和报告
3-11 配置审计
《配置审计检查单》
项目过程文档使用指南 1、《项目质量审计检查单 》（《项目质量审计报告》 中） 《项目质量审计报告》 2、所有被审计的项目阶段 的工作产品
3-12 阶段质量审计
4-10 基线化详细设计
4-11 项目周例会及周报
4-12 项目度量与分析
4-13 变更控制
4-14 风险管理
4-15 配置状态统计和报告
项目过程文档使用指南 1、《配置审计检查单》（含 审计结果） 2、配置审计报告（包含在《 项目质量审计报告》中） 3、项目配置状态报告
4-16 配置审计
《配置审计检查单》
CMMI3同行评审详细过程定义讲解
同行评审4.1同行评审与测试的关系发现缺陷的手段为什么要引入同行评审而不是继续完全使用测试呢？有些工作产品在早期阶段就可以进行同行评审去发现缺陷，但无法对其进行测试；即使到了编码阶段，测试活动也不能发现某些特定类型的缺陷（例如违反编程规范）。
从图4-1（开发各阶段缺陷放大图）可以看出，随着开发的不断开展，缺陷不断泄漏和放大，最终形成的产品是一个灰色的距离用户真正需求很远的一个"东西"。
这就需要在开发的过程中不断进行同行评审，减少泄漏到下一个阶段的缺陷。
成功的同行评审是提高质量和生产率的重要因素，不管人们喜欢与否，审查过程会迫使每个人在一种开放式的环境中工作。
一旦人们懂得了他们的工作都要接受同行评审，他们就会越早地将他们的工作公之于众，以待监督。
在同级评审上的投入把组织的一些质量成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。
更重要的是，工作产品的作者学到了如何将工作做得更好，从而避免了缺陷。
固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量，但这些可以在测试中节省更多。
从经济角度考虑，许多缺陷是在早期阶段注入的，越早消除缺陷就越能降低开发成本。
据统计，对于保存精确记录的大系统，一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。
这样一来，即使在综合考虑了同行评审活动成本的情况下，同行评审活动也会使测试成本下降50%～80%。
同时，通过同行评审，开发人员能够及时地得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，在一定程度上提高了开发生产率。
再者，消除工作成果的缺陷，可以提高产品质量，提高客户满意度。
（点击查看大图）图4-1 开发各阶段缺陷放大图总之，同行评审有助于"提高质量、提高生产率、降低成本"。
但是要注意，同行评审不可能代替测试，正如测试不可能替代同行评审一样。
那么，工作产品通过了什么样的评审才算合格呢？同行评审本身的要求有没有在质量目标里？评审的工作量和参加人员的资格、评审时间是否有要求呢?4.2 同行评审的种类和对象同行评审活动的关注点应该是工作产品中的缺陷，而不应该是工作产品的作者或者生产者，管理者也不应使用同行评审的结果去评价个人的行为。