Технологическая стратегия: собирать как продукт

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

Первый вопрос ведущего практический: ты выходишь в новую компанию, где всё новое, тебя позвали на масштабные изменения, и можно уйти с головой в операционку, подхватив выпавший флаг, — но вряд ли это лучший вариант. Киверин разводит калибры: CTO всей компании держит образ результата, который приведёт компанию к бизнес-результату, а у руководителя направления на входе уже несколько вводных — технологическая стратегия компании и то, чего ждёт его подразделение. Дальше нужен контекст: технологический менеджер — визави бизнеса, у зрелой компании бизнес-стратегия есть, а если её нет, то именно CTO должен вместе с CEO и CPO поднять вопросы «куда мы движемся», «какой образ результата» и «что для нас business critical». Здесь гость советует книгу ребят из Amazon про движение от образа результата назад: она помогает мыслить вне текущего статус-кво.

Круг стейкхолдеров гость перечисляет сразу: CEO, CPO и CIO или головной технологический блок сверху — и юниты и команды в собственном подчинении. Технологическую стратегию он любит сравнивать с продуктом: сначала Vision, вбирающий взгляд на конкурентов, финансовую модель и — то, о чём забывают даже CPO, — реальные возможности твоей команды. Входные параметры берутся из бизнес-стратегии: важна скорость, качество или их баланс, нужно создавать новые цифровые решения или оптимизировать ландшафт, а иногда — вместе с бизнесом определить бизнес-капабилити и проверить, чем они закрываются технологически. Дальше — что болит сверху, сбоку и внутри подразделения, причём не только в технологиях и процессах, но и в людях и оргдизайне. Из этого рождаются цели: от KPI к OKR, где objectives бизнеса превращаются в технологические, а ключевые результаты — в инициативы. Стратегия, подчёркивает Киверин, — это не только цели, но и то, какими инициативами к ним идут.

Ведущий добавляет про целеполагание сверху вниз и снизу вверх: когда команды сами собирают ключевые результаты, появляется их коммит, а спущенные сроки рождают отторжение. Он же вспоминает, как смещался цикл хайпа: сначала внедряли DevOps, потом бежали в облака, отказываясь от своих дата-центров, потом строили платформы, теперь везде внедряют artificial intelligence. Отсюда совет гостя держать в подразделении кусочек R&D — и ради ноу-хау для бизнеса, и ради оценки применимости новых технологий. Ведущий переводит разговор на отчёты крупных аналитических агентств: все погружены в информационный поток, но времени на глубокий разбор нет, поэтому трендвотчинг стоит кому-то поручить, подкидывая этой команде находки с индустриальных конференций. У гостя такие команды были везде: небольшая в B2C Сбера, в Газпром нефти — рядом с архитекторами и с выделенной капасити на исследования, в Ак Барсе — и про технологии, и про новые бизнес-решения; аналитику вроде Gartner как раз они и аккумулируют.

Ведущий рассказывает про Т-Банк: центр, который пишет статьи для топовых конференций и на днях выпустил большой текст с разбором обучения моделей, и свежую новость про инженерный центр исследований, созданный около года назад, — там встраивают ассистентов в тесты, код-ревью и миграцию кодовых баз между языками. Выгода как в Civilization: технологическая ветка внезапно апается, и появляются возможности, на которые в обычной работе не хватало фокуса. Дальше разговор переходит к метрикам: если стейкхолдерам важны результативность и скорость, фокус смещается на производственные процессы, если проседает доставка ценности — на delivery- и проджект-менеджмент, если падает удовлетворённость людей и буксует найм — на управление людьми. Ведущий просит слово и приводит пример: коллега готовил доклад про внедрение SPACE, первый пункт которого — satisfaction and wellbeing, и стало видно, что несчастнее всех инженеры надёжности, чаще всех встречающиеся с инцидентами, следом — те, кто разбирает баги и обращения с прода, а разработчики в среднем довольны: они видят код и делают фичи.

Начинать он предлагает с измерения: не занимались надёжностью — сделайте способ измерять и поставьте таргет; болят total cost of ownership и дублирование — соберите общую платформу, начав с MVP из сервисов, без которых не обойтись. По его ощущению, именно с этого во многих компаниях стартовали internal developer platform. Гость упаковывает это в механику: команда эффективности следит за метриками и находит западающие зоны, вокруг них собираются команды и инициативы, планирование идёт годовыми циклами, а итерации — квартальными, с ретроспективой и фидбеком от стейкхолдеров. Ведущий добавляет, что здесь много проджект-менеджмента: гейты показывают, где инициатива закончилась быстрее ожидаемого, а где проскальзывает или гипотеза не сработала. Из накопленных изменений, замечает Киверин, и складывается инженерная культура: практики, оргдизайн команд вроде Team Topologies или структуры в духе Spotify, компетенции, ролевые модели и коммьюнити. Отдельно ведущий спрашивает про баланс между фичами и практиками с отложенным эффектом. Киверин отвечает масштабом — потери в процессе множатся на число команд, поэтому небольшой компании хватает качественного CI/CD-пайплайна, — и объективными показателями: развивать архитектуру дальше подсказывают fitness-функции по maintainability и scalability, а не желание сразу построить «как в Google».