У нас было пять руководителей проекта, семь лет разработки, несколько почти законченных решений, меняющиеся цели, задачи и разнообразные системы всех цветов и размеров. Не то, чтобы это было нужно для успешной реализации, но раз уж начал пилить долгострой, то иди в своём увлечении до конца. Единственное, что меня пугало — это разработка серебряной пули, которая якобы исправит все проблемы. В ИТ нет ничего более иллюзорного, чем попытка разработать универсальную систему для решения всех проблем. И я знал, что мы скоро в это окунёмся.
Первый этап: актуализация ставок НДС на объектах и обновление версии ПО на кассах
В далеком 2018-м, когда проект ещё только открывался, целью было автоматизировать доставку до магазинов актуальных ставок НДС и перейти на актуальную версию касс. Специфика крупной торговой сети заключается в том, что каждый магазин — это, по сути, отдельный экземпляр системы. При этом магазины могут быть в любом городе нашей Необъятной, и далеко не везде есть интернет (или есть, если залезть на ближайшую берёзку и подкинуть мобильник повыше), к тому же за сеанс связи нужно передать в центр информацию о продажах за день. При таких раскладах на актуализацию ставок НДС никто и не рассчитывал — их обновляли эпизодически, что приводило к значительному количеству неправильно пробитых чеков, которые потом исправляли централизованно.
Первый этап проекта, в целом, прошел успешно: теперь данные по ставкам обновлялись каждый день и количество ошибочных чеков существенно снизилось.
Что не получилось?
Закрыть проект.
Что получилось?
На несколько порядков снизить количество проблемных чеков.
Обновить версии ПО касс во всех магазинах «Магнита».
Второй этап: система автоматического формирования чеков коррекции на SAP ERP
В 2020 году в проект добавили новый смысл и новую цель: теперь нужно было бить чеки коррекции, чтобы исправлять отдельным чеком все возможные допущенные ошибки. Но! Прежде всего нужно ошибку обнаружить и понять, стоит ли вообще её исправлять. Так от первоначальной цели — актуализировать ставки НДС на местах и обновить версии ПО касс — мы пришли к созданию полноценного аналитическо-сверочного инструмента. Этот сложный механизм должен был собирать данные из разных источников, находить ошибки и готовить чеки коррекции, в идеале — без вмешательства человека. В качестве решения выбрали SAP ERP. Казалось бы, что могло пойти не так?
Что не получилось?
Успеть до 2022 года.
Передать в пилотирование и внедрение.
Что получилось?
Сделать полноценное решение.
В декабре 2022 года решили самостоятельно написать с нуля новую систему. О проблемах на этом пути и будет дальнейший рассказ.
Трудности бытия
У самурая нет цели, есть только путь
Ситуация
В течение полутора-двух лет формировались бизнес-требования к проекту, их совокупный объём составил около 400 страниц А4. Казалось бы, что могло пойти не так?
Документация стремительно устаревала. Когда завершили бизнес-анализ, первичная потребность от бизнеса уже изменилась практически полностью.
Изменилась целевая система проекта: после событий, серьёзно повлиявших на отрасль, взяли курс на импортозамещение, а предыдущие решения (и почти готовая реализация) пошли под нож.
Несмотря на то, что целевая система изменилась, документация осталась прежней, в том числе со спецификой планируемой изначально системы.
Большой объём документации привёл к тому, что ею стало неудобно пользоваться — ни авторам, ни разработчикам: чем больше документ, тем сложнее его применять, а любое изменение превращалось в мучительный квест.
К чему всё это привело:
В процессе найма членов команды на проектные ставки возникало всё больше и больше расхождений между бизнес-требованиями и реальной жизнью.
Каждая сторона периодически уходила в режим отрицания, переводя обсуждение на уровень руководства и откатывая и без того скромный прогресс по реализации проекта.
Что не получилось?
Подогнать реальность под картинку двухлетней давности.
Быстро доказать себе и окружающим, что решение, разработанное по бизнес-требованиям, не будет работать в реальной жизни.
Что получилось?
Провели глубинный анализ проблематики проекта, как со стороны ИТ, так и со стороны бизнес-функции.
Нашли уязвимые места в бизнес-требованиях, которые привели бы к неработоспособности конечного продукта.
Предложили свою реализацию продукта, учитывающую выявленные проблемы и особенности существующих систем и бизнес-требований.
Презентовали и согласовали концепцию с заказчиками, заинтересованными лицами и смежными командами.
???
PROFIT! Решение соответствует ожиданиям заказчиков и заинтересованных сторон.
Что надо было сделать?
Перед набором команды проверить бизнес-требования, убрать накопившиеся с предыдущих версий отклонения.
Полноценно спланировать проект с заказчиками, проектной командой и заинтересованными сторонами.
Совместно проработать риски и их влияние на проект.
При необходимости повторно выйти на архитектурный и инвестиционный комитет, прозрачно показав всем заинтересованным лицам изменения в проекте.
Вывод
В итоге проект снова получил смысл, а команда — согласованный план.
Не существует идеального документа. Есть только постоянная работа над синхронизацией ожиданий и возможностей. И к этому нужно быть готовым.
Думать наперёд: зачем ты это будешь делать? А не противоречит ли новое всей логике проекта?
Главный урок: если что-то совсем не работает, то следует набраться смелости и начать заново, а не пытаться оживить концепцию с изначально неудачным ядром. Потом будет больнее и дороже.
Хороша ложка к обеду
Ситуация
Наступает новый день, просыпается мафия. Открывается новый проект и все ставки идут в подбор по заранее рассчитанному плану. Первым нанимают тимлида. Казалось бы, что могло пойти не так?
Первоначальный план защищён в декабре 2022 года: первую ставку (тимлида) закрыли 3 апреля — с инвесткомитета прошло 4 месяца.
Первый месяц-полтора тимлид вникал в процессы и погружался в специфику проекта. Остальные ставки уже были открыты и по ним параллельно вели собеседования — первые позиции закрыли без участия тимлида.
Начальный подбор осуществляли разные специалисты со своими взглядами и представлениями о проекте, без синхронизации с основным треком.
На инвесткомитете было согласовано on-prem размещение инфраструктуры, после чего почти сразу согласовали подход CloudFirst, который не был учтён в проекте. В итоге наняли DevOps под on-prem без навыков облачного развёртывания.
На проект уже наняли сотрудников поддержки, при этом из документации на тот момент были только бизнес-требования.
К чему всё это привело:
Первые полгода, пока шёл активный найм, проблема была ещё незаметна. Но когда основные позиции закрыли, начался отток людей.
Уходит DevOps: «У вас тут должно быть облако, я с облаками не работал и не планирую, пойду в другую компанию».
Уходит поддержка: «Я хочу работать (!!!), у вас тут нечего сопровождать» (справедливо).
Уходят аналитики и разработчики: «Мы представляли себе проект иначе, на собеседованиях нам рассказывали одно, по факту получилось другое».
Как итог: седой тимлид собирает по одному-два заявления на увольнение в месяц, каждый раз проходя пять стадий Кюблер-Росс.
Что не получилось?
Сохранить нервы и боевой дух команды. Когда каждый месяц уходит коллега, это больно и бьёт по всем.
Соблюсти сроки. Каждый сотрудник — это не только друг и коллега, но ещё и 3-4 месяца на подбор и несколько месяцев на адаптацию.
Что получилось?
Провести ретроспективу и проделать работу над ошибками. Так, нового DevOps наняли с уклоном в облачные технологии, а тестировщиков — только после того, как появилось что тестировать и автоматизировать.
Что надо было сделать?
Составить календарно-ресурсный план.
Распланировать подключение специалистов согласно плану.
Предоставить тимлиду время на адаптацию.
Учитывать изменения в процессах компании.
Вывод
Спешка хороша только при ловле блох. Потратив больше времени на планирование, распределение и загрузку ресурсов, мы могли бы сэкономить больше ресурсов в долгосрочной перспективе.
Старый друг лучше новых двух
Ситуация
Требования есть, план проекта есть, архитектурный комитет пройден, интеграционные системы утверждены, люди наняты. Казалось бы, что могло пойти не так?
Целевая система интеграции за это время успела перейти в статус «Выводится из эксплуатации». Интеграция невозможна, требуется срочно найти новую систему.
Рядом со старой системой планируется новая. Конечно же, она решит все проблемы разом (нет)... но надо подождать ещё три года.
Предлагается новое целевое решение, которое устранит все проблемы... но «решение на той же стадии, что и ваше, посмотрите план следующего архитектурного комитета — как раз его обсуждать и будем».
К чему всё это привело:
Сроки, сроки, срок на сроки, срочный срок на срочные сроки. Жёсткая зависимость от других систем: если не работает одна, то не работает и другая. В итоге, долгие согласования с привлечением руководства, неработающие компоненты. Квинтэссенция всего этого (как будто остального было мало) — длительная недоступность интеграционной системы, которая не выдержала неожиданного потока запросов.
Что не получилось?
Обеспечить должный уровень надёжности и отказоустойчивости системы.
Быстро и качественно разбирать инциденты на стыке систем: чем больше звеньев, тем сложнее договориться по самым элементарным вещам.
Что получилось?
Проработать с каждой из систем контракты, НФТ. В будущем, ближе к запуску всех систем, будут проработаны SLA.
Разработать на своей стороне комплекс решений, которые снизили риски от сильной связанности и зависимости.
Снизить первичный объём погрешностей с 80 % (преимущественно технические проблемы интеграций) до 1 % (в основном бизнес-сценарии, которые и должна выявлять система).
Что надо было сделать?
Запустить прототип решения на максимально устойчивых и стабильных системах.
Поэтапно и аккуратно внедрять новые системы, чтобы не утонуть в проблемах и рисках.
Определять функциональные и нефункциональные требования сразу, а не после разбора инцидентов.
Вывод
Новое — не значит лучше старого. Большое количество новых систем ведет к нарастающей энтропии, причины которой впоследствии крайне сложно объяснить заказчику.
Кто не падал, тот не поднимался
Ситуация
Выходит новая версия Java, на профильных сайтах появляется статья про новую технологию. Казалось бы, что могло пойти не так?
Новая технология не подходит к текущему проекту, но чтобы это понять, требуется детально в неё погрузиться и попробовать внедрить.
Время, потраченное на неудачную технологию, толкает продолжать эксперимент дальше. Кажется, что ещё чуть-чуть, буквально завтра всё заработает, и не хочется бросать дело на полпути.
В команде нет нужных компетенций, чтобы оценить риски заранее.
В выбранной технологии есть корневой баг, висящий в трекере у разработчика ещё с лохматых годов, и править его, конечно же, никто не собирается.
К чему всё это привело:
Неудачный выбор ключевой для функционирования системы технологии растянул время на внесение изменений и проверку гипотез с разумных 4-5 часов до 5 дней.
Проблемы с вводом новых сотрудников: приходилось долго и мучительно объяснять мифологию проекта.
Что не получилось?
Выстроить сразу прозрачный процесс RnD.
Вовлечь в обсуждения всю команду: зачастую решения принимали на уровне энтузиастов в обход основной части команды.
Что получилось?
Идти в ногу со временем и своевременно переходить на новые версии компонентов.
Не накапливать техдолг и legacy.
Наладить, в конечном итоге, процесс исследования и обкатки новых подходов.
Полученный опыт оказался не напрасным: нашли, где применить технологию иначе.
Что надо было сделать?
Вовлекать в процесс всю команду.
Закладывать время на исследование при планировании.
Вывод
Нужно соблюдать баланс между новым и старым.
Эксперимент может окончиться неудачей, это тоже результат, который надо учесть и не пытаться продолжать его дальше, раз за разом, в надежде на то, что завтра результат будет другой.
Все врут (с) Доктор Хаус
Ситуация
Обычная встреча по уже неоднократно оговоренной функциональности, и тут: «А вот мы ещё вспомнили, что...» или «А в системе Х есть уже похожая функция (но это неточно), поэтому интегрируйтесь с ней». Казалось бы, что могло пойти не так?
Добавляются новые заказчики, интересы которых необходимо учесть в требованиях.
В проекте начинают появляться новые смыслы, цели и системы, изначально не заложенные во время инвесткомитета и планирования архитектуры.
В бизнес-требованиях уже заложены конкретные технические решения, не проверенные на реализуемость представителями ИТ и не соответствующие уже действующим системам.
Требования транслируются сразу нескольким командам, что приводит к ситуации, когда в смежной команде уже реализовано неверное техническое решение, а вы ещё даже не проверили возможность его реализации.
К чему всё это привело:
Требования заказчиков начали противоречить друг другу, что создавало всё больше и больше развилок в реализации. Непроработанные технические решения вызывают коллизии, когда смежные команды уже сделали так, как было заказано, но не так, как будет работать в реальной жизни.
Что не получилось?
Своевременно заметить проблемные требования.
Не тратить ресурсы на проработку заведомо неправильных технических решений.
Что получилось?
Исключить технические решения из бизнес-требований, переведя их на уровень спецификаций и концепта.
Состыковать между собой разноплановые требования заказчиков.
Распределить по фазам реализацию проекта, управляя ожиданиями заказчиков.
Что надо было сделать?
Зафиксировать конечный результат проекта до начала его реализации.
Новые вводные должны приводить к изменению проекта, а если изменения радикальные, то надо было закрывать текущую фазу и начинать новую — с новыми целями и ожидаемым результатом.
Вывод
Если в проект постоянно добавлять новую функциональность, он рискует никогда не завершиться.
В условиях, когда команда знает конечный срок и параллельно слышит призывы «нужно ускориться», это неминуемо приводит к выгоранию коллег и размытию ценности уже проделанной работы.
Шестой подвиг Геракла
Ситуация
Сверочная система выявляет проблему — отлично, ведь это значит, что её можно исправить. Казалось бы, что могло пойти не так?
Выявленная проблема не относится к процессу сверки, она возникает где-то там, в самом начале цепочки передачи данных, и исправить её на этапе сверки уже невозможно.
Контроль за полнотой доставки данных возлагается на приёмник, который не в курсе, какое количество данных ожидать в принципе.
Промежуточные системы занимают позиции «передаста»: мы передали то, что было, дальше разбирайтесь сами.
Никто ранее не согласовывал допустимую долю ошибок: невозможно понять, является ли это вариантом нормы или нужно срочно бежать и исправлять.
Проблема может вовсе не относиться к ИТ, это может быть бизнес или административная ошибка на местах.
К чему всё это привело:
Много разноплановых ошибок вне контура системы.
Возникновение функции ручного разбора подобных проблем, что не нравится заказчику.
Что не получилось?
Функция ручного разбора не прошла стадию принятия у заказчика.
Определить зоны ответственности систем по функциям.
Что получилось?
Снизить уровень технических ошибок миграции.
Взять на себя часть функций по качеству и проверке данных. Возможно, неправильно с точки зрения архитектуры, но правильно для получения результата.
Предложить и реализовать функцию ручного разбора.
Что надо было сделать?
Согласовать матрицу ответственности за функциональность и потоки передачи данных.
Зафиксировать допустимые виды и пороги ошибок.
Транслировать, что полная автоматизация всей ручной работы без понимания объёма этой работы невозможна.
Вывод
Автоматизировать можно всё, но не всё из этого нужно или целесообразно автоматизировать. Чем больше доля автоматизации, тем выше стоимость конечного решения.
Happy End
Мы здесь. За два с половиной года с момента прихода новой команды мы смогли окончательно продумать и разработать решение, которое на текущих данных смогло выявить проблемы и формировать коррекции. Конечно, впереди ещё много работы: даже на идеальных данных находятся ошибки внутри сервисов, а данные редко бывают в идеальном виде. Но тёмный период нашей истории закончен, а значит, впереди только светлое будущее.
Что получилось?
Проработать и согласовать концепт решения.
Сформировать устойчивый костяк команды.
Предложить и разработать решение по ручному формированию чеков коррекции.
Запустить прототип автоматического формирования чеков по основным форматам.
Разработать интерфейс согласования и ручного разбора спорных корректировок.
Что ещё впереди?
Запустить остальные форматы: аптеки, интернет-магазин.
Масштабировать решение на всю географию «Магнита».
Продолжать улучшать принципы работы алгоритма сверки.