language-agnostic - 如何让非技术人员理解非 UI 问题？

Question

假设您正在处理一个企业项目，您必须在该项目中获得管理层批准才能开发新功能集。通常，您的管理层签署一些明亮闪亮的新 UI 功能是没有问题的。不幸的是，他们很难理解一些对应用程序的健康至关重要的幕后问题，例如事务、数据完整性、工作流路由、可配置性、安全性等。因为它们不是技术性的，而且这些问题是不是立即可见的，对他们来说这并不明显，这是至关重要的。

您如何说服他们必须处理这些基础设施问题并且这对他们的业务流程很重要？

score 18 · Accepted Answer

每一种工艺都有其不性感的一面。必须做的事情，但没有人直接注意到它们。在杂货店里，有人必须组织如何以及何时填满杂货货架，以使它们看起来总是新鲜的。在洗衣店，您需要有人思考如何优化流程，以便客户及时拿到衣服。

棘手的部分是：客户不会注意到这些微妙的事情何时正确完成，直到他注意到它们丢失了！就像洗衣服没有按时准备好但晚了两天，或者超市里的蔬菜有褐色斑点，看起来很糟糕。

IT 也是如此。直到您的主要客户敲门并告诉您一个重要且昂贵的项目失败了，因为您的产品的数据库条目神秘地混淆了，您才会注意到良好的交易。在客户信用卡信息出现在Elbonia之前，您不会注意到良好的安全性（并且很快就会在全国性报纸上警告贵公司的客户）。

您真正需要一次又一次地敲定的是软件不是静态的。即使在其初始开发阶段结束后，也必须对其进行保养。它不仅仅是您购买一次就忘记的产品。每个汽车制造商都知道，服务对他们制造的产品至关重要，仅仅是因为会发生必须修复和改进的事情。软件也是一样。

因此，进行演示、可视化、语言化、将您的技术信息转化为收益。业务人员并不关心您在重构项目中对代码美学的期望，但他们会理解您的更改将有助于产品变得更可靠、获得更好的声誉并减少未来的服务请求数量。通过向他们展示好处让他们理解！

score 9 · Accepted Answer

几千年来人们一直在做同样的事情：画画。绘制问题图，使用观众熟悉的视觉隐喻，将问题拖入他们的领域。

假设他们不是故意钝...

score 4 · Accepted Answer

类比和隐喻的大+1。如果可能的话，找一个能与你的听众的个人兴趣产生共鸣的人（如果是 1-2 人）。对于一般的比喻，出于某种原因，我经常发现自己使用通勤交通或地铁。

例如，我们目前正在将应用程序从 OODB 迁移到 Postgres/Hibernate：大部分工作是在 Release '4' 中完成的。许多领域专家一直在问为什么 R4 中面向用户的功能如此之少。我经常告诉他们，我们一直在“拆毁这座城市以安装地铁”。这是非常昂贵且不可否认的风险，但一旦完成，R5+ 的好处将是惊人的，真的。真正的对话更复杂，但我可以一次又一次地回到这个主题，在 R4 之后。几个月后，我希望说“你要求 X，现在很容易——正是因为你让我们把那个地铁放回 R4”。

score 2 · Accepted Answer

让高层管理人员接受开发工作的最可靠方法是以可量化的方式呈现它。理想情况下，这种可量化的度量单位是 $$。您需要向他们解释在数据完整性、安全性、交易等方面吝啬的后果，以及这将如何影响客户\用户社区并最终影响利润。在这些情况下您应该小心，因为有时管理层希望这些非功能性需求“正常工作”。如果是这种情况，您应该估计高并在可见的 UI 工作旁边处理这些项目（无知是幸福），或者您需要在与管理层沟通时记录这些需求领域，以便如果事情确实如您预期的那样糟糕，危在旦夕的不是你的工作。

score 1 · Accepted Answer

不幸的是，在这些东西得到应有的关注之前，通常需要一两次灾难。

这真的取决于你的管理是怎样的，但我很幸运能摆脱老实人的恐惧。如果你经历了几个灾难场景，并指出如果他们发生就会受到责备，这足以让他们的搜捕本能开始并最终引起注意:)

score 1 · Accepted Answer

我正在与基本上相同的情况作斗争。无论是管理层签字还是用户/赞助商接受，问题仍然是不同的词汇、优先事项和观点之一。我在这里问了一个类似的问题。

我也得到了各种各样的答案，非常接近有用，但还不够明确。使用相关关键字浏览和搜索 SO 使我在分布在许多不相关问题的各种答案中找到有用的见解。为了找到并提取这些宝石，我在 site-mining 上提出了这个问题。

能够标记各种答案并将它们全部显示在一个列表中会很有用，但可惜的是，该功能在 SO 中尚不可用。我在 uservoice 上建议了它。

希望您从我提供的参考资料中找到可以使用的东西。

score 1 · Accepted Answer

1

汽车类比。

每个人都知道这个“系统”，它足够复杂来描述可怕的情况。

于 2008-10-04T06:53:49.273 回答

score 1 · Accepted Answer

正确的反驳问题是秘诀。

每 5 个网页崩溃一次可以吗？
我们必须保护信用卡号码吗？
是否可以支付承包商每个周末部署补丁的费用？
您现在想要它还是想要它工作？

score 0 · Accepted Answer

稳健性。归根结底，您需要谈论他们的语言，这就是它如何影响他们的底线。如果是安全性或正确性问题，您需要告诉他们客户不会想要行为不正确的产品，无论它们看起来多么漂亮。

score 0 · Accepted Answer

描述性图片确实可以帮助非技术人员理解您在说什么。例如，下面是 Sun 的一个示例，描述了如何在其有些复杂的应用程序中处理信息。

_{（来源：sun.com）}

试图用语言解释这个应用程序对于非技术人员来说是不可能的。指着图说看，这部分是我们的弱点，需要改进。这对他们来说是有意义的。如果他们觉得他们对您的工作有所了解，他们将更愿意支持您的请求。

score 0 · Accepted Answer

我喜欢技术债务的想法，因为它可以将技术问题（尽管是松散的）转化为金钱问题——而金钱是大多数管理者都理解的东西。

尽管技术债务的概念最初适用于架构问题，但它可以更广泛地用于任何有压力走捷径的情况——即陷入技术债务——而不是一开始就做对时间。（正确地做就相当于存钱买东西——这需要时间——而不是赊购并负债。）

正如债务可以是好的（例如房屋贷款）和坏的（例如信用卡）一样，技术债务也可以是好的和坏的。我不会尝试完全描述差异，但可以准确跟踪良好的技术债务，以便您知道自己的债务有多少。

所以，试着从技术债务的角度来解释你重要的、非 UI 问题，以及在支付债务利息方面不解决它的成本。

language-agnostic - 如何让非技术人员理解非 UI 问题？

11 回答 11

Related

Reference