解释为什么“只需添加另一列到数据库”对于非程序员来说是一个坏主意
我有销售人员和豆制品柜台谁试图出售定制给客户,这很好。 但是当一个复杂的变更请求发回给我一个大的估计时,他们会感到困惑。 他们经常回到我身边:“为什么你不能再添加一列?” 而另一个则是PER客户端的十几个自定义列。
到目前为止,我所能回来的是“我们试图保持数据库正常化”,这对他们来说毫无意义。 我告诉他们,我可以创build一个允许每个客户定义他们自己的一套自定义字段的表格系统,但是当然比“只添加几列”要花费更多的时间和金钱。 当然,他们也想吃蛋糕,也吃。
那我怎么能让他们明白?
我发现的最好的方法是展示如何创build一个新的function ,他们要求你不能只添加几个自定义的列。 function比自定义更好,特别是当你可以向某人收费时。
在进入技术层面之前,试着为你做一个好的商业案例。
我告诉他们,我可以创build一个允许每个客户定义他们自己的一套自定义字段的表格系统,但是当然比“只添加几列”要花费更多的时间和金钱。
我认为你应该把这个选项推给你的老板,因为可定制性显然是一个非常需要的function。 强调为每个客户单独定制(而不是广义的,有限的可定制)系统意味着必须为每个客户创build补丁和更新(导致更长的推出时间和更高的成本); 非标准化的安装意味着服务台门票需要更长的时间才能closures(导致不满意的客户和更高的成本); 等等
换句话说,通过显示解决scheme的成本远远超过解决scheme的成本,从而长期获得短期的收益。
销售人员专注于销售。 这是他们的佣金。 他们不关心后面的事情。 然而,老板把重点放在成本上。 卖给你的老板,你的老板可以卖给销售人员。
啊..一点知识是一件危险的事情。
试试这个:
你:我们哪些公司没有卖给?
销售: Acme Industries,OCP Corp,等等等等
你:呃….为什么你不能再打几个电话呢?
答案当然是销售并不那么简单。 软件开发也不是。 除非他们真的想要在架构和维护方面花费数小时的时间,否则我build议他们相信你作为软件开发人员的判断。
这是这里的问题,信任。 你应该向他们解释他们对你的能力缺乏信任。
你可以告诉他们,devise不好的数据库意味着从长远来看:
-
他们需要更长的时间来检索他们的数据 – 他们真的想等待吗?
-
devise查询来生成报告会更困难,花费更长时间 – 如果明天他们需要这个查询,他们是否要告诉他们仍然在工作?
-
这将是一个噩梦维护,容易出错的查询更可能被写入。
如果他们是销售人员和豆制柜台,那么他们一定会明白全能的美元(英镑,欧元等)。 你能否certificate花费在维护这些额外的列上的时间并不能certificate增加的销售额?
在这里要非常小心,确保你的观点是有道理的。 过去,我发现自己对自定义的抵制更多,因为我不想让我漂亮的小领域模型变得丑陋,而不是因为维护起来真的很难。 一个体面的分析将帮助你确定你为什么抵制自定义。
请记住 – 最重要的是你需要保持客户满意度才能保持业务。 我们有思想的开发人员有时会忽视这一点,我们的追求使维护和简单。
Google“技术债务”; 向他们展示结果。
如果您从事的是定制产品的销售业务,则产品需要支持定制化,而不必在每次销售时都分解构build。
听起来像你试图解释说,没有用。 相反,请尝试估算为一张桌子添加“定制正确方式”的成本,例如,维护具有不同定制的六种版本的产品,并修复一个错误。 我敢打赌,他们将会看到,他们很快就会获得统一的代码库和架构。 而且一个开发者不是疯狂的。
告诉他们,当人们制造一辆车,然后他们想要一个比以前更快,更多的模型时,他们通常不会添加另一个引擎。
问题是,“我们试图保持数据库的正常化”几乎肯定是错误的答案 – 它将不信任和交叉目的带回法庭。
你必须把注意力转移到最终目标上,如何才能最好地实现这个最终目标(也许在几个版本中)以及短期和长期的成本。 我已经看到提到技术债务的答案,成本估算应考虑到这些因素。
“只是添加另一列”可能不是一个坏主意? 你真的没有给出整个商业案例。 另一方面,他们用一个无知的技术问题挑战了你的消极反应。 这并没有达到帮助你理解这个要求的核心,因为他们不喜欢听到“不”。 (我想知道原来的问题是什么。)
使数据库正常化是一个技术问题,与系统必须满足的要求无关 – 这是一个系统devise原则,您可以使用这个原则来交付具有可维护性等特性的系统。 但是一个不能满足用户需求的可维护系统是零价值的,而不可维护的满足用户需求的系统却有非零价值(这可能会超出维护成本 – 这是一个业务问题)。 无论是EAV还是某种其他机制都不是必需的 – 这只会导致系统复杂性或成本增加。
如果要求过于昂贵,那么这就是商业案例的一部分。 您还没有告诉我们足够的关于这些表模型的体系结构或实体的types。 假设你有100个客户。 在特定实体中的列可能有重叠。 多达95%的客户永远不会使用可选的Billing-Address或Middle-Name列,这并不意味着这些列被排除在外 – 不仅如此,他们往往是在一个原始的devise! 或者,如果这是一个Products表,并且每个客户想要很多特殊的列并且没有重叠,那么您可能需要一个用户定义的现场系统(EAV / XML /标签 – devise必须符合要求)保持一个有凝聚力的系统devise。
我很less发现企业忽视技术债务的论点 – 特别是如果一个提出的解决scheme可以满足用户的需求,灵活性可以成为一个卖点。 我发现,如果您尽可能快速,彻底地提出解决schemeselect,而不花费更多时间解释为什么不能完成某些工作,或者需要花费多less成本,下午,实际上完成了工作。
我从来没有尝试过这个,但我已经想过了:比喻一下法律制度。 存在法律上的漏洞,是因为立法者试图用懒惰的方式来修补这个系统。 软件等同于错误,安全漏洞等等。解决这些问题的唯一方法就是精心策划和努力工作。
让他们了解在开发时间内有多less成本,这个变化是否需要一到两名开发人员的时间? 那么testing呢? 如果复杂的请求花费更多,那么整个公司的工作就会减less。 帐户/项目经理应该是缓冲这些types的请求的中间人。
在技术方面,你不会在任何地方向他们解释。 你需要一个比喻。 如果可以的话,将它定制给与你交谈的人。 如果他/她是一个汽车怪胎,让他们思考引擎修改方面。 福特要在金牛座提供三种不同的电动机,还是按需定制MODS,费用多less?
一旦他们接受了比较,即使他们没有完全理解,你也可以开始理解为什么这个比喻是适用的。
还有另外一个很好的方法来帮助他们看到你的方式 – 花一些时间看看它的方式。 当你的薪水取决于给顾客他们想要的东西时,你根本不在意工程中的螺旋桨头是怎么告诉你的。 如果您收到很多自定义请求,则应尽可能考虑采用架构和策略方法来提供这些自定义设置。
为了扩展tuinstoel的build议(避免通用的实体属性值结构):虽然我一般喜欢这种结构的轻量使用,但过多(无论是什么意思)的使用会降低性能,如上所述。 这样的结构不能很好地索引。 我写了和支持一个这样的系统。 当我们有10万个密钥的50,000个“实体”时,即使在中端硬件上也是很慢的)。
但是,它们非常有用,而且相当容易实施。 因此,如果需要在每个客户的基础上添加许多任意的“额外字段”,那么这可能是最有意义的。
另一个可能的select可能是在适当的表中添加一些未使用的通用列,供客户端用于他们自己的目的。 有些企业应用程序就是这样做的。 销售表可能有十到二十个CUSTCODE01到CUSTCODE10列,每个应用程序的部署可以以不同的,完全自定义的方式使用。
这可能起初看起来很可怕,也可能是一个快乐的媒介。 在每个客户的基础上有相当多的空间可以自定义,而不需要“仅仅添加一列”并且中断应用程序或者开发过程,或者b)实现一个可能很慢的通用系统。 尽pipe如此,您只能获得有限的可用性,并且缺less自我logging的列名(但可根据需要定制列描述)。
…我告诉他们我可以创build一个表格系统,允许每个客户定义他们自己的一套自定义字段,但当然这需要更多的时间和金钱….
看起来你想build立某种通用数据模型? 实体 – 属性 – 值…?
那些generics模型往往是真正的慢,他们不能正确索引和混淆查询优化。 添加一些列通常会更好。
在走普通路之前做一些非常彻底的基准testing。
也许这是数据库供应商的依赖,但是如果你使用Oracle,我宁愿在实体属性值路上添加一些列。
你可以解释这个问题与图书馆进行比较。 有很多书。 小而厚的,大而薄的,每个人都可以想象得到。 现在,如果你想在某个地方存储更多的信息,将一些新的页面添加到一本书中比放大一些单一的页面要简单很多 – 如果一本书的多个页面比其他页面大,那么这个页面不是很健壮,这个信息是否在索引中没有条目? 也许最好把新的附加信息存储在另外一本书中,一个新的结构。 想象一下,如果一个图书馆的全部内容都写在一本厚厚的书中,人们如何获得信息呢? 没有其他人可以find任何东西,直到你find你想要的东西,并把它放回原处。如果你能够携带这本巨大的书。 如果你只想知道一个人的出生date,为什么要检索整个Livestory?
所提到的人不必了解数据库的架构,但他们应该相信你。 而且你组织起来,这样他们就可以把他们的信息放在这个数据库的大洞中,并在需要的时候把它恢复 – 快速而可靠。