如何应对需求变更

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/yangrendong/article/details/89283350

    我们国内做开发,经常需要加班加点,而外企很少加班,但是产出却很明显,这里面涉及因素很多,包括大环境、管理制度水平、配置设施等等,但是有一个因素至关重要,那就是需求变更。

    我们国内大部分软件公司,需求变更是常态,开发到一半,很多原始需求已经发生了变化,当初的设计已经不能满足要求了,很多代码需要修改,不得不加班加点来赶上进度。

    反观外企,需求确定后很少变更,这样开发人员就可以针对需求有良好的架构设计,而不用考虑太多可能的变更,从容地在项目计划的时间内完成任务,而不需要加班加点。

在需求变更这个事情上,没有赢家,每个人都是受害者。

    程序员自己辛苦的工作白费,得不到成就感,频繁变更的需求,不得不在设计时考虑更多肯能,导致代码臃肿,代码质量下降,加班加点成了常态。业界曾调侃到,“杀一个程序员不需要用枪,改三次需求就可以了!”。

    产品经理也觉得委屈:“客户要改,我有什么办法?”程序员和产品经理似乎变成了两个对立的岗位,程序员怪产品经理乱改需求,产品经理觉得是客户造成的,人人都觉得自己委屈,客户也同样不满意,觉得做出来的软件非他所要,进度总是在延后,还想加钱?

    既然大家都不满意,那么我们就需要想办法去改善,这也是软件工程存在的意义!

    目前有如下两个比较常见的解决方案

  1. 方案一:增强需求变更流程,让需求变更规范起来

简单来说就是通过严格的流程,来避免一些没有意义的变更,从而达到管理需求变更的目的。

  1. 方案二:快速迭代,缩短版本周期

简单说就是将大的功能拆分,每个版本周期仅实现一部分功能需求,周期较短,这样需求变更时就可以快速响应

    不过,我们要思考上面的答案是否能够解决当前项目的问题,因为软件工程这类偏理论知识的学习,不能仅仅停留在了解有什么样的解决方案上,而是要追本溯源,研究问题背后的原因,研究理论背后的来龙去脉。

为什么建筑工程中少有需求变更?

    我们可以拿软件工程和建筑工程进行对比,你可以思考一下,同样是工程,建筑项目也是有需求变更的,但不会像软件项目这么频繁和失控,why?

我们可以总结出两个主要原因:需求的确定性和需求变更的成本。

原因一:需求的确定性

    建筑需求是很具象的,而软件工程是抽象的,所以建筑项目立面,无论是提出需求还是变更需求,客户和施工方都明确地知道他们想要什么。

    软件需求则经常是抽象、模糊、不精确的,模糊不清的需求导致在软件开发有了雏形后,才慢慢想清楚真正的需求是什么,从而导致需求变更。

原因二:需求变更的成本

    建筑项目里的需求变更,很容易和成本挂钩,这些都是生活常识了,但是很多老板对软件项目需求变更导致的成本增加缺少系统认识。

    举个例子,装修房子的时候,如果墙面已经刷成白色了,但是客户想都刷成蓝色,显然这涉及一系列成本:需要重新购买涂料、需要找人重新粉刷。

    但是换成一个软件项目,客户想把界面的白色背景换成蓝色,会觉得很简单,理所当然的,甚至产品经理都这么认为,可是实际上,软件项目的需求变更,哪怕是换一个背景颜色,也是涉及成本的:需要修改所有涉及背景颜色的代码,需要更新相关测试代码,还需要对涉及的界面重新测试。

    也许你会说成本是架构设计水平不到家导致的,但是如果设计时就考虑到要有支持背景切换的功能,那么开发量一开始就上去了,同样成本是提升了。

    所以为什么美国程序员不加班,为什么美国的产品经理不敢随意更改需求?因为在美国很多IT公司都是工程师文化,工程师相对比较有话语权,正常情况是不会加班加点的,所以产品经理变更需求的成本很高,在确定需求时是很谨慎的。

如何解决需求变更问题?

    说完了原因,咱们再来看看解决方案。

    首先,我们需要意识到,软件项目开发中,需求变更其实是不可避免的,一味抵制需求变更是不可取的,我们能做的就是利用软件工程的知识,理解需求变更背后深层次的原因,找到合适的方案来改善,积极拥抱合理的需求变化,减少不必要的需求变更,这是大的前提条件,也是共识的基础。

    我的经验是从源头着手,既然需求变更的原因是需求不确定和需求变更成本太低,那么我们就针对性地提出相应的解决方案:

  1. 提升需求确定性,把需求分析做好,减少需求变更
  2. 提高需求变更的成本,让客户或者产品经理不太容易变更需求,这样就可以达到减少需求变更的目的

但在实施的时候,我们会发现,如果一味地提高需求变更的成本,会让客户满意度下降,也造成了产品经理和开发人员之间的对立,不利于项目协作。

所以我们从另一个角度思考:需求变更之所以让你痛苦不堪,也是因为需求变更让项目成员付出了高昂的代价,返工、加班。如果我们可以低成本地响应需求变更,那么一样可以达到管理需求变更的效果。于是解决方案上可以再加上一条:

  1. 降低响应需求变更的成本,可以方便快捷地响应需求变更

案例分析

    我有个大学同学X,毕业后自己开了个公司,早些年企业建站火的时候专门接企业网站的活,刚开始的时候很艰苦,没几个人,甚至都没有专门的产品经理。

