1,265
社区成员
发帖
与我相关
我的任务
分享客户有提出新的需求，怎么办？
在开发中，需求落实是在什么时候的，因为在我现在开发的项目过程中，需求是先做了一点，然后再去收集，在做，在收集。这样的话，客户会不断提出新的需求，但是公司并没有更我们说这个项目定了合同没有，多少钱，只是让我们做。现在发现在客户规定的范围时间内是做不完的。
我觉得奇怪，开发项目应该不会是这样的吧，要是这样的话不就玩死开发人员，客户却占了便宜。
我觉得奇怪，开发项目应该不会是这样的吧，要是这样的话不就玩死开发人员，客户却占了便宜。
...全文
请发表友善的回复…
发表回复
gxdq 2003-02-01
- 打赏
- 举报
to ： 10jqkA(harter) (
经典！！！
经典！！！
badbirdhaveold 2003-01-22
- 打赏
- 举报
进行需求变更，记录、评审、并跟踪！
10jqkA 2002-12-26
- 打赏
- 举报
世界上只有一个客户没有提出3次以上的需求变更，因为他在送第三次变更请求时发生了车祸，死了。
ningIII 2002-12-17
- 打赏
- 举报
正常，呵呵，软件开发就是这样的！
有的用户就不告诉你怎样做，只是说最后要什么东西出来，或者他们也不知道到底要做成个什么样子！所以需求分析就很重要了，具体的我也不在这里罗嗦了！教你个办法，当用户提出新的需求时，先看看自己目前所做的能否适合，若是能加进去，那就OK，若是不行，就要想办法先让用户满意（当然，不能完全妥协）。还有一点最重要，概要设计不是要出最终编码的规范，很多东西是要在详细设计时再完善的，要不然概要设计永远也不能结束。
有的用户就不告诉你怎样做，只是说最后要什么东西出来，或者他们也不知道到底要做成个什么样子！所以需求分析就很重要了，具体的我也不在这里罗嗦了！教你个办法，当用户提出新的需求时，先看看自己目前所做的能否适合，若是能加进去，那就OK，若是不行，就要想办法先让用户满意（当然，不能完全妥协）。还有一点最重要，概要设计不是要出最终编码的规范，很多东西是要在详细设计时再完善的，要不然概要设计永远也不能结束。
jacquiyan 2002-12-03
- 打赏
- 举报
如何在人手短缺，工作量原本就不少的情况下，即可以安抚都客户也可以按步骤开发？
Jinq0123 2002-12-03
- 打赏
- 举报
这里暴露许多问题：
1.需求分析不够深入，没有挖堀出潜在的需求。多花些时间在需求上会好许多。
2.客户不了解需求过程，任意妄为。需求分析开始前，可以与客户一起进行一次需求分析的培训，以求达成一致。
3.没有最基本的配置管理。配置管理将首先确定需求，一旦确定，需求变更须
谨慎进行。
4.开发者的开发过程受到太多干扰。如果代码是直接来自某一版本的详细设计，开发者就可以确保自已不被玩死。
1.需求分析不够深入，没有挖堀出潜在的需求。多花些时间在需求上会好许多。
2.客户不了解需求过程，任意妄为。需求分析开始前，可以与客户一起进行一次需求分析的培训，以求达成一致。
3.没有最基本的配置管理。配置管理将首先确定需求，一旦确定，需求变更须
谨慎进行。
4.开发者的开发过程受到太多干扰。如果代码是直接来自某一版本的详细设计，开发者就可以确保自已不被玩死。
haitaoyu 2002-12-03
- 打赏
- 举报
你的问题是一个很典型的软工问题，主要看你们采用何种开发模式了。象人力资源不足又要快速的话，一般推荐使用RAD快速开发模式，可以比较好的适应这些情况。
xmbill 2002-12-02
- 打赏
- 举报
记录下所有变更,然后进行评估
zag 2002-12-01
- 打赏
- 举报
在需求分析时想完全了解用户的需求是不可能的,只有适可而止,建议在需求前先进行一步立项工作,了解用户真正想要什么样的产品,再进行各项有目的的需求,一旦需求阶段完成后,立即将其纳入基线受控,至于变更,则要有相关的变更手续进行控制了.
happykarol 2002-11-28
- 打赏
- 举报
我觉得你的问题重点是在如何处理需求变更的问题。
第一，用户不变几乎是不可能的（也有，但是我们很少遇到），所以要有一个变的基础，即变化从哪里变。如果没有基础，那么就是客户随便的更改需求。————很烦的，而且这对软件的质量是有负面影响的。
第二，记录下一段时间内（自己或者客户认为合适的范围）客户的变更，讨论解决的可行性和必要性，讨论工期的问题和价格的问题。最后在确定是否实施变更和实施变更的方法和跟踪过程。
第三，定期检查变更的实行情况，满足用户的需求和保证变更按期完成。
第四，不要扯皮，因为你和客户都没有错误。
第一，用户不变几乎是不可能的（也有，但是我们很少遇到），所以要有一个变的基础，即变化从哪里变。如果没有基础，那么就是客户随便的更改需求。————很烦的，而且这对软件的质量是有负面影响的。
第二，记录下一段时间内（自己或者客户认为合适的范围）客户的变更，讨论解决的可行性和必要性，讨论工期的问题和价格的问题。最后在确定是否实施变更和实施变更的方法和跟踪过程。
第三，定期检查变更的实行情况，满足用户的需求和保证变更按期完成。
第四，不要扯皮，因为你和客户都没有错误。
flyingwithoutwings 2002-11-27
- 打赏
- 举报
在软件开发的中，开始你要尽可能多的了解客户的需求，甚至要深入客户（企业）内部去完成你开发前的调查，这大概占开发周期的10%，很重要，要了解客户需求可能会发生的变化。在你的软件建模时，要使用一种可扩展性好的，可多次再开发的模型。当然，开发软件不是一件机械的工作，它需要你有长远的眼光，需要你大胆地尝试。满足客户就是成功！
cgb_prince 2002-11-27
- 打赏
- 举报
太正常了！
knoppix 2002-11-26
- 打赏
- 举报
> 要是这样的话不就玩死开发人员，客户却占了便宜。
要想不被玩死, 就要想办法去适应需求的变化。
世界上只有一种东西不会变化，那就是“变化”本身。
客户就是上帝，你应该去满足客户的所有需求。
要想不被玩死, 就要想办法去适应需求的变化。
世界上只有一种东西不会变化，那就是“变化”本身。
客户就是上帝，你应该去满足客户的所有需求。
xwmhn 2002-11-25
- 打赏
- 举报
在开发之前，获得全部需求是不可能的,但你可以尽量获取客户的需求，这样才能减少你们工作被动的局面，最重要的是要向客户的需求进行调研。这样客户和公司之间的关系比较融洽。
webcat 2002-11-25
- 打赏
- 举报
在开发之前，获得全部需求是不可能的，但是应获得几乎全部的关键需求，这样你才能构建一个能够持续改进的体系结构。本来，开发过程是不断迭代和增量的，需求变了，就要对需求进行评估，是否是关键需求，如果是那就没有办法了，只好从底层改，如果不是，可与用户协商解决
anxue 2002-11-25
- 打赏
- 举报
需求变更是不可避免的，有时候甚至做的原型整个都要抛弃，
因为需求部门可能都不清楚自己真正想要的是什么。
但是一旦开始做--进行详细设计的时候就不能随便改变需求了，
概要设计阶段有时候需求变更还可以忍受。
软件工程做得好的公司都有一个需求变更委员会专门负责这一块。
因为需求部门可能都不清楚自己真正想要的是什么。
但是一旦开始做--进行详细设计的时候就不能随便改变需求了，
概要设计阶段有时候需求变更还可以忍受。
软件工程做得好的公司都有一个需求变更委员会专门负责这一块。
AechoJohn 2002-11-25
- 打赏
- 举报
需求的更改和新加是现在做软件没法子的事，就像两位楼上的兄弟说的那样，开发之前尽量获取关键的需求，讨论一些以后可能的需求，以后用户要添的话，如果提出的是关键的主要的也是合理的话，那没法子，至于其他的尽量与客户解释协商，千万不要什么样的需求都答应下来，要不然公司可就离死不远了：）
