`
yiding_he
  • 浏览: 437138 次
  • 性别: Icon_minigender_1
  • 来自: 湖南
社区版块
存档分类
最新评论

受众不明确导致需求变更频繁

阅读更多
有些需求受众非常不明确,比方“各部门领导”。这样的需求用户意见无法统一,需求变更反反复复。比如一个查询界面包含多选,开始说默认不选就代表全选,做好了然后又说不选就给出提示,将来又不知道会变成什么样。不知道大家是怎么应对这种情况的?
分享到:
评论
13 楼 billgui 2007-04-25  
Julien 写道
我的还要绝,领导只在项目做完的时候才看,看了然后就提一大堆要求,把原来的都推翻。所以你要想获得真正的需求,必须先把项目做完,然后重新再做一遍……OTL

Prototype,先把界面画出来,演示一下。
12 楼 抛出异常的爱 2007-04-24  
lkfnn 写道
现在的项目都是这样的,有很多时候客户都不知道自己要什么样的东西,关键看这么处理,我做的都是比较小的项目,一般都是现场开发,程序员直接找最终用户了解需求,然后回来做,基本上都可以定下来,左后再做查询的功能。
客户是不知道自己要什么
但你要是给了足够信息
他们会知道自己要什么的。。。。
11 楼 lkfnn 2007-04-24  
现在的项目都是这样的,有很多时候客户都不知道自己要什么样的东西,关键看这么处理,我做的都是比较小的项目,一般都是现场开发,程序员直接找最终用户了解需求,然后回来做,基本上都可以定下来,左后再做查询的功能。
10 楼 Julien 2007-04-21  
……你们把理论上这三个字断得太短了,我是说给整句的。
意思我接受,我自己如今也是这个观点。
我说的,那个重做的东西是我好几年前第一次干的大项目,现在还在维护中。
当初做那玩意的时候我就隐约意识到了有这种问题,不过那个时候觉得自己能写出好程序来挽救,用不着跟客户交流(吵架)浪费时间,就做了一大堆定制的东西,打算客户每次说“我要改”的时候在界面里面调一下就“现在改好了”来解决。
结果是局部解决了一些问题,但整体上还是不太成功,验收时间点到了的时候拿给客户看,根据要求,几乎又整个重构了一次才最终搞定
现在看起来就是不应该只在开发人员和开发环节里面敏捷,而是应该把整个产品周期都拿出来跟客户一起rockroll
9 楼 rtdb 2007-04-20  
clamp 写道
Julien 写道
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?


我个人认为:是否能够完全抛弃“理论上需求清晰”这种幻想是衡量一个人是否具有敏捷思想的重要标志

更是衡量一个人是否具有真正实践经验的重要标志
8 楼 clamp 2007-04-20  
Julien 写道
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?


我个人认为:是否能够完全抛弃“理论上需求清晰”这种幻想是衡量一个人是否具有敏捷思想的重要标志
7 楼 温柔一刀 2007-04-20  
Julien 写道
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?


怎么会高呢?迭代又不需要特意花时间发布部署什么的
全部自动化,让机器去做
6 楼 抛出异常的爱 2007-04-20  
每天出一个可视的东西。。。以前是html的
5 楼 Julien 2007-04-20  
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?
4 楼 温柔一刀 2007-04-20  
Julien 写道
我的还要绝,领导只在项目做完的时候才看,看了然后就提一大堆要求,把原来的都推翻。所以你要想获得真正的需求,必须先把项目做完,然后重新再做一遍……OTL


每周迭代发布让领导看,提意见,修改
3 楼 clamp 2007-04-20  
现实如此,所以才要迭代啊。
我们现在也面临一个不确定的流程,第一次需求调研会该来的人都没来,来的人都是一群不能拍板的,提了一堆要求,鬼才知道下次还是不是这批人来。

所以,我们的策略是,2周内交付一个可运行的版本,直接部署上线,然后开始推广使用,看看哪些人开始叫就是真正用户了。
2 楼 Julien 2007-04-20  
我的还要绝,领导只在项目做完的时候才看,看了然后就提一大堆要求,把原来的都推翻。所以你要想获得真正的需求,必须先把项目做完,然后重新再做一遍……OTL
1 楼 cozone_柯中 2007-04-20  
yiding_he 写道
有些需求受众非常不明确,比方“各部门领导”。这样的需求用户意见无法统一,需求变更反反复复。比如一个查询界面包含多选,开始说默认不选就代表全选,做好了然后又说不选就给出提示,将来又不知道会变成什么样。不知道大家是怎么应对这种情况的?


我们公司目前也是这样,经常变来变去,我是这样做的.

先把能确定的东西做完,这个估计就用了大部分时间,像你说的不确定因素应该是少数,然后不确定的再和相关人员探讨,如果没有结果,自己先按照自己的理解做个自己满意的出来, 提交测试.

相关推荐

Global site tag (gtag.js) - Google Analytics