如何应付项目中的细节需求？

  在项目开发中，有时候遇到非常细心的用户，经常在看到界面成品的时候，不断的提出细节需求，如这个地方应该有图有列表（原先是有图的），这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围，但是如此反复提出细节需求（多的达到8次），势必会增加项目中的成本，请问下大家对这样的事情有什么看法？

  另外做项目的时候有两个出发点，第一控制项目的成本，第二将项目做好，我认为把项目做好，但是把项目做好势必会增加项目的成本，两者如何平衡呢？

评论

30 楼 miaow 2010-03-27  

jcs7575 写道

开发之前需求确认，确认后不允许需求变更。

也许我孤陋寡闻，我从来没见过不改的。
就08年有个项目差点做到，也没熬到最后，破了功。

29 楼 fsxxl 2010-03-26  

象这样的细节修改可以说非常之多，大部份情况下，都是拍脑袋想出来的，站在自己的角度利益，并且有可能破坏整个软件的流程，千万不能被用户迁着走，所有提出的需求由用户书写明细的文档说明如何改进，并且审批确认，这样的话，他对自己提出的需求就会进行深思考虑是否真的需要。

由经验评判需求的分类，合理的要求，真正可以帮助用户的，就尽可能满足。不合理的、可有可无的、十年不用一次的，就进行解释，或者说，先这样用着看看，用户其实就会慢慢的适应了，否则单在一个地方就转到你出不来。

最可怕的需求就是，用户本身素质不高，用过其他别的软件，然后将其他软件的功能作为需求提出。有些时候，完全不懂的还好过。

28 楼 beckrabbit 2010-03-04  

jcs7575 写道

开发之前需求确认，确认后不允许需求变更。

“不允许”恐怕难以实现。

27 楼 jcs7575 2010-03-04  

开发之前需求确认，确认后不允许需求变更。

26 楼 tangshd 2010-03-03  

androider 写道

seeckt 写道

1、细节是实现方式，需求是用户真的想要什么。这两个要分清楚，能够让他使用，并且好用就行，并不是他坚持图在表下面1CM你就不能挪到下面1.5CM。
2、让提问题的人和付钱的人是同一个人，否则随便找个谁到处提问题又不必掏钱那提点啥的还不容易么？
CCB的意思就是虽然需求是到各个用户那去采集的，
但是能做客户方确认的人只有一个，而那个人需要知道提范围外的需求需要付出一定的代价.
2其实比1更重要

这是没办法的事情，拥抱变化吗，嘿嘿，这是正常的，重要的是，得帮客户分析，在你真正开始做之前，跟客户分析清楚他需要什么，最起码再大的方向确定下来，否则这些东西要是在后期变更还是很恐怖的。对于项目进程中的细节问题还是应该修改，只要是客户需要的，不管什么，但是有些问题是可以跟客户沟通的，比如某个地方需要编辑功能，问问他是不是确实需要，用这个干什么的，如果他确定需要，那就给他一个评估时间，这里面沟通能力就极其重要了，你要让客户时刻都感觉到你是在为他着想，在这种长期的环境影响下，你否决他的一个请求（当然否决的方式也是出于为他考虑的方式）概率就很高了，而且还能得到客户的赞赏：）

其实跟掏钱的人谈是没用的，因为项目基本上在开始动手之前，钱就谈好了，最好就是从时间上来搞定，如果时间无所谓，就帮他做吧，这些成本还是得付出的，所以开始谈钱的时候，多少钱很关键。

同意您的观点, 说的很不错~~

25 楼 nijian 2010-03-03  

需求不是成本增加的根源，细节需求是软件开发的一部分

24 楼 pochonlee 2010-03-03  

页面画出来，按照页面来

23 楼 seeckt 2010-03-03  

引用

一般出现用户死磕界面的情况，要么你把界面做得震撼能满足客户，要么商务解决。

有种可能是每个客户的领导背后都有一家有关系的供应商
如果在换过客户方领导的时候被死磕界面其实是他想换自己有关系的那个供应商
要么联系他的上级领导给他施压
如果搞不定最好保证项目盈利，自己识相点乘早退出，别人也不折腾你了

