如何解释样本量不影响项目长度

我们有大型企业项目，它们通常涉及将数据从源数据库复制到目标数据库，然后设置许多其他应用程序来同步此数据等。

最后一个项目包含250,000个项目（数据行）。下一个项目将仅包含4,000个项目。项目经理/业务人员认为，该项目应该是完成时间的1/10，因为它只是上一个项目规模的一小部分。

我可以用一个很好的类比来解释，编写代码以将数据从一个系统传输到另一个系统所花费的时间是相同的，而与项目的数量无关-写一个项目或一亿个代码将花费大致相同的时间。观点看法。

告诉他们，这就像在该国偏远地区修建一条新的四车道高速公路。不管该道路每天被100辆汽车使用还是每天1000辆汽车使用，创建该道路的努力将大致相同。

当然，如果要每天支持一百万辆汽车，您必须使道路更加坚固，但是无论如何，您都必须砍伐相同的树木，冲破相同的山脉，平整相同的数量污垢，无论有多少辆汽车上路，这些活动几乎都是固定成本。

给他们一个计算器，要求他们将1238783423加到9858238483，这需要多长时间。然后要求他们将3423加到8483，并告诉他们您期望答案大约快100000次。

您可能还会解释数据量（可能）会影响软件运行所花费的时间长度，而不是影响开发时间。

放到经理说话。

如果您构建一台机器以每秒1个小部件的速度制造小部件，那么使用它来制造100个小部件或10000个小部件都没有关系，则机器本身会花费相同的时间来构建。

区别在于运行时，而不是构建时。

所有的管理类都通过假设的小部件工厂来解决此类问题。

不要使用类比。只是解释一下。

• 对于极少量的项目（10？），手动转换最便宜。根本不用编写程序。
• 对于少量项目（100个？），值得编写一个程序。您可以通过忽略理论上可能的但在实践中不会出现在小数据集中的数据的某些排列来节省开支。或以很小的数字出现，程序可以拒绝它们，并且可以手动转换它们。对数据进行快速分析以检查是否在数据中实际出现了极端情况是可行的。如果未出现，则可以忽略它们。
• 通过这一点后，数据的实际大小将不受影响。您需要编写一个严肃的程序来处理任何可能的输入。该程序可以处理1,000或100,000个项目。运行只需要更长的时间。

教育胜于无聊:)

并不是一个真正的类比，但我仍然相信有一个处理此论点的好方法：证明其中存在致命缺陷。

您以前的项目包括（从我那里得到的）复制数据并对其进行一些修改。

如果我做对了，那么一个由100名会计师组成的团队可以在几个月内完成这项工作。那他们为什么要让软件开发人员来解决这个问题呢？

因为您创建的软件并不关心它是否会处理10或1000万个数据（不完全是，但是我怀疑您的经理是否关心O(n)复杂性）。因此，它可能更便宜，更快和更干净（更少出错的过程）。

如果您比较激进，甚至可以建议他们，如果他们不喜欢软件团队的工作速度，他们总是可以请会计师亲自完成工作。

这使您的经理在开发上一个项目时的工作变得轻松多了，而现在，当他们不得不使用相同的逻辑来确定下一个软件是否可以运行1000万或4时，他们就不必在意了。 000行，他们突然忘记了。

我认为在您的情况下，经理们只是在打估计游戏，并试图通过指出4000与250000之间的差异并希望有“罪恶感”来迫使团队更快地工作。我可能是错的，但是我之前已经看过。

这是管理程序员团队（实际上是任何类型的创意团队）的一种糟糕方法，并且对任何人都没有帮助。

我知道您要求类比，但是我认为这是错误的技术。

我相信，正如其他人在过去提到的那样，您需要强调数据大小会影响运行时间，而不是构建时间。
因此，为他们分解-您实际上有两个子项目，即构建和运行。建筑项目（在大多数情况下）应该与运行多少数据无关，这仅关系到数据类型。
至于运行时-当然，它们可以根据数据大小（不包括任何非平凡的固定开销）进行考虑。

这就好比您必须开车去墨尔本-但首先必须制造汽车。
当然，开车去悉尼可能会更快-但制造车辆所需的时间相同。
_{好吧，我毕竟给了你一个比喻。}

也许是电话？您的客户需要定制的电话。如果他每天拨打0个电话或每天拨打100个电话，那么创建电话所需的时间将相同。

手机传输的数据类似于程序复制的数据。

您的经理似乎将开发时间与程序的实际运行时间混淆了。但是他们的误解可能有所不同。他们可能会认为涉及的“领域”较少。不仅是更少的数据记录。如果只有100000个单独的数据字段，那么与只有10个字段相比，这将是一个巨大的开发工作。系统之间的映射工作更多。在这种情况下，它们实际上可能是正确的，但是仍然涉及一些持续的开销，您不能简单地将其除以字段数来获取时间。

正如我要描述的那样，数据具有2个维度的长度和宽度。长度是记录数，宽度是所有表中的总列数

现在，当您要导入数据时，就像从孔中获取一个块一样。您需要为最小尺寸制造一个足够大的孔，然后将块穿过

现在具有1000万和1万的最小尺寸仍然是宽度。因此，宽度决定了打孔所需的时间。

要完成这个比喻，ff的长度要短一些，您只需手动输入数据即可

我每周都会导入数百个客户端文件。

我发现的一件事是，小文件通常需要更长的时间来开发数据导入，原因是：

• 它们不太可能遵循规则（我们具有标准的文件结构，我从未见过有小型客户端以我们要求的标准格式提供数据给我们，但是大型客户端理解为什么这很重要）
• 它们往往会有更多的数据完整性问题，尤其是当它们来自Excel文件而不是数据库（大型文件通常来自该数据库）时，这些数据已经内置了数据完整性规则。
• 每次都不太可能以相同的格式提供它们。

我们发现，通过构建具有标准子进程的父子SSIS包，可以节省大量开发时间，并且可以在父级中完成以标准形式获取数据的任何必要操作。这样，当我们进行估算时，它变得不再是多少记录的问题，而是变得越来越接近我们要获取的文件的标准。现在，当较小的东西需要较长的开发时间时，因为它们不符合标准，我们不会收到太多的抱怨。

编写程序有点像雇用新员工。您必须教他们在哪里可以找到数据，如何处理数据以及如何为您提供结果。您必须留意他们一段时间，以确保他们做得正确。如果他们的工作很复杂/很重要或者他们要做大量的工作，则可能要花一些时间来培训他们，但是无论如何，这都需要大量的时间。

许多经理都熟悉培训新员工所涉及的管理费用，因此这对他们来说可能很有意义。

（如果您的新员工是一个超能力的机器人，这个类比就破裂了，无论您向他们扔了多少记录，它都可以在很短的时间内完成工作，但希望到那时您已经指出了要点。）