项目风险管理的常见问题和对策

引言
项目风险管理相对于企业全面风险管理，主要关注项目范围之内的风险，所关注风险相对比较具体，涉及总的影响范围较小，一般地采用定性分析方法。 在定性项目风险管理中，本文指出了五个方面的问题，并给出了对策。
1，用词问题
各大标准/最佳实践中也都有风险管理的内容，其中用词并不一致。在多个标准/最佳实践的导入中产生了由于用词理解不一致而发生的误解，在业界交流讨论时也多有不便。
风险，没有其它用词，但本身有二个不同含义：一种定义强调了风险表现为不确定性；而另一种定义则强调风险表现为损失的不确定性。这二个不同含义简直就是导致用词不一致的根源。现在大多数标准采用第一种定义，但停留在各级管理者头脑中的定义仍是第二种
风险管理，在有些地方又叫“危机管理”，不过一般对危机管理的理解与风险管理并不一样，危机管理更偏重于危机发生后的管理。
风险应对，在PMP中是指在风险识别以后到风险触发或关闭之间采取的促使风险向有利方面转化的方案和措施，在CMMI中相应的词是“风险缓解”，也有地方用“风险处置”，“风险处理”。 本文下文中使用“风险应对”。
风险应急应对，在PMP中“对某些特定事件，专门设计一些应对措施。对于有些风险，项目团队可以制定应急应对策略，即只有在某些预定条件发生时才能实施的应对计划。如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略。应该对触发应急策略的事件进行定义和跟踪，如未实现阶段性里程碑，或获得供应商更高程度的重视。”，一般而言，这是指风险触发后或预计必定触发后的方案和措施。其它用词有“风险应变”，“风险应急”。
风险可能性，指风险发生的可能性，其它用词有“风险概率”。
风险影响，指风险发生的冲击，其它用词有“风险影响的程度”，“风险严重级别”。
危险性，其它用词有“风险值”。
接受风险，其它用词有“承受风险”，“保留风险”，“保持风险”。
避免风险，有“回避风险”，“规避风险”。
转移风险，有偏转风险
减轻风险，有“缓解风险”，“控制风险”，“降低风险”注意：与前文有冲突。
风险触发器，其它用词有“风险征兆”，“警示信号”。

对此问题，对策是在一定的组织范围内对风险用词给出定义，比如在风险管理规程中专门进行词汇定义。
2，认识问题
20世纪80年代，软件风险管理之父Boehm将风险管理的概念引入软件界。Boehm认为:软件风险管理这门学科的出现就是试图将影响项目成功的风险形式化为一组易用的原则和实践的集合，目标是在风险成为软件项目返工的主要因素并由此威胁到项目的成功运作前，识别、描述并消除这些风险项。
在CMMI过程域中，风险管理过程域是关联度最高的过程域之一。与风险管理明确相关的过程域目标有：
1，需求分析过程域的特定目标3：分析并确认需求
2，需求管理过程域的特定目标1：管理需求
3, 项目计划过程域的特定目标2：建立和维护开发项目计划
4, 项目监控过程域的SG 1：按照计划监控项目
5, 供应商管理过程域的SG 1：建立供应商协议
6，集成项目管理过程域的SG 1： 使用项目定义过程
7, 技术解决方案过程域的SG 1：选择产品组件解决方案
8, 决策分析及决议过程域的SG 1 ：评估备选方案
9, 产品集成过程域的SG 1： 准备产品集成
10, 组织过程焦点过程域的SG 2： 策划与执行过程改进
11, 组织培训过程域的SG 1：建立组织培训能力
等等不完全列举
在PMP中，风险管理是9大领域之一。

从以上大师的论述、CMMI的相关性、PMP中的篇幅，可以充分看到风险管理的重要性。

3，风险的表述问题
风险在表述时，用多个属性来综合说明风险的全部内容，常见的风险属性有：标题、说明、负责人、应对措施、时间要求、风险概率、风险影响度等等。
必备的属性有标题和说明（也有称为描述）
常见的一个突出问题是没有对风险的标题给出指导或要求，各项目识别的风险标题差异明显，如下面的例子：

• 存在工期延误的风险
• 过多的支持工作占用工作量可能导致工期延误
• 频繁的需求变更可能导致项目规模变大，成本超支，工期超期，人员士气低落而离职
• 频繁的需求变更、过多的故障现场支持还有人员意外离职都可能导致项目工期延误

