软件项目管理的成功原则
1平衡原则在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了做什么,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。
如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹多快好省四个字,多快好省,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。
多:需求越多越好吗?软件系统实施的基本原则是全局规划,分步实施,步步见效,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的80-20原则,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。
快:真能快起来吗?快是用户、软件开发商都希望的。
传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。
但是快不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。
软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产式的精神鼓动就可以短期完成的。
省:省到什么程度?一分钱一分货,这是中国的俗话,他是符合价值规律的。
甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。
2高效原则在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈,产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则,对项目的管理需要从几个方面来考虑:要选择精英成员目标要明确,范围要清楚沟通要及时、充分要在激励成员上下工夫3分解原则化繁为简,各个击破是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高,参与的人员越多,需要协调沟通的渠道越多,周期越长,开发人员也容易疲劳,将大项目拆分成几个小项目,可以降低对项目管理人员的要求,减少项目的管理风险,而且能够充分地将项目管理的权力下放,充分调动人员的积极性,目标会比较具体明确,易于取得阶段性的成果,使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB,该项目前期投入了5人做需求,时间达3个多月,进入开发阶段后,投入了15人,时间达10个月之久,陆续进行了3次封闭开发,在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整,项目组成员的压力极大,大家疲惫不堪,产品上市时间拖期达4个月。
项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做,进行阶段性版本化发布,以缓解市场上的压力,减少项目组成员的挫折感,提高大家的士气。
4实时控制原则在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。
作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用紧盯2字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。
正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。
我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精神要...
项目管理软件有用吗?
楼上有两位已经把项目管理软件的重要性说的比较清楚了,就我个人理解,简单来说就是让管理者轻松地掌握项目的进度,而具体的负责人员也可以明白自己在特定时间段内该完成的内务。
从上到下都知道自己在干嘛,该干成什么样子,什么时候该完成。
项目管理顾名思义是对项目进行管理,所以任何有项目需要管理的企业都需要这种软件的。
所以也就没有特定性质的什么企业需要,有项目就用项目管理软件罗。
楼上的都没有进行品牌推荐,我还是推荐一下吧,我是最近才开始用这家的,虽然不知名但软件和价格都很实在,物美价廉谁都喜欢吧~所以让大家知道也不是坏事。
全程软件的PM任务项目管理软件。
就是这个了,其他的太贵我们都没考虑,所以只推荐这一个。
希望有帮助到你~
软件项目进度管理怎样当进度发生偏差时,如何调整项目的进度?
及时制定实施调整与补救措施。
调整的目的是根据实际进度情况,对项目计划作必要的修正,使之符合变化的实际情况,以保证项目目标其顺利实现。
由于初期编制项目计划时考虑不周,或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑,计算调整后的各时间参数、关键线路和工期。
进度落后的情况下,有几种措施来弥补,如加人、加班、加激励等等,这些都是增加资源而又未必会见效的方法。
根据Brooks原则,在某些项目进度延迟的情况下增加人手,有可能会使项目的进度更加延后。
因为对于新加入本项目的员工来说,对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加,可能会使项目的工作效率急剧下跌。
而加班造成的疲劳会再次使工作效率降低。
增加激励会造成工作成本却不断的向上攀升。
这些措施并不是完全不可取,而是项目经理要考虑适度原则。
最好是要全面分析项目进度延迟的原因,如果确实是不合理的项目交付时限要求,就应当通过沟通变更为合理的项目时限要求,以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响,最终导致项目最终的失败。
否则应从技术、团队成员心态、环境等方面查找原因,找到提高效率、加快进度的方法。
如何做好软件项目的验收
项目验收是公司乃至每个项目成员都想要的结果,一旦验收对公司来说就是,可以收验收阶段的款了,不需要再投入那么多人力到项目当中,项目终于可以告 一段落,大家都可以轻松一下了。
项目验收是一系列细致工作完成到位的结果,而不是某一点的成功或某个人能力就可以促成的事情。
一个项目的验收,一般是由一 系列验收准备工作组成的。
如果我们在最终验收前,已经将很多阶段的工作细化并得到认可执行,那么项目验收也就是水到渠成的事情了。
首先我们要明确进入验收的前提。
很多人都认为只要我们完成了合同中规定的内容,完成了需求规格说明中规定的工作,并且按合同试运行了几个月,应该就可以验收了。
就可以拿着合同或技术协议与客户谈论验收的相关事宜了。
但 实际上客户往往不同意在此时验收。
他们的判断往往不是招标书、合同、技术协议、需求规格说明书等文档。
其实这些文档无论做得如何细致,对用户而言并没太大 的参考价值。
客户关心的是他们的业务是否真地在系统中运作,并且运行良好,并以此作为检验项目验收的标准。
当然有的项目也可以通过商务运作,在业务实现不 太好的情况下验收。
1、在项目实施过程中注重里程碑的确定,制定阶段性目标如果要做好一个项目,完成项目的验收条件,主要还是以业务是否可用作为衡量的。
不是一定得实现所有用户的需求(这里指的是口头上的需求,如果落实到文字上的还是要实现的),也不是只有将一些所谓的技术难点解决用户就会同意验收,而是我们可以完成一定的阶段应用业务目标。
我们从进行需求调研的时候就要主动控制项目的边界,将一个一个业务流根据客户方的实际情况合理组织实施顺序,形成我们项目实施计划中的里程碑点,明确达到里程碑点的条件,并得到双方一致正式认可。
没有双方高度达成一致的里程碑认可,也就是没有项目目标约定,没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标,导致计划不可控制,更谈不上验收。
很多人希望通过详细的系统需求规格说明书来定义项目要实现的内容和业务目标,这是很有必要的,但需求规格说明书得到认可并非是通过用户审核就可以的结果,应该想办法让用户一起参与到需求规格说明书的制定过程中来,变成用户自己推导出来的业务实施目标,未来才不容易变形。
2、积极主动地与客户进行沟通沟 通的作用对于高管是让他们清楚我们一直按照项目目标前进,每个阶段工作进展是否顺利,影响项目正常运做原因是什么,需要哪些资源帮助。
和高管沟通比较多的 话,第一个好处是高管经常听汇报就知道项目进展程度,可以安排反馈检查,看是否具备我们所说的进展,这样一旦认可了各个阶段目标后,最终要求高管签字确认 也就顺理成章了。
给高管汇报技巧就是简洁明了,真实客观,有理有据分析问题,提出对策建议请其决策即可。
中层往往是项目主要的推动力量和实际执行者,也往往是对具体业务需求最主要的要求者,他们对企业实际运做过程最清楚,提出要求最具体,而且项目验收与否没有中层的同意往往也是不太容易做到的。
和基层的沟通主要体现对最终用户的关怀,定期主动和最终用户沟通,消除一些怨气,让用户能坚持用下去,这个时候我们往往发现很多用户真的是非常好相处,尽管软件还有很多值得改进的地方,但他们一旦认可我们团队,反而会尽心尽力帮助我们推动项目的进行。
目前我们公司一般要求每个项目经理在项目进行中都要填写详尽的项目月报,反映项目的进度,与计划的偏差,完成的项目内容,投入人力,目前项目存在的问题,以及预计项目下月的进度等等。
将进度月报交部门负责人、项目管理中心、总经办审阅。
类似地也要制定针对客户的月报甚至是周报,将相关的信息反应到客户方的负责人,及相关高层。
可以先发邮件,然后还要电话落实收到并口头简要汇报,特别是高管层,千万不要以为发了就等于别人会去看,一定要口头跟进汇报一次,保证客户各方面负责人对项目进展做到心中有数。
在 项目的过程中,我们也需要注意平时做人的积累,比如要做到讲诚信,讲原则。
主要是三条:1)做不到的事情千万别随意承诺;2)承诺的事情一定要努力做 到;3)每次做到的事情都进步一点点。
按这三条做事,即使在系统的使用过程中总会有这样或那样的一些不方便,用户也会慢慢接受稍微长一点的响应周期,也会 用更多积极性眼光看现在的问题,也相信问题一定有人响应,也一定可以得到解决。
进而使我们和客户之间形成一种较为和谐的关系。
3、写好备忘录和问题跟踪记录在一个漫长项目周期中,很多工作做了也就做了,认可了也就认可了,时间一长也就忘记了很多承诺和约定,到了验收的时候就可能重新翻出来,这种事情很多人可能都经历过,明明说可以先不做的内容最终验收的时候又成了必要条件。
每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。
下次工作则根据前次备忘录的双方约定继续进行,保障项目在每次工作基础上不断前进,并用备忘录约束双方的行为。
同 时我们建议在收集项目出现的各种问题时,采用问题跟踪记录表的形式,这样可以一目...
软件项目招标的方式主要有哪些
(1)招标方式 按竞争开放程度,招标分为公开招标和邀请招标两种方式。
1)公开招标。
属于非限制性竞争招标,这是一种充分体现招标信息公开性、招标程序规范性、投标竞争公平性,大大降低串标、抬标和其他不正当交易的可能性,最符合招标投标优胜劣汰和“三公”原则的招标方式,常用的采购方式。
2)邀请招标。
属于有限竞争性招标,也称选择性招标。
邀请招标适用于因涉及国家安全、国家秘密、商业机密、施工工期或货物供应周期紧迫、受自然地域环境限制只有少量几家潜在投标人可供选择等条件限制而无法公开招标的项目,或者受项目技术复杂和特殊要求限制,且事先已经明确知道只有少数特定的潜在投标人可以响应投标的项目,或者招标项目较小,采用公开招标方式的招标费用占招标项目价值比例过大的项目。
按照标的物来源地划分可以将招标划分为:国内招标,包括国内公开招标、国内邀请招标;国际招标,包括国际公开招标、国际邀请招标。
国际招标文件的编制应遵循国际贸易准则、惯例。
(2)招标方法和手段1)两阶段招标。
适用于一些技术设计方案或技术要求不确定或一些技术标准、规格要求难以描述确定的招标项目。
第一阶段招标,从投标方案中优选技术设计方案,统一技术标准、规格和要求;第二阶段按照统一确定的设计方案或技术标准,组织项目最终招标和投标报价。
2)框架协议招标。
适合于重复使用规格、型号、技术标准与要求相同的货物或服务,特别适合于一个招标人下属多个实施主体采用集中统一招标的项目。
招标人通过招标对货物或服务形成统一采购框架协议,一般只约定采购单价,而不约定标的数量和总价,各采购实施主体按照采购框架协议分别与中标人分批签订和履行采购合同协议。
3)电子招标。
与纸质招标相比,将极大提高招标投标效率,符合节能减排要求,降低招标投标费用,有效贯彻“三公”原则,有利于突破传统的招标投标组织实施和管理模式,促进招标投标监督方式的改革完善,规范招标投标秩序,预防和治理腐败交易现象。
特别对于一些技术规格简单、标准统一,容易分类鉴别评价,或需要广泛征求投标竞争者的招标项目,电子招标的效率优势更加明显。
工程造价要用的软件有哪些??
展开全部 我工程造价毕业4年多了,我来说些吧。
毕业了,大体可以去的有甲方、施工单位、咨询单位三种。
做审计和做甲方覆盖面广,做施工单位一般专业会被局限一点,因为施工单位要么做装饰,要么土建,要么幕墙等等,专业划分多样,但是可以深入的理解这些,怎么说呢,有机会接触现场,也不错。
前途这个东西不好说,喜欢建筑热爱这行的才不在乎前途,反正饿不死;但是也不要过于担心,刚开始工资不是很高,但是坚持下来能独立负责的时候就会高很多,但是坚持下来的不多,我当初的班级50人,现在在做造价的也就20人吧。
软件使用:CAD,Office、广联达,预算之星,鲁班等等存手打字,希望能帮到你。
...
在软件公司做第一个项目需要注意哪些?
在公司 就算你不是新去的 也要认真再认真何况你是新去的 那就要更加的认真 做玩了 要多检查几遍 你的同事都是很有经验的人 你可以多问问他们 一些需要注意的地方我以前在一家韩国企业工作的时候 我作完的东西 要是那边检查员检查出问题 我这就是白做 不记工资
施工单位工期索赔
施工单位工期索赔:1、不可抗力因素2、因业主、设计原因造成工期损失3、还要看合同对工期的具体约定对施工项目工期索赔的探讨 【摘要】施工进度管理中,索赔是一项不可避免的工作,工期索赔又因其特殊微妙的意义使得做好这项工作就更需要技巧。
本文以消防特勤站工程的工期索赔为例,提出了几点看法。
【关键词】工期索赔 施工进度计划 索赔意向书 索赔报告 建筑工程项目由于建设周期长、涉及的经济关系和法律关系复杂、受自然条件和客观因素的影响大,导致工程的实际施工情况与招标投标时的工程情况相比往往会有一些变化,这或多或少都会对项目施工工期有所影响。
因而会涉及到工期索赔工作。
一、 工期索赔的必要性与概念 随着建筑市场的发展,施工项目管理已成为施工企业经营管理体制的核心,项目索赔工作是反映项目管理水平的一个重要方面,索赔工作的好坏直接影响到工程经济效益。
这里仅论述施工项目的工期索赔。
工期索赔是指承包人在合同实施过程中,由于非承包人责任的原因而导致施工进程延误,要求批准顺延合同工期的索赔。
它形式是对权利的要求,以避免在原定合同竣工日不能完工时,被发包人追究拖期违约责任。
一旦获得批准合同工期顺延后,承包人不仅免除了承担拖期违约赔偿费的严重风险,而且还可能因提前工期得到奖励,最终仍反映在经济收益上。
工期索赔按索赔性质又可分两类:一类是工程延误索赔,是因发包人未按合同要求提供施工条件,如未及时交付设计图纸、施工现场、道路等,或因发包人指令工程暂停或不可抗力事件等原因造成工期拖延的,承包人对此提出索赔;另一类是工程变更索赔,由于发包人或监理工程师指令增加或减少工程量或附加工程、修改设计、变更工程顺序等造成工期延长,承包人对此提出索赔。
二、消防特勤站工程工期索赔情况 秦山核电三期项经部在核电三期建设过程中曾对BOP工程的多个项目进行过工期索赔工作(水处理厂房由于施工场地移交延误,工期索赔78天;次氯酸钠厂房施工由于场地及施工运输道路移交延误,工期索赔3个月),以民用建筑中的消防特勤站工程最为典型。
消防特勤站及其室外配套工程于2003年9月16日开标,合同签订日期为2003年9月22日,合同竣工日期为2004年4月28日,整个合同的有效工期为220天。
施工期间由于各种主观、客观因素的影响,最终我们于2004年7月28日完工移交,其中索赔成功工期70天。
在这项工程的工期索赔过程中,我们暴露出许多问题,很多时候我们都是处于被动状态。
最为明显的是以下几点: 1、工期索赔工作与现场施工分离,现场施工人员索赔意识不强,以致错过了索赔的最佳时机。
在基础开挖时发现土质状况与设计资料不一致,有大块的岩石需要处理,增加了工程量。
但施工人员没有及时发出索赔报告,仅到后期因整个进度情况与计划偏差较大时才将此问题提出,这对索赔工期的准确度与可信度打了折扣。
2、对工期索赔工作认识不足,重视不够,认为与效益联系不大。
在进行索赔资料收集时发现,与费用有关的施工记录较为详细,但有关业主与监理的口头施工指令时间却记载不详,多数仅靠头脑回忆,“大概”,“可能”是常被用到的。
3、索赔人员对现场情况了解不及时,不准确,仅充当文笔处理工作,使索赔工作的力度不够。
4、索赔工作未形成固定成熟的工作程序开展执行,也是一大问题。
若未得到领导通知,索赔工作停滞不前,索赔人员不知如何人手。
三、工期索赔的相关因素与过程 很显然,索赔工作不是单一独立的行为,它应与其它施工管理行为协调、一致。
怎样解决这些问题,是需要我们所有施工管理人员共同思索、共同努力的。
人个认为做好索赔工作有几个重要的相关因素: ★ 科学严谨的施工进度计划是前提 编制施工进度计划是一个集专业知识、实际施工经验、先进计算机软件操作于一体的脑力劳动,它需要有比较完备的基础数据:了解工程施工期限、施工顺序、主要施工方法。
计划是基于通常状态下的施工时间安排,是根据招标文件中对工程节点的时间要求,对整个施工过程进行合理安排,只有通过计划确定了关键路径,才能为索赔提供依据,工期索赔是要对关键路线进行分析比较才能发现的。
在我们进行特勤站的投标计划编制过程中,为了能在众多承包商中竞争取胜,对业主提出修改部分计划的苛刻要求做出了妥协,如缩短工程施工准备时间,并将准备工作放在工程开工前完成,而实际情况是该工程定标时间较晚,合同一经签定便立即开工,准备工作在工程正式开工后才陆续完成,致使工程刚刚开工就存在滞后的情况。