22 楼 seeckt 2010-03-03  

关心界面的领导是你的领导还是客户的领导？
如果是客户的领导
很清楚最后合同的价格应该在双方底线内
如果因为折腾了很长时间界面，造成成本突破软件公司能够承受的底线
结果不是终止这次或下次合作关系就是想办法从别的功能点上捞回来
只要暗示对方这个潜规则就行

如果是开发方的领导
想把产品做精应该是好事，因为成本是领导出，
项目经理应该提醒进度和成本
项目组倒霉纯粹是项目经理未够班啊
乱承诺别人的要求又不提出对方应该额外付出的代价
一将无能累死三军

21 楼 fantasy 2010-03-03  

beckrabbit 写道

seeckt 写道

引用

当对界面斤斤计较的人不是客户，而是公司的领导怎么办？现在功能完成的不多，界面倒是快做到元素px级别了

是公司领导最好，马上拉销售一起拜访一次
既然大家都是生意人，当然知道所有的成本必须被覆盖
不需要明说，只要销售暗示反复折腾界面会造成乙方成本增加，
然后搞开发的说重要需求的处理资源被占用就行了

我们现在是在做产品，领导只关心界面好看就行了，精雕细琢，还请了外包美工，用了相当多的时间在界面，基本不怎么关心功能的实现，还定死了最后的工期，功能还有大块没做或者没和界面联调，最后倒霉只能是项目组了。

只所以领导只关心界面是因为客户在向领导邀功的时候，能让领导看懂的也只有界面，当然界面是用户的第一感觉，功能缺点，用户都能接受，界面不好看，用户绝对不能接受。
一般出现用户死磕界面的情况，要么你把界面做得震撼能满足客户，要么商务解决。

20 楼 beckrabbit 2010-03-03  

seeckt 写道

引用

当对界面斤斤计较的人不是客户，而是公司的领导怎么办？现在功能完成的不多，界面倒是快做到元素px级别了

是公司领导最好，马上拉销售一起拜访一次
既然大家都是生意人，当然知道所有的成本必须被覆盖
不需要明说，只要销售暗示反复折腾界面会造成乙方成本增加，
然后搞开发的说重要需求的处理资源被占用就行了

我们现在是在做产品，领导只关心界面好看就行了，精雕细琢，还请了外包美工，用了相当多的时间在界面，基本不怎么关心功能的实现，还定死了最后的工期，功能还有大块没做或者没和界面联调，最后倒霉只能是项目组了。

19 楼 seeckt 2010-03-03  

引用

当对界面斤斤计较的人不是客户，而是公司的领导怎么办？现在功能完成的不多，界面倒是快做到元素px级别了

是公司领导最好，马上拉销售一起拜访一次
既然大家都是生意人，当然知道所有的成本必须被覆盖
不需要明说，只要销售暗示反复折腾界面会造成乙方成本增加，
然后搞开发的说重要需求的处理资源被占用就行了

18 楼 beckrabbit 2010-03-02  

当对界面斤斤计较的人不是客户，而是公司的领导怎么办？现在功能完成的不多，界面倒是快做到元素px级别了

17 楼 fantasy 2010-03-02  

<div class="quote_title">karisen 写道</div>
<div class="quote_div">
<div class="quote_title">fantasy 写道</div>
<div class="quote_div">
<p>  在项目开发中，有时候遇到非常细心的用户，经常在看到界面成品的时候，不断的提出细节需求，如这个地方应该有图有列表（原先是有图的），这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围，但是如此反复提出细节需求（多的达到8次），势必会增加项目中的成本，请问下大家对这样的事情有什么看法？</p>
<p>  另外做项目的时候有两个出发点，第一控制项目的成本，第二将项目做好，我认为把项目做好，但是把项目做好势必会增加项目的成本，两者如何平衡呢？</p>
</div>
<p> </p>
<p>不知LZ 的项目用什么模型？瀑布？迭代？……</p>
<p>采用什么方法挖掘客户需求的？</p>
<p> </p>
<p> </p>
</div>
<p>迭代，但很多时候迭代期不是预先计划的，而是用户临时提出需求，我们被迫再迭代一次开发周期。</p>
<p>挖掘用户需求会根据项目的大小和时间而不一样，有原型法，截图+人工讨论法。</p>