类似第一个风险标题，没有说明风险来源，只说了后果，在实践中有如下不利之处：

1. 不能直观理解，仅从标题不难了解可能的困难。
2. 在风险的说明中，把多个风险来源写在一起，相应的应对措施也放在一起，不利于分别跟踪，可能导致只跟踪了部分诱发困素。
3. 风险难于高效地有效地跟踪到关闭，由于多种风险来源能够导致相同的后果，风险长期得不到关闭，会产生风险麻痹。

类似第二个风险标题，说明了一个风险来源及相应的一个后果，这样应对措施可以针对这个诱发困素，应变计划针对这个后果，可以高效且有效的跟踪风险直到关闭。

类似第三个风险标题，说明了一个风险来源及相应的多个后果，这样应对措施可以针对这个风险来源，由于是同一因素引发的后果，应变计划虽然要处理多个后果，但是相对应容易制订。在着重预防的风险应对中，能够清晰识别并管理应对措施，也是不错的做法。

类似第四个风险标题，说明子多个风险来源及相应的一个后果，这个写法的不利之处与第一种写法相似，相对好一点的地方是限定了风险来源的范围，但总得说来，也是不推荐的写法。

对此问题，对策是优先采用上述类似第二个风险的写法，可以采用上述类似第三个风险的写法。

4，风险的跟踪问题
常见的风险跟踪问题主要有二类：第一类是轻视风险管理；第二类是没有预先考虑风险发生的条件。

对于第一类问题，主要发现为风险不及时跟踪，过程中不主动识别，认识问题是主因。前期加强宣导、培训，在过程中保持关注，恰当地进行监督是这类问题的对策。

对于第二类问题，过程中的风险发展是一个渐变的过程，有些风险的渐变比较缓慢，因此在风险跟踪中比较容易错过采取措施的第一时间。所以预先考虑风险发生的条件是很有必要的，做法是设立风险触发器，风险触发器说明风险已经发生或者将必然发生。比如对于第3章中第2个例子，风险触发器可以是“当连续两周支持工作量比重超过了50%”，或者是“到X年X月X日，累计支持工作量比重超过40%”。风险触发器中设立日期期限是个推荐的做法，这样会较容易监控这个触发器。为争取第一时间，风险触发器设立时，应优先更注预警信号。比如对于第3章中第3个例子，触发器1设成这样“一期工程完工日期较计划延迟二周”，触发器2是这样“变更后的项目规模超过了原计划估模的130%”，比较一下就发现，触发器2是能更早地捕捉风险的发生，也就能更多地争取到时间和调整空间。

5，可操作性问题
风险识别之后的应对措施是保证风险向有利方面转化的关键过程。以下是应对措施的实例。
1, 加强交流，保持沟通

2, 密切注意里程碑工期偏差

3, 对新员工开展Java工作流方面的培训

以上应对措施的通病是不具备可操作性，可操作性有三个要素：人员、时间和任务，包括三个要素的应对措施一般来说都是可操作的。改定上述三个实例得下。

1, 张三每双周电话联络用户代表李四

2,项目经理每周进行里程碑工期偏差估计

3,王五在6月底之前在Java工作流方面来培训新员工

风险管理中的用词问题

风险管理的重要性无需再说明，在各个领域几乎都有风险管理。
各大标准/最佳实践中也都有风险管理的内容，其中用词并不一致。在多个标准/最佳实践的导入中产生了由于用词理解不一致而发生的误解，在业界交流讨论时也多有不便。

本文列举一些，来看看中文用什么词更合适。风险管理的国际标准据说就要出来了，国内的翻译恐怕仍将是众矢之的。

