如何让非技术人员理解非 UI 问题？[关闭]
https://stackoverflow.com/questions/169765
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
假设您正在开发一个企业项目，在该项目中您必须获得管理层的批准才能开发新的功能集。通常，您的管理层会毫无问题地批准一些闪亮的新 UI 功能。不幸的是，他们很难理解一些对应用程序的健康至关重要的幕后问题，例如事务、数据完整性、工作流路由、可配置性、安全性等。由于他们是非技术性的，并且这些问题不会立即显现出来，因此对他们来说这并不明显至关重要。
您如何说服他们必须解决这些基础设施问题并且这对他们的业务流程很重要？
解决方案
每一种工艺都有其不性感的一面。必须要做的事情，但没有人直接注意到它们。在杂货店里，必须有人安排如何以及何时填满杂货货架，这样它们才能看起来总是新鲜的。在洗衣店，您需要有人思考如何优化流程，以便顾客及时拿到衣服。
棘手的部分是：客户不会注意到这些微妙的事情何时完成，直到他注意到它们丢失了！比如，衣服没有按时准备好，却晚了两天，或者超市里的蔬菜有褐色斑点，看起来很糟糕。
IT 也是如此。直到您的主要客户敲门并告诉您一个重要且昂贵的项目失败了，因为您产品的数据库条目神秘地混淆了，您才会注意到良好的交易。直到客户信用卡信息显示在 埃尔博尼亚 （不久之后，全国性报纸上就有消息警告贵公司的客户）。
你真正需要一次又一次强调的是软件不是静态的。即使在最初的开发阶段结束后，也必须对其进行保养。它不仅仅是您购买一次后就忘记的产品。每个汽车制造商都知道，服务对于他们生产的产品至关重要，因为总会发生需要修复和改进的事情。软件也是如此。
因此，请进行演示、可视化、语言化，并将您的技术信息转化为优势。业务人员并不关心您在重构项目中对代码美观的愿望，但他们会理解您的更改将有助于产品变得更加可靠，获得更好的声誉并减少未来的服务请求量。通过向他们展示好处来让他们理解！
其他提示
人们几千年来一直在做的事情：画画。绘制问题图，使用您的观众熟悉的视觉隐喻，将问题拖入他们的领域。
假设他们不是故意钝的......
类比和隐喻的重要+1。如果可能的话，找一个会引起观众个人兴趣的人（如果是1-2人）。对于一般的比喻，我经常发现自己出于某种原因使用通勤交通或地铁。
e.g。我们目前正在将应用程序从OODB迁移到Postgres / Hibernate：这项工作的大部分是在Release'4'中完成的。许多领域专家一直在问为什么R4中面向用户的功能如此之少。我经常告诉他们，我们一直在“撕毁这座城市以便安装地铁。这是非常昂贵且无可否认的风险，但一旦完成，R5 +的好处将是惊人的，真实的。真正的对话更多涉及，但我可以一次又一次地回到这个主题，在R4之后。几个月后，我希望说“你问了X，现在很容易 - 正是因为你让我们把地铁放回R4里”。
让上级管理层在开发工作中获得回报的最可靠方法是以可量化的方式呈现它。理想情况下，这种可量化的衡量指标是$$。您需要向他们解释限制数据完整性，安全性，交易等的后果，以及这将如何影响客户\用户社区以及最终的底线。在这些情况下您应该小心，因为有时管理层希望这些非功能性需求“正常工作”。如果是这种情况，您应该估计高，并在可见的UI工作（无知是幸福）的同时处理这些项目，或者您需要在与管理层沟通时记录这些需求区域，以便如果事情确实如您预期的那样变坏，这不是你的工作。
不幸的是，在这些东西得到应有的关注之前，通常需要一两次灾难。
这真的取决于你的管理层是什么样的，但我已经幸运地拥有了善良的诚实 - 善良的恐惧。如果你经历了几个灾难情景，并指出某人会在发生时受到指责，这足以让他们的直觉本能开始并最终引起注意：）
汽车类比。
每个人都知道'系统'，并且它足以描绘可怕的情况。
我正在与基本相同的情况作斗争。无论是由管理层签字还是由用户/赞助商接受，问题仍然是不同的词汇，优先级和观点之一。 我在这里问了一个类似的问题。
我也得到了不同的答案，非常接近有用，但还不够明确。使用相关关键字浏览和搜索SO使我能够在许多不相关的问题中找到各种答案中的有用见解。为了找到并提取这些宝石，我在网站挖掘中提出了这个问题。
能够标记各种答案并在一个列表中查看所有答案本来是有用的，但是，这些功能尚未在SO中提供。我在uservoice上建议。
希望您能从我提供的参考文献中找到可以使用的内容。
正确的反问方式就是秘密。
- 每 5 个网页就崩溃一次可以吗？
- 我们必须保护信用卡号码吗？
- 必须向承包商支付每个周末部署补丁的费用可以吗？
- 您现在想要它还是想要它发挥作用？
稳健性。当谈到它时，你需要谈论他们的语言，这是它影响他们的底线的方式。如果出现安全性或正确性问题，您需要告诉他们，无论客户看起来多么好看，客户都不会想要不正确的代理产品。
我喜欢技术债务的想法，因为它可以翻译技术问题（虽然松散地进入了金钱问题 - 而且大多数管理人员都理解金钱。
尽管技术债务的概念最初应用于建筑问题，但它可以更广泛地用于任何类型的情况，在这种情况下，需要采取捷径 - 即进入技术债务 - 而不是去做技术债务这是第一次。 （正确行事相当于节省购买东西 - 需要时间 - 而不是通过信贷购买并承担债务。）
正如债务可能是好的（例如房屋贷款）和坏的（例如信用卡），因此技术债务可能是好的和坏的。我不会试图完全描述这些差异，但可以准确地跟踪好的技术债务，这样你就可以知道你的债务是多少。
因此，尝试从技术债务方面解释您重要的非UI问题，以及在支付该债务利息方面不解决问题的成本。
描述性图片确实可以帮助非技术人员了解您所谈论的内容。例如，下面是Sun的一个示例，描述了如何在一个复杂的应用程序中处理信息。
尝试用文字来解释这个应用程序对于非技术人员来说是不可能的。指着图表说看，这部分是我们的弱点，我们需要改进它。这对他们来说是有意义的。如果他们觉得他们对你在做什么有所了解，他们会更愿意支持你的要求。
