这是一个哲学问题。我在我的软件中添加了一个小功能，我认为大多数用户都会使用该功能，但大概只有他们使用该软件的次数的10％。换句话说，该软件在没有该软件的情况下已经运行了3个月，但是有4或者5个用户要求使用该软件，我同意该软件应该存在。

问题是，由于我所使用的平台的局限性(可能还有我的大脑的局限性)，"我能做的最好的"仍然存在一些非关键性但值得注意的错误，可以说编码功能可用但在某些情况下，"有点儿糊涂"。

该怎么办？那里有90％的功能真的"总比没有好"吗？我知道我会收到一些错误报告，而这些错误报告将无法修复：我该如何告知客户？我应该接受未答复的功能请求或者未答复的错误报告吗？

解决方案

始终会有未答复的功能请求和错误报告。附带它，但在可能的情况下，请包含具有"已知问题"和解决方法的自述文件。

准确记录并发送。
确保用户可能会看到并理解文档。

我们甚至可以与要求该功能的用户讨论该决定：进行一些市场研究。

仅仅因为我们现在不能修复它，并不意味着我们将来将无法修复。事情会改变的。

将我们现在拥有的标签标记为"测试版"，然后将其发送给要求它的人。得到他们的反馈意见，如何解决问题，解决他们的抱怨，然后就应该准备将其推广到更大的用户群体。

确保人们知道存在问题。那里有虫子。并给他们提供反馈的简便方法。

首先与建议该功能的" 4个或者5个用户"进行"封闭beta"怎么样？

我们需要从用户的角度考虑这一点，这会减少沮丧感吗？ Buggy代码通常比缺少功能更令人沮丧。

如果它没有破坏其他任何东西，为什么不发货呢？听起来我们与客户之间的关系很好，所以即使功能并非一帆风顺，那些想要该功能的人也会很乐意，而那些不想要该功能的人则不会在意。另外，在下一个版本中，我们将获得很多反馈来改进它！

提早发货，经常发货，不断进行重构。

我的意思是，不要让它阻止我们发货，但也不要放弃解决问题的方法。

无法解决混乱是代码库中出现问题的迹象。与添加功能相比，花费更多的时间进行重构。

完美主义者可能会回答"不要这样做"。

商界人士可能会回答"做到"。

我想余额由我们决定。如果错误不是很严重的话，我会朝着将功能放在那里的方向摇摆。大多数用户不会以与我们相同的方式看到软件。我们是手工艺者/艺术家，这意味着我们比普通人更重要。

有什么方法可以为要求使用此功能的4-5位用户获得测试版？然后，一旦获得他们的反馈，就可以清楚地做出哪个决定。

我想这取决于标准。对我来说，错误的代码尚不适合生产，因此不应该交付。我们是否可以使用带有已知问题列表的Beta版本，以便用户知道在某些情况下会发生什么？他们从使用新功能中受益，但也知道它并不完美(要自己承担风险)。这可能会使要求该功能的4或者5个客户满意一段时间，这使我们有更多的时间来修复错误(如果可能)并在以后批量生产。

根据情况，只是一些想法。

要看。关于这些错误，它们的严重性以及我们认为需要花费多少精力进行修复。在截止日期上，我们认为可以延长多少时间。关于其余的代码以及客户端可以使用多少代码。

• 确保记录错误和后果(对用户和其他开发人员)。
• 确保将错误添加到错误跟踪数据库。
• 如果我们编写单元测试(我希望如此)，请在交付之前确保编写的测试能够突出显示错误。这意味着我们将来要修复这些错误时，无需记住它们就知道它们的位置和含义。
• 安排工作以尽快修复错误。我们可以在编写新代码之前先修复错误，不是吗？