• 风险，没有其它用词，但本身有二个不同含义：一种定义强调了风险表现为不确定性；而另一种定义则强调风险表现为损失的不确定性。这二个不同含义简直就是导致用词不一致的根源。现在大多数标准采用第一种定义，但停留在各级管理者头脑中的定义仍是第二种。[建议用第一种定义]
• 风险管理，没有其它用词
• 风险识别，没有其它用词
• 风险分析，没有其它用词
• 风险应对，在PMP中是指在风险识别以后到风险触发或关闭之间采取的促使风险向有利方面转化的方案和措施，在CMMI中相应的词是“风险缓解”，也有地方用“风险处置”[建议用风险应对]
• 风险应急应对，在PMP中“对某些特定事件，专门设计一些应对措施。对于有些风险，项目团队可以制定应急应对策略，即只有在某些预定条件发生时才能实施的应对计划。如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略。应该对触发应急策略的事件进行定义和跟踪，如未实现阶段性里程碑，或获得供应商更高程度的重视。”，其它用词有“风险应变”，“风险应急”，一般而言，这是指风险触发后或预计必定触发后的方案和措施[建议：风险应变]
• 风险可能性，指风险发生的可能性，其它用词有“风险概率”，[建议：风险概率]
• 风险影响，指风险发生的冲击，其它用词有“风险影响的程度”，“风险严重级别”[建议：风险影响度]
• 危险性，其它用词有“风险值”,[建议：风险值]
• 接受风险，其它用词有“承受风险”，“保留风险”,[建议：接受风险]
• 避免风险，有“回避风险”，“规避风险”,[建议：避免风险]
• 转移风险，似乎没有其它用词
• 减轻风险，有“缓解风险”，“控制风险”，注意：与前文有冲突，[建议：减轻风险]
  

导入标准的两层皮问题

在公司推进各项标准建设中，难免出现两层皮的问题。 表面上符合了各项标准，实质上是另外一套，没有符合标准。
典型的两层皮做法：
1,选择少数样本在一个小的时间范围内来满足标准，应付标准检查。
2,把标准的导入看成是短期项目，认证或评估结束后恢复旧样。
两层皮产生的原因
主要有:
1, 原有方式方法难于改变
2, 标准的某些强制要求过高，而且效率低下。比如ISO27001中的软件白名单、信息资产穷举、CMMI中的代码需求双向可追溯性等等。
两层皮的后果
两层皮的后果也是不利的，本来引来标准是要有正面收益的，两层皮之后，反而是负面收益，费了很多工夫搞标准，而实质上没有改进，看起来就是在繁忙的工作 之外还要搞标准费时费力。
导致两层皮的不当理解
不当理解1：“标准导入完全是正常工作之外的额外工作”。导入标准应当是工作本身的一部分，没有导入标准, 也是要总结经验教训，下一步改进的。标准一般是某个领域的最佳实践,是前人经验和智慧的集中.
不当理解2：“这部分是标准范围，那部分不是”。本身这句话没有错, 某个标准总有其适用范围, 问题在于随意的设定标准范围, 无视标准范围真正的维度, 在适用的范围内限制标准的应用, 并美其名日:消化吸收, 拿来主义, 或是结合自身实际情况。
以CMMI为例,CMMI是软件工程多年来实践的经验总结，其范围与软件工程这门学科的范围基本一致。诚然CMMI 是有不适合范围的，主要在于个人绩效考核方面，而不在于项目类型，不在于项目参与方过多，不在于工程部门是否参与，也不在于产品还是工程.
不当理解3：搞标准就是搞文档，文档齐了就可以。听说业界的ISO9001就是顾问公司给一批文档，换个抬头，就可以过ISO9001。早期CMM引入中国的时候留下了这个印象。现在研发部的需求文档已经不是强制要求，设计文档只需要5~6 页。“用最少的文档达到业务的需要”才是CMMI的要求。
不当理解4:"通过标准的认证或评估是要达到的目标", 对于独立核算的组织而言, 利润才是目标；对于不独立核算的组织，高绩效才是目标，CMMI及其它标准 是为了达成目标的方法、手段。在过程改进中，时时保持对绩效的关注，一切改进都是为了绩效或利润。当然有些标准更加关注长远利益。
如何避免两层皮现象
管理者代表对导入各类标准的战略目标应当有准确的认识，如果管理者代表以通过某标准为唯一目标，就是为了拿张证书，那么两层皮几乎必然出现。
标准导入层在导入标准时，应对牵记绩效利润优先，切身为标准执行层考虑问题，避免利用导入标准的授权来过分显示个人或小团体的权威。在标准导入与绩效利润冲突时，对上对下要有充分沟通，在上级的支持下可以设立一些检查惩罚措施。
在标准适用范围方面慎重考虑后，与上级达成一致共识，正式宣布。在这方面虽然可以征询执行层的意见，但不能为执行层左右。
培训标准执行层的意识是标准导入的重点。从实际看，标准导入后在技术上的难点都是可以克服的，有些改变是极其简单的（比如垃圾分类，U盘登记等），技术改变的困难往往是借口，真正困难在于意识。 大多数直观的认识是导入标准是额外工作、是负担。

诱因分析的常见方法

