论坛首页 综合技术论坛

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

浏览 6246 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2007-04-20  
有些需求受众非常不明确,比方“各部门领导”。这样的需求用户意见无法统一,需求变更反反复复。比如一个查询界面包含多选,开始说默认不选就代表全选,做好了然后又说不选就给出提示,将来又不知道会变成什么样。不知道大家是怎么应对这种情况的?
   发表时间:2007-04-20  
yiding_he 写道
有些需求受众非常不明确,比方“各部门领导”。这样的需求用户意见无法统一,需求变更反反复复。比如一个查询界面包含多选,开始说默认不选就代表全选,做好了然后又说不选就给出提示,将来又不知道会变成什么样。不知道大家是怎么应对这种情况的?


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

先把能确定的东西做完,这个估计就用了大部分时间,像你说的不确定因素应该是少数,然后不确定的再和相关人员探讨,如果没有结果,自己先按照自己的理解做个自己满意的出来, 提交测试.
0 请登录后投票
   发表时间:2007-04-20  
我的还要绝,领导只在项目做完的时候才看,看了然后就提一大堆要求,把原来的都推翻。所以你要想获得真正的需求,必须先把项目做完,然后重新再做一遍……OTL
0 请登录后投票
   发表时间:2007-04-20  
现实如此,所以才要迭代啊。
我们现在也面临一个不确定的流程,第一次需求调研会该来的人都没来,来的人都是一群不能拍板的,提了一堆要求,鬼才知道下次还是不是这批人来。

所以,我们的策略是,2周内交付一个可运行的版本,直接部署上线,然后开始推广使用,看看哪些人开始叫就是真正用户了。
0 请登录后投票
   发表时间:2007-04-20  
Julien 写道
我的还要绝,领导只在项目做完的时候才看,看了然后就提一大堆要求,把原来的都推翻。所以你要想获得真正的需求,必须先把项目做完,然后重新再做一遍……OTL


每周迭代发布让领导看,提意见,修改
0 请登录后投票
   发表时间:2007-04-20  
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?
0 请登录后投票
   发表时间:2007-04-20  
每天出一个可视的东西。。。以前是html的
0 请登录后投票
   发表时间:2007-04-20  
Julien 写道
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?


怎么会高呢?迭代又不需要特意花时间发布部署什么的
全部自动化,让机器去做
0 请登录后投票
   发表时间:2007-04-20  
Julien 写道
原来迭代是这个意思,不是说开发版本的迭代,而是部署使用之后开始产品迭代。
但是理论上需求清晰的话这个迭代的成本肯定比直接按照清晰的需求编码要高吧?


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


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

更是衡量一个人是否具有真正实践经验的重要标志
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics