设计变化和需求变化
开发人员最怕的是什么呢?设计变化,还是需求变化?我觉得需求变化是最最致命的。
当你的一个项目数据库都定下来后,而且已经开发了若干个工作日,突然接到甲方公司提出,某个功能要改变,原先的需求分析要重新改,如果这个修改是涉及的数据库的表结构更改的话,那真是最致命的。
这就意味着项目的某些部分得重新推倒重来,如果这个部分跟已完成的多个部分有牵连的话,那就后果更可怕了。
所以当碰到这种情况发生,作为项目经理的你就应该考虑先查责任人,究竟是自己的需求分析做的不够好,还是客户在认同了需求分析后做出的修改,如果是后者的话,你完全可以要求客户对他的这个修改负责任!
那么,呵呵,客户先生,对不起了,本次新增加的需求将归入另外一个版本。如果是改变前面某个需求的定义,那么说不定就要推倒重来了,不过这个时候到不用太在意,毕竟错的是客户。(项目正式开始前没有没有说清楚其需求)。
所以,各位看客,在需求分析做好后,在开工之前一定要叫客户认可签字,并且在合同上要注明,当由客户原因引起的需求改变而造成开发成本的增加,客户要为此买单地。
如果在需求不变的情况之下,设计发生了变化,这个仅仅是我们内部之间的矛盾,商量一下就能解决。在简单设计中,因为前期的设计是不完整的,那么当进入任何一个新的模块进行开发时,都有可能引起设计的变化。开发人员的水平的高低就基本上决定了软件的好坏。
需求变更流程
变更控制
(Requirement Change Control) 需求变更通常会对项目的进度、人力资源产生很大的影响,这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目,特别在外地实施的工程软件项目而言,需求发生若干次变更似乎是不可避免的。
需求发生变更的起因主要有:
- 随着项目生命周期的不断往前推进,人们(包括开发方和客户方)对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷,因此要变更需求。
- 市场业务需求发生了变化,原先的需求可能跟不上当前的市场业务发展,因此要变更需求。
由于市场变化而导致需求发生变更,开发商大可不必为此烦恼,应当高兴才对。倘若市场静如死水,那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化,才会产生更多商机,聪明的开发商才会有活干,有钱赚。
如果在项目开发的初始阶段,开发人员和用户没有搞清楚需求或者搞错了需求,到了项目开发后期才将需求纠正过来,导致产品的部分内容需要重新开发。毫无疑问,这种需求方工作失误造成的,双方应当好好反省,认真学习需求开发和管理的方法,避免再犯相似的错误。
总的而言,人们提出需求变更,本就是出于能够使产品更加符合市场或客户需求,出发点本身是好的。
但对于开发小组而言,需求的变更则意味着要需要重新进行估计,调整资源、重新分配任务、修改前期工作产品等,而作为开发商,需要增预算与投资,开发组要为此付出较重的代价。假定每次需求变更请求都被接受的话,那么这个项目将会成为一个连环式的工程。
需求变更控制的动机是:
- 如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的变更规程执行,以免变更失去控制。
- 如果需求变更带来的坏处大于好处,那么拒绝变更。
当然,好处与坏处并不是主观的,而是通过客观的分析与评价而得出的。
对于需求的变更,在某一个程度上来说,也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与,包括负责人及市场人员。当然,我们需要根据变更的内容来灵活运用。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利,因为他付钱给开发方。通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。
怎么解决这个问题呢,通常情况下,每一类“游戏”都有一定的游戏规则,那么我们事先也需要建立“游戏规则”。
如果事先没有“游戏规则”的话,开发方的负责人需要一些社交技巧来减缓矛盾。
- 例如首先承认客户提出的需求变更请求是合理的,再阐述己方的难处,最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多,既不得罪客户,又为自己争取了余地。
- 另外还有一种方法,可以将变更需求先进行记录,并通知给客户,当其需求变化在开发组不能接受的范围时,可以通过市场进行相关的协调。
需求变更本是正常的,并不可怕,可怕的是需求的变更得不到控制。