If this feature runs counter to the philosophy of your product, it indicates that the product does not conform to the mental model of your users. The consequences of that are much larger than just a single missing feature. You need to get inside your users heads, and figure out how to adjust your model to their expectations, or guide their expectations towards your model.
Put enough thought into this and it could become a great opportunity for you.
In 'The Mythical Man Month' (which you have read, haven't you?), Brooks says words to the effect that 'conceptual integrity of the architecture is the most important thing'. That means that if the requested feature breaks the conceptual integrity of the overall design of your product, you probably should continue to avoid implementing it, regardless of how much it is requested. Or, you need to reshape the architecture so that the requested feature fits into the revised architecture.
One of the products I work on has a 'much requested feature' that was added. It behaves unlike any other feature in the product. It is a horrid wart. But since the competition does it, we had to do it. But instead of remaining true our architecture (which happens to differ fundamentally from the competition's in this area), we aped the competition's feature, down to silly details.
I still bitterly resent the fact that the feature was botched into the system with broken semantics w.r.t the rest of the product. To rub salt into the wound, I had to present the new feature as the 'greatest thing since sliced bread' to our customer base -- that really hurt.
Having said that, no-one has complained (as I think they should) about the feature. It probably gets used sometimes. It is one less difference that the competition can use against us.
(And note: I was not against the feature being implemented in a style consistent with our product's normal way of working; I was only against it being implemented in the style that our competition uses - because the other related features work analogously to the broken implementation in their system, whereas our system is more sane and friendly.)
It's almost impossible to answer this, as we don't know exactly what you're talking about.
Having said that some points:
The number of users who actually want the feature, probably are far higher then you think, as most users will never log feedback.
You describe a 'workaround', this implies your product either has a problem, or it's UI needs to change.
I'd be inclined to implement it, as this will make your customers happy.
An option would be to give them a menu option, which directs them to both methods. Possibly a wizard of some sort, which helps them decide which workaround to use.
I would try to re-design the UI for your work around to make it easier and more obvious for your users. At the end of the day, the customer pays the bills so we have and obligation to meet their needs. When what they ask for will cause more problems, it comes back to us to offer a different solution such that we don't create more future bugs, and we still keep the customers happy.
While not a programming question, I've seen quite a few people over the years struggle with this type of issue.
You need to ask yourself a few questions
1) Have you, or management, done a cost-benefit analysis? Ask yourself "How will the feature.."
increase sales? i.e. will more people buy it
decrease sales? i.e. loosing customers that are put off
impact customer service?
2) If the product will change radically - would it make sense to spin it off to an entire new SKU?
3) Management will get what they want in the end. Do you want to work with them to provide your customers the best experience possible & be the hero, or against them and look for other opportunities.
Define "our users". Is it 5% of your user base, 80%, 95%? Have you surveyed enough of them to find out if this is something that the vast majority of the users want, or is it just a rogue group of users (they can be the most difficult and hard to please).
I think that needs to be established first. If it's the majority of your user base and it adds value in their eyes, then I would try to reach a compromise where you meet in the middle, not compromising the integrity of your product, but still offering the customer an alternative solution that would still meet their needs.
I would go with whatever has more potential ROI. Will you increase profits by implementing this feature? If so, does that exceed the cost of supporting the new feature? If potential profits are greater than your support cost, I'd suggest going with the feature.
If there is no gain to be made either finacially or by lowering costs for support, then it makes no sense to do it.
I'd go with a simple guess at the cost (in terms of usability) versus the benefit, at least as a major factor to weigh. For example, if the feature will likely help 45% of users but make the program harder to use for the other 55%, don't do it.
发布评论
评论（10）
将其作为插件实现。
Implement it as a plug-in.
如果这个功能与你的产品理念背道而驰，则表明该产品不符合你的用户的心智模型。其后果比仅仅缺少一个功能要大得多。您需要深入用户的头脑，找出如何根据他们的期望调整您的模型，或引导他们对您的模型的期望。
对此进行足够的思考，这可能会成为您的绝佳机会。
If this feature runs counter to the philosophy of your product, it indicates that the product does not conform to the mental model of your users. The consequences of that are much larger than just a single missing feature. You need to get inside your users heads, and figure out how to adjust your model to their expectations, or guide their expectations towards your model.
Put enough thought into this and it could become a great opportunity for you.
在《人月神话》（你读过，不是吗？）中，布鲁克斯说了这样的话：“架构的概念完整性是最重要的”。这意味着，如果所请求的功能破坏了产品整体设计的概念完整性，您可能应该继续避免实现它，无论请求有多少。或者，您需要重塑架构，以便请求的功能适合修改后的架构。
我开发的产品之一添加了“急需的功能”。它的行为不同于产品中的任何其他功能。这是一个可怕的疣。但既然竞争对手这么做了，我们就必须这么做。但我们并没有保持真实的架构（这恰好与该领域的竞争对手的架构有根本不同），而是模仿了竞争对手的功能，甚至到了一些愚蠢的细节。
我仍然对这个功能被拙劣地植入系统这一事实感到非常不满，因为与产品的其余部分相比，语义被破坏了。为了在伤口上撒盐，我必须向我们的客户群展示“自切片面包以来最伟大的东西”这一新功能——这真的很伤人。
话虽如此，没有人抱怨过（我认为他们应该）抱怨该功能。可能有时候会用到。竞争者可以利用这一点来对付我们。
（注意：我并不反对以与我们产品正常工作方式一致的方式实现该功能；我只是反对以我们的竞争对手使用的方式实现该功能 - 因为其他相关功能的工作方式与损坏的实现类似在他们的系统中，而我们的系统更加理智和友好。）
这很难。有时市场会胜出。
In 'The Mythical Man Month' (which you have read, haven't you?), Brooks says words to the effect that 'conceptual integrity of the architecture is the most important thing'. That means that if the requested feature breaks the conceptual integrity of the overall design of your product, you probably should continue to avoid implementing it, regardless of how much it is requested. Or, you need to reshape the architecture so that the requested feature fits into the revised architecture.
One of the products I work on has a 'much requested feature' that was added. It behaves unlike any other feature in the product. It is a horrid wart. But since the competition does it, we had to do it. But instead of remaining true our architecture (which happens to differ fundamentally from the competition's in this area), we aped the competition's feature, down to silly details.
I still bitterly resent the fact that the feature was botched into the system with broken semantics w.r.t the rest of the product. To rub salt into the wound, I had to present the new feature as the 'greatest thing since sliced bread' to our customer base -- that really hurt.
Having said that, no-one has complained (as I think they should) about the feature. It probably gets used sometimes. It is one less difference that the competition can use against us.
(And note: I was not against the feature being implemented in a style consistent with our product's normal way of working; I was only against it being implemented in the style that our competition uses - because the other related features work analogously to the broken implementation in their system, whereas our system is more sane and friendly.)
It's tough. Sometimes the market wins out.
回答这个问题几乎是不可能的，因为我们不知道你到底在说什么。
话虽如此，但以下几点：
我倾向于实施它，因为这会让您的客户满意。
一个选择是为他们提供一个菜单选项，引导他们使用这两种方法。
可能是某种向导，帮助他们决定使用哪种解决方法。
It's almost impossible to answer this, as we don't know exactly what you're talking about.
Having said that some points:
I'd be inclined to implement it, as this will make your customers happy.
An option would be to give them a menu option, which directs them to both methods.
Possibly a wizard of some sort, which helps them decide which workaround to use.
我会尝试为您的工作重新设计用户界面，以使其对您的用户来说更容易、更明显。最终，客户支付账单，因此我们有义务满足他们的需求。当他们的要求会导致更多问题时，我们会提供不同的解决方案，这样我们就不会在未来产生更多错误，并且仍然能让客户满意。
I would try to re-design the UI for your work around to make it easier and more obvious for your users. At the end of the day, the customer pays the bills so we have and obligation to meet their needs. When what they ask for will cause more problems, it comes back to us to offer a different solution such that we don't create more future bugs, and we still keep the customers happy.
虽然这不是一个编程问题，但多年来我见过很多人都在为此类问题而苦苦挣扎。
您需要问自己几个问题
1) 您或管理层是否进行过成本效益分析？
问问自己“该功能将如何......”
买了会
2) 如果产品将发生根本性变化 - 将其拆分为全新的 SKU 是否有意义？
3）管理层最终会得到他们想要的。您是否想与他们合作，为您的客户提供尽可能最好的体验？成为英雄，或者对抗他们并寻找其他机会。
While not a programming question, I've seen quite a few people over the years struggle with this type of issue.
You need to ask yourself a few questions
1) Have you, or management, done a cost-benefit analysis?
Ask yourself "How will the feature.."
buy it
2) If the product will change radically - would it make sense to spin it off to an entire new SKU?
3) Management will get what they want in the end. Do you want to work with them to provide your customers the best experience possible & be the hero, or against them and look for other opportunities.
定义“我们的用户”。是你的用户群的 5%、80%、95% 吗？您是否对他们进行了足够多的调查，以了解这是否是绝大多数用户想要的东西，或者只是一群流氓用户（他们可能是最难取悦的）。
我认为首先需要确定这一点。如果这是您的大多数用户群，并且在他们眼中增加了价值，那么我会尝试在中间达成妥协，不损害产品的完整性，但仍然为客户提供替代解决方案，该解决方案仍然可以满足他们的需求。
Define "our users". Is it 5% of your user base, 80%, 95%? Have you surveyed enough of them to find out if this is something that the vast majority of the users want, or is it just a rogue group of users (they can be the most difficult and hard to please).
I think that needs to be established first. If it's the majority of your user base and it adds value in their eyes, then I would try to reach a compromise where you meet in the middle, not compromising the integrity of your product, but still offering the customer an alternative solution that would still meet their needs.
向提出请求的人宣布解决方法作为请求的解决方案。使解决方法在 UI 中更加突出/更易于使用。
Announce the workaround as the solution to the request to those who have requested it. Make the workaround more prominent in the UI / easier to use.
我会选择任何有更多潜在投资回报率的东西。您会通过实施此功能来增加利润吗？如果是这样，这是否超出了支持新功能的成本？如果潜在利润大于您的支持成本，我建议您使用该功能。
如果在财务上或通过降低支持成本都无法获得收益，那么这样做就没有意义。
I would go with whatever has more potential ROI. Will you increase profits by implementing this feature? If so, does that exceed the cost of supporting the new feature? If potential profits are greater than your support cost, I'd suggest going with the feature.
If there is no gain to be made either finacially or by lowering costs for support, then it makes no sense to do it.
我会对成本（在可用性方面）与收益进行简单的猜测，至少作为权衡的主要因素。例如，如果该功能可能会帮助 45% 的用户，但会让其他 55% 的用户更难使用该程序，那么就不要这样做。
I'd go with a simple guess at the cost (in terms of usability) versus the benefit, at least as a major factor to weigh. For example, if the feature will likely help 45% of users but make the program harder to use for the other 55%, don't do it.