1,268
社区成员
发帖
与我相关
我的任务
分享如何应对客户不断变化的需求!
我承接了一个软件开发项目,这个项目由我一个人负责(以前都是合作开发)单独完成,但是和客户谈需求只是口头上的交谈,没有文字上的需求说明,在开发过程中,用户的需求不断变更,请问,我应该怎么办呀??
...全文
请发表友善的回复…
发表回复
zhulinu 2003-12-05
- 打赏
- 举报
我没有看到有那家公司的需求管理做的比较好.
不能说是软件业的悲哀
不能说是软件业的悲哀
rockrabbit 2003-12-05
- 打赏
- 举报
呵呵，我似乎看到项目的结局。
哇呜 2003-12-05
- 打赏
- 举报
也许现在最重要的还是将文档补全吧，主要是需求规格说明，这样以后有据可查。对于以后所有的大的需求变更，都应该有双方的备忘录，这样他们不至于随意的更改需求。至于系统设计方面可能书上就说得比较多了。
Ruosi 2003-11-29
- 打赏
- 举报
你现在做什么，客户都明白，你是不想做更多的工作，这样下去，等着僵持吧。
你还是等下一个项目吧，签署的文件都没有，怎么开始的。
你还是等下一个项目吧，签署的文件都没有，怎么开始的。
w_rose 2003-11-29
- 打赏
- 举报
而大部分人，虽然口口声声“面向对象”，却并不接受“继承”这种分析设计技术。这样，迭代周期之间的对象没有继承性，当对象需要修改时，一次次“重构”，这不是“找死”还能有什么好结果？
w_rose 2003-11-29
- 打赏
- 举报
不熟练使用OO思想，使用XP是“找死”。每一种方法都是适合特定的思想的。
zcwhgj 2003-11-28
- 打赏
- 举报
使用XP的软件方法，XP拥抱变化。
Fusuli 2003-11-28
- 打赏
- 举报
1.改变对需求变化的态度，需求变化是不可避免的
2.用原型、迭代的开发方法
2.用原型、迭代的开发方法
wuyanfeng 2003-11-28
- 打赏
- 举报
我工作一年多了，做DRP的，其实让我们整个团队最头痛就是需求的不确定，客户有时也不知道自己到底想要什么。但劝你不要着急编码，设计，演练，再设计，再演练，最少重复三次以上，才能保证客户不会发生大的需求变化。
祝你好运。
祝你好运。
rolandash 2003-11-28
- 打赏
- 举报
"所以，为了保证自己的利益，最好的办法就是在项目开始前你要积极的让客户知道他想要什么！"
这句说的很好啊
这句说的很好啊
kseven 2003-11-28
- 打赏
- 举报
一切应该从“公”方面着手，还有就是能尽量从业务方面了解客户，争取主动。
Spielmann 2003-11-28
- 打赏
- 举报
几点建议
1.要和客户有一个良好的合作关系。
2.前期的需求分析要做的充分，一般占整个项目所用时间的15－20％左右。
3.要求客户方提供明确的业务联系人员，当项目出现问题时能及时和客户沟通。如果项目比较大，甚至可以要求客户提供相应的人员全程的参与到项目中。
4.尽可能的将项目分成若干个部分，每个部分完成后要与客户积极沟通，如果在某个部分上发现有需求上的变化时，更改上投入的工作量会相对减小。
5.在整个项目的计划中要给客户在需求上的变化留出充分的时间，避免因客户不断变化的需求导致整个项目在时间、经费、质量上出现问题。
首先得要端正态度！不要以为客户是SB，如果客户自己什么都懂，我们也就没饭吃了！
要向客户说明不断变化的需求将会导致怎样的后果。就国内目前的情况看，一般都是客户想怎样就怎样，价格不变，需求天天变。如果你把需求变化这部分的费用考虑进去，价格就会太高，在价格方面你就很难与其他企业竞争。所以，为了保证自己的利益，最好的办法就是在项目开始前你要积极的让客户知道他想要什么！
1.要和客户有一个良好的合作关系。
2.前期的需求分析要做的充分，一般占整个项目所用时间的15－20％左右。
3.要求客户方提供明确的业务联系人员，当项目出现问题时能及时和客户沟通。如果项目比较大，甚至可以要求客户提供相应的人员全程的参与到项目中。
4.尽可能的将项目分成若干个部分，每个部分完成后要与客户积极沟通，如果在某个部分上发现有需求上的变化时，更改上投入的工作量会相对减小。
5.在整个项目的计划中要给客户在需求上的变化留出充分的时间，避免因客户不断变化的需求导致整个项目在时间、经费、质量上出现问题。
首先得要端正态度！不要以为客户是SB，如果客户自己什么都懂，我们也就没饭吃了！
要向客户说明不断变化的需求将会导致怎样的后果。就国内目前的情况看，一般都是客户想怎样就怎样，价格不变，需求天天变。如果你把需求变化这部分的费用考虑进去，价格就会太高，在价格方面你就很难与其他企业竞争。所以，为了保证自己的利益，最好的办法就是在项目开始前你要积极的让客户知道他想要什么！
michaelli 2003-11-27
- 打赏
- 举报
善于发现客户的潜在要求,另外在分析时要考虑具有可扩展性
zcwhgj 2003-11-27
- 打赏
- 举报
需求不应该都通地口头约定，最好是要形成文档，双方有据可查，这为以后验收打好基础，同时要对方整理需求也可以拖延一点时间出来。
Onega 2003-11-27
- 打赏
- 举报
多用方法，少用公共变量。客户是上帝，指望他们一次想清楚是不可能的，只有让自己的程序经得起折腾
sevenn 2003-11-10
- 打赏
- 举报
软件需求是一个大问题，是很重要的问题，建议：正规程序：双方签署：《软件客户需求权利书》《软件客户需求义务书》。并做好思想工作。
loveisbug 2003-11-07
- 打赏
- 举报
建议用原型法
BloodyCold 2003-11-07
- 打赏
- 举报
再补充点。
尽快将功能实现，但不需要完善，尽快将雏型交给客户检验，在客户的意见上进行修改，直到客户满意为止，再将其进行完善和测试，这样实际上将一部分测试交给客户完成，即使需求变更，也不会太被动。
尽快将功能实现，但不需要完善，尽快将雏型交给客户检验，在客户的意见上进行修改，直到客户满意为止，再将其进行完善和测试，这样实际上将一部分测试交给客户完成，即使需求变更，也不会太被动。
BloodyCold 2003-11-07
- 打赏
- 举报
给你2点建议。
1。想好了再动手。
2。要想在客户前面。
一切都取决于对业务的熟悉。
你好好想想吧。
1。想好了再动手。
2。要想在客户前面。
一切都取决于对业务的熟悉。
你好好想想吧。
