1,265
社区成员
发帖
与我相关
我的任务
分享请教怎么控制客户没完没了增加功能到需求中
正在做一个项目,客户没完没了增加功能,我们这边的人都顶不住,只有被动接受.
请教一个好方法,让客户停止增加新的需求.
请教一个好方法,让客户停止增加新的需求.
...全文
请发表友善的回复…
发表回复
meidengyin 2005-06-06
- 打赏
- 举报
最好是做产品,而不是做项目。
项目需求的东西有些很抽象,客户以为是个豪华公寓、开发人员是个简单适用的住宅。
有了一个产品，核心的东西就是这样,双方就不会产生认识上的偏差了。
项目需求的东西有些很抽象,客户以为是个豪华公寓、开发人员是个简单适用的住宅。
有了一个产品，核心的东西就是这样,双方就不会产生认识上的偏差了。
HowcanIdo 2005-05-27
- 打赏
- 举报
对于每个业务来说，都有其核心部分，如果要按时完工，抓住核心部分就ok，其它增加的需求放到系统升级中去做
我曾听一个用户这样对开发人员讲：
你们这样做骗不了我，只能骗你们自己。我问题我迟早会发现，你们必须在我提出之前自觉地给我解决，否则你们只会浪费自己的时间。
如果我的客户这样对我说，他惨了：）当然要公司配合
一般的项目付费：30％项目启动费，项目完成实施再付50％，试运行完10％，客户验收完最后10％，
最后的10％很难要的，一般都在一年后客户才会验收，即使验收他也会提出这样那样的问题。所以这10％很多时候就当它不存在，所以他惨了，在后期维护时，软件费用已经收了90％，反正收不到，不给你好好维护，还行，求我了吧
当然，如果签了服费维护协议林当别论
我曾听一个用户这样对开发人员讲：
你们这样做骗不了我，只能骗你们自己。我问题我迟早会发现，你们必须在我提出之前自觉地给我解决，否则你们只会浪费自己的时间。
如果我的客户这样对我说，他惨了：）当然要公司配合
一般的项目付费：30％项目启动费，项目完成实施再付50％，试运行完10％，客户验收完最后10％，
最后的10％很难要的，一般都在一年后客户才会验收，即使验收他也会提出这样那样的问题。所以这10％很多时候就当它不存在，所以他惨了，在后期维护时，软件费用已经收了90％，反正收不到，不给你好好维护，还行，求我了吧
当然，如果签了服费维护协议林当别论
yohomonkey 2005-05-18
- 打赏
- 举报
关注中...
futuredreams 2005-05-17
- 打赏
- 举报
由于需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级以上对需求变更做了详细规定。
我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
p2bl 2005-05-16
- 打赏
- 举报
这是现在大部分软件公司遇到的一个难题吧。尤其某些领域，项目之间功能的重复很少，而客户又非常强势，通常是客户促进你进行瀑布式开发，解决的方法？我也不知道！
lisir010 2005-04-25
- 打赏
- 举报
呵呵,我觉得是搂住的项目经理不行
是指社交上,业务上也不行
需求刚开始就应该定下来
即使有些遗漏,在开发过程中,应该针对实际情况调整,不是客户说加就加得
那样不仅仅是对自己不负责,也是对客户不负责
因为杂同事浪费大家得时间
如果能用,就先用,好的需求可以下一个版本解决呀,
有可能用了一段时间,客户有更好得解决办法呢
是指社交上,业务上也不行
需求刚开始就应该定下来
即使有些遗漏,在开发过程中,应该针对实际情况调整,不是客户说加就加得
那样不仅仅是对自己不负责,也是对客户不负责
因为杂同事浪费大家得时间
如果能用,就先用,好的需求可以下一个版本解决呀,
有可能用了一段时间,客户有更好得解决办法呢
vccsdn 2005-04-25
- 打赏
- 举报
如果改了很多业务需求,那就是没有做需求调研或者调研时没有得到客户的真正需求
okitgo 2005-04-22
- 打赏
- 举报
需求变更-->加钱
liangyong007a 2005-03-04
- 打赏
- 举报
加功能收银子
hilite2000 2005-03-04
- 打赏
- 举报
可能你的用户还没有真正清楚他们想要什么
或者不能一下子明白自己想要什么，或者能要什么。
所以可以先做个原形，引导出他们的需求，要注意区分功能性需求和非功能性需求。
评审，指定优先级，然后在一定时期内固定需求。
当然你的软件也应该适应变化。
当你觉得需求总在变的时候，是否意识到自己真正理解需求。
或者不能一下子明白自己想要什么，或者能要什么。
所以可以先做个原形，引导出他们的需求，要注意区分功能性需求和非功能性需求。
评审，指定优先级，然后在一定时期内固定需求。
当然你的软件也应该适应变化。
当你觉得需求总在变的时候，是否意识到自己真正理解需求。
gzlucky 2005-03-04
- 打赏
- 举报
现实中，大部分项目都会有需求变更。变更是正常的，应该在开始时就要了解到。
从我所在地描述中可以看出有几个在项目开始前就埋下的炸弹：
1. 需求不清晰。不管是客户，还是开发商都没有明确需求，客户不清楚自己要什么，开发商也没能利用自己的经验告诉客户应该做一个什么样的系统。这种情况下不适宜使用瀑布型开发。应先做一个试验性的产品，用演化模型或螺旋型比较好。
2. 需求说明书好象没有强制性。需求说明书没有得到很好的实践，或者有很多模糊的不规范的地方，从而导致需求不断改变。
. 如果需求增加严重的话，应该暂停项目，双方重新确定需求，那怕项目要延时，这也是可预计的。
. 规范化需求变更制定。每一个变更都要双方项目签字确认，并定期通布双方的领导管理层。每一个变更写出变更的影响范围，人员，时间等。让大家都知道是什么原因让项目延时的。因为对于一个项目来说，IT人员和业务人员的想法是不一样的。业务人员要的是一个按时完成的可用的系统，IT人员要的是一个完美的系统，你要善于利用两者间的差别。
从我所在地描述中可以看出有几个在项目开始前就埋下的炸弹：
1. 需求不清晰。不管是客户，还是开发商都没有明确需求，客户不清楚自己要什么，开发商也没能利用自己的经验告诉客户应该做一个什么样的系统。这种情况下不适宜使用瀑布型开发。应先做一个试验性的产品，用演化模型或螺旋型比较好。
2. 需求说明书好象没有强制性。需求说明书没有得到很好的实践，或者有很多模糊的不规范的地方，从而导致需求不断改变。
. 如果需求增加严重的话，应该暂停项目，双方重新确定需求，那怕项目要延时，这也是可预计的。
. 规范化需求变更制定。每一个变更都要双方项目签字确认，并定期通布双方的领导管理层。每一个变更写出变更的影响范围，人员，时间等。让大家都知道是什么原因让项目延时的。因为对于一个项目来说，IT人员和业务人员的想法是不一样的。业务人员要的是一个按时完成的可用的系统，IT人员要的是一个完美的系统，你要善于利用两者间的差别。
futuredreams 2005-03-04
- 打赏
- 举报
由于需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级以上对需求变更做了详细规定。
我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。
许野平 2005-03-04
- 打赏
- 举报
我曾听一个用户这样对开发人员讲：
你们这样做骗不了我，只能骗你们自己。我问题我迟早会发现，你们必须在我提出之前自觉地给我解决，否则你们只会浪费自己的时间。
呵呵，公道不公道，只有天知道！
你们这样做骗不了我，只能骗你们自己。我问题我迟早会发现，你们必须在我提出之前自觉地给我解决，否则你们只会浪费自己的时间。
呵呵，公道不公道，只有天知道！
kylin__2000 2005-03-03
- 打赏
- 举报
我遇到的一种情况：需求与实际情况不沾边。
这种情况下，你能不变更吗？所以我认为，需求变更的原因很大部分也是源自于需求调研的随意。
1、需求写太简单或者全是废话，不具备可操作性。
2、需求不能反映实际情况，不具备有效性。
所以开发出来的系统也不具备可操作性，开发人员做的工作也就不具备有效性，就是瞎忙活,做得越多错得越多。
这种情况下，你能不变更吗？所以我认为，需求变更的原因很大部分也是源自于需求调研的随意。
1、需求写太简单或者全是废话，不具备可操作性。
2、需求不能反映实际情况，不具备有效性。
所以开发出来的系统也不具备可操作性，开发人员做的工作也就不具备有效性，就是瞎忙活,做得越多错得越多。
chinadrencher 2005-03-01
- 打赏
- 举报
我们用户也是.
需求不断增加是他们对付公司的一个策略.功能一点一点给加上去.并且是在第二次大的增加才告诉我们需求人员的.殊不知,这样的软件如何去进行好的架构设计.
并且他们自己的意见是.看到我们一个基线版本.再在上面提要求. 这样的结果是把很多以前做的模块的表现给改变了. 甚至死活要加上的小模块.又给随意砍掉了--这个是项目经理的问题.过于随意.
在界面上,为了美观,也不停地要换这个图片,那个位置的.
甚至最后项目经理顶不住了.用户方就和公司协调.直接指挥开发人员.有问题就调整.项目经理只有从了.
客户还是中央级的安全部门的技术单位.
我靠.简直垃圾项目. 现在项目是小问题多多.堵了这个.另一个又出来了.
政府部门的信息中心的落后,或者说用户的不成熟.很难把项目做得成功和完善.
需求不断增加是他们对付公司的一个策略.功能一点一点给加上去.并且是在第二次大的增加才告诉我们需求人员的.殊不知,这样的软件如何去进行好的架构设计.
并且他们自己的意见是.看到我们一个基线版本.再在上面提要求. 这样的结果是把很多以前做的模块的表现给改变了. 甚至死活要加上的小模块.又给随意砍掉了--这个是项目经理的问题.过于随意.
在界面上,为了美观,也不停地要换这个图片,那个位置的.
甚至最后项目经理顶不住了.用户方就和公司协调.直接指挥开发人员.有问题就调整.项目经理只有从了.
客户还是中央级的安全部门的技术单位.
我靠.简直垃圾项目. 现在项目是小问题多多.堵了这个.另一个又出来了.
政府部门的信息中心的落后,或者说用户的不成熟.很难把项目做得成功和完善.
sml99301 2005-02-25
- 打赏
- 举报
需求的变更是不可必免的，只能去尽量减少，不管你前期需求做得多么详细，因为大部的用户都不清楚他们的系统真正是怎么样的，一般都是等你开发完，试用行时就什么问题都来的。我个人觉得在做需求时应尽量少用模糊的字眼如“等”什么之类的，到时客户就会针对这些字眼跟你没玩没了的，钱在他们手上你没有不做的理由。至于一些在需求合同上没定的功能，我想还是可以通过沟通，分析成本与期限等来解决的。
zrb007 2005-02-25
- 打赏
- 举报
合理控制了，把需求按照紧急程度和重要程度进行分类，先做最重要和最紧急的，还有就是要明确需求是否超过合同范围，也许你可以根据需求发现新的项目呢，哈哈
cnepine 2005-02-21
- 打赏
- 举报
其实,我认为这个只能去适应.
根据当初的合同,看能否增加开发经费.
根据当初的合同,看能否增加开发经费.
jacklondon 2005-02-21
- 打赏
- 举报
项目经理正在与客户谈，一方面加钱，一方面砍需求。
我开始学习 PMP, 希望能够学到点东西
我开始学习 PMP, 希望能够学到点东西
偷得浮生半日闲啊~ 2005-02-17
- 打赏
- 举报
保证现有需求的正确完成。
用“加钱”卡住用户的需求增加。
可以使用如下流程。（变更管理）
需求变更--〉双方签字（需要时间——〉成本《钱》）--〉变更
中心思想是没钱就不变（目前），可以在加钱升级时变化。
另外一定要有一个阶段的目标监测点。就是进度管理。
愚见，请高手指点。
用“加钱”卡住用户的需求增加。
可以使用如下流程。（变更管理）
需求变更--〉双方签字（需要时间——〉成本《钱》）--〉变更
中心思想是没钱就不变（目前），可以在加钱升级时变化。
另外一定要有一个阶段的目标监测点。就是进度管理。
愚见，请高手指点。
加载更多回复（18）
