CMMI2.0之我见-原因分析和解决CAR&决策分析和解决DAR
编者按：
CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域，笔者将通过系统性的梳理、浅显易懂的文字描述，同时结合笔者的思考和观点，对每个实践域的目标以及所基本涵盖的内容进行描述，希望能抛砖引玉、相互碰撞，燎原出契合读者各自心中的答案。
目录/CONTENT
01 策划PLAN
02 风险与机会管理RSK
03 估算EST&监视与控制MC
04 组织级培训OT&供应商协议管理SAM
05 需求开发和管理RDM
06 验证和确认VV&同行评审PR
07 技术解决方案TS&产品集成PI
08 原因分析和解决CAR&决策分析和解决DAR
09 配置管理CM
10 过程管理PCM&过程资产开发PAD
11 管理性能和度量MPM
12 治理GOV&实施基础条件II
13 过程质量保证PQA
CMMI2.0之我见-原因分析和解决CAR&决策分析和解决DAR
原因分析和解决CAR
原因分析和解决（CAR）是识别选定结果的原因并采取行动，防止错误的过程和结果再次发生，同时采取纠正措施或预防措施。
在CMMI1.3模型中这个实践域属于高等级过程域，只有实施到高等级才会涉及，但在CMMI2.0版本中重新调整了它的定位，认识到原因分析的重要性，在诸多环节上都离不开原因分析，让它回归到了本质。
通过将原因分析和解决落实到项目的每个阶段，提前对缺陷与问题进行预防，这种方式将更为有效。如果我们仅仅依靠在缺陷与问题产生之后对其进行检测，这样的效率是极其低下的，同时也将耗掉更多的成本。
原因分析和解决是项目间沟通经验教训的重要机制，通常需要对结果的类型进行分析，重要的是需要识别趋势。例如：基于CMMI模型，对已定义的过程及其如何实施的理解，确定这些结果的根本原因及其将来的影响。
因为对所有结果执行原因分析并不现实，所以通过对质量、生产率与周期时间的估算投入与回报进行权衡分析，选择需要执行原因分析的对象。
根因分析活动中，重点分析问题是怎么发生的，例如对于客户投诉还需要考虑产生根源在哪？也就是是否有完备的措施进行规避。如果分析产生的原因和流出根源还了解不够深入，必要时要上升至公司层面来关注如何规避问题，需要审视流程上是否存在漏洞与可优化点。
流程的优化并不一定是大刀阔斧的改动，流程优化可以是系统的，全面的，富有意义的，也可以是一个细节的补充和完善，也许同样可以解决大问题。根因分析之所以重要，同医生对症下药一个道理，根因分析得准确，措施才能自然而然的形成。
通常措施要与根因相对应，每一条根因至少有一或多条纠正预防措施，产生原因和流出原因对应纠正措施，系统原因可对应预防措施。
原因分析的主要使用场景举例：
1、问题或失败反复多次出现时，同样的问题多次在项目或者组织执行中出现。
2、项目实施、组织改进执行过程中明显与计划目标或需求发生偏移时。
3、测试阶段BUG的数量及比例远远高于预期时。
4、过程性能目标超出或低于预期时。
5、某一改进流程执行结果不能够满足预期质量与过程性能目标时。
下面主要介绍一下根本原因分析的常用方法及步骤：
鱼骨图分析法首当其冲，鱼骨图又名石川图，发明者是日本管理大师石川馨。鱼骨图是一种发现问题“根本原因”的方法，它也可以称之为“因果图”。鱼骨图主要用于各类管理中的建立分析模型。
鱼骨图分析法是进行因果分析时经常采用的一种方法，其特点是简捷实用，比较直观。鱼骨图实施的主要分析步骤是：
①分析结构：针对问题点，甄别不同层别的方法，例如：人、机、料、法、环等，按头脑风暴分别对各层别、类别找出所有可能原因，将找出的各要素进行归类、整理，明确其从属关系，分析选取重要因素，检查各要素的描述方法，确保语法简明、意思明确。
②分析要点：确定主要原因时，实施方面一般从“人、机、料、法、环”着手，管理类问题一般从“人、事、时、地、物”层别，应视具体情况决定，主要原因需用中性词描述，不说明好坏，其他次要的原因可以使用价值判断。
需要尽可能多而全地找出所有可能原因，而不仅限于自己能完全掌控或正在执行的内容。另外从对人的原因分析方面，应该从行动而非思想态度面着手分析，理清其中的问题关系，如果某种原因可同时归属于两种或两种以上因素，需要以关联性最强者为准。例如：场景化还原现场，通过相对条件的比较，找出相关性最强的要因归类。最后在选取重要原因时，应标识在鱼骨刺的最末端。
③使用步骤：首先查找要解决的问题，把问题写在鱼骨的头上，召集同事共同讨论问题出现的可能原因。另外尽可能多的找出问题，把相同的问题分组，在鱼骨上标出，根据不同问题征求大家的意见，总结出正确的原因。
最后拿出任何一个问题，研究为什么会产生这样的问题，针对问题的答案再问为什么？这样至少深入五个层次，当深入到第五个层次后，认为无法继续进行时，列出这些问题的原因，同时需要列出多个解决方法。
决策分析和解决DAR
决策分析和解决的目的在于利用正式的评判标准流程，依据已建立的准则评估各种已识别的备选方案，分析可能的决策。
决策分析和解决实践域包含建立指导，利用正式评审过程，依据已建立的准则，评估已识别的多种备选方案，以分析可能的决策，确定最佳解决方案。
正式的决策流程减少了决策的主观性，提高了决策的科学性。定义清晰决定什么议题需要正式评估过程，然后引用正式评判过程解决议题。正式评判过程为结构化的方法，依据已建立的准则评估备选解决方案，并决定最终的方案来解决议题。
在CMMI2.0中决策分析这个实践域也有一些改变，例如：决策分析的条件进行了增加，包括风险，变更，质量，进度，团队氛围等方面的考虑，同时由1.3版本中的6个实践，精简合并变成5个实践。即将”评价候选方案”和”选择解决方案”进行了合并，变为“使用准则和方法评价并选择解决方案”。
决策分析可以应用于选定技术的重要事项上，正式评判过程也可应用于许多非技术的议题，特别当项目开始规划，议题有多种备选解决方案与评估准则时，例如人的选择，物的选择，环境的配置等等，适合使用正式评判过程。
而大多数的设备选择或软件技术的替代方案研究是正式评判过程的典型范例。再举例：在项目策划期间，识别哪些特定议题需要正式评估过程。典型的议题包括：选择架构或设计的备选方案、使用复用或现成品组件、选择供应商、工程支持环境或相关工具、测试环境、交付的备选方案等。
在项目实施过程中，技术方案选型往往是比较揪心的一个过程，需要在满足需求、技术先进性、成熟度、成本、人力、工期等方面进行平衡，而且这些方案是项目干系人和项目组成员在头脑风暴会议上，通过快速互动、刺激提出有创意的备选技术解决方案。每个方案都有意义，或者说多数的方案都是能解决问题，只是成本、时间、人力等方面的目标一致性需要统一衡量。
其他非技术的包括：自行开发或采购的决策、过程的开发、产品定位的选择及其它决策。在使用决策分析时需要建立指导原则和进入和退出准则，以决定何时使用正式评判过程来解决非计划中的这些议题。
当议题涉及中高风险或议题会影响达成项目目标的能力时，通常建议使用正式评判过程。正式评判过程有不同的形式、准则类型及使用的方法，例如：不正式的决策，其分析可能花费几小时、只使用几条准则、人员投入决策的工作量很少，以及产生一两页报告。
但是较正式的决策可能需要具体的计划、一定的工作量投入、制定与确定准则的会议、模拟、原型等。
评判的标准如何定义？正式评判过程可使用量化或非量化的准则。量化准则使用权重以反映准则的相对重要性；非量化准则使用较主观的等级划分，如：高、中、低。较正式的决策可能要求完整的替代方案，需要识别与评估各种备选解决方案。
另外在评判期间，已识别的备选方案，可能被重新组合、新技术也可能改变备选方案，供应商的资质情况在评估期间也可能改变，所以建议备选方案在评审之前需要有充分的理解和研判。
最后我想强调一点是在决策过程中如能够量化的，尽可能的拿数据进行说话，目前许多企业在决策时仍沿用以往的个人经验，没有数据，这在实际决策运行时会出现很多问题。
在数据分析行业发展成熟的国家，90%的市场决策和经营决策都是通过数据分析研究确定的。用数据说话，重视定量分析，也逐渐成为科学研究、企业经营、政府决策等过程着重考虑的问题，越来越多的人们意识到基于数据分析的决策对公司经营的重要意义。
更多精彩内容和视频，请关注同名微信公众号。