我有销售人员和 bean 柜台，他们试图向客户销售定制产品，这很好。但是当一个复杂的变更请求出现时，我发回了一个很大的估计，他们会感到困惑。他们经常对我说“你为什么不能再添加一列？” 换句话说，它们意味着每个客户都有十几个自定义列。
到目前为止，我所能回答的只是“我们正在努力保持数据库正常化”，这对他们来说毫无意义。我告诉他们我可以创建一个表格系统，允许每个客户定义他们自己的自定义字段集，但当然这比“仅仅添加几列”需要更多的时间和金钱。当然，他们也想吃蛋糕。
那我怎样才能让他们明白呢？
问问题
2718 次
15 回答
55
我告诉他们我可以创建一个表格系统，允许每个客户定义他们自己的自定义字段集，但当然这比“仅仅添加几列”需要更多的时间和金钱。
我认为你应该把这个选项推给你的老板，因为可定制性显然是一个非常需要的功能。强调为每个客户端单独定制（而不是通用的、有限的可定制性）系统意味着必须为每个单独的客户端创建补丁和更新（导致更长的推出时间和更高的成本）；非标准化安装意味着 HelpDesk 票证将需要更长的时间才能关闭（导致客户不满意和更高的成本）；等等
换句话说，通过证明他们的解决方案的成本远远超过你的解决方案的成本，以短期的痛苦换取长期的收益。
销售人员专注于进行销售。这就是他们获得佣金的原因。他们不在乎接下来会发生什么。然而，老板们关注的是成本。卖给你的老板，你的老板可以卖给销售人员。
于 2009-11-12T18:45:18.957 回答
30
我发现的最好方法是展示如何根据他们的要求创建一个新功能，而这些功能是您无法仅通过几个自定义列添加的。功能比自定义更好，尤其是当您可以向某人收费时。
在你进入技术领域之前，试着为你的一方制定一个好的商业案例。
于 2009-11-12T18:45:05.717 回答
17
啊.. 一点知识是一件危险的事情。
试试这个：
你：我们没有卖给哪些公司？
销售： Acme Industries、OCP Corp、等等等等。
你： 嗯....你为什么不能再打几个电话？
答案当然是销售不是那么简单。软件开发也不是。除非他们真的需要数小时的架构和维护方面的解释，否则我建议他们相信您作为软件开发人员的判断。
这就是这里的问题，信任。您应该通过发表这些声明向他们解释他们对您的能力缺乏信任。
于 2009-11-12T18:58:16.983 回答
10
您可以告诉他们，设计不佳的数据库从长远来看意味着：
他们将需要更长的时间来检索他们的数据 - 他们真的要等待和等待吗？
设计查询以生成报告将更加困难并且需要更长的时间 - 再次，如果他们明天需要该查询，他们是否希望被告知它仍在处理中？
维护将是一场噩梦，更容易编写容易出错的查询。
于 2009-11-12T18:39:10.310 回答
10
如果他们是销售人员和豆类柜台，那么他们一定会了解万能的美元（英镑，欧元等）。您能否证明花费在维护这些额外列上的时间并不能证明增加的销售额是合理的？
在这里要非常小心，并确保你的论点是有道理的。过去我发现自己更不愿意进行自定义，因为我不想丑化我漂亮的小域模型，而不是因为它真的很难维护。体面的分析将帮助您确定您拒绝定制的原因。
请记住 - 底线是您需要让客户满意才能继续开展业务。我们深思熟虑的开发人员有时会在我们寻求使事情可维护和简单的过程中忽略这一点。
于 2009-11-12T18:40:20.917 回答
9
谷歌“技术债务”；向他们展示结果。
于 2009-11-12T18:49:10.263 回答
7
如果您从事与定制一起销售产品的业务，则该产品需要支持定制，而不必在每次销售时分叉构建。
听起来您已经尝试过解释，但无济于事。相反，请尝试估算为一张表添加“以正确方式进行定制”的成本，例如维护具有不同定制的六个版本的产品，并修复它们之间的错误。我敢打赌，他们很快就会发现，拥有统一的代码库和架构，他们将领先一步。和一个没有被逼疯的开发者。
于 2009-11-12T18:41:28.080 回答
7
告诉他们，当人们制造汽车，然后他们想要一款速度更快、功能更多的车型时，他们通常不会添加另一个引擎。
于 2009-11-12T18:41:43.757 回答
6
问题是“我们正在努力保持数据库正常化”几乎可以肯定是错误的答案——它把球打回了不信任和交叉目的的法庭。
您必须将注意力重新转向最终目标，如何最好地实现该最终目标（可能在几个版本中）以及短期和长期的成本。我已经看到答案中提到了技术债务，成本估算应该考虑这些因素。
“只添加另一列？”可能不是一个坏主意。你真的没有给出整个商业案例。另一方面，他们用一个无知的技术问题来挑战你的否定回答。这并不能帮助您理解需求，因为他们不喜欢听到“不”。（我想知道问题的原始陈述是什么。）
使数据库标准化是一个技术问题，与系统必须满足的要求无关——它是一种系统设计原则，您可以使用它来交付具有某些属性（如可维护性）的系统。但是不满足用户需求的可维护系统具有零价值，而满足用户需求的不可维护系统具有非零价值（维护成本可能会超过该成本 - 这是一个业务问题）。是否需要 EAV 或其他机制也不是真正的重点——这只会导致系统复杂性或成本增加。
如果需求太昂贵而无法实现，那么这就是业务案例的一部分。您还没有告诉我们足够多的有关这些表模型的体系结构或实体类型的信息。假设您有 100 个客户。特定实体中的列可能存在重叠。多达 95% 的客户永远不会使用可选的 Billing-Address 或 Middle-Name 列，这并不意味着这些列被遗漏了——不仅如此，它们通常是原始设计！或者，如果这是一个 Products 表并且每个客户都想要许多特殊列并且没有重叠，那么您可能需要一个用户定义的字段系统（EAV/XML/标签 - 设计必须符合要求），以便保持一个有凝聚力的系统设计。
我很少发现企业会忽视技术债务的争论——特别是如果提议的解决方案可以满足用户需求并且灵活性可以成为卖点。我发现，如果您尽可能快速和彻底地提出解决方案选择，而不花更多时间解释为什么某事无法完成或它将花费多少，那么企业通常会更喜欢下午和实际完成工作。
于 2009-11-13T04:23:16.117 回答
5
我自己从未尝试过，但我想过：与法律制度进行类比。法律漏洞的存在是因为立法者试图用懒惰的工具修补系统。软件等价物是错误、安全漏洞等。解决这些问题的唯一方法是仔细计划和努力工作。
于 2009-11-12T18:36:09.180 回答
3
让他们了解开发时间的成本是多少，这种变化是否需要 1 或 2 个开发人员的时间？测试呢？如果复杂的请求成本更高，那么整个公司的工作就会减少。客户/项目经理应该是负责缓冲这些类型请求的中间人。
于 2009-11-12T19:01:43.060 回答
3
您将无法用技术术语向他们解释。你需要一个比喻。如果可以，请根据您正在与之交谈的人量身定制。如果他/她是个爱车狂，让他们考虑发动机改装。福特在 Taurus 中提供三种不同的电机或按需定制模块需要多少钱？
一旦他们接受了这种比较，即使他们不完全理解它，你也可以开始了解为什么这个比喻适用。
还有另一种好方法可以帮助他们以您的方式看待它 - 花一些时间以他们的方式看待它。当您的薪水取决于为客户提供他们想要的东西时，您不在乎工程中的螺旋桨告诉您什么。如果您收到大量定制请求，则应尽可能考虑交付这些定制的架构和战略方法。
于 2009-11-12T19:03:50.480 回答
2
...我告诉他们我可以创建一个表格系统，允许每个客户定义他们自己的一组自定义字段，但这当然需要更多的时间和金钱......
看起来您想构建某种通用数据模型？实体-属性-值...？
那些通用模型通常很慢，它们无法正确索引并混淆查询优化器。通常最好只添加一些列。
在走通用道路之前做一些非常彻底的基准测试。
也许它取决于数据库供应商，但如果您使用 Oracle，我更喜欢实体属性值路径上方的“仅添加一些列”路径。
于 2009-11-12T18:57:34.410 回答
2
扩展 tuinstoel 的建议（避免通用的实体-属性-值结构）：虽然我通常喜欢这种结构用于轻度使用，但过度使用（无论这意味着什么）会降低性能，如前所述。这样的结构不能被很好地索引。我编写并支持了一个这样的系统。到我们有 50,000 个“实体”时，每个实体都有 10-100 个键，即使在中端硬件上也很慢）。
但是，它们非常有用并且相当容易实现。因此，如果需要在每个客户的基础上添加许多任意“额外字段”，那么它可能是最有意义的。
另一种可能的选择可能是在适当的表中添加一些未使用的通用列，以供客户用于他们自己的目的。一些企业应用程序就是这样做的。一个销售表可能有十个或二十个 CUSTCODE01 到 CUSTCODE10 列，应用程序的每个部署都可以以不同的、完全自定义的方式使用这些列。
这乍一看可能很可怕，但它也可能是一种快乐的媒介。有相当大的空间可以在每个客户的基础上进行定制，而不需要 a）“只是添加一个列”并破坏应用程序或开发过程，或者 b）实现一个可能很慢的通用系统。但是，您只能获得有限的 felxablity，并且缺少自记录的列名（但可以根据需要自定义列描述）。
于 2009-11-12T20:15:55.097 回答
1
您可以通过与库进行比较来解释此问题。有很多书。一个小一个大一个，薄一个厚的——每个人都能想象得到。现在，如果您想在某处存储更多信息，那么在书中添加一些新页面比放大一些单页要简单得多 - 如果一本书的几页比其他的大，这不是很健壮，如何找到如果该信息在内容索引中没有条目？也许最好将新的附加信息存储在另一本书中，一本具有特定结构的新书。想象一下，如果图书馆的全部内容都写在一本厚厚的大书中，人们如何获得信息？在你找到你想要的东西并将书放回原处之前，没有人能找到任何东西……如果你能够携带这本巨大的书。
上面提到的人不必了解数据库的体系结构，但他们应该相信你。你组织它，这样他们就可以把他们的信息扔到这个数据库的大洞里，并在他们需要的时候取回——快速而可靠。
于 2009-11-12T21:03:27.260 回答