Always relate any request to money. The people that come up with these requests are usually more concerned about money so make sure they are aware that it will cost them more because:
it is going to take longer
it is likely to introduce more bugs
it is likely to slow down maintenance
it will slow down development of new features relating to it
I find the phrase "shall we do that in phase two?" works wonders, possibly backed up with "I think we can manage without it to start with - let's get something out the door first".
您选择的武器应该是估计。 可笑的功能，通常伴随着可笑的估计。 当必须具有功能 X 得到 3 人年的估计时，它会神奇地变成，很高兴拥有功能 X。
Your weapon of choice should be the estimate. Ridiculous functionality, usually comes with a ridiculous estimate. When must have feature X gets a 3 man year estimate, it magically turns into, nice to have feature X.
没有人再看《星际迷航》TNG 或 TOS 了吗？ 请记住，一号会让皮卡德船长知道任何错误，有时让-吕克会同意，有时则不会。 这就是我要说的
If it is a customer and technically possible to do, and you can do it, get a statement of work - and do it.
If it is a job you have, you do the same as anything else. You say, "Yes, sir (or ma'am), I'll be happy to do that. And I don't mind doing it at all. I just thought you might want to know how this would impact our other systems or budget. Not saying you're wrong, just saying that maybe we should think about this a little bit. Is that okay?"
If they say no, well, they signed off on it and you do it. If you really concerned, document your conversation where your advice was not heeded. Remember, if you don't document it it didn't happen. If they listen, then you win a friend.
This would be the same for any job - computer, construction worker, whatever.
EDIT:
I took this from my comment below:
Doesn't anyone watch Star Trek anymore TNG or TOS? Remember Number One would let Captain Picard know of anything wrong and sometimes Jean-Luc would agree and sometimes he wouldn't. That's all I'm saying
我会花时间礼貌地倾听，如果有多个请求，请他们优先考虑这些请求，并以书面形式获取请求，最好是“签字”或您拥有的任何程序。 然后告诉您的经理/客户，您将审查这些请求，并向他们反馈估计情况及其对您的日程安排的影响。 解释一下，仅仅为了生成这些数据，您将需要花费 X 小时（或天），因此您的其他工作将被延迟......
I would take the time to listen politely, if there is more than one request ask them to prioritise them and get the request in writing, idealy "signed off" or whatever procedure you have. Then tell your manager / customer that you will review the requests and get back to them with estimates and the impact it will have on your schedule. Explain that just to produce these data you will need to take X number of hours (or days) and therefore your other work will be delayed...
Then come back with estimates - if the request was ridiculous then your estimate is likely to reflect that:-)
If your manager / customer wants to proceed and waste lots of time and money then at least you have made it clear up front and you have done what you can to help them.
If at all possible you should ask them to defer such requests until a future phase, suggest you look at it in the next version (I think a couple of other replies mentioned this idea already).
A good software designer will restrain from calling a feature request ludicrous. You've got to trust your gut feeling, but it's just a good indication that you want to consider the problem carefully.
Be able to explain where in your opinion the problem with the proposed feature lies. Paul Graham has an excellent piece called "How to Disagree".
These two simple steps will help you and users to deepen the understanding of the actual problem. Software is meaningless without users, most of us depend on users paying for it. Work with the users instead of alienating them with an attitude that may appear insulting.
Some "ridiculous" feature requests have their roots in very intresting and hard to solve problems.
These are all good answers. You need hard data (if it's possible to generate it), "believably ridiculous" estimates, and, most of all, respect.
Johnny's answer was right on in essence, if not in the exact words (I'd comment if I'd built enough rep). In some cases, though, using those exact words might create enough dissonance to get the requestor to take a second look at the content of your objections. And yes, this applies to any project-based endeavor: software, advertising design, even (gasp!) construction. Not that the grunt carrying the mortar will have the grounds or clout to object to flawed design, but the construction lead does have an obligation to tell the architect if his plans are unbuildable.
If all else fails, document the discussion & build it anyway. It's no longer your responsibility.
Ridiculous feature requests fall into two camps for me when responding to them.
Feature will cause the application to stop functioning as expected, i.e. breaks it, slows it down too much, makes it unworkable
Feature that will not cause the application to stop functioning as expected but I don't understand why you'd want such a feature
For type 1 I'll analyse the request and respond with either hard facts or professional opinion. If the analysis indicates that it may be possible with additional effort on existing code then estimate and estimate high!
For type 2, firstly I'll ask the requestor to explain the feature in more detail, after all they may work in an area of the business that I don't have a clear understanding of beyond the problem space for the original application spec. If I still don't get it and I really cannot see the purpose of the feature then I estimate high to discourage them.
If they accept the estimate or I do, finally, get it then I do it.
At the end of the day, they are the customer and if a customer goes into the tailor and asks for trousers with 4 legs, the tailor may argue for a while but in the end it's a custom job and far more expensive. So if they see enough value in the feature that they are willing to pay be willing to take their money; just because you can't see the value doesn't mean they are wrong.
I think the only thing you can do is very concisely describe the major issues that the change request will bring up to the people involved. At my place of work we have the same problem as you do.
Some of the change requests force the developers to jump through hoops just to get it done and in the end it results in less maintainable code for a feature someone upstairs thought would be a good feature.
In my experience there is really nothing you can do to stop this and eventually management will start complaining about how long development is taking etc etc. It's a horrible crappy cycle which will either end in the site being re-built or your team spending eternity in code hell.
你们共同意识到这确实很好，但这是不可能的。 通常，根据我的经验，发生这种情况是因为您需要对大型闭源应用程序进行更改 - 在这种情况下，您只需向供应商提出功能请求，这对于非技术人员来说更令人满意对于技术人员来说； Microsoft 不会对 Excel 进行更改，因为一家小公司要求他们这样做！
I find that most of the time people asking for the impossible don't realise why what they are asking for is such a problem.
Generally, I just ask for more and more clarification of the requirement and more and more detail until:
A lightbulb comes on in my head, I realise what they are trying for and I can say "ah, what you really want is X, not Y". At which point they will generally say "yeah, that's what I was saying all along".
They realise how unrealistic they are being and they withdraw the request
You jointly realise that it would be really good but it's not possible. Usually, in my experience, that one happens because you'd need to make a change to a large closed-source application - in which case, you just make it a feature request to the supplier, which is more satifying for non-techies that for techies; Microsoft don't make changes to Excel because one small firm asked them to!
Customer created requirements can be a major cause of this problem. The issue is that the customer sometimes tries to do a software developer's job.
They have a problem and then work out what feature they will solve that problem. Unfortunately some (most) of these poor souls aren't very good at software design hence you get a very curious feature at the end of it.
A way to remove some of these kind of retarded features is just via the recursive .Why() function. Keep asking why until you find their problem and then design the feature yourself. In a lot of scenarios you can re-design it in a way that is simple, inexpensive and satisfies all parties.
There are also times where what seems to be a ridiculous functionality request does actually pan out to be a good one. There are times where software developers (and I have caught myself doing this in the past) say no to a reasonably complex but highly useful feature that will make the company a lot of money. So when you encounter a "ridiculous" feature be sure to calculate its potential value to the business before instantly dismissing it.
It's too expensive: I argue that the customers need must be worth the money to spend
It's just unnecessary stuff: I try to explain that the customer can't use it. If they still want it, they can have it.
It's against existing concepts: This is actually "too expensive" of the kind "unaffordable". They won't get it.
I like to discuss about requirements :-)
Edit:
A Typical discussion
Marketing Guy: Next to this table we need a button to provide function X to the selection.
Developer: But we need additional parameter P for function X
M: Parameter P is obvious is many cases
D: But we have to cover all cases. We need to prompt for P
M: No! Users don't like to be prompted for obvious values! They just want to "click and go".
D: It's impossible in this case. We need to prompt.
M: (accommodating) Can't you guess it and only prompt if really really necessary?
D: It's hard to guess reliably. Actually takes weeks or even month to implement and it's a high risk. What if we guess wrong? We'd need artificial intelligence for this.
M: But it's very simple: Always in case blahblah, we know P
D: Yes, sure, but we don't know what the user knows.
M: Hm. You developers are always so complicated.
D: ...
M: So, can you do it or not?
D: No.
M: Why?
D: (irritated) I just explained. After all, do you think the user likes that the system guesses P if he actually wants to decide?
M: You just have to guess what the user decides.
D: But where do I know?
M: It's this situation blahblah ...
D: I know, but it's not as simple as that.
M: Ok, I go to the project leader, he will give you a task.
We have sometimes such requests coming from product managers.
In one case I explained there were going to be performance issues and the senior guy confirmed that so we won.
The next time and raised a similar concern but the senior guy wasn't available, so I just did what they wanted because noone really cared. I decided no to as well.
You probably mean things like sending a multi-criteria request to the database, showing the results and at the same time showing which one of all those criteria had a hit. Guessed it?
Sometimes you can explain why the functionality is ridiculous, and the functionality is dropped.
Sometimes you can get someone more senior to say "no" for you.
Sometimes you are senior (or influential) enough to say "no" for yourself.
Sometime you can say "yes", but give the task a low priority (and never do it).
Sometimes you just have to get on with it.
In the latter case, you should make sure to do the task very, very well indeed. Why? You will shine, and as you do so, the shadow of the ridiculous will be brought into focus.
发布评论
评论（14）
始终将任何请求与金钱联系起来。 提出这些请求的人通常更关心金钱，因此请确保他们意识到这会花费更多，因为：
Always relate any request to money. The people that come up with these requests are usually more concerned about money so make sure they are aware that it will cost them more because:
我发现了“我们应该在第二阶段这样做吗？”这句话。 创造奇迹，可能是因为“我认为我们可以在没有它的情况下进行管理——让我们先把一些东西拿出来”。
I find the phrase "shall we do that in phase two?" works wonders, possibly backed up with "I think we can manage without it to start with - let's get something out the door first".
您选择的武器应该是估计。 可笑的功能，通常伴随着可笑的估计。 当必须具有功能 X 得到 3 人年的估计时，它会神奇地变成，很高兴拥有功能 X。
Your weapon of choice should be the estimate. Ridiculous functionality, usually comes with a ridiculous estimate. When must have feature X gets a 3 man year estimate, it magically turns into, nice to have feature X.
如果是客户并且技术上可以做到，并且您可以做到，则获取工作说明书 - 并执行。
如果这是你的工作，你就会像做其他事情一样做。 你说，“是的，先生（或女士），我很乐意这样做。而且我根本不介意这样做。我只是想你可能想知道这将如何影响我们的其他系统或并不是说你错了，只是说也许我们应该考虑一下，可以吗？”
如果他们拒绝，那么他们就签字了，你就去做。 如果您真的担心，请记录您的建议未被听取的谈话。 请记住，如果您不记录下来，那么它就不会发生。如果他们倾听，那么您就会赢得一个朋友。
这对于任何工作都是一样的——计算机、建筑工人等等。
编辑：
我从下面的评论中摘取了这一点：
没有人再看《星际迷航》TNG 或 TOS 了吗？ 请记住，一号会让皮卡德船长知道任何错误，有时让-吕克会同意，有时则不会。 这就是我要说的
If it is a customer and technically possible to do, and you can do it, get a statement of work - and do it.
If it is a job you have, you do the same as anything else. You say, "Yes, sir (or ma'am), I'll be happy to do that. And I don't mind doing it at all. I just thought you might want to know how this would impact our other systems or budget. Not saying you're wrong, just saying that maybe we should think about this a little bit. Is that okay?"
If they say no, well, they signed off on it and you do it. If you really concerned, document your conversation where your advice was not heeded. Remember, if you don't document it it didn't happen. If they listen, then you win a friend.
This would be the same for any job - computer, construction worker, whatever.
EDIT:
I took this from my comment below:
Doesn't anyone watch Star Trek anymore TNG or TOS? Remember Number One would let Captain Picard know of anything wrong and sometimes Jean-Luc would agree and sometimes he wouldn't. That's all I'm saying
我会花时间礼貌地倾听，如果有多个请求，请他们优先考虑这些请求，并以书面形式获取请求，最好是“签字”或您拥有的任何程序。 然后告诉您的经理/客户，您将审查这些请求，并向他们反馈估计情况及其对您的日程安排的影响。 解释一下，仅仅为了生成这些数据，您将需要花费 X 小时（或天），因此您的其他工作将被延迟......
然后返回估算 - 如果请求很荒谬，那么您的估算可能会反映这一点:-)
如果您的经理/客户想要继续并浪费大量时间和金钱，那么至少您已经事先明确表示并且您已尽力帮助他们。
如果可能的话，您应该要求他们将此类请求推迟到未来的阶段，建议您在下一个版本中查看它（我认为其他几个回复已经提到了这个想法）。
I would take the time to listen politely, if there is more than one request ask them to prioritise them and get the request in writing, idealy "signed off" or whatever procedure you have. Then tell your manager / customer that you will review the requests and get back to them with estimates and the impact it will have on your schedule. Explain that just to produce these data you will need to take X number of hours (or days) and therefore your other work will be delayed...
Then come back with estimates - if the request was ridiculous then your estimate is likely to reflect that:-)
If your manager / customer wants to proceed and waste lots of time and money then at least you have made it clear up front and you have done what you can to help them.
If at all possible you should ask them to defer such requests until a future phase, suggest you look at it in the next version (I think a couple of other replies mentioned this idea already).
优秀的软件设计师不会认为功能请求是可笑的。 你必须相信你的直觉，但这只是一个很好的迹象，表明你想仔细考虑这个问题。
我建议一个简单的模型：
尝试了解实际问题是什么，而不是用户要求的解决方案。 黄金设计规则“不要讨论解决方案与客户讨论需求”。
能够解释您认为所提议功能的问题所在。 名为“如何表达不同意见”。
这两个简单的步骤将帮助您和用户加深对实际问题的理解。 没有用户，软件就没有意义，我们大多数人都依赖用户为其付费。 与用户合作，而不是以可能看起来侮辱性的态度疏远他们。
一些“荒谬的”功能请求的根源在于非常有趣且难以解决的问题。
A good software designer will restrain from calling a feature request ludicrous. You've got to trust your gut feeling, but it's just a good indication that you want to consider the problem carefully.
I suggest a simple model:
Try to understand what the actual problem is, not the solution the user is asking for. The golden design rule "Don't discuss solution with the client, discuss requirements".
Be able to explain where in your opinion the problem with the proposed feature lies. Paul Graham has an excellent piece called "How to Disagree".
These two simple steps will help you and users to deepen the understanding of the actual problem. Software is meaningless without users, most of us depend on users paying for it. Work with the users instead of alienating them with an attitude that may appear insulting.
Some "ridiculous" feature requests have their roots in very intresting and hard to solve problems.
这些都是很好的答案。 您需要硬数据（如果可以生成的话）、“令人难以置信的荒谬”估计，以及最重要的是尊重。
约翰尼的回答本质上是正确的，即使不是确切的措辞（如果我建立了足够的代表，我会发表评论）。 但在某些情况下，使用这些确切的词语可能会产生足够的不和谐，让请求者重新审视你的反对内容。 是的，这适用于任何基于项目的努力：软件、广告设计，甚至（惊呼！）建设。 并不是说扛着迫击炮的人有理由或影响力反对有缺陷的设计，但施工负责人确实有义务告诉建筑师他的计划是否无法施工。
如果其他方法都失败了，请记录讨论并进行讨论。 无论如何都要建造它。 这不再是你的责任。
These are all good answers. You need hard data (if it's possible to generate it), "believably ridiculous" estimates, and, most of all, respect.
Johnny's answer was right on in essence, if not in the exact words (I'd comment if I'd built enough rep). In some cases, though, using those exact words might create enough dissonance to get the requestor to take a second look at the content of your objections. And yes, this applies to any project-based endeavor: software, advertising design, even (gasp!) construction. Not that the grunt carrying the mortar will have the grounds or clout to object to flawed design, but the construction lead does have an obligation to tell the architect if his plans are unbuildable.
If all else fails, document the discussion & build it anyway. It's no longer your responsibility.
在我回复可笑的功能请求时，它们分为两个阵营。
对于类型 1，我将分析请求并以确凿的事实或专业意见进行回应。 如果分析表明在现有代码上付出额外的努力是可能的，那么估计并估计高！
对于类型 2，首先我会要求请求者更详细地解释该功能，毕竟他们可能工作的业务领域超出了原始应用程序规范的问题空间，而我对此没有清晰的了解。 如果我仍然不明白并且我真的看不到该功能的目的，那么我会估计很高以阻止他们。
如果他们接受了这个估计，或者我接受了，最后，得到它，然后我就这样做。
归根结底，他们是顾客，如果顾客走进裁缝店并要求制作 4 条腿的裤子，裁缝可能会争论一段时间，但最终这是一项定制工作，而且价格要贵得多。 因此，如果他们看到该功能有足够的价值，他们愿意付费，就愿意接受他们的钱； 仅仅因为你看不到价值并不意味着他们是错的。
Ridiculous feature requests fall into two camps for me when responding to them.
For type 1 I'll analyse the request and respond with either hard facts or professional opinion. If the analysis indicates that it may be possible with additional effort on existing code then estimate and estimate high!
For type 2, firstly I'll ask the requestor to explain the feature in more detail, after all they may work in an area of the business that I don't have a clear understanding of beyond the problem space for the original application spec. If I still don't get it and I really cannot see the purpose of the feature then I estimate high to discourage them.
If they accept the estimate or I do, finally, get it then I do it.
At the end of the day, they are the customer and if a customer goes into the tailor and asks for trousers with 4 legs, the tailor may argue for a while but in the end it's a custom job and far more expensive. So if they see enough value in the feature that they are willing to pay be willing to take their money; just because you can't see the value doesn't mean they are wrong.
我认为您唯一能做的就是非常简洁地描述变更请求将给相关人员带来的主要问题。 在我工作的地方，我们也遇到了和你一样的问题。
一些变更请求迫使开发人员费尽心思才能完成它，最终导致楼上的人认为是一个好功能的功能的可维护性代码较差。
根据我的经验，你真的无法阻止这种情况，最终管理层会开始抱怨开发需要多长时间等等。这是一个可怕的蹩脚循环，要么以重建网站结束，要么你的团队永远在代码地狱。
祝你好运。
I think the only thing you can do is very concisely describe the major issues that the change request will bring up to the people involved. At my place of work we have the same problem as you do.
Some of the change requests force the developers to jump through hoops just to get it done and in the end it results in less maintainable code for a feature someone upstairs thought would be a good feature.
In my experience there is really nothing you can do to stop this and eventually management will start complaining about how long development is taking etc etc. It's a horrible crappy cycle which will either end in the site being re-built or your team spending eternity in code hell.
Good luck.
我发现大多数时候人们要求不可能的事情并没有意识到为什么他们所要求的是这样一个问题。
一般来说，我只是要求越来越多的需求澄清和越来越多的细节，直到：
我的脑海中突然灵光一现，我意识到他们正在尝试什么，我可以说“啊，你真正想要的是X，不是 Y”。 这时他们通常会说“是的，这就是我一直在说的”。
他们意识到自己是多么不切实际，然后撤回了请求
你们共同意识到这确实很好，但这是不可能的。 通常，根据我的经验，发生这种情况是因为您需要对大型闭源应用程序进行更改 - 在这种情况下，您只需向供应商提出功能请求，这对于非技术人员来说更令人满意对于技术人员来说； Microsoft 不会对 Excel 进行更改，因为一家小公司要求他们这样做！
I find that most of the time people asking for the impossible don't realise why what they are asking for is such a problem.
Generally, I just ask for more and more clarification of the requirement and more and more detail until:
A lightbulb comes on in my head, I realise what they are trying for and I can say "ah, what you really want is X, not Y". At which point they will generally say "yeah, that's what I was saying all along".
They realise how unrealistic they are being and they withdraw the request
You jointly realise that it would be really good but it's not possible. Usually, in my experience, that one happens because you'd need to make a change to a large closed-source application - in which case, you just make it a feature request to the supplier, which is more satifying for non-techies that for techies; Microsoft don't make changes to Excel because one small firm asked them to!
客户创建的需求可能是导致此问题的主要原因。 问题是客户有时会尝试做软件开发人员的工作。
他们遇到问题，然后找出可以解决该问题的功能。 不幸的是，这些可怜的人中的一些（大多数）不太擅长软件设计，因此最后你会得到一个非常好奇的功能。
删除某些此类延迟功能的方法就是通过递归 .Why() 函数。 不断问为什么，直到找到他们的问题，然后自己设计该功能。 在很多情况下，您可以以简单、廉价且令各方满意的方式重新设计它。
有时，看似荒谬的功能请求实际上却是一个很好的请求。
有时，软件开发人员（我自己过去也曾这样做过）会对相当复杂但非常有用的功能说不，因为这些功能会给公司带来很多钱。 因此，当您遇到“荒谬”的功能时，请务必计算其对业务的潜在价值，然后立即将其驳回。
Customer created requirements can be a major cause of this problem. The issue is that the customer sometimes tries to do a software developer's job.
They have a problem and then work out what feature they will solve that problem. Unfortunately some (most) of these poor souls aren't very good at software design hence you get a very curious feature at the end of it.
A way to remove some of these kind of retarded features is just via the recursive .Why() function. Keep asking why until you find their problem and then design the feature yourself. In a lot of scenarios you can re-design it in a way that is simple, inexpensive and satisfies all parties.
There are also times where what seems to be a ridiculous functionality request does actually pan out to be a good one.
There are times where software developers (and I have caught myself doing this in the past) say no to a reasonably complex but highly useful feature that will make the company a lot of money. So when you encounter a "ridiculous" feature be sure to calculate its potential value to the business before instantly dismissing it.
“可笑”有很多种。
我喜欢讨论需求:-)
编辑：
典型讨论
There are different kinds of "ridiculousity".
I like to discuss about requirements :-)
Edit:
A Typical discussion
有时我们会收到来自产品经理的此类请求。
在一个案例中，我解释说将会出现性能问题，而那位资深人士也证实了这一点，所以我们赢了。
下一次，我提出了类似的担忧，但高级人员不在，所以我只是做了他们想做的事，因为没有人真正关心。 我也决定不。
您可能指的是向数据库发送多标准请求、显示结果并同时显示所有这些标准中的哪一个受到点击。 猜到了吗？
We have sometimes such requests coming from product managers.
In one case I explained there were going to be performance issues and the senior guy confirmed that so we won.
The next time and raised a similar concern but the senior guy wasn't available, so I just did what they wanted because noone really cared. I decided no to as well.
You probably mean things like sending a multi-criteria request to the database, showing the results and at the same time showing which one of all those criteria had a hit. Guessed it?
有时您可以解释为什么该功能很荒谬，然后该功能就会被删除。
有时您可以让更资深的人为您说“不”。
有时，您的资历（或影响力）足以对自己说“不”。
有时你可以说“是”，但给予任务较低的优先级（并且从不执行）。
有时你可以说“是”，但
有时你只需要继续做下去。
在后一种情况下，你应该确保确实非常非常好地完成任务。 为什么？ 你会发光，当你这样做时，荒谬的阴影就会成为焦点。
Sometimes you can explain why the functionality is ridiculous, and the functionality is dropped.
Sometimes you can get someone more senior to say "no" for you.
Sometimes you are senior (or influential) enough to say "no" for yourself.
Sometime you can say "yes", but give the task a low priority (and never do it).
Sometimes you just have to get on with it.
In the latter case, you should make sure to do the task very, very well indeed. Why? You will shine, and as you do so, the shadow of the ridiculous will be brought into focus.