项目章程是正式批准项目并授权项目经理权限的文件。在制定项目章程之前,我就被公司任命为该项目的项目经理。在项目起案以后,我拿到了本项目的项目章程。里面记载的内容有:项目目的或批准项目的原因,总体的预算,项目主要的风险有哪些,项目从开始到结束的里程碑,项目概要(到底要做什么),做到什么程度算成功的成功获准,有哪些主要的干系人等,作为项目经理我逐一和起案项目的人核对了项目章程中的内容,并参照核对了项目工作说明书,协议合同和商业论证的信息,和项目发起人对项目章程中关于验收的细节和可行性分析的内容确认并修改以后,项目正式起案并得到高层领导的签字承认。
管理干系人是对项目干系人的需求希望的识别,并通过沟通上的管理来满足其需要解决其问题的过程。干系人管理好了有以下三点好处:赢得更多的资源,能预测干系人对项目的影响,更好的理解用户需求。干系人管理具体管理的内容也有三个:沟通,问题,干系人分析。 在制定项目章程的同时,我就开始了识别项目干系人的过程。我首先参照了项目章程里面关于项目干系人的记载内容,识别出本项目的干系人有:团队成员,项目组合经理,项目主管,QA人员,部门负责人,总公司的技术窗口,总公司领导等,并参考原来公司的干系人登记册模版,将他们的基本信息:姓名,职位,邮箱联系方式等写入一个列表中,然后采用了权力利益方格和干系人人参与度评估矩阵进行了干系人分析;通过使用权力利益方格,找出了总公司窗口小组长和组合项目经理是本次重点管理的干系人,在使用了参与度评估矩阵理清干系人的参与情况之后,发现部门负责人当前的参与度是中立,而真实需要的是支持。把这些干系人分析的结果排序以后,我将其更新到干系人登记册中并和组合经理通过会议的方式交换了意见。
范围管理计划是如何定义,确认和控制范围的过程进行描述的过程。这个过程可以为整个项目中咱们如何管理范围提供了一个指南和方向。它的输入有项目管理计划,项目章程,输出是范围管理计划和需求管理计划;使用的工具与技术有会议和专家判断。
需求管理计划的内容有七种:1.如何规划跟踪和汇报各种需求,2.需求管理需要使用的资源有哪些,3.培训计划,4.项目干系人与需求管理的策略,5.判断项目范围和需求不一致的准则,6.需求跟踪结构,7.配置管理活动。项目的需求管理贯穿于整个项目的始终,它的主要任务就是明确干系人的需求,对于需求于关系人达成共识,建立需求基线和需求跟踪联系链的过程。
项目范围和产品范围有什么区别和联系呢?项目范围由项目范围说明书,WBS,WBS字典三项构成,用来确认项目可交付成果物是否已经完成的标准,简单说项目范围就是为了完成可交付成果而必须做的工作;产品范围是描述产品具有哪些功能,提供哪些服务;产品范围是项目范围的基础,而项目范围又是产生项目管理计划的基础。产品范围在项目范围说明书中描述,一旦产品范围变更了,那么项目范围说明书也需要相应的变更,所以产品范围首先受到影响的就是项目范围的变更。
在发布项目章程以后,我便马上着手开始了项目范围计划的编制,首先我参考了项目章程中对于本项目范围的概要描述和项目成功判断的标准后,在项目管理计划书的范围Sheet中,我简单写了如下大内容:打算由谁如何来做项目范围说明书,如何分WBS,如何进行可交付成果的确认和由谁负责制定变更控制流程等;而在需求管理计划制定的Sheet中,对于重构改善的要件,我打算通过分析遗留代码的坏气味来收集需求,对于新功能的开发,我打算使用问卷调查,产品分析和原型法结合的方式来收集需求,还有把如何去跟踪管理这些需求也简单的在该sheet中进行了描述。然后我便召集团队成员一起开会讨论了了范围管理计划和需求管理计划的内容, 集思广益听取了大家的意见以后,我对分解WBS的方法简单进行调整后,作为项目管理计划书的一部分,发布了范围管理计划和需求管理计划。
为了规划,编制,管理,执行和控制项目进度而制定的程序,政策和文档的过程。它的重要性不言而喻,在整个项目中要对如何有效管理项目进度提供方向性的指南。它的输入有项目管理计划,项目章程,组织过程资产和事业环境因素,输出就是进度管理计划,使用的工具和技术有:分析技术,会议,专家判断。为什么要制定项目进度管理计划?只有制定了比较详尽的项目进度管理计划之后,才能够制定如成本,设备采购,风险,人力资源,配置管理等计划,只有先制定了进度管理计划,才能够使整个项目的工作有条不紊的展开。所以它是其他这几个计划的基础。
进度管理计划的内容有:项目绩效测量方式,控制临界值,准确度,计量单位,报告格式和过程描述。它的内容基本上和成本管理计划是一致的。
在发行了项目章程并被授权为项目经理以后,我便开始着手制定项目进度计划。在参照了项目章程,了解了大概的进度里程碑以后,我决定和之前的项目一样,使用挣值管理的方式以每周为单位对进度绩效和成本绩效进行报告,并决定采用JIRA作为进度管理工具,结合成本管理以小时为计量的单位。为了更好的度量进度,我对JIRA 上的每个活动的进度,定义了度量的标准:具体是10%为理解完毕刚着手,30%-70%正在作成中(具体根据情况担任者自由输入),90%活动完成,等待验收,100%是验收通过。同时发生外部依赖或者选择性依赖的时候,将票状态从进行中改为待机中。并用Comment写出待机的理由。当进度绩效SPI出现正负0.1的偏差时,需要团队内部进行分析,当进度绩效值SPI出现正负0.2的偏差时,必须要向干系人报告进度偏差以及需要团队会议的形式讨论如何让进度走上正轨的对策。和成本绩效一样,和干系人商议后决定,在每周三下午一点的进度会议上,使用沟通管理制定好的绩效报告格式,对进度和成本的偏差情况,预测情况,产生课题情况,发生变更请求的情况等,一并事先总结好,向干系人发送进度绩效报告。
为了规划,花费,管理和控制项目成本而制定的程序,政策和文档的过程。它的作用就是给整个项目的成本管理提供政策和指南的过程。它的输入和范围,进度管理计划制定时是一样的,有项目章程,项目管理计划,组织过程资产和事业环境因素;它的输出就是成本管理计划,使用到的工具和技术有分析技术和专家判断,会议。
项目成本管理和干系人管理也是息息相关的,不同的项目干系人可能在不同的时间,以不同的方式测量项目成本。所以我们在做成本管理的时候要考虑到项目干系人的信息需要,同时应该更加关注为了完成项目所需要的成本。
在成本管理过程中,难免会遇到成本失控的情况,一般造成成本失控的原因有以下五种:组织制度不够健全,需求变更频繁,技术制约,对工程项目的认识不足,成本管理的方法有问题。
在发布项目章程以后,我便马上着手开始编制项目成本管理计划。成本管理计划的内容有:计量单位,临界值,绩效测量的方法,报告格式于频度,精准度等。我们首先参考了公司的事业环境,因和总公司甲方签订的是成本补偿类合同,设备硬件采购均为甲方负担,也就是说项目实施过程中作为项目经理只需要管控好人力资源这个直接项目成本就可以了。于是我参考了项目章程中关于总体预算的内容,并设定生产性指标为1.0。也就是项目实际耗费的成本除以我们估算的活动成本(包括应急储备,但不包括管理储备)。决定以挣值分析的方式来管理控制项目成本,同时规定,项目经理和高级技术工程师每小时单价为150元,中级工程师和初级主管每小时90元,初级工程师每小时单价为50元。然后在成本管理计划中注明了如果成本偏差在正负0.1时,在项目周会上内部共有偏差信息,并分析;如果成本偏差在正负0.2这个临界值时,需要向项目外部主要干系人报告成本情况并分析原因,并内部制定相应的对策。完成以上成本管理计划后,我先听取了团队内部的意见,经过修改后通过会议的形式展开给项目组成员甲方在内项目干系人并得到他们的承认。
识别项目相关的质量标准,以及为了实现这些质量标准,确定需要对哪些过程和工作产品进行质量管理。
它的输入是项目章程,项目管理计划,组织过程资产和事业环境因素,除了和其他过程相同的输入以外,干系人登记册,风险登记册,需求文件这三个输入。输出除了质量管理计划以外,多了过程管理计划,质量测量指标,质量核对单,可以采用的工具与技术有:成本效益分析,质量成本,质量的七工具,会议等,
还有一般不经常使用的统计抽样,实验设计,标杆对照。
质量的概念:质量是一组固有的特征满足要求的程度。需要区分它和等级的区别。用途相同但技术特征不同的可交付成果的级别分类是等级的概念。质量水平未达到标准要求是问题,而低等级不一定是问题。
质量管理就是合理运用好规划质量管理,实施质量保证和控制质量三个过程及其工具,使项目可交付成果物满足既定的质量标准和客户要求。
质量成本的概念:为预防产品不满足用户的需求,或者评价产品或服务是否符合质量要求,以及因未达到要求而发生的所有成本。质量成本包括了一致性成本和非一致性成本;一致性成本包括预防成本和评估成本,模板化流程化就属于预防成本,通过培训等方式提高了大家的质量意识就是预防成本,评估成本就是对产品进行测试的成本;非一致性成本又包括内部成本和外部成本,对应我们团队测试发现的BUG所消耗的成本属于内部成本,而对应在客户现场或者Beta版测试发现的BUG消耗的成本就是外部成本。出现了非一致性成本一般需要更多的返工成本。
成本效益分析:每一个质量活动所需要花费的成本与预期可以获得的收益进行对比比较的技术。
老七工具:流程图,因果图,直方图,散点图,帕累托图,控制图和检查表。
新七工具有:矩阵图,树形图,相互关系图,亲和图,程序过程决策图,优先矩阵图,活动网络图。
质量管理的八大原则:全员参与,持续改进,领导作用,过程分析,以事实为决策依据, 以顾客为中心,互利的供方关系,系统管理。
全面质量管理的四个特征:全员参与,全过程,全面结果,全面过程
全面质量管理四个环节:确认质量标准体系,对项目质量进行监控;将计划实际对照,纠偏纠错。
说到质量规划不得不说说它与成本之间的关系。成本效益分析和质量成本都是和成本相关联的质量的工具技术。好的质量不是通过测试检查出来的,好的质量是通过计划出来的。如果一次性把事情就作对,不产生计划外的返工情况,那么就是节约成本。所以我在制定项目管理计划时,特别注重规划质量管理。在项目计划过程中,在活动分解好并分配给各个团队成员,让他们进行成本估算时,团队遇到了无法对遗留系统重构的活动进行准确成本估算的问题。针对这个问题我参照了项目章程中描述改造功能的描述并参照了ISO9126质量模型,对于既有功能改善和重构的功能,制定了五个等级的质量测量改善的标准:1.必须要改善;2.不改善难以容忍;3.最好改善;4.基本不用改善;5.已经没有要改善的余地。同时安排团队中有多年嵌入式开发经验的小王以这个标准和活动建设实施者一起使用成本效益分析,先分析现在该模块目前的内部质量等级,再根据预算情况,决定花多少成本将遗留代码质量提升到哪个质量等级。采用了该方法后,我们通过成本效益分析方式,对不同模块设定不同的质量目标,再使用三点估算和专家判断的方式,估算出了项目活动的成本。
识别和记录项目角色,职责,所需技能,报告关系,并编制人员配备计划的过程。
它的输入有:项目管理计划,组织过程资产,事业环境因素,活动资源需求,它的输出就是我们需要编制的人力资源管理计划,可以用到的工具和技术有会议,专家判断这些通用的以外,还有人际交往,组织图与职位描述,组织理论这三项目。或许是因为组建什么样的团队一般都由乙方团队自己决定,所以不需要参照项目章程,相反需要参照组织理论和组织图等工具,来找到合适项目的人。
如何选拔项目经理:企业高层任命,内部竞争选拔,与用户协商决定
项目经理的五大权力:职位权力,惩罚权力,奖励权力,专家权力,参照权力。专家权力,参照权力来源于管理者自己,职位权力,惩罚权力,奖励群里来源于职位。
尽量少用惩罚权力,多用奖励权力,参照权力,专家权力,会使我们管理更加具备管理者个性魅力。
项目经理应该具备的技能:领导力,沟通协调能力,目标导向能力,项目管理能力,洞察力,专业技能,激励能力,冲突管理能力,团队协作能力;这些能力在人力资源管理中起到关键的作用。
因为根据要求需要为本项目组建一个项目型的团队,我先参照了项目管理计划中的进度计划,确认了上面大致的对于活动资源的需求后,得出结论:除了项目章程中预分派的两个人之外,还需要投入六个人才可以满足要求。其中中级工程师2人,主管2人,实习生或者初级工程师2人。于是我首先看了看2016年11月的公司体制图,看看有没有满足项目要求的人。找到几个候选人以后,我采用人际交往的工具技术,和候选工程师和组织中对应的职能经理分别进行了交谈,主要就是将该项目的重要性,大概跨度在1年多,以及团队成员在本项目中可以获得的成长等内容,通过沟通传达给他们。特别是高级工程师小李,因为经验丰富,同时在多个项目中开发,在组合项目经理的帮助下,和小李的职能经理合意好小李的资源日历,这样小李保证小李每周有一天的时间可以投入在本项目中。小李作为项目组资深工程师,担任重构框架设计,小周作为预分派的工程师,参与主要功能的开发,小王作为新人,除了帮助小周以外,还担任组织中配置管理和发行ROM管理的工作。在分配好各自成员的职责定义后,我将做成的人力资源管理计划和我的上级和团队成员一起开会确认,并最终合并到项目管理计划书中。
根据干系人的信息需要和要求,组织可用资产情况,制定合适与项目的沟通方式和计划的过程。它的输入有项目管理计划,项目章程,干系人登记册,组织过程资产和事业环境因素;它的输出就是沟通管理计划;工具与技术也基本上是通用的只有会议,除了会议以外,有沟通方法,沟通需求分析,沟通技术,沟通模型等。
沟通管理计划的内容有:沟通术语表,干系人沟通需求,沟通的频率,报告格式,需要沟通的信息,传递信息的技术与方法,负责沟通信息相关的人员,问题升级程序,随着项目进展,对沟通计划优化的内容,沟通制约因素等。
沟通模型由以下五个方面所组成:它们分别是沟通媒介,沟通噪音,沟通编码,沟通解码,信息和反馈信息。同时沟通模型包含了五个状态:已发送,已接受,已理解,已认可,已经转化为行动。已经转化为行动是这五个状态中最难的一环。
沟通方法有三个:推式沟通,拉式沟通,交互式沟通。
选择沟通的因素:沟通需求,时间成本限制,相关资源可用情况,以及对工具的熟悉程度。
沟通渠道有两个,一个是正式渠道,一个非正式。正式沟通渠道约束力强,容易保密但比教刻板;非正式渠道速度快,简单明了,缺点就是不容易控制,容易失真和曲解。
IT项目成功的四个要素:主管层的支持,用户的积极参与,有经验的项目经理,清晰的业务目标。这些因素都依赖于项目经理和团队具有良好的沟通能力。沟通能力已经列入质量保证成功的先决条件,项目经理八成以上的时间都是用来沟通。 沟通管理不当可能会造成各种问题。尽早规划沟通管理,可以为沟通分配相应的资源。
在沟通过程中要掌握一定的沟通技巧:赞美对方,移情入境,求同存异,倾听,适时合理的提问,正确有效的复述,听说者之间的角色转换,掌握好这些技巧可以让咱们都是沟通效率有很大的提高。
在项目章程得到批准后,我便调取了识别干系人的输出:干系人登记册,马上了解各个干系人对于项目沟通的期待后,对于内部干系人(有部门负责人,组合项目经理,团队成员,SQA)我制定了三个会议:每日早会(每日),内部成果Review会(不定期)和里程碑报告会;针对外部干系人的沟通需求,也制定了三个会议:技术课题讨论会(不定期),周报告会,月次报告会,同时规定好,并定义了会议的参加者,沟通信息内容和格式,会议时长等信息,比如以最重要的周报告来说,面向公司高层,依据领导关心的报告内容以进度成本,风险等为主,报告格式参考了之前的项目,保存在JIRA的Confluence中,会后会议纪要也同时记在上面,再邮件组展开等。在听取了本公司上级领导,团队成员,总公司合作伙伴等干系人的建议后,我将修改好的沟通管理计划合并到项目管理计划中。
项目干系人的管理由项目经理进行。规划干系人管理和识别干系人一样,都是一个需要在项目中反复进行的过程。 干系人管理计划的制定是为了调动干系人参与项目而制定的管理策略。 规划干系人管理的内容有:干系人当前的参与程度和期待的参与程度,干系人之间的相互关系和潜在的影响,干系人变更的范围和影响,现阶段干系人的沟通需求,需要分发给干系人的信息,向干系人发送信息的频率和实限,更新与优化干系人管理计划的方法。 制定干系人管理计划的输入有:项目管理计划,干系人登记册,组织过程资产和事业环境因素;它的输出就是干系人管理计划;工具与技术有分析技术,专家判断会议。
在制作沟通管理计划的同时,我同时开始做成干系人管理计划,参照识别干系人的结果:干系人登记册和参与度评估矩阵的内容,发现部门负责人当前参与度不够,在项目立项承认以后,还没有正式参与到项目中来,通过我的了解,他最近负责其他项目组较多时间无法参加,如果部门负责人不及时参与项目中来,会对组织中资源分配造成阻碍,针对这个问题,我找了项目组合经理沟通后,确定了对本项目可能需要的信息和每周可用于沟通的时间段和时长后,修改了沟通管理计划,到2017年春节为止,因其他项目,我们决定预约他任意出席项目会议,同时将项目里程碑的情况,通过邮件抄送给他,关于人员配备上面,在提前和其他经理协商好了后,再带着解决方案去找他承认。依照干系人实际情况,调整了沟通及干系人管理计划,项目也得以顺利推进。
它是决定如何进行规划和实施项目风险管理活动的过程。风险管理的核心思想就是提前发现项目的问题,为解决这些问题留有充分的时间和预算。风险管理的宗旨就是确保每一个风险都能够提前被发现被对策,而不是等到风险发生以后让自己忙着去救火。
制定风险管理计划的输入有项目章程,项目管理计划,干系人登记册,组织过程资产和事业环境因素,输出有:风险登记册,
工具与技术有会议,分析技术,专家判断这三种。
风险管理计划的内容有:预算,报告格式,跟踪,概率影响矩阵,概率影响分析,风险类别,方法论,角色与职责,干系人对风险的承受程度。
项目风险既包括了对项目目标的威胁,也包括促进项目目标的机会。未知的风险是无法管理的,只能够采取一般的应急处理措施来处理项目的未知风险。
风险的分类:
按后果划分:存粹风险和投机风险
按来源可以划分为:自然风险和人为风险
按影响范围:局部风险和总体风险
按可预测性:已知风险,可预测风险,不可预测风险
是否可管理:可管理风险,不可管理风险
风险后果承担者:业主风险,政府风险,承包商风险
项目风险管理的目标:增加积极事件的概率和影响,降低消极事件的概率影响
风险管理的重要性:减少项目整个过程中的不确定性。
风险管理与成本管理的关系:风险管理是成本管理的一部分,没有风险管理则成本管理是不够完善的。
我首先查看了项目章程中对于项目主要风险的记载,上面记载的风险有市场风险,技术风险,需求风险,变更风险,成本与进度风险和质量风险;因为制定风险管理计划首先就是需要考虑组织中干系人对于风险的态度和风险承受能力,所以我拿来的干系人登记册,尤其是对项目影响重大的干系人,对他们的风险偏好进行了分析。风险承受能力分析的结果为:项目组合经理和总公司的小组长对于风险承受力比较低,对于重构改善类的工作,只给出了最低的要求,而我方部门负责人对风险承受力比较高,因为他想通过本项目,对嵌入式系统进行框架改造后,让其他项目组都能够受益,所以对于重构和改善类的工作,给与了特别的支持和关注,希望我们能够尽量能做到完美。分析完干系人风险承受力后,我将如何对风险分类,风险预算大概是多少,风险报告和课题一起报告,风险跟踪由两个主管负责等风险管理计划的细节以后,我将上面的信息都记入到风险管理计划中,为了让全员都参与到风险计划中来,我随后召开了风险规划会议,在会议上对于如何管理风险听取了大家的意见以后,跟团队成员达成了共识。
略
制定项目管理计划 包括项目管理计划在内的所有的子计划的制定都可以是正式的或者非正式的,可以是非常详细的也可以是高度概括的。
定义,准备协调所有的子计划,并把它们整合为一份综合的管理计划的过程。
它的输入是其他过程领域的子管理计划,项目章程,组织过程资产和事业环境因素,它的输出就是项目管理计划,可以使用的工具与技术有:专家判断,会议引导技术。
项目管理计划包括了三个基准:成本基准,范围基准和进度基准;其他九个领域的子管理计划,再加上需求管理计划和过程改进计划,最后加上配置与变更,有配置管理计划和变更管理计划。
项目管理计划主要包含了哪几部分的内容?项目背景,项目各个干系人的情况,项目总体解决方案,项目的生命周期和各个阶段,项目的进度计划,项目的预算情况,变更流程和变更控制委员会等。
项目管理计划的作用:首先它是项目规划,执行,监控,收尾的指南,以便项目经理按照项目管理计划对项目进行管理,并有效控制风险情况。通过项目管理计划可以明确项目团队中每个人在团队中担任什么样的角色,起到什么样的作用。项目管理计划可以明确项目的目标,明确各个子计划的协调关系,促进管理者展望未来,预测未来项目可能发生的事情,并以此为决策的依据。
在项目正式立项并授权我为项目经理之后,我便开始制定过程计划和制定项目管理计划的工作。首先我根据成员之间的技能和熟悉的领域不同,将软件团队分为UI界面小团队,功能层对应小团队,中间模块对应小团队,工具研发小团队,测试小团队,并任命各个小团队中的项目主管。同时召集起各个小组的主管,对于如何分工协作,一起计划如何制定大项目过程管理计划和项目管理计划,在会议上,我们参照了从总公司那里拿来的产品规格说明书,结合项目章程中对于本衍生机型的开发概要性的叙述内容,以大的机能和生命周期的方式,分配给各个小组长,并在会议中合意好,进一步的范围分解和成本估算的工作交给各个小组完成后再汇总起来,同时为了让更好的实施对大项目的间接管理,每周三下午一点,召开只由小组长参加的Leader会议,目的是报告各个小组项目推进和绩效情况,同时沟通需要协作的工作内容。会议后,我将项目的各个子计划的制定工作分配给各个小组长,当各个小组长都完成各自的子计划后,我们又召开了一个会议,综合考虑了项目成本,质量,进度,风险,范围之间的制约因素并调整整体的计划后,作出了初版的项目管理计划书。
为了实现项目目标,记录并管理干系人需要和需求的过程。好的系统分析师不是用户说让我们做什么我们就做什么,而是更多的时候要站在用户的角度去倾听,去体会用户真正需要什么,并且帮助用户去解决问题。良好的需求来源于和客户反复的沟通。
它的输入有:干系人管理计划,干系人登记册,项目范围管理计划,项目章程,组织过程资产和事业环境因素
它的工具与技术有:问卷调查,原型法,文档分析,访谈,观察,会议,名义小组,引导式研讨会,头脑风暴,群体决策技术,群体创新技术,标杆对照,焦点小组,系统交互图等。
它的输出有需求文件,需求跟踪矩阵
需求可以分为六个种类:解决方案需求,质量需求,业务需求,用户需求,过渡需求,项目需求。其中解决方案需求又分为功能需求和非功能需求。
过渡需求:从当前状态过渡到将来状态所需的临时能力。
干系人需求:干系人和干系人群体的需要。
业务需求:整个组织的高层级的需求。
项目需求:项目需要满足的行动和过程,还有其他条件。
质量需求:用于确认项目可交付成果的成功完成。
重要性:没有需求就没有范围,只有先明确了需求,才可以定义范围。
常用的工具与技术:焦点小组,名义小组,引导式研讨会的区别
引导式研讨会:跨职能部门收集需求,有利于快速达成一致的意见。
焦点小组:特点是6-10人参加,需要一个专业的主持人参加
名义小组:强化版的头脑风暴技术。名义小组是群体创新技术的一种。除了名义小组以外,群体创新技术还有:亲和图,德尔菲,头脑风暴,思维导图,多标准决策分析等。
需求跟踪矩阵的状态有:进行中,已取消,新增加,已批准,已分配,已完成,已推迟。
需求的双向跟踪性:正向跟踪和逆向跟踪。 可验证性是需求的最基本特征。
收集需求是为实现项目目标而确定,记录并管理干系人需要和需求的过程。在XXX衍生机型开发工作中,主要分新功能的开发和既有功能的改善开发两类。针对新机能的开发,我们采用了调查问卷和原型法相结合的方法来收集需求,就拿微信打印这个新功能来说,我们在开发阶段先花了三周时间部分实现了微信打印部分演示功能,然后配置了微信打印的演示环境,放在公司小会议室中,同时发送全员邮件,告诉大家可以使微信免费打印微信中照片,在使用打印照片这个免费的午餐后,协助我们填写一份调查问卷来说明对演示版的意见和建议。该活动受到了公司全体员工的参与与好评,通过回收的问卷,我们也意识到大家对照片质量不高,打印速度太慢,不支持PDF打印等,针对这些意见和问题,我们又充分讨论了解决方案,并把讨论结果以用户故事的形式记入到需求文件和需求跟踪矩阵中。
范围定义是定义项目或产品详细描述的过程。它的目的就是明确项目产品,服务或成果物的范围的边界。
项目范围说明书的六项内容:产品范围描述,可交付成果,验收标准,除外责任,假设条件,项目边界,制限事项。
项目范围说明书的作用一共有五个:规划的基础,项目实施和监控的依据,变更的基础,与干系人沟通的依据,明确了范围的边界。
定义范围与干系人管理的关系:项目经理需要和干系人说明项目范围时,就是拿项目范围说明书去说明的。
它的输入:项目范围管理计划,需求文件,项目章程,组织过程资产
它的输出:项目范围说明书
它的工具与技术:引导式研讨会,备选方案生成,专家判断,产品分析
定义范围的重要性: 项目范围说明书的编制对于项目来说至关重要。可以在项目的规划过程中,对项目有更多的了解,并明确假设条件和制约因素。
项目范围说明书的做成是项目范围定义的主要内容。它一共有以下六个部分组成:产品范围描述,可交付成果,验收方法,制约因素,假设条件,除外责任。范围定义的清晰明白,能够让项目团队干系人等迅速明确项目的边界,可有效避免因范围模糊而产生的扯皮的现象。
在项目的实施过程中,我通过查看项目章程中关于范围概要的定义,明确了本次产品范围具体内容是在XX机型的基础上,新增XX机能,XX机能,并完成XX框架的改善工作。
我通过确认之前衍生机型开发的组织过程资产,明确了本项目的软件部分的可交付成果。具体来说有:衍生机型的发行ROM及相关开发管理文档。
我通过参考之前的项目经验,加上在需求收集时听取了重要干系人的意见以后,明确了本项目主要功能的验收方法,简单来说就是XX等新增功能能够综合测试评价没有问题,对于改善类功能,至少要保证与改善前外部质量要一致。
接下来我通过之前衍生机型产品分析,改善类功能结合质量测量指标,成本效益等工具与技术,明确了本项目的假设条件,除外责任和制约因素。
最后我将得到信息都归纳好,并将这些信息做成了Excel版的项目范围说明书。
将可交付成果物分解为较小的易于管理的组件的过程。
它的工具与技术有:分解和渐进明细的规划
它的输入有:范围管理计划,项目章程,组织过程资产。项目范围说明书,需求文件
它的输出就是:分解后的WBS(范围基准),以及项目文件的更新。
范围基准由三个部分组成:批准的项目范围说明书,WBS和WBS字典。
创建WBS有八个原则:100%原则,80小时原则,4-6层原则,滚动式规划,独立职责原则,不可再分原则,分解透明过程,包含原则。
WBS有两种表现形式:树形和列表型,树形结构清晰易懂,但是不容易修改;而列表型更加适合用于大项目中,它直观性较差,但是不容易被遗漏。
分解的原则:根据子系统,根据功能或技术原则(将不同的人的工作分开),根据组织结构。
创建WBS的重要性和意义:没有WBS就没有完美的进度计划。
创建WBS的作用:明确和准确说明项目范围,清楚的定义项目边界,为各个独立的单元分派人员,提高估算准确性,为进度安排和费用控制奠定基础,有助于防止需求范围的蔓延。
分解WBS的五个活动步骤:
1.识别分析可交付成果及其明细
2.确定WBS结构和编排方法
3.自上而下逐步细化分解
4.为WBS组件分配标识编码
5.核实分解的程度是否恰当
里程碑:标志着某个阶段或可交付成果物的正式完成。重要的里程碑是基线,重要的检查点是里程碑。
工作包:需要符合8/80小时的原则,是WBS分解后最小的单元。
控制账户:是一种管理控制点,方便测量项目的绩效。由多个工作包所构成。
规划包:对于远期的规划,它是工作内容已知但尚缺进度活动的WBS组成部分。
这三者的关系是工作包 < 规划包 < 控制账户
在和团队成员一起定义完项目范围后,我们都对项目的概要范围和项目的边界有了进一步的认识,为了接下来做成进度计划,并更好的管理项目的可交付成果,我在项目中使用了分解和滚动式规划等工具和技术,将项目可交付成果分解成了更加易于管理的一个个工作包。在分解之前,我先参看了范围说明书和需求文件,确定本次项目的可交付成果的情况,然后决定以子项目,大功能的方式分解第二层,有些大的功能和子项目再分为各个功能列表作为第三层,然后在以项目生命周期作为第四层来进行分解。明确了分解规则后我便按照这个规则,对可交付成果进行了自上而下的分解工作。分解完的WBS工作包,有些比较暧昧难懂的部分,我使用WBS字典对每个工作包对应的可交付成果进行了说明,并标上了WBS编码。最后我召集了小组长和组合项目经理,对WBS分解的粒度和妥当性进行了会议确认,然后又拿确认后的WBS和外部干系人进行了Review,在Reivew后内容修改好了以后,我将WBS,WBS字典和项目范围是说明书找部门长进行最终承认,最后有了第一版的项目范围基准。
识别和记录为完成项目可交付成果而采取的具体行动的过程。它的作用是作为项目工作进行估算,进度规划,执行监控和控制的基础。
它的输入是项目管理计划,范围基准,事业环境因素和组织过程资产; 它的输出是活动清单,活动属性和里程碑清单。 工具与技术:分解,滚动式规划,专家判断。其中定义活动的工具和技术和创建WBS是一样的。定义活动一般也是紧跟着WBS创建以后实施。
里程碑计划可以从项目的终点开始反向进行。在编制完成后要确认边界是否明确,是否无异议,是否与其他里程碑内容重叠。
在活动属性中,包括了活动标识,WBS标识和活动标签或名称。
进度管理的重要性:只有制定比较详尽的可操作的项目管理计划才可以统筹安排整个项目的管理工作,使得项目各方面的工作有条不紊的展开。
在做成的WBS的基础上,我召集了机能实现小组和预分派的高级程序员一起,把最急待实现的工作包分解成一个个活动,同时考虑到与总公司进度计划的依存性,首先我向总公司索要了大日程进度表,综合分析后做成了里程碑清单,定义了包括变更设计矩阵做成完了,Base功能内部测试通过,扩张机能内部测试通过等九个里程碑。并说明了达到里程碑的判定标准。根据标准,把已分解的活动逐一分到里程碑后,第一阶段活动定义结束。因为早期有很多未定事项,未分解的远期WBS工作包,准备在明确后再分解成详细的活动。有了明确的里程碑后,明确了每个项目阶段目标,避免了整体进度前松后紧的情况,规避了进度风险,里程碑对应的活动清单也让团队得到共识,明白各阶段为完成该里程碑需要具体做什么事情。
它是识别和记录活动之间相互关系的过程。排列活动顺序的作用是:以便在既定的项目约束的前提下,获得最高的效率。
排列活动顺序的工具与技术:紧前关系绘图法,提前量和滞后量,确定依赖关系
排列活动顺序的输出:活动进度网络图,项目文件更新(活动属性和活动清单的更新)
排列活动的输入:进度管理计划,活动清单,活动属性,组织过程资产和事业环境因素,项目范围说明书。
活动之间的依赖关系有四种:内部依赖,外部依赖,选择性依赖,强制性依赖。其中这四种依赖关系是可以组合的。
前导图(PDM):圆圈表示活动,箭头表示活动之间依赖关系的网络图。也叫做单代号网络图。
箭线图(ADM):箭线表示活动的网络图。它叫做双代号网络图。
前导图和箭线图的区别:紧前关系绘图的时候一般用的就是前导图法,箭线图也就是双代号网络图相对来说使用的比较少。箭线图中需要使用虚活动来辅助说明活动之间的前后关系。
前导图法包括了活动之间的四种依赖关系:开始-开始,开始-结束,结束-开始,结束-结束。、虚活动:虚活动既不消耗时间,也不占用资源(这点跟里程碑计划一样),它仅仅用在箭线图中弥补箭线图在表达活动依赖关系方面的不足。
在前导图的每个活动也可以用六方格来表示分别表示:最早开始时间(ES),最早结束时间(EF),最迟开始时间(LS),最迟结束时间(LF),活动工期,总浮动时间。
总浮动时间和自由浮动时间的区别:总浮动时间是基于项目的关键路径不可变的前提下,活动可以自由调整的时间;而自由浮动时间是指在不影响紧后活动最早开始的前提下,本活动可以自由浮动的时间。
总浮动时间的计算方法:本活动的最迟开始时间减去本活动最早开始时间。所以相对于自动浮动时间,总浮动时间更加好求。
关键路径:完成所有的活动需要最长的时间的那个路径就是关键路径,其中关键路径可以是有多条的,项目在实施过程中各个活动也有可能提前完成,也有可能延迟未完成,网络图在不断变化的时候,项目的关键路径也是在不断的变化的。
时标网络图:以实箭线表示工作,实箭线的长度表示工作的持续时间;虚工作用虚线垂直线;波形线表示本活动与其紧后活动之间的时间间隔。
在时标网络图中求关键路径比较简单了,只要看看没有波形线的最长路径就是关键路径。
关键路径上的总时差和关键时差一定是0。这个是恒古不变的定理。
活动之间往往是有相互联系的,如果在编制进度计划之前,不对各个活动之间的关系进行有效的识别并明确相互之间的优先顺序的话,将会影响进度已经开发的效率。在明确了这些以后,我作为项目经理,首先就参照活动清单和活动属性,开始识别活动之间的相互关系,活动之间的相互影响关系有:选择性依赖,强制性依赖,内部依赖和外部依赖四种对于每一个活动,我都和项目团队一起进行分析,找出活动之间的关系,并将这些事先识别的依赖关系写到JIRA的说明中,然后再JIRA票之间加上相互关联。在此基础上,我参照了里程碑计划,对于近三个月内不得不完成的所有活动采用紧前关系绘图法,简单的画出了单代号网络图。明确了项目活动之间相互关系之后,就可以进一步下一步:对活动资源的估算和活动持续时间的估算。
定义:估算执行活动所需的材料人员设备或用品的种类与数量的过程。
作用:明确完成活动所需的资源种类和数量,以便做出更加准确的成本和持续时间估算。
特点:该过程与成本估算过程密切相关,资源的成本可能影响对资源的选择;该过程要考虑风险管理的情况,因为风险事件可能影响资源的可用性以及对资源的选择;它与人力资源管理也有关系,资源日历来自于人力资源管理过程。
它的输入有:进度管理计划,活动属性,活动清单,资源日历,风险登记册,活动成本估算,事业环境因素和组织过程资产。
它的输出有活动资源需求和资源分解结构两项。
活动资源需求:明确了工作包中每个活动所需的资源的类型和数量。 资源类别包括了人力资源,材料,设备和用品。
资源分解结构的作用:结合资源的使用情况,组织与报告项目进度数据。
只有给各个项目活动分配相应的资源以后,才可以做成合理的进度计划。首先我查看了资源日历,确认我的项目组成员每天能够投入到项目中的时间资源。除了资深工程师老王需要兼任另外一个项目外,其他的项目组成员都能够100%在每个工作日投入到项目组中。然后我查看了成本估算的结果,核实了每一项活动所需要花费的成本大概是多少后,将各个活动的担任者改成了各个项目组的成员,最后查看了风险登记册,在确认资源可用性上面的风险可控的前提下,简单的对担任各个活动的担当者进行了调整后,做成了活动资源需求。有了活动资源需求以后,为做成合理的进度计划奠定了基础。
估算为了完成项目活动所需要的时间资源的过程。
它的输入:进度管理计划,活动清单,活动属性,资源日历,风险登记册,,活动资源估算,活动成本估算,组织过程资产和事业环境因素
它的输出:活动的历时估算,项目文件更新(主要有活动属性,活动清单的更新)
它的工具与技术有:PRRT评审技术,类比估算,参数估算,自上而下估算,储备分析,群体决策技术。
估算项目中各个活动所需要的时间长短的过程就是估算活动持续时间的过程。它的输出活动持续时间估算的结果是制定进度计划的重要输入,也只有明确了活动的持续时间以后,才能够排出合理有效的进度计划表来。对于各个活动的持续时间,我主要还是采用了三点估算的方式,在各个活动明确了担任者和责任者以后,我就安排由担任者,责任者和项目经理(我)一起对活动的所需时间进行估算,对于XX功能实现的活动,我们先预测了一下在最理想的情况下,大概需要2天时间可以完成,然后参考项目的风险,如果在发生了等待的时候或者出现质量问题产生返工的前提下,大概估算需要1周的时间,最后讨论了最可能的时间后,根据三点估算的公式,得出XX功能实现的活动需要3天完成的结论。以此方法,我们对项目中所有的工时都进行了简单的估算,最终就有了估算的活动时间。逐一将估算出来的活动时间计入JIRA票后,我们迅速汇总了定义活动,排列活动顺序,估算活动资源,估算活动持续时间的成果物,开始着手项目进度计划的制定。
分析活动顺序,活动持续时间,活动资源需求和进度制约因素,并创建项目进度模型的过程。
它的输出有很多,包括了之前定义活动,排列活动顺序,估算活动资源,估算活动持续时间的输出,
除此以外还有和人力资源相关的资源日历,和风险管理相关的风险登记册。
它的工具与技术:关键路径,关键链,提前量和滞后量,储备分析技术,资源优化技术,进度压缩技术,进度编制工具,建模技术。
它的最主要的输出就是进度基准。还有什么进度数据,项目日历,项目进度计划的更新等。
资源优化技术包括了资源平衡和资源平滑两个。资源平滑一般不会改变项目的关键路径,而资源平衡往往会让关键路径变长。
资源平滑主要是解决资源使用忽高忽低波动大的情况,资源平衡是解决关键路径上资源不足的问题,往往是有对资源过渡分配的情况。
进度压缩技术也包括两个:赶工和快速跟进。
缩短项目工期的方法有五种:缩小项目范围,赶工,快速跟进,用高技能的资源替换新人,提高质量改善过程减少返工。
关键链法:它是基于关键路径的基础上的一种进度规划管理方法,它允许在项目的任何地方设置缓冲。它把对项目进度的管理反映到对项目缓冲时间的管理上,
这里需要明白两个概念:项目缓冲是在关键链末尾的缓冲时间,而接驳缓冲是不在关键链末尾的缓冲时间。
接驳缓冲放在关键链和非关键链之间的结合点。
使用了关键链法以后,就不再管理网络路径下的总浮动时间,而是变为管理剩余缓冲持续时间和剩余活动持续时间之间的匹配关系上。关键链法用统计的手段确定缓冲时段,作为各个活动的集中的安全冗余。
活动的实施需要时间,合理估算每个活动所需时间才能做成有效的项目进度计划。而且只有少部分活动完全独立,大多数已定义的活动,有些彼此之间内部依赖关系外,还有些活动与总公司大日程之间也存在外部强制依赖的关系。所以除了实现难易度,既有代码复杂度,成果物数量外,我们将活动依赖关系也作为专家判断估算时间的重要理论依据。我邀请预分派的专家程序员和担当者一起参加估算,比如安全密码打印功能在XXXX机中有类似的开发经验,便采用类比估算的方法估算了下面各个的活动包的时间。而卡纸重新印刷功能是首次新增的功能,它的工作包我们便采用会议讨论和三点估算得出活动时间。自下而上汇总各个活动时间后,因整体风险,也估算了项目的管理储备,以备将来关键路径进度落后赶工时使用。
在明确了活动先后次序,识别关键路径,分配资源后,并将信息录入JIRA系统,于是就有了本项目的进度管理计划。得到高层领导的承认后,此计划变成为了初版进度基准。
设定合理的估算依据,根据活动属性不同,结合风险因素后的三点或类比估算,预分派的高级程序员的专家判断,使我们有了较为合理的项目时间估算。进而做出较为合理的进度日程。
估算成本是对完成项目所需要的资金进行近似估算的过程。
估算成本的工具与技术:三点估算,类比估算,自上而下估算,储备分析,质量成本
估算成本的输入:项目成本管理计划,范围基准,组织过程资产和事业环境因素,风险登记册,人力资源管理计划,进度管理计划
估算成本的输出:项目活动成本估算,估算依据和项目文件的更新。
估算成本的步骤:首先确认构成成本的科目,然后估算每一个构成成本科目的成本;对成本构成科目以及估算的成本进行再确认和调整(找出可以替代的成本)
成本估算和制定预算之间的区别和联系
估算成本是对完成项目活动所需要的资金进行近似估算的过程,而制定预算是汇总所有工作包的成本,并建立成本基准的过程。
制定预算侧重于汇总各个活动包的成本,而估算成本侧重于估算单个活动的成本;
制定预算的结果成本基准是需要批准的,而估算成本的输出是不需要批准的;
制定计划需要考虑在项目实施过程中怎么花钱,估算成本不需要考虑;
成本估算需要不需要考虑项目是否盈利等信息,而制定预算过程中是需要考虑项目的盈利的。
汇总所有单个活动或工作包的估算成本,建立一个经批准的成本基准的过程。
它的输入有:成本管理计划,范围基准,资源日历,活动成本估算,项目进度计划,风险登记册
它的工具与技术有:资金限制平衡,专家判断,储备分析
它的输出就是成本基准
大项目可能会有多个成本基准,来度量项目绩效的多个方面
制定预算的步骤:
1.将项目总成本分摊到WBS工作包
2.将各个工作包成本再分配到各个活动上
3.确定成本支出的时间计划和成本预算计划
编写成本预算的原则: 1.以项目需求为基础 2.成本预算要与项目目标相联系 3.预算要切实可行 4.预算要留有弹性
风险识别是一个反复的过程,在项目进行中,随时有可能出现新风险。 风险识别主要包括了:识别并确定项目有哪些潜在的风险,识别引起这些风险的主要的原因,识别这些风险可能会引起的后果。
风险登记册的内容:已识别的风险清单,潜在应对措施清单,风险根本原因,风险的类别。
项目组应该在需求分析之前就列一张风险的清单,直到项目结束前不断地更新这张清单。
它的工具与技术:SWOT分析,专家判断,文档审查,假设分析,信息收集技术(头脑风暴,德尔菲,访谈,根本原因识别),核对表分析,图解技术(因果图,影响图,过程流程图)它的输出只有一个就是风险登记册。因为输入需要各个子计划为基础,所以识别风险需要范围,成本,进度,质量,人力资源,采购等的子计划作为输入,当然还有风险管理计划。
越早识别风险,越早管理风险,就越有可能规避风险,促进项目成功。在项目需求分析开始之前,我就开始制定了项目风险计划,作为项目经理我的采用会议的方式去识别风险,除了团队成员外,还邀请了项目重要的干系人一起参加风险管理计划会。在会议上我规定大家根据以前项目的经验和本项目特有特征,按顺序发言,为达到头脑风暴的效果,规定不许评价打断别人的风险发言。逐一发言完后,我将大家集思广益后的风险进行了归类,得到以下五大类:需求风险,范围风险,团队风险,关键人物离职风险和超预算风险。并将分类后的风险情报记入了风险登记册中。
定性风险分析工具与技术有:风险概率与影响评估,概率影响矩阵,风险数据质量评估,风险分类,风险紧迫度评估,专家判断。定性风险分析是对风险概率和影响评估和汇总,并排序风险以便进一步对风险进行分析的过程。它的输入有风险管理计划,风险登记册,还有组织过程资产和事业环境因素,输出有项目文件的更新,主要就是风险登记册的更新。
定量风险分析的工具与技术有:敏感性分析,决策树分析,预期货币价值分析,龙卷风图,蒙特卡洛分析,专家判断,访谈,概率分布。就识别的风险对项目总体目标的影响进行定量的分析的过程。它的输出是项目文件的更新,最主要就是风险登记册的更新,它的输入除了风险管理计划和风险登记册以外,因为要模拟对项目总体的影响也就是对SPI和CPI的影响,需要参照成本管理计划和进度管理计划。
定性风险分析强调单个项目风险发生的概率和影响的过程,而定量风险分析是针对单个风险的不确定性对整体项目的影响度的分析的过程。作为项目经理的我,对于风险的分析,也使用了会议的形式来推进。与之前通过会议召集全员集思广益的方式不同,风险分析会议我只召集了业务专家,预分派高级工程师参加。首先我们对五大类风险进行了主观优先度高低的排序,然后参照已完成的风险概率影响图定义和概率影响矩阵,使用会议讨论加上专家判断总结加德尔菲的方式,逐一分析了各风险,在随后的定量风险分析中,我使用了蒙特卡洛分析,建模分析出风险对项目的影响后,于是和业务专家,预分派的高级工程师展开了激烈的讨论,发现已识别的定义在风险登记册中的风险中,团队风险和需求风险发生可能最大,且发生概率中等偏上,影响中等偏上,故我将其定义为最重要需重点关注的风险。而关键人员离职虽然在定量分析中对项目的偏移最大,但发生概率不高,所以作为了次重要风险来进行管理。
针对项目目标而制定提高机会,降低威胁的行动的过程。
风险来源:需求风险,技术风险,政策风险,市场风险,运行风险,团队风险,预算风险,范围成本,质量等其他风险。
工具与技术:积极的风险应对计划,消极的风险应对计划,应急应对计划,专家判断
它的输出:项目文件的更新(风险登记册的更新),项目管理计划的更新
积极的风险应对计划有:开拓,分享,提高,接受
消极的风险应对计划有:回避,转移,减轻,接受
针对需求分解不充分,业务需求理解发生偏差的情况,我们讨论后决定采用减轻回避的方法,具体由我们的业务专家参与所有需求分析的审核工作,并导入UML用例图与总公司业务专家核实需求。而对于团队年轻化战斗力不足的风险,采用外部招聘高技能资源和开展团队建设活动。依据优先度剩下的风险也如此制定了应对计划。最终该风险管理计划得到了高层领导的承认。
质量保证的工具与技术有过程分析和质量审计。它主要的目的就是保证过程的质量。
质量保证的输入:质量管理计划,过程管理计划,质量测量指标,组织过程资产和事业环境因素。
质量保证的输出:变更请求,组织过程资产更新,项目管理计划的更新,项目文件的更新
质量保证过程和质量控制过程都会输出变更请求。除此以外质量控制过程还有工作绩效信息的输出。
质量保证是有计划实施的质量活动,质量保证活动贯穿于整个项目。质量保证的最终要的工具与技术就是质量审计。
质量保证和质量控制的区别于联系:
质量保证强调的是过程的改进和审计,强调的是过程的改进和提高干系人对于质量的信心。
而控制质量是按照质量定义的要求,对项目可交付成果物进行检查确认的过程,强调的是具体的项目可交付成果物。
一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作,包括质量控制和质量改进。
质量审计的定义:识别在项目中效率低下的并且需要改进的过程。质量审计可以是预先计划的,也可以是随机进行的,可以是组织内部完成的,也可以委托第三方来一起完成。
质量审计还可以对变更请求进行审计,
质量审计的目的有五个:
1. 识别正在实施的过程中好的项目实践
2. 识别正在实施的过程中需要改进的项目实践
3. 将良好的项目实践在组织内推广
4. 强调每一次质量审计都对组织作出一定的贡献
5. 帮助项目团队和组织制定改进计划并实施过程改进
质量审计于过程分析的关系
两者的概念很相似,但是过程分析强调的是识别项目中的非增值活动,强调按照计划对过程进行分析,确认过程是否按照计划进行的。
QA的职责有哪些:
在计划阶段规划质量,并确定质量过程计划
在实施过程中,根据计划实施质量的检查工作
在实施过程中,根据过程改进计划,对项目进行审计,找出非增值活动,并提出改善意见
定期给项目干系人发送质量报告
为项目组成员提供质量管理方面的培训与指导
QA的指责:过程指导,过程评审,过程改进,过程度量,产品审计。
具体而言QA担任的QA三个角色扮演:警察角色(项目过程中),医生角色(项目过程中),教练角色(项目前期)
质量保证应该以证明项目满足相应的质量标准为目的。具体说来有:
设法提高项目干系人对项目将要满足质量的信心。
按照过程改进计划进行过程改进,并减少非增值环节
按照质量管理计划实施具体的质量活动,让项目过程和产品符合质量的要求。
根据过去的质量控制的结果,对质量标准进行重新评价,确保所采用的质量标准是合理且可以操作的。
为实现项目目标而领导和执行项目管理计划中确定的工作,并实施已批准的变更的过程。
它的输入:批准的变更请求,项目管理计划,组织过程资产和事业环境因素
它的输出:可交付成果,变更请求,项目文件更新,组织过程资产更新,工作绩效数据
它的工具与技术:会议,专家判断,项目管理信息系统
指导与管理项目工作包括了三部分:
纠正措施(针对已经出现的偏差)
预防措施(针对即将要出现的偏差)
缺陷补救(针对产品或组件的质量问题)
确认范围是正式验收项目可交付成果的过程。它的作用是提高最终项目,服务,成果被验收的可能性。确认范围这个过程和识别干系人识别风险等过程一样,都需要贯穿项目的始终。它的工具与技术有:检查和群体决策技术。这两个技术和质量控制是一样的。
确认范围其实并不容易,难点就是在与用户的沟通上。要让客户认识到虽然范围确认是可交付成果物正式验收的过程,但并不表示项目的范围就不能再修改了。
它的输入有:范围管理计划,需求文件,需求跟踪矩阵,组织过程资产和事业环境因素,核实的可交付成果,工作绩效数据
它的输出有:验收的可交付成果,变更请求,工作绩效信息,项目文件。
1.确认范围和质量控制之间的区别和联系
确认范围主要强调的是可交付成果的客户的确认和接受,质量控制强调通过检查等手段确认可交付成果的正确性;
质量控制一般在范围确认之前进行,确认范围一般在阶段或者末尾进行,质量控制和范围确认也可以同时实施;
质量控制属于内部的检查,而范围确认则是外部干系人对项目的验收。
2.范围确认和项目收尾之间的区别与联系
范围确认和项目收尾一般都是在项目或阶段末进行 范围确认更强调对可交付成果的确认与接受;
而项目收尾强调的是项目结束时的流程性的工作。
范围确认强调验收可交付成果,而项目收尾强调对产品服务的验收。
确认范围一般可以分为五个步骤:1.确定需要范围确认的时间 2.识别范围确认需要哪些投入 3.确定范围正式被接受的标准和要素 4.确认范围确认会议的组织步骤 5.组织范围确认会议
范围确认需要检查的六个问题: 1.可交付成果是确定的可确认的 2.每个可交付成果是否有明确的里程碑 3.是否有明确的质量标准 4.覆盖了所有活动没有遗漏 5.审核和承诺是否有清晰的表达 6.项目范围的风险是否太高。
范围蔓延和质量镀金:
未经授权的范围的扩大就是范围蔓延。质量镀金就是干了不属于范围内的活,质量镀金是主动的范围扩大,范围蔓延是被动的范围扩大。
范围确认是在项目实施过程中对可交付成果物进行验收的过程。如果和干系人范围确认过程做得好,可以大大提高项目最终成果物被验收通过的可能性。在项目开始前,我便查找之前机型开发的组织过程资产,发现了在之前的衍生机型开发中,出现过和干系人范围确认时,却文档资料,版本有问题等情况。出现该问题就是因为范围确认过程没有管理好,没有对范围确认后的可交付成果物进行有效的配置管理。为了在本项目中避免同样的问题发生,我要求项目组成员将开发文档和管理文档都放入SVN以方便管理,同时对于每张JIRA票对应的可交付成果采用检查的技术。首先进行严格的内部检查(质量控制),测试报告书中所有的测试用例都已经动作完毕并确认没有错误,质量核对表的要求都已经实现,代码和文档等可交付成果物都放入SVN,并在JIRA上给出相应的链接后,才可以将JIRA票改为已解决的状态,再由两个小组长检查没有问题后,打上内部范围确认完毕的标签,内部加强对可交付成果的质量控制和范围管理后,由我每两周再从SVN配置库中取出可交付成果,顺利得完成了项目可交付成果的范围确认。
它的作用是在整个项目生命周期内对范围基准的维护。
输入:项目管理计划,需求文件,需求跟踪矩阵,组织过程资产和事业环境因素,工作绩效数据
输出:变更请求,工作绩效信息,组织过程资产更新,项目管理计划更新,项目文件更新
工具与技术:偏差分析
变更控制的工作有三点: 1.影响可能导致范围变更的因素 2.判断范围是否已经发生变更 3.范围变更发生时管理实际的变更
造成范围变更的主要原因是: 1.政策导向(事业环境) 2.范围计划不够周密,有遗漏(范围计划) 3.市场上出现新技术设计人员提出新技术方案(事业环境) 4.项目执行组织发生了变化(事业环境) 5.客户对项目或者产品要求发生了变化(干系人需求)
作为本项目的项目经理,我十分清楚,相比新增功能的开发,既有功能的改善和重构更加容易出现范围蔓延和质量镀金的情况。为了防止这个情况发生在项目中,在项目开始前,我就参照范围管理计划,制定了范围基准变更的流程,规定不管是内部还是外部提出的变更,都必须以书面形式记入需求文件之后,再口头通知我。同时成立了临时CCB小组(干系人代表,我的上级领导和我)来对范围和需求的变更进行决策,等CCB小组将批准变更的信息更新到需求文件之后,才可以在JIRA上起票并对应,一张JIRA票只能对应本功能点的代码提交。同时在每周五的进度会议上确认JIRA票的情况,先确认是否有增减,并确认对于上一周内提交到主库的差分代码和文档,确认每一张JIRA票是否有多余内容的提交,如有多余的提交项,由我和该成员先做偏差分析并判断重要程度,判断影响项目范围基准的时候,以变更请求的方式补报给CCB,并召开会议对偏差内容进行分析,来防止预想外的范围蔓延和质量镀金的情况。因为在规划范围管理过程中,制定了较为完善的范围控制流程,并在实施过程中结合配置管理工具每周对提交至主库的可交付成果进行了严格有效的管控,所以范围控制一直做了不错,没有出现范围的蔓延。
如何分析进度的偏差:
分析产生进度偏差的工作是不是关键活动
分析进度偏差是否大于总时差
分析进度偏差是否大于自由时差
对项目进度计划的调整。
进度控制应该关注的内容有:
判断当前项目的进度状态
对引起进度变更的因素施加影响,以保证这种变化朝着有利的方向发展。
判断项目进度是否已经发生改变
当变更实际发生时严格按照变更控制流程对其进行管理。
进度延迟的原因一般有以下四点:
1.计划方面:计划做了不充分未考虑风险等。
2.人员方面:增加新手,工作效率低下
3.技术方面:错误导致返工
4.管理方面:监控粒度过大,估算工作量不够准确
JIRA上不仅可以要件课题管理,也可以自动生成为甘特图查看进度。输入每天的进度后,将进度可视化表示出来,达到进度建模的效果。为了花更少时间更好的把握效果,作为项目经理,我要求团队成员们周一三五下班前在JIRA上输出一次进度,周二四通过早会的形式核实进度。因为分解后的活动时间均在20-70小时/人,和团队成员一起开会合意了进度刻度。10%为理解完毕刚着手,30%-70%正在作成中,90%活动完成,等待验收,100%是验收通过,先前识别过的和总公司的外部强制依赖发生时,将JIRA票改为待机中,并写明具体原因在JIRA上。出现技术难题,无法预估剩余工作量时,把课题也写进JIRA票上便于项目绩效的报告。
有了团队成员准确输入的进度绩效数据,在项目进行到第七周时,通过挣值和绩效信息,及时准确的分析出了进度偏差。采用会议形式问题分析,分析后得出是某个需求分析不充分,需要花额外时间调查,且判断延后将影响关键路径后,我安排了预分配的高级程序员,并采用赶工的对策,两周后让进度走回了正轨。
监督项目成本的状态,以更新项目成本,管理成本基准变更的过程。它的作用是在整个项目周期内对成本基准的维护。
它的输入有:成本管理计划,工作绩效数据,组织过程资产和事业环境因素
它的输出有:工作绩效数据,变更请求,组织过程资产更新,项目文件更新,成本预测
工具与技术:挣值分析,预测技术
项目成本控制活动不是个人的活动。 项目成本控制是以工作包为单位
成本控制包括了:
对造成成本基准变更的因素施加影响
确保所有的变更请求都得到及时的处理
当变更实际发生时,管理这些变更
确保成本支出不超过项目限额 监督成本绩效,分析与成本基准的偏差
对照资金的支出,监督工作绩效 防止出现未批准的变更
向干系人报告经过批准的变更和响应成本 挣值技术:它将项目的(资源)成本,范围,进度等综合考虑在一起,帮助项目管理团队评估项目绩效的方法。
典型偏差和非典型偏差:典型将错就错,非典型是知错就改,改正了计算就方便了。将错就错所以要除以成本绩效指数,非典型是因为已经改正了所以计算就变得简单,不需要参杂进CPI了。
质量控制是采取措施监督项目活动实施结果是否符合有关的质量标准,并确定消除产品不良结果。
它的输入:可交付成果,工作绩效数据,组织过程资产和事业环境因素,质量管理计划
它的输出:验证的可交付成果,变更请求,工作绩效信息
质量控制的工具与技术:检查,质量七工具,统计抽样
质量位于范围,成本和进度中间,任何一个因素的变化都可以对质量造成影响。规划质量管理之前需要以项目管理计划为输入,而项目管理计划当中包括了成本基准,范围基准,进度基准,应该在这三个基准的基础上,规划质量的管理。
质量与范围的关系:质量控制和范围确认的工具及技术中,都有检查,这两个过程可以同时进行,也可以在质量控制以后,在范围确认中对项目可交付成果物进行核实验收。质量如果出现了问题,当然直接影响范围确认的结果。
质量与成本的关系:成本效益分析,质量成本这两个工具。高质量需要花高成本。如果质量不满足要求,就需要花更多的成本来保证质量。质量测量指标的高与低,将直接影响到项目的成本情况。
质量与进度的关系:提高可交付成果的质量,是挽回进度落后的一种方式。质量测量指标越高,在其他因素都不变的前提下,当然需要花更多的时间进行对应。
统计抽样这个工具的使用就是充分考虑了质量和成本之间的关系
质量与风险的关系:质量成本中有非一致性成本中的外部成本,这个可以和风险来一起谈。风险登记册在质量规划的时候输入,风险登记册中的内容可能包含影响质量要求的各种威胁和机会的信息。
提升项目质量的基本步骤:
1.建立项目质量目标
2.建立质量保证和质量控制的规范
3.建立对质量参数的度量体系
4.在项目中对产品和可交付成果物的质量进行检查
5.对质量问题进行分析,并提出改进措施
6.不断的循环以上的过程,坚持不懈地提升项目质量。
质量控制的作用:
1.识别过程低效或者产品质量低劣的原因,建议采取相应的措施来消除这些原因;
2.证明项目可交付成果已经满足干系人对质量得到要求,足以进行既定的验收。
3.审查已经批准的变更请求也是质量控制的一部分工作,也算是质量和范围之间的关系吧。
质量控制的具体内容有哪些:
按照质量标准进行质量的检查,发现偏差和质量缺陷,并对质量偏差提出纠偏建议,对质量缺陷提出补救建议。
纠偏建议和补救建议都属于变更请求。
对已完成的可交付成果进行检查。如果不合格就提出变更请求。
对已批准的变更措施实施检查。如果缺陷补救已经到位,则确认为可交付的成果。
风险监控的定义是跟踪已识别风险,检测残余风险,识别新风险,实施风险应对计划并对其有效性进行评估的过程。
权变措施:实现没有计划的风险,临时想出来的办法。
风险审计:检查并记录风险应对措施,处理已识别风险及其根源上面的有效性,以及风险管理过程的有效性。审计风险会议之前要明确审计风险的格式和目标。
工具与技术:风险审计,风险再评估,储备分析,偏差与趋势分析
输入:风险管理计划,风险登记册,工作绩效数据,组织过程资产和事业环境因素
输出:变更请求,工作绩效信息,项目文件的更新,组织过程资产的更新
随着项目的实施,风险状况时时都在发生变化,及时使用绩效数据,基准偏差分析等方式对风险进行再评估,需要贯穿项目的始终。作为项目经理我首先将风险登录到JIRA的Confluence的方式,向团队和干系人一起共有风险,一起监督管理风险。同时每周进度报告会前载分析项目绩效的同时,确认是否有之前没有识别的风险,对已经登记的风险再次评估。比如随着项目的进行,对需求风险的优先级逐步调低,而随着变更的频繁发生,范围风险的预防和应对也变得重要,根据风险变化我也了调整手上的管理储备并将风险再评估的结果上报给了重要干系人。为了更有效监控风险,在重要里程碑节点除了报告风险变化和对策情况外,还和公司SQA一起报告风险审计的情况,调整了下个里程碑中,风险会议的频率。
控制沟通是对项目中的沟通进行监督与控制,使其满足干系人对信息的需求的过程。
控制沟通的目的:确保信息沟通的最优化。
控制沟通的工具与技术有会议和专家判断,
控制沟通的输入有:沟通管理计划,工作绩效数据,组织过程资产和事业环境因素
控制沟通的输出有:工作绩效信息,变更请求,组织过程资产更新,项目文件更新,项目管理计划更新
随着项目顺利开展,项目风险和不确定因素也逐渐变小了。总公司重要干系人对信息的需求也从风险审计慢慢的转向了流程效率改善上。通过看邮件组发出的每周会议纪要察觉这一点后,我及时和总公司干系人主动确认了当前沟通信息的需求,并修改了沟通管理计划,将每周一次的周会改为了隔一周一次,同时在成本和进度绩效照常报告外,在报告模版中简化了风险跟踪情况的报告,并增加了实施效率改善活动的内容,随着项目进入综合评价阶段,我和团队成员开会后,选出了一些常见的BUG进行了whywhy分析,并将分析结果也写入到了周报中,同时取消了里程碑报告会外的月次报告会,改为了邮件组推式沟通方式发送月次绩效报告。
跟踪,审查和报告项目进展,以实现项目管理计划中确认的绩效目标的过程。
主要工作内容:以项目管理计划为基准,比较实际的项目绩效
它的输入:工作绩效信息,项目管理计划,组织过程资产和事业环境因素
它的输出:工作绩效报告,变更请求,组织过程资产,事业环境因素
它的工具与技术:分析技术,会议,专家判断,项目管理信息系统
监控项目工作包括以下几点:
1.对照项目管理计划,确定项目的实际表现
2.评价项目目前的绩效情况
3.对项目风险实施监控
4.为状态报告,绩效测量和预测提供信息的支持
5.基于目前的绩效情况,对于成本和进度进行预测
实施整体变更控制的定义:审查所有变更请求,批准变更,管理可交付成果,组织过程资产,项目文件,项目管理计划的变更,并对变更内容实施沟通的过程。
实施整体变更流程的输入:项目管理计划,组织过程资产,事业环境因素,变更请求,工作绩效报告
实施整体变更控制流程的输出:批准的变更,项目管理计划更新,项目文件更新,变更日志
它的工具与技术:变更控制工具,会议,专家判断
变更管理的原则:项目的基准化,变更管理过程的规范化。超出基准的部分才需要实施项目变更并走项目变更的流程,变更实施以后,往往会改变项目的基准。
变更管理的重要性:作业过程中作业的内容与预先的发生变化是必然的。项目很少有保质保量交付的情况,所以对于变更的管理必不可少。
变更对项目产生的影响:工期可能延迟(进度),质量基准可能降低(质量),可能要签订补充协议(合同),成本可能超支(成本),可能要增加新的员工(人力资源)
产生变更的原因:外部事件发生,增值变更,与基准出现偏差纠偏时,产品范围定义出现了遗漏的时候,应对项目风险的时候。
工作程序:1.变更申请;2.对变更进行初审;3.变更方案论证;4.CCB审查;5.发出变更通知并实施变更;6.变更实施监控;7.变更效果评估;8.判断发生变更后的项目是否已纳入正常轨道。
按变更的性质:重大变更,重要变更,一般变更。按迫切程度:紧急变更,非紧急变更;
按发生的领域:设计变更,成本变更,进度变更
按来源:内部变更和外部变更。
实施变更有两个重要的角色:一个是项目经理一个是CCB。CCB一般由一个或多个人组成的决策机构,只对哪些变更需要采纳哪些变更不需要对于进行决策,当CCB中意见出现不一致的情况下,往往可以由CCB的主席来进行拍板决策。另一个重要的角色就是咱们项目经理,项目经理在变更中的作用可以简单总结为:响应需求,评估需求,将业务需求转化为对资源的需求,根据评审的结果对基准进行调整。
变更的四个种类:纠正措施,预防措施,缺陷补救,更新。变更如果太多太大,有需要修改项目章程的必要性。
在项目管理计划被高层领导和客户方承认后,我便依照开发管理计划制定了具体的项目变更流程。包括:变更的申请,变更初步审查,变更可行性论证,CCB决策,JIRA起票变更执行,变更实施的监控,变更评估,变更后确保项目走上正轨并通知干系人。并要求所有的变更需求不管是否去做,必须文档化,也就是都先写到需求文件列表中。然后由我,总公司干系人代表,项目组合经理三个人组成了临时的CCB小组。为在不影响项目进度的前提下更快速响应变更需求,我在需求文件的模版上增加了需求紧迫度变更分类和变更状态,在干系人计入变更内容后,自动生成邮件,并以邮件组的形式通知项目团队和重要干系人,对于特大变更或者直接影响基准的变更,我们在收到邮件后立响应和分析,有些不确定内容的变更,就亲自找申请变更的人开会核实,紧急度不高的变更,一周确定一次。相比新功能对应案件,重构改善的案件更容易出现范围蔓延和质量镀金,为了防止这些风险的发生,我要求各个小组长在范围确认也就是每张JIRA票关闭时,通过SVN都要仔细核实是否有不必要多余的提交。
对项目可交付成果物向客户进行最终移交的过程。
输入:项目管理计划,验收的可交付成果,组织过程资产。
输出:已移交的可交付的成果,组织过程资产的更新,项目文件的更新
工具与技术:会议,专家判断,分析技术
结束项目包括了合同收尾和管理收尾两项。管理收尾偏重过程与文档,而合同收尾则偏重于可交付成果或产品服务的验收
项目总结的意义:了解项目的绩效情况,了解项目中的不足之处,总结项目中的经验,更新组织过程资产
项目总结报告会要讨论的内容(4项):
项目整体情况的回顾与介绍
项目整体绩效总结,包含但不限于进度成本质量。
项目实践中优秀和好的方面
项目实践中需要进一步改进的方面
项目经理在确保上面的工作都完成后才宣布项目结束。如果项目完工前提前终止,还需要制定程序,来调查和记录提前终止的原因。
项目后评价的内容:目标评价,过程评价,效益评价,持续改进。
可交付成果的演化过程:首先在项目管理计划制定的时候,规划可交付成果;
指导与管理项目工作过程后,做出来了可交付成果;
在质量控制过程中对可交付成果进行了检查,于是就有了核实的可交付成果;
在范围确认过程中对核实的可交付成果与客户进行了验收,就有了验收的可交付成果;
在项目或阶段收尾的时候,对验收的可交付成果进行了移交,于是就有了移交的可交付成果。
项目收尾时一般提交的文件有:
培训类文档,测试类文档,设计类文档,合同类文档,管理类文档,需求类文档,运维类文档
管理沟通就是根据沟通管理计划,对项目沟通所需要的信息进行生成,收集,分发,存储等处理的过程。
它的作用是确保有效率的沟通。
管理沟通的工具与技术有:沟通技术,沟通模型,沟通方法,报告绩效。
管理沟通的输入有:沟通管理计划,绩效报告,组织过程资产和事业环境因素
管理沟通的输出有:项目沟通,组织过程资产更新,项目文件更新,项目管理计划更新
沟通有五个原则:尽早沟通,主动沟通,沟通内外有别,沟通升级原则,站在对方的立场上沟通
举行高效率会议的时候应该注意的问题:
1.事先对会议要有一个例会的制度
2.放弃可开可不开的会议
3.明确会议的目标与期待
4.发布会议通知
5.将会议的内容文件资料发给参会人
6.可以借助视频设备
7.明确会议议事规则
8.会议要有会议纪要
9.对会议结果要有总结与提炼结论
绩效报告是管理沟通中重要的工具与技术,它包括的内容有:进度成本状态报告,项目进展报告,项目的预测。
绩效报告具体的内容有:
1.项目当前状态下的进度情况和成本情况
2.项目当前状态下产生的风险和课题
3.项目中的变更请求的情况
4.到下一个报告周期对于项目的预测
5.本期应该完成的工作列表
6.下一个周期应该完成的工作列表
7.需要审查和讨论的其他的相关项目信息
项目开始后,我便根据沟通管理计划,把项目正式的会议沟通在Outlook上定期预约了会议参加者和会议室。根据项目沟通管理计划,和总公司的进度报告每周只有一小时,在每周一周间项目报告中,如何把项目绩效信息简洁高效的传递给总公司团队成为了满足重要干系人满意度和项目取得成功的重要因素。为了更高效的完成沟通,作为项目经理,我在每周五下午开始,就要求项目成员在公司信息系统中输入成本,在JIRA中更新每张票的进度情况,同时在周五下班前举行一个简单的夕会,核实进度成本信息,并跟踪项目风险和质量测量指标的情况,收集完这些信息后,做成项目周报,并以邮件组的形式,提前发送给总公司的干系人,因为使用母语的差异,为了避免在会议上出现理解偏差,在听取重要的确认事项后,首先是用自己的语言复述确认一下,同时提醒会议纪要的担当人,把重要的内容写入纪要中。除了会议外为了能和异地的总公司工程师更好的私下沟通提高效率,我在项目团队座位旁边放了常时连接的TV会议室,这样相互之间一有问题,就可以马上使用视频会议呼叫对方,消除了虚拟团队沟通滞后的问题。