Привет, Хабр! Меня зовут Глеб Тильтиков, я Chief Technical Officer платформы МТС OmniChannel. Обычно вопрос «Что должен делать СТО?» вызывает много дискуссий, потому что на рынке нет золотого стандарта или общего мнения на этот счет. Единственной переведённой на русский язык книгой про нашу работу является «Настоящий CTO. Думай как технический директор» Алана Уильямсона. По ней можно примерно рассчитать, сколько CTO должен тратить на разные направления работы. 

Мне стало интересно, как мой опыт соответствует теории из книги. Я собрал свои задачи, разбил их по группам и посчитал, сколько трачу на них времени. С одной стороны, я увидел как распределяются мои силы по разным направлениям, а с другой — получил ответ на вопрос: «СТО я или только маскируюсь?». Под катом — разбивка моих задач по времени и и сравнение с теорией из «Настоящего СТО».

Сферический СТО на моем примере

Приоритеты СТО зависят от целей бизнеса, размера команды и от вызовов инфраструктуры:

• Я руковожу разработкой МТС OmniChannel — высоконагруженной омниканальной платформы для маршрутизации SMS в различные каналы.  Уровень доступности — 99,97%, а классификация — mission critical. Это означает, что любые сбои недопустимы, так как приведут к неприятным последствиям для наших клиентов, среди которых банки и крупные компании.

• У меня в команде 50+ человек: разработчики, DevOps-инженеры, аналитики и тестировщики. 

• Сейчас МТС OmniChannel обрабатывает 20 тысяч запросов в секунду. 

Как распределяется моя работа

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

1. Поставка ценности — 5%

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

Как мы подходим к задачам:

• приоритезируем в соответствии с потребностями бизнеса;

• вместе с командой бизнеса прорабатываем продуктовые гипотезы и оцениваем их ценность;

• аргументируем пользой для бизнеса все задачи, в том числе по оптимизации, обновлению фреймворков или устранению техдолга.

2. Поддержка качества — 7%

Mission critical — это одновременно наша гордость и бремя. Продукт обеспечивает работу внутренних сервисов и ИТ-платформ внешних клиентов. Любое нововведение или изменение должно учитывать этот контекст и реализовываться максимально аккуратно.

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

3. Культура разработки — 8%

«Процесс — это когда нужный сотрудник, в нужное время, делает то, что нужно». 

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

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

Среди ключевых практик:

• управление техзрелостью по 11 направлениям;

• гибкие команды, менеджмент целей и непрерывная актуализация бэклога;

• учёт техдолга, баланс между готовым корпоративным решением и собственной реализацией;

• внедрение лидерства в безопасности — DevSecOps и Security Champion.

4. Оценка ресурсов — 10%

В разработке часто говорят «дать точную оценку = сделать». 

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

Мне пришлось учитывать кучу факторов:

• Инженерные трудозатраты: разработку, интеграцию и тестирование — сколько людей и часов понадобится для каждого этапа.

• Инфраструктуру: ресурсы серверов, сети, мониторинг и обеспечение отказоустойчивости.

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

Интересный факт: аналогичную задачу поручили стороннему вендору, и наши оценки совпали на 85%.

5. Постановка целей и планирование — 10%

В этом пункте я учел время, которое идет на формирование целей и их проработку с командой. 

Взаимодействие с CPO

Вместе с CPO мы составляем цели и критерии их достижения по методике OKR, чтобы каждый знал зачем мы здесь. 

Для успешного внедрения OKR важно ставить цели на уровне топ-менеджмента. Но в масштабах МТС, наши OKR остаются внутри проекта, без прямой привязки к корпорации. У МТС свои KPI, такие как OIBDA и EBITDA, а у нас — локальные ориентиры.

Мы подошли к вопросу прагматично: представили, что работаем как отдельный бизнес, выделив внутри проекта СТО и CPO разными ролями. Эти роли ставят OKR так, словно выше их ничего нет, ориентируясь только на нужды продукта. Конечно, это не идеальный подход, но он работает.

PI-Planning: два дня для планов на три месяца

PI-Planning — не просто обсуждение задач, а глубокое погружение в планирование. Команда собирается на два дня, чтобы понять, чего хочет бизнес и разложить задачи по приоритетам.

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

В процессе возникают трудности. Хотя PI-Planning мероприятие общекомандное и создан для вовлечения сотрудников, некоторые коллеги присуствуют только на словах. На деле — постоянно отвлекаются на сообщения и опаздывают с обеда. Чтобы это преодолеть, мы готовим участников заранее: они должны знать контекст и сроки. Помогает фасилитатор, который задаёт повестку, правила и инициирует обсуждение.

Эпизодические ретроспективы

Я разочаровался в этом инструменте и мы его пересматриваем: сократили их количество и проводим не после каждого спринта. 

Иногда на ретро можно узнать что-то новое и понять, что и где надо улучшить Но часто эти встречи превращаются в «нытинги» : жалобы на всё подряд или пустые выводы вроде «пора в отпуск». Когда они становятся формальными, то на 80% мероприятий команда нечего не предлагает. Если же идеи есть, их проще озвучить без формата ретро.

6. Выбор технологий — 10%

У нас mission critical сервис, поэтому поддержка ценности продукта предполагает соответствие высоким стандартам надёжности. 

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

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

• Каждый новый инструмент добавляет уровень сложности.

