집 >데이터 베이스 >MySQL 튜토리얼 >中小软件公司项目管理(3.3 项目外部关键成功因素)
非常道-中小软件公司项目管理(3.3 项目外部关键成功因素) 最近忙一些私事,要离开自己亲手创建的团队了,心中多少有一些怅惘。软件开发这个行业总是这样分分合合,朋友在眼前来来往往,缘来则聚,缘尽则散。亲爱的兄弟姐妹们,希望以后还有机会再在一起奋
非常道-中小软件公司项目管理(3.3 项目外部关键成功因素)
最近忙一些私事,要离开自己亲手创建的团队了,心中多少有一些怅惘。软件开发这个行业总是这样分分合合,朋友在眼前来来往往,缘来则聚,缘尽则散。亲爱的兄弟姐妹们,希望以后还有机会再在一起奋斗。
接上节讲述的项目的内部成功因素,主要是:
一、识别团队能力
1、关键技术掌握度
2、团队成员综合能力(经验、能力、体力、专注度)
3、团队成员期望值
4、公司重视及期望值
二、获得资源
下面我们讲讲项目成功的外部因素,通常这些因素是最难以厘清的,也是考验一个项目经理真实功底的地方。
三、项目外部关键成功因素
项目要想成功,只靠内部因素是不够的,其实很多时候,内部的问题相对外部来说,也好解决的多,毕竟大家利益基本上是一致的,除开龌龊的政治斗争外,内部团队没人愿意项目失败。当然越大的公司内斗越利害,好比腾讯的财付通要在QQ空间投放软广告也要看QQ空间部门脸色还得付钱一样,这个没办法避免,只能尽量在公司的企业文化和政治制度下去尽量平衡和避免。因为我讲的主要是中小企业,所以这些厚黑的部分我们暂时忽略,大家自己将来慢慢领悟吧,讲多了也体会不到。
项目的外部关键成功因素重点就在两个字,关键。好了,我这不是废话,好比打仗一样,行军、选将、粮草、情报、天气、士气、地理都重要,但都考虑了,就算是越级计算机也算不过来。为什么这么多因素,还有人可以运筹帷幄打胜仗,我想没人说是运气,这其中的奥妙就在于,抓住了主要矛盾,一场战争,我可以一直输,但关键的一仗赢了,我就赢了,看看项羽和刘邦就明白了,小邦子开始那个输得惨,最后垓下一战一开始还被项羽打得找不着北,却转瞬就反包围了项羽,这其中,小邦子论武功、战场意识、用兵能力均比不上项羽,为什么他能赢,就因为他找准了关键因素,单打不行,要人多齐心一起灭了项羽,刘邦稳定了诸候,用利益调动了韩信、彭越、英布、刘贾这些人来一起群殴项羽,先除掉项羽这个最大的威胁,再来发展。这时战场上什么因素都不用去考虑,5个人打1个,小邦子这边又都是精英,大家都知道项羽厉害,不能让他翻身,全力以赴,终于让一代英雄项羽饮恨乌江。
说了这个故事,大家应该明白,关键成功因素是指在某个时间段内,某一因素对项目的成功起着决定性的正作用或反作用,只有运用各种手段,保证这一因素的形成或避免这一因素的形成,才能保证项目的最终成功。
关键因素是很微妙的,但一定是在某一时间段内恒定不变的,如果关键因素在项目交付前发生了变化,那就不是关键因素,而是我们所说的次要因素。下面我们分析一个案例:
某企业(甲方)委托某软件公司(乙方)开发一个生产管理系统,客户方要求根据工厂的生产管理特点进行钢材的工序及材料管理,甲方对接的小组长为信息中心主任,使用者为生产车间及仓库的统计员。甲方以前在生产管理中暴露的问题为:用Excel统计,数据规范性差,数据录入偏差大导致真实度低,并且难以统计分析。因此甲方希望在四个月内开发一套适合甲方生产特点的MIS系统,主要进行工序管理及原材料的出入库管理。
项目呢不大,总共不到三十万,乙方组织一个项目经理和两个开发人员外加一个测试人员进入项目,这里面成本预算从立项到实施加上一年的免费运维期,项目经理小强(打不死累不跨的项目经理们的统称)于是根据经验估算至少需要3个月的时间,加上一个月的缓冲期应该足够了(注意这里开始有问题),成本控制在6个月交付是最保守的,公司同意后,于是,立项、需求分析就开始了,需求分析的时候发现有个很严重的问题,甲方信息中心主任是foxbase开发出身,又要求软件用B/S架构,很多C/S的操作习惯又想带到B/S中,搞得小强一筹莫展,后来项目总监要小强先按B/S画个原型给甲方信息中心主任看看,结果甲方来了句看不懂,小强几乎要崩溃了,于是项目在拖拖沓沓的需求分析中勉强结束,甲方也勉强认可了。(问题很明显,同学们思考一下)。后面我就不说了,美国服务器,经过漫长的五个月,项目失败了,甲方信息中心主任极度不满意功能实现和操作方式,就更别提推广在全厂使用了。小强差点要吐血了。公司也终止了这个项目并总结了失败原因,不过总结的只是皮毛,诸如需求不明确,架构选择错误之类的。下面我来说一说:
这个项目的外部关键成功因素是什么,注意这个因素只有一个,请同学们思考一下:
(漫长的1分钟......)
诸位,答案肯定很多,我讲讲我的分析思路
1、 四个月完成不了,五个月、六个月交付项目是否可以算成功呢?
当然算成功,因此进度不超过四个月不算是关键成功因素,何况项目在五个月时就已经交付使用了。
2、 需求分析不明确
怎么说呢,原型也画了,功能描述和数据表设计甲方也认可了,勉强认可了原型和需求分析,也算是评审通过了。又有几个项目是需求完全无误差通过的呢,所以,需求吻合度也不算是关键成功因素
3、 架构错误
说实话,这个比较迷惑人,确实按甲方使用习惯是采用C/S比较好,但甲方又一定要求采用B/S架构,而且这个架构下的原型及操作方式都和甲方讲清楚了,甲方开始的时候也表示可以按这种方式去做,单纯的换架构到C/S方式也不一定能让用户像以前使用Excel那样方便
上述3个原因只是项目失败的原因,其实这个项目的关键成功因素只有一句话:
在保证用户操作使用习惯的前提下,实现简单的工艺流程及出入库管理。
看见没有,香港空间,技术人员和甲方认为B/S先进,却没想甲方一直是用Excel进行管理的,而且甲方的初衷就是开发一套适合甲方的生产管理系统,“适合”两个字被多少小强忽略了,因为太泛泛,但这种忽略换来的恶果就是项目的失败。软件,始终是要给人用的,当人的使用习惯不能被改变时,我们就只能按客户的习惯去实现,这是市场规律,要不然大家就都是乔布斯了。
小强的问题在于:
1、分析项目进行估算时,过于乐观,没有进行和组员一起头脑风暴,在没有和客户建立有效沟通的前提下,单纯的凭个人经验预估,导致后面死得很惨