项目估算与计划不是一般的难(上)

 摘要:

  估算、计划、计划跟踪是项目管理的主要工作,难度之高超乎你想象!光靠学习项目管理理论难以管好项目,而往往真能管好项目的都是那些在具体项目中打滚出来的实干人士。本文将会让你全面学习项目估算、计划、计划跟踪的知识,体验实际项目管理的难度,学到提高项目管理水平的一些方法。本文有点长,麻烦你慢慢阅读了!

  大纲:

  1、从建筑工程说起
  2、估算要估啥?
  3、估算如何做出来?
  4、计划有什么内容?
  5、计划是如何做出来的?
  6、如何跟踪计划?
  7、优秀项目经理是怎样炼成的?

  正文:

  从建筑工程说起

  大家都喜欢用建筑工程与软件工程做比较,但我们常常所说的建筑工程只是指建筑施工部分,而不是一个完整的建设项目。我们常常将施工项目管理与软件项目管理进行比较,这是不合适的。

  一个完整的建设项目,由甲方提出需求,设计院根据需求设计出图纸,再由造价公司进行估价,然后公开招标,最后由建筑公司承担建设。相对于软件项目,建筑工程有以下特点:

  1、从需求到竣工,经历需求、设计、估价、建设等环节,每个环节由不同专业的公司或人员完成。

  2、每个环节签署不同的合同,每个环节对应不同的乙方。而软件项目从需求到开发完成,基本上是签署一个合同,只有一个乙方。

  3、整个过程可以认为是瀑布型的,需求和设计会在前期确定,后期基本上不会变动。而软件项目就没有这么理想了,需求和设计不断在变。

  4、建筑工程只会采用最成熟的技术,可行性和设计方案要经过反复论证,你看看港珠澳大桥就论证了好多年了。而软件项目往往要采用不成熟的技术,边设计边尝试。

  5、建筑工程的估算是在需求与设计都确定的基础上估算的。而软件项目不确定的东西太多,估算无法一次成型。

  软件项目管理可能是最复杂的一种项目管理,因为软件项目具备这样的特点:

  1)需求、设计不明确。

  2)项目组需要在需求设计不明确的基础上,承担需求、设计、编码、实施等全部工作。

  如果你是这样项目的项目经理,对你来说是多么大的挑战啊!

  建筑行业发展了这么多年,整个建设工程的各个环节已经有很多专业的公司,有很多设计院、造价公司、建筑公司等。而软件行业,几乎很少见到专业的需求分析公司、软件设计公司。这既是软件行业的特点决定的,也是甲方习惯决定的。我们公司在一些项目尝试和客户签署两份合同,第一份合同只做需求的工作,而第二份合同则完成实现与编码,但客户往往不会接受。

  软件项目管理难归难,但我们还是要去面对的,我们应该如何应对软件项目的估算与计划呢?

  估算要估啥?

  很多人问如何才能做好估算?这个问题是问如何正确做事情的问题,而实际上要回答好这个问题,先要回答估算要估算什么内容的问题,也就是什么是正确的事情问题。

  对于估算要区分以下几种情况:

  1、甲方对项目的估算

  甲方想做某个系统,会根据自己对系统的估计以及自己的预算估计出一个价钱。甲方往往不能准确对项目进行估算,项目的价钱往往是来自预算,而所有甲方都是想在有限的预算内办更多的事情。很多项目需要招标,其实重要目的就是希望找出性价比最高的软件公司。

 2、乙方在投标阶段对项目的估算

  作为软件公司,要判断该项目需要多少的成本,然后稍微“放大”成本作为投标价,这样公司才能有利可图。

  然则现实情况很残酷:

  1)需求大多数是不明确的,甚至甲方对项目的期望都没有想清楚,这样软件公司无从估算。

  2)很多招标其实甲方都“隐含”一个预算价,如果软件公司的报价超出这个价钱,你就别想中标了。而这个预算价往往会小于软件公司对项目的估算,让你难以决定这项目做还是不做好!

  这个阶段的估算是最难做的,除了考虑项目实际工作量,还要考虑项目是否要赚钱、客户关系等因素。

  在我们公司,对于已经产品化的项目,估价比较容易,这其实是一个积累的过程。而对于全新的以前没有多少经验的项目,估价其实也是很难做得很好的,我们往往是由项目经验与技术经验都实力雄厚的总经理来“拍脑袋”拍出来的。所谓“拍脑袋”,其实不代表乱猜,是以雄厚的经验和强大的知识为前提的。

  3、项目组开展项目时对项目的估算

  当我们要真刀真枪开干时,项目组需要对项目的实际工作量有充分的认识,并以此为基础来做好项目工作。

  我们常常所说的项目估算问题,就是指这第三种情况,后文我们将重点讲述这种情况。

  项目估算到底要估什么呢?

  项目的成本包括:人工费、差旅费、业务费用、招待费用、采购费用。

  人工费:

  包括项目组各人的薪金,以及公司运作分摊到项目组各人头上的运作成本。公司运作成本包括非项目组人员的人工、场地设备费用、水电通讯费用、人员培训招聘费用、人员闲适成本、研究失败时的成本、商务活动的成本等。

  一般来说,项目组只需要估算出实际的项目工时就可以了,工时再乘以一个折合的人工成本单价就是项目的人工成本了。

  差旅费:项目组成员因项目出差的交通费、住宿费、通讯费、差旅补贴等。

  业务费用:公司领导、销售人员与客户进行商务谈判、联络所花费的费用,例如送礼、回扣等的费用。这笔费用往往还很大呢,不过项目组一般不需要估算这部分费用。

  招待费用:项目组成员因工作需要,和客户相关人员吃饭、娱乐的相关费用。例如:需求调研期间和客户吃饭;项目实施阶段因推动验收和客户一起加班,加班后请客户吃饭。这笔费用一般不会很大,一顿饭一般就是几十到一百多元,一个项目也不会请很多次吃饭。

  采购费用:采购项目所需的软硬费用,如数据库平台、服务器等,如果项目部分内容要外包出去,那还要包括外包的费用。有时候这笔费用会比较巨大,但这些费用都很容易估计。

  以上费用最难估计的就是人工费,人工费我们以工作量来考虑,下文开始我们重点讲解项目工作量的估算。

  如何估计项目的工作量呢?

  简单地说,我们需要将项目的所有工作进行分解,直到每个分解后的工作都能估计出具体的所需时间来。

  那项目的“所有工作”包含什么呢?回答这个问题其实就是回答“估算要估啥?”这个问题了。

  一般情况下,项目工作包括以下内容:

  1、项目前期工作。

  包括商务谈判、技术方案准备、投标准备、前期需求调研、前期技术研究等工作。当你接手项目的时候,这些工作往往已经做了,你估算项目工作量时,不要忘记这些已经花费的工作量。

