软件项目管理的成功法则

1 平衡原则
在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。


需求定义了 " 做什么 " ,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。

对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹 " 多快好省 " 四个字, " 多快好省 " ,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。



多:需求越多越好吗?

软件系统实施的基本原则是 " 全局规划,分步实施,步步见效 " ,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据 pareto 的 80-20 原则,企业中的 80 的问题可以用 20 的投资来解决,如果你要大而全,对不起,你那 20 的次要问题是需要你花费 80 的投资的!而这一点恰恰是很多软件用户所不能忍受的。



快:真能快起来吗?

" 快 " 是用户、软件开发商都希望的。传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。但是 " 快 " 不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产 " 式的精神鼓动就可以短期完成的。



好:什么是好软件?

软件系统的 " 好 " 字是最难定义、最难度量的。 " 让用户满意 " 是最高目标,你可以做到,但是资金的投入与时间的投入用户能否接受� ?



省:省到什么程度?

" 一分钱一分货 " ,这是中国的俗话,他是符合价值规律的。甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。



正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。

企业实施 it 系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。

2 高效原则
在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈, " 产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣 " ,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。

基于高效的原则,对项目的管理需要从几个方面来考虑:

& oslash 要选择精英成员

& oslash 目标要明确,范围要清楚

& oslash 沟通要及时、充分

& oslash 要在激励成员上下工夫



3 分解原则
" 化繁为简,各个击破 " 是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。

项目越大对项目组的管理人员、开发人员的要求越高,参与的人员越多,需要协调沟通的渠道越多,周期越长,开发人员也容易疲劳,将大项目拆分成几个小项目,可以降低对项目管理人员的要求,减少项目的管理风险,而且能够充分地将项目管理的权力下放,充分调动人员的积极性,目标会比较具体明确,易于取得阶段性的成果,使开发人员有成就感。

作者 ( 作者: e 剑 来源:赛迪论坛 ) 主管过的一个产品开发项目代号为 sb ,该项目前期投入了 5 人做需求,时间达 3 个多月,进入开发阶段后,投入了 15 人,时间达 10 个月之久,陆续进行了 3 次封闭开发,在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整,项目组成员的压力极大,大家疲惫不堪,产品上市时间拖期达 4 个月。项目完工后总结下来的很致命的一个教训就是应该将该项目拆成 3 个小的项目来做,进行阶段性版本化发布,以缓解市场上的压力,减少项目组成员的挫折感,提高大家的士气。

4 实时控制原则
在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用 " 紧盯 " 2 字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。

上述的方法中对项目经理的个人能力、牺牲精神要求是很高,我们需要有一种进行实时控制项目进度的机制,依靠一套规范的过程来保证实时监控项目的进度。如在微软的管理策略中强调每日构建 " ,这确实是是一种不错的方法,即每天要进行一次系统的编译链接,通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。

实时控制确保项目经理能够及时发现问题、解决问题,保证项目具有很高的可见度,保证项目的正常进展。

5 分类管理原则
对于不同的软件项目其项目目标差别很大,项目规模也是不同的,应用领域是不同的,采用的技术路线差别也很大,因而,针对每个项目的不同特点,其管理的方法、管理的侧重点应该是不同的。就像古人讲的, " 因材施教 " , " 对症下药 " 。对于小项目你肯定不能象管理大项目那样去做,对于产品开发类的项目,你也不可能象管理系统集成类的项目那样去做,项目经理需要根据项目的特点,制订不同的项目管理的方针政策。如,下表是作者为一家应用软件公司制订的项目管理的方针:

在该案例中,将项目分成了订单类项目与非订单类项目,非订单类项目是指由公司根据市场的需求开发一个标准产品的项目,而订单类是指针对某个具体的客户定制软件的项目,订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类,非订单类根据估算的工作量的大小也分成了 a 、 b 、 c 三类,估算的工作量超过 720 人天的为 a 类,超过 360 人天的为 b 类, 360 人天以下的为 c 类。不同类的项目管理的侧重点是不同的,从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑,以确保管理的可行性。

6 简单有效原则
项目经理在进行项目管理的过程中,往往会得到开发人员这样的抱怨 " 太麻烦了,浪费时间,没有用处 " ,这是很普遍的一种现象。当然这样的抱怨要从 2 个方面来分析,一方面从开发人员本身可能存在不理解,或者逆反心理的情况,另一方面,项目经理也要反思:我所采取的管理措施是否简单有效?搞管理不是搞学术研究,没有完美的管理,只有有效的管理,而项目经理往往试图堵住所有的漏洞,解决所有的问题,恰恰是这种理想,会使项目的管理陷入一个误区,作茧自缚,最后无法实施有效的管理,导致项目的失败。

7 规模控制原则
该原则是和上面提到的其他原则相配合使用的,即要控制项目组的规模,不要人数太多,人数多了,进行沟通的渠道就多了,管理的复杂度就高了,对项目经理的要求也就高了。在微软的 msf 中,有一个很明确的原则就是要控制项目组的人数不要超过 10 人,当然这不是绝对的,也和项目经理的水平有很大关系。但是人员 " 贵精而不贵多 " ,这是一个基本的原则,这和我们上面提到的高效原则、分解原则是相辅相成的。

你可能感兴趣的:(数据结构,工作,项目管理,企业应用,360)