1, 鱼骨图法 也叫石川图
在QC活动发布中，这个方法被强制使用，常说的“人机料法环”给出了一个清淅的鱼骨框架。
2,五问法
3, 帕累托法
4, 麦肯锡 MECE

组合应用以上方法可以获得更好的效果。以下提出一个实践的步骤。
1,首先选一个鱼骨图的大框架，常见的有“人机料法环”，这在QC活动中有详尽说明，
还有从过程的几大方面“输入”，“输出”，“用什么”，“做什么”，“谁”，“如何校验”来考虑。 管理类问题从“人事时地物”来划分。
2,其次，按照选定的大框架来收集信息，以MECE（穷尽但不重迭）为原则来收集各方面的客观信息。
3, 在某些方面如果有分类统计的机会，应用帕累托方法，以数字来说明主要原因。如果有假设校验（一种数学统计分析方法）的机会，应用这个更为复杂的统计分析方法，参见6西格玛。在实际工作中，应用复杂数学分析的机会其实不多，如果一个问题可以应用数据分析，反而这个问题容易分析了。
4, 对认定的事实或主要原因进行五问法分析
5, 最后结论和对策从五问法中导出

如何高效地接待现场咨询

这里指的接待现场咨询是指作为甲方来接受咨询方的服务；而不是办一个现场咨询，接受公众的提问。
在不少咨询服务中，收费是按现场时间来计算的，因此提高现场咨询的效率是很有好处的。
最近几次现场咨询中,连续看到了多次效率不高的咨询接待。先来看看低效的咨询接待，罗列一下。
1，所有似乎相关的人员（总数>10)全部出席，准备的议程不足，中间不断有人提出新的话题。
2，请咨询师点评内部已经达成共识的文件，但只有1~3个人陪同，最后也没有其他/她人员共同参与。
3，没有准备，请咨询师按照咨询师的顺序进行，要相关人员出场时，相关人员不在。

首先，如果自身对情况和相关内容不熟悉，不能在内部识别问题的话，把时间和议程交给咨询师是个不错的做法，把咨询的主要诉求提前与咨询师沟通，请咨询师安排议程和所需人员，虽然这样做效率不是最高，但至少能保证咨询的有效。如果咨询师已经在内部作过调研，比较了解的话，也会主导一个高效的咨询，当然咨询师在内部的了解是要付出成本的，而且是不小的成本。

本文的重点是如何主动的接受咨询，对自身情况有所了解、可以识别部分问题的情况下，如何来组织高效的接受现场咨询。
Entry
1, 识别咨询需要，
典型咨询需要有：

• 内部无法达成共识的地方
• 内部执行中的困难
• 推进新事物的改进方案
• 有疑虑的改进方案

2, 识别出场人员，协调时间和场地，制订现场议程
特别建议在现场议程的最后安排一个相关人员的小结会，在咨询师在场的情况下，确认达成的共识。
3, 按约定提前把相关材料发送给咨询师，让咨询师有时间做好作业
Task
1，按准备的议程进行，现场伴同人员控制时间，邀请相关人员在需要的时候出场
2，小结现场咨询达成的共识
Verify
1, 准备的议程是否全部完成
Exit
1, 咨询纪要或联席会议纪要或记录达成共识的其它文档得到发布。

如何开展一次高效的讲座式培训

