Как объяснить, что размер выборки не влияет на длину проекта

У нас есть крупные корпоративные проекты, которые обычно включают копирование данных из исходной базы данных в целевую базу данных, а затем создание ряда дополнительных приложений, которые синхронизируют эти данные и т. Д.

Последний проект содержал 250 000 элементов (строк данных). Следующий проект будет содержать только 4000 предметов. Менеджеры проектов / деловые люди полагают, что проект должен быть в 1/10 времени завершен, потому что это только часть размера последнего проекта.

Хорошая аналогия, которую я могу использовать, чтобы объяснить, что написание кода для передачи данных из одной системы в другую занимает одинаковое количество, независимо от количества элементов - написание этого для 1 элемента или для 100 000 000 займет примерно столько же времени от программирования точка зрения.

Скажите им, что это все равно что построить новое шоссе с четырьмя переулками в отдаленной части страны. Будет ли эта дорога использоваться 100 автомобилями в день или 1000 автомобилями в день, усилия по созданию дороги будут примерно одинаковыми.

Конечно, если он будет обслуживать 1 000 000 автомобилей в день, вам придется сделать дорогу немного более устойчивой, но, тем не менее, вам придется рубить одни и те же деревья, взрывать одни и те же горы, выравнивать одинаковое количество грязи, и эти мероприятия в значительной степени фиксированной стоимости независимо от того, сколько автомобилей используют дорогу.

Дайте им калькулятор и попросите их добавить 1238783423 к 9858238483, сколько времени это займет. затем попросите их добавить 3423 к 8483 и скажите им, что вы ожидаете ответа примерно в 100000 раз быстрее.

Вы могли бы также объяснить количество данных (возможно) эффекты продолжительности времени , программное обеспечение потребуется для запуска не времени разработки.

Положите это в менеджер говорить.

Если вы создаете машину для создания виджетов со скоростью 1 виджет в секунду, не имеет значения, используете ли вы ее для создания 100 виджетов или 10000 виджетов, для сборки самой машины требуется то же время.

разница во время выполнения, а не во время сборки.

Все классы управления работают над такой проблемой с гипотетическими фабриками виджетов.

Не используйте аналогию. Просто объясни это.

• Для очень небольшого количества предметов (10?) Дешевле всего конвертировать вручную. Не пишите программу вообще.
• Для небольшого количества предметов (100?) Стоит написать программу. Вы можете сэкономить, игнорируя некоторые перестановки данных, которые теоретически возможны, но на практике не отображаются в небольшом наборе данных. Или появляются в таких небольших количествах, что программа может отклонить их, и они могут быть преобразованы вручную. Можно провести быстрый анализ данных, чтобы проверить, действительно ли в данных появляются угловые случаи. Если они не появляются, их можно игнорировать.
• После того, как вы пройдете этот этап, фактический размер данных не окажет влияния. Вам нужно написать серьезную программу, которая может обработать любой возможный ввод. Программа может обрабатывать 1000 предметов или 100 000. Это займет больше времени, чтобы бежать.

Образование лучше, чем говорить внизу :)

Не совсем аналогия, но я все еще считаю, что хороший способ справиться с этим аргументом: продемонстрировать, что в нем есть роковая ошибка.

Ваш предыдущий проект включал (из того, что я получаю) копирование данных с некоторыми изменениями.

Если я правильно понял, команда, скажем, из 100 бухгалтеров может сделать это за несколько месяцев. Тогда почему они бросили разработчиков программного обеспечения в проблему?

Потому что созданное вами программное обеспечение не заботится о том, будет ли оно обрабатывать 10 или 10 миллионов фрагментов данных (не совсем так, но я сомневаюсь, что ваши менеджеры заботятся о O(n)сложности). Таким образом, он был, вероятно, дешевле, быстрее и чище (менее подвержен ошибкам).

Если вы более радикальны, вы можете даже предположить, что, если им не нравится, как быстро работает команда разработчиков программного обеспечения, они всегда могут вызвать бухгалтеров для выполнения работы вручную.

Это сделало жизнь ваших менеджеров намного проще, когда вы разрабатывали последний проект, и теперь, когда им приходится применять ту же логику, чтобы выяснить, следующее программное обеспечение не заботится о том, будет ли оно работать на 10 миллионов или 4. 000 строк, они вдруг забывают об этом.

