精华内容
下载资源
问答
  • 软件外包项目中甲方外包管理的思考(一)——人员外包和项目外包
    千次阅读
    2020-01-23 21:14:18

    一、概述

    在软件外包项目中,甲方(发包商)通过资金或其它资源获取乙方(承包商)的开发服务,以达成其软件需求目标。为了让外包项目按时按质按量完成,甲方需要做好项目的采购管理外包管理,其中采购管理的核心是选择合适的供应商、签订合同,外包管理的核心是过程监控、项目验收。按照外包项目采用的形式和管理方法的不同,可以将外包项目分为项目外包人员外包[1]。

    • 项目外包

    甲方将项目的需求和范围要求发给乙方,候选乙方对此进行报价,然后进行实地考察和分析确认,当甲方认为乙方符合承担条件后,将项目需求和技术资料发给乙方,进行软件开发[1]。项目研发过程涉及的需求、设计、编码、测试、上线、系统支持等项目活动全部由乙方承担。项目外包适合缺少相关专业人员的甲方。

    • 人员外包

    甲方负责项目的组织和管理,雇佣乙方的相关人员参与项目研发的中间环节。常见的人员外包的形式是雇佣乙方的开发人员进行编码工作,人员外包适合拥有具备需求分析、项目管理、技术管理等相关能力的专业人员的甲方。

    近期笔者以甲方项目负责人的身份参与我司一个内部系统的外包项目,项目前期以"项目外包"的形式进行,后期以"人员外包"的形式进行。在本文中笔者将结合项目经历对项目外包、人员外包中外包管理的异同、注意要点进行简要的说明。

    二、项目外包

    笔者在接手项目时, 项目已经进入开发阶段。获取到的项目资料仅仅只是短短几句的项目文档、项目外包合同。通过对业务进行调研,和业务人员沟通,阅读相关文档发现该项目在的规划、需求阶段存在着很大的不足,进而导致了很严重的项目后果。通过对该阶段项目进行复盘,笔者认为在项目立项项目规划需求分析项目验收阶段甲方的外包项目管理需要注意以下几点:

    1. 明确项目干系人

    什么是项目干系人?

    项目干系人又称项目利益相关者,是指积极参与项目实施或完成的,或其利益可能受项目实施或完成情况产生积极或消极影响的个人或组织(如客户、发起人、执行组织或公众),识别干系人是一个持续性的过程[2]。通常参与项目的角色有项目发起人、项目业务方、项目经理、设计人员、开发人员、测试人员等,受项目影响的角色有成果拥有者、系统使用者等。

    在本次的项目过程中,由于在项目规划阶段漏掉了一个重要的业务方,而且笔者因为缺乏干系人的资料导致没有及时干涉,进而导致了项目成果不能满足所有业务方的需要。因此在项目规划阶段明确干系人的人员组成、优先级、期望点,是保障项目定位、需求来源的准确性的必要途径,是进入项目需求阶段的基础

    2. 合理的项目团队组织

    项目团队组织包括人员安排、任务划分、沟通协作项目确认。合理项目团队组织能够明确人员职责,监控项目进程,及时发现问题,降低项目进度和质量失控的风险。在笔者没有介入该项目的前期,乙方项目经理直接和业务需求人员进行沟通,由于业务需求人员缺乏专业知识,导致需求设计不完善、项目节点不合理、项目资源提供不及时等诸多问题。同时在整个项目过程中缺乏正式有效沟通协调机制,导致对进度没有清晰的掌控,无法确认乙方是否充分投入资源。因此笔者认为合理的项目组织需要做到以下几点:

    • 安排专业人员作为项目对接人

    合格的项目对接人需要了解软件开发知识,熟悉项目开发流程,善于交流,又了解业务知识。项目对接人负责对软件外包项目全过程进行全面的监控和协调,以期更好地消除由于信息不对称所产生的一系列项目进度和质量风险,确保软件外包各方能够更有效地履行合同[3]。

    • 建立项目进度跟踪机制

    建立项目进度跟踪机制的目的是监督外包项目的进展情况,确认项目实际进度与合同规定的时间进度表是否相符,评估乙方投入的开发资源是否充分。项目进度跟踪通常以会议、邮件、即时聊天等约定的交流形式定期检查,频率至少1周一次。通过乙方定期提供的项目相关信息,来确认阶段任务完成情况、总结项目问题,检查实际进度是否延迟,评估项目进行的风险,并讨论相关解决方案。

    3. 不可忽视项目的非功能需求

    非功能需求是系统需求的重要组成部分,是影响用户使用体验、产品能否提供高效稳定服务的关键。常见的非功能需求包括性能需求、安全需求、集成需求、可靠性需求、兼容性需求、易用性需求等。在本次外包项目过程中,由于忽略了非功能需求导致了多个项目失误,比如管理后台没有对接单点登录,同时在线用户过多服务器瘫痪,因此在项目规划时不能忽视对非功能需求的需求分析。然而非功能的定义很抽象,如何清晰准确的描述非功能需求是非功能需求分析的关键。通常对于非功能需求的描述是通过量化业务指标、详细具体的规则进行说明,常用到的如下:

    • 性能需求

    对于前台的系统而言,通常以“响应时间”上进行定义,并具体到的某个业务场景[4]。需求描述举例如下[5]:

    • 定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。
    • 在非高峰时间根据编号和名称特定条件进行搜索,可以在3秒内得到搜索结果。

    对于后台的业务管理系统来说,通常以“整体能力上来定义”,并具体到某个业务场景[4]。常见的业务指标包括“并发量、资源使用率、业务量、系统容量”等等[4]。需求描述举例如下[5]:

    • 系统可以同时满足10,000个用户请求,并为25,000个并发用户提供浏览功能。
    • CPU占用率<=50%,内存占用率<=50%。
    • 数据库表行数不超过100万行,数据库最大容量不超过1000GB,磁盘空间至少需要40G以上。
    • 可扩展性需求

    系统的可扩展性就是考虑系统未来为了追加新功能是否方便,便宜,能够满足未来业务量增长的需要。定义扩展性需求时要确定系统的生命周期,然后分析在系统生命期内,业务量变化情况,压力增长情况,以此分析出来的结果,作为扩展性需求,进行定义[4]。系统可扩展可以从系统性能、系统功能两个方面进行考虑,其基本要求是功能扩展时不需要对系统的基础架构进行改动,性能扩展不通过任何代码的更改。在描述系统性能的可扩展需求时应结合性能需求,举例如下:

    • 系统可以在未来需要的情况下,不通过任何代码的更改,对系统性能进行提升,使之中心系统每秒钟能记录25个以上的考勤记录[4]。

    系统功能的可扩展性体现在需求分析与设计阶段是否能有效识别系统可变的需求,不能停留在可扩展的基本原则上,要落实对一个一个功能的分析中,以提供出合理的方案[6]。从业务设计的角度来说,模块化、可复用、较少依赖或耦合是可扩展的原则。

    • 集成需求

    企业内部系统存在多个业务系统,系统之间集成和整合的需求就是集成需求。集成需求主要包括数据对接(系统之间的数据交换和信息传递)、单点登录(多个独立系统统一账号和登录认证)、系统融合( 将多个系统融合在一个系统中,统一账号、权限、应用的管理,最终以一个独立的软件系统存在)[7]。需求描述举例如下:

    • 某某图书管理系统采集##库存管理系统的数据包括库存数据、订单数据。
    • 某某课程管理系统通过与EHR系统实施集成,实现相关基础数据(组织机构、用户数据等)的共享,实施统一身份认证和统一登录界面。
    • 内训管理后台融合到社区管理后台中,统一账号、权限、功能的管理。
    • 兼容性需求

    一般对于前台系统而言,都需要考虑其兼容性。目前最为广泛的前台系统是手机客户端、web端,在考虑系统的兼容性时主要前台的适用平台有哪些,需求描述举例如下。

    • 系统仅支持chrome浏览器,不考虑移动端适配。
    • 移动端需要兼容的操作系统IOS6以上、Andriod6.0以上。
    • 易用性需求

    易用性和产品的用户体验相关,是一组规定或者潜在的用户为使用其软件所需做的努力和对这样的使用所作的评价有关的一组属性[8]。衡量易用性的标准是用户对于系统功能是否容易理解、是否容易学习、是否容易操作,需求描述举例如下:

    • 80%的用户经过培训后,可在5分钟内完成课程创建。
    • 90%的用户完成建课后,需要在5s内知道下一步需要进行什么操作,如课程上线、编辑、查看详情等。

    4. 合理的项目里程碑安排

    项目里程碑安排就制定项目计划,是对项目的进度管理、目标管理,是进度跟踪的关键。项目里程碑就是通过识别项目的软件活动,以软件活动完成时间节点作为项目里程碑。具体的项目计划安排由乙方产品经理负责,甲方需要进行评审,判断其合理性。
    在此次项目中,由于项目的阶段划分、开发计划制定都没有进行严格的审核,项目过程虽然按照业务需求划分成两个阶段,但是没有做相关的阶段验收计划,因此笔者增加了项目阶段验收的环节。项目第一阶段的计划周期过短,中间有法定假日的影响,虽然乙方组织开发人员进行加班,但是只有web端完成,追赶进度的同时导致了严重的质量问题。由于移动端采用的技术方案是以SDK的形式嵌入公司的移动OA应用中,在项目集成过程中产生了严重的类库冲突问题,阻碍了项目进展。因此合理项目计划安排、计划实施过程中需要考虑以下几点:

    • 提前预估项目风险

    在进行项目规划的时候,要充分地平台项目进展过程中可能遇到的风险,针对这些风险制定相应的规避措施,对于容易产生风险的项目任务,需要预留充足的时间。

    • 项目任务的工期要符合项目开发实际

    在很多时候乙方为了中标会向甲方承诺工期,然而实际开发的结果往往会是不能按时交付、完成质量不能满足客户期望。因此对应甲方对接人在乙方完成需求分析后,根据需求规格说明书评审乙方的项目开发计划,如果发现不合理需让乙方调整,确认计划无误后须进行冻结。

    • 划分子项目

    对应涉及多终端、多业务需求的大型项目,可根据业务需求的优先级、系统终端类型,划分多个子项目进行多次验收多次交付,一个阶段没有完成不能进入下一阶段,项目通过多次迭代完成上线验收。采用这种方式能够降低项目风险,提高项目完成质量。

    三、人员外包

    在此次项目的人员外包阶段,外包的开发人员异地开发,因此项目过程中如何协调异地开发人员的开发工作,如果保证需求沟通中无阻碍,就是人员外包面临主要问题。复盘此次的项目经历,笔者认为人员外包需要注意以下几点:

    ###1. 和乙方项目经理沟通

    在项目过程中可能会出现外包人员工作配合度不高,需要安排外包人员加班处理某些任务等问题。遇到这些问题时首先要和乙方的项目经理进行沟通反应问题,或者在告知外包人员的同时告知乙方项目经理。

    ###2. 统一的项目协作平台

    通过在线的项目协作平台,能够方便团队成员直接进行沟通,便于项目经理对项目任务协调和控制,同时记录项目需求、项目决策、需求变更等重要内容。笔者参与的外包项目采用的在线协作平台是wiki+redmine的形式,wiki记录项目需求、项目人员、项目里程碑、会议纪要等内容,redmine进行任务分配、任务跟踪、bug管理。

    四、总结

    软件项目外包管理涉及到很多流程,甲方从项目立项到选择承包商,再到签订合同、跟踪监控,最后成果验收,乙方从项目竞标到竞标成功 ,再到系统策划、需求分析、系统设计、编码测试,最后提交验收,整个项目从开始到收尾,甲方乙方其实是合作者,为了共同的项目目标而走到一起的,虽然整个过程中,难免会遇到很多问题,踩很多坑。
    笔者结合自身的项目经验总结了一些要点,希望能对大家在进行外包项目能够有所帮助,减少弯路,其中难免会有不足之处,请大家批评指正。

    参考资料

    [1] 杨曙贤, 王军辉和张爱国. 软件外包概论. 普通高等教育软件工程“十二五”规划教材. 人民邮电出版社, 2015.
    [2](美)项目管理协会.项目管理知识体系指南(PMBOK指南)第四版.北京:电子工业出版社,2009:23-24.
    [3] 王梅源. 软件外包项目全过程风险管理. 华中科技大学出版社, 2009.
    [4] 非功能需求定义与测试.百度文库, 2011.
    [5] 常见非功能性需求的描述案例.CSDN博客, 2018.
    [6] [我们应当怎样做需求分析:非功能需求.ITeye博客, 2012.]
    (https://www.iteye.com/blog/fangang-1497941)
    [7] 软件系统集成与整合的常见方式.百度文库, 2018.
    [8] 电子工业部标准化研究所.GB/T 16260-1996 信息技术 软件产品评价 质量特性及其使用指南.

    更多相关内容
  •  要有效地进行进度控制,必须影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素...

    软件开发项目进度控制

      一、影响软件开发项目进度的因素

      要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况:

    180-20原则与过于乐观的进度控制

    80-20原则在软件开发项目进度控制方面体现在:80%的项目工作可以在20%的时间内完成,而剩余的20%的项目工作需要80%的时间。这个80%的项目工作不一定是在项目的前期,而可能是分布在项目的各个阶段,但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉,使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了,就一块石头落地“总算交差了”,同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作,同时如果软件还不成熟的话,会给用户造成不好的影响。

    2、范围、质量因素对进度的影响

      软件开发项目比其他任何建设项目都会有更经常的变更,大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧,用户是想改就改,造成需求的蔓延,项目经理有时还不知如何拒绝,加上要说“我能”的心理因素,一般都会答应修改。这样集少成多,逐渐影响了项目进度。

      如果某项工作在进度上表面上达到目标了,但经检验其质量没有达到要求,则必然要通过返工等手段,增加人力资源的投入,增加时间的投入,实际上是拖延了进度。不管是从横向或纵向来看,部分任务的质量会影响总体项目的进度,前面的一些任务质量中会影响到后面的一些任务质量。

    3、资源、预算变更对进度的影响

      资源,最主要的还是人力资源,有时某方面的人员不够到位,或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源,就是信息资源,如某些国家标准、行业标准,用户可能提供不了,而是需要去收集或购买,如果不能按时得到,就会影响需求分析、设计或编码的工作。其他资源,如开发设备或软件没有到货,也会对进度造成影响。

      预算其实就是一种资源,它的变更会影响某些资源的变更,从而对进度造成影响。

    4、低估了软件开发项目实现的条件

      低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。

      首先是低估技术难度。软件开发项目团队成员,有时甚至是企业的高级项目主管也经常低估项目技术上的困难。低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。软件开发项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验;

      其次,低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。软件开发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。

      另外,企业高级项目主管和项目经理也经常低估环境因素,这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。低估这些条件,既有主观的原因,也会有客观的原因。对项目环境的了解程度不够,造成没有做好充分的准备。

    5、项目状态信息收集的情况

      由于项目经理的经验或素质原因,对项目状态信息收集的的掌握不足,及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。某些项目团队成员报喜不报忧,不希望别人知道自己工作的不好的情况,例如软件程序的编制,可能会先编制一些表面的东西,现有界面,看起来好像完成任务了,实际上只是一个“原型系统”或演示系统。给领导造成比较乐观的感觉。

      如果项目经理或者管理团队没有及时地检查发现这种情况,将对项目的进度造成严重的影响。当然,如果出现这种需要时时刻刻都互相提防的氛围,管理人员就应该从管理的角度,从制度的角度检讨一下,进行改进,让大家实事求是地进行沟通。温伯格说:“无论你多么聪明,离开了信息,对项目进行成功的控制就是无源之水、无本之木。”

    6、执行计划的严格程度

      没有把计划作为项目过程行动的基础,而是把计划放在一边,比较随意去做。例如对于项目团队内部沟通或外部沟通,在计划中要说明清楚人员、周期、方式、方法,不能遗漏,但在实际项目过程中,可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。若项目计划本身有错误,执行错误的计划肯定会产生错误。如,计划制订者在计划系统框架设计考虑上的错误、进度安排上的失误等。实际的项目实施中,除了这种错误之外,还可能因为项目执行上的错误,造成项目的麻烦。例如,项目的客户及其他项目干系人没有及时为项目中出现的情况采取必要的措施或者所采取的措施的不适合具体的情况、没有效果或者有副作用等。另外,如果在项目中的某项工作(如某个子系统或模块、组件)被转包给第三方开发后,不能进行有效的管理,也会造成进度上的延误。

    7、计划变更调整的及时性

      渐近明细是项目的特点,特别是对于软件开发项目,并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些,随着项目的进展,特别是需求明确以后,项目的计划就可以进一步的明确,这时候应该对项目计划进行调整修订,通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业,日新月异是主要特点,因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式,随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ,需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系,所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ,根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细,无法对工作任务的分解、均衡分配和进度管理起参考作用,因此要随着需求的细化和设计的明确,对项目的分工和进度进行及时的调整,使项目的计划符合项目的变化,使项目的进度符合项目的计划。

    8、未考虑不可预见事件发生造成的影响

      假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响(即项目按时完成是基于如下假设:人力资源不会缺乏、人员不会生病、人员不会流动)。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑,在项目进展过程中也要不断地重新考虑有没有新的情况,新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题,而这些问题是一定要解决才能保证项目按计划完成;约束一般是难以解决的问题,但可以通过其他途径回避或弥补、取舍,如牺牲进度、质量等等;假设与约束是针对比较明确会出现的情况,如果问题的出现具有不确定性,则应该在风险分析中列出,分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题,因为任何人都不可能把所有以外的情况都考虑完整,实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患,但是有的时候也要冒一定的风险,同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响,则这种防范是没有必要的。

    9、程序员方面的因素对进度的影响

      程序员方面有两种常见的心态影响了进度的控制:一是技术完美主义、二是自尊心。

      技术完美主义的常见现象是,有些程序员由于进度压力、经验等方面的原因,会匆忙先做编码等具体的事情,等做到一定程度后会想到一些更好的构思,或者看到一些更好的技术的介绍,或者是觉得外部构架可以更加美化,或者是觉得内部构架可以更加优化,这样他们会私下或公开对软件进行调整,去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响,相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本,可能对软件开发进度造成较大的影响。

      自尊心的常见想象是,有些程序员在遇到一些自己无法解决的问题时,倾向于靠自己摸索,而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决,否则要花很多实践摸索。而如果向周围的人求教,可能摸索几天的问题别人早就解决了。

    10、未考虑软件开发过程的循环、迭代特性

      对软件开发的各个过程分类过于精细,制定进度计划时各项工作过于紧凑、没有弹性,造成的后果是,定期提交项目进度阶段报告的制度只有在表面上起到效果,按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”,强行的规定会使人产生一些错误的认识:如在项目计划中“规定”某个时间只能做某某类别的事情,那么严格执行的后果就是编码阶段就不能修改文档;另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了,而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误;如果上下阶段是同一个人,就可能非正式地修改上一阶段的错误,但占用的时间和精力却是下一阶段的,并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是,用户在合同中限定了提交软件系统的时间,实际上这个时间对完成项目任务来说是远远不够的,但计划只能按照合同来进行,所以要不用户让步,要不只能按照时间的约定提交实际上还未完成的软件系统,完成系统的安装,但这时候的“完成阶段任务”只是一个表面现象,系统虽然安装了,但可能是没有经过严格彻底测试的,也可能是只完成了部分的功能,省略了某些功能,有些是整块功能省略,有的是省略了某些功能的某个过程,如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能,而是实现了比较粗糙的功能。这样,系统交付并不意味着项目的完成,而在项目交付之后还要花更多的时间。

    11、其他因素

      以上这些因素是影响项目进度的几个主要方面,除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素,这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等,都会对项目进度造成影响,这是因为由于软件开发的特性。因为篇幅有限无法一一列举,只能在此分析一些常见的因素。

      不可否认,软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目,其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验,虽然我们说,顾客是上帝、以顾客为中心,但并不是说我们要把主导权交给他们,而关键是我们如何去主导、引导、把握。因此,项目控制的好坏与相关人员人际关系方面的经验也有关系。

      尽管存在很多不可控的因素,我们的任务是首先分清哪些是可以控制的,哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域,减少不可控的领域,二是不要在“不可控”上花太多时间,而是多花一些时间把可控的工作控制好,做好防范措施,减轻不可控因素对项目进度的影响。

      项目进入实施阶段后,项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系,需要项目经理去平衡。

      二、项目进度控制的目的

      项目进度控制和监督的目的是:增强项目进度的透明度,以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。

    1、根据计划进行监控

      项目控制的第一个目的是根据计划对项目的各项活动进行监控,即根据已经制定并取得共识的软件开发项目计划来监控项目的实际表现和进度。为此应该根据项目计划来监控项目计划参数的实际值,这些参数包括进度表、项目成本、工作量、工作产品和任务的属性、使用的资源、项目成员的知识和技能;根据项目计划来监控项目团队所作的承诺是否已经或可能兑现、原来的确定的风险是否可以避免或减少损失,是否有新的风险出现;根据项目计划来收集、管理、使用项目数据;根据计划监督项目干系人的参与情况,监控各项任务承担人的参与活动;定期进行必要的进度评审,确定项目是否存在重大偏差、跟踪变更请求和问题报告直到变更或问题得到解决;在项目的里程碑对项目的成果进行评审。

    2、管理纠正和预防措施

      项目控制的另外一个目的是管理纠正和预防措施,即当项目进度或者结果已经或即将与计划有严重偏差时,对需要采取的纠正或预防措施进行管理。为此应当收集并且分析项目进行中可能存在的问题,并以此确定解决这些问题的纠正或预防措施;对已经确定的问题采取纠正和预防措施;监控要实施的纠正和预防措施,分析措施采取以后的结果,判断这些措施的有效性,确定和记录纠正与计划结果存在偏差的问题而采取的必要且合适的措施。

      项目执行过程中仅仅靠最初建立的一份“完善”的基准计划是不够的,最好的计划也未必会一直有效。根据项目任务渐进明晰的特点,特别是软件开发项目的特点,在项目进行过程中,肯定需要在适当和必要的时候对项目进行变更控制,这种控制过程包括定期搜集有关项目进展情况的信息,把实际进展情况与计划进展情况进行对比;如果实际进展情况比计划进展情况有差距,或可能会有差距,就应当采取纠正或预防措施。变更控制应当在项目期间定期进行,这里所说的变更控制不一定要进行真正的变更,而是说要定期对变更进行控制。

      如果在项目生命周期内的某一时间点,把实际进度与计划中约定的进度相比对,显示出项目已经延误或即将延误、超出预算目标或不符合质量要求,就必须采取纠正或预防措施使项目回到正轨上来,重新符合计划的安排要求。在已做出执行纠正或预防措施的决定之前,应评估一下纠正与预防措施的有效性和无副作用性,以确保纠正措施使项目回到项目的工作范围、时间和预算约束内,并对项目的其他目标不会造成太大的影响。

    3、在各种项目目标中进行平衡

      如果经过评估确定项目确实已无法控制,就应当下定决心以牺牲软件功能范围、工作成果范围(如某些中间文档)、成本预算、进度计划或软件质量中的某一项目标为代价,来保住项目最重要的那些目标,在各种项目目标中进行平衡,最终确定一个最合适的解决方案。有效的项目控制的关键是定期及时测量实际进程,并与计划进程相比较,如有必要就立即采取纠正或预防措施。指望不采取纠正和干预措施,问题就自行消失的想法是不现实的。问题越早发现就越好改正,造成的影响和损失越小。问题越提前发现就越好采取预防措施,可以用最小的代价避免造成损失。基于项目实际进展情况,就有可能准确预测项目进度计划和成本预算的实施情况,以便顺利完成项目。如果这些项目参数超出项目目标的限制范围,就必须马上采取纠正措施;如果发现这些项目参数有超出项目目标的限制范围的趋势,就必须马上采取预防措施。

      软件开发项目实施中进度控制是项目管理的关键,若某个分项或阶段实施的进度没有把握好,则会影响整个项目的进度,因此应当尽可能地排除或减少干扰因素对进度的影响,确保项目实施的进度。

      三、软件开发项目常用进度控制措施

    1、项目进度控制的前提

      项目进度控制的前提是有效地项目计划和充分掌握第一手实际信息,在此前提下,通过实际值与计划值进行比较,检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段,对项目进度进行监督、督促、影响、制约。及时发现偏差,及时予以纠正;提前预测偏差,提前予以预防。

      在进行项目进度控制时,必须落实项目团队之内或之外进度控制人员的组成,明确具体的控制任务和管理职责。要制定进度控制的方法,要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。

      项目进度控制应该由部门经理和项目监控人员共同进行,之所以需要部门经理参与,是因为部门经理负责项目一般要负责一定人事行政的责任,如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员,项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。

    2、项目进度控制主要手段

      项目计划书:作为项目进度控制的基准和依据,项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控,如果由于某些原因阶段成果提前或延后完成,项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的,应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施,在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整,以保证基准和依据的新鲜性、有效性。

      项目阶段情况汇报与计划:项目负责人按照预定的每个阶段点(根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等)定期在与项目成员和其他相关人员充分沟通后,向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划,内容包括:

    a、对上一阶段计划执行情况的描述

    b、下一阶段的工作计划安排

    c、已经解决的问题和遗留的问题

    d、资源申请、需要协调的事情及其人员

    e、其他需要处理的问题

      这些汇报将存档,作为对项目进行考核的重要材料。

      在计划制定时就要确定项目总进度目标与分进度目标;在项目进展的全过程中,进行计划进度与实际进度的比较,及时发现偏离,及时采取措施纠正或者预防;协调项目参与人员之间的进度关系。

      在项目计划执行中,做好这样几个方面的工作:

      检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据,积累资料,总结分析,不断提高计划编制、项目管理、进度控制水平。

      做好项目计划执行中的检查与分析。通过检查,分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。

      及时制定实施调整与补救措施。调整的目的是根据实际进度情况,对项目计划作必要的修正,使之符合变化的实际情况,以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周,或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑,计算调整后的各时间参数、关键线路和工期。

    3、进度控制内容

      从内容上看,软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容:

      (1)项目经理监督并控制项目进展情况;

      (2)进行项目分解,如按项目结构分,按项目进展阶段分,按合同结构分,并建立编码体系;

      (3)制订进度协调制度,确定协调会议时间,参加人员等;

      (4)对影响进度的干扰因素和潜在风险进行分析。

      技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视,有些技术问题可能需要特殊的人员,可能需要花时间攻克一些技术问题,技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。

      在软件开发项目中,合同措施通常不由项目团队负责,企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况,按计划通过计划进度与实际进度的动态比较,定期向客户提供比较可靠的报告等。

      软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是:预测信息,即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测;决策信息,即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人;统计信息,软件开发项目中统计工作主要由参与项目实施的人员自己做,再由项目经理或指定人员检查核实。通过收集、整理和分析,写出项目进展分析报告。根据实际情况,可以按日、周、月等时间要求对进度进行统计和审核,这是进度控制所必须的。

    4、不同阶段的项目进度控制

      从项目进度控制的阶段上看,软件开发项目进度控制主要有:项目准备阶段进度控制,需求分析和设计阶段进度控制,实施阶段进度控制等这几个部分。

      准备阶段进度控制任务是:向业主提供有关项目信息,协助业主确定工期总目标;编制阶段计划和项目总进度计划;控制该计划的执行;

      需求分析和设计阶段控制的任务是:编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划,控制相关计划的执行等。

      实施阶段进度控制的任务是:编制实施总进度计划并控制其执行;编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。

      为了及时地发现和处理计划执行中发生的各种问题,就必须加强项目的项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件,以适应项目实施情况的变化。

    5、关于进度落后时的“赶工”措施

      进度落后的情况下,有几种措施来弥补,如加人、加班、加激励等等,这些都是增加资源而又未必会见效的方法。根据Brooks原则,在某些项目进度延迟的情况下增加人手,有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说,对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加,可能会使项目的工作效率急剧下跌。而加班造成的疲劳会再次使工作效率降低。增加激励会造成工作成本却不断的向上攀升。这些措施并不是完全不可取,而是项目经理要考虑适度原则。最好是要全面分析项目进度延迟的原因,如果确实是不合理的项目交付时限要求,就应当通过沟通变更为合理的项目时限要求,以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响,最终导致项目最终的失败。否则应从技术、团队成员心态、环境等方面查找原因,找到提高效率、加快进度的方法。

    展开全文
  • 由阶段组成(通常包括项目规划阶段、实施阶段和完成阶段等,每个阶段确定了开始和结束点,每个阶段都有质量保证QA/质量测试QC人员阶段的里程碑点进行检查进行相应的阶段评审),一系列有逻辑关系的阶段,阶段通常...

      接受项目管理培训至今已经有三年时间了,一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头,从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验,希望可以帮助到从事项目管理的人!

      在前面的博文项目管理 之一 软件开发生命周期(软件开发过程、瀑布模型、敏捷开发等) 中我们说过 软件开发生命周期 ≠ 项目的开发周期。接下来就再进一步,站在整个项目的角度来了解一下软件项目管理。

    注意:

    1. 这部分仅仅是自己学习记录的一些总结,所以内容大多数都是来自互联网或者各种书籍。如果您发现对您构成了侵权,请随时联系我进行处理。
    2. 这部分内容都是一些理论,实际项目中往往与理论有所不同。例如,阶段划分更加详细,项目活动可裁剪等

    项目管理

      项目这个概念非常的广泛,项目管理同样是个范围很大的概念。项目管理是管理学的一个分支学科 ,对项目管理的定义是:指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程。所谓管理包含领导、组织、用人、计划及控制等五项主要工作。

    项目(Project)是为完成某一独特的产品、服务或成果所做的临时性工作。临时性是指计划有确定的开始日期和结束日期。独特意味着项目的最终结果不重复。

      作为一门学科,项目管理从土木施工、工程、重型国防等多个应用领域发展而来。20 世纪 50 年代项目管理被公认为具有工程模式的管理学科所产生的一门独特的学科。1969 年,项目管理研究所(PMI)在美国成立。PMI 于 1996 年出版了第一版《项目知识管理机构指南》(PMBOK 指南)。这本书是必看的!本文的有些内容就是来自这本指南。

    • PMBOK 每 4 年会更新一次,目前中国使用的官方教材为第六版
    • 全球项目管理业界定义的最重要的价值观是责任、尊重、公正和诚实
    • PMBOK 指南为项目经理提供了指导方针和最佳实践,定义了从项目生命周期到项目管理策略和概念的一切内容。项目管理知识体系指南详细描述了在整个项目生命周期中相互作用和重叠的各种项目管理过程。

      项目管理方法可应用于任何类型的项目。它通常根据项目规模、性质、行业或部门为特定类型的项目量身定做。例如,以建筑、道路和桥梁等工程的交付为重点的建筑行业已经发展了自己的专业项目管理形式,称为建筑项目管理;我们软件行业则有我们的软件项目管理。

    接下来,我们来区分一下三个比较容易混淆的概念:项目生命周期、项目管理生命周期、产品生命周期
    在这里插入图片描述

    项目生命周期

      项目的生命周期是描述项目从开始到结束所经历的各个阶段。通常由 启动阶段、组织与准备阶段(规划阶段)、实施阶段、结束阶段 这四阶段个组成。每个阶段确定了开始和结束点,每个阶段都有质量保证 QA / 质量测试 QC 人员对阶段的里程碑点进行检查并进行相应的阶段评审。
    在这里插入图片描述
      项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。 阶段通常有先后的顺序(如瀑布型),也可以有阶段的交叠。不同行业,不同规模的项目,项目生命周期可以不同。

    项目活动 是确认和描述项目的特定活动,它把项目的组成要素加以细分为可管理的更小部分,以便更好地管理和控制。

      项目规划阶段的目的是为了管控的需要,每一个阶段都可以当成是一个子项目,每一个阶段中都可以执行项目管理生命周期定义的五大过程组。阶段结束时要进行阶段评审。由于项目有特定的目标,在产品生命周期中,一般产品完成后通过验收则项目生命周期即结束。

      项目阶段并没有严格的划分标准。这里所说的 4 个阶段仅仅是指的一般情况。一个具体的项目可以根据项目所属专业领域的特殊性和项目的工作内容等因素划分成不同的项目阶段。

    启动阶段

      启动阶段是整个项目生命周期的第一阶段。这一阶段的目标是确定项目,并获得批准。在此期间,通常有以下项目活动需要项目经理来处理:

    • 需求调研
    • 进行可行性研究
    • 创建项目章程
    • 确定关键利益相关者
    • 选择合适的项目管理方法
    • 选择项目管理工具

    通常,从项目启动会议开始,项目经理向所有相关利益相关者概述项目目标。在会议召开之前,项目经理必须执行以下工作:

    1. 建立目标和可交付成果
    2. 识别团队成员并分配任务
    3. 制定项目计划草案
    4. 定义用于衡量项目成功的指标
    5. 识别和准备潜在的路障
    6. 建立团队沟通的物流和时间表
    7. 选择首选的项目管理方法
    8. 确保您的团队能够访问相关工具并了解相关工具
    9. 安排会议
    10. 设置议程并准备幻灯片

    启动会议议程可能如下所示:

    • 简介:谁是谁?
    • 项目背景:您为什么要进行这个项目? 目标是什么?
    • 项目范围:涉及哪种工作?
    • 项目计划:路线图是什么样的?
    • 角色:谁负责项目的哪些元素?
    • 交流:将使用哪种交流渠道? 您的团队应该期望什么样的会议或状态报告?
    • 工具:将使用哪些工具来完成项目,以及如何使用它们?
    • 后续步骤:需要完成哪些立即行动项目?
    • 问答(Q&A):现场答疑

    到此阶段结束时,项目经理应对项目的目的、目标、要求和风险有更深入的了解。

    规划阶段

      规划阶段对于创建整个团队可以遵循的项目路线图至关重要。为了满足组织提出的要求,所有的细节和目标都在这里列出。在此阶段,通常有以下项目活动需要项目经理来处理:

    • 创建项目计划
    • 制定资源计划
    • 评估项目预算
    • 定义目标和绩效衡量指标
    • 向团队成员传达角色和责任
    • 构建工作流
    • 预测风险并制定应急计划
    • 制定沟通交流计划(可能是会议、交流工具)

    执行阶段

      这个阶段是项目投入时间最多的阶段。可交付品的构建是为了确保项目符合要求。这也是大多数时间、金钱和人被投入的阶段。

      在执行阶段必须时刻对项目进行控制和监测(严格来说,项目的每个阶段都可以控制和监测)。随着项目的推进,项目经理必须确保所有活动的部分都朝着正确的方向无缝地进行。如果由于不可预见的情况或方向的改变而需要对项目计划进行调整,则可能会在这里进行调整。在控制和监测中,项目经理(有可能是公司中专门的 QA 人员)可能需要做以下工作:

    • 管理资源
    • 监控项目性能
    • 风险管理
    • 质量管理
    • 成本管理
    • 变更管理(更新项目计划、修改项目计划)
    • 执行状态会议和报告
    • 协作、沟通

    项目关闭

      结束阶段是项目生命周期的关键一步。它标志着项目的正式结束,并为反思、总结和组织材料提供了一段时间。通常有以下项目活动需要项目经理来处理:

    • 盘点所有可交付成果
    • 处理好任何零碎的事情
    • 将项目移交给客户或负责项目日常运营的团队
    • 进行事后分析,讨论并记录从项目中学到的任何东西
    • 集中组织所有项目文件
    • 与利益相关者和主管沟通项目的成功
    • 庆祝项目完成并感谢团队成员

    阶段关口

    阶段关口在项目阶段结束时进行,将项目的绩效和进度与项目和业务文件比较,这些文件包括 (但不限于):

    • 项目商业论证
    • 项目章程
    • 项目管理计划
    • 效益管理计划

    根据比较结果做出决定(例如继续/终止的决定),以便:

    • 进入下个阶段;
    • 整改后进入下个阶段;
    • 结束项目;
    • 停留在当前阶段;
    • 重复阶段或某个要素。

    在不同的组织、行业或工作类型中,阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。

    项目管理生命周期

      项目管理生命周期是对项目目标的实现进行管理的过程。项目生命周期每个阶段都是通过一系列项目管理活动进行的。这些管理活动被称为项目管理过程。 每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。

    项目生命周期的每个阶段都要执行项目管理生命周期
    项目管理的输出一般都是些项目标准文档

      项目管理过程组指对项目管理过程进行逻辑分组,以达成项目的特定目标。过程组不同于项目阶段。项目管理过程可分为以下五个项目管理过程组:

    • 启动过程组: 定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。
    • 规划过程组: 明确项目范围,优化目标,为实现目标制定行动方案的一组过程。
    • 执行过程组: 完成项目管理计划中确定的工作,以满足项目要求的一组过程。
    • 监控过程组: 跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更的一 组过程。
    • 收尾过程组: 正式完成或结束项目、阶段或合同所执行的过程。

      但是,需要注意 阶段 ≠ 过程组。不同行业,不同规模项目的项目管理生命周期大致相同。项目管理生命周期的过程是 PMP(Project Management Professional​) 考试的主要考试范围。

    除了过程组,过程还可以按知识领域进行分类,分为 10 个知识领域(其中始终关注的是范围、进度、成本和质量):

    • 项目整合管理: 包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动。
    • 项目范围管理: 包括确保项目做且只做所需的全部工作以成功完成项目的各个过程。
    • 项目进度管理: 包括为管理项目按时完成所需的各个过程。
    • 项目成本管理: 包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程
    • 项目质量管理: 包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方的期望的各个过程。
    • 项目资源管理: 包括识别、获取和管理所需资源以成功完成项目的各个过程。
    • 项目沟通管理: 包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。
    • 项目风险管理: 包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。
    • 项目采购管理: 包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
    • 项目相关方管理: 包括用于开展下列工作的各个过程:识别影响或受项目影响的人员、团队或组织,分析相关方对项目的期望和影响,制定合适的管理策略来有效调动相关方参与项目决策和执行。

    下图显示了管理过程朱与知识领域的对应关系以及在过程中需要的工作:
    在这里插入图片描述

    裁剪

      由于每个项目都是独特的,所以有必要对项目管理过程进行裁剪;并非每个项目都需要《PMBOK® 指南》所确定的每个过程、工具、技术、输入或输出。裁剪应处理关于范围、进度、成本、资源、质量和风险的相互竞争的制约因素。各个制约因素对不同项目的重要性不一样,项目经理应根据项目环境、组织文化、相关方需求和其他变量裁剪管理这些制约因素的方法。

    产品生命周期

      产品生命周期管理的是产品,包括一系列产品阶段:市场调研、产品研发、试产、量产、运营、维护和退市。产品生命周期通常包含顺序排列且不互相交叉的一系列产品阶段。

    产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

      产品生命周期由一个或多个项目生命周期组成,也可能分为多个迭代周期来实现。 而项目生命周期也可开发一个或多个产品。一个项目生命周期通常只包含在一个产品生命周期中。在项目生命周期结束即项目完成后,而产品生命周期还需进行产品的运营、维护和退市等阶段。

      与产品生命周期相对应的成本概念是全生命周期成本,包括一次性的项目软硬件投入(一次性成本),以及 3 - 5 年运营或运维成本(持续成本)。

    三重关系

      三重约束,又称项目管理三角,是指适用于每个项目的时间、质量和成本界限。负责控制这些限制的项目管理流程包括进度管理、成本管理和质量管理。下图显示了软件项目的三个限制的关系。
    限制

    我在学习中发现,有部分文章中,质量 被替换为 范围,即:时间、范围和成本。

    软件项目管理

      到目前为止,仍然有很多人有疑问:软件开发项目到底能不能称为项目?这与对于软件工程能不能算是工程的疑问类似。在某些人的认识中,项目或者说工程更多的是指工业建筑中的专有名词。

      自 20 世纪 60 年代以来,软件制造商自行开发了几种专有的软件项目管理方法。今天,软件项目管理方法仍在不断发展,但是当前的趋势已从瀑布模型转移到了模仿软件开发过程的更具周期性的项目交付模型。

      软件项目管理(Software Project Management)就是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。通常,可以将软件开发项目可以分为两大类:

    • 软件项目: 运行于已有通用硬件上的软件系统。例如,PC 上运行的软件,服务器上运行的网站。
    • 系统项目: 运行于特定硬件上的软件系统,除了要开发软件,还要开发对应的硬件。例如各种嵌入式设备。

    如果没有特殊说明,后文我们所说的软件项目管理均指这两种类型的统称。

      软件工程项目管理不同于传统的项目管理,因为软件项目具有独特的生命周期过程,需要多轮测试、更新和客户反馈。目前,大多数 IT 相关项目都以敏捷的风格进行管理,以跟上业务增长的步伐,并根据客户和利益相关者的反馈进行重复。

    过程方法

    2017 年的一项研究显示,任何项目的成功取决于四个关键方面,这些方面被称为 4P :

    1. 计划(Plan):指所有涉及规划和预测的活动。在这个阶段,项目或项目的要素尚未实现;
    2. 过程(Processes):项目管理知识体(PMBOK, Project Management Body of Knowledge)指南中记述,项目主要由一系列预定和结构良好的过程所组成;
    3. 人员(People):人员是项目动态的重要组成部分,一些研究表明,人员是某些项目特有问题的核心。所谓“可怕的结合”,特别是指规划不善和不适当人员的构成;
    4. 权责(Power):描述当局所有的权力与责任、决策者、组织图,执行政策和喜好。

      组织与完成项目活动有许多方法,包括:分阶段、精益、迭代和增量等;也有一些对项目规划的几个扩展,例如,针对结果(基于产品)或活动(基于流程)。不论采行何种方法论,必须精心缜密地考虑项目总体的目标,时程和成本,以及所有参与者和利害关系人的作用和责任。

      对于软件开发项目,在博文 项目管理 之一 软件开发生命周期(软件开发过程、瀑布模型、敏捷开发等) 中介绍的各种过程模型,基本就是指导我们软件开发的方法。但是,由于项目具有独特性,因此标准的生命周期模型往往难以满足项目的特殊需要。通常项目在定义生命周期时,可首先选择一种标准的生命周期模型作为基础,然后指定出适合自己的方法。

    传统的顺序方法

    瀑布式管理方法

      规划项目的最常见方法是对导致最终交付的任务进行排序,并按顺序进行工作。这个过程也被称为瀑布方法——管理项目的传统方法,也是最容易理解的方法。

      这种方法的强大之处在于,每一步都是预先计划好的,并按照适当的顺序安排好。虽然这可能是最简单的最初实现方法,但涉众需求或优先级的任何更改都会破坏一系列任务,使其很难管理。这种方法在可预见性方面很出色,但缺乏灵活性。

    关键路径方法(CPM)

      关键路径方法(Critical Path Method)是在 20 世纪 50 年代开发的,其基础是,有些任务在完成上一个任务之前无法启动。当您从头到尾将这些依赖任务串在一起时,您会绘制出关键路径。

      确定并关注这一关键路径后,项目经理就可以确定优先级并分配资源,以完成最重要的工作,并重新安排可能会阻塞团队的所有低优先级任务。 这样,如果您需要更改项目进度表,则可以在不延迟结果的情况下优化团队的工作流程。

    关键链项目管理(CCPM)

      关键链项目管理(Critical Chain Project Management)将关键路径方法更进一步。CCPM 是一种方法,它侧重于通过在关键路径中增加资源可用性来完成项目任务所需的资源。它还在项目计划中围绕这些任务建立时间缓冲,确保项目满足其最后期限。

    敏捷家族

      由于竞争激烈的商业环境和不断创新,敏捷的项目管理方法越来越受欢迎。一般来说,敏捷方法优先考虑更短的迭期周期和灵活性。

    Scrum

      Scrum 是最受欢迎的敏捷发展框架,因为它的实现相对简单。它还解决了软件开发人员过去遇到的许多问题,例如复杂的开发周期、不灵活的项目计划以及更改生产计划。

    详细介绍见 项目管理 之二 敏捷开发方法 Scrum 最全指导 .

    看板

      看板是基于团队能力实施敏捷的另一个框架。它起源于 20 世纪 40 年代的丰田工厂。各部门使用可视化的卡片系统(“看板”)来表示他们的团队已经为更多的原材料做好准备,并拥有更多的生产能力。

    极限编程 (XP)

      极限编程 (Extreme Programming) 是敏捷的另一个分支。XP 是一种旨在提高软件质量(和简单性)和开发团队适应客户需求的能力的方法。与原始的敏捷开发非常类似,XP 具有工作冲刺短、迭代频繁以及与利益相关者不断协作的特点。变化可能发生在冲刺阶段。如果特定功能的工作尚未开始,则可以将其更换为类似任务。

    自适应项目框架(APF)

      自适应项目框架(Adaptive Project Framework)源于由于不确定和不断变化的需求而难以使用传统项目管理方法来管理大多数 IT 项目的情况。

      APF从需求分解结构(RBS)开始,以根据产品需求,功能,子功能和功能定义战略项目目标。 该项目分阶段进行,在每个步骤的最后,团队都会评估以前的结果以改善性能和实践。

    变更管理方法

    有些方法论用于管理项目,但更侧重于变更管理,尤其是风险规划和在变更发生时进行控制。

    事件链方法(ECM)

      事件链方法(Event Chain Methodology)背后的基本理念是,潜在风险往往不在项目范围之外。必须做好应对这些风险的准备,并计划您的应对措施,因为意外事件会影响您的项目的进度、交付成果以及潜在的成功。

    极限项目管理(XPM)

      极限项目管理 (Extreme Project Management) 与瀑布正好相反。它为您提供了一种管理大规模变革的方法,并且仍然朝着项目完成的方向前进。在 XPM 中,无论项目进展有多远,您都可以更改项目计划、预算,甚至最终交付,以满足不断变化的需求。

    基于过程的方法

    其中每种方法都侧重于将工作作为流程的集合。

    精 益

      精益(Lean)是一种专注于精简和减少浪费的方法(精益求精)。第一步是创建工作流程分解,以识别和消除瓶颈和延迟。目标是用更少的人力、更少的钱和更少的时间为客户提供价值。

    Six sigma

      Six Sigma 于20 世纪 80 年代中期由摩托罗拉的工程师介绍,通过识别项目中不起作用的内容来提高质量。

      Six Sigma 是一种基于统计的方法,旨在通过测量存在的缺陷并消除尽可能多的缺陷来提高过程质量。 如果 99.99966% 的最终产品(您的项目可交付成果)没有缺陷,则该过程可以达到 Six Sigma 等级。

    其他方法

    PRINCE2

      PRINCE2 代表受控环境中的项目。 这是一种用于管理英国政府使用的项目的方法,其特点是基于产品的计划方法。 在 PRINCE2 中,结构化的项目委员会负责高层活动,例如确定业务理由和资源分配。 项目经理负责日程安排等较低级别的日常活动。 这种方法使团队可以更好地控制资源并有效降低风险。

    PRiSM

      PRiSM 代表“集成可持续方法的项目”,旨在在将环境可持续性纳入其流程的同时管理变更。 PRiSM的目标是完成任务,同时减少公司对环境和社会的负面影响。 从字面上看,它是绿色项目管理。

    项目管理的角色

    项目经理

      项目经理密切监视开发过程,准备并执行各种计划,安排必要和充足的资源,保持所有团队成员之间的沟通,以解决成本,预算,资源,时间,质量和客户满意度方面的问题。

      正式的项目经理通常通过美国 PMI 或英国 PRINCE2 之类的机构进行认证。认证后,他们需要通过接受额外的培训来收集目标数量的 PDU(Professional Development Units)来维持其认证。

    1. PDU 代表专业发展单元,是 一种衡量正在进行的专业发展的方法。 为了保持作为项目管理专业人员(PMP)的认证,您将需要维护特定数量的 PDU,这些 PDU 可以通过参加活动或完成课程来获得。
    2. 美国项目管理协会(PMI)举办的项目管理专业人员(PMP)认证考试在全球180多个国家和地区推广,是目前项目管理领域含金量最高的认证。被全球项目管理界人士所认可!

      在实际的工作中,认证并不总是一个要求,它可以是在以后的职业生涯中获得的东西。大多数项目经理通常从工商管理学位开始,但实际中并非总是这样。经验往往比学位更响亮。

      通常,项目经理需要熟练使用 PERT 来对项目进行管理。

    Rrogram (or Project) Evaluation and Review Technique (PERT) 程序(或项目)评估和审查技术是用于项目管理的统计工具,旨在分析和表示完成给定项目所涉及的任务。它最初由美国海军于1958年开发,通常与1957年推出的临界路径方法(CPM)一起使用。

    软件项目经理

      软件项目经理是负责执行软件项目的人员,通常是 PMI 认证的项目管理专业人员 (PMP)。 软件项目经理完全了解软件将经历的 SDLC 的所有阶段。项目经理可能永远不会直接参与最终产品的生产,但他会控制和管理生产中涉及的活动。

    项目成员

    他们是负责完成项目一的人员。 团队成员是熟练的专业人员,他们致力于为项目目标做出贡献。

    客户

    项目产品的交付者。可能来自内部,也可能来自外部。

    利益相关者

    这是在项目中有既得利益的人或团体。它可能是一个组织的内部团体或机构,也可能是公共工程项目的公众。

    风险管理

      风险管理是对风险(在 ISO 31000 中定义为不确定性对目标的影响)的识别,评估和优先级划分,然后协调,经济地使用资源以最小化,监视和控制不幸事件的可能性或影响或最大化机会的实现。风险管理包括与识别、分析和为项目中的可预测和不可预测风险做准备相关的所有活动。

    风险评估

      软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题,以及由这些问题而对项目所产生的影响。

      项目的风险与其可行性成反比,其可行性越高,风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面。

    成本预算

    自上而下的预算方法(经验估计技术)

      自上而下的预算方法主要是依据上层、中层项目管理人员的管理经验进行判断,对构成项目整体成本的子项目成本进行估计,并把这些判断估计的结果传递给低一层的管理人员,在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计,然后继续向下一层传递他们的成本估计,直到传递到最低一层。

    该技术使用经验导出的公式进行估算。这些公式基于 LOC 或 FP。

    • Putnam 模型: 该模型由Lawrence H. Putnam制作,该模型基于Norden的频率分布(瑞利曲线)。 Putnam模型映射了软件大小所需的时间和精力。

      关于 Putnam 模型,详见 https://wiki.mbalib.com/zh-cn/Putnam%E6%A8%A1%E5%9E%8B

    • COCOMO: COCOMO 是由 Barry W. Boehm 开发的建设性成本模型(COnstructive COst MOdel)的缩写。它将软件产品分为三类:有机软件、半分离软件和嵌入式软件。

    自下而上的预算方法(分解技术)

      自下而上方法要求运用 WBS(Work Breakdown Structure,工作分解结构)对项目的所有工作任务的时间和预算进行仔细考察。最初,预算是针对资源(团队成员的工作时间、硬件的配置)进行的,项目经理在此之上再加上适当的间接费用(如培训费用、管理费用、不可预见费等)以及项目要达到的利润目标就形成了项目的总预算。

    主要有两种模式:

    • 代码行: 依据软件产品中的代码行数进行估计。
    • 功能点: 依据软件产品中功能点的数量进行估算。

      自下而上的预算方法要求全面考虑所有涉及到的工作任务,更适用于项目的初期与中期,它能准备地评估项目的成本,与真实费用相差在 5% ~ 10% 之间。

    质量管理

      质量管理确保组织、产品或服务是一致的。它包括四个主要组成部分:质量规划、质量保证、质量控制和质量改进。 质量管理不仅注重产品和服务质量,而且注重实现质量的手段。因此,质量管理利用对工艺和产品的质量保证和控制来实现更一致的质量。

    软件质量保证

      软件质量保证(SQA,Software Quality Insurance)是在软件过程中的每一步都进行的“保护性活动”。SQA 主要有基于非执行的测试(也称为评审)、基于执行的测试(即通常所说的测试)和程序正确性证明。

      软件评审是最为重要的 SQA 活动之一。它的作用是,在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。

    配置管理

      配置管理是根据产品的需求,设计,功能和开发来跟踪和控制软件更改的过程。IEEE 将其定义为:the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items。

      配置管理是组织管理的一门学科,它负责处理阶段性基础化后发生的任何变化(流程、要求、技术、战略等)。CM 会不断检查软件中所做的任何更改。

    软件配置管理

      软件配置管理(SCM,Software Configuration Management)是应用于整个软件过程中的保护性活动,它是在软件整个生命周期内管理变化的一组活动。是配置管理这个更大的跨学科领域的一部分。

      软件配置管理包括版本控制和基线的建立。如果出现问题,SCM 可以确定更改了什么以及是谁更改了它。如果配置工作良好,SCM 可以决定如何在许多主机上复现它。

      软件配置由一组相互关联的对象组成,这些对象也称为软件配置项,它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外,用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了评审,它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。

    软件配置管理系统
      库是软件配置管理系统的根本。库是集中控制的文件库,并提供对库中所存储文件的版本控制。任何库中的文件都被视为在确定的软件配置管理之下。
      在项目实际工作中,可以用 SVN、Git 等工具来建立配置库。

    基线

      在配置管理中,基线是在某个时间点对产品属性达成的一致描述,可作为定义更改的基础。更改是从此基准状态到下一个状态的移动。 识别基线状态的重大变化是基线识别的主要目的。

      如果 SDLC 的一个阶段已经建立了基线,那么就假定它已经完成了,例如,基线是定义一个阶段完整性的度量。当与阶段有关的所有活动都已完成并得到良好的文档记录时,阶段就被确立为基线。如果它不是最后阶段,它的输出将用于下一个直接阶段。

    版本控制

      在软件工程中,版本控制(也称为修订控制,源代码控制或源代码管理)是一类负责管理对计算机程序,文档,大型网站或其他信息集合的更改的系统。 版本控制是软件配置管理的组成部分。

      在软件开发中,版本控制系统的使用是必不可少的。详细见博文 版本控制系统 之一 概念、分类、常见版本控制系统(CVS、SVN、BitKeeper、Git 等)

    变更管理

      变更管理(Change management)是对所有支持和帮助个人或团队进行组织变更的方法的集合术语。变更的驱动因素可能包括技术的不断演变、流程的内部审查、危机应对、客户需求变化、竞争压力、收购和兼并以及组织重组。 它包括重定向或重新定义资源使用、业务流程、预算分配或其他显著改变公司或组织运营模式的方法。

    变更控制

      变更控制(Change Control)是质量管理系统(QMS)和信息技术(IT)系统中的一个过程,用来确保以受控和协调的方式引入产品或系统的变更。它减少了在没有预先考虑的情况下对系统进行不必要的更改、在系统中引入错误或撤销其他软件用户所做的更改的可能性。变更控制过程的目标通常包括最小化对服务的干扰,减少回退活动,以及对实现变更所涉及的资源的低成本利用。

    不要与版本控制相混淆。

    项目管理工具

    见独立博文

    参考

    1. https://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86
    2. http://learnfuture.com/PMP/902
    3. https://www.cnblogs.com/leslies2/archive/2012/06/29/2569765.html
    4. https://www.tutorialspoint.com/software_engineering/software_project_management.htm
    5. https://www.wrike.com/project-management-guide/project-lifecycle/
    6. https://www.wrike.com/project-management-guide/methodologies/
    7. https://en.wikipedia.org/wiki/Software_project_management
    8. https://www.projectmanager.com/project-management
    展开全文
  • 项目管理:项目质量管理

    千次阅读 2021-01-15 10:09:41
    PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会(Project Management Institute(PMI)发起的,严格评估项目管理人员知识技能是否具有高品质的资格认证考试。该文章内容基于PMBOK第六版总结而得。 重 ...

    PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会(Project Management Institute(PMI)发起的,严格评估项目管理人员知识技能是否具有高品质的资格认证考试。该文章内容基于PMBOK第六版总结而得。

    重 点 知 识

    “规划质量管理”、“管理质量”、“控制质量”相互影响、交叠进行,没有先后顺序。

    “管理质量”的重点是审计,需要对“规划质量管理”的结果和“控制质量”的结果都审计。

    管理质量是所有人的共同职责,包括:项目经理、项目团队、项目发起人、执行组织的管理层,甚至是客户。

    管理质量过程的作用:做出合格质量建立信心(客户/团队)满足特定的需求和期望审计质量要求和质量控制测量结果改进生产过程

    质量成本(COQ)是指在整个产品生命周期中的、评价产品或服务是否符合要求,以及因未达到要求而发生的所有成本。

    质量成本包含一致性成本非一致性成本,一致性成本包含预防成本评估成本,非一致性成本包含内部失效成本外部失效成本

    流程图:追溯过往步骤(向上)查找原因;对于未来(向下)做预测;制作SIPOC模型。

    因果图(鱼骨图/why-why分析图/石川图/ISHIKAWA图):找出产生问题的根本原因

    帕累托图:遵守“二八原则”,可以找到最主要的原因

    散点图(相关图):显示2个变量间的关系,找到引起2个变量问题的共同原因

    问题解决方法通常包括的因素有:定义问题;识别根本原因;生成可能的解决方案;选择最佳解决方案;执行解决方案;验证解决方案的有效性。

    质量报告可能是图形、数据或定性文件;其中包含的信息可帮助其他过程和部门采取纠正措施,以实现项目质量期望。

    质量报告的信息可以包含团队上报的质量管理问题,针对过程、项目和产品的改善建议,纠正措施建议(包括返工、缺陷/缺漏补救、100%检查等)以及在控制质量过程中发现的情况的概述。

    控制图主要作用:用来确定一个过程是否稳定;是否具有可预测的绩效。

    控制图具体功能:查明何时发生了特殊原因引起的变化,导致该过程失控;评价过程变更是否达到了预期的改进效果;提醒人们在还有时间解决问题时及时发现问题并采取措施。

    控制图经验总结:控制界限通常设在±3西格玛的位置;控制线外异常;7点原则(7点同侧,或7点同趋势,过程算异常,需要纠正);当过程被认为是在控制之内时不应调整,可以进行质量改进。

    质量管理详细内容

    一、项目质量管理包含的过程

    “规划质量管理”、“管理质量”、“控制质量”相互影响、交叠进行,没有先后顺序。

    “管理质量”的重点是审计,需要对“规划质量管理”的结果和“控制质量”的结果都审计。

    二、现代质量管理理念

    五个基本理念:客户满意、预防胜于检查、持续改进(PDCA)、管理层的责任(85%)、与供应商的互利合作关系。

    一个基本前提:项目质量管理需要兼顾项目管理与项目产品两个方面。

    三、质量和等级,精确和准确

    质量(ISO9000):一系列内在特性满足要求的程度。等级:对用途相同但技术特性不同的产品或服务的级别分类。

    精确:重复测量的结果非常聚合,离散度很小。

    准确:测量值非常接近实际值。

    四、五种质量管理水平

    按有效性递增排列的五种质量管理水平如下:

    让客户发现缺陷:这种方法可能会导致担保问题、召回、商誉受损和返工成本。

    先通过控制质量检测和纠正缺陷:再将可交付成果发送给客户。该过程会带来相关成本,主要是评估成本和内部失败成本。

    通过质量保证检查并纠正过程本身:不仅仅是特殊缺陷。

    将质量融入项目和产品的规划和设计中√

    在整个组织内创建一种关注并致力于实现过程和产品质量的文化。

    五、裁剪考虑因素

    政策合规与审计:组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?

    标准与法规合规性:是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?

    持续改进:如何管理项目中的质量改进?是在组织层面还是在单个项目层面进行管理?

    相关方参与:项目环境是否有利于相关方及供应商合作?

    六、关于敏捷/适应型环境的考虑因素

    敏捷方法要求多个质量与审核步骤贯穿整个项目,而不是在面临项目结束时才执行。

    循环回顾,定期检查质量过程的效果;寻找问题的根本原因,然后建议实施新的质量改进方法;后续回顾会议评估试验过程,确定是否可行、是否应继续、或做出调整,或者直接弃用。

    为促进频繁的增量交付,敏捷方法关注于小批量工作,纳入尽可能多的项目可交付成果的要素。

    小批量系统的目的是在项目生命周期早期(整体变更成本较低)发现不一致和质量问

    题。

    七、质量政策(Policy)

    由高级管理层颁布的、确定组织质量工作方向的质量政策。

    执行组织的产品质量政策经常可“原样”照搬到项目中使用。

    如果执行组织没有正式的质量政策,或项目涉及多个执行组织(如:合资项目),项目管理团队就需要为项目制定质量政策。

    无论质量政策源自何处,项目管理团队必须通过适当的信息发布,确保相关方完全了解项目所使用的质量政策。

    八、专有的质量管理方法

    六西格玛:每100万个机会中只3.4个错误Minitab。

    精益六西格玛:精益生产与六西格玛管理的结合,其本质是消除浪费。

    质量功能部署:把顾客对产品的需求进行多层次的演绎分析,转化为设计和工艺要求等。

    CMMl:软件能力成熟度模型集成,目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力。

    全面质量管理:鼓励全公司及所有员工共同致力于持续改进其本职工作质量以提高产品质量。

    九、规划质量管理

    定义:识别/制定质量标准(质量政策[由上至下],质量测量指标);记录如何达到(质量管理计划[how])。

    作用:在整个项目期间如何管理和核实质量提供指南和方向。

    发生时间:仅开展一次或仅在项目的预定义点开展。

    十、规划质量管理

    十一、数据分析——成本效益分析

    概念:对每个质量活动进行成本效益分析(商业论证),比较可能成本与预期效益

    投入 = 回报,质量免费

    十二、数据分析——质量成本(COQ)

    十三、质量成本(Cost of Quality)

    十四、数据表现——流程图

    *流程图也叫过程图。

    *基本要素:活动、决策点、分支、并行、处理顺序。

    *是对一个过程的图形化表示

    *四点用途:

    - 了解和估算一个过程的质量成本

    - 追溯过往步骤(向上)查找原因

    - 对未来(向下)做预测

    - 制作SIPOC模型

    十五、SIPOC模型

    * SIPOC模型是质量大师戴明提出来的组织系统模型

    * Supplier 供应者;Input 输入;Process 过程;Output:输出;Customer 客户

    十六、数据表现——矩阵图

    矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。

    根据可用来比较因素的数量,项目经理可使用不同形状的矩阵图,如L型、T型、Y型、X型、C型和屋顶型矩阵。

    在本过程中,它们有助于识别对项目成功至关重要的质量测量指标。

    十七、测试与检查的规划

    在规划阶段,项目经理和项目团队决定如何测试或检查产品、可交付成果或服务,以满足相关方的需求和期望,以及如何满足产品的绩效和可靠性目标。

    不同行业有不同的测试方式:

    软件项目:α测试和β测试。

    建筑项目:强度测试、制造和实地测试的检查、工程的无损伤测试。

    十八、质量管理计划

    * 描述如何实施执行组织的质量政策

    * 可以是正式或非正式的,非常详细或高度概括

    * 在项目早期进行评审,以确保决策是基于准确信息的(更加关注项目的价值定位,减少返工)

    * 包括:

    √项目采用的质量标准;

    √项目的质量目标;

    √质量角色与职责;

    √需要质量审查的项目可交付成果和过程;

    √为项目规划的质量控制和质量管理活动;

    √项目使用的质量工具;

    √与项目有关的主要程序;

    十九、质量测量指标

    * 是一种操作性定义。

    * 用非常具体的语言,描述项目或产品属性以及控制质量过程将如何验证符合程度。

    * 测量指标的例子包括:按时完成的任务的百分比、以CPI测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数,测试计划所涵盖的需求的百分比(即:测试覆盖度)。

    * 测量指标可允许的变动范围叫公差。

    二十、管理质量

    定义:把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动。

    作用:提高实现质量目标的可能性,以及识别无效过程和导致质量低劣的原因(审计)。

    发生时间:在整个项目期间开展。

    * 管理质量有时被称为“质量保证”,但“管理质量“的定义比“质量保证”更广,因其可用于非项目工作。

    * 管理质量包括所有质量保证活动,还与产品设计和过程改进有关。

    * 管理质量的工作属于质量成本框架中的一致性工作。

    二十一、管理质量

    * 管理质量是所有人的共同职责,包括:项目经理、项目团队、项目发起人、执行组织的管理层,甚至是客户。

    * 在敏捷项目中,整个项目期间的质量管理由所有团队成员执行;在传统项目中,质量管理通常是特定团队成员的职责。

    * 管理质量过程的作用: - 做出合格质量; - 建立信心(客户/团队); - 满足特定的需求和期望; - 审计质量要求和质量控制测量结果(确保使用合理标准); - 改进生产过程(提高过程和活动的效率与效果,获得更好的成果和绩效,提高相关方的满意程度)。

    二十二、管理质量

    二十三、数据表现——因果图

    * 1953年日本管理大师石川馨先生创造了一种极方便又有效的原因分析法。

    因果图又称“鱼骨图”、“why-why分析图”、“石川图”、“ISHIKAWA图”。

    * 直观地显示各种因素如何与潜在问题或结果相联系,找出产生问题的根本原因

    * 用于找出控制图中产生特殊偏差的非随机原因,来消除特殊偏差。

    * 因果图还可用于风险识别(识别风险起因)。

    二十四、数据表现——直方图

    * 概念:描述集中趋势、分散程度、统计分布形状。

    * 利用数字和柱形的相对高度,直观表示引发问题最普遍的原因,不考虑时间因素影响(非过程监控)

    * 示例:横轴是问题各个原因,纵轴是各个原因的发生次数。

    二十五、帕累托图

    * 按发生频率排序的特殊直方图,显示每种已识别的原因分别导致了多少缺陷。

    * 80/20原则,排序的目的是为了有重点地采取纠正措施。

    降序排列,涵盖100%的可观察结果

    * 项目团队首先要处理那些导致最多缺陷的原因。

    * 关键词:排序,最重要

    二十六、数据表现——散点图

    * 散点图又称相关图。

    * 显示2个变量间的共同原因。

    * 找到引起2个变量问题的共同原因。

    * 需要在散点图上标出因变量和自变量。

    * 数据点越接近对角线,两个变量之间的关系就越密切。

    * 相关性:正比例(正相关),负比例(负相关),不存在(零相关)。

    二十七、(质量)审计

    * 独立的结构化审查。* 通常由项目外部的团队开展,如:组织内部审计部门、项目管理办公室(PMO)或组织内部或外部的审计师。

    可确认项目活动是否遵循了组织和项目的政策

    作用: - 识别全部正在实施的良好及最佳实践

    - 识别所有违规做法、差距及不足

    - 分享所在组织和/或行业中类似项目的良好实践

    - 积极、主动地提供协助,以改进过程的执行,从而帮助团队提高生产效率

    - 强调每次审计都应对组织经验教训知识库的积累做出贡献

    * 质量审计还可确认已批准的变更请求。

    二十八、面向X的设计

    * 面向X的设计(DFX)是产品设计期间可采用的一系列技术指南,旨在优化设计的特定方面,可以控制或提高产品最终特性。* DFX中的“X”可以是产品开发的不同方面,例如:可靠性、调配、装配、制造、成本、服务、可用性、安全性和质量。

    * 使用DFX可以降低成本、改进质量、提高绩效和客户满意度。

    * 典型的DFX方法如下:

    - DFA:面向装配的设计

    - DFM:面向制造的设计

    - DFI:面向检验的设计

    - DFS:面向维修的设计

    - DFR:面向回收的设计

    - DFC:面向成本的设计

    - DFQ:面向质量的设计

    二十九、问题解决

    * 发现解决问题或应对挑战的解决方案。* 它包括收集其他信息、具有批判性思维的、创造性的、量化的和/或逻辑性的解决方法。

    * 有效和系统化地解决问题是管理质量和质量改进的基本要素。

    * 问题可能在控制质量过程或质量审计中发现,也可能与过程或可交付成果有关。

    * 使用结构化的问题解决方案有助于消除问题和制定长久有效的解决方案。

    * 问题解决方法通常包括以下要素:

    - 定义问题;

    - 识别根本原因;

    - 生成可能的解决方案;

    - 选择最佳解决方案;

    - 执行解决方案;

    - 验证解决方案的有效性。

    三十、质量改进方法

    * 质量改进的开展,可基于质量控制过程的发现和建议、质量审计的发现,或管理质量过程的问题解决。* 计划 - 实施 - 检查 - 行动(PDCA)和六西格玛是最常用于分析和评估改进机会的两种质量改进工具。

    三十一、质量报告

    * 质量报告可能是图形、数据或定性文件。

    * 其中包含的信息可帮助其他过程和部门采取纠正措施,以实现项目质量期望。

    * 质量报告的信息可以包含团队上报的质量管理问题,针对过程、项目和产品的改善建议,纠正措施建议(包括返工、缺陷/漏洞补救、100%检查等)以及在控制质量过程中发现的情况的概述。

    三十二、控制质量

    定义:为了评估绩效,确保项目输出完整、正确且满足客户期望,而监督和记录质量管理活动执行结果。* 作用:核实项目可交付成果和工作已经达到主要相关方的质量要求,可供最终验收。

    发生时间:在整个项目期间开展。

    * 控制质量过程确定项目输出是否达到预期目的,这些输出需要满足所有适用标准、要求、法规和规范。

    控制质量过程的目的是在用户验收和最终交付之前测量产品和服务的完整性、合规性和适用性。

    * 控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。

    三十三、控制质量

    * 项目管理计划 + 工作绩效数据 -> 数据分析 -> 工作绩效信息

    * 测试与评估文件 -> 测试/产品评估 -> 质量控制测量结果

    * 可交付成果 -> 检查 -> 核实的可交付成果

    三十四、数据收集——核对单(Checklists)

    * 结构化工具。* 用于质量控制过程。* 基于项目的不同要求和实践,可简可繁。

    * 应该涵盖范围基准中的验收标准。* 核对单可能会不够全面

    三十五、数据收集——核查表(check sheets)

    * 核查表也叫计数表(tall sheets)* 实时记录结果

    * 用一些图案、符号表示核查的结果

    * 有效收集潜在质量问题的有用数据* 收集属性数据比较擅长* 核查表 + 帕累托图

    三十六、数据收集——统计抽样

    关键:确定抽样的频率和规模,选取的样本可以代表全局。* 思考:最大的好处:是解决成本吗?

    * 使用场景:样本多,概率统计。

    三十七、测试/产品评估

    * 测试是一种有组织的、结构化的调查,旨在根据项目需求提供有关被测产品或服务质量的客观信息。

    * 测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。

    * 用于评估各项需求的测试的类型、数量和程度是项目质量计划的一部分,具体取决于项目的性质、时间、预算或其他制约因素。

    * 测试可以贯穿于整个项目,可以随着项目的不同组成部分变得可用时进行,也可以在项目结束(即交付最终可交付成果)时进行。

    * 早期测试有助于识别不合规问题,帮助减少修补不合规组件的成本。

    * 不同应用领域需要不同测试:

    软件项目测试:包括单元测试、集成测试、黑盒测试、白盒测试、接口测试、回归测试、σ测试等。

    建筑项目测试:水泥强度测试、混凝土和易性测试、在建筑工地进行的旨在测试硬化混凝土结构的质量的无损伤测试,以及土壤试验等。

    硬件开始测试:环境应力筛选、老化测试、系统测试等。

    三十八、数据表现——控制图

    主要作用

    - 控制图用来确定一个过程是否稳定。

    - 是否具有可预测的绩效。

    具体功能

    - 查明何时发生了特殊原因引起的变化,导致该过程失控。

    - 评价过程变更是否达到了预期的改进效果。

    - 提醒人们在还有时间解决问题时及时发现问题并采取措施。

    两对概念

    - 规格的上限和下限:反映了可允许的最大值和最小值,根据协议要求而制定。

    - 控制上限和下限:反映了必须采取纠正措施的位置,由项目经理和相关方设定。

    经验总结

    - 控制界限通常设在±3西格玛的位置。

    控制线外异常

    7点原则(7点同侧,或7点同趋势,过程算异常,需要纠正)

    - 当过程被认为是在控制之内时不应调整,可以进行质量改进。

    三十九、质量责任

    需要项目管理资料合集的同学可留言

    展开全文
  • 软件项目管理笔记

    万次阅读 2020-05-13 09:51:18
    4.过程管理就是过程进行管理,目的是要让过程能够被共享,复用,并得到持续的改进 5.项目与日常运作的区别与共同点: 项目 日常运作 以目标为导项 通过效率和有效性的体现 通过项目经理及其团队工
  • 项目管理第十一章项目风险管理

    千次阅读 2020-09-21 12:08:51
    项目管理第十一章项目风险管理 项目风险管理:项目风险管理的目的在于提高正面风险的概率和影响,降低...实施定量风险分析:就已识别的单个项目风险和其他不确定性的来源整体项目目标的综合影响进行定量分析的过程。
  • 软件项目管理期末复习题

    千次阅读 2021-12-02 17:11:27
    2、项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。() 3、过程管理目的是要让过程能够被共享、复用,并得到持续的改进。() 4、项目具有临时性的特征。() 5、日常运作存在大量的变更...
  • 如何使用区块链技术进行项目开发

    千次阅读 2018-04-29 13:30:21
    从经济学的角度来看,这种容错能力很强的点点网络,恰恰满足了共享经济的一个必须要求——低成本的可信环境。本文以联盟链为例,描述了实践一个联盟链的基本过程,包含以下内容:业务场景的构建与初步分析,业务...
  • GitHub 上的优质 Linux 开源项目,真滴牛逼!

    万次阅读 多人点赞 2021-01-14 09:59:44
    GitHub 是我非常喜欢的一个网站,很多人在 GitHub 上开源了自己的优质项目通常我也闲逛 GitHub 会搜集一些自己有利的开源项目进行分类汇总,这次特意筛选了些 Linux 领域的优质开源项目,分享给大家。...
  • 项目管理复习题

    万次阅读 多人点赞 2020-09-18 11:54:44
    蓝字位注释,红字为错误原因,紫字为重点 ...提取码:j4jz 第一章 一、填空题 1.敏捷模型包括(4)个核心价值...2、项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。(×) 3、过程管理就是.
  • 软件项目管理知识点总结

    千次阅读 多人点赞 2020-12-27 18:18:16
    5、适用于软件项目管理的知识体系。​第2章 项目确立 &第3章 生存期模型【项目初始】1、理解项目启动的基本过程(项目评估、项目立项、招投标、发布项目章程);2、项目章程的主要内容和作用;3、理解各生存期...
  • 项目工具(如企业级项目管理软件)的实施和管理中心 项目之间的沟通管理协调中心 对项目经理进行指导的平台 通常对所有PMO管理的项目的时间基线和预算进行集中监控 在项目经理和任何内部或外部的质量人员或标准化...
  • 项目监控一般来说在项目启动以后就要开始进入监控状态,监控一般分成日监控、周监控、里程碑监控和随时监控。监控的频率和你想了解项目当前状况的信息需求相关。 日监控比如敏捷方法中的站会就是一种日监控的方式...
  • Java 项目项目范围分析 ...当你点击图标时,IntelliJ IDEA将开始检查你的项目,然后显示任何出现的问题,包括那些通常只有通过扫描整个项目才能发现的问题。请注意,第一次检查的时间可能比后续检查的时间长。 Int
  • IT项目管理

    万次阅读 多人点赞 2018-06-25 11:00:51
    IT项目管理 第一章 IT项目管理概述 1. 什么是项目?它有什么特点? 项目:是一个特殊的将被执行的有限任务,它是在一定时间内,满足一系列特定目标的多项相关工作的总称 三层含义: 项目是一项有待完成的任务...
  • 大型项目前端架构浅谈(8000字原创首发)

    千次阅读 多人点赞 2019-05-26 13:06:52
    大型项目前端架构浅谈 目录: 1、综合 1.1、使用场景 1.2、核心思想 1.3、切入角度 1.4、其他 2、基础层设计 2.1、自建Gitlab 2.2、版本管理 2.3、自动编译发布Jenkins 2.4、纯前端版本发布 2.5、统一脚手架 ...
  • PMP第十一章:项目风险管理

    千次阅读 2021-05-11 22:19:45
    PMP第十一章:项目风险...整体项目风险:不确定性对项目整体的影响,是相关方面临的项目结果正面和负面变异区间。 整体项目风险大于项目中单个风险之和,整体风险源于包括单个风险在内的所有不确定性。 三种性质的项目
  • 软件项目管理考前复习资料

    万次阅读 多人点赞 2018-12-12 16:53:27
    第一章.软件项目管理概述 1.实现项目目标的制约因素有: 项目范围 成本 进度计划 客户满意度 ...4.过程管理就是过程进行管理,目的是要让过程能够被共享,复用,并得到持续的改进 5.项目与日常运作的...
  • PMP 考点 第十一章 项目风险管理

    千次阅读 2020-12-04 09:19:41
    PMP第十一章项目风险管理 章节 序号 知识点 考点级别 备注  第十一章 项目风险管理         11.1 风险...
  • 用于支持管理决策数据仓库的结构通常包含数据源、数据集市、数据分析服务器和前端工具的4个层次 6、 大数据分析相比传统的数据仓库应用,其数据量大,查询分析复杂,且在技术上须依托分布式,云存储,虚拟化等...
  • ·项目干系人:是指那些积极参与项目,或是其利益会受到项目执行的影响,或是其利益会受到项目结果影响的个人或组织,他们也可能会对项目及其结果施加影响。 ·项目管理系统:是指用于管理项目的工具、技术、方法...
  • 软件项目管理案例教程韩万江课后习题答案第四版

    万次阅读 多人点赞 2021-01-01 07:29:35
    软件项目管理韩万江(第四版)课后习题答案第一章 软件项目管理概述填空判断选择问答第二章 项目确立填空判断选择问答第三章 生存期模型填空判断选择问答第四章 软件项目范围计划填空判断选择问答第五章 软件项目...
  • JAVA上百实例源码以及开源项目

    千次下载 热门讨论 2016-01-03 17:37:40
    通过本源码可以了解到Java如何产生单钥加密的密钥(myKey)、产生双钥的密钥(keyPair)、如何保存公钥的字节数组、保存私钥到文件privateKey.dat、如何用Java对象序列化保存私钥,通常应对私钥加密后再保存、如何从...
  •  WBS(P86)完成项目本身是一个复杂的过程,必须采取分解的手段把主要的可交付成果分成容易管理的单元才能一目了然,最终得出项目的任务分解(Work Breakdown Structure , WBS)。2. 项目目标实现的制约因素(P3...
  • 什么是项目管理?怎么管?(一)

    千次阅读 2020-04-25 19:43:33
    前言 项目管理是团队建立共同语言的需要、保证每个项目结果的需要、积累企业过程资产必要,同时还是打造企业战略执行力和项目管理... 项目就是为进行达到目标的一系列活动的综合概述,即实现某个目标所要做的事情...
  • 第十二章(项目采购管理)知识点

    万次阅读 2021-10-14 17:19:31
    项目采购管理包括从项目团队以外采购或获取产品、服务或结果的过程。包括合同的编写、管理和控制。
  • 项目风险管理的目标在于提高正面风险的概率和(或)影响,降低负面风险的概率和(或)影响,从而提高项目成功的可能性。 项目的独特性带来风险。风险三要素:风险事件、概率、影响。 单个项目风险是一旦发生,会...
  • 软件项目管理案例复习题

    万次阅读 多人点赞 2020-03-27 09:36:51
    敏捷模型包括(4)个核心价值,对应(12)个敏捷原则。 项目管理包括(启动过程组)、...、过程管理就是过程进行管理,目的是要让过程能够被共享、复用,并得到持续的改进。 √) 、项目具有临时性的特征。(√)...
  • K8S 部署电商项目

    万次阅读 2021-11-20 08:53:52
    K8S 部署电商项目

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 159,281
精华内容 63,712
关键字:

对全部项目进行检查通常更适用于