CMMI 差距分析

今天在北京为一家软件开发公司做培训、诊断。
当谈到度量与分析，他们部门经理就要求项目经理打开他们使用的免费项目管理工具，希望让我看看他们如何度量与监控项目。项目经理打开项目展示了一些任务的记录和图表：如，敏捷的燃烧图和任务实际完成多少%。
我问：从度量与分析的角度，你们度量的主要目的是什么？
他想了一下，然后说：当然是把项目管好。
我说：管好项目是否代表尽量控制项目进度与工作量偏差？
他说：是的。
我问：从刚才这些图与表，怎么可以知道实际与计划的对比？
部门经理就让项目经理找，找了好一会，他们自己发现工具记录的都只有实际，没有与计划的偏差。虽然也有活动计划工作量，但由于项目经理会不断按实际调整，我们看到已完成的活动都没有超出计划工时。
开始时，部门经理满脸笑容，觉得用工具获得这么多各样的图表已经很不错，现在发现原来有基本的不足，已经不再说话，只是一直望着他的项目经理。
我立马打圆场说：请不要太介意，很多像你们的公司也有类似的问题，这种工具是无法有效地度量实际与计划的对比，因为你的计划天天按实际来变动，也不知道第一版本，第二版本是多少，所以永远是度量不出真正的偏差。
这工具也没有里程碑的概念：里程碑是当你一开始做项目计划时，预计哪些必须达标或按时完成的日期，定期监控，就可以避免项目不会到最后才知道超时。
如果没有明确截止时限，每个人很自然都会尽量拖到最晚，（帕金森定理,详见我11月份的 “为什么要WBS管理v1.0"）最终导致工作不断延迟，但管理层不知道。如果没有一个固定里程牌的计划，按照这个计划去监控的话，大家都延误，整个研发的的生产力便难以提升。

监控以外其他发现

除了实际监控的问题以外，我也发现他们的任务有些还是非常大，比如超过200工时。
我问他们为什么不再细分？
他们项目经理也知道WBS最底下的工作包应该不超过4-5人天才可以有效管理。只是由于项目经理分派工作后，有些活动没管到那么细，只是把大的包分出来，然后下面的人员再依据这些填实际。大家可以想象这种的话，肯定很难控制好时间，很容易延误。所以工具也需要能让下面的小组主管把大的任务再细分。
我再问他们如何填写每周的工时表，他说这工具没有工时表功能，只是在工具上面直接填所花的工时。我再问比如随便一个开发人员，他在某一段时间之内总共要负责多少个任务，我们随便抽某员工的某一周出来，我们发现某小李在短短一周之内，有二三十个活动要处理。
项目经理解释说：有些可能是维护项目，实际上应没有这么多，但确实经常一个开发同时要兼顾几个开发项目。
我解读:如果开发人员每天都有这么一大堆做不完的任务要处理，你觉得他会有动力自己把最重要的开发任务用心地做好？
想想都知道很难，并且最后会导致——虽然任务很多，最终每个活动、项目都服务不好。
我再问他们：如何分派人员到项目中？当项目要占用某个开发的时候，怎么知道这人是否已经被其他项目占用？
他们说：这个工具没有这个功能，所以很可能导致一人身兼很多任务的情况。

度量与分析

