CMMI 概述用实例学 V2.0( 二 ) _改进

也应该让团队多参与，我上次已建议你们加强过程改进小组，例如今年目标是提升项目管理，便应让多些项目经理进入项目过程改进小组，一起参与，不是单靠你们两自己想如何提升。你们心里可能已经想好一些好方法，但最好还是先一起讨论，在会议中你们引导，最好尽量让他们自己提出，他们才会觉得这是他们的事，而不是仅仅服务管理层。
刚才我没看到你们现在的基线与量化目标 / 商业目标，可能你们都有概念，但没有明确写出，例如：项目延误要从现在的什么水平提升到多少；每周提交多少，现在是什么情况，希望达到多少？没有明确的量化目标，所有的过程改进便缺乏正确的方向。例如，要提高项目组生产效率，降低延误，团队培训很重要，但不仅仅是项目管理系统的培训。问你们两位：“你觉得如何可以把项目的效率提升？减少延误？比如你现在用系统，有两方面你可以考虑，比如我们刚才讨论，项目延误的主因是需求常常变。
你们说有些客户变化很频繁，例如周一说了A,周二就变成B，后面有几轮变化，增加了C与D，可能最后还是觉得变回A更合适，把BCD推翻。这样的项目当然会延误，开发人员也无法集中精力。所以你们可以严格遵从敏捷2周的迭代模式，2周内不容许其他变更，才能让项目经理和项目人员专心做好项目，所有的需求变更都规定必须在2周冲刺才处理。另外，你们可以利用系统来定不同的基线，项目组的偏差是跟变化后的基线比较，而不是与最早变化前的基线比较。
但我们不能单靠他们自发，培训也很重要，比如我以前说过如何做回顾、复盘、根因分析，现在有了数据，整个根因分析就更具体。培训也不要仅考虑传统授课形式。培训的目的是希望通过培训让大家知道新的方法应如何做。如没有合适培训，大家很可能走弯路，浪费资源。
还有什么可以提升项目组效率？
我说：很简单，尽量在早期找出缺陷，减少返工。
另外就是项目人员个人的时间管理。
缺陷管理我在之前的同行评审的文章中详细提过，时间管理你们应该都学过。
其实道理很简单，如果每个人时间都管不好，每天很多骚扰，不会集中做一些重要的事情，把它完成，整个项目管理的时间延误管理肯定不会好。所以，在做改进时，要对有影响效果的主因做改进 - 如果项目组人员做事方法没有变化，项目组便不会有提升。
有没有发现我的建议都是基于13 条内容，包括：
不良例子
我来讲一个反面例子，让大家知道，为什么不注重这些要素会失败。
比如一政府的内部ＩＴ部门，他们也做ＣＭＭＩ过程改进很多年，但是他们管理者的心态是“不追求高分，及格就足够” 。
管理层这心态便会妨碍了整个改进。比如他们希望咨询顾问帮他们更新过程，引进敏捷项目实践。
我说：好啊，你们这些项目应该不会完全没用过敏捷的方式，让我们一起了解，参与一起改善不是很好吗？

文章插图
但这内部ＩＴ部门主管心态不同，比如政府项目都要招标，必须先写清楚要做什么，然后投标。他的想法是你们顾问过来诊断/差距分析，依据你的专业知识，帮我们写一套详细的敏捷流程，评审可以的话就按这个推广就可以了。
你可以看到刚才这种思路很可能失败——所有的变更不是一步到位，才能一步步让受影响的人接受。如果他们在前期，不按照他们的现状，让他们参与，他们就没有动力后面跟顾问设计的最佳流程走，最后变成一堆放在总经理书柜的无用文档。

CMMI 概述 用实例学 V2.0( 二 )

CMMI 概述用实例学 V2.0( 二 )