我有销售人员和豆子柜台试图向客户销售定制，这很好。但是当一个复杂的变更请求出现我发回一个大的估计时，他们会感到困惑。他们常常带着“为什么你不能再增加一列？”来回到我身边。另一方面，它们意味着PER客户端的十几个自定义列。
到目前为止，我所能回过头来的是“我们正在努力使数据库保持正常化”，这对他们来说毫无意义。我告诉他们我可以创建一个表系统，允许每个客户定义他们自己的一组自定义字段，但当然比“只添加几列”需要更多的时间和金钱。当然，他们也想要自己的蛋糕，也可以吃。
那我怎么能让他们明白？
答案 0 :(得分：55)
我告诉他们我可以创建一个表系统，允许每个客户定义他们自己的一组自定义字段，但当然这比“只添加几列”需要更多的时间和金钱。
我认为你应该把这个选项推给你的老板，因为可定制性显然是一个非常需要的功能。强调每个客户的单独定制（而不是通用，有限的可定制）系统意味着必须为每个客户创建补丁和更新（导致更长的推出时间和更高的成本）;非标准化安装意味着HelpDesk门票需要更长时间才能关闭（导致不满意的客户和更高的成本）;等
换句话说，通过证明他们的解决方案的成本远远超过您的解决方案的成本来销售短期痛苦以获得长期收益。
销售人员专注于进行销售。这就是他们的佣金。他们不关心后来发生的事情。然而，老板们专注于成本。卖给你的老板，你的老板可以卖给销售人员。
答案 1 :(得分：30)
我发现的最好的方法是展示如何根据他们要求的内容创建一个新的功能，只有几个自定义列才能添加。功能优于自定义，尤其是当您可以为某人收取费用时。
在进入技术人员之前，尽量为自己做一个好的商业案例。
答案 2 :(得分：17)
试试这个：
您：我们未向哪些公司出售？ 销售： Acme Industries，OCP Corp，等等等等 你：嗯....为什么你不能再打几个电话？
答案当然是销售并不那么简单。软件开发也不是。除非他们真的想要在架构和维护方面花费数小时的解释，否则我建议他们相信您作为软件开发人员的判断。
这是问题，信任。你应该向他们解释，他们通过发表这些陈述表现出对你的能力缺乏信任。
答案 3 :(得分：10)
你可以告诉他们，设计糟糕的数据库意味着从长远来看：
他们需要更长的时间来检索他们的数据 - 他们真的想等待并等待吗？
设计查询以生成报告会更难，需要更长的时间 - 再次，如果他们明天需要查询，他们是否希望被告知它仍在处理？
维护是一场噩梦，更容易写错误查询。
答案 4 :(得分：10)
如果他们是销售人员和豆类柜台，那么他们肯定会理解全能的美元（英镑，欧元等）。您是否可以证明维护这些额外列的时间并不能证明增加的销售额是合理的？
在这里要非常小心，确保你的论点有意义。我发现自己过去一直在做更多的自定义，因为我不想让我的小域模型丑陋而不是因为它真的难以维护。一个体面的分析将帮助您确定您抵制自定义的原因。
请记住 - 最重要的是，您需要让客户满意才能保持业务。我们有思想的开发人员有时会在我们追求可维护和简单的过程中忽视这一点。
答案 5 :(得分：9)
答案 6 :(得分：7)
如果您的业务是销售产品以及自定义项，则产品需要支持自定义，而无需在每次销售时分叉构建。
听起来你已经尝试过解释，但无济于事。相反，尝试估算为一个表添加“正确定制”的成本，例如，维护具有不同自定义的产品的六个版本，并修复一个错误。我敢打赌，他们会看到他们很快就会拥有统一的代码库和架构。还有一个没有疯狂的开发人员。
答案 7 :(得分：7)
告诉他们，当人们制造汽车然后他们想要一个比以前更快且做得更多的模型时，他们通常不会添加另一个引擎。
答案 8 :(得分：6)
问题是“我们试图保持数据库正常化”几乎可以肯定是错误的答案 - 它将球带回了不信任和交叉目的的法庭。
您必须将重点转回最终目标，如何最好地实现最终目标（可能在多个版本中）以及短期和长期内的成本。我已经看到在答案中提到技术债务，成本估算应该考虑这些因素。
不可能是“只添加另一列？”的坏主意。你真的没有给出整个商业案例。另一方面，他们用无知的技术问题挑战你的消极反应。这并不是帮助你理解要求的核心，因为他们不喜欢听到“不”。 （我想知道问题的原始陈述是什么。）
使数据库规范化是一个技术问题，与系统必须满足的要求无关 - 这是一个系统设计原则，用于提供具有某些属性（如可维护性）的系统。但是，不能满足用户需求的可维护系统具有零价值，而满足用户需求的不可维护系统具有非零值（维护成本可能超过这一点 - 这是一个业务问题）。是否需要EAV或其他一些机制并不是真正的重点 - 这只会导致系统复杂性或成本增加。
如果要求太昂贵而无法实施，那么那是业务案例的一部分。您还没有告诉我们足够的架构或这些表建模的实体类型。假设您有100个客户。特定实体中的列可能存在重叠。只有95％的客户永远不会使用可选的Billing-Address或Middle-Name列，这并不意味着那些列被遗漏 - 不仅如此，它们通常采用原始设计！或者，如果这是Products表并且每个客户端都需要许多特殊列并且没有重叠，则可能需要用户定义的字段系统（EAV / XML / tag - 设计必须符合要求），以便保持一致的系统设计。
我很少发现业务忽略技术债务论点 - 特别是如果可以证明提出的解决方案能够满足用户需求并且灵活性可以成为卖点。我发现，如果您尽可能快速，彻底地提出解决方案选择，而不花费更多时间来解释为什么无法完成某些工作或者花费多少成本，那么企业通常会更喜欢这样做。下午并实际完成工作。
答案 9 :(得分：5)
我自己从未尝试过，但我已经考虑过了：对法律制度进行类比。存在法律漏洞，因为法律制定者试图用懒惰的克拉格修补系统。相当于软件的是漏洞，安全漏洞等。解决这些问题的唯一方法就是仔细规划和努力工作。
答案 10 :(得分：3)
让他们了解开发时间的成本是多少，这个变化需要一两个开发人员的时间吗？怎么样测试？如果复杂的要求成本更高，那么整个公司的工作量就越少。帐户/项目经理应该是缓冲这些类型请求的中间人。
答案 11 :(得分：3)
您无法通过技术术语向他们解释任何问题。你需要一个比喻。如果可以的话，给你正在谈话的人量身定做。如果他/她是一个汽车狂热者，让他们考虑发动机改装。福特在金牛座提供三种不同的电机或按需定制的电机需要多少钱？
一旦他们接受了这种比较，即使他们不完全理解，你也可以开始进入为什么这个比喻适用。
还有另一种很好的方式可以帮助他们按照自己的方式进行操作 - 花一些时间来看待自己的方式。当您的薪水取决于为客户提供他们想要的东西时，您并不关心工程中的螺旋桨头是什么告诉您的。如果您收到大量自定义请求，则应尽可能考虑提供这些自定义的架构和战略方法。
答案 12 :(得分：2)
...我告诉他们我可以创建一个表系统，允许每个客户定义他们自己的一组自定义字段，但当然这需要更多的时间和金钱.... < / p>
看起来你想构建某种通用数据模型？实体 - 属性 - 值...？
这些通用模型通常很慢，无法正确编制索引并使查询优化器混淆。通常最好只添加一些列。
在走上通用道路之前做一些非常彻底的基准测试。
也许它依赖于数据库供应商，但如果您使用Oracle，我宁愿在entity-attribute-value-road之上添加“只添加一些列”。
答案 13 :(得分：2)
扩展tuinstoel的建议（避免泛型实体 - 属性 - 值结构）：虽然我通常喜欢这种结构用于轻量级使用，但过量（无论这意味着）使用会降低性能，如上所述。这种结构不能很好地编入索引。我写了并支持一个这样的系统。当我们拥有50,000个“实体”时，每个实体都有10-100个密钥，即使在中端硬件上也是如此。
但是，它们非常有用且相当容易实现。因此，如果需要在每个客户的基础上添加许多任意“额外字段”，那么它可能最有意义。
另一种可能的选择可能是在适当的表中添加一些未使用的通用列，以供客户端用于自己的目的。一些有进取心的应用就是这样做的。 Sales表可能有10或20个CUSTCODE01到CUSTCODE10列，应用程序的每个部署都可以使用不同的，完全自定义的方式。
这可能起初看起来很可怕，也可能是一种快乐的媒介。在没有a）“仅添加列”和破坏应用程序或开发过程，或b）实现可能较慢的通用系统的情况下，存在相当大的空间来定制每个客户。但是，您只能获得有限数量的可变性，并且缺少自我记录的列名称（但可以根据需要自定义列描述）。
答案 14 :(得分：1)
您可以通过与库进行比较来解释此问题。有很多书。小而大，薄而厚 - 每个人都可以想象。现在，如果你想在某个地方存储更多的信息，那么将一些新的页面添加到一本书比放大一些页面要简单得多 - 如果一本书的几个页面比其他页面大，那么这不是很强大，如何找到如果在竞争索引中没有条目，这个信息是什么？ 也许最好将新的附加信息存储在另一本书中，一本带有特定结构的新书。 想象一下，如果图书馆的整个版本都写在一本厚厚的书中，人们如何获得信息？在你找到你想要的东西之前，没有其他人可以找到任何东西，并把书放回原处...如果你能够携带这本巨大的书。 如果您只想知道一个人的出生日期，为什么要检索整个Livestory？
上述人员不必了解数据库的体系结构，但他们应该信任您。然后你组织它，这样他们就可以把信息扔进这个大洞的数据库中，并在他们想要的时候把它拿回来 - 快速可靠。