最终用户如何应对这种不幸的非假设情况？

我在一家中型公司工作，但IT力量很小。

去年（2011年），我编写了一个受大量最终用户欢迎的应用程序。去年年底，我们赶到了最后期限，但最终并未将某些功能（从现在开始我称为funcA）添加到应用程序中。因此，此应用程序自2011年底以来一直在现场/生产中运行，我可能会添加，没有任何问题。

昨天，一群最终用户开始抱怨应用程序中从未使用过的funcA不再起作用。我们在这家公司的工作重点是，如果某个应用程序被破坏，则必须在确定优先级的项目之前先对其进行修复。

我已经比较了代码和查询，自2011年以来没有区别，这就是proofA。然后，我能够让一位最终用户承认它从未使用过proofB，但是从那以后，那个最终用户又回过头来说它以前已经在工作……我相信最终用户的群体已经吸收了她。我还查看了该项目的注释，该注释包含有关该项目的要求和每日更新，其中特别指出“ proofC由于时间限制而未实现”。

我已经与其中许多人进行了交谈，我看到它们可能会在哪里混淆，因为它们与编程背景相距甚远，但是我也知道它们足够聪明，可以在小组中采取行动，从而绕过项目优先顺序以获取他们想要使他们的工作更轻松的功能。

最糟糕的部分是，即使没有代码或查询的更改，现在团队思考开始起作用，而我的老板和IT主管实际上开始相信他们。就检查逻辑状态而言，它非常干and，直到1 = 1时，funcA将不起作用。

因此，这是对方案的描述的结尾，但是由于此原因，我试图在性能指标上不加赘述，这实际上将使我不得不解决不存在的生产问题，而该问题很可能会接管1个月。

关于易于观察的事实的争议实际上很容易解决：只需观察事实即可。 如果我说“我家外面有一棵紫色木树，”任何能够来我家的人都可以亲自验证我陈述的真假。

如果他们抱怨FuncA曾经出现在产品中，并且曾经在较早的版本中工作，而现在却无法使用，并且您认为产品中从未使用过FuncA，请要求他们进行证明。（或者用更温和的话语，例如“我们在重现问题时遇到麻烦。您能在这里帮助我们吗？”）

如果他们还没有早期版本，请给他们一份副本，然后将它们放入LiveMeeting中，并让他们向您展示他们过去如何使用FuncA。如果他们做不到，那么（希望）他们会意识到它根本不在那儿，然后就此事展开讨论，或者至少尝试另一种策略来实现它。（并确保在LiveMeeting上邀请高层管理人员或PM参加。）

这不是事实可以解决的问题-如果您尝试这样做，将失去信誉。

首先，接受该软件已“损坏”-因为它没有按照用户的意愿执行操作。现在，接受用户有权让软件执行他们想要的操作的权利-这就是软件的功能。因此，我们所拥有的是有缺陷的软件，而一位工程师拒绝对其进行修复.....

结果，如果您运行系统来设置优先级，那么这些用户将无法通过正常渠道来解决其软件问题，因此他们将使用副渠道并在食物链中逐步升级一半事实，以试图操纵该系统。同时，使您的KPI看起来不好（您的主要关注对象应该是客户，而不是您的KPI）-如果您的KPI喜欢您，则将其视为“附带损害”；如果不喜欢，则被视为有益的副作用。但是，他们确实可以控制发生的事情-他们最喜欢您。

因此，正在发生的事情是系统崩溃了，每个人都在尝试操纵事物以获取他们想要的东西。他们想要一个功能，而您想要保留一尘不染的KPI。

除非您能修复系统或学会快速玩弄办公室政治，否则游戏就会结束：您输了。

注意：本次讨论均不涉及死线，错误与功能讨论，谁付费等。这些都是事实-事实并不重要（嗯，它们确实可以做到，但是可以用很多方法来操纵...。 ）在办公室政治中。

在组织上，我感觉到一个问题。

有一个层次结构，其中包括IT主管和您的老板。如果您的组织是传统组织（听起来不像是敏捷组织），则您是资源，而他们是资源管理器。您有一份全职工作，称为软件开发。如果最终用户直接要求功能，设置优先级并尝试管理您的时间，则您的经理是多余的。他们可能对最终用户负责，但是如果他们在做自己的工作，那么您就对他们负责，他们需要保护您避免从专注的开发人员模式进入防御性的开发人员模式。

设置我的答案的上下文有几点：

• 软件开发人员不是时间旅行家，因此需要根据结果，而不是可能的结果来判断结果。
• 如果某个功能在需求规范，时间表中，并且在完成的工作之前排在优先位置，则可能存在合法投诉。否则，追究您责任的理由是什么？
• 您的惩罚（如果有根据的话）需要来自您的指挥系统。正如产品开发要骂客户一样，营销和销售都不喜欢，大多数组织都有产品经理来接收客户的愤怒（和称赞）并通过渠道传达出来。
• 如果产品经理沉浸在项目成功部分的热情中，他们可能会创建极其困难的关系，但是只有面对开发人员时，产品经理才能做到这一点。
• 如果您交付的功能性产品需要花费一年的时间，并且根据我在行业中的经验，添加所需的功能需要一个月（或两个月），那么您的估计就超出了平均水平。
• 要公平有效地解决问题，就需要人们将责任归咎于他们的口袋并制定前进的计划。

如果您被赞赏，那么您将能够以更高的动力来完成更高质量的工作，而不是成为IT主管应该拥有的过程中的山羊皮。这是公平的方式，也是生产性的方式。我希望您将以这种方式得到管理，并且在将来的某个时候，希望您以这种方式来管理其他人。

在这种现实失败的情况下，最好的办法是前进。不用争论过去，而要谈论使之工作以及这将多么容易或困难。问题是初次解决还是首次实施并不重要。如果管理层希望A在B之前完成。

您是唯一从事过该项目的开发人员吗？听起来像您在进行项目时对某人的回答。那个人在哪里呢？该项目的文档在哪里说明交付了什么？

应该有一个文件纸迹。显示如何使用该应用程序的培训文档。概述开发内容的功能规范。如果不包含功能，则也应该有相关文档。有人应该不得不签字表示接受。

这不应该是您反对他们的话，应该是文档中的全部。

如果您没有此文档...那么恐怕您将不得不咬此文档。认为这是一门人生课。归根结底，用户就是您的客户，俗话说：客户永远是对的。拟定如何添加此功能以及需要多长时间。开会，并按照“我们的记录表明该功能从未实现过，但我们可以在x周内获得使用”的方式发言。我们应该去头吗？

出于对圣洁事物的热爱……获取所需文件，以证明它已被批准。