[项目经验]开发者的烦恼在继续...

 谈谈目前的项目体会,由于涉及商业秘密,不说人数,也不说内容,就关系上讲分为3类人来描述

      1,  客户,对项目的专业性和技术性有比较高的水平, 简称A

      2,  开发公司在项目的专业人士,知道开发任务的技术规格,简称B

      3, 软件开发,负责将项目有关的代码码出来,并实现软件各功能,简称C

 

整个项目属于小型的,项目的难点如下.

     A 方面,对项目的期望比较高,开发目的也很明确,但对各细节上的,专业技术上的细节经常变更.导致开发任务经常变动,整个软件框架已经大改了一次,

     B 方面, 专业技术很强,可惜擅长的领域,和工作惯性.并不适合本次项目的技术水平.经常要迎合A做专业技术的算法讨论,还不停地推C快点实现一个目标都比较模糊地软件

    C 方面,对该类项目已经有多年的开发经验,但是对于本次项目的科研方向来讲,算是第一次尝试,人员方面对工作量的安排有一点难度,很多好的想法,考虑到工作量的时间,所以放弃

 

    这是3方主要问题,详细点的就不说下去,当然,也会经常沟通,毕竟开发任务属于科研性质.连项目合同也成为科研合同,而非甲方公司的软件合同.

    项目也快进入尾声了,可惜,B里面的主力人士由于压力承受不住,多次在B和C中提出无法实现. A对技术上有一定认识但,这各认识却无法对整个项目的开发有任何帮助,他们的角色只要求他们给出个方向,也许A他们在自己的圈子中也要承受很大压力,所以项目要求改来改去.B和C都属于合同中乙方公司的人,对此类项目也没有很强的经验,多数情况下是做点头羊的角色.

 

    在C看来,这里有一个很矛盾的地方是.

    项目的成果,包括一份技术报告文档和一个项目软件.

    展现个项目最终使用者的,他们更关注的是,更直观看到的是这个项目软件.

    但实际的情况是A,认为本次项目的重点是文档,而非软件.A的领导能更关注的是软件的功能,能否让他的工作变得更有意义,技术文档只是这个软件的灵魂.

 

    项目的结果和初衷已经存在很大不同了,当然也是计划没有变化的快.

    这是一次典型的需求频繁变更的软件开发项目. B和C都在努力地坚持完成这个项目的最后这段时间,当然有些人早也萌生退意.可是也有很多人在坚持,我想感谢和我一起坚持的同事.

 

    最后总结一下项目经验吧,要在不同的专业领域实现计算机软件应用,需求变更是很难避免的,无论甲方和乙方. 若要追问责任,最终只能归结为计划赶不上变化快. 软件设计的教程中的开发模式和流程只是说明一个理想状态下的开发流程的模型,但是在不同的项目环境下, 对于开发者来讲,要做好心理准备,想做好来,就得面对"计划赶不上变化快".为了减少失败的可能性,要冷静,不要放弃,坚持下去.