• Часто необходим отдельный инженер для поддержки, чтобы инфраструктура оставалась стабильной.

• Когда порядок наведён, а система оптимизирована, наступает следующий цикл: выход новой версии, адаптация инфраструктуры и добавление задач в бэклог. Колесо сансары совершает ещё один оборот.

7. Партнерства — 10%

Одной из моих ключевых задач является выстраивание партнерских отношений — как с клиентами, так и со смежными продуктами внутри компании. 

Партнерство внутри компании

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

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

Работа с клиентами

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

Я всегда держу под рукой «презентацию из лифта» — двухминутный рассказ о продукте. Иногда такие короткие спичи открывают двери к крупным сделкам.

Кроме того, меня приглашают на встречи с клиентами. Это не только «вес» в переговорах, но и возможность оперативно ответить на технические вопросы, убедить в надёжности решения и найти обоюдовыгодные варианты сотрудничества. Забавно, но тут можно встретить бывших коллег, но работающих уже с другой стороны.

Технический аудит при слияниях

Иногда меня зовут на оценку зрелости компаний, которые планируется приобрести полностью или частично. Такой процесс называется due diligence, о нем писала моя коллега в статье «Шпионские игры сеньор-разработчиков».

Я оцениваю:

• состав и уровень компетенций команды;

• состояние инфраструктуры и архитектуры систем;

• наличие и актуальность лицензий, сторонние зависимости;

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

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

8. Эксплуатация — 15%

Никто не сможет эксплуатировать mission critical-систему лучше, чем её разработчики. Тут можно выделить три направления работы:

SRE (Site Reliability Engineering)

Я договариваюсь с бизнесом о ключевых функциональных характеристиках и необходимых им SLO.

И чтобы эти SLO соблюдались мы внедряем контроль над метриками: 

• SLI (Service Level Indicator): фактический, измеренный показатель значения. В нашей платформе важен факт доступности, время обработки запроса и доставки сообщений. 

• MTBF (Mean Time Between Failures): время между сбоями. Этот показатель изначально использовался в авиации, но сейчас стал стандартом для высоконагруженных систем.

• MTTR (Mean Time To Repair): среднее время восстановления

• MTTA (Mean Time To Acknowledge): среднее время подтверждения инцидента.

На DevOpsConf2025 я подробно расскажу, как обосновать SLO по доступности и рассчитать затраты на его повышение. Приглашаю всех SRE, CTO, DevOps и TechSupport — обсудим детали и реальные кейсы.

Техподдержка

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

• На первой круглосуточно обрабатываются обращения;

• На второй осуществляется ежедневная поддержка более сложных запросов;

• В качестве третьей линии мы привлекаем DevOps, тестировщиков и разработчиков для решения критических задач.

DevOps у нас дежурят ежедневно. Повторяющиеся запросы добавляем в бэклог для устранения техдолга и автоматизации.

Противодействие угрозам

Как CTO я несу ответственность за защищенность моей системы, поэтому мне необходимо:

• следование актуальному техрадару компании;

• выстраивать защиту от сетевых атак и проникновений;

• исключать использование санкционного ПО;

• своевременное обновлять сертификаты безопасности;

• следить за соблюдением лицензионных политик.

9. Командообразование — 25%

«Я счастлив, когда мой сотрудник выполнил задачу, гораздо больше, чем когда задачу выполнил я сам». (с) 

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

В Agile-манифесте ключевая идея — ценность людей. Ответственность СТО — подобрать правильные кадры и создать условия, в которых каждый сможет раскрыть свой потенциал. Именно поэтому большая часть моего времени уходит на управление командой, личные встречи один на один и разъяснение отдельным сотрудникам вопросов «что происходит» и «куда мы идем». 

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

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

• Вокруг задач, когда мы фокусируем усилия на достижение новых целей.

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

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

Так настоящий ли я СТО по Алану Уильямсону?

Кажется, что да, но есть нюансы. Задачи CTO из книги и реальной жизни выглядят похожими, но их распределение заметно отличается.

Во-первых, книга охватывает широкий спектр продуктов: от стартапов, где CTO отвечает за принцип «раз-раз и в продакшен», до вендорских решений, которые нужно интегрировать и поддерживать. Мой случай — это mission-critical-продукт, созданный в корпорации с нуля. Этот формат накладывает свои особенности.

Самое заметное отличие — перекос в сторону эксплуатации. Мой продукт требует качества и надёжности — это требует постоянного внимания к инфраструктуре, метрикам, отказоустойчивости и техподдержке. Неизменность качества здесь — не просто один из пунктов, а база, вокруг которой строится весь процесс разработки.

Культура разработки в нашем случае тоже выглядит иначе. Мы не можем позволить себе опробовать каждую новую методику или технологию только ради эксперимента. Прежде чем внедрять что-то новое, мы оцениваем, как это повлияет на стабильность и не представляет ли угрозы ключевым бизнес-процессам наших клиентов. Каждая ошибка может дорого стоить, поэтому главное правило как у врачей: «Не навреди».

Задачи CTO всегда зависят от контекста. Для кого-то это стартап и эксперименты, для другого — строгий SLA и ответственность за бизнес-критичные процессы. Книга Уильямсона предлагает универсальные инструменты, но только практика помогает понять, какие из них использовать, а какие отложить.

На этом у меня все. Было бы интересно узнать, как распределяются задачи у других моих коллег и как они видят книгу Алана Уильямсона.