16 楼 karisen 2010-03-01  

<div class="quote_title">fantasy 写道</div>
<div class="quote_div">
<p>  在项目开发中，有时候遇到非常细心的用户，经常在看到界面成品的时候，不断的提出细节需求，如这个地方应该有图有列表（原先是有图的），这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围，但是如此反复提出细节需求（多的达到8次），势必会增加项目中的成本，请问下大家对这样的事情有什么看法？</p>
<p>  另外做项目的时候有两个出发点，第一控制项目的成本，第二将项目做好，我认为把项目做好，但是把项目做好势必会增加项目的成本，两者如何平衡呢？</p>
</div>
<p> </p>
<p>不知LZ 的项目用什么模型？瀑布？迭代？……</p>
<p>采用什么方法挖掘客户需求的？</p>
<p> </p>
<p> </p>

15 楼 一蓑烟雨任平生 2010-02-25  

细节的需求可以分成两种：业务规则的细化，另一种是界面展现和操作风格的。

前者没有什么好的办法，看业务顾问的经验，用户提出来就应该做评估和修正，我的经验是最后还是要改的，只是看客户关系怎样，能不能走变更流程。

而后一种，就非常复杂，我的意见是在项目的技术协议阶段就最好能明确界面的展现和操作风格，原则上不允许对这块做大的修改，如果因为修改导致工时的增加则要求额外付费。

反过来也对我们自己的能力要有要求，一块是业务，一块是基础的标准，业务能力靠经验的积累和外部资源的帮助，基础标准则要提前做好准备。

项目中可以变化的是业务规则，基于这个概念考虑问题。

14 楼 yschen 2010-02-25  

任何的需求变更都需要客户签单，就算再小也好，我也试过这样的项目，今天他说这样，明天他又说那样，后来就直接签单的方式，就少了这样的要求了。

13 楼 fantasy 2010-02-23  

seeckt 写道

引用

“把项目做好会增加成本的问题”

这个观点很奇怪

做好了对甲乙双方都是增值，怎么会增加成本？

这个问题源于项目目标不明确
有两种可能：
1、甲乙双方对“好”的定义不一致，甲的目标如果是“打造世界一流的XX系统”，那么乙方基本上怎么做都是失败的
甲方想让乙方达到他心中的“好”，对乙方必然是增加了成本
2、对项目计划范围外的变更价值严重低估

特别是1、2并存的时候，通常乙方很吃力的做完很多功能，被甲方认为是本就应该做的，收不到钱还挨批

您说的很有道理。
在我们公司，做好会增加成本的问题，主要来源于需求不是我们产品的有意义功能。
如我们是做安管的，但是用户非常关心把安全论坛做好，提出很多这个模块的需求，而这个模块又恰好不是我们产品的重心和核心模块，不断的开发只会不断的增加成本，做一些对我们产品没有很高意义的需求。

12 楼 tuzipp 2010-02-11  

感觉项目开始时，首先敲定一个DOME，用HTML做出一个轮廓，有链接，JS功能倒是其次，然后给客户演示一下大体的操作步骤，比如“从哪个页面进去，进行什么操作，然后转到哪个页面”之类的。就算页面时空的，写几个字表示一下也可以。
项目中的二八原则，20%的功能解决了80%的需求。80%的时间用于解决那20%的需求。先把那些“大功能”、“主要的”完成，估计没有那么多的人那么较真……

11 楼 seeckt 2010-02-11  

引用

“把项目做好会增加成本的问题”

这个观点很奇怪

做好了对甲乙双方都是增值，怎么会增加成本？

这个问题源于项目目标不明确
有两种可能：
1、甲乙双方对“好”的定义不一致，甲的目标如果是“打造世界一流的XX系统”，那么乙方基本上怎么做都是失败的
甲方想让乙方达到他心中的“好”，对乙方必然是增加了成本
2、对项目计划范围外的变更价值严重低估

特别是1、2并存的时候，通常乙方很吃力的做完很多功能，被甲方认为是本就应该做的，收不到钱还挨批