2、商务方面的工作。

  从客户开始有意向做这个项目,一直到项目验收、维护,整个过程中都会贯穿商务活动。前期的商务活动有商务谈判、投标准备、合同签署等,而签订合同后的商务活动有项目请款和催款、促进验收等。某些商务活动属于灰色地带,如请客、送礼等,这些往往是花费巨大的。一般来说我们不需要估算灰色地带的商务活动,灰色地带的商务活动公司的高层会考虑的了,但我们需要对正常的商务活动进行估算。

  3、需求调研方面的工作。

  需求调研是一个“反复”的过程,一般来说能在前期确定80%已经是很了不起的成绩。

  需求调研的工作量一般由三部分组成:前期调研的工作量,后期需求细化的工作量,后期需求变更的工作量。

  前期调研的工作包括:项目组内部讨论、确认,与客户讨论、确认需求,编写需求规格说明书及组织评审等工作。

  需求细化是指对之前已确定需求的进一步具体化、优化或轻微调整,如:界面细节的确认、各业务概念的具体化等。需求细化一般是可预见可估计的。

  需求变更是指对之前已确认需求的“否定”,变更的原因主要有两种情况:一是之前需求调研工作没有能做好,理解错客户的真正意图或者是遗漏重要的需求;二是客户业务情况发生变化,与之前情况已经不同。第一种情况应该尽量避免,而第二种情况一般是难以估计的。需求变更时需重新估算,和客户签订需求变更协议。

  我们一般会充分估计前期需求调研工作量以及需求细化工作量,对于需求变更则暂不考虑,因为一旦变更我们会和客户确认需求变更的费用。但有些项目有很特殊,项目报价中预留了少量的需求变更费用,这时估算中就需要适当考虑需求变更了。

  4、软件设计方面的工作。

  不少项目为了“赶”进度,设计文档很少,然则项目真的很简单、不需要仔细考虑设计的情况是非常少的!

  软件设计工作包括:

  1)系统架构设计。

  2)技术方案选择。

  3)关键模块设计。

  4)数据库设计。

  5)用户体验设计。

  以上内容具体项目可以有所取舍,但不可能全部都不用考虑。

  另外不要忘记了以下两方面的工作:

  1)各类设计工作产品的讨论、确认、评审工作。

  2)设计细化与优化工作。设计是需要持续改进的,不要忘记这些工作。

  5、编码方面的工作。

  要注意不要遗漏代码返工、代码评审、代码调试、修复缺陷的工作量。

  需求、设计没有做好,编码质量不过关,这些会严重增加代码返工、代码调试、修复缺陷的工作量。代码首次完成的时间如果是100小时,那么后面代码调试、修复缺陷等所需要的时间可能是200小时以上,往往我们估算时只考虑了前面的100小时。

  6、测试方面的工作。

  测试工作包括测试计划、测试用例、测试文档评审、测试环境准备、测试数据准备、执行测试、回归测试等内容。

  软件测试一般要经历多轮,我们估算往往只考虑了第一轮,就好象软件只需要测试一回就不用再测试了。而测试环境准备、测试数据准备这些工作也很容易在估算时“忘记”了。