依据下图的《度量与分析》，假如刚才的目标是控制好进度与偏差的话，现在工具是无法做到有效监控。理论上你可以人手定期去记录收集、计算，但又太费劲，也很难确保不会有人为因素的干扰，导致最后数据失去意义。
再依据度量与分析来收集一些度量项时，需要自问：我们要控制好进度与偏差？会有哪些影响？
其中一位项目经理很快就回应：影响的因素可能有不同客户类型、需求变化多少、人的能力等。
我说：好啊，那有没有收集过不同项目这些参数？然后定期从项目的实际数据来验证不同类型的客户确实有差异？需求变更的多少是否影响进度偏差？如果没有数据验证你的想法，一切都只是猜想。所以我们度量与分析，使用了一个GQM (Goal, Question, Metric）的方法——依据目标，比如进度偏差，加上自问的问题，来收集你所需要的度量项。所以你收集的度量项不应该仅仅是一些结果，也应该是一些可以控制或有影响的因素，比如需求变更、人的能力等。就好比你要减肥，不能只度量体重一样。有了这些，其实你在开始做度量之前，你应该已经有概念，当我收集到那些度量以后，我会怎么分析？从分析得到什么结论？就好比做一个问卷调查，在邮寄第一封信或打第一个电话之前，其实你心里已经预计到会如何对收集到的信息做分析，得出结论一样。

选择工具问题单

也常被问到选择工具有什么要注意，下面是我常用的检查单：

基线管理 (监控)

实际与计划对比：如何收集任务的实际完成情况？是否可以与项目成员填写的工时表关联？

WBS 及范围管理

系统中，任务之间如何做分层？项目WBS不可能一开始就全部建好，是否可以先有一个总括(上层)，然后逐步细分？
项目经理把每个活动分配给负责人。由负责人进行一步细分。
因每个WBS都应该有一个明确的产出物 (如代码 ， 文档 )。产出物如何与WBS 对应活动关联？如何确保产出物确实已完成?

变更管理

项目很多时候都会有需求变更，系统如何支持不同版本的WBS或项目计划？避免出现偏差只是和最后版本比较?
( 但实际 可能已经变了多次) 如何与不同版本对比？
系统可否打基线？可监控实际与不同基线的对比

资源管理(人员)

安排人员到项目时，可否查看人员被其他项目的占用？例如: 如何避免同一个人需服务好几个项目（人员过度分配)，或者成员临时被其他项目调走？

时间管理 (甘特图+关键路径)

关键路径是项目中最长（也是最短）路径，如关键路径上的活动延误，整个项目必然延误。
当项目有非常多活动，项目经理应主要关注关键路径上的活动。

成本管理 (成本/预算)

如需要管项目的实际成本，项目管理系统可否把人力成本管理起来，而不是要靠手工计算出来?

挣值分析（Earned Value）

用来监控进度与成本偏差（计划与实际对比）

(以上每一项都能对上 CMMI-DEV 实践，表示这些也是卓越软件公司的做法。)
注：工具会有重叠，比如基线管理，就包括了时间管理，WBS分解，也需要资源分配计划的支撑等；变更可以包括时间，资源等。

为什么还是这么多软件公司使用这些功能不全的项目管理工具？

后来我跟一位总监也讨论过这个问题，结论是：他们大多数还没有真正管理研发的成本和效率。
这一两年，市场的竞争越来越激烈，客户都严格控制预算，使得成本的控制越来越重要，很多他认识的同行都开始考虑要从以前研发做出一个成本分享中心，帮助部门、项目管好成本和进度，成为考核指标。
所以当管理层迫切地觉得有这种需要时，才会意识到现在工具的不足。因任何改变都不容易，人的习惯（包括管理层本身）是最难改变。
除了高层需要有改变的决心，要成功除了有合适的工具，也需要给项目经理和团队充分培训。

经验教训 (Lesson Learned)

这些事令我想起一位项目管理的老前辈说过：
“如果公司没有这个决心要把WBS管好，配合相关的培训，单是购买具有WBS功能的工具也没用，不如就让他们继续用现有的工具就算了。若要真正做好WBS管理必须工具配合足够的项目管理培训才会有效果。很多开发人员都不希望被管得这么严，因觉得开发工作已经很累了。”

我非常赞同，归根到底，必须高层有项目管理的意识与决心，工具才会真正被使用起来。

反馈

一金融行业项目经理：
文章写的就是实际情况，感触也蛮大的。文章中提到的问题，我们这边其实也存在，有管理工具但没有正式推广起来。

 （源文来自主任评估师宋世杰）