По мере роста запросов к ИТ в компании появляется куча интеграций, куча временных решений и куча костылей, потому что нужно чем-то срочно закрыть операционку, решить задачу и потом, наверное, когда можно будет выдохнуть, отрефакторить. Правда, вместо рефакторинга предлагается новая срочная задача со сгорающим дедлайном. Всё это нужно поперчить тем, что люди в команде примерно раз в два года меняются, а сейчас и того чаще, на ведение базы знаний не хватает времени, и уже нужен археолог, чтобы ориентироваться в старых костылях. В итоге образуется система, которой сложно обучить людей, на которую сложно вообще нанимать людей: непонятно, как это будет развиваться. ИТ-отдел в третий раз приходит на Совет директоров и говорит, что нужно во-о-оо-от столько денег и времени, чтобы всё решить. А бизнес говорит: 

— Вы там охренели? Давайте фичу! И ещё у нас интеграции к следующему месяцу нужны.

ИТ-отдел соответственно вежливо возражает:

— Нет, это вы там охренели. У нас беклог по поддержке ваших палок на год вперёд, потом — рефакторинг на полгода, только потом будем что-то делать.

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

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

Что обычно происходит, когда нас зовут

Вернёмся на стадию обсуждения конструктива на Совете директоров. Предположим, что ИТ-отдел пришёл не просто со словами про палки и охреневание, а с конкретным предложением по выходу из кризиса. Обычно оно всегда есть на случай большого падения, чтобы достать его из штанов, показать всем и произнести: «Я вас год назад предупреждал!» Правда, на практике эта часть обычно входит в ритуал увольнения CTO. 

Но предположим, что бизнес понимающий, предложение принесли задолго до падения. Обычно его нужно детализировать до конкретики. Здесь тоже возможны варианты: если оценивать перспективы больше месяца, то бизнесу это всё надоедает, и дальше предложение делает уже новый ИТ-отдел. А если сделать всё вовремя, то появляется черновик стратегического плана изменений.

Как правило, к этому моменту ИТ-отдел уже прочно заработал репутацию ненадёжных внутренних партнёров, потому что его разрывает от нагрузки и внутренних проблем. Соответственно бизнес уже не верит никаким обещаниям CTO и его команды и ищет, у кого бы их перепроверить. Часто обращаются за консультацией наружу, на рынок, к тем, кто уже такие преобразования успешно делал. Обычно это или космически дорогие команды бизнес-консультантов, или кто-нибудь из интеграционного бизнеса. Часто мы либо на подряде у кого-то из крупных консалтеров, либо сами, если заказчик "просёк" цепочку формирования цены.

Самое интересное, что команда со стороны никогда не будет обладать той полнотой данных, которая уже есть в ИТ-отделе компании. И не факт, что они смогут придумать что-то лучше, чем смогли бы эти же самые люди. Дальше опять же есть четыре варианта действий:

1. После того как деньги заплачены, ящик водки пропит, а предложение по трансформации принято, его просто не исполняют, потому что дорого и долго. Задачи начинают перекладываться на аутсорсеров, что откладывает кризис ещё на один-два года. Это хороший в целом-то план, особенно если учитывать, что руководители через один-два года тоже могут быть уже другие, а квартальные бонусы сами себя не заработают.

2. ИТ-отдел немного разгоняется, немного нанимается, и дальше становится понятно, что без потерянной аналитики и без потерянных знаний разработчиков пациента уже можно не лечить. И все идут в историю «старое за 20 лет хороним, новое пишем с нуля». Тоже вполне реальный рефакторинг, только дороже, чем многим хотелось бы.

3. ИТ-отдел реально оказывается овощной, и пинки внешних людей помогают его трансформировать. Как правило, это если у проблемы есть имя, фамилия и подстрока «директор» в названии должности. Такие случаи я встречаю очень редко, потому что обычно проблема — на уровне климата в компании и понимания, зачем ИТ-отдел вообще нужен, а не в конкретном кризисе руководства.

4. Ну и внешняя команда укрепляет имеющуюся, и дальше они вместе работают над проектом исправления всего горящего, после чего продумывают плавный план улучшения ситуации на пару лет вперёд.

Что мы обычно застаём в своих проектах

По большей части мы работаем с розницей, которая отлично и быстро развивалась, жертвовала процессом разработки ради её скорости первое время. Обычно это легаси 2000–2010 годов (бывает и из 90-х), его до сих пор поддерживают, вкручивают и проворачивают там фичи, патчат. Тогда популярны были интеграции через БД, файлы, а у особо прокачанных – интеграционные шины, и бизнес часто на стадии перерастания малого и выхода на средний или крупный брал какое-нибудь монструозное коробочное решение, если не запилил ещё своё на БД и хранимках. Сейчас всё это не очень хорошо вписывается в текущие девопс-практики и разные аджайлы, в общем, в CI/CD. Выкатка часто выглядит так: берёшь какую-нибудь веб-сферу, пишешь код, пакуешь ручками, ручками грузишь, метрики отслеживаешь тоже ручками, и продукт получается очень дорогой. Внезапно ещё выясняется, что есть какие-то новые опенсорсные решения, которые могут делать похожие задачи быстрее и проще, и ещё они дешевле в поддержке. А команды мало того, что привязаны к какой-то старой мрачной технологии, так ещё и платят хорошие деньги за устаревшее решение.

