Как мы переводили в Сбере систему на новый технологический стек. 
 

Что значит перевести 13 000 пользователей на новый стек. И чтобы никто не заметил.
 

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

Это был второй случай.
 

Сначала немного предыстории
 

До этого проекта я провёл 22 года в МИнБанке. Классическая среда: чёткие процессы, согласования, водопад. Всё понятно, всё предсказуемо, всё по регламенту.
 

И вот я прихожу в Сбер. В настоящий продуктовый Agile. Трайбы, кластеры, скрамы, дейли, ретро, спринты. Другой язык. Другой ритм. Другая логика принятия решений.
 

Первое время было ощущение что ты умеешь плавать — но тебя бросили в другой океан.
 

Спасло две вещи. Первое - наставник. Человек, который не просто объяснял как здесь всё устроено, а помогал думать в новой системе координат. Без него адаптация заняла мучением. Если у вас есть наставник это не слабость, это разумность.
 

Второе - люди вокруг. Но об этом позже. Потому что они заслуживают отдельного разговора.
 

Сам проект
 

Федеральный уровень. Распоряжение президента. Пять кварталов. Корпоративная система, на которой работают тысячи людей каждый день. Задача - полностью сменить технологический стек. Бесшовно. Незаметно. В срок.
 

Условие звучало просто: пользователи не должны почувствовать переход. Даже смежные системы не должны почувствовать переход. Особенно смежные системы.
 

Звучало просто. На деле, если что-то пошло бы не так, головы полетели бы быстро и без предупреждения. Федеральный уровень не прощает.
 

Квартал первый. R&D
 

Первое, что мы сделали - не побежали писать код. Мы потратили целый квартал на исследование.

​

Было две гипотезы: мигрировать существующее ядро или строить новое. Прогнали обе. Выбрали второй путь - строить новое. Смелое решение, потому что означало больше работы в начале. Но именно оно дало чистую архитектуру без груза старых решений.
 

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

Этот квартал сэкономил несколько месяцев в конце. Любой кто говорит, что R&D это потеря времени просто никогда не разгребал последствия решений принятых без него.
 

Кварталы два, три, четыре. Машина заработала
 

Аналитика, разработка, тестирование, нагрузочное тестирование, внедрение - всё параллельными потоками.
 

Разработка шла в ветках, каждый pull request проходил через код-ревью. И вот здесь начиналось самое интересное. Разработчики - люди с характером и убеждениями. Дискуссии при акцепте пул-реквестов были живыми, местами громкими, всегда по делу. Никто не рубил с плеча, но никто и не молчал из вежливости. Это было настоящее инженерное мышление в действии - и смотреть на это было одно удовольствие.
 

CI/CD — непрерывная интеграция и доставка - держал процесс в тонусе. Каждое изменение автоматически проходило через пайплайн: сборка, тесты, деплой на окружение. Это не давало копиться техническому долгу и позволяло ловить проблемы сразу, а не перед релизом.
 

ИФТ — интеграционное функциональное тестирование. Как новая система работает с каждой из смежных. Не в теории - на реальных сценариях. У каждой смежной системы свои форматы, своя команда, свои ожидания.
 

Регресс — полное покрытие всех сценариев которые работали в старой системе. Сотни сценариев. Прогнать, зафиксировать, передать на доработку, прогнать снова. Итерация за итерацией.
 

НТ — нагрузочное тестирование. Система должна выдерживать пиковую нагрузку. Не среднюю - пиковую.
 

ПСИ — приёмо-сдаточные испытания. Формальная проверка с протоколами, актами, подписями.
 

И всё это не последовательно - параллельно.
 

Смежные команды. Это не просто согласование
 

Двадцать с лишним смежных систем. И вот здесь есть важный момент который многие недооценивают.
 

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

Это называется синхронизация релизов. И это отдельное искусство.
 

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

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

Полночь. Звонок в другой часовой пояс
 

Вот момент который я запомнил надолго.
 

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

Я руководитель проекта. Моя роль управление, не технарка. Но в этот момент вспоминаю слова наставника: хоть из под земли достань.
 

Начинаю искать. Выясняется, что нужный человек находится в другом часовом поясе, плюс пять часов. Там уже пять утра. Звоню. Человек берёт трубку в недоумении. Объясняю ситуацию, нахожу общий язык. Он подключается к синку.
 

Вот это и есть команда. Не на бумаге - по-настоящему.
 

Когда наставник уходил в отпуск
 

Было несколько моментов когда наставник уходил в отпуск. Два или три раза за проект.
 

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

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

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

Тринадцать сегментов пользователей
 

Тринадцать клиентских сегментов. Каждый со своими сценариями, своими болями, своими ожиданиями.
 

Пользовательское тестирование это не "дайте людям доступ и посмотрим, что будет". Подготовка сценариев, согласование, тестирование, сбор обратной связи, разбор дефектов, повторное тестирование. По каждому сегменту отдельно. Приёмка без подписи - движения вперёд нет.
 

Параллельный запуск
 

Старая и новая система работали одновременно. Данные синхронизировались. Если что-то пошло бы не так - откат занимал минуты, а не дни.
 

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

День внедрения
 

Знаете, что самое странное в больших технологических переходах?
 

Когда всё прошло хорошо - это выглядит как обычный рабочий день.
 

Никто не позвонил с вопросом, что случилось. Никто не написал, что что-то сломалось. 13 000 пользователей зашли в систему - и система работала.
 

Три дня наблюдения после внедрения. Мониторинг. Дежурство. Готовность реагировать. И тишина - в хорошем смысле этого слова.
 

О людях. Самое главное
 

Я намеренно оставил это напоследок.
 

Сбер - это другой уровень профессионализма. Говорю это не как дежурный комплимент. Говорю как человек который пришёл из другой среды и увидел разницу своими глазами.
 

Каждый человек в команде знал, что он делает. Не приблизительно, а точно. Каждый был на своём месте. Каждый тянул свою часть и доверял, что остальные тянут свою.
 

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

Наша МАМА команды - именно так её все называли и именно так она себя и вела. Человек, который сканировал всё и всех, к которому можно было обратиться в любое время даже если она была занята по горло. Она просто была на месте. Всегда. Она поверила в меня с первого дня - и это дорогого стоит.
 

Наставник - без него первые месяцы в новой системе координат были бы совсем другими. Он научил думать иначе, а не просто объяснил правила. И именно его слова про "хоть из под земли достань" всплыли в нужный момент в 12 ночи.
 

Сказать, что кто-то не помогал — неправда. Помогали все. Включая человека, который в пять утра взял трубку и подключился к синку. Это и есть команда с большой буквы.
 

Скучаю по этой команде. По-настоящему.
 

Вывод
 

В больших проектах технические решения это треть работы. Остальное - люди.

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

Хороший R&D в начале всегда дешевле плохого решения в середине.
 

И последнее - единственное о чём я жалею в этом проекте: что он закончился в срок)