Я думаю, что в вашем случае менеджеры просто играют в оценочную игру и пытаются заставить команду работать быстрее, указывая на разницу между 4000 и 250000 и надеясь на некоторую «вину». Я могу ошибаться, но я видел, как это было сделано раньше.

Это ужасный способ управлять командой программистов (фактически любой тип творческой команды), и это никому не помогает.

Я знаю, что вы просили провести аналогию, но я думаю, что это неправильный метод.

Я полагаю, как уже упоминали другие, что вам нужно подчеркнуть, что размер данных влияет на время выполнения , а не время сборки .
Итак, разберитесь с ними - у вас есть два подпроекта: строительный и работающий. Проект здания должен (по большей части) не иметь отношения к тому, сколько данных он будет выполнять, он имеет значение только для типов данных.
Что касается времени выполнения - конечно, они могут учитывать это в соответствии с размером данных (исключая любые нетривиальные фиксированные накладные расходы).

Это как если вам нужно ехать в Мельбурн - но сначала вы должны построить машину.
Конечно, поездка в Сидней может быть быстрее, но на создание машины уходит столько же времени.
_{Хорошо, я дал вам аналогию в конце концов.}

Может телефон? Ваш клиент хочет заказной телефон. Если он делает 0 звонков в день или 100 звонков в день, то для создания своего телефона потребуется столько же времени.

Данные, которые передает телефон, аналогичны данным, скопированным вашей программой.

Ваши менеджеры, похоже, путают время разработки с фактическим временем выполнения программы. Но их недоразумение может быть другим. Они могут предположить, что задействовано меньше «полей». Не просто меньше записей данных. Если имеется 100000 отдельных полей данных, это будет огромным усилием разработчика по сравнению только с 10 полями. Больше картографическая работа от системы к системе. В этом случае они могут на самом деле быть правильными, но при этом все еще присутствуют некоторые постоянные издержки, и вы не можете просто разделить на количество полей, чтобы получить время.

Как я хотел бы описать это данные имеют 2 измерения длины и ширины. Длина - это количество записей, ширина - это общее количество столбцов во всех таблицах.

Теперь, когда вы хотите импортировать данные, это похоже на прохождение блока через дыру. Вам нужно сделать отверстие достаточно большим для наименьшего размера, а затем провести блок через

теперь с 10 миллионами и 10 тысячами наименьшее измерение по-прежнему является шириной. Так что именно ширина решает, сколько времени потребуется, чтобы сделать отверстие.

Чтобы завершить метафору, если это меньшая длина, вы просто наберете данные вручную

Я импортирую сотни клиентских файлов каждую неделю.

Одна вещь, которую я обнаружил, состоит в том, что небольшие файлы обычно занимают больше времени для разработки импорта данных, потому что:

• Они с меньшей вероятностью будут следовать правилам (у нас есть стандартные файловые структуры, я никогда не видел, чтобы маленький клиент предоставлял нам данные в стандартном формате, который мы запрашиваем, но крупные понимают, почему это важно)
• У них, как правило, больше проблем с целостностью данных, особенно если они поступают из файла Excel, а не из базы данных (откуда обычно берутся большие файлы), в которой уже встроены правила целостности данных.
• Они с меньшей вероятностью будут предоставляться в одном и том же формате каждый раз.

Мы обнаружили, что мы экономим много времени на разработке, создавая родительский дочерний пакет служб SSIS со стандартным дочерним процессом, и любые необходимые манипуляции для получения данных в форме стандарта можно выполнить в родительском процессе. Таким образом, становится меньше вопрос о количестве записей, когда мы делаем оценку, а вопрос о том, насколько близок к стандартному файлу, который мы получаем. Теперь мы не получаем столько жалоб, когда мелкие вещи занимают больше времени, потому что они не соответствуют стандарту.

Написание программы похоже на наем нового сотрудника. Вы должны научить их, где найти данные, что с ними делать и как дать вам результаты. Вы должны присматривать за ними некоторое время, чтобы убедиться, что они делают это правильно. Их обучение может занять немного больше времени, если у них сложная / важная работа или они собираются выполнять очень большой объем работы, но это занимает значительное количество времени, несмотря ни на что.

Многие менеджеры знакомы с накладными расходами, связанными с обучением нового сотрудника, поэтому для них это может иметь смысл.

(Аналогия нарушается, поскольку ваш новый сотрудник - робот, обладающий сверхспособностью, который может выполнить работу за тривиальное время, независимо от того, сколько записей вы на них бросите, но, надеюсь, вы к тому времени уже сделали свою точку зрения.)