Мыслить как СТО: как в Dodo Engineering сменили парадигму техлидерства

Павел Притчин — СТО в Dodo Engineering. Он выступил на конференции для топ-менеджеров ИТ-компаний South HUB 2024. Рассказал, как изменил взгляды на руководство техническим проектом, и как новое мышление помогло ему в работе. Собрали самые важные мысли из доклада в статье.

Сеть пиццерий «Додо Пицца» выросла из небольшого бизнеса в крупную международную компанию. Только в России у нас более тысячи точек, а присутствуют франшизы всего в 22 странах. Последние открытия были в Грузии и Азербайджане. Также у нас есть 35 кофеен Дринкит.

В IT-отделе работает 320 человек, и все они трудятся над развитием Додо ИС — нашей единой информационной системы на .NET, которая развивается с 2015 года. В пиковые моменты она обрабатывает до 740 заказов в минуту. Кажется немного, но на самом деле это огромное количество, ведь каждый заказ — это сложная бизнес-транзакция, которая включает приготовление и доставку, чтобы клиенты как можно быстрее получили горячую пиццу.

Мой путь с Dodo начался ещё в Сыктывкаре: я пришёл как .NET-разработчик, затем стал тимлидом, а позже перешёл в SRE-инженеры и занимался инфраструктурой.

Мне предложили стать Product Owner Technical Platform — то есть возглавить несколько команд разработки. Я понял, что старые подходы здесь не сработают, ведь раньше я руководил одной командой. Чтобы показать хорошие результаты за первый год, нужно было менять принципы и установки.

Помимо большого количества людей, были и другие вызовы:

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

Чтобы продемонстрировать быстрые результаты и завоевать доверие команд и стейкхолдеров, нужно было грамотно распределить силы. Чтобы не изобретать велосипед, я решил взять за образец сам бизнес Dodo.

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

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

Я сел и расчертил план на год, разбив бэклог на категории по срокам.

Долгосрочные. Например, проект по Kubernetes занимал около года. Я посадил туда команду и не трогал, позволив спокойно работать над проектом.

Среднесрочные. Переделка стендов заняла два месяца. Хорошо, что мы организовали её в начале — разработчикам стало удобнее делать оставшуюся работу.

Краткосрочные. В первую неделю работы я организовал встречу с разработчиками для обновления статусов. На первых встречах по 30 минут выслушивал критику, но со временем встречи стали более конструктивными.

Получился такой портфель проектов:

К проектам можно подходить и с точки зрения рисков. Например, для входа в наш бэкофис мы разрабатывали Pass Key, чтобы не использовать SMS и упростить доступ. Для этого не было готовой библиотеки для .NET, и нам пришлось написать свою. Это был рисковый проект, ведь могли и не справиться. Я был готов к тому, что проект может не получиться, и зафиксировать убыток через месяц разработки. Такие рисковые инвестиции в бэклоге — нормальное явление. А если нужно быстро получить результат, можно исправить пару багов — и все будут счастливы.

Разные группы стейкхолдеров видят свои выгоды: кто-то получает что-то значительное в конце, кто-то — небольшие результаты в процессе. Правильное управление бэклогом позволяет удовлетворить всех стейкхолдеров, хотя бы раз в полгода предоставляя им значимые результаты.

Мысля как инвесторы, мы используем и приумножаем капитал. Можно даже виртуально подводить баланс, оценивая, в минусе мы или в плюсе.

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

Когда я занимался инфраструктурной платформой, всё было понятно: мне нужны Kubernetes, базы данных, разработчики, логи, финансы.

На должности CTO вместо чёткой работы с инфраструктурой и разработкой я столкнулся с постоянным хаосом и неожиданными проблемами. От меня требовали стратегических изменений, но это было трудно, так как каждое утро я обнаруживал десять сообщений с пометкой «срочно!». Стал думать, как совмещать планы на будущее с необходимостью решать текущие задачи и двигаться к цели, оставаясь гибким.

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

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

Какой из этих паттернов лучше подходит для CTO? Ответ: никакой и оба сразу.

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

