nicole_zmf 2007-4-3 15:45
用户没有进行正式的需求确认,开发工作怎样进行!
目前,在周围的项目开发中出现了这样的现象:用户基本上已经对需求进行了初步确认,但是由于一些原因不能立即(需要一些时间)或者完全进行确认(需求没有确认).此时项目组为了不影响进度已经开始了需求阶段之后的后继工作(此时需求基线是没有发布的).因为需求基线没有发布,此后的设计基线以及测试基线都不能发布,直至项目结尾时用户才有可能完全的对需求进行确认.但那时项目即将结束,在那时发布需求基线的意义就不大了.
而且,在此期间(没有发布需求基线---项目临近收尾),项目的进展状况是由PM来控制的,QA人员很难在对项目进行控制,监督工作进行的也很吃力，有没有什么办法能让[color=Red]用户的需求确认不影响开发流程[/color]而且[color=Red]QA人员也能很好地对项目进行控制了[/color]？大家有什么好办法吗或者同样也遇到过这样的现象,最终是怎么解决的呢？:em2
nicole_zmf 2007-4-13 13:21
大家谈谈自已的意见和想法,如上面所述,怎样才能管理好用户需求呢?
小学一年级 2007-4-17 12:53
首先要让你的客户明白，做好需求是双方的负责。当然在现实中，很多问题都是客户直接提出，而确认只有到他看到实际的东西出来之后才下判断。
对于这种需求不明确的情况，可采取增量的开发模式，这就要求对项目要有很强的管理控制能力。
至于需求的基线可包括所有明确的需求，对于不明确的需求依次区分，在下一个版本中进行体现。
bobytang 2007-4-26 21:46
定义需求的优先级，一个阶段内只实现当前优先级最高的feature；
每周推出一个用户可以使用的新版本，使用户能够方便的提出其真正想要的需求；
建议看一本书《敏捷与秩序》，其讲到的rup的最佳实践会非常有助于你们的项目。
朱雀_陵光 2007-9-13 16:30
迭代；或者用快速原型法让客户确认需求
nobody365 2007-9-18 13:38
回复 #1 nicole_zmf 的帖子
客户在项目初期, 不可能就对此项目的整体需求进行确认, 他们的思想总徘徊在模糊状态, 这时, 我个人同意楼上的看法, 采用原形法, 快速实现项目整体的棱阔, 让客户模糊的思想逐渐变得清晰, 然后对清淅的部分, 进行逐步精化, 确认, 实现.........欢迎指正!
tigergun 2007-9-19 12:03
用户特别是政府机关用户完全没有耐心和你做需求
regina2007 2007-9-28 13:24
也许是有些需求用户自身也不是很清晰，我们的做法是先基于确定部分开始编码，测试及提供给用户可运行版本．用户在试用了该版本后，也许会提出需求变更，之前未确认的需求也许会取消．虽然这种方法不是最好的，至少仅供参考．
hpx209 2007-11-5 17:46
用迭代的全生命周期或原型法
nicole_zmf 2008-1-23 10:30
大家说的都是很不错的好办法,但对于我们出现这种情况的项目的客户几乎都是政府部门,强势得很.就像tigergun所说的,他们不会和你进行需求确认,拿去原型给他们看,往往也没有什么提出来的建议,反而是在开发过程中随便提出这样或那样的要求.变更变得频繁和无法控制.这样在很大程度上浪费时间,人力资源,成本.对待这样用户还有什么好办法吗?
zheng123fei 2008-2-23 16:56
如果需求无法和客户确认，或者开发了原型，客户也没有提出什么建议或更改。
可以考虑这样做，基于原型制定需求基线，再和客户约定一个需求封闭时间，在封闭时间之后提出的需求都作为需求变更来处理。
朱雀_陵光 2008-3-27 11:29
那就公司高层出面, 和政府机关领导把关系勾兑好, 饭桌子上吃好喝好什么都好谈了, 那个时候用调侃点的口气给他们说说如果需求不定那公司做到最后就只有亏本, 想来这样会便于沟通些, 建议可以这样试试
黄六梅 2008-3-27 16:50
这是软件开发公司的大难题，用户需求无法即时确认，开发公司也只能提醒和催客户，然后自己再慢慢往这方面靠罗。
warfalcon 2008-4-9 14:45
出现这种情况首先要考虑你们的沟通是不是有问题。最好先要由公司高层把关系打好。政府高层发活之后，下面的人会好说话多了。不行的话，多请对面中层人员吃吃，玩一玩。
你们具体做需求的时候，最好拿一下样例或原形让对方了解整体框架。然后确定关键流程，最好做好的流程图，请对方一一确认。根据上面的交流结果来写需求文档。完成之后，请对方签字确认。你们的所有开发都以这个别需求说明书来完成。对方如果任意变更需要，让对方填写变更确认书，由对方签字确认。把需求分为几级进行管理，主要需求变更，需要主管领导签字确认。明确要求增加项目金额或开发周期。小的需要变更，也要签字确认，做为管理依据。每隔一段时间向客户汇报项目进度。一般的工作人员，一旦知道自己的提的需求需要签字确认的时候，下回不会乱提需求的。
a2349 2008-4-11 16:54
我是学生...先了解下...::em57::
pailun 2008-4-14 15:04
個人想法最好在合約要有定義確認的方式,還有在某些情況下就算確認完畢。例如提交需求確認書，十四天內無提出異議就算同意。
乐天无忧 2008-4-21 14:27
把握用户的核心思想，针对最重要最紧急的需求先进行定制，以DEMO化的方式展示开发思路，保证所开发的东西和客户所要求的没有太大的偏差。
scmscmscm 2008-5-23 12:00
这类事情很多，不太容易得到干脆利落的解决。
迭代等方法都很好，另外，项目经理可以再去深入了解一下用户方的目标和开发方（自己所在公司）的目标到底是什么。有时候仅仅关注软件系统本身的功能和性能是不够的，要看软件系统在用户的整体业务中和自己公司的整体业务中承担的角色和可能达到的程度。
对双方的目标有底了，再决定开发工作时就有了心理准备。
页:
[1]