软件项目管理的成功原则
1平衡原则在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了做什么,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。
如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹多快好省四个字,多快好省,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。
多:需求越多越好吗?软件系统实施的基本原则是全局规划,分步实施,步步见效,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的80-20原则,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。
快:真能快起来吗?快是用户、软件开发商都希望的。
传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。
但是快不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。
软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产式的精神鼓动就可以短期完成的。
省:省到什么程度?一分钱一分货,这是中国的俗话,他是符合价值规律的。
甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。
2高效原则在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈,产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则,对项目的管理需要从几个方面来考虑:要选择精英成员目标要明确,范围要清楚沟通要及时、充分要在激励成员上下工夫3分解原则化繁为简,各个击破是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高,参与的人员越多,需要协调沟通的渠道越多,周期越长,开发人员也容易疲劳,将大项目拆分成几个小项目,可以降低对项目管理人员的要求,减少项目的管理风险,而且能够充分地将项目管理的权力下放,充分调动人员的积极性,目标会比较具体明确,易于取得阶段性的成果,使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB,该项目前期投入了5人做需求,时间达3个多月,进入开发阶段后,投入了15人,时间达10个月之久,陆续进行了3次封闭开发,在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整,项目组成员的压力极大,大家疲惫不堪,产品上市时间拖期达4个月。
项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做,进行阶段性版本化发布,以缓解市场上的压力,减少项目组成员的挫折感,提高大家的士气。
4实时控制原则在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。
作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用紧盯2字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。
正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。
我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精神要...
几个项目管理软件的比较
1、项目管理软件主要是看公司的需求来决定,不要人云亦云。
不以公司的角度考虑的做项目管理软件都是刷流氓。
2、国内很多项目管理软件商都是工程类型的项目管理软件,比如邦永科技,建文等,在研发项目管理软件上不涉及或者不做。
3、相对来说一直做研发类型的项目管理软件,比较早的是捷为科技的iMIS-PM集成项目管理软件,其他商家价格上有优势,功能这块有待商榷。
4、用友,金蝶也做项目管理软件,但是都是后来做的,专业程度上其实不太擅长。
请从软件项目管理角度回答问题某软件公司出现的甲方乙方项目管理问...
一、问题在于合同缔约时未确认需求(即客户所要实现的功能,可由软件公司总结、客户确认)。
所以,在未确认需求的前提下,客户的任何一个工作人员每次提出新的需求,在软件公司未实现之前,都是没有完成功能,无法验收。
换言之,这是一个永远无法结束的工程。
二、要解决这个问题,1、必须以书面形式回顾过往的缔约史,总结双方对需求认识的差异,形成《谅解备忘录》;2、必须双方坐下来坦诚面对问题,确定现在的需求,并且约定一旦发生新的变更将增加费用并订立新增条款。
希望我的回答能够帮助到你。
敬请采纳。
工程甲方项目管理的职责和作用是什么
根据所处角度(业主、PMC、监理、总承包商、分承包商、供应商)不同,工程管理的职能重点也不同。
其共性职能是:为保证项目在设计、采购、施工、安装调试等各个环节的顺利进行,围绕“安全、质量、工期、投资”控制目标,在项目集成管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理等方面所做的各项工作。
作为甲方,软件项目需要成立PMO项目管理办公室吗?
项目组的范围界限可以有三种划分:1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员,包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员;2、包括客户方项目经理、业务需求提出人和测试人,包括开发商具体负责该项目开发的人员;3、仅包括开发商具体负责该项目开发的人员。
大部分人在思想上可以接受范围1,而在实务中接受的是范围3。
而我个人认为项目经理,特别是开发商方面的项目经理应该采用的是范围2。
对项目组范围理解不同,将影响项目经理对工作的处理方式,范围1实际上是很虚的,在项目管理实务操作中没有太大的意义;而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来,也就是所谓的甲方、乙方。
在这种对立的前提下处理项目的分歧和矛盾,效果肯定要打折扣。
而按范围2来理解,在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点,从而拆除双方之间的障碍,达到相互信任、相互尊重、共同协商解决问题的良性氛围,以达到降低项目外部风险的目的。
当然,这样就增大了项目经理工作的难度,但对项目的成功则是很重要的。
我建筑行业最常用的项目管理软件有哪些
1还可以,对于刚毕业的人来说是个不错的赚钱和社会锻炼学习的机会。
2晋升啊,这个圈子其实很小,你的成绩圈内人士都会知道的(包括好的与不好的)。
3看你的想法了,可以考的很多,你自己可以去问问,主要是看你想向什么方向发展。
4不容易,毕竟隔行如隔山,你干什么其实都一样,你最后赚到的是金钱、经验和人脉。
其中人际关系是在学校得不到的啊。
请用软件项目管理角度分析,某软件公司一个大型项目进度失控的原因...
这问题刚回答过,怎么没提示?重新提交如下:1、进度失控分析:任务本身估算出现偏差,WBS本身存在问题;项目需求偏移也有可能,毕竟项目中需求把控是影响进度的另一大诱因;进度控制松紧不一致在项目进行到一半时常常才发现时间不够用,进度表经过调整后,谁知道没过多久进度表滞后又来了。
原因在于项目开始时前期太过拖沓,导致进度远远落后于进度表;项目组组建方面一定有问题;项目是各级一把手工程,既然是大型项目,则一定要构建好三层或多层项目组架构;项目沟通计划未得到有效管理:例会、周报、月度进度会等;干系人管理不到位;拖期后未及时采取措施,实施变更加强,以至于分工存在混淆,项目工作拖拉,难以持续;进度控制循环未建立,其包括:(1)执行计划的事前进度控制,体现对计划、规划和执行进行预测的作用;(2)执行计划的过程进度控制,体现对进度计划执行的控制作用,以及在执行中及时采取措施纠正偏差的能力;(3)执行计划的事后进度控制,体现对进度控制每一循环过程总结整理的作用和调整计划的能力;项目监控及应急机制未真正建立;2、下步行动计划:分析存在问题并解释下步安排计划,向公司高层申请项目暂停;(可选)详细了解项目进展状况,写出项目执行报告及总结;明确项目目标,锁定需求,避免无休止的变更;重新规划项目组成员;建立项目高层委员会;执行项目过程控制机制,重新订立项目沟通汇报秩序:周报、月报等,明确高层分工;制定新的项目执行主计划,重新做项目WBS;重新制定奖惩制度;关键干系人和各级一把手都要缜密考虑;如果需要赶工,制定赶工计划与所需资源,制定成本预算报批;申请项目变更;重新召开项目动员会,请一把手出面造势,稳定人心,措施发布,切中要害;项目赶工……3、当然,如果不得已需要有人承担责任,而项目经理要被撤换,则需要制定好交接程序;