您如何回答：客户提出的“自更新以来……”问题？[关闭]

自从更新以来，人们一直在喊着说：“自从更新X，Y和Z变慢，变差并崩溃后”

自从更新开始以来就发生了这种情况。

人们期望什么？伽玛版是beta版本之后的版本，伽玛测试始终使我们的用户成为“不可思议的绿巨人” ...

也许您从未听说过来自客户的消息，也许您是在大学或FLOSS开发人员中，可以将责任推卸到5个或6个以上的家伙上，也许您要对代码进行单元测试，也许您并没有遇到这种有趣的情况客户实际上打电话给您，要求您提供一天中的确切时间（今天我想向M​​icrosoft发布），或者您是像我这样对不起的饼干儿子，他刚发布了新补丁更新并回家，令人恐惧的是明天要恢复工作。

无论如何，你们比我还要聪明。您如何对“您必须是一个糟糕的程序员，因为您会使软件变得更糟”提出批评？

如果您每次部署时都遇到这种情况，那么在开发过程中可能会存在严重的缺陷。我会怀疑是导致问题的几件事。

1. 您是否使用与生产相同（大致）大小的数据库进行开发？如果不是这样，那么您将始终遇到这些问题，因为适合于小数据集的查询通常是大狗。
2. 您是否在质量检查中加载测试？一次用户测试的最佳效果与千位尝试同时进行操作的用户的响应方式大不相同。
3. 您是否认为用户的看法是错误的，并像对待投诉一样愚蠢地对待他们？如果是这样，那么您的态度会引起更多的抱怨而不是减轻他们。
4. 您的测试工作做得好吗？您是否对未更改的功能进行回归测试以查看它们是否受到更改的影响？您什至不在乎事情要花多长时间才能推到产品上？
5. 您是否在部署用户时注意什么时候是用户的好时机？或者在运行工资单的时候就将更改轻松地部署到会计系统中，并且想知道为什么用户会对速度下降感到生气？
6. 您在开发和生产之间有环境差异吗？有时，操作系统或数据库版本的讨厌差异也会引起类似的问题。通常，最好有一个与prod完全一样的暂存环境，某些设备具有相同的操作系统，相同的数据库和dat尽可能接近于prod数据。这用于测试您的部署。首先在此服务器上运行它，然后有一些用户或测试人员进入它并通过一些测试。
7. 您的部署过程有多好？您经常错过步骤吗？它可以由开发人员以外的其他人运行，因为很清楚您要部署的分支中包含什么代码？当我们有一个配置管理团队时，我们在部署代码方面做得更好，没有人有权坐在产品上并保管它来进行“ oopsie”更改。自动化构建可以极大地帮助您。没有人会猜测应该生产什么，因为它应该先进行质量检查并首先进行准备，然后解决所有运输问题。脚本化数据库更改也是关键。它们应该在脚本和源代码控制中，因此构建过程可以在无需记住的情况下拾取它们，哦，是的，我们需要将B列的长度从50更改为241。

您如何对“您必须是一个糟糕的程序员，因为您会使软件变得更糟”提出批评？

但是这种批评在大多数情况下是合理的。新发行的发行版不应该比旧发行的发行版差，但正如我们所知，实际上它经常会发行，这是我们的错，因为我们制造了它。

犯错误是人为的，并且不会使任何人成为“不良程序员”，因此请不要个人批评（无论如何我也不会认真对待非同事的任何专业批评）。只需感谢客户报告此问题，并尽快解决。作为一名优秀的程序员，这是您的工作。

好吧，在工作中，我们不会直接与客户互动，因此我必须从个人项目工作中回答这一问题。我正在编写一个游戏引擎，人们可以用来构建自己的游戏。它仍然处于预测试阶段，但是我有一些感兴趣的用户，有时还会出现错误。

当我从用户那里收到这样的报告时，我会尝试使用个人风格。我并不是要引入错误，而是希望它们对我的引擎有很好的经验，因此我需要让他们相信。首先，获取IM句柄，以便我们进行交谈。我将向用户询问有关他们的项目的信息，然后尝试获取该项目的副本。这使得复制容易得多。问他们发生故障时他们在做什么。同时，我已经在调试器中打开了引擎，并且在我们交谈的时候我一直在研究这个问题。

如果是例外，通常很简单。重现问题，调试器抓住它，并通过完整的堆栈跟踪将您直接带到错误位置，这很明显是怎么回事。如果性能降低或行为不正确，则可能需要更长的时间。但在大多数情况下，我可以在前20分钟之内准备好修复程序。我将其压缩并发送给他们进行测试。“好吧，我想我明白了。看看这是否对您有用？”