7、实施方面的工作。

  实施工作包括实施计划、实施方案的准备,编写管理员手册、用户手册,熟悉系统,搭建实施环境并进行演练,在客户现场安装、部署、调试系统,培训客户,协助系统上线,推动验收等工作。

  我们公司通常的做法是:

  1)系统在客户处部署后,会推动客户进行初步验收,初验标准是系统的所有功能跑就可以了。初验成功,客户需要支付相应的项目款项。

  2)初验后要协助客户让系统正式上线,让客户真正用上这套系统,推动最终验收。

  影响终验主要有两个因素,一个是客户在使用系统过程中会提出各式各样的问题,如果在需求范围内应该都予以满足;而另外一个影响因素是客户会因为各种各样的原因推迟使用系统,或者是使用不充分,让项目终验遥遥无期。估算时需要充分考虑这两个影响因素。

  8、维护方面的工作。

  项目终验后,一般都要提供半年到一年的维护服务,维护器后项目还会有最后一笔款项。

  维护期比较长,事情繁杂,一个不小心就很容易估算不足。

  维护的工作一般有:

  1)用户培训;

  2)协助客户录入资料;

  3)修复被破坏的数据以及数据库;

  4)修改客户或内部发现的软件缺陷;

  5)代码重构,提高部分程序的性能与可靠性;

  6)修改一些界面文字或显示风格;

  7)回答客户反馈的一些安装与操作疑难问题;

  8)提供合同中所要求的其它特殊软件维护服务。

  在维护期,往往还需要发布数个小版本来解决客户的问题。

  9、项目管理方面的工作。

  项目管理工作主要有编制项目计划、持续更新项目计划、跟踪计划执行、各种工作协调、指导项目组成员完成工作等等。

  项目管理工作量一般占整个项目工作量的10-20%,项目不明确的东西越多、项目组成员水平越不足、项目组成员之间工作磨合度越不好,管理工作量就越大。

  项目管理在项目进行整个过程都需要持续进行,一般来说前期工作量会比较大,版本发布前后阶段工作量也会比较大。项目管理前期工作抓得紧抓得好,会大大减轻后期的工作量。

 10、配置管理方面的工作。

  什么叫配置管理?简单说就是对工作产品的管理,包括对各类文档、各种记录、代码、数据库、脚本、安装程序、组件等等的管理。

  软件生产过程的工作产品可分为两类:中间产物和最终产物。

  中间产物有:

  1)工程类:需求文档、设计文档、测试方案、代码、数据库脚本、数据库、测试脚本等。

  2)管理类:开发计划、测试计划、培训计划、采购计划、实施计划等。

  3)记录类:会议记录、邮件、缺陷等。

  最终产物是指最终会交付给客户的东西,一般有:组件、安装程序、数据库、用户手册、管理员手册等。

  针对不同的工作产品应采取不同的针对性管理办法,很多公司会制定单独的配置管理计划。

  11、质量保证方面的工作。

  严格来说,质量保证是靠项目组全体来保证的,这里所说的质量保证是“狭义”的质量保证,是指:要确保项目组按照既定的规定、过程、标准来工作,需按照既定的格式要求产出相应工作产品。

  对于以上十一点,实际项目估算中往往出现这样的问题:

  1)忘记包含项目前期工作的工作量。

  2)没有考虑商务、维护、配置管理、质量保证方面的工作。

  3)需求调研、软件设计、编码、测试、实施方面的工作估计过少。

  4)项目管理方面的工作量估计不足。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-23 20:06:48

项目估算与计划不是一般的难(上)的相关文章

项目估算与计划不是一般的难(下)

计划是如何做出来的? 一.要站在战略的高度. 有时候我会问项目经理这样的问题: 1.项目预算是多少?(注意前文提到的预算与估算的差别哦,预算是指公司打算花多少钱做这个项目.) 2.合同要求在什么时候验收? 3.验收一次进行还是分初验.终验? 有些项目经理答不出了,他们没有去关注合同中的要点,也没有向高层取得项目的战略指示. 一般情况下,在项目初期,你应该搞清楚这些战略层面的内容: 1.合同价钱是多少,公司打算赚多少钱? 2.公司为什么要做这个项目?想赚钱?想维持客户关系?想积累业务和技术?本项目

