如何处理愚蠢的客户请求？

我赢得了一个项目的竞标,现在客户(他本身来自IT部门)希望我以一种非常特殊的方式构建/实施解决方案.我确信应用程序会因性能问题而失败.而且它不易扩展.

这个特定的客户端/用户不知道我将使用的平台和语言(ASP.NET/SQL Server).他唯一的知识是在科博尔,并试图让他了解我的POV只是让他生气.

他联系了我.他是选择我作为竞标赢家的人.他将批准我的支票.他是我与这家公司的唯一联系人.

我不知道提供一个我知道会失败的解决方案,我不想被称为使它失败的愚蠢程序员.我确实知道他们的真正需求和这个应用程序的使用模式,因为我过去已经为他们完成了项目.

另一方面,以他的方式执行此操作只会延长我的合同时间(因此,更多的财务收益),以便通过修改代码来解决问题.

我是否应该从项目中退出,知道我可能永远失去这个客户？

要么…

我是否应该服用避孕药并从扩展项目中获取经济利益,并将其视为成本的不良名声？

你从完全错误的角度看待这个问题.这不是来自对技术一无所知的客户的愚蠢要求.您认为这是一个设计约束,会将风险引入项目中.

因此,当您在项目中遇到风险时,您会做任何事情:定义,评估和推荐缓解策略.

定义风险. 说它会导致"性能问题"和"不易扩展"并不能定义风险.你需要准确说明你的意思.什么不会执行,为什么？规模会有什么变化会遇到这些问题？

评估风险. 好的,所以你认为有一个问题.有多糟糕？你有多确定这些性能问题会不会发生？如果他们这样做会对用户产生什么影响？你说程序无法扩展:规模的增长是否会暴露设计缺陷甚至卡片？最重要的是,你怎么知道这个？ 这里是花时间构建和基准测试原型可以为您节省大量毫无意义的论点.

推荐缓解策略.实现这个 的正确方法是什么？为什么这是正确的方法？再说一遍,你怎么知道这个？ 再次,原型设计是你的朋友.

这项练习将产生一些事情.

首先,你可能会发现,虽然你对每个特定事物都是正确的,但当你把它们放在一起时,这并不重要.是的,这个程序不能很好地运行或扩展性很好,但是如果它的预计用例都不会遇到这些问题,那么很可能不值得解决它们.

第二,告诉某人"这不会发挥作用,我只是知道它"并告诉他"我对我们期望的用例进行基准测试,看起来这种方法将导致四个 - 或每个用户交易的5秒响应时间."

第三,如果您知道什么条件会使软件失败,并且您向客户阐明这些问题,并且客户说"我们真的只是希望它以这种方式工作",那么您已经履行了您的责任.如果由于客户选择不降低您已识别的风险而失败,则没有人可以指向您并说这是程序员的错.

最重要的是,证据胜过意见.你把这整个问题都描述为你的意见与客户的对比.这是一个失败的主张.您需要做的是将其描述为"这是我们需要解决的问题".要以这种方式构建问题,你必须证明问题的存在,为此,你需要证据.

最终,客户决定是否应该减轻风险,而不是你.你可以向他提供最好的信息来支持他的决定.而且你需要明确表明,这是他的决定.

我不止一次发现,一封简单的电子邮件完全集中了注意力:

我一直在审查设计,我认为这里有一个我们需要讨论的风险.[方法A]对交易量非常敏感,我担心我们会有足够的用户,我们会遇到麻烦.

我使用[方法B]进行了一些测试,它的灵敏度要低得多; 在我的简单原型中,我能够每秒获得X次交易.这是有道理的,因为[技术比较两种方法如何处理事物].

我特别担心这个因为[描述程序如果表现不佳会如何失败].

这对我来说似乎是一个重大问题.如果是我,我会使用[方法B],因为[描述这种方法将如何降低风险].

但是你对[方法A]比我更熟悉,我很乐意遵从你对此事的指导.您认为我们应该怎么做？

这条消息非常明确地说:"如果你忽视我告诉你的内容,这就是项目将如何失败,我将会有文件证明你告诉我这样做." 它实际上也没有这么说.

我想你需要和他坐下来,并提出一些澄清问题.

您需要了解为什么他希望以特定的方式实现它.您需要证明您希望提供满足业务需求的可行解决方案.

可能存在一些潜在的问题,需要解决的问题,正如您所说,他可能不熟悉您提出的技术并需要一些保证.

如果做不到这一点,请确保完整记录并签字.