IT в ФинТехе. Как всё начиналось: боли, релизы и средневековая Чехия. Часть 1
IT в ФинТехе. Как всё начиналось: боли, релизы и средневековая Чехия. Часть 1 Привет! 👋 Это новый выпуск из рубрики IT & Инсайты — здесь я делюсь разбором интересных и полезных материалов из мира технологий, управления и цифровой трансформации. Сегодня — обзор свежего эпизода под
27-08-2025 16:15 (МСК)
IT в ФинТехе. Как всё начиналось: боли, релизы и средневековая Чехия. Часть 1 Привет! 👋 Это новый выпуск из рубрики IT & Инсайты — здесь я делюсь разбором интересных и полезных материалов из мира технологий, управления и цифровой трансформации. Сегодня — обзор свежего эпизода подкаста «Техно.Логично» с Алексеем Ульенковым, руководителем ИТ Розницы и МСБ, и Александром Черушниковым, ИТ-куратором платформ Розницы. Речь — о непростом, но вдохновляющем пути ИТ-трансформации в Газпромбанке: как команда перешла от зависимости от вендоров и громоздких процессов к гибким продуктовым командам, частым релизам и инженерной культуре качества. Что особено запомнилось: 1️⃣ Как менялись процессы в ИТ: от «чёрного ящика» к прозрачности Один кейс из прошлого выглядел так: 👉 код отправляли внешнему вендору (например, Oracle), 👉 а «на местах» — собственные инженеры вручную разбирали, что изменилось, 👉 искали логику в кодовой базе, 👉 анализировали, какие параметры нужно подкрутить, 👉 и только потом формулировали, что именно надо исправить или донастроить. 💡 Представьте: вы не контролируете код, не видите, как он работает, и ждёте ответа от вендора — как от оракула (в прямом и переносном смысле 😉). Процесс — медленный, хрупкий, с высоким риском ошибок и простоев. 2️⃣DevOps и эволюция процессов в финтехе: Как менялась культура доставки изменений в продакшн: 🔹 Сначала — большие, но точечные релизы: развивали 1–2 решения, тестировали, выпускали релизы раз в месяц. → Просто, но медленно и с задержками. 🔹 Потом — «большие релизы»: один запуск на десятки систем, тестирование — неделями, стеки изменений — огромные. → Кажется, что «всё под контролем», но на деле — ложное чувство безопасности. Один "крупный" баг = всё откатываем. 🔹 Сейчас — частые и маленькие релизы: каждая команда выкатывает, когда продукт готов. Автоматизация, мониторинг, обратная связь — в реальном времени. 🚨 Ключевой инсайт: «Чем чаще мы ставим — тем реже падаем.» (и когда падаем — быстро встаём) 💡 В начале было сопротивление: «Так не принято», «Слишком рискованно». Но результат доказал эффективность: меньше стресса, выше стабильность, быстрее изменение уходит к клиенту. ➕ Плюс — очень понятное и короткое объяснение, зачем нужны DORA-метрики и как они помогают оценить реальную эффективность команды. 📌 Всё это — не теория, а реальная жизнь. Истории, которые узнают многие, кто работает в корпоративном ИТ. 💬 А у Вас в команде были похожие кейсы? — Когда код был «чёрным ящиком»? — Или когда «большой релиз» внезапно рушил всё? Делитесь в комментариях — интересно сравнить контексты! 📌 И да — вы наверняка задаётесь вопросом: «При чём тут, вообще, средневековая Чехия?» 🔎 Ответ — во второй части. 😉 Поведую о том, как участники подкаста изменили культуру в кампании, внедрили DevOps и перестроили подход к разработке. 🎧 Подкаст рекомендую послушать по ссылке: 👉 https://vkvideo.ru/video-145457488_456239856 #ITИнсайты