也谈应对需求变化

起因

偶然看到博客园一位朋友写的一篇应对需求变化的文章,顿时来了兴趣,需求变化是软件开发过程中很常见的事情,也是最让程序员朋友们头疼的一个问题,如果这个问题能够很好的解决,对软件开发一定是一件非常好的事情,虽然谈不上是创新,但是至少可以归结为一项技术改革,因此,如果能够有一种或多种好的方案来应对需求变化,那么,它的重要性不言而喻。因为任何办法或方案都没有银弹,因此,方案的实用型、行业适用性就成为了我们要考虑的问题。

当我看到了这位园友的文章,于是兴致勃勃的发了如下回复:“只给出了思想,没有给出解决方案。”

我在今天早晨的时候收到如下回复:“思想比方案重要”。

于是我又做出了如下回复:“文章的实操性差一些”。

很明显,这样下去很容易陷入一个固执、偏见、口水仗……的怪圈,自己的所想很难用一两句话概括的清楚,也不是十几行文字就可以概括的清楚的。

我写本文的目的也只是想起到抛砖引玉的作用,希望跟大家多讨论讨论大家是怎么想的,以及大家在面对这样的问题的时候是怎么去应对这种需求变化的。

议程

  1. 园友的那篇文章及观点跟我想的有哪些不同
  2. 引起需求变化的原因有哪些
  3. 针对这些需求变化的原因我们应该如何应对
  4. 应对的案例

一、园友的那篇文章及观点跟我想的有哪些不同

1.考虑问题的广度不够,有一定的狭隘性

需求包括功能性需求跟非功能性需求,那位园友只给出了功能性需求中的如何应对CRUD的一些不算很成熟的想法。很多时候,一些非功能性需求才是最具有颠覆性的,更加难以应对的。举个例子,架构师常常需要考虑性能、并发性、安全性、可扩展性、易维护性等等,在做项目之前,这些非功能性的需求是最应该先考虑进来的,一个项目辛苦做完,测试没有问题正式上线了,却发现并发性、性能根本就无法满足企业的要求,导致整个项目无法应用,架构一旦定型,最终要改架构无异于重新开发。因此,考虑需求变化的应对不能仅仅考虑功能性的变化对程序的影响,也应当考虑非功能性需求的变化带来的影响。

2.成熟度差一些

该文仅仅是作者的一些不成熟的想法,离真正的在企业中应用还差很远,极有可能造成昙花一现,就连微软本身也常说想法不等于办法不等于方案。

3.没有给出具体的解决方案,仅仅是抛出了问题

最终企业最需要得到的是怎么做,而不是仅仅抛出问题,却不给出解决办法,哪怕仅仅是指导性的办法也可以。

4.观点对园友有一定的误导性

思想真的比方案重要吗?

坦白说,寻求一项新的解决办法来应对需求变化,这本身就是一项技术改革,虽然谈不上真正创新,至少大家都从观念上认为这是创新。我也姑且把这个当做是创新吧。有这种想法的原因主要是因为不了解创新过程及创新过程的管理。

创新过程要展开谈的话,主要分为以下几个方面:

  • 什么是创新
  • 为什么要创新
  • 管理中的创造力
  • 管理创新过程

由于篇幅影响,本文就不展开来谈这个很大的话题了。

我主要想说的是如下的一些总结:

  • 创新是一个生产过程,信息是它的原料,必须提高信息搜集的效率,以及利用信息的创造力。
  • 信息的搜集固然重要,但是信息的创造加工以及加工后的结果(解决方案)更加的有价值。

二、引起需求变化的原因有哪些

IT168的李倩编辑把引起需求变化的原因分为如下几类,有兴趣的读者可以参考原文《软件项目的需求开发与管理

1.用户不能正确表达自身的需求

2.业务人员配合力度不够

3.用户需求的不断变更

4.需求的完整程度

5.需求的细化程度

6.需求描述的多义性

7.忽略了用户的特点

8.需求开发的时间保障不充分

