现在的位置: 首页 > 综合 > 正文

也谈应对需求变化

2012年05月04日 ⁄ 综合 ⁄ 共 2000字 ⁄ 字号 评论关闭

起因

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

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

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

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

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

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

议程

  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. 大大降低了开发成本,毕竟改文档或模型比该代码要容易的多,快的多。绝对不能在需求不明确的时候提前进入编码阶段。

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

【上篇】
【下篇】

抱歉!评论已关闭.