这里“一次”的意思是指这个培训还没有计划成为长期重复的培训，有可能讲完这次，就不再讲了。这种情况比较常见，就算是后来成为一个长期重复培训，第一次的时候还并不知道这个培训会重复。 一般采用讲座式培训是较经济的做法，所需准备时间较短，讲座时间也较短。体验式培训在这种“一次性”培训时显得过于奢侈。
Role角色
1，讲师：在一次性的培训中，讲师是承担任务的最主要角色，本文是以讲师的身份来书写的。
2, 学员：参加培训的人
Entry 进入条件
一次性培训应当根据培训需要来安排，培训需要一般有三个途径：1,来自学员，学员在碰到某些新事物时主动提出培训需要；2, 来自领导，领导试图推进某些事情时提出培训需要。
3, 来自讲师，讲师有新东西要和大家分享。
第1种来自学员的培训需要是最有可能带来一次高效的培训，第3种来自讲师的培训需要是最有可能带来一次泛味的培训。因此，珍视第1种培训需要，慎重处理第3种培训需要。
讲座式培训的时间与一般的讲座时间相当，一般不会超过4小时。
Task任务
讲座前任务
1, 讲师进一步收集培训需要，了解学员当前的背景知识和当前面临的问题，要照顾大多数的学员。
2, 协调确定讲座的时间，制作培训材料，在时间允许的情况下，实例越多越好，尤其注意要有反面实例。
3,请1~2位同伴或学员复查这个培训材料，如果是特别重要的培训，可以试讲。
4,培训材料根据反馈意见建议修改。
5,预订讲座场所，分发讲座通知。
讲座时任务
1, 准时开始，开场白，请大家签到。
2, 花3~5分钟时间，请学员谈一下培训的期望，“特别想要了解什么”。
3, 说明提问的规则，可选的有：1,随时可以打断；2,每小节安排；3,全部讲完再提问。
4, 进行讲解，实例讲解可能是最吸引人的部分，值得多花一些时间。
5, 提问和问题
讲座后任务
1, 简单回顾，修改培训材料（也许以后还会用），根据情况分发或不分发材料。
Verify 验证
1, [可选]向学员发放调查问卷
2, [可选]个别了解培训效果
Exit退出
1, 学员在讲座上的问题得到解答，无法或不必在讲座上解答的问题进行私下交流
2, 发放学员所需的材料
3, [可选]得到调查问卷结果

高效推进过程执行的一个方法：主题单项奖励

在颁布了一套新过程/规程时，或者发现某个领域过程/规程执行不力时，可以采用主题单项奖励的方法。
1, 选择一个主题：比如“让会议更高效”，或者“让PPT更能打动客户”
2, 安排本主题活动的组织者，如果有自荐者或者过程的推动者，最好。
3, 选择安排评委，评委数量要适当多一些，要有覆盖度，请评委制订评分标准和计分规则，确定参与活动的范围和对象，对于有些主题，可以规定符合范围的对象必须参加；参加对象可以是团队，也可以是个人，看主题来确定对象。
4, 颁布正式主题周活动通知，评分标准也要公布，计分规则，物质奖励也要公布。
5, 提交和收集活动的工作产品，如果有现场观察环节，要安排评委，一般建议针对工作产品来评分，现场环节评分的操作难度较高，在一定条件下也是值得安排的，要注意避免对正常工作的过多干扰。
6, 评委独立评分
7, 汇总公布，进行适当的物质奖励。

独立测试团队在敏捷开发中的几个特别实践

最近读了《我和敏捷团队的五个约定》（from InfoQ），很是赞同，不少来自于传统方法，似乎并没有体现敏捷团队的特点。哪么在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践？
这个内容与软件密切相关，转移到了http://hespr.blogspot.com/2009/03/blog-post.html

有效过程特征的表达方法：CMMI的过程域

CMMI的过程域主要组成如下：

1，概述

      目的

2，特定目标1

    特定实践1.1

3，特定目标2

    特定实践2.1

......

n  通用目标

通用目标下的通用实践对于任何过程域都是一样的。

大量的书和文章介绍了过程流程，包括国际标准，个人看法：CMMI的写法是最有效的，既便于学习执行，也便于检查。

高效会议过程域特定目标1: 使必要的会议高效的进行

特定目标1G1: 使必要的会议高效的进行

特定实践1.1 SP1.1: 识别必要的会议

1, 判断会议是否需要

   a，1对1交流不能解决问题

   b，会议的组织者是否存在

   c，会议的主题是否符合当前的时间，不必过早安排尚未到时的会议

特定实践1.2 SP1.2:会前准备

1,确定希望达到的结果

2,确认会议召开

3,请适当的人出席

4,准备背景资料

5,设定会议提纲和时间表

6,预先设想可能发生的冲突

7, 安排会议的主持人

8, 会前2小时之内准备：检查会议场所和设备，如有必要，再次通知会议参与人员，检查会议材料是否就绪，包括实体材料和电子档材料

9, 准备或确定达成会议决议的方法和流程，对于某些特定会议（比如董事会），这是已经确定的

特定实践1.3 SP1.3:会中进行

1, 会议主持人开场，简介会议目的、会议出席人员和所需大约时间

2, 按照议程开会

3, 避免跑题

4, 避免开小会

5, 保持会议目标，达成共识或决议

高效会议过程小议之一:低效会议罗列