通常，响应几乎是惊奇和感激的混合，因为大多数开发人员（阅读：软件公司）只是不修复错误并迅速发布。然后，如果实际上已解决，那么我已经将潜在的批评家变成了粉丝。这是一种非常好的技术。我只是希望更多的开发人员会采用它。

我个人积极地对待这个问题。我一直在与很多客户互动，而且我仍然在编写代码。

当他们下载新版本并告诉我类似内容时，我总是这样说：

感谢您向我报告该错误。也许将我们添加的所有新功能一起引入。我们将尽快修复它。

实际上，客户是您真正的老板。如果与您的经历不好，那对您也很不利。

即使他不对，您作为公司的一部分，您也应借此机会：

• 通过收集您可以对产品进行的改进来向他学习。
• 将不满意的客户转变为满意的客户，以至于很高兴他会谈论您（包括您的老板）
• 为自己的工作感到自豪

详细信息，详细信息，详细信息。我问他们在做什么，什么时候做，具体点。可能是某件事，也可能只是Justin Beaber视频刚刚在youtube上发布。在这两种情况下，日志文件都是您的朋友。

我还要求他们注意到的日期。有时，尤其是在企业商店中，用户不知道发布的时间，他们只是知道需要花费很长时间才能完成，而现在他们只是抱怨。

工作阴影。无法强调这一点。如果您有幸在附近有用户，只需看着他们不时工作即可。我经常发现他们忽略了明显的问题，从不报告。他们通常只会在知道新事物或最初注意到问题时抱怨。

步骤1是您必须以这种思维方式（更新破坏了其他内容）是不正常的。您的更新不应破坏或减慢应用程序的其他部分。这不行，这不是意料之中的，这不是用户抱怨时的过错。您应该进行尽可能多的测试以尝试阻止它。发生这种情况时，您会遇到一个问题，并且是紧急问题。

第2步是您必须知道自己做了什么。您的源代码管理系统可能会为您提供帮助，或某种工作跟踪系统，但是您必须能够说出收到这些投诉之一的那一刻，“好吧，我在此表中添加了一个列，更改了此网格以进行计算新税收，添加了这两个新报告...”，依此类推。

第3步是您必须具有迅速发现性能问题并崩溃的经验，因此您知道可能导致此类问题的种类，并且可以立即解决问题。这个东西已经上线了，您必须迅速找到问题并发布补丁。更改报告不会减慢不使用报告的应用程序的一部分。您现在处于紧急模式，必须弄清楚错误出在哪里以及如何解决-在此过程中不要破坏应用程序的另一部分。

第4步适用于这些痛苦中的每一个，您应该学习下一课，然后再进行测试。您将成为反对特定构造的“那个家伙”，因为“当有10,000条记录时，这将是可怕的”。

在“这很正常”方面要多一点。我为外部客户运行（以及正在进行的所有其他事情）一个敏捷项目。现在，我们大约每6周发布一次版本，已经有两三年了。是的，发布计划在分钟内完成。我们昨天早上8点才做一个。大约每4或5个发行版（换句话说，一年一次或两次）就会被破坏，我们会立即采取行动并尽快将其改正。即使我们在发布前进行测试和测试。然后我们告诉他们发生了什么。“ 6月部署中有一个小错误，使该字段为空白，但我们从未注意到，因为那时我们没有使用该值。然后在此部署中，当我们开始使用该字段时，空白字段导致了您看到的错误消息。修复了错误，使它们不能为空，将值放在错误的记录中，并确认不会再爆炸了。我们的道歉。”或“在发布前两天，您请求进行的紧急更改会产生我们未曾想到且未进行测试的后果。还记得我们为什么拒绝紧急更改吗？”我可能不是一个糟糕的程序员，因为随着更新的进行它会使情况变得更糟，但是我确实做得不好。我需要把它纠正。我可能不是一个使更新变得更糟的程序员，但是我确实做得不好。我需要纠正它。我可能不是一个使更新变得更糟的程序员，但是我确实做得不好。我需要纠正它。

只是为了涵盖另一个方面：

我们保留一份客户清单，但事实并非如此。虽然软件是错误的，通常是非常错误的，但是我们的许多客户会声称“从更新开始”来引起迅速的关注，但没有意识到这样做最终会浪费每个人的时间，因为我们将遍历指定功能的delta以查找问题。如果客户说的是实话，这往往会很快发现它。如果客户在虚假列表上的次数过多，我们就不会打扰，因为我们不喜欢浪费时间。

我无法想象要告诉我们说谎会加速这一过程，需要什么样的思维方式。这些人是医生或与医生一起工作，应该充分了解当人们对医生撒谎时会发生什么。同样的原则适用。