决策分析与解决方案Decision Analysis & Resolution是CMMI 中Maturity Level 3的一个过程域。这个过程域的作用就是用正规的方法对项目中比较重要的问题进行决策。
正规的决策方法需要经过以下几步：
1. 确定有哪些问题需要用标准的决策流程
2. 建立评价标准
3. 识别备选方案
4. 选择评估方法
5. 评估备选方案
6. 选择解决方案
这些活动，在时间充裕、资源足够的情况下，是合乎处理事务的自然顺序的，而且它带来的好处，每个有点经验的PL都能看到。所以一般情况下，PL都是愿意认真对待。
CMMI建议以下情况下使用DAR流程：
1. 高风险问题
2. 会造成进度产生较大偏差的问题
3. 会影响项目目标达成的问题
4. 与其达成的结果相比，DAR成本是合理的一些选择
而实际项目中，我们使用DAR比较多的情况是：
1. Technical Solution的选择
2. 测试的一些关键点上的判定（评价实行判断、GM Release判定等）
3. 项目中需要进行外包或者外购的情况（供应商的选择，Make/Buy的选择）
在执行这些决策分析时， 会经常听到PL如下的抱怨：
1. No Real Choice。例如在测试的GM Release判定，虽然可能有Damage A的Bug，但项目还是不得不放行。
2. 没有足够多的真正关心这个问题的专家来进行决策。备选方案有限，评价的各个方面并没有经过认真的核查。
3. 决策耗时，而项目时间又紧张。
那该如何应对PL的这些意见呢？我们先来看看决策的四种方法：
1. 命令式决策（Command Style Decision Making）
2. 顾问式决策（Consult Style Decision Making）：在决策前咨询其他专家，但他们并不参与决策。
3. 投票式决策（Vote Style Decision Making）
4. 一致性决策（Consensus Style Decision Making）：需要获取所有参与人真实同意。
PL的第1个抱怨，PL并非是真正的决策者，而只是顾问，PL从各个方面给出建议和推荐，但真正决策的人是PM。 第2，3个抱怨，我建议也采取第2种方式提高决策的正确性和效率。在公司里，找一些熟悉问题领域，但并不关心你的问题的专家，向他们咨询可能的解决方向，这可能只需要占用他们半个小时时间。把这些意见收集回来后，安排项目中几个学习能力强的同事分别就这些方向进行一到二周的学习调研，然后将他们聚集起来依据评价标准对备选方案逐一评价。
下面分享一个比较成功的DAR案例。在2006年，公司还在使用Excel记录测试过程中发现的缺陷，项目成员对Excel的Bug管理抱怨很多。通过分析，EPG把在公司导入缺陷管理工具设为了一个年度改进目标。那时候的公司文化，还是尽量使用免费工具，比如Bugzilla，Valsun，所以要想获得老板同意还是不太容易。而那时比较高大尚的付费工具是ClearQuest。我们的DAR步骤如下：
1． 先组织几位资深的程序员对权限管理工具需要满足的功能进行了头脑风暴和排序。
2． 安排EPG三位同事分别熟悉Bugzilla，JIRA和ClearQuest。就是在那调研的两个星期内，我成了公司的JIRA专家。
3． EPG的成员按照评价标准对几种方案进行评分，最高得分者是JIRA。（这个时候还不是最终决定，因为EPG并不是实际的用户）
4． 向老板进行了第一次汇报，获取老板同意后进行项目试点。
5． 选择合适的并且愿意配合的项目进行一个月试用后，我们请参与的开发人员进行了第二次评估，10/12个同事推荐使用JIRA（投票式决策）。
6． 向老板进行第二次报告，因为具备完整充分的评估过程和真正使用者的客观评价，老板欣然同意。