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

Но как это часто бывает в больших проектах, эпичный концепт столкнулся с не менее эпичной реальностью. Легаси‑инфраструктура с которой мы столкнулись и на которой нам предстояло строить этот самый «космолет», в реале оказалась сложнее и неповоротливей, чем мы могли себе представить. Распределённая архитектура, множество стыковочных узлов, кривые сторонние сервисы, языковые и культурные барьеры внутри команд, а главное — жёсткие рамки Waterfall. Всё это требовало не просто инженерной смекалки, а умения балансировать между интересами разных игроков, не теряя фокуса на конечном пользователе.

В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.

Если вы не читали первую часть — рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации — добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.

Приготовьтесь, отправляемся. Следующая станция — «прод».

ВЕБИНАР| 23 сентября в 11:00| РЕГИСТРАЦИЯ

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

На вебинаре 23 сентября в 11:00 эксперт SOFROS Яна Журавлёва покажет, как определить оптимальную последовательность внедрения решений в зависимости от текущего состояния данных, ИТ‑ландшафта и задач бизнеса.

На вебинаре разберем:
1. как понять, когда достаточно нормализации данных, а когда уже необходимо внедрение MDM;
2. в каких случаях начинают с интеграционной платформы DATAREON Platform;
3. почему параллельный запуск всех трех компонентов — самый рискованный, но при наличии плана и экспертизы — самый быстрый сценарий;

Вебинар будет полезен: руководителям и специалистам по НСИ, бизнес‑аналитикам и архитекторам данных, руководителям цифровой трансформации, ИТ‑специалистам, участвующим в проектах управления данными

Регистрируйтесь и забронируйте место заранее по ссылке
Количество мест ограничено.

Я довольно активно использую ИИ в разработке примерно с конца 2024 года.

Наверное, многие слышали оценки в духе: «ИИ ускоряет разработчика на 20–30%». Возможно, для каких‑то привычных задач это и неплохая метрика.

Но недавно у меня случился кейс, который вообще плохо укладывается в эту систему координат.

За один очень плотный рабочий день — примерно 11 часов от идеи до боевого переключения — удалось исследовать закрытый Windows‑компонент, восстановить недокументированный бинарный протокол, разобраться с особенностями криптографии, написать совместимую реализацию на Java, сформировать регрессионный корпус из реального трафика, завернуть всё в контейнер, развернуть в Kubernetes, провести независимое ревью и переключить production.

И вот после такого слова про «+30% производительности» начинают казаться немного смешными.

Честно говоря, это пока самый впечатляющий кейс разработки с AI, который у меня был. Восторг скрывать не буду:)