Как выстраивать работу в командах, чтобы она была не только эффективной, но и адаптивной к изменениям?

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

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

Типы команд
- Stream-aligned team — это основной тип команды в организации. Такие команды сосредоточены на конкретном потоке ценности (продукте, услуге или функции) и полностью отвечают за разработку и поддержку своих продуктов. Они стремятся минимизировать внешние зависимости, чтобы сосредоточиться на быстрой поставке инкрементов, полезных для пользователей. Как правило, такие команды кросс-функциональные, то есть включают специалистов с различными компетенциями, необходимыми для самостоятельного выполнения задач.
- Platform team — создают платформенные решения, необходимые для работы других команд. Обычно это команды, которые превращают инфраструктуру в сервис для разработчиков. Они должны наладить сбор обратной связи от пользователей их платформы.
- Complicated subsystem team — работают над системами, требующими глубоких специализированных знаний. Примеры таких систем — поиск, рекомендации, финтех.
- Enabling team — помогают другим командам улучшать свои процессы, внедрять новые технологии или решать сложные задачи. Например, это может быть команда экспертизы по качеству, которая проводит аудит и помогает улучшить качество работы, или команда, которая помогает выделить функционал из монолита.

Виды взаимодействия
- Collaboration — команды работают вместе для достижения общей цели. Это самый «дорогой» вид коммуникации, поэтому его стоит использовать только тогда, когда это действительно необходимо.
- X-as-a-service — команды предоставляют сервисы или платформы другим командам с четкими SLA и документированными интерфейсами. Это снижает потребность в частых коммуникациях.
- Facilitating — основной тип взаимодействия для Enabling team. В его рамках они помогают другим командам улучшать процессы или решать технические вызовы.

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

Существует бенчмарк, согласно которому, для быстрой и эффективной работы поставки ценности, большинство команд в организации должно быть Stream-aligned team, а их взаимодействие преимущественно — по типу X-as-a-service.

Далее необходимо определить идеальное состояние, к которому хочется прийти, оценить текущий разрыв (гэп) и составить план по его сокращению.

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

Интервью о карьере, управлении командами и искусстве быть CTO

Летом на SouthHub я познакомился с Мишей Трифановым. Миша и команда Cloud.ru записывают подкаст, и недавно пригласили меня поговорить о том, как пройти путь от разработчика до CTO, управлять командами разных размеров и внедрять изменения, оставаясь при этом продуктивным и сохраняя баланс между работой и личной жизнью.

Мой топ интересных мыслей из интервью
    1. Брать на себя ответственность и делать результат — главный ключ к росту в любой компании.
    2. Роль CTO — это переводить язык технологий на язык бизнеса
    3. Хороший лидер должен уметь делегировать, иначе выгорание неизбежно.
    4. Если вы хотите расти в карьере, важно не только быть хорошим разработчиком, но и понимать, как работает бизнес.
    5. Тимлид — это не лучший программист в команде, а тот, кто делает команду эффективной.
    6. Важно строить такие процессы, которые помогают компании работать стабильно даже без вашего постоянного участия.
    7. Внедрение изменений — это постоянная работа, и сопротивление всегда будет, но оно преодолимо.
    8. Важная часть работы CTO — это долгосрочное планирование, чтобы компания оставалась на острие технологий.

Если вам интересно узнать больше о лидерстве в IT и моем пути, заходите по ссылке и смотрите интервью.
- YouTube
- VK Video

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

Меня волновал один вопрос: будет ли этот опыт отличаться? Ответ оказался очевидным — да, и очень сильно

В чем оказались основные отличия?

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

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

2. Когда ты CTO, никто не поставит тебе цели на испытательный срок
Ты главный эксперт, и CEO ждёт от тебя план изменений и первые шаги. Важно это понимать и начинать готовить свою стратегию уже с первого дня. Весь онбординг на самом деле должен быть посвящён формированию стратегии и целей.

