|
一、项目风险发生的根源blog.mypm.net 极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲，风险的出现非常常见，把所有风险都拒之门外几乎没有可能，你几乎没有可能完美的解决“工期”、“资源”、“质量”三者的天生的冲突，这些导致项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测，在执行过程中与实际情况肯定会有差异，这些预测和实际情况的差异性，就为项目各种各样的风险埋下了伏笔。经过一些项目实践，我总结出项目风险产生的原因主要有以下几条。项目管理者联盟 1. 项目计划中对风险管理没有引起足够的重视，导致风险发生以后手足无措。项目管理者联盟 2. 轻视前期需求工作，导致项目实际产品与客户预期的差别较大。项目经理圈子 3. 项目过程中过渡轻视文档管理，导致风险发生以后要么无据可依（通常指需求发生变更以后，发现当初需求文档不完善），要么后继无人（通常是一些设计类文档，在人员发生变动的时候，其它人看不懂文档，无法接手工作）。 4. 轻视质量控制，导致主管得到的信息与实际差距较大，不能清晰的及时判断出真正的风险是否已经发生。在项目运作过程中，如果只靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来，将在后续阶段造成大更大的纰漏。缺乏质量控制机制，也就是缺乏有效的“监督”人员来制约，是造成这种情况的主要原因。项目管理者联盟 5. 轻视架构和概要设计。一般项目时间紧、资源有限，这样一些项目管理者在缺乏对系统架构和其它技术方面的设计缺乏有效的论证的前提下，就凭借着经验匆匆启动项目，很可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响，导致系统大量的修改。以前就我曾经经历过这种事情，简直让人崩溃。blog.mypm.net 6. 缺乏积极的应对风险的措施。实际上，项目发生风险非常正常，很多风险甚至可以预料是肯定会发生的，一旦比较大的风险发生，会直接对项目组每个成员产生一些负面影响，此时很多项目管理者不能以积极的态度应对，而是自乱了阵脚，很可能导致项目计划频繁变更，项目节奏感被打乱并且逐渐开始失控。项目管理者联盟文章 二、解决措施项目管理者联盟 任何问题，如果找到了真正原因，其实已经向解决问题迈进了一大步。针对以上风险发生的原因，我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。项目管理者联盟 在项目计划中重视风险的评估项目管理者联盟 很多项目主管在项目启动的时候认为既然团队已经建立好了，项目计划已经制定好了，就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的，任何项目都会有风险的。在项目初期认真做好风险的评估，并且能让你的项目干系人（尤其是项目主管的掌控项目资源的负责人）清楚这些风险，那么一旦风险发生，也可以更加从容不迫的应对，并且有理由更好的协调资源，不至于让大家不知所措。club.mypm.net 要重视需求工作项目管理者联盟 一个好的需求是连接业务层面和技术层面两类人，让他们达成一致的目标的关键，对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响，（很多项目都是这样，不断的需求变更导致不断的修改，如此反复，最后陷入无法自拔的泥潭），因为客户一旦签字确认以后，这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束；另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作，测试人员很好的编写测试用例，就是这份需求，可以大大降低项目组以后在沟通、修改方面的成本，提高效率和产品质量。service.mypm.net 其实大部分人都知道“需求”的重要性，有些人肯定会说：“项目时间和资源有限，怎么可能化那么多精力专门做需求呢？”。这是一种误区，需求并不一定要长篇累犊、事无具悉，但是一定要有需求。具体需求怎么写，应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务，那么这些就可以写简单点；或者项目时间太紧，那么需求文档的模版可以根据实际情况做一些必要的简化。项目管理者联盟 不合格的需求，往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件，是以后项目路线的指挥棒，好的需求一定能清晰的描述出整个项目：包括都要做什么以及这些事情的优先级。比如知道优先级以后，项目的管理者就可以根据重要性、难以程度而因人制宜的分派工作，尤其遇到时间特别紧张的情况下，可以说服客户先上最重要的系统模块而把一些不重要的放在以后逐渐实施，这样把好钢都用在刀刃上，在资源等方面受到很多限制的前提下，尽量做到大家的满意，这也为降低日后的风险打下了坚实的基础。项目管理者联盟 重视项目文档管理项目管理者联盟 让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。尤其在IT项目中，人员流动性强，文档就是成员之间交接的重要工具。但是很多主管很容易陷入“重技术实现，轻文档”的误区，他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长一点，到了最后，谁还会清清楚楚记得每个实现细节呢？如果下一个项目与此类似，以前的劳动成果还有谁能继承得下来呢？ 项目管理者联盟 当然，现在越来越多的公司已经注意到了管理好文档的重要性，一般可以借助VSS、CVS、PVCS等工具来很好的对文档进行版本控制，但是有一点要特别引起注意：单单关注文档本身远远不够，还要重视文档的质量！即使是在现在很多管理很规范（比如已经通过了CMM3、ISO9000等认证）的公司，“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前，都要通过评审、同行评审等方式来对文档进行专门的“轰击”以保证文档的有效性，这些评审小组中如果能包括一些行业、技术方面的专家将经常能达到更好的效果，这些专家完全可以从公司外面聘请。项目管理者联盟 有了完善和有效的文档做基础，能降低很多项目过程中的风险。项目管理者联盟 重视质量过程控制项目管理培训 很多人通常认为，在的项目组中最重要的是主管和设计开发人员，而认为项目中的质量过程控制没有什么必要。但是在实际项目过程中，单靠研发人员提供的报告来判断项目进程、确认是否有或者将有风险发生远远不够。因为大部分人喜欢报喜不报忧，而且汇报的内容大部分只是他本人主管的认知，也缺乏通盘的考虑。越复杂的项目，越需要量化的管理，必须有一种机制能让管理者真正掌握项目的实际进展情况，最有效的办法就是建立质控部门与实际的研发部门相互制约，监控测试项目实际情况和实际的问题，而不参与项目的具体实施。项目管理者联盟 作为一个项目管理者，明确这种研发和质控的关系，除了更好的保证项目质量以外，还能客观的反映项目实际情况，通过这些文档来表明每个基线、每个成员的工作量和完成质量，对识别、预测项目风险意义重大，当然，这些措施也大大降低了项目过程中可能的风险发生的概率。项目管理者联盟 重视架构和概要设计项目管理者联盟 在IT项目中，编码实施固然重要，但是对于一个比较复杂项目中的项目组来讲，如何让不同角色的研发人员高效协作，将是更加要紧的问题。项目管理论坛
|