В стартапе потери могут быть небольшими, поэтому нужно действовать. В случае зрелого бизнеса каждое действие требует тщательного обдумывания и выполнения. В английском есть выражения one way door decision и two way door decision — одностороннее и двустороннее решение. Одностороннее решение — это такое, после которого нет возврата назад. В таких случаях важно тщательно обдумать и выбрать единственно верный вариант. А двустороннее решение — это действие, которое можно отменить, если что-то пойдёт не так, поэтому его можно принять после краткого обдумывания.

У нас был проект по переводу сервисов на новую версию .NET с последующим внедрением Kubernetes. В какой-то момент неожиданно один из проектов быстро завершился, и у нас возник профицит в бюджете. Это была неожиданная ситуация, но у меня был готовый план действий.

Я быстро принял решение использовать лишние средства для ускорения разработки. Мы наняли внешний аутстаф и масштабировали наши внутренние команды разработки. Это позволило нам значительно ускорить завершение проекта, быстрее доставить ценность бизнесу и перейти к следующим задачам.

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

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

Мы в нашей команде осознали эту проблему и внедрили практику RFC (Request for Comment). Когда кто-то из команды хочет внести изменения, которые затрагивают не только его сервис, но и другие команды, он пишет дизайн-док. Этот документ проходит процесс утверждения у архитекторов, и только потом уходит в работу.

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

Разделение на таймлайны для проектирования и реактивных действий оказалось эффективным. В периоды шторминга более важно быть реактивным и оперативно решать возникающие проблемы, в то время как в более спокойные периоды можно следовать планам и стратегиям.

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

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

В стремлении к стабильности лучше отталкиваться от метрик. Если наоборот хотим что-то изменить, лучше делать как чувствуем, отталкиваться от того, каким видим будущее.

Data Driven — метод, основанный на тщательном сборе метрик и их анализе. После принятия решения вновь собираете данные, оцениваете результаты, и так дальше — по кругу.

При Data Informed подходе человек действует как художник, заранее представляет, куда хочет прийти. Он действует в соответствии с этим видением, но учитывает данные.

Видение и метрики можно подружить. Для этого мы применяем концепцию Run Change Disrupt. В этом случае работа разделяется на три основных направления.

Мы делали систему надёжности Service Level Objective. SLO — это такая система, в которой нужно поддерживать некоторые значения. Если индикатор отклоняется от нужного значения, то это событие заставляет совершить действие. Например, если падает надежность, приостанавливаем бизнесовый бэклог и берём больше технических задач. Это пример run-деятельности: поддерживающий процесс, который помогает держать статус-кво.

Dodo решила выйти на рынок Дубая. Компания была малоизвестной в регионе, где Pizza Hut уже была на протяжении десятилетий, а Dodo начинала с нуля. Вопрос заключался в том, как организовать разработку IT, чтобы успешно войти на этот новый рынок.

Обычно в таких случаях мы создаём специализированную команду — небольшую, но очень профессиональную. В такой команде может быть один бэкенд-разработчик, специалисты по iOS и Android, аналитик данных и опытный продакт-менеджер. Эти люди работают вместе, чтобы реализовать инновационные идеи и адаптировать приложение под местные потребности.

Например, для Дубая команда разработала функцию AI Pizza, которая позволяет клиентам заказывать пиццу по индивидуальным предпочтениям или кастомизировать блюда. Это помогло привлечь новых клиентов и удержать их.

Если нужны изменения и амбициозные цели, топология команды должна быть продолжением идеи бизнеса.

Мы обязаны действовать по многими направлениям. Быть CTO — значит жонглировать десятками шариков. Это можно сделать, если ты взял свой шарик из портфеля проектов и вбросил в правильный таймлайн. То есть, если ты мыслишь как инвестор и понимаешь риски для своих инвестиций.

Нам нужны и реактивные, и активные сценарии работы. Если их разделять, удастся и планировать, и действовать по обстоятельствам.

Мы поддерживаем операционную работу и одновременно совершаем прорывы. В этом помогают правильно поставленные цели, а под цели нужно удачно выбрать лидеров и команду.

Посмотреть запись доклада можно на YouTube-канале South HUB. А чтобы послушать доклады вживую и познакомиться со спикерами и участниками, приезжайте на следующий South HUB — кэмп для C-level в IT, который пройдёт в июне 2025 года. Следите за новостями кэмпа в телеграм-канале.