Мне помогает два подхода
- Визионерство. Что нужно исправить, чтобы стало идеально? Какие практики и бенчмарки из индустрии подойдут новой команде?
- Слушать команду. У команды часто есть идеи, которые обсуждались раньше, но так и не были реализованы. В рамках онбординга нужно успеть понять, что из этого важно и возможно реализовать.

3. Сложно показать быстрый результат
Когда ты CTO, горизонт планирования и реализации изменений составляет 9+ месяцев. А если добавить сюда онбординг, то получается уже 12+.

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

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

Что в итоге?
Онбординг в новой компании оказался для меня гораздо глубже и сложнее, чем я ожидал. Это похоже на жонглирование тремя гранатами: ты одновременно узнаёшь что-то новое, анализируешь ситуацию и начинаешь действовать. И уронить ни одну из них нельзя :)

Коллеги попросили меня поделиться списком материалов для тим лидов, которые лично мне запомнились и зацепили чем-то.

Задача оказалась довольно трудная, но я справился! :) Решил запостить в канал топ-3 из тех, что пришли в голову.

1. “Agile менеджмент” - Юрген Аппело
https://alpinabook.ru/catalog/book-agile-menedzhment/
В оригинале называется “Management 3.0”.

Эта книга мне очень зашла, когда мы внедряли Scrum и думали с командой над вопросом: “А зачем нужен менеджер в самоорганизующихся командах?”

Автор рассказывает про стиль управления servant leadership (лидер-слуга) и подкрепляет всё понятными примерами из своего опыта.

Потом оказалось, что на позиции CTO это вообще must have, так как ты уже работаешь только с опытными, самостоятельными и организованными менеджерами. И управление в концепции лидер-слуга позволяет лучше понять свою добавленную стоимость и приносить пользу команде.

2. “Джедайские техники” (обе части) - Максим Дорофеев
https://www.mann-ivanov-ferber.ru/catalog/product/dzhedajskie-texniki/
https://www.mann-ivanov-ferber.ru/catalog/product/put-dzedaia-dopolnennoe-izdanie/

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

Книжки очень практичные, я до сих пор пользуюсь советами оттуда :)

3. Подходы к системному ведению заметок: Zettelkasten, Метод PARA, Вечнозеленые заметки (Evergreen notes) и программа Obsidian

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

Практики очень полезные, когда изучаешь много нового контента. Помогают хорошо систематизировать знания и не забывать важные мысли. Каких-то конкретных материалов хороших не могу посоветовать, собирал свое представление из кусочков. Свои мысли об этих подходах писал тут: https://t.iss.one/cto_notes_panov/11

Сначала команды, потом код: как оргдизайн меняет архитектуру

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

Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной.

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

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

Как объяснить топам, что у нас всё хорошо с качеством?

Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение SLA на исправление багов (aka zero bug policy);
- надёжность ключевых пользовательских сценариев (aka «девятки», 99.99);
- среднее время восстановления после сбоя (Mean Time to Recovery)
- скорость работы интерфейса (например, Time to Interactive, Freeze Time);
- и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью.

Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию.

Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой.

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

А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов.

Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог:

Quality Score = Σ (вес метрики × значение метрики в шкале)

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

Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728

ChatGPT vs performance review
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?

Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.

Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.

Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂

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

Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.

Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...

В июле я выступил с докладом «Быть заметным и расти: как руководителю взять развитие в свои руки» на первой конференции Яндекса для тимлидов — Dream Team Lead. Делюсь ключевыми идеями и полезными материалами.

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

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

Что помогает расти:
— Диагностика через матрицы компетенций
Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки:
• TL roadmap
• Avito Tech Lead Profile
• Dropbox Career Framework

— Развитие скиллов
Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами».

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

— Окружение
Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать:
• GetMentor
• Solvery
• No Flame No Game (бот в Telegram)
• IT-мастермайнды

Где посмотреть доклад:
• VK Video
• YouTube
• Слайды

Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.