三、针对这些需求变化的原因我们应该如何应对

    1. 心态上要保持一个良好的心态,要把这个看成是一个常态。
    2. 针对不同的问题来解决问题。战略决策上、团队打造上、架构设计上、程序设计上……
    3. 在程序设计上优先考虑设计不同的解决方案及软件架构来应对一些变化。
    4. 更改开发流程,把风险降低到最低。
    5. 在设计的时候做好扩展,避免再改动的时候造成改动过大。很好的应用面向对象与设计模式的思想来解决问题。

四、应对的案例

面对需求变化的挑战,我们之前公司在架构设计上提前做过考虑,程序设计上也做过考虑,不过我在这里主要想跟大家分享的是开发流程。

开发流程上不采用传统的瀑布模式开发,而是采用原型模式。

在开发之前,由开发经理或产品经理用模型设计软件做好模型,然后给客户做演示,在给客户演示的时候,不断的跟客户做沟通、交流。等原型相对稳定的时候,再进入开发阶段。这样做的好处主要有:

  1. 客户很多时候不知道自己想要什么,客户只知道自己不想要什么。通过这样的不断演示、沟通,逐步的离客户想要的东西无限接近。
  2. 大大降低了开发成本,毕竟改文档或模型比该代码要容易的多,快的多。绝对不能在需求不明确的时候提前进入编码阶段。

总结:无论是从哪个方面去应对需求的变化,不同公司总归是有自己的一套东西的,很多时候知道不代表可以做到或能够很好的解决,我们更希望通过知道的信息,然后探讨出好的应对策略来,希望本文能够起到抛砖引玉的作用,也希望大家把自己的想法踊跃的分享出来。

Untitled Page .net技术交流三号群:196882675
作者:深山老林
出处:http://wlb.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

posted @ 2010-05-10 10:43 深山老林 阅读(1623) 评论(16) 编辑 收藏

 回复 引用 查看   
#1楼2010-05-10 10:58 | Kevin-moon      
关于原型,BS架构的原型比较容易
但是CS架构的原形做比较就比较麻烦,因为涉及到简单地编程,这个就需要占用开发人员的时间,
而且还有原型复用的问题,希望进入开发阶段后原型中的代码直接利用,但是要做到这点时间又成为一个问题
想知道LZ是怎么做这些问题的平衡的?

 回复 引用 查看   
#2楼[楼主]2010-05-10 11:03 | 深山老林      
@Kevin-moon
原型复用,目前只有Silverlight可以做到。
Webform方面,我们之前都没有能够做到复用,很多时候就是大白板,能够说明问题就好,也不会做太过复杂的交互。
CS架构的原型比较麻烦,具体我们CS架构的软件做的比较少,所以有多麻烦这个我确实体会不到。
原型复用这个问题,我们确实也没有很好的应对办法,这方面目前也没接触到很好的工具的支持。

 回复 引用 查看   
#3楼2010-05-10 11:27 | 卡通一下      
先不说变化,只说说客户的需求。

客户方的需求,往往是他们所需要的结果,而且多是主观性的东西。

做为开发方来说,面对客户的需求,不能简单的应对,常常需要到现场去调研,去做评估,最后才会与客户坐下来,详细地讨论,一一地确认这些需求问题。

我认可,思想比方案重要;

但我更认可:切实可行的方案,要比那些模棱两可、不着边际的思想更为重要!

 回复 引用 查看   
#4楼2010-05-10 11:43 | 李进博客      
强烈支持原型设计,先出界面,基本上用户的需求能了解到80%左右
 回复 引用 查看   
#5楼2010-05-10 11:44 | 李进博客      
不出原型的话,DEMO也可以有,
不过Demo做起来稍微麻烦些,但对以后的开发有直接帮助。

 回复 引用 查看   
#6楼2010-05-10 15:22 | Kevin Zou      
說辭感覺比較空洞
 回复 引用 查看   
#7楼2010-05-10 18:09 | 金色海洋(jyk)      
我感觉很是空洞,好像也没有提出来什么解决方案 呀。
 回复 引用 查看   