项目估算与计划不是一般的难(中)

估算如何做出来? 这里开始所说的估算,全部都是指项目组对项目的估算,这个估算的目的是用来指导项目的具体工作. 有很多种估算办法,大致可以分为两类: 1.先得到软件规模,然后根据公司实际的生产率由软件规模导出工作量. 2.直接得到工作量. 第一类的常见方法有:功能点法.代码行法,第二类的常见方法有Delphi估算法.微软的由底而上估算法. 什么是软件规模?我们先看看一个搬砖头的估算. 假设有1000块砖头,它们的大小和重量一样,每名工人每天能搬100块砖头,于是我们可以估算到需要10人日来搬完.1

敏捷项目估算之故事和点数

引言 当你要雇一位漆工来装饰你的房子,或者一位修理工来修你的车时,你会要他们先给个估算,对吗? 你需要知道大概会花多少钱,需要多长时间.这是常识. 然而经验告诉我们什么?初始的估算和最终的账单有多大差距?很有可能漆工会发现有松动的石膏需 要铲除,墙面需要修补和重新粉刷:修理工一定会发现要让你车子重新上路还有些其它的问题要解决. 在1951年的<纽约客>杂志中有这样一幅漫画,Syd Hoff画了一个修理工对他的客户说: "当然,那不过只是个估算,实际的花费一定会更多" 如果漆

紫金-天津北辰盛景湾项目集合资金信托计划拟融资不超迿亿元

2014广朿3日消息,紫金-天津北辰盛景湾项目集合资金信托计划拟融资〿/p> 融资主体为天津景浩投资有限公司,募得资金用于天津北辰盛景湾项目C1地块开发建设,受托人为紫金信托有限责任公司.信托总规模不超过3亿元,信托期陿4个月,预期年化收益率_00万≤认购金额<300万,10.3%/年:300万≤认购金额_1.5%/年.天津景浩将位于天津北辰盛景湾项目中的C1.C3.C4地块土地.C1地块圿a target="_blank" href="http://zdb.pe

项目沟通管理计划

沟通计划包括决定项目涉及人的信息和沟通需求:谁需要什么信息:什么时候需要:怎么获得.虽然所有的项目都需要沟通项目信息,但信息需求和传播方式差别很大.确认涉及人的信息需求和决定满足需求的适当方式是项目获得成功的重要因素. 对于大多数项目,沟通计划的大部分工作作为项目前期阶段的一部分来完成.然而本过程的结果在项目进行中应时常被复查和修订(如有需要)以确保持续的应用性. 沟通计划常常与组织计划紧密联系在一起,因为项目的组织结构对项目沟通要求有重大影响. 沟通计划输入(inputs to communi

索尼育碧计划将《刺客信条》搬上银幕(图)

索尼育碧计划将<刺客信条>搬上银幕 新浪科技讯 北京时间11月8日上午消息,经过长达数月的谈判,索尼影业终于与育碧达成了协议,两家公司决定联手将网游<刺客信条>搬上大银幕.但业内人士却认为,由于育碧对拍片计划干涉太多,<刺客信条>电影版前景不容乐观. 被指越俎代庖 根据这份协议,育碧将负责预算控制.选角.剧本创作.上映日期等绝大部分事宜.这种对拍片计划的控制在好莱坞前所未闻,尤其是一部大制作影片,而<刺客信条>电影版几乎肯定就是此类影片. 据说,在得知协议条

艾伟也谈项目管理,项目经理成长日记(6)——对不上的帐

    中午吃过了午饭,端着杯茶做在休息室里正稍稍休憩.公司内部特别开辟出一个空间,并装修成吧台,高脚转椅,微高的台面和酒吧里面的样子多少有点类似.不少人见过微软.google的office的专修格调,让多少人羡慕而又渴望.其实程序员作为脑力劳动的工作者,有时候我们太需要像作家那样的灵感源泉,所以office的风格或多或少应该尽量给人营造一种比较轻松的环境,这样在轻松的环境中进行高强度的脑力将会尽可能让二者得到一种缓和,从而使质量和效率更为高效. "吃过了?小余."标准的中国人问候的方

同一javaweb项目在同样配置的两台Linux服务器上,一台能正常访问,另一台就报错!

问题描述 同一javaweb项目在同样配置的两台Linux服务器上,一台能正常访问,另一台就报错! java.lang.reflect.InvocationTargetException sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.Delega

web and jmf-WEB项目中导入JMF jar包部署到tomcat上出错

问题描述 WEB项目中导入JMF jar包部署到tomcat上出错 错误信息如下: 解决方案 Eclipse部署Java Web项目到Tomcat出错 解决方案二: 违规访问造成的.换一个低版本的包试试