IT项目的质量、进度、成本和风险管理汇总

IT 项目的质量、进度、成本和风险管理成都微软技术中心苗宁摘要本篇论文将从质量、进度、成本和风险四方面，阐述IT 项目管理中遇到的问题，并结合本次项目经理的理论培训，论述项目管理的重要性和对项目成功发挥的作用。前言作为项目经理带了几年的团队和IT 项目，项目的质量、进度、成本和风险管理就像是一个综合的复杂矛盾体，无论是在顺利还是不顺利的项目中，都一直多多少少的困扰着团队也困扰着我。项目的最终目的是向用户按计划交付集成开发完成的系统，用户希望得到合格可用、方便快捷、运行稳定的高质量成果，而项目质量的第一负责人就是项目经理，但是在项目过程中，过分强调项目质量，往往会拉大项目进度，造成项目的成本增加，甚至出现延期的风险；而一味的追求进度，必然造成项目的质量下降，短期看，似乎成本下降了，但是其中蕴藏着巨大的返工风险，一旦用户在使用过程中，特别是实际使用一段时间之后，发现了必须修改的问题，甚至可能造成项目交付使用之后却面临要么返工重做，要么宣告失败的尴尬局面。质量、进度、成本和风险管理，在项目中如此的相互依赖、相互作用和影响，那么，项目经理应该如何处理好这些棘手的事情，最大程度的保证项目成功呢？下面，我就从这四个方面结合自己的实践，论述项目管理在项目中发挥的作用，以及我的认识和理解。质量管理，强调“第一次就把事情做对”克劳斯比有句名言：“质量是免费的”。他认为“真正费钱的是不符合质量标准的事情-没有第一次就把事情做对”。因为，那些不符合质量标准的工作，那些没有第一次就做好的工作，就必须进行补救，就会使企业产生额外的支出，包括时间、金钱和精力。由此而产生了质量损失。朱兰博士将此类损失喻为“矿中黄金”，其蕴藏量非常 丰富 。这些损失又象一座巨大的“水面冰山”只露出小小一角，而其大部分还深没“水中”未被人们所认识。因此对“矿中黄金”进行开采，将“冰山”全部推出“水面”，并加以挖掘，这就是质量经济性管理的基本思路。从上述文字不难看出，质量的优劣对项目进度和成本的影响是巨大的。在软件开发项目中，最终产品包含软件本身和项目文档，质量管理的重点和对象一般也放在软件质量和文档质量上，通常，我们在项目开发中采用测试、走查、抽查、互查的方式来把握质量，但是，实践中，测试基本对发现软件本身的bug 和缺陷有用，但是对软件的质量缺乏有力的支撑，采用的审查方式，也会因人而异的存在一些不足之处，特别是检查的频度和粒度，往往导致检查制度在项目中无法贯彻和持久的操作。该如何在项目中进行质量管理？有没有更好的选择？其实还是有几点可以遵循和借鉴：1、 要把质量建立到产品中，审查不是问题的答案，它来得太晚也不可靠，也不产生质量；2、 提高质量不是一朝一夕的事，应该持续改进系统开发过程从而提高质量和劳动生产率；3、 项目经理要充分了解项目成员的技能，建立工作培训计划，每个人都要受到培训，开发技能和知识水平要提高；4、 为所有项目组成员建立起教育和自我提高的机制。在这个前提下，我们探索并进行了以下的尝试：1、 不再单纯的强调某个项目的质量，而是注重不断持续改进的过程和方法；2、 制定规范，包括项目开发规范、文档规范，在项目开始前就获得所有项目组成员的共识，并不断强化；3、 充分了解每个项目组成员的专业技能，并根据情况提供必要的培训；4、 强化评审机制，包括需求评审、设计评审，确保项目出发点的正确性和共识；5、 加强测试，特别是边界情况的测试；6、 加强代码检查，一方面是代码的规范，一方面是代码的质量。实践中，我们发现，提高质量的第一要诀，就是：第一次就把事情做对。进度管理，找出项目的关键路径IT 项目一旦开始，最常看到和提到的，就是加班。不加班的原因都一样，加班的原因各有不同，归结起来，就是进度出现了问题，怎么办？加班。用搬砖为例，一堆砖一个人要一天时间搬完，如果有皮鞭和喝骂，可能会提前一、两个小时，如果有狼狗和刺刀，可能会提前半天，但是IT 项目不能通过皮鞭、狼狗和刺刀来增加进度，因为IT 项目和搬砖不一样，它本身是一个带有创造性过程的脑力劳动，绝大多数时候，项目本身不能凭借单纯的增加人手和施加高压就能提高进度，同时，在IT 项目中，还经常会出现由于技术问题而导致延期的情况。怎么办？增加人手和压力不仅不解决问题，还会不断的因为突发事件延期！相信这是每一个项目经理都曾经遇到和会遇到的头痛问题，同时，我也相信，绝大多数项目经理都知道，这种情况，要找出项目的关键路径，加快关键路径上的项目活动，才能获得项目进度的提升。但是，往往我们在项目管理中面临的窘况是，关键路径找出来，项目进度仍然时常无法保证。带着实践中的疑问，把目光落在在理论学习上，不难发现，找出关键路径的做法无疑是正确的，但是，当我们把焦点放到对关键路径上的工作、活动的分解，时间的估算，进度的编制是否合理、正确的时候，终于发现了问题：如果在错误的工作任务的分解，或者不当的时间估算，甚至不对的进度编制的情况下，关键路径本身就存在着问题，从一个错误的命题出发，得到的肯定不会是一个正确的结果，在一个不正确或者存在问题的关键路径上下功夫，只会让进度问题更大，即使勉强做完，相信项目组也已经人仰马翻、天昏地暗了。所以，找寻关键路径，不是项目开始之后，而是项目开始之前，一个正确的关键路径，一定是以正确的工作任务分解、恰当的时间估算、合理的进度编制为前提条件的。项目开始前，正确的理解客户需求、正确的分解工作任务，定义正确的关键路径，才能在项目中，通过提高关键路径上的进度，来合理的提高项目进度。成本管理，不当家不知柴米贵IT 行业有一个特点，加班多，支付员工加班费的公司很少，在没做项目经理之前，我觉得这种情况很不可思议，从开始负责项目管理之后，越来越觉得成本管理的重要性。首先，作为项目经理，要争取让项目最大程度盈利，为公司挣取利润，才能为项目组成员争取利益；二，在现在激烈的IT 竞争中，项目的合同价格下利润空间已经很薄；三，在技术因素和用户需求变动的情况下，IT 项目很容易造成延期；四，作为公司办公，每个人天的平均运行成本相当高，项目每一天延期，成本都是乘以项目组人数在增长，在利润已经很薄的情况下，没有好的成本管理，一个项目如果不盈利甚至亏本，那么对公司、项目组、个人的利益都有连锁影响和不可估量的损失。如果说，对用户而言，项目经理是项目质量的第一负责人，那么，对公司和项目组成员而言，项目经理也是项目成本的第一负责人，要确保在批准的预算内完成项目。成本管理，到底管理哪些内容，如何管理？首先是资源计划，在我们实际的项目中，主要视项目大小，来确定资源计划的形式，如果项目比较小，资源计划就在项目计划中用一个章节来记录，如果项目比较大，会单独成一个文档，进行分析确认，最后提交评审。在资源计划中，首先要根据项目的阶段和里程碑，明确项目完整生命周期中要完成每个阶段目标所需要的物质资源，包括人、设备、材料，这些资源的种类和数量。实践证明，把资源计划细化到项目每个阶段，明确种类和数量，是有效进行成本管理、节约成本的第一步。其次，根据上述的资源计划，结合项目每个阶段的时长，确定完成这些阶段所需要的资源成本。接着，结合资源计划、成本估计，估算项目成本，再和公司拟定的总预算进行比较，如果两者差异不大，说明成本预算合适，如果差异太大，需要重新确定，到底是公司的总预算过少，还是项目的资源规划过大，最后达到公司和项目组都认可的成本。最后，就是项目进行过程中的成本控制，一方面计划中所需的项目组成员要尽量做到结构和人数合理，避免由于估算不足而在开发过程中增加项目组人手，另一方面要尽量按计划启用资源和释放资源，比如，UI 设计师，在完成开发设计之后，要尽快释放，如果采用V 字型的测试过程，那么在需求调研的时候，就不需测试人员的进入，而在需求确定之后，就要尽快引入测试，明确需求，了解功能设计。而加班餐费和加班交通费，会根据加班情况产生，那么，是否需要加班，加多久的班就要随时动态调整，合理加班，有利于项目进度和成本控制，也有利于减轻项目组成员的工作压力。风险管理，防火防盗防风险项目进行中，随时可能遇到风险，比如骨干人员离职、技术攻关失败、用户取消合同、无法按时交付项目产品等等，这些都是风险，只是它们发生的概率和后果严重性各不相同，对于这些可能发生还没有发生、或者一旦发生的情况，应该如何防备并进行有效管理呢？如果对风险能进行有效的预估和识别，并制定相应对策，那么项目风险面前，我们就能做到游刃有余，处变不惊。理论上，风险管理分为了风险识别、风险评估、风险响应和风险监控。风险识别，首先需要识别风险分类，技术风险、项目管理风险、组织风险、外部风险、市场风险、财务风险，等等，这些分类除了大多数常见的内容，还需要项目组成员经验和历史工作中的内容来补充，比如，完成项目之后，收不到钱，最后公司和业主陷入法律纠纷，或者，由于需求分析结果得到业主口头承诺但是没有签字确认，最后用户做出重大变更，项目组却无法控制用户的变更，造成项目亏本或者失败，等等，这些不常见但是发生过的风险。仔细回顾一下，其实在IT 项目中，风险没有我们感觉的那么小，往往一旦爆发出来，破坏力相当的惊人，比如，常见的：项目组成员在项目开始后无法到位内部资料 项目组人员对项目热情不高，没有兴趣 项目进行中离职 项目经理、项目成员能力不足 需求调研未能真实反映用户要求 缺少项目进行必要的设备或软件 不能搭建接近真实环境的测试环境 用户需求只有口头承诺没有签字认可 用户在项目进行中提出重大需求变更 项目进行中关键技术难题无法攻关 项目质量发现重大缺陷 代码质量不符合规范要求 Bug 数量远远超过正常情况 系统集成调试发生重大故障 性能指标无法达到用户要求 无法通过内部测试或者用户验收 上线之后发现重大 bug 影响运行 想想这些真实存在，可能发生的情况，相信作为项目管理者的心情一定不会 好，就像身背巨额销售任务的市场人员，每天睁眼就已经欠下公司几百万，市场 人员最好的解决办法就是，签下大单，完成销售任务，而项目管理者，最好的办 法就是在识别出来并评审通过的风险基础上，加强风险监控，让这些风险不发生 或者尽量扼杀在萌芽状态。 实际工作中，我们除了定义了类似上述识别出来的风险条目，还定义了风险 系数，如下表： 风险系数 灾难的 4 严重的 3 轻微的 2 可忽略的 很高 5 20 15 10 5 比较高 4 16 12 8 4 风险可能性 中等 3 比较低 2 12 8 9 6 6 4 3 2 很低 1 4 3 2 1 风险严重 性 内部资料 1 然后列出风险记录，如下表： 编 风险描述 类别 号 1 应用系统所采 技术 用的技术是否 能熟练掌握 责任 人 xxx 严重 可能 性 性 2 2 系 数 4 风险减缓措施 对开发涉及到的语言、 开发工具、开发技术在 前期准备和开发中应尽 快熟悉提高，出现障碍 时，及时汇报并需求部 门资源予以解决。 开发之前，对现有系统 充分了解，熟悉专有名 词和业务流程。 明确开发目标，确保关 键进度，加强项目监控 2 3 对用户需求和 技