Критерии эффективности - забавная старая банка червей. Скажем: нам нужен импортер данных, который может импортировать данные о покупках быстро и без сбоев.

Как быстро? Ну, думаю, больше 5–10 минут наши пользователи ждать не захотят, наверное; им необходимо провести сверку покупок после их импорта, и они делают это каждый день. И, конечно же, поскольку у нас есть более 200 клиентов, использующих наш продукт SaaS, каждое утро в одно и то же время будет выполняться множество операций импорта, что замедлит их. И, конечно же, через пару лет мы надеемся иметь более 1000 клиентов…

Давайте добавим еще одно измерение. Насколько велик импорт закупок? Что ж, самые большие файлы наших клиентов обычно содержат до 5000 строк. Но, конечно, мы надеемся завоевать более крупных клиентов. Если на то пошло, наши существующие клиенты надеются стать больше!

Так что, возможно, команда разработчиков программного обеспечения создаст средство импорта, которое сможет обрабатывать 5–10 операций импорта одновременно и обрабатывать до 8000 строк примерно за 5 минут, если это так. Фу. Хорошая работа!

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

Проблема в том, что команда разработчиков программного обеспечения глубоко погружена в другие крупные и важные проекты. Которые либо сойдут с рельсов, либо эта проблема только усугубится. Один умный инженер предложил решение для менеджеров по работе с клиентами: «попросите клиентов нарезать свои файлы поменьше, так как импортеру намного проще обрабатывать большое количество файлов по 5000 строк; мы просто бросаем в него больше металла. Процесс тормозят действительно большие файлы».

Менеджеры по работе с клиентами уходят с ворчанием. Они не понимают, почему импортер такой хлам, и знают, что клиенты тоже будут ворчать: «ладно, сделаем, но временно и нам ПИТА! Назовите нам точную дату, когда это будет исправлено».

У умного инженера была правильная идея, но с опозданием на год. Они должны были встроить это ограничение производительности прямо в код. Вот так: если импортер обнаруживает файл импорта с › 5000 строками, он тут же останавливается и сообщает пользователю: «Извините, я могу импортировать файлы только до 5000 строк».

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

Перенеситесь на год вперед, и разговор станет другим и очень спокойным. Теперь у нас больше клиентов с большими файлами. Они спрашивают, зачем им резать импорт, нельзя ли упростить? Конечно, можем: мы можем пересмотреть средство импорта и переделать его, чтобы оно лучше справлялось с большими файлами. Где бы вы хотели, чтобы улучшение продукта было приоритетным?

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

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