假设您正在处理一个企业项目，您必须在该项目中获得管理层批准才能开发新功能集。通常，您的管理层可以毫无问题地签署一些闪亮的新 UI 功能。不幸的是，他们很难理解一些对应用程序的健康至关重要的幕后问题，例如事务、数据完整性、工作流路由、可配置性、安全性等。因为它们不是技术性的，而且这些问题是不是立即可见的，对他们来说这并不明显。
您如何说服他们必须处理这些基础设施问题并且这对他们的业务流程很重要？
【问题讨论】：
标签： language-agnostic communication requirements
描述性图片确实可以帮助非技术人员理解您在说什么。例如，下面是 Sun 提供的一个示例，描述了如何在其有些复杂的应用程序中处理信息。
（来源：sun.com）
试图用语言解释这个应用程序对于非技术人员来说是不可能的。指着图说看，这部分是我们的弱点，需要改进。这对他们来说是有意义的。如果他们觉得自己对您的工作有所了解，他们会更愿意支持您的请求。
【讨论】：
我喜欢Technical Debt 的想法，因为它可以将技术问题（尽管是松散的）转化为金钱问题——而金钱是大多数经理所理解的。
虽然技术债务的概念最初适用于架构问题，但它可以更广泛地用于任何类型的情况，即有压力走捷径（即陷入技术债务）而不是这样做第一次就对了。 （做对就相当于存钱买东西——这需要时间——而不是赊购并负债。）
正如债务可以是好的（例如房屋贷款）和坏的（例如信用卡）一样，技术债务也可以是好的也可以是坏的。我不会尝试完全描述差异，但可以准确跟踪良好的技术债务，以便您知道自己的债务有多少。
因此，请尝试从技术债务的角度解释您的重要的非 UI 问题，以及在支付该债务的利息方面不解决该问题的成本。
【讨论】：
正确的反驳问题是秘诀。
【讨论】：
每一种工艺都有其不性感的一面。必须做的事情，但没有人直接注意到它们。在杂货店里，有人必须组织如何以及何时填满杂货货架，以使它们看起来总是新鲜的。在洗衣店，您需要有人思考如何优化流程，以便客户及时拿到衣服。
棘手的部分是：客户不会注意到这些微妙的事情何时正确完成，直到他注意到它们丢失了！就像洗衣服没有按时准备好但是晚了两天，或者超市里的蔬菜有褐色斑点，看起来很糟糕。
IT 也是如此。直到您的主要客户敲门并告诉您一个重要且昂贵的项目失败了，因为您的产品的数据库条目神秘地混淆了，您才会注意到良好的交易。在Elbonia 中出现客户信用卡信息之前，您不会注意到良好的安全性（并且很快就会在全国性报纸上警告您公司的客户）。
您真正需要一次又一次地强调的是，软件不是静态的。即使在其初始开发阶段结束后，也必须对其进行保养。它不仅仅是您购买一次就忘记的产品。每个汽车制造商都知道，服务对他们制造的产品至关重要，仅仅是因为会发生必须修复和改进的事情。软件也是一样。
因此，进行演示、可视化、语言化、将您的技术信息转化为收益。业务人员并不关心您在重构项目中对代码美学的期望，但他们会理解您的更改将有助于产品变得更可靠、获得更好的声誉并减少未来的服务请求数量。通过向他们展示好处让他们理解！
【讨论】：
我正在与基本相同的情况作斗争。无论是管理层的签字还是用户/赞助商的接受，问题仍然是不同的词汇、优先事项和观点之一。 I asked a simmilar question here.
我也得到了各种各样的答案，非常接近有用，但还不够明确。使用相关关键字浏览和搜索 SO 使我在分布在许多不相关问题的各种答案中找到有用的见解。为了找到并提取这些宝石，我摆出了 this question on site-mining 的姿势。
能够标记各种答案并将它们全部显示在一个列表中会很有用，但是遗憾的是，该功能在 SO 中尚不可用。我suggested it on uservoice。
希望你能从我提供的参考资料中找到可以使用的东西。
【讨论】：
汽车类比。
每个人都知道这个“系统”，它足够复杂，足以描述可怕的情况。
【讨论】：
不幸的是，这些东西通常需要一两次灾难才能得到应有的关注。
这真的取决于你的管理层是什么样的，但我很幸运，老老实实地散布恐惧。如果你经历了几个灾难场景，并指出如果它们发生某人会受到指责，这足以让他们的搜捕本能开始并最终引起注意:) p>
【讨论】：
让高层管理人员接受开发工作的最可靠方法是以可量化的方式呈现。理想情况下，这种可量化的度量单位是 $$。您需要向他们解释在数据完整性、安全性、交易等方面吝啬的后果，以及这将如何影响客户\用户社区并最终影响利润。在这些情况下您应该小心，因为有时管理层希望这些非功能性需求“正常工作”。如果是这种情况，您应该估计高并在可见 UI 工作的同时处理这些项目（无知是幸福），或者您需要在与管理层沟通时记录这些需求领域，以便如果事情确实如您预期的那样糟糕，危在旦夕的不是你的工作。
【讨论】：
类比和隐喻的大+1。如果可能的话，找一个能与你的听众的个人兴趣产生共鸣的人（如果是 1-2 人）。对于一般的比喻，出于某种原因，我经常发现自己使用通勤交通或地铁。
例如我们目前正在将应用程序从 OODB 迁移到 Postgres/Hibernate：大部分工作在 Release '4' 中完成。许多领域专家一直在问为什么 R4 中面向用户的功能如此之少。我经常告诉他们，我们一直在“拆毁这座城市以安装地铁”。这是非常昂贵且不可否认的风险，但一旦完成，R5+ 的好处将是惊人的，真的。真正的对话更复杂，但我可以一次又一次地回到这个主题，在 R4 之后。几个月后，我希望说“你要求 X，现在很容易——正是因为你让我们把地铁放回 R4”。
【讨论】：
稳健性。归根结底，您需要谈论他们的语言，这就是它如何影响他们的底线。如果是安全或正确性问题，您需要告诉他们客户不会想要行为不正确的产品，无论它们看起来多么漂亮。
【讨论】：
几千年来人们一直在做同样的事情：画画。绘制问题图，使用观众熟悉的视觉隐喻，将问题拖入他们的领域。
假设他们不是故意钝...
【讨论】：