成本估算.docx
- 文档编号:26434652
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:14
- 大小:27.33KB
成本估算.docx
《成本估算.docx》由会员分享,可在线阅读,更多相关《成本估算.docx(14页珍藏版)》请在冰豆网上搜索。
成本估算
一:
成本估算
成本估算是对完成项目各项活动所需资源成本的近似估算,它根据活动资源估算中确定的资源需求和市场上各种资源的价格信息来进行。
成本估算是一个十分容易被忽视但又十分重要的一个内容,其重要的原因是没有成本估算,项目计划会失去基础。
容易被忽视的原因是大部分软件开发组织未能有效掌握它。
具体来讲,项目成本的大小同项目耗用资源数量、质量和价格有关,同项目工期长短有关,同项目质量结果有关,同项目范围的深度和宽度有关。
一般来说,编制成本估算有以下步骤:
1)识别分析项目成本构成科目;2)根据已识别成本构成科目,估算每一成本科目的成本大小;3)分析成本估算结果,找出可以相互替代的成本,协调成本间比例关系,成本估算通常以人天、人月、人年为单位表示,成本估算的具体方法有:
类比估算法、确定资源费率、项目管理软件、卖方投标分析、准备金分析、质量成本。
项目估算包括规模估算、工作量估算、进度估算和成本估算,整个估算过程如下:
首先根据需求进行规模估算即预计系统的规模,通常以代码行数、功能点数为单位;然后在估计的规模基础上,根据项目特点(如技术能力、使用的语言、开发平台、项目复杂度、团队稳定性等)、开发生产率经验数字估算开发的工作量,通常以人天、人月、人年为单位;最后根据客户提出的进度进行进度估算,根据人员和其他成本对总的开发成本进行估算,估算基础是经验数字和模型。
规模估算是系统开发成本估算的基础,而工作量估算是系统开发成本估算的关键,规模估算最常用的方法包括LOC代码行估算法、FP功能点估算法,工作量估算主要有MARK2FP估算、COCOMO估算、PUTNAM估算模型、类比估算、自下而上估算等。
二:
成本管理
项目成本管理是项目管理的一个重要组成部分,它是指在项目的实施过程中,为了保证成项目所花费的实际成本不超过其预算成本而展开的成本估算、预算编制和成本控制等方面的管理活动,它包括在批准的预算内完成项目所需要的诸过程,主要有:
1)成本估算:
编制一个为完成项目各活动所需要的资源成本的近似估算;2)成本预算:
将总的成本估算分配到各项活动上,建立成本基线;3)成本控制:
控制项目预算的变更。
以上彼此独立、相互间有明确界面的过程在实践中也会交叉重叠,互相影响,同时与其他知识领域的过程相互作用。
成本管理首先应关心完成项目活动所需资源的成本,同时考虑项目决策对使用项目产品成本的影响;其次在资金筹措项目中应对项目产品的财务经营状况进行预测和分析,可以使用投资回报分析、折算现金流等技术;最后还应考虑干系人的信息需求。
项目超预算的成本失控现象主要由以下原因造成:
1)成本估算和预算工作不够细致准确;2)很多项目在进行成本估算和预算以及成本控制方法上没有统一的规范和标准;3)思想上存在误差,认为项目具有创新性,造成项目实施过程中有太多变量,实际成本超出预算成本在所难免;4)早期的范围定义不清晰,没有形成明确所有需求的合理的项目管理计划。
三:
人力资源管理
在项目管理中,时间、成本、绩效三个因素达到客户的满意是项目成功的标准,但是除了以上因素外,人的因素也极为重要,因为项目中的活动都是由人来完成的,如何充分发挥人的作用,对于项目的成功起着至关重要的作用。
项目失败的原因除了对客户的需求不明确、项目的计划不清楚、公司的支持不到位以外,还有其他因为人力资源获取和建设方面的原因:
如招募到的团队成员不适合当前项目需要;团队成员尽管富有才干,但缺少或根本没有彼此合作的经验;团队气氛不积极,造成成员的士气低落;团队的职责和任务分配不清楚等。
所有这些原因都是因为在项目管理中,没有能够完整识别项目所需人力资源的种类和数量、清楚的分配责任到组织单元和个体、没有获得适合项目的人力资源、没有建立一个有效的团队,充分发挥项目干系人的能力以达到一个更好的绩效。
项目人力资源管理就是有效发挥每一个参与项目人员作用的过程,包括组织和管理项目团队所需的所有过程。
一般而言,一个完整的人力资源管理体系包含以下内容:
1)人力资源计划编制:
识别项目中角色、职责和汇报关系并形成文档;2)组建项目团队:
获取项目所需人力资源;3)项目团队建设:
提高个人和团队的技能以改善项目绩效;4)管理项目团队:
跟踪个人和团队的绩效,提供反馈、解决问题并协调各种变更以提高项目绩效。
四:
进度管理
成功的项目管理是在约定的时间、范围和预算的成本以及要求的质量下,达到项目干系人的期望。
进度管理是项目管理的重要组成部分,有效的进度管理是项目的灵魂和最大挑战。
项目进度管理的重点是通过调整资源要素,保证项目能够按时完成,对于影响到项目成功的风险和关键问题进行跟踪,项目经理在进度计划制定后的一大半时间都应该花在消除不确定性上。
进度安排的准确程度可能比成本估计的准确程度更重要。
对于成本估计的偏差,软件产品可以靠重新定价或者大量销售来弥补成本增加,但如果进度计划不能得到实施,则会导致市场机会的丧失或用户的不满,而且也会使成本增加。
因此在考虑进度安排时要把人员的工作量和花费的时间结合起来,合理分配工作量,利用进度安排的有效分析方法严密监视项目的进展情况,保证项目进度不被拖延。
一般而言,一个完整的时间管理体系包含以下内容:
活动定义、活动排序、活动资源估算、活动历时估算、制定进度计划和进度控制。
虽然以上过程是作为彼此独立,相互间有明确界面的组成部分,但在实践中也会交叉重叠,互相影响,同时与其他知识领域的过程相互作用。
项目在实施中一直处于动态的变化中,会遇到各种意外情况使项目不能按照计划进行,出现偏差,如我们遇到的问题就有项目人数和效率问题、任务的确定和并行问题、进度计划的制定、执行和控制问题等。
因此针对项目特点,结合公司战略,我采用以下策略进行项目进度管理:
五:
范围管理
项目范围管理包含一系列子过程,用以确保项目包含且只包含项目达到成功所必须完成的工作。
范围管理主要关注项目内容的定义和控制,即包括什么,不包括什么。
主要过程有1)范围计划编制:
规定如何对项目范围进行定义、确认和控制以及如何制定WBS;2)范围定义:
开发详细的范围说明书,作为将来项目决策的基础;3)创建工作分解结构:
将项目的主要可交付成果和项目工作细分为更小更易于管理的部分;4)范围确认:
项目干系人正式接受已完成的项目范围的过程;5)范围控制:
控制项目范围的变更。
项目范围是否完成以项目管理计划、项目范围说明书、WBS和WBS字典作为衡量标准,项目的几个生命期阶段和管理过程,项目的一次性和临时性,决定了项目工作范围都是有限的可控的,对项目范围管理和控制的有效性是衡量项目是否达到成功的一个必要标准,在项目中不断重申项目范围,有利于项目不偏离轨道,是项目实施控制管理的一个主要手段。
范围管理不仅仅是让项目管理人员和实施人员知道为达到预期目标需要完成哪些工作,还要确认清楚相关各方在每项工作中清晰的分工界面和责任。
确认范围有如下意义:
1)清楚项目范围后,为提高项目成本、时间和资源估算的准确性打下基础;2)范围计划编制是确定项目进度测量的基准;3)范围的确定有助于划分责任和分派任务,为进一步工作打下基础。
六:
质量管理
成功的项目管理是在约定的时间、范围、预算的成本和要求的质量下,达到项目干系人的期望。
能否成功的管理一个项目,质量的好坏非常重要。
质量管理是项目管理的重要方面之一,它与范围、成本和时间是项目成功的关键因素。
项目质量管理包括为确保项目能够满足所要执行的需求的过程,包括质量管理职能的所有活动,这些活动确定了质量策略、目标和责任,并在质量体系中凭借质量规划、质量控制和质量保证等措施,决定了对质量政策的执行、对质量目标的完成和对质量责任的履行。
在项目管理领域,质量管理的一个关键因素是通过项目范围管理转换隐含需求为项目需求。
项目质量管理必须针对项目管理过程和产品,管理团队需要考虑质量成本。
美国质量管理协会对质量的定义是:
过程、产品或服务满足明确或隐含的需求能力的特征。
一般而言,项目质量管理体系主要包括以下内容:
1)质量规划:
确定适合项目的质量标准并决定如何满足这些标准;2)质量保证:
在质量系统内实施的所有计划的系统性活动,是保证质量管理计划得以实施的一组过程和步骤,旨在证明项目满足相关质量标准;3)质量控制:
监控具体项目结果以确定其是否满足相关质量标准,制定有效方案以消除产生质量问题的原因。
七:
风险管理
项目是在复杂的自然和社会环境中进行的,受众多因素影响,对于这些内外因素,从事项目活动的主体往往认识不足或者没有足够的力量加以控制。
项目的过程和结果常常出乎人们的意料,有时不但未达到项目主体预期的目的,反而使其蒙受各种各样的损失,而有时又能给他们带来很好的机会。
项目同其他经济活动一样带有风险,要避免和减少损失,将威胁化为机会,项目主体就必须了解和掌握项目风险的来源、性质和发生规律,进而实施有效的管理。
对项目风险进行管理,已成为项目管理的重要方面。
项目风险具有随机性、相对性和可变性,风险也有多种分类,可以按风险后果、来源、是否可管理、影响范围、后果的承担者、可预测性等来划分。
风险的成本包括有形成本、无形成本和预防控制费用。
项目风险管理包括进行风险管理计划编制、对项目风险进行识别、分析和应对的过程,具体有以下内容:
1)风险管理计划编制:
决定如何动手处理规划和实施项目风险管理活动;2)风险识别:
哪些风险会对项目造成影响,并记录下它们的属性;3)定性风险分析:
对项目的风险进行优先级排序;4)定量风险分析:
测量风险出现的概率和结果,并评估它们对项目目标的影响;5)风险应对计划编制:
开发制定一些应对方案以提高项目成功的机会,降低失败的威胁;6)风险监控:
在项目整个生命期内监视残余风险,识别新的风险,执行应对计划和评估这些工作的有效性。
八:
采购管理
项目采购管理是项目执行的关键工作,是作好项目的重要方面,项目采购管理的模式在某种程度上决定了项目管理的模式,对项目整体管理起着决定性作用。
采购工作是项目执行的物质基础和主要内容。
规范的项目采购要兼顾经济性、合理性和有效性,可以有效降低项目成本,促进项目顺利实现项目各项目标,成功完成项目。
根据美国项目管理协会PMI的定义:
项目采购是从项目外购买或获取工作所需的原材料、产品和服务以及货物的过程。
也就是有效规划、管理和控制项目采购的过程。
一般而言,一个完整的项目采购管理过程包括:
1)采购计划编制:
决定采购什么,何时采购;2)编制合同:
记录项目对于和服务的要求,寻找潜在供应商;3)招标:
获取适当信息、报价、标书、要约等;4)供方选择:
审核所有要约,选择供应商并与之谈判最终合同;5)合同管理:
管理合同以及买卖关系,审核并记录供应商绩效以建立必要的纠正措施并作为将来选择供应商的标准;6)合同收尾:
合同履行和清算,包括对一些未决项目的决策。
九:
配置管理
配置管理在项目管理中具有重要的地位和作用。
近年来,随着信息系统项目的规模越来越大,复杂性越来越高,由于管理上的失误带给我们的教训也越来越深刻,这使得人们不得不重视配置管理。
它是PMBOK、ISO9000和CMMI中的重要组成部分,在产品开发的生命周期中提供结构化的、有序化的、产品化的管理方法,是项目管理的基础工作。
配置管理是采用技术手段和行政手段进行管理和监督的一套规范化方法,对配置项的物理特性和功能特性加以标识,并将其文档化。
控制这些特性的变更,报告变更进行的情况和变更实施的状态以及验证与规定需求的一致性。
总之,配置管理可以有效的管理产品的完整性和可追溯性,是对项目生命期各种阶段产品和最终产品演化变更的管理,通常完成以下工作:
1)制定配置管理管理计划:
由CCB审批,主要内容包括配置管理软硬件资源、配置项计划、基线计划、备份计划等;2)确定配置标识规则:
根据项目计划文档和配置管理的组织方针确定配置项的范围和识别准则;3)实施变更控制:
对变更实施有效控制和管理;4)报告配置状态:
有效记录和报告管理配置所需信息;5)进行配置审核:
确保配置管理的有效性;6)进行版本管理和发行管理:
按照一定规则保存配置项的所有版本,避免发生混乱和丢失并能准确找到配置项的任何版本。
案例
时长测试是固定电话网交换机计费准确性检测中的关键技术之一,通过深入分析在实际网络上的测试方案和试验数据,说明了影响交换机计费时长准确性的几种因素。
2003~2005年,信息产业部在全国范围内对多家运营企业的固定电话网在用局用电话交换设备计费性能进行了检测。
如图1所示,为了评估交换系统的计费准确率,在检测中采用七号信令测试仪表采集信令链路上的消息,对信令数据进行解码、分析、统计等一系列的处理,得到整个测试时间段内的呼叫流程并合成仪表话单,然后将仪表话单与交换局提供的局方话单相比较。
在检测过程中时长测量是一个很重要的环节,文章通过列举一些问题实例,针对影响计费时长准确性的因素进行分析。
固网计费检测的标准依据
测试所采用的通信行业标准为YD/T1278-2003《在用局用交换设备计费技术要求和检测方法——固定电话网部分》,由于计费准确性是由交换机和计费处理系统共同决定的,因此计费检测的对象主要针对交换机和相关计费处理系统两大部分。
(1)交换机主要进行计费时长的测试,检查交换机向相关计费处理系统提供CDR话单是否准确。
(2)相关计费处理系统 包括前置采集机、计费中心、账务中心等各种设备,是除交换机外其他计费设备的总称,主要进行计费后台处理工作。
对相关计费处理系统,主要进行批价的测试。
3、问题实例分析
通过对大量测试数据的分析,发现影响交换机计费准确性的主要因素有如下几个方面:
1)交换机版本低,精度不够:
某型号交换机在X版本前详单计费话单时长精确度为1s,不支持0.1s计费精度
2)交换机参数设置匹配问题:
如内部定时器参数设置不匹配造成时长超差
3)交换机时间与北京标准时间误差大:
时钟板老化及人为引入误差所致
4)时钟不匹配:
时钟系统是实现数字同步通信网内同步的心脏设备,时钟系统的工作稳定与否,它所产生的同步信号的好坏在很大程度上决定了交换系统的运行稳定程度,对计费精确度造成一定影响
5)计费点控制方式不同的影响:
由于呼叫的释放控制方式直接与计费有关,计费点采用不同的控制方式,交换机所记录的时长就不一致
3.2 相关计费系统造成的问题
1)计费采集软件对话单时长百毫秒位的处理问题
2)计费中心后期处理问题:
交换机向相关计费处理系统提供CDR话单,交换机记录一个呼叫开始时刻和结束时刻这两项数值,应可精确到百毫秒位,即开始时间、结束时间分辨率应不低于0.1s。
计费中心必须按向上取整、四舍五入或向下取整其中一种方式处理。
二、需求变更的产生原因
在软件开发项目中,需求变更可能来自方案服务商、客户或产品供应商等,当然,也可能来源于项目组内部。
对于需求变更发生的原因,细细追究起来无外乎以下几种原因:
1、范围没有圈定就开始细化;2、没有指定需求的基线:
需求的基线是指是否容许需求变更的分界线。
随着项目的进展,需求的基线也在变化。
是否容许变更的依据是合同以及对成本的影响,比如软件整体结构已经设计出来,是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。
随着项目的进展,基线将越定越高(容许的变更将越少)。
3、没有良好的软件结构适应变化:
组件式的软件结构就是提供了快速适应需求变化的体系结构,数据层封装了数据访间逻辑,业务层封装了业务逻辑,表示层展现用户表示逻辑。
但适应变化必须遵循一些松耦合合原则,各层之间还是存在一些联系的,设计要力求减少会对接口入口参数产生变化。
如果业务逻辑封装好了,则表示层界面上的一些排列或减少信息的要求是很容易适应的。
如果接口定义得合理,那么即使业务流程有变化,也能够快速适应变化。
因此,在成本影响的容许范围内可以降低需求的基线,提高客户的满意度。
三、需求变更控制
前面已经说过了,在软件开发项目开始之前,就要消除“绝不允许发生需求变更”的思想。
在项目进行,一旦发生需求变更,更不要不一味的抱怨,也不要去一味地迎合客户的“新需求”,而是要管理和控制需求变更。
1、分级管理客户需求
对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。
一级需求(或变更)是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。
这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成员的所有努力,所以定为“Urgent”。
这通常是属于补救性的debug类型,要救火。
二级需求(或变更)是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续,所以是“Necessary”。
一般新模块关键性的基础组件,属于这个级别。
三级需求是后续重要的需求,如果不被满足会令整体项目工作的价值下降,为了体现项目价值,也是开发人员自已的技术价值的证明,所以定为Needed”。
一般性的重大的有价值的全新模块开发,属于这个级别。
项目管理者联盟,项目管理问题。
以上三个等级是应该实施的,但时间性上可以作优先级的排列。
四级需求是改良性需求,没有满足这类需求并不影响已有功能的使用,但如果实现了则会更好,定级为“Better”。
界面和使用方式的需求,一般在这个档次。
五级需求是可选性需求,更多的是偶是一种设想,以及一种可能,通常只是客户的的一种个人喜好而已,定级为“Maybe”。
对于四级需求,如果时间和资源条件都允许的话,不妨做下去。
对于五级需求,正如对它的描述一样,做与不做是“Maybe”。
2、全生命周期的需求变更管理
各种规模和类型的软件项目的生命周期大致可以分为三个阶段,即项目启动、项目实施、项目收尾。
不要以为需求变更的管理和控制只是发生在项目实施阶段,而是要贯穿在整个项目生命周期的全过程中。
站在全局角度的需求变更管理,需要采用综合变更控制的方法。
(1)项目启动阶段的变更预防
正如前面强调的,对于任何软件项目,需求变更都无可避免,也无从逃避,无论是项目经理还是开发人员只能积极应对,而这个应对应该是从项目启动的需求分析阶段就开始了。
对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理提出需求变更的几率就越小。
如果需求没做好,基准文件里的范围含糊不清,被客户发现还有很大的“新需求空间”,这时候项目组往往要付出许多无谓的牺牲。
如果需求分析做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。
这个时候,项目经理一定要据理力争,此时这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。
2)项目实施阶段的需求变更
成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。
项目经理应该树立一个理念,即“需求变更是必然的、可控的,并且是有益的”。
项目实施阶段的变更控制需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。
控制需求渐变需要注意以下几点:
需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
所以,在项目的开始,无论是开发方还是出资方都要明确这一条:
需求变,软件开发的投人也要变。
需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。
精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的,并非需求写细了,它就不会变化了。
注意沟通的技巧。
项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。
(3)、项目收尾阶段的总结 能力的提高往往不是从成功的经验中来,而是从失败的教训中得来。
许多项目经理不注重经验教训总结和积累,即使在项目运作过程中碰得头破血流,也只是抱怨运气、环境和团队配合不好,很少系统地分析总结,或者不知道如何分析总结,以至于同样的问题反复出现。
事实上,项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容,同时也可以作为对项目合同、设计方案内容与目标的确认和验证。
项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结,也包括项目中发生的变更和项目中发生问题的分析统计的总结。
3、需求变更管理原则
虽然需求变更的内容和类型有各种各样,但需求变更管理的原则却是万变不离其宗。
实施需求变更管理需要遵循如下原则:
(1)建立需求基线。
需求基线是需求变更的依据。
在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。
此后每次变更并经过评审后,都要重新确定新的需求基线。
(2)制订简单、有效的变更控制流程,并形成文档。
在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
(3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。
CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
(4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
(5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
循序渐进说“不”的四项原则
在国内,没有几家公司会用钱来砸项目,项目经理必须快速完成开发、实施、布署、测试和客户培训,让客户接受并认可系统,从而在验收时不再为难你。
因为签字就意味着项目组人员的撤离,之后的服务肯定和现场是有差别的,而且签字也意味着对方要分担责任。
如何对不同类型的客户说“不”,还可以让客户接受,这是很大的一门学问,笔者从实践中总结出四个原则、四个方法和两个注意,借此抛砖引玉,和大家一起共勉。
四个原则:
一.说“不”之前,先请听完客户的话
二.思考后再答复
三.重复一遍客户话中的重点,表示你理解正确
四.让客户自己认为自己的观点不成熟、不完善、不合适是最高境界
一.理解客户的新需求,合理适当地满足
笔者遇到的客户,基本上没谁能将自己的需求写得非常详细,让开发人员看着像内部的详细设计说明书,一般都是比较笼统的概念和功能点。
这种情况下,首先要看一下客户的需求是全部合理,还是全部必需,还是都非常迫切。
迫切且合理必需的,就安排人手做;不迫切但却合理必需的,就考虑有时间时再安排人手来做;如果合理,但却不是必需的,一般就不做了;如果是不合理的,自然要说“不”了。
二.将客户的新需求安排到后期进行
这是笔者常用的方法,比如某些需求并不是现在必须的,笔者一般会说:
“这需求比较好(先肯定,客户也愿意听的),只是现在我们的重点是……,先保证项目的进度,这样就有更充足的时间来做这个需求了。
你所提的需求我们会在下期版本或升级时考虑”。
这方法既尊重客户,又肯定了他的提议,只是现在的工作重点不是这个,项目的进度又是工作的重中之重,我想没有人会毫无理由地反对的。
三.扩充客户的需求,让其知难而退
对固执的客户有时需要反其道而行之:
首先肯定客户的需求,再扩充客户的需求,然后告诉他要先做哪些,再做哪些,需要多少人手、多少时间才能完成;项目进度要推迟到什么时候,要增加多少人员才行,这样的话要双方老总重新签字才可以开始做。
四.记录成正式文档,告之客户以后再做,并向其主管与直属上司表扬其人其事
需求说明书白纸黑字写的功能点还没有完成,而客户新提的合理需求点也还没有完成,却可以将项目验收,这在国内的项目经理中应当是不会太多的。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 成本 估算