IT项目风险管理案例和应对之道

1、ITIT项目管理从某个意两个控制风险的原则虽然风险总是发生，但就如同大多数的公司一样，该公司也不愿意花费太多的精力和时间在这风险管控上，所以在寻求一个低成本又高效的管控方法。王总监和我们在研讨后，使用工具DevSuite基于下列两个原则做了处理。（为避免篇幅太大，以下我们仅把最精彩的点列出来。）（1）提高项目的可视性不论是哪一种风险，其最后冲击的基本上就是项目本身，延期是最常见的结果。如果是对可能发生的风险都一一进行管控，成本必然很高，而且还可能有疏漏。使用燃尽图（BurnDownChart）可能是针对项目延期最有效的解决办法，因为它很大程度地提高了项目的可视性。在实际操作时，我们让团队成员每

2、天对其参与的每一任务都键入下列两项数字：1）该任务花费时间，和2）该任务所剩时间。结果就会生了类似如下如图所示，起初这项目被估计是要3480小时完成。大致上来说，一般的研发团队因着人员请假、会议和其他突发事情，平均每人每天只能有六小时花在实际项目工作上。现这项目有七个人参与，估算出来大约需要四个月完成。（也就是从2009年11月29日到2010年3月29日，图中红色直立线为起始线，蓝色直立线为终止线。）这图里共有三条曲线。红色号码?/span表示到现在为止在该项目的总花费时间，红色号码?表示估算的项目剩余时间，红色号码?是到目前为止所花的时间与剩余时间之和的曲线。到了2010年3月21日就得到

3、了上面的这个图。到了这一天，我们发现原本估计的3480总小时数是低估了，更可能的是?所示的3740小时。以纵轴的性质区分，燃尽图可以分为两大类，即纵轴可以是时间或是事件。以范围区分，燃尽图至少可以分为三类：项目级的、任务级的和需求级的。透过燃尽图，我们可以看到项目进行的情况，项目需求是否按计划进入开发流程，工作是否有延时，或者工作安排的饱和度是否适合。如上图所示，我们可以轻易地看到，照着现在的进度，这项目最可能会延期6到7工作天。当高层看到这图时，就可以在资源上做调动，以避免延期产生的不良后果。我们刻意使用了这个较理想的图做讲解，为的是让读者更容易理解。它不是个典型的图。在大多情况，使用燃尽图

4、会是比较复杂的，因为它可能包含了需求搜集、编程、单元测试、集成测试和缺陷修复，并且还可能有迭代。所以估算时间会较困难。这个燃尽图的过程是比较稳定的，结果是比较理想的，其原因至少有二：（一）项目里单纯地只有编程、单元测试和缺陷修复任务，全都由程序员搞定；它里头没有需求搜集、集成测试或其他任务。（二）这个项目复杂度低，约一半的编码任务是机械性的，所以估出来的时间较为准确。（2）固化工作流以管控过程对于公司里既定的流程，我们在DevSuite里以图形化的工作流将其固化。下图就是以前面王总监提到的需求变更流程设计出来的。这工作流指明了，在一个变更事件被创建后，它需要经过一个评审状态。在评审阶段里，有三

5、个人（A,B和C）要全部同意，才能到达通过状态。有任何一人不同意，状态就转到拒绝。当一到达评审状态，系统马上促发邮件和手机通知，将信息寄给A，B和C。系统可以预先设定这三人有两天的时间评审该变更。假如两天过了，状态仍为评审，那就是有人未及时处理该事件。这时候，系统会自动将事件升级，把状态转换为升级处理，系统马上促发邮件，将信息寄给研发部王总监。王总监可以斟酌情况，做最妥善的处理。祁适犀垂車轴谒恋翠|丑輕殖|柜誨VBCttiM使用固化的工作流至少有四个优点：1）提高通知效率?邮件和手机自动通知提高效率，沟通出错的机会减少了；2）避免流程出错？DevSuite的工作流将流程完全自动化，每个人在收到

6、邮件或短信通知时，照着工作流中既定的步骤操作就行了，省心又省力；3）工作流变动时处理很容易?当流程或人员变动时，系统配置员可以轻易地花几分钟就做完调整，之后所有团队成员就照着流程走便行了；4）避免摩擦?人是有情绪的，固化的工作流使得操作完全对事不对人，避免了人和人之间不必要的摩擦。以上提到的软件项目风险实例几乎在每个项目中都出现，而且，它们造成的损失也是严重的。所幸，从实际操作中，我们发现处理它们的成本并不高：1）培训团队成员照工作流中既定的步骤操作，学会填写任务花费时间和任务所剩时间，并理解意图，所花时间不超过1小时，2）系统配置员要了解需求，设计工作流，并设置人员（如例子中的A、B、C和走

7、流程的人）的权限等，所花费时间在1到3天之间，也算合理，3）以往当团队人员或评审流程有变动，管理人员要更改文档并向所有人宣布；现系统配置员只要花几分钟改系统配置，一切就就绪了。小结这并不是一个全方位的风险管控系统；相反的，它是个相当简化，只对关键点作处理的系统。虽然只是做在关键点上，但效果却十分明显。就拿需求变更来说，需求变更一直都是项目中让人恨得牙痒痒的瘤。既然需求变更是不可避免，那我们所能做的就是，尽可能减少变更的次数，降低变更造成的冲击。以往大多数人审核需求变更时较为草率，导致同一个功能点变了又变。在一轮又一轮的返工后，程序员和测试人员会产生倦怠感，编码和测试的质量一再下降。使用了DevSuite后，所有的操作都在系统里留下记录，这统计在年终时可以作为考评的参考材料。自然而然地，审核人员就很严谨地审核每一个需求变更。而且，因为系统设置了每人只有两天的时间处理，审核人员处理需求变更时不仅是快，而且较仔细。单单就这个变化，就使得整个