#8楼[楼主]2010-05-10 21:08 | 深山老林      
@金色海洋(jyk)
@Kevin Zou
空洞的原因在于希望大家去探讨。

 回复 引用 查看   
#9楼2010-05-10 21:28 | 卡通一下      
引用深山老林:
@金色海洋(jyk)
@Kevin Zou
空洞的原因在于希望大家去探讨。

空洞的原因在于需求变化是一种常态,也是无法预知的,我们也不可能没事坐在那,成天揣测客户有可能提出修改什么的,是吧?

我也想不出这有什么探讨的,呵呵!

 回复 引用 查看   
#10楼2010-05-10 22:10 | 诺贝尔      
应对需求变化
http://www.cnblogs.com/Nobel/archive/2010/05/09/1730977.html


虽然我说的是应对需求的变化,但是我针对的层面比博主的要底层。我不是讨论软件工程层面的东西,而是探讨软件设计方面的东西。

把握设计的原则,找到设计的分界线。设计,是一个平衡的艺术,而找到平衡点的方法或者说是原则就在文章中。

其实只要把握好原则,设计就找到方向,不能说是没有意义。当然每个人的设计能力是不同的,每个项目的平衡点也是不同的。

当然博主说我只是针对功能来说,或许是吧。但是如果按照博主的想法,恐怕这种从根本上改革的简易方法是不存在的。比如.net类库,要添加良好的多线程支持,也是翻天覆地。

 回复 引用 查看   
#11楼[楼主]2010-05-10 22:13 | 深山老林      
@诺贝尔
嗯,有道理。
不过没有听到大家的意见,真是太可惜了。

 回复 引用 查看   
#12楼2010-05-12 13:48 | 羽之      
并不是所有的项目都适用于原型模式的
 回复 引用 查看   
#13楼[楼主]2010-05-12 18:08 | 深山老林      
@羽之
能否举一个不适用的例子?

 回复 引用 查看   
#14楼2010-05-13 20:51 | george.hu      
原形设计分为推演型原型和抛弃型原型,如果系统对人机交互、功能实现等表现形式比较在意的话,多半会要求推演型原型,通过逐步求真,原型会非常接近真实的产品,这类原型产生的提交物我们也可称之为高保真原型产品,高保真的产品通常会成为开发阶段代码实现的一部分;而抛弃型原型不同,顾名思义,这种原型一般比较简陋,只用来说明功能的大概实现和页面的布局等,等明确客户需求后,此类原型即做放弃,不会成为代码实现的一部分
 回复 引用 查看   
#15楼[楼主]2010-05-14 13:20 | 深山老林      
@george.hu
受教了。
不过在项目开发中,高保真原型一般是会非常慢的,远不能跟上开发进度,甚至会拖延整个团队的开发进度。
就比如说一个流水线作业,当一个环节成为了这条生产线的瓶颈的时候,它的速度就是整个团队的速度。
对于一个组件化的团队,这种流水线开发多半会有问题的,各方面的速度跟人员协调上都是一个很大的问题,即使采用Scrum,即使是每天都有站立式会议,多半在团队中都是开发人员发扬风格,至少在前期还是通过抛弃式原型进行开发的,高保真原型远远跟不上项目进度,是在后期才被采用的。
高保真原型这种模式的开发很少有团队能够养得起。
到底多少团队或项目组在采用高保真模型,以及实施程度如何,我见过的开发团队这种方式执行的并不是太好。

 回复 引用 查看   
#16楼2010-05-14 15:52 | 羽之      
引用深山老林:
@羽之
能否举一个不适用的例子?


如一个通讯协议算法的开发项目。

本来就没有界面,全是接口,这种项目能用原型吗?

是否用原型法,主要看项目的重点是什么?如果界面是重点或界面上能体现项目的主要部分原型法是合适,反之原型法无法使用在项目中。

公告

英文名:Kevin

位置:中国 北京

职位:技术总监

Email:iamwlb@qq.com

昵称:深山老林
园龄:4年1个月
粉丝:92
关注:4