В рознице это воспроизводится примерно похожим образом с завидным постоянством. Почему именно в рознице — потому что у нас традиционно только банки, страховые, сотовые операторы и розница имели развитые ИТ. Потом подтянулись и производства, и много кто ещё, но в своё время розница была на пике технологий, с одной стороны, и самой раздолбайской, с другой, потому что у остальных игроков рынка были какие-то ограничения, заставлявшие делать качественнее или хотя бы надёжнее. Хотя в банках я видел и 30-летний легаси, но там это вопрос двойной-тройной надёжности.

Мировой тренд — такие бизнесы понимают, что нужно как-то модернизировать старое.

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

Пример такого проекта

Есть такая сеть — «Винлаб», крупнейшая в России. У них этот процесс образцово-показательный, потому что случился примерно за пару лет до описанных в начале гипотетических событий с «я вам говорил» и ритуалом увольнения CTO. Просто вовремя пришли, вовремя обозначили риски, вовремя посчитали всё в деньгах и вовремя же решили модернизировать всё, чтобы не оказаться в лесу легаси-костылей.

У них в основе стека — SAP с невероятным количеством собственной разработки вокруг. Не всегда, скажем так, по мировым лучшим практикам и промышленным стандартам. Отчасти это особенность любой розницы, отчасти — России, где время от времени случаются сюрпризы от регуляторов, которые могут сказать что-то вроде: «А сделайте онлайн-кассы быстренько там». Разрабатывать на SAP дорого, ресурс для этого найти дорого. Дорого поддерживать. Нужно было расширить стек до чего-то, что лучше подходит под DevOps практики и где рынок разработчиков больше. Часто разработка велась на аутсорсе, и далеко не всем стеком и всеми решениями владел заказчик. Проанализировав возможности и запрос, пришли к выводу, что необходим стек, обеспечивающий оптимальное быстродействие, в итоге основным стеком выбрали Java.

Нас позвали как консультантов помогать во всём этом. Тут важно, что позвал сам ИТ-отдел, а не в противовес ему или не для оценки его действий. Мы сформулировали два подхода: новую архитектуру отдела и новую методологию разработки. Если до этого они всю разработку строили путём найма подрядчиков на фичи, и это было не слишком прозрачно, то теперь подрядчики заходят внутрь DevOps-контура заказчика и в его среду разработки, в его Jira и в его стейджинг (нечего им на проде делать). Время списывается внутри инфраструктуры заказчика, после каждого шага остаётся предсказуемый артефакт, всё видно и понятно.

До этого заказчик не понимал, за что платит, и хотел у себя команду в штате: элементарно, чтобы снимать метрики проще и контролировать проще. И желательно денег меньше. Собственно, мы показали, как можно уравнять эту новую потенциальную команду с внешними, чтобы они работали в одном контуре.

Мы формализовали этот процесс.

Архитектурный подход — перешли на вариант гибридной архитектуры, когда у нас есть один большой кластер для разработки. Он может быть как on premise, так и в облаке.

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

Этапы реализации проекта:

1. Аудит процессов разработки.

2. Создание методологии процесса разработки ПО.

3. Разработка архитектуры Цифровой платформы(ЦП).

4. Внедрение ЦП в инфраструктуру.

5. Разработка архитектуры и макета интеграционного слоя для создаваемых бизнес-приложения и существующих систем.

6. Обучение.

Срок реализации — три месяца.

Как это видел бизнес

Бизнес видел это всё поначалу как досадное недоразумение, а потом — как одну из рабочих задач роста, которую просто надо вовремя решить. То есть они продавали алкоголь, кратно росли каждый год и не собирались останавливаться. Чтобы расти, нужно было лучше и точнее общаться с клиентами. Поскольку алкоголь в оффлайне очень ограничен в возможностях рекламы, то в фокусе всегда были разрешенные цифровые каналы, то есть нужно было очень много маркетинговых интеграций. Законодательство меняется часто, условия на рынке — тоже, и вообще надо часто и активно меняться. Внутренняя команда и внутренняя инфраструктура не предназначены для такого, Т2М очень долгий. Нет команд внутри — некем разрабатывать, технологии старые и очень проприетарные. С их точки зрения идеальным решением была бы цифровая платформа, которая сочетала бы в себе общие API, общий стек выкатки в прод, общие девопс-инструменты и общую методологию с общими же инструментами для её поддержания типа базы знаний.

Первая точка роста, естественно, — из одной команды разработки всего сделать несколько продуктовых команд для отдельных продуктов. Продуктовые команды в околоаджайл-методологии наращивают скорость своей работы, быстро обучают новичков, оставляют базу знаний и делают сервисы по общей архитектуре. И параллельно уходят от привязки к отдельным людям. Конечно, она остаётся, но становится уже не такой критичной, как в прошлых командах. Новый стек даёт возможность ограничить легаси и не тратить кучу времени и денег на сертификацию и обучение каждого сотрудника. Ну и не ужасать новых кандидатов это тоже помогает.

Общий процесс сначала строится из постулата «Как ИТ наименьшей кровью может угодить бизнесу», а потом уже постепенно переходит к «ИТ-отдел — партнёр бизнеса». Для людей делается понятный конвейер, а не творчески неповторимые процедуры, характерные для начала развития. 

Собственно, если всё это правильно делать, то дальше оно взлетает, и компания становится цифровой, идёт выступать на конференциях по маркетингу, рассказывая, как они "дисраптили" и испытывали цифровую трансформацию.

Результаты этого проекта:

1. Заказчик может разрабатывать на 30% быстрее.

2. На ЦП уже разработано одно и проектируется/разрабатывается четыре бизнес-приложения.

3. Четыре команды уже работают по методологии и на базе ЦП, и им это нравится.

4. Позволил заказчику раньше ввести в эксплуатацию и получать бизнес-эффекты по четырём проектам.