开发流程比较简单,先把项目谈下来,客户提一个建站的需求,然后他们去开发网站,开发好了给客户演示。客户在看到网站演示后,每次都会提出很多变更的需求,例如颜色变一下、布局变一下、给留言功能加上关键字过滤功能等等,甚至客户还喜欢直接在QQ上找负责开发的程序员直接改一下。

    创业初期,X同学真的是不容易,每天和几个程序员一起加班加点,就是为了应对客户这种频繁变更的需求。如果你是X,参考前面总结的几种解决方案,你会怎么做?

    很幸运的是,X同学作为软件工程专业毕业的学生,他当时运用软件工程知识去改善需求变更问题的做法上非常好,他其实并没有采用一个单一的解决方案,而是分阶段逐步改进。

第一步:规范变更流程,提升客户变更成本

    X同学知道,通过提升需求确定性,做好需求分析,和客户多沟通确认,是可以有效减少需求变更的,但是创业初期人手太有限,也没有专业的产品经理,不能短时间内去提升需求分析、产品设计的水平,所以他首先选择提升客户变更需求的成本,马上立竿见影。

    于是在后面的项目中,在和客户签订合同时,他会和客户约定,如果有需求变更,先统一提交到他那里,他进行甄别后决定是否做,什么时候做,是否需要重新签订新的附加合同(增加额外费用)。通过制定一系列标准,让双方合作的流程变得更规范。

    这样,程序员就可以专注于开发,不会因为频繁的需求变更影响进度,但是需求变更的情况还是时有发生。

第二步:用原型设计低成本响应需求变更;做好需求分析和确认,减少需求变更

    X同学在挺过最艰难的创业初期后,雇佣了一个全职的产品经理,专门去和客户确认需求,这个产品经理很专业,每次在了解完客户的需求后,不急于让程序员马上写代码,而是自己先用Axure类似的原型设计工具,做一个简单的交互原型,给客户演示。

    于是客户会针对原型的效果提出一些修改意见,他再快速地修改原型,这样反复确认,等到客户没有什么修改意见后,再让开发着手实现。

    通过原型设计的方式,不仅可以方便地与客户沟通需求,还可以灵活响应需求变更。

第三步:通过灵活的架构和强大的配置,低成本响应客户需求变更

    X同学经过两年的发展后,敏锐地发现其实大部分企业网站的功能都是相似的,主要差别还是在界面样式上。

    这些年大部分网站的开发其实都是把前一个网站复制一份,修修改改,但是这样效率太低,如果可以做到定制化,就可以更高效地定制网站。

    于是X同学从公司抽调了几名骨干程序员,成立了一个专门的项目组,把这几年的网站类型做了分析,做了一套建站系统,类似于后来流行的WordPress这样的博客系统,可以通过换皮肤的方式来定制界面,通过插件的方式增加功能。

    由于前期积累充分,大约半年后他们就开始使用这套系统去建站,一下子大大降低了建站的成本,而且当客户的需求有变化时,只要后台做简单的配置就可以马上支持需求变更。

    但是这个模式也有问题,就是有些特别个性化的定制需求,还是满足不了,对于这种个性化需求的客户,要么增加额外的费用,要么就直接放弃掉。

    如果咱们对X同学的三步采取的方案做一个总结,就是我们前面说的三个方案:

1、提升需求确定性

2、提高需求变更的成本

3、降低响应需求变更的成本

总结

针对需求变更频繁,主要是由于需求不确定和变更成本低导致的,所以如下三个解决方案:

1.提升需求确定性,来减少需求的变更,此方案的优势是对需求理解透彻,后期返工少,缺点是要求产品经理对需求分析能力要求很高

2.提高需求变更的成本,规范需求变更流程,减少需求变更,这种方案立竿见影,但是过于繁琐的流程不太利于项目协同作业

3.降低响应需求变更的成本,积极应对需求变更,此方案优势在于可以快速响应需求变更,快速试错调整,缺点是对软件架构和项目管理要求很高

展开阅读全文

需求变更

03-28

关于需求变更对软件结构的冲击,我想如果使用面向对象方法效果会好一些。Yourdon在《Object Oriented Analysis》中有一个被人广泛引用的结论。就是对于软件结构言,最容易变化的首先是流程,其次是接口,在次是对象的属性,最后才是对象本身。拿一个单位的人事管理系统来举例子,最容易变的肯定是流程,单位的一道文件就可能改变比如入职,辞职,调动等等流程。接口的易变性要小一点,比如原来的脱机接口变成联机接口,增加一些额外的用户界面,报表生成等等。对象的属性(包括对象之间的关系)其实就很不容易变动了,在现实世界中增加的情况比较多,如果此系统要进行移植,比如从国企到外企,对象属性要进行比较大的变动,但是对象和对象的基本属性是非常稳固的,任何企业,雇主和雇员,上级和下级,工作,报酬等等对象是一定要存在的,对象的状态,对于雇员,入职,离职,请假,生病,这些状态和状态转移关系,是具有一定普遍性的。rn 系统分析员如果能抓住系统中这些稳固的部分,并且加以很好抽象和封装,在应对需求变化的时候,就会从容得多,当然,西谚有云“不要认为递给一个傻瓜一把锤子,他就会成为一个建筑师”,能否构建稳定的系统模型是衡量系统分析员的一个重要的方面。需求的不断变化,是系统分析员永远要面对的挑战,我想,这也是系统分析工作的魅力之所在。rn 论坛

没有更多推荐了,返回首页