你从完全错误的角度看待这个问题。这不是来自对技术一无所知的客户提出的愚蠢要求。您认为这是一种设计约束,会在项目中引入风险。
因此,当您在项目中遇到风险时,您会做任何事情:定义风险、评估风险并推荐缓解策略。
- 定义风险。 说它会导致“性能问题”和“不容易扩展”并不是定义风险。您需要准确说明您的意思。什么不会执行,为什么?什么规模的变化会遇到这些问题?
- 评估风险。 好的,所以你认为有问题。有多糟糕?您如何确定这些性能问题会实际发生?如果他们这样做会对用户产生什么影响?您说程序无法扩展:规模的增长是否会暴露设计缺陷,即使在卡片中?最重要的是,你怎么知道这个? 在这里花时间构建和基准测试原型可以为您节省很多毫无意义的争论。
- 推荐缓解策略。 实现这一点的正确方法是什么?为什么它是正确的方法?再说一次,你怎么知道的? 同样,原型设计是您的朋友。
做这个练习会产生一些事情。
首先,你可能会发现,虽然你对每一个细节都是正确的,但当你把它们放在一起时,这并不重要。是的,这个程序不会很好地执行或扩展,但如果它的预期用例都不会遇到这些问题,那么它很容易不值得解决。
其次,告诉某人“这不会执行,我只知道它”和告诉他“我对我们期望的用例进行了基准测试,看起来这种方法将导致四个——或每个用户事务的 5 秒响应时间。”
第三,如果你知道什么条件会导致软件失败,并且你向客户表达了这些担忧,而客户说“我们真的只是希望它以这种方式工作”,那么你已经履行了你的责任。如果由于客户选择不减轻您确定的风险而导致失败,那么没有人可以指向您并说这是程序员的错。
最重要的是,证据胜过观点。您已经将整个问题构建为您的意见与客户的意见的案例。这是一个失败的提议。您需要做的就是将其框定为“这是我们需要解决的问题”。要以这种方式提出问题,您必须证明问题的存在,为此,您需要证据。
最终,决定是否减轻风险的是客户,而不是您。您可以向他提供最好的信息来支持他的决定。而且你需要清楚地表明这是他的决定。
我发现,不止一次,一封简单的电子邮件完美地集中了注意力:
我一直在审查设计,我认为这里有一个风险需要我们讨论。[方法 A] 对交易量非常敏感,我担心我们将拥有足够多的用户,我们会遇到麻烦。
我使用 [Approach B] 进行了一个小测试,它的敏感度要低得多;在我的简单原型中,我能够从中获得每秒 X 笔交易。这是有道理的,因为[两种方法如何处理事情的技术比较]。
我特别担心这一点,因为[描述如果程序表现不佳将如何失败]。
这对我来说似乎是一个重大问题。如果是我,我会使用 [方法 B],因为 [描述这种方法将如何降低风险]。
但是你比我更熟悉[方法A],我很乐意在这件事上听从你的指导。你认为我们应该怎么做?
This message very clearly says "If you disregard what I'm telling you, here's how the project is going to fail, and I'm going to have documentation demonstrating that you told me to do it that way." It also doesn't actually say that.