在我经历的这么多会议来看，80%的会议是低效的，因此在讨论高效会议过程之前，先来看看低效会议。
1,会议室没有预订，开到一半被赶出。
2,会议室空间小，后面的人进来发现没位，再要自己去拖椅子，等椅子拖完，会议已经延期了10分钟。挤挤的开会，也很压抑。
3,会议室设备没准备好，大家都来了，会议组织者还在调笔记本和投影仪之间的连接，死活投不上去。
4,10个人甚至更多开一个头脑风暴会议，必然有2~3人 索然无味，并没有参与讨论。
5,并不是计划一个头脑风暴会议，但是会前没有准备讨论的草案，会议变成没有标的的讨论，费时也未必能达成共识。
6,会议关键的决策者没来，会前没有与关键人员确认参会时间和地点，会议时，大家发现 无法作决定，因为某关键人员没来。
7,大会当中开小会，部分人员（有些资历）开小会，最不好的是拽着关键人员开小会。
8,同时有2个或2个以上的人在发言，抢着说话
9. 没有制订清晰的议程
10. 会议组织者没有权威，或者组织者背后没有权威，控制不了局面。特别是跑题的时候没法找回来
11. 没有专人记录，导致没有track后续任务的依据
12. 后续会议不讨论前次会议的遗留问题

高效的过程表达方式

ETVX是指 entry进入，Task任务，Verification验证(也有用Validate确认)，Exit退出。ETVX本身也是一个质量控制的过程。下面是指自于http://syque.com/quality_tools/toolbook/Process/etvx_quality.htm

• Entry criteria define what inputs are required and what quality these must be to achieve the exit criteria. Entry criteria should be communicated to supplier processes, to become their exit criteria. If supplier processes are sufficiently well controlled, then there is no need to check inputs.

• Task definitions specify the actions within the process.

• Validation definitions identify test points within the process and define the tests and criteria for checking at these points. This enables problems to be caught close to their cause, reducing rework and scrap costs, and enabling problem causes to be addressed.

• Exit criteria define what outputs are required and what quality these must be to meet the needs of customer processes. Exit criteria may be derived from the entry criteria of customer processes.

Together, these make up what is known as the ETVX model (as below), which can be used to define the process and the quality required within it completely.

In process improvement, it can be useful to apply this model to processes that are suspected of being troublesome, in order to identify measures to identify specific problems.

ETVX在各个场合得到应用，已经被证明是一种有效的高效的过程。

过程的表达方式有很多种，最常见的就是带序号的文字，也有用图表示的，各种的说明书等等都有各自的过程表达方式。
作为过程的表达方式，ETVX也是一种高效的写法，有如下的原因：
1，ETVX的写法与ETVX的过程本身就是一致。
2，ETVX的写作过程可以尽量使用文字，避免使用图片、动画等等，写作过程高效。
3，ETVX写出来的过程表述结构清晰，易于理解，阅读过程商效。
4，ETVX可扩展，也容易扩展，对于重要的过程可以再加上职责、度量、工作产品或称产出物等等 。

正应为ETVX的优势，以后本版所表达的过程将尽量用ETVX范式来表达。
ETVX过程表达范式如下：

XXX过程
进入条件(E)
xxxxxxx
任务(T)
1, xxxxx
2,yyyyy
3,zzzzzzz
...
n, aaaaaaa
验证(V)
bbbbbbbbb
退出(X)
ccccccc
其它关注的内容
dddddddddddd

参考:http://dbmaker.syscom.com.tw/mag/132/se-cmmi_01.htm

开版宣言

什么是过程？ 下面摘了一些定义。

过程 – 为了给定目的而执行的一系列步骤 (IEEE)

过 程 – 将人员、材料、能源、设备和规程，设计成以产生特定最终结果的工作活动的逻辑组织 (Gabriel A.Pall Quality Process Management. Englewood Cliffs, N.J. : Prentice-Hall, 1987.)

过程 – 用以实现一个模型中多个实践的一系列活动 (CMMI术语)

过程是为达到一定目标的活动的偏序集。

这个版就是来和大家讨论如何设计并实施高效的过程，笔者从事软件开发，所熟悉的过程大都是软件相关过程。
过程是否高效，其实还是用过程的结果来判断的；没有高效的过程，也就没有好的结果。
CMMI主要在软件开发领域给出了各个方面的最佳实践的特点和要点，出于模型的全球性、各行业的适用性，其中并没有特别具体的指导。

本版将就一些具体的过程进行讨论，试图给出一些高效过程的做法。
HEPR 是Highly Efficient Process Research的首字母缩写。
很高兴在google的blog上注册到了hepr. blogspot.com的域名。