Разбивать крупные задачи на мелкие, при этом не теряя видения — это целое искусство, речь о котором пойдёт в следующих главах. Большие задачи могут наводить просто животный ужас на людей, которые не просто откладывают их выполнение на все максимально далёкий срок, а даже не приступают к попыткам разделить слона на части.
Одна из таких историй произошла со мной и моей командой в 2014 году.
У нашего заказчика была старая система, которую внедрили более 10 лет назад, и за это время она успела крепко пустить корни в организации. Система не только была по самые уши обвязана интеграциями и кастомным кодом, который в некоторых местах оставил едва различимый хребет коробки, но также скопила в себе большое количество данных.
Далеко не все эти данные были ценны, потому целесообразность их миграции была крайне сомнительна, однако, для упрощения процесса, данные готовились к переезду без особого анализа. GiGo (Garbage In Garbage Out) был легализован руководством проекта во имя получения должной скорости реализации. Несмотря на это, один из типов данных оказался настолько огромным, что колоссальная стоимость его миграции все-таки заставила руководство заняться решением этой проблемы.
Это были данные типа «Notes» - текстовые заметки, привязанные к карточке клиента, в которых (по задумке поставщика системы) можно было хранить особую информацию о клиенте, которой не нашлось места в типовой модели данных. Записей было около 80 миллионов, и никто не горел желанием тащить их в новую IT-систему.
Заказчик долго откладывал выполнение этой задачи и, когда костёр дедлайна уже был отчётливо виден на горизонте, эту задачу просто спихнули на нас, под предлогом того, что это не миграция данных, а настройка будущей системы, и моя команда как раз отвечает за эту часть! Объёмы и сроки выполнения нас пугали не меньше, чем заказчика, но, несмотря на это, решать задачу всё равно было нужно, и мы решили съесть этого слона по частям.
Для того, чтобы понять, что хранится в этих заметках, мы попросили выгрузить нам случайные 100 тысяч записей. Проведя анализ этих записей, мы увидели несколько трендовых, часто встречающихся данных:
1. Паспортные данные клиентов
2. Информация о договоре клиента
3. Наименование дилера, продавшего контракт
4. Контактные данные персонального менеджера клиента
5. Служебные заметки (например, о возможности блокировки клиента по неоплате)
Описав данные тренды, мы попросили заказчика провести аналитику базы, по ключевым словам, чтобы понять, насколько часто подобные типы записей встречаются в БД.
Оказалось, что таких типов записей - миллионы. Мы объявили результаты своих исследований заказчику и предложили не перетаскивать эти данные, поскольку информация о клиентах была представлена в структурированном виде и это были просто копии, а сведения о заказах, менеджерах и дилерах имели риск устареть.
А дальше произошло то, что обычно происходит со всеми людьми, когда они решают провести генеральную уборку и выкинуть лишний хлам. Мне это нужно, подожди выбрасывать вдруг соседям пригодится, 10 лет лежало и не мешало, пусть ещё 10 лет полежит и так далее.
Как и в случае с генеральной уборкой, у нас начался торг.Сначала мы решили избавиться от совсем уж старья.
Ограничив срок создания записей временными рамками, мы смогли отсеять большой кусок базы, который был старше 5 лет, а затем повторяли эту процедуру ещё несколько раз: брали сотни тысяч записей, проводили анализ, готовили тренды и принимали совместные с заказчиком решения о судьбе этих записей, постепенно добавляя сутевые фильтры.
Выполняя эту работу, параллельно мы, все-таки, сужали критерии актуальности записей, которые не были приняты в первую итерацию. В итоге мы остановились на 15 миллионов записей к миграции. Дальнейшее исследование трендов приносило (в лучшем случае) десятки тысяч записей: анализ становился все более точечным и требовал больших аналитических затрат. Принцип Парето в действии – 20 % данных, начали требовать 80 % усилий.
Цифра в 15 миллионов уже устраивала всех, а тратить ресурс на дальнейший анализ было признано нецелесообразным, потому, остановившись на этом, мы сдали задачу и переключись на другие: в этом день мы стали героями и нас публично похвалил руководитель проекта.
Секрет нашего успеха зиждился на принципе, описанном в названии этой главы – «ешьте слона по частям». Большие задачи пугают своей массивностью и потому люди склонны не делать их, ожидая, что либо задача отвалится, либо найдётся тот, на кого её можно переложить.
Потому каждый раз сталкиваясь с огромной задачей, старайтесь найти небольшую ниточку, за которую можно потянуть, а потом ещё за одну, пока не распутаете весь клубок. Не бойтесь ошибиться: иногда ниточка оказывается канатом, тогда нужно оставить его в покое и искать другую зацепку.
Главное в этом деле - не поддаваться отчаянию, не убеждать себя, что задача должна быть выполнена за один раз, а иначе никак. Я ещё не видел больших задач, которые никаким образом нельзя было бы разделить на части. Да, бывают такое, что не каждая составная часть решения приносит понятный и ценный результат, но это история про видение далёкой цели, а никак не про декомпозицию.