|
通过这个故事，我的体会是，作为一个项目“管理”者，既要“管”，更要“理”。“管理”这个词其实应该调过来叫“理管”，即项目经理要能首先找出问题，先把事情理顺，让每个人都明确自己的位置和方向;接着，就是要管，而且要高效的管。有道是“欲善其事，先利其器”，“管”作为一种器，项目经理要思想开放，用于创新，尽可能的使其“利”起来。当然，在管的过程中，又会发现新问题，从而再理，如此反复，最终把事情做好。项目管理者联盟
故事三： 通过积累并分析历史数据来提高估算准确度项目管理者联盟
在TSA后期，特别是Victory Release中，很多需求都是基于现有系统的增强工作。这类需求的特点是单个需求的工作量不是很大，但是很多、很杂。因为没有一个成熟的估算模型可以套用，这给项目工作量估算带来了难度;还有一点是，PMO会在需求还不明确的情况下要求大家给出估算，目的是利用每个系统的估算排出主计划。为了很快给出估算，大家完全凭借经验。根据我们的统计，单纯凭经验做出来的估算，有大约84%的需求估算误差都在50%以上。service.mypm.net
为了解决该问题，我们引入了一种基于经验矩阵的类比估计，把它称为ETF(Estimate-Track-Feedback)方法。这个方法可以用图2表示：项目管理者联盟
项目管理者联盟
图2 基于经验矩阵的类比估计club.mypm.net
这个方法分成三个步骤：项目管理者联盟
第一步是估算(Estimate)，首先要确定需求的分类，然后根据分类与经验矩阵进行对比，找到以往类似需求的工作量作为参考;如果在经验矩阵中没有记录，则引入其他专家进行集体会审，把会审后的结果作为初步估算;项目管理者联盟
第二步是跟踪(Track)，在项目执行过程中，设有一个估算执行记录库，记录每个实际需求的最初估算量，一旦录入，该指标不能随意更改，同时， 在日常工作中，会要求开发人员随时更新在该需求上投入的时间，并对这些时间进行分类，比如，是沟通相关的，文档整理相关的，开发相关的等等。这是这个模型的关键点，因为这些数据的准确性将会影响在经验矩阵中的数据可靠性。我们做了两件事情来保证，第一提高开发人员的积极性，跟大家进行深入沟通，阐明这样做的目的是为了积累工程数据，并不是作为考勤，不是用来监督大家的工作;第二，要求每个系统的负责人按时检查这些数据的完整性和准确性，并将其作为考核指标。项目管理者联盟
第三步是反馈(Feedback)，在项目后期，会根据估算执行记录库中的内容进行分析总结，首先会统计估算偏差，然后对于偏差较大的项目分析原因，基于这些结果，将一些有价值的指标反馈到经验矩阵中。项目管理者联盟
通过这个模型的建立和使用，估算的准确度得到了很大的提高，而且更加迅速，更为重要的是，因为有了工程数据方面的积累，在和业务人员的沟通上有了更多的数据方面的支持，表现的也更加自信。pmp.mypm.net
结论项目经理博客
本文列出了三个作者在实际项目中遇到的问题，并介绍了针对这些问题的解决办法，这些办法的执行效果也都还不错。项目情况各不相同，也没有放之四海而皆准的实践，只要项目经理和团队成员能够保持敏感性，灵活性，随需应变，相信总能找到适合自己项目的最佳实践。项目管理者联盟
参考文献：项目管理者联盟
1. 联想全球战略下的IT整合之路转自项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
