项目管理——某公司软件开发案例

项目管理——某公司软件开发案例

ID:8524325

大小:24.50 KB

页数:8页

时间:2018-03-31

项目管理——某公司软件开发案例_第1页
项目管理——某公司软件开发案例_第2页
项目管理——某公司软件开发案例_第3页
项目管理——某公司软件开发案例_第4页
项目管理——某公司软件开发案例_第5页
资源描述:

《项目管理——某公司软件开发案例》由会员上传分享,免费在线阅读,更多相关内容在学术论文-天天文库

1、项目管理——某公司软件开发案例观察项目的三个指标:时间、预算、质量及功能完整性。   失败的项目一般体现为:超时、预算超支、牺牲了部分功能或质量。彻底失败的项目,就是一个最后压根没有完成的项目,比如烂尾楼。   首先,我们讨论其中的一个指标,时间。   每个人对时间的理解不同,同样在项目里面的每个人对项目的时间理解也是不同的。   1、 公司, 希望项目在最短的时间内完成,这样时间和预算都是最小的。当然能做到的项目少之又少,业内有数据的。   2、 项目经理(为行文方便,暂称为PM,下同), 希望项目的计

2、划时间尽可能地长,这样才有机会应付各种突发事件和不可抗的影响,毕竟很多原因是客观存在的。墨菲定律。   3、 功能模块小组长(如……等,暂称为小组长), 一方面承受着项目经理的压力,一方面又承受着来自基层开发人员的压力。PM会要求小组长以最短时间完成所负责的部分;开发人员则很反感长期加班、高度的压力感。   从过去的一年多来看,在时间要求方面,我们公司的意愿并不强烈。当然并不是强烈就可以解决的,后面会讲到,这是本文的重点。   在我们公司,最后决定项目时间长短的关键,是开发人员。在人数不变、人员不更换的前

3、提下,每个开发人员的产出是固定的,至少目前来说是固定的。加班,也不会有更好的改善,原因已经在我以前的邮件中说明过了。   那么,从上至下形成一种新的强制性时间要求,会不会有效呢?事实上,不是没人试过,结果估计并不理想。程序开发是一种脑力劳动,决定一件任务完成所需时间是由程序员的脑袋决定的,甚至任务完成到什么程度,如果不花费大力气的检查也是不会轻易能发现的。这点有过中层管理经验的人,应该都清楚。例如,管理人员要求用三天完成某个新功能,开发人员说至少要一周时间,即使最后管理人员令开发人员妥协了,他得到的也很可

4、能是一个半成品——能用,但有缺陷;或者表面功能完成了,主线功能有部分没有完成。   换人吧,中国程序员遍地都是,这不是问题的关键,所以换人作用不大。新人很快会被同化。那全换吧?全换是什么概念,换到哪个级别,这是个BigQuestion.而且还有另外一个问题——知识传承。弄不好,伤筋累骨,结果还不一定就能如愿。   那么,问题是不是无解了呢?不知道,我也没有经验,这里只能提供一点看法,周末不想逛街,就写点东西,分析一下身边的问题,说得不对,就按一下DEL,不会太费事。就当是闲聊吧。接着……其实还有一类人的时

5、间,或许他们的时间要求才是最值得研究的。   4、甲方(客户) 一般地,政府作为甲方,内部意见并不完全统一。我们作为承建方,可能要配合那些支持我们的某些甲方代表(暂称友好方,下同),另一方面也要考虑到对我们不太支持的另一些人(暂称反对方)。很可能看起来无关紧要的一个小员的一句话,就会对项目产生不可挽回的影响。甲方内部的友好方和反对方,他们的时间要求是不一样。反对方,在具体开发的过程中会有一些不配合,另一方面对项目完成的时间要求又会格外的严格。所以,我们的时间表,以达到甲方内部的反对方的时间要求为最优,以达

6、到甲方内部友好方的时间要求为及格。如果我们在开发中,处处以友好方的时间表作为自己的时间表,完全不预留安全时间,那么到最后我们会非常被动。   甲方的时间表对我们的可能影响包括:   A、要弄清楚甲方真正的时间表,尤其是反对方的,并传达到公司内部每一个相关人员,所有计划都就应按这个时间表走。(反观我们,一方面我们只考虑友好甲方的时间表。另一方面,现在整个时间表其实已被开发人员劫持,我们的计划是按开发人员人数×每周工作量摊开的,呵呵。)   B、系统主要功能的真正完成,是真正完成,需要与客户多次反复交互、反复

7、调试修改。第一次提交的版本,完全不能算是最终版本。对于具体的某个功能,或对于整个系统来说,都是这样。(反观我们,我们可能无法在客户要求的时间表之前(之前!)提交版本,即使提交了,也是首次提交,而非经与客户反复联调过的版本)   C、准确把握业务需求,还要准确地把握客户的非业务需求(如性能、推动试运行、UI易用性人性化、配套的培训等等)。准确地把握这两件东西,将会对开发效率,乃至于项目进度都会产生极大的助益。(反观我们,我们现在的绝大部分兵力,都投在研发环节,投在客户身上的时间实在不够,下面还会着重提到。)

8、   D、公司应该有自己的时间表,产品研发计划应与市场运作联动。如获取业内行家的好评,需要我们及时发布可用的、漂亮界面的、稳定的、功能完整的版本;如搞财政系统内的推介会,我们也需要这样一套东西。对于我们没有的系统,我们应该有演示版本,而演示版的制作,也需要公司有专门的部门提前研究潜在的客户要求、业务需求。   E、 产品研发的进度,任何时候都应该有5~10%的弹性。不是说要把时间表随意向前一调就叫弹性。(如果所谓的时间表到了一

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。