项目管理方法

项目管理方法项目章程如何写按照项目过程管理的教科书的要求，任何项目上来，除开前期的项目调研外，项目章程是一个必不可少的项目整体管理的组成部分。看看书面解释“项目章程是正式批准一个项目的文档。项目章程要么由项目组织以外的发起人或资助人发布，要么由组织内某个级别的管理层发布，以便为该项目提供所需的资金。项目章程对项目经理进行了授权，以便他可以使用组织资源执行项目，应该尽可能在项目的早期确定并任命项目经理。”其实这段话和所有教科书一样，是建立在完美资源和充分条件的基础上的，在目前国内的实际环境中，一个项目的发起往往就是几个主要决策人拍板决定的，有一个过得去的炒了不知道几遍的调研分析报告，就把合同约定了，有的甚至在没有签定合同的前提下，就开始组建项目团队。在项目章程确定上，不能尽信书也不能无书。项目章程的在教科书上约定的输入条件、分析工具如下：输入工具与技术合同项目选择方法工作说明书项目管理方法企业环境因素项目信息系统组织过程资产专家判断以上内容不太明确的，可以参考清华大学的信息系统项目管理师教程的第84-86页的内容。但是今天的重点不在这些，我想说的是象我们这样的小公司，如何用浅显易懂的方法理清项目章程，让项目章程成为软件开发中的整体过程管理中的标杆文档，为项目管理提供提纲挈领的作用。我认为，项目章程在国内的小公司只需要抓住如下重点：一、项目名称、项目立项时间、项目小组成立时间、立项调研文档出处。大家不要小看上面四项，有很多公司的项目，项目小组内部对项目的名称叫法都统一不了，这样的素质怎么能让客户放心。二、客户描述这个客户描述是比较有学问的，一要描述客户的企业背景，二要描述客户的组织结构图，三要描述客户目前项目小组方的主要成员的姓名、联系方式。另外，要对客户在项目中的沟通方式做个简单描述，譬如客户中谁看迭代版本，谁看进度报告，谁看测试报告等，有的项目比较小，不用做项目沟通计划的时候，就可以依照这个沟通方式来执行。三、项目组及职能描述这节要分为两部分，一是描述开发方项目小组的主要成员、职务、联系方式；二要描述项目小组的职能矩阵，具体描述如下所示：序号工作单元高xx欧阳x张xx赵xx谭xx1需求调研Dddd2需求分析DDDD3项目沟通Ddddx4工作计划分解Ddddx5编码实现dDDD6架构实现DDDD7单元测试DDD8黑盒测试ddd9用例测试ddd10集成测试Dddd11上线实施Dddd12用户培训ddddD 重要决策者d 参与决策者 x 执行者四、项目远景项目远景包含以下内容：项目目标功能范围目标项目管理目标组织目标项目目标：师出必有名，做一个项目，必须让项目组成员明白这个项目是要实现什么目的，这个项目远景就是项目要达成的目标，譬如下面这句话：此项目是为完成客户总部生产技术部实验系统的无纸化管理，将以前手工登记的试验计划、试验结果评定、试验标准对比等纸张数据由计算机系统进行统一管理。这段描述是指的项目的完成目标。功能范围目标：如果在项目成立之初就了解更多的项目需求和信息，甚至还可以扩展写下诸如项目的功能范围目标（譬如要完成和实现哪些范围的功能），这个功能范围有别于具体的功能列表，可以说是项目的功能边界的描述，如果有项目范围说明书，那这里的功能范围目标就要保持前后一致，实际上项目章程也是项目范围说明书的必要输入条件之一。项目管理目标：我们都知道项目管理的铁三角（成本、质量、进度），也有人说项目管理有金四角（成本、质量、进度、功能），钻石五角（成本、质量、进度、功能、发展）等等（见张传波的UML视频），其实不管怎么解释，对各类中小型软件企业来说，首先要完成的是项目的目标本身，其次才是扩展项目的管理目标，这是一个渐进的目标层次。在这里，应该尽量量化项目的管理目标，而不要模糊化，因为目前国内的项目经理的能力普遍参差不齐的前提下，要通过短短的几次培训让他们明白何为项目管理太难了，还不如明确的告诉本次项目要完成的项目管理目标，譬如：在项目最终版本交付时，level300以上的bug数为零；项目章程中各项规定的文档提交齐全并通过外审和内审；项目总结时按期提交知识共享文章等等。项目管理目标是在完成项目目标并按约束条件验收（后面论述）的前提下，完成软件开发企业对项目管理过程提升和总结归纳的要求。说白了，在国内目前的情况下，很多中小型公司都要完成从项目到产品或解决方案的转变，否则项目做完了，企业也就无米下锅了。组织目标：组织目标和项目管理目标不同，项目管理目标是在项目管理过程中进行明确的要求，而组织目标则是站在企业战略目标的基础上对项目产生的提交物或是企业整体能力完善提出更高的要求。譬如：完成某某通用组件并形成可部署的解决方案1.0版本（含相关使用帮助），并在内审通过后完成企业内开发人员的使用培训；完成项目小组中开发人员对报表系统的开发能力的提升，并完成对企业内其它开发人员的报表系统的培训；在项目中尝试使用客户沟通管理系统，并提出完善意见和客户对沟通系统的使用反馈总结等。五、项目约束项目约束是指驱动项目成功的因素，在这里奉劝大家要站在出资人的角度去考虑这些约束条件，而不要过多的考虑上述第三条的项目管理目标、组织目标等，我前面说过，项目成功是先决条件，否则其它都是扯淡。我罗列一些项目的常见约束条件如下：约束备注项目资源人力资源、设备资源、关系资源等一切可以为项目成功或失败的因素对应的实体，可用鱼骨图分析发布日期在何时发布什么版本，对大部分项目来说，客户会只要求一个最终版本，这是不现实的，要告诉在最终发布版本前起码还有2个或以上的内测版本功能列表要完成哪些功能，即实现哪些必要功能是这个项目成功的必要条件，这个条件需要和客户反复的商榷，客户通常都是买小菜的念头，相信功能越多越好，要让客户理解项目成功的铁三角关系，这个需要进行多次项目管理思想的宣讲甚至培训缺陷管理要将缺陷控制在一个什么样的程度上，这个指标要量化，譬如在最终版本时，level300的bug要为零工作环境这点恐怕大家都不太注意，我要重点说的是就中小型公司来说，要竭力避免现场开发，这里写清楚，以后就少了很多扯皮的事情沟通管理有时候出资方的管理背景比较复杂，就要求项目经理要提早知道哪些干系人会对项目验收造成影响，要学会及时沟通和汇报，多打几个电话可以免去很多沟通障碍企业愿景这是指开发方对项目中产生的过程知识进行完善和规划的要求，通常这个对项目成功的约束很小，但在某些项目，譬如要完成项目到解决方案或产品的抽象时需要这个，不过要完成这个约束需要很高的项目管理造诣，如果项目比较有把握完成时才建议把这个纳入到约束中来以上只是列举了一部分，当然实际情况中，项目的约束有很多，不过对于大部分软件开发公司来说，基本上足够了。值得注意的是，项目的约束需要进行优先级别的排序。也就是说一个项目中，这些约束不要在同一个优先级上全部满足，根据我的经验，一个项目也就是一个高优先级的关键约束，另外加上两到三个的次要约束条件即可满足项目成功的所有必需条件，另外的约束条件应该作为锦上添花的约束进行罗列，完成了当然好，不完成也影响不了项目的总体验收。六、项目假设 就字面意思来解释，就是必需满足这些假设的条件，项目才可能按计划开展任务，这里的假设大家不要写得过多，而要集中关键假设上，这个需要结束上篇文章提到的项目约束来讲：为了大家不用翻上篇文章，我把描述粘过来值得注意的是，项目的约束需要进行优先级别的排序。也就是说一个项目中，这些约束不要在同一个优先级上全部满足，根据我的经验，一个项目也就是一个高优先级的关键约束，另外加上两到三个的次要约束条件即可满足项目成功的所有必需条件，另外的约束条件应该作为锦上添花的约束进行罗列，完成了当然好，不完成也影响不了项目的总体验收。因此，影响高优先级及次要优先级的假设条件才是你需要关注的：譬如：工期作为高优先级约束。有些项目有近乎苛刻的工期要求，这时首要保证的假设无外乎如下：人力资源（包括开发方和客户方，大部分项目经理在做假设时只估算了开发方，其实客户如果业务繁忙，没法配合你的需求调研、版本审核、业务指导等也会影响工期，如果有第三方，那么还要包括第三方）设备资源（计算机设备、网络设备、其它硬件设备、办公条件等）资金资源（人力成本、加班经费、风险准备金（这个要估足）、交通误餐等）知识储备（预估项目中可能遇到的知识难点，可以通过培训、外聘专家、外包等解决）根据项目实景分析（采用鱼骨图，SWOT等工具）会遇到的项目延期问题，譬如客户没一个懂需求分析重要性的，那就要安排相应的需求分析知识培训给客户项目假设是可以补充的，应该说项目假设有点类似于风险分析，但项目假设是着重于关键约束实现的必要条件，而不是应对方案。六、项目管理方法论 项目管理方法论就不过多阐述了，如果你的企业有一个完整的项目生命周期管理，那么这里其实就是选择相应的生命周期，如果需要适当裁剪的，要把裁剪后的周期详细说明。 瀑布、敏捷、RUP等这些都是生命周期的呈现形式，根据不同的企业特点，会对这些方法进行相应的改动以适应开发过程。七、项目的可交付成果这个很清晰，一般来说第1、2项是客户要求的，第3项需另外约定1、软件各个版本2、各个里程碑提交物（文档、阶段交付产品）3、项目过程中生产的其它附属提交物（通用类库或组件、附属开发产品（譬如一个小型OA）等八、概要进度这一项很多项目经理很反感，确实我也很不愿意预估，因为项目开始的时候很多条件都不是很明确，那些WBS在这个阶段是没法弄的，没办法预估，而项目章程非要来这么一项，怎么办呢。我提供一些思路给大家1、凭经验预测，这是最不靠谱的，建议不到山穷水尽的时候不要用，因为你一旦对企业承诺了，实现不了就全是你的责任了。2、短暂启动评估法老外也叫这个“哈德逊湾式启动”，方式源自17世纪加拿大的哈德逊湾航运公司，这家公司的商船在启航后，会在距离港口几英里的地方做短暂停留几天，这样确保如果忘记装载了一些必须的给养和装备，可以回到港口再补充。运用到项目管理中，可以让项目小组先尝试在项目的实际环境中先开展完成某些功能和工作，具体说来譬如一组测试驱动的代码或是某一组功能的思维导图，这个时间要尽量短，一般不要超过三天，如果你不好选择开展哪些工作，那么你可以选择手头上可以在4小时内完成的工作，完成之后，项目组一起来分析这些工作。如果还是不知道，那么请看下面的办法3、短期迭代和上面不一样，这个估算是以一组功能或工作完成后，团队成员来一起分析整个项目的工期，譬如说大家一起把需求分析中所需的功能点整理出来后，或是以某一组功能完成为前提，来进行工期的整体评估，这个时间最好在一周内。4、团队头脑风暴按任务从上至