如何让非技术人员了解非UI问题?[关闭]

每一艘飞船都有其不完美的一面。必须做的事情,但没有人直接注意到。在杂货店,必须有人组织如何和何时填满杂货架,这样他们总是看起来新鲜。在洗衣房,你需要有人考虑如何优化流程,以便客户及时拿到衣服。

棘手的部分是:客户不会注意到这些微妙的事情何时做得正确,直到他注意到它们丢失为止!比如说,当洗衣店没有按时准备好,但是晚了两天,或者超市里的蔬菜有褐色斑点,看起来很糟糕。

同样的道理。直到你的主要客户敲门告诉你一个重要而昂贵的项目已经失败,因为你产品的数据库条目被神秘地混淆了,你才会注意到好的交易。直到客户信用卡信息出现在 Elbonia (很快,全国性的报纸上就有消息警告你公司的客户)。

你真的需要一次又一次地敲入的东西是软件不是静态的。即使在最初的开发阶段结束之后,它也必须得到照顾。它不仅仅是你买过一次就忘了的产品。每一个汽车制造商都知道,服务对他们生产的产品至关重要,这仅仅是因为会发生一些需要修理和改进的事情。软件也是如此。

所以做一个演示,形象化,描述,把你的技术信息转化为利益。业务人员不关心您在重构项目中对代码美学的期望,但他们会理解您的更改将帮助产品变得更可靠,获得更好的声誉,并减少未来服务请求的数量。向他们展示好处,让他们理解!

几千年来人们都在做同样的事情:画画。绘制问题图,使用观众熟悉的视觉隐喻,将问题拖到他们的领域中。

假设他们不是故意迟钝的…

用于类比和隐喻的大+1。如果可能的话,找一个能引起听众个人兴趣共鸣的人(如果是1-2个人的话)。用一般的比喻来说,我经常发现自己出于某种原因使用通勤交通或地铁。

例如,我们目前正在将一个应用程序从oodb迁移到postgres/hibernate:大部分工作是在版本“4”中完成的。许多领域专家一直在问,为什么在R4中很少有面向用户的功能。我经常告诉他们,我们一直在拆毁这座城市,准备搭地铁。这是非常昂贵和不可否认的风险,但一旦它完成了,R5+的好处将是惊人的,真正的。'真正的对话是更多的参与,但我可以回到这个主题一次又一次,很好地在R4之后。几个月后,我希望说,“你要的是X,现在很容易——正是因为你让我们把它放回了R4号地铁。”

让高层管理层买下开发工作的最可靠的方法是以可量化的方式呈现出来。理想情况下,这个可量化的度量单位是美元。您需要向他们解释跳过数据完整性、安全性、事务等的后果,以及这将如何影响客户/用户社区,最终影响底线。在这些情况下,您应该小心,因为有时管理层希望这些非功能性需求“只起作用”。如果是这样,您应该估计高一些,并在可见的UI工作(无知就是幸福)旁边处理这些项目,或者您需要在与管理层沟通时记录这些需求领域,因此如果发生了什么情况按你的预期去做吧,这不是你的工作。

不幸的是,在这些事情得到应有的关注之前,通常要经历一两次灾难。

这真的取决于你的管理层是什么样的,但我很幸运地遇到了诚实善良的好心人。如果你经历了一些灾难场景,并指出 某人 如果他们发生了,就会受到指责,这足以让他们的纵火本能被激发,并最终引起注意:)

汽车类比。

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

我正在与基本上相同的情况作斗争。无论是由管理层签核还是由用户/发起人接受,问题仍然是不同词汇、优先级和视角中的一个。 I asked a simmilar question here .

我也得到了各种各样的答案,非常接近有用,但还不够明确。浏览和搜索,所以使用相关的关键词,让我找到有用的见解,在各种答案散布在许多无关的问题。找到并提取这些宝石让我摆姿势 this question on site-mining .

能够标记各种答案并将它们全部显示在一个列表中是很有用的,但是遗憾的是,在So中还没有这种功能。我 suggested it on uservoice .

希望你能从我提供的参考资料中找到一些有用的东西。

正确的回答问题是秘密。

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

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

描述性的图片确实有助于非技术人员理解您所说的内容。例如,下面是来自Sun的一个例子,描述了如何在其中一个稍微复杂的应用程序中处理信息。

diagram from docs.sun.com http://docs.sun.com/source/816-7152-10/images/wsgoverview3.gif

非技术人员不可能用文字解释这个应用程序。指着图说,看,这部分是我们的弱点,我们需要改进。这对他们来说是有意义的。如果他们觉得他们对你所做的有所了解,他们会更愿意支持你的请求。

我喜欢 Technical Debt 因为它可以将技术问题(尽管不严格)转化为货币问题——而货币是大多数管理者都理解的东西。

尽管技术债的概念最初应用于建筑问题,但它可以更广泛地应用于任何有压力采取捷径的情况——也就是说,进入技术债——而不是第一次正确地进行。(正确的做法相当于存钱买东西——这需要时间——而不是赊账买东西然后负债。)

正如债务可以是好的(如住房贷款)和坏的(如信用卡),所以技术债务可以是好的和坏的。我不会试图完全描述这些差异,但是可以准确地跟踪好的技术债务,这样您就知道自己负债了多少。

所以,试着从技术债务的角度来解释你的重要的、非用户界面问题,以及不通过支付债务利息来解决问题的成本。