Teamlead Balun Courses

Как стать тимлидом и не сойти с ума

[Complete] Я стал тимлидом, что дальше

Как становятся тимлидами

Обычная наша карьерная лестница выглядит следующим образом:

1. Junior
2. Middle
3. Senior
4. Предложение руководить → Перекос в менеджмент
5. Тимлид

Является ли переход в тимлиды эволюцией разработчика?

Зачастую нет

Обычно, когда разработчика переводят в тимлиды в качестве повышения, то:

• Там попросту нет для человека других предложений
• Нет понимания иных сценариев

По бОльшей части, тимлид - это революция в карьерном пути, потому что работа становится менее технической и более менеджерской

Senior	Teamlead
Сильный тех	Сильный организатор
Большая насмотренность	Много общения с людьми
Строит архитектуры	Строит команды

Чего ждут от лида

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

Но в реальности к нам приходят со следующими вопросами:

• Бизнес
  • А когда фича доедет?
  • А зачем тебе этот специалист?
  • Команда медленно работает
  • Много багов на проде
• Команда
  • Повысят ли мне ЗП?
  • Зачем оценивать задачи?
  • Давай этот фреймворк затащим?

На самом деле тимлид - это целиково отдельный трек, который является менеджерским

В итоге парадигма меняется, и:

• От нас ждут решения проблем и задач
• У нас на руках команда и проект, которым нужно уделять внимание
• Система ценностей существенно сдвигается

Основные проблемы

• Пошёл в лиды, а времени на код нет
  • Мы должны тратить время на то, чтобы разобраться с техническими проблемами
  • определить трек развития и технической составляющей проекта
  • нас невозможно заменить на нетехнического менеджера, потому что решать технические вопросы - наша компетенция
  • наши обязанности:
    • принятие решений
    • тех. документы
    • ревью решений
    • валидация
    • арбитраж споров
    • выбор технической стратегии
• Иногда погружаюсь в тех, а потом отвлекают
  • нет полноценно времени на погружение в задачу и принесение ценности в виде кода
• Не успеваю всем этим рулить
  • большое количество встреч, которые вклиниваются в обед и отъедают почти всё время
• Несу ответственность за всё
  • ошибка команды = ошибка менеджера - даже если не в курсе о том, что делала команда, всё равно несёт ответственность менеджер
  • тимлид - всегда фасад для своей команды
• Жизнь как по чек листу
  • Для эффективной работы нужно изменить mindset. Всё должно быть структурировано и организовано. Обязательно нужно записывать все свои операции, планы, составлять ADR, потому что всё сохранить в голове невозможно - это высыпется.
  • Так же нужно не бояться говорить:
    • Согласовывать
    • Планировать
    • Отпускать людей на конференции
    • Прорабатывать фичи
    • Работать с выгоранием команды
    • Входить в ситуацию и помогать команде
  • Появляется сильное желание кодить

Из всех этих проблем у нас рождается:

• Смещение системы ценностей
• Вопрос о том, как себя оценивать и относительно кого?
• Что есть успех?

Лид - это ситуативная история, но не случайная.

Мы становимся лидами, когда в команде не становится тимлида. Но очень важно ответить себе на вопрос: “А оно мне надо?”

Типичные сценарии перехода в тимлиды:

• “Звёздный разработчик” - высшая техническая компетенция и отличная исполнительность. Компании, переводя таких разработчиков в тимлиды, теряют отличных исполнителей и преобретают неопытного тимлида
• “Оказался самым опытным” -
• “Кто-то должен был этим заняться” -

Переходя в лидские роли, специалист всё ещё пытается оставаться "лучшим исполнителем"

Как собрать требования к своей работе

Мы можем просто пойти к руководству и уточнить, по каким критериям нас будут оценивать, как тимлидов. Зачастую это неэффективно, так как:

• Ожидания часто бывают неявными, размытыми или даже противоречивыми
• Менеджер сам может не до конца понимать, что требуется от тимлида в конкретной ситуации
• Можно получить общие фразы вроде “руководить командой” или “доставлять фичи вовремя”

То, что мы не измеряем - этим мы не управляем

Неявные ожидания

Начальник описывает роль на 20-30% сознательно, остальное - культурные нормы компании, текущие боли и контекст, который он не артикулирует.

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

Противоречия

Один руководитель ждет «больше кода», другой - «1:1 с командой», третий - «метрики в дашборде». Один вопрос не раскроет всю картину.

По бОльшей части, нам нужна матрица компетенций, которая раскроет ожидания от каждого из уровней менеджеров

Динамика

Ожидания меняются ежеквартально (новые цели, смена приоритетов), а разовый разговор этого не ловит

Как собрать требования к работе

В первую очередь, нам нужно провести интервью:

• Что от нас ожидает менеджер?
• Что от нас ожидает команда?

Далее нам нужно сформировать:

• Список зон ответственности
• Стратегия делегирования
• Система отчётности - подаём руководителю в сжатом варианте отчёт о том, что было сделано

Далее можно составить небольшой инструмент “Карту ожиданий и границ влияний”:

• за что я отвечаю
• где влияю
• что не моё

Зона	Что входит	Примеры задач	Кто ещё вовлечён	Критерии успеха
Ответственность (только ты отвечаешь за результат)	То, что зависит ИСКЛЮЧИТЕЛЬНО от твоих решений. Без этого команда встанет	1. Планирование спринта 2. Распределение 1:1 встреч 3. Согласование приоритетов с руководителем 4. Performance review команды	Ты + руководитель	1. Задачи закрыты 2. команда растет 3. нет срыва дедлайнов
Влияние (ты направляешь, но не делаешь сам)	Области, где твое мнение определяет траекторию, но исполнители команда/другие	1. Архитектурные решения 2. Code review процесс 3. Онбординг новичков 4. Настройка мониторинга	Ты + техлиды/сеньоры	Решения принимаются без тебя, но в правильном направлении
Не моя зона (наблюдаешь или эскалируешь)	То, что вне твоего контроля или уровня. Не тратишь энергию	1. Бюджет на найм 2. Инфраструктура кластера 3. Корпоративные KPI 4. Стратегия продукта	Руководитель / другие отделы	Знаешь, куда эскалировать но не решаешь сам

Типы компаний

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

• Стартапы
  • небольшие команды
  • строительство с нуля
  • больше хаоса, чем разработки
• Небольшие компании
  • прошли “долину смерти”
  • сформировался стек
  • основные задачи в IT - операционка и трансформация
• Средний бизнес
  • заняли свою нишу
  • решение обкатано и приносит деньги
  • основные задачи в IT - стабильность и процессы
• Большие компании (Газпром, Северсталь)
  • штат более 1000 человек
  • имеют многолетний опыт и узнаваемость на рынке
  • имеют значимость на рынке
  • зачастую, IT - как обслуживающая история
• Bigtech (Яндекс, Т-банк, Ozon)
  • Такие же, как и большие компании, но IT-продукты - основа
  • Создают продукты для миллионов

Типы тимлидов

Тип	Определение	Плюсы	Минусы
играющий тренер	и кодит, и управляет командой - это Senior, который не может отпустить код и полностью перейти на управление командой	1. хорош для стартапов и команд до 4 человек 2. Может подтянуть команду 3. Умеет делать сложные технические решения	1. Не потянет больше 4 человек 2. Code Review 3. Запланировать далеко работы 4. Менторинг растущ
начинающий менеджер	Человек, который уже организует процессы в команде и меньшую часть времени тащит задачи	1. Уже понимает, что нужно тянуть процессы 2. Способен строить долгосрочную работу 3. Пишет код как раз 20% времени и тащит небольшие задачи	Не подходит: 1. Когда команде требуется разработчик 2. Когда команда джунов 3. Когда не нужно менторс
тимлид	Человек, который осознаёт себя менеджером, а его руками является команда. Он помогает двигать бизнес.	1. Уже умеет строить процессы 2. Делегирует задачи 1. Будет выгорать в стартапах, где хаос и нет процессов 2. В красных компаниях ему нужно будет больше исполнять, а не руководить 3. Команду джунов менторить не сможет - только часть >3.

Canvas ожиданий команды

Тимлиду и команде стоит вместе построить Team Canvas, чтобы понять, кто и чего ожидает друг от друга.

Начало работы тимлида

Что стоит определить для себя сразу:

• Какие изменения я привнесу в команды в первые 3 месяца?
• Какой будет мой первый шаг? Когда?
• Какой я хочу видеть команду через год, через 3?
• Что я хочу получить для себя через год, через 3? Почему?
• Что будет если не получится?

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

Должен ли тимлид работать руками

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

Неуверенность - это переоценка своих пробелов и обесценивание успехов Объективный пробел - это конкретная нехватка знаний и навыков, которые можно закрывать обучением или практикой

Что нужно зафиксировать:

• Команда всегда в общем плане знает больше тимлида, так как они погружены в проект плотнее
• Тимлид должен верхне видеть всю картину целиком
• В целом задача тимлида - организовать команду

Самодиагностика по компетенциям:

• Фиксируем 7 дней
  • Записывай каждый инцидент: «Сомневаюсь в решении Х. Что говорят факты/команда?»
• Круг отзывов - спросить 3-х человек (менеджер, peer-лид, сеньор команды):
  • Что я делаю хорошо стабильно?
  • Где конкретно результаты хуже ожиданий?
• Тест на повторяемость
  • если проблема единичная или эмоциональная - это неуверенность
  • Если системная и подтверждается метриками - это пробел

Выводы

1. Ты - менеджер
2. Тимлид - это новая роль, а не продолжение инженерного роста
3. Тебя наняли руководить командой, а не работать руками
4. Тебя наняли не просто так - ты уже проявил себя
5. Не бойся спрашивать, формируй четкие ожидания

---

[Видео] Как не тонуть в задачах и созвонах и проводить синки дейли ретро

Проблема

Когда мы работаем эффективно?

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

Как это ощущается:

• Ясные цели и мгновенная обратная связь
• Высокая концентрация без отвлечений
• Баланс между сложностью задачи и навыками (не слишком легко, не слишком сложно)
• Ощущение контроля и внутренней мотивации
• Позитивные эмоции, эйфория и потеря самокритики

Условия входа:

• Актуальность задачи - ощущение “надо делать”
• Минимизация отвлечений: отдельное пространство, наушники, режим “не беспокоить”
• Предварительная подготовка: разбивка на цели с “вехами” прогресса

Как это выглядит в действительности:

• длится 30 мин - 2 часа
• вход за 10–15 мин
• можно повторять несколько раз в день с короткими перерывами

Когда он рушится:

• Отвлекая человека, мы рушим его поток
• Вход и перезагрузка контекста — минимум полчаса
• Точно вопрос такой срочный, что не работает асинхронно?

Убираем раздробленность

Очень важно дефрагментировать нашу работу, так как это поможет нам сегментировать выполняемые задачи и повысить эффективность на отдельных участках

Дефрагментация = Сосредоточенная работа над запланированными задачами

Если задачи постоянно летят

Постоянное переключение между задачами (ложная многозадачность) снижает эффективность, так как мозг тратит до 40% времени на восстановление фокуса после каждого перехода.

Краткосрочные последствия:

• Стоимость переключения - каждый раз мозг тратит 15–25 минут на возврат к предыдущей задаче из-за остаточного внимания, что приводит к потере продуктивного времени
• Рост ошибок - Количество ошибок увеличивается на 40%, так как снижается глубина обработки информации и контроль
• Усталость и стресс - Переключения истощают когнитивные ресурсы, вызывая выгорание в 3 раза чаще, нарушения сна и снижение креативности

Долгосрочные последствия:

• Деградация мышления - Формируется зависимость от стимулов, мозг теряет навык глубокого фокуса на сложных задачах
• Снижение качества работы - Поверхностное выполнение приводит к переделкам, ухудшению отношений в команде и пропуску деталей

Мыслетопливо

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

Это воля или энергия для умственных действий:

Каждое решение (даже мелкое), загрузка задачи в память и борьба с отвлечениями тратят запас. Приятные задачи экономят ресурс, неприятные и сложные - жрут его быстрее всего

Думай медленно - решай быстро

Даниэль Канеман привел теорию двух систем мышления:

• Система 1 - Автоматическая интуитивная - предлагает быстрые импульсы
  • Работает инстинктивно, без усилий и контроля: распознаёт лица, эмоции, реагирует на опасности
  • Основана на ассоциациях, привычках и эмоциях (98% решений); склонна к ошибкам вроде стереотипов или иллюзий
  • Экономит энергию, но игнорирует нюансы - идеальна для рутины
• Система 2 - Сознательная логическая - корректирует при необходимости
  • Требует внимания, усилий и концентрации: решает задачи, считает, планирует, проверяет логику
  • Логична, стратегична (2% мышления), но устает быстро, как «мыслетопливо»
  • Контролирует Систему 1, но активируется редко из-за энергозатратности

Утечки «бензина»:

• удержание задач в голове
• уведомления
• переключения
• негативные эмоции

Последствия истощения:

• наступает «Информационная паника»
• импульсивность и ошибки
• действия «по умолчанию» без размышлений

Потеря фокуса: Без мыслетоплива фокус разрушается, как при многозадачности (15–25 мин на переключение) или выходе из потока

Экономия: Списки задач, шаблоны решений, минимизация отвлечений - чтобы хватило на важное

Режим Eco

• Выгружайте мысли на бумагу/в приложения
• Стандартизируйте рутину (одежда, еда)
• Делайте паузы для восстановления

Выгружаем задачу

Наша память - решето

Software as a memory

• Obsidian
• Todoist
• Remember the milk

Простота в использовании != Наличие процесса применения

Процесс распределения времени

Список задач на бумажке

Попробуем спланировать список задач на бумаге

Дано:

• Пустой инбокс
• Списки задач

Запишем список задач

Плюсы	Минусы
убираем вещи из памяти	непонятно, когда делать задачу
создаем порядок задач	непонятно, хватит ли на нее времени
очень приятно вычеркнуть готовую задачу	все в куче

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

Формализуем процесс

• Что нужно сделать?
• Когда нужно сделать?

ретроспектива

• Что я делал? Output
• Что я сделал? Outcome
• Что было не так?
• Что стоит улучшить?

Таймбоксинг

Смотрим трезво на календарь

Важность

Первым делом, когда мы смотрим на все наши встречи, нужно определить - где мы точно нужны.

Некоторые встречи можно выпустить и выкинуть из календаря.

Люфт

Далее нельзя планировать время встреч впритык - всегда должно оставаться небольшое окно, так как встреча может задержаться

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

Распределение нагрузки

Нужно заранее заложить время на отдых, обед и перерывы от работы

Делегирование

Часть встреч можно спокойно делегировать на других своих участников команды:

• есть суб-проекты, где нужны только определённые члены команды
• есть встречи, с которых могут принести final тейки, чтобы в них потом погрузиться

Приоритеты

У нас должно быть не более 3ёх приоритетов на день. Всё остальное мы делегируем на других участников команды.

Делегирование

Все ли нужно сделать именно нам?

Почему руководители не отдают задачи?

1. Боязнь провала со стороны команды
2. Недоверие к показателям качества

Последствия:

• Команда демотивирована недоверием
• Команда не растёт профессионально
• Руководитель не занимается своими прямыми обязанностями

Что мы можем делегировать:

1. Задачи
2. Полномочия

Делегирование != перекладывание ответственности

1. Берём инструмент планирования
2. Выбираем те задачи, которые объективно можем выполнить только мы
3. Для остальных задач выбираем сотрудников, которые могут решить задачу (например, у них больше экспертизы)
4. Решаем, какие вводные нужны, чтобы выполнить задачу
5. Отправляемся к выбранному сотруднику, объясняем все, что необходимо, и ставим срок, к которому должен быть получен результат

Рецепт делегирования:

• Кому?
  • мотивация
  • компетенции
  • обучение
• Что?
  • Что конкретно делегируем (принятие решений, экспертную оценку)?
  • Какой результат мы хотим получить?
  • Критерии
  • Какие полномочия передаем?
  • Какие ресурсы выделяем (время, деньги, люди)?
• Когда?
  • начало делегирования - окончание делегирования
• Контроль

Ошибки делегирования:

1. Бояться, что ничего не сделают
2. Не возвращаться в срок
3. Не давать вводные
4. Задавать сроки директивно
5. Не отвечать на вопрос «Зачем?»

Тактические и стратегические задачи

Типы планирования

• Тактические
  • нужно решить сегодня / завтра / на неделе
  • должны быть всегда перед глазами
• Стратегические
  • не решаются за 5 минут
  • много информации
  • требуют структуры и планов

Сначала планируем на бумаге очертания глобальных задач

Формируем инструментарий

1. Задача
2. Ответственные
3. Статус
4. Приоритет
5. Дедлайны
6. Идеи
7. История

Инструменты

Excel

Gant-like системы

MindMap

Построение простой диаграммы с нашим шаблоном для удобного начала работы

Так же есть Roadmap продуктов по O’Relly, где описаны дополнительные подходы к построению инструментария.

Целевая архитектура сервиса

Целевая архитектура DDD выстраивается вокруг ключевых поддоменов - областей, где сосредоточена основная прибыль и конкурентное преимущество (Core Domain)

Это позволяет инвестировать ресурсы именно в то, что приносит доход, минимизируя усилия на вспомогательные функции (Supporting/Generic Subdomains)

Цели: TTM снижен на Х%, баги снижены на Y%

Q1: проводим оценку текущего состояния сервисов	H1: рефакторинг 80% сервисов	Внедрение DORA метрик
Q2: проведение ES сессий для одного сервиса, выделение домена, описание в виде RFC	H2: оценка состояния, выделение плана доработок
Q3: рефакторинг и проверка гипотезы
Q4: рефакторинг 25% сервисов

Типичные ошибки:

1. Забивание на процесс
2. Отсутствие регулярности
3. Потеря контроля
4. Потеря результата
5. Неправильный инструментарий
6. Отсутствие ретроспективы

Появление информации

Входящий поток сообщений:

Критерий / Средство	Личное общение	Мессенджеры	Почта
Быстро	+	+	-
Понятно	+	+	+
Есть структура	-	-	+
Есть история	-	+	+
Асинхронное взаимодействие	-	-	- / +

Все задачи из трёх наших источников (входящий поток - личное общение, мессенджеры и почта) должны попадать в единый трекер.

В итоге у нас должен сложиться пайплайн:

• Общение
  • Постановка задачи
• Выявление сути
  • Корректировка задачи
  • Декомпозиция
• Обозначение сроков
  • Сроки
  • Сжатие задачи
• Обновление информации
  • Актуальный статус дел
• Выдача результата
  • Продукт

Нужно зафиксировать:

1. Не браться за работу, пока не выявим суть
2. Соблюдать сроки и обещания
3. Никаких сюрпризов

Контроль - это часть нашего планирования:

1. Обозначение сроков
   1. Согласование ТЗ со всеми участниками процессов
   2. Письменное подтверждение всех договорённостей
   3. Привлечение экспертных знаний
   4. Декомпозиция задачи
2. Обновление информации
   1. Постоянное обновление статуса (standups, встречи по планированию, и тд)
   2. Своевременное обозначение проблем и обсуждение их решения
   3. Бэкап исполнителей
3. Выдача результата
   1. Анализ проблем проекта
   2. Оценка производительности команды
   3. Соответствие оценок команды и реальных показателей

Встречи

Часто, встреча может быть просто тратой времени, если она не была полностью проработана заранее.

Эффективная встреча строится на этих столбах:

1. Она запланированная
2. У встречи есть координатор
3. Есть чёткий результат
4. Помогает команде достичь целей

Как спланировать эффективную встречу:

1. До встречи
   1. Обозначить цели встречи
   2. Приготовить повестку
   3. Разослать повестку всем участникам
2. Во время встречи
   1. Распределить роли: фасилитатор, Time Keeper, Note Keeper
   2. Придерживаться повестки
   3. Записывать
3. После встречи
   1. Разослать краткую сводку всем участникам
   2. Назначить ответственных и дедлайны для всех задач

Для выделения регулярных встреч, нужно определиться с тремя вещами:

• Зачем они нужны?
• Регламент встречи
• Фасилитация

---

[Видео] Как доносить мысли чтобы тебя понимали

Как понимать мотивацию и ограничения коллег

Teamlead выступает зачастую мостом между командой и руководством. Мы должны продавать идеи и подходы сразу команде и руководству:

1. Почему мы должны писать тесты и документацию?
2. Почему нельзя всем сразу повысить зарплату?
3. Почему нужно сделать определённую фичу?

И с той, и с другой стороны будут недопонимания

Кто виноват?

• Бизнес?
• Разработчики?
• Тимлид?

Мне неважно, почему «нет». Я хочу знать, что сделано, чтобы было «да»!

Огромная доля ошибок вызвана недопониманием ожиданий

Очевидное и неочевидное: ошибки и конфликты

«То, что очевидно для вас, не очевидно для других»

Принцип:

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

Синдром главного героя

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

Позиционное мышление

Для того, чтобы договориться, надо понять, чего хочет твой оппонент

Например:

1. Бизнес приносит задачу: «Нам надо сделать свою CRM к концу квартала»
2. Главный герой: «Да вы там с ума посходили?! Это нереально!»
3. Позиционное мышление: «Для чего? Что вы хотите получить? Что у нас уже есть?»

• Каждый фильтрует информацию через свои страхи/цели
• Ты проецируешь свою ясность на других

Мы думаем от своего лица:

• Наша позиция - “нужно ускорить деплой”
• Junior - “боюсь сломать прод”
• Стейкхолдер - “когда фича будет у клиентов?”

Кейс

Нам важно научиться думать с чужой позиции

Кейс: Вы принесли идею рефакторинга бизнес-стейкхолдерам Ваш интерес: Выделить 20% времени в течение года на то, чтобы сделать DOMA

Задача №1: Как бизнес воспримет это? Задача №2: А как тогда надо принести эту задачу?

Общение с командой

Типичные ловушки:

• «Ты же понимаешь» (команда кивает из страха)
• Технические детали без бизнес-контекста
• «Сделай как надо» без критериев успеха

Донесение мыслей до команды:

• Ты стоишь на вершине пирамиды опыта
• Команда видит только основание
• Ошибка: начинаешь с вершины, а не с основания

Структура мысли

Принцип пирамиды Минто - это способ структурировать мысли и коммуникацию так, чтобы сначала давать главное, а потом уже объяснять, почему это так

В основе три идеи:

• Сначала формулируется верхушка пирамиды - главный вывод или решение (answer first)
• Ниже идут 3-4 ключевых аргумента, которые логично и однотипно поддерживают этот вывод
• Ещё ниже - детали и факты, которые объясняют и доказывают каждый аргумент

Кейс

Мы имеем такой текст:

Привет, команда!

У нас проблемы с деплоем. Вчера опять упали платежи, клиенты пишут в поддержку. Надо что-то делать с тестами, они не покрывают edge cases. Ещё нагрузка на Redis выросла, надо посмотреть кластер. В прошлый раз помогло, когда добавили кэш, но сейчас не помогает.
Давайте обсудим на синке, что можно сделать. И вообще, спринт на 60% только, надо ускориться.

Что думаете?

Проблемы:

1. Главная мысль спрятана (надо ускорить деплой)
2. Смешаны симптомы, причины, предложения
3. Нет приоритетов и логики
4. Читатель тратит 2 минуты на понимание + пишет уточнения

Принципы

SCQA

По этой структуре, мы делим обращение на 4 части:

1. Situation - 1 предложение
2. Complication - почему это проблема?
3. Question - что решаем?
4. Answer - решение

Пример:

1. Situation - команда сдаёт спринты на 60%
2. Complication - теряем 2 недели на переделки
3. Question - как ускорить delivery без выгорания?
4. Answer - внедряем DoD + автоматизацию тестов

MECE

Mutually Exclusive, Collectively Exhaustive

Методика структурирования мыслей/текста/писем, которая вытекает из принципа пирамиды Минто.

• Mutually exclusive = в деталях есть все подробности

• Collectivery exhaustive = рассуждения покрывают все критические вопросы внутри области

• 🔼 МЕСЕ: категории не пересекаются, ничего не пропущено

• 🔽 НЕ МЕСЕ: «критичное/не критичное» - расплывчато

Пример:

Sprint Goals (неМЕСЕ)	Sprint Goals (МЕСЕ)
Платежи работают	[P0] Платежи работают с надежностью 99,9
Нотификации	[P1] Нотификации доходят до пользователей вовремя
Личный кабинет	[P2] Личный кабинет запущен с функциональностью 1-2-3

Результат

Привет, команда!

Я предлагаю ускорить деплой в 2 раза без влияния на число инцидентов.

Сейчас деплойим раз в 2 недели, покрытие тестов 65%. Вчера упали платежи на 2 часа, потеряли 1.2млн руб. Как я хочу сократить цикл деплоя до 1 раза в неделю?

3 шага:

1. Автотесты на edge cases (junior + QA, дедлайн пятница)
2. Blue-green деплой (middle архитектор, среда готова)
3. Мониторинг Redis (alerts уже настроены)

Спринт на 90% вместо 60%, риски под контролем.
Обсудим детали на синке 14:00?

1. Такие решения будут челленджить - они не конечны
2. Но теперь разговор строится от конкретных шагов, а не от абстрактного понимания с точки зрения каждого

Быстрые объяснения

Шаблон elevator pitch

Задача: Донести то, что хотите, за пять минут (пока едет лифт)

• Проблема - бизнес-метрика
• Решение - простыми словами
• Результат - цифры через месяц
• Риски - что может пойти не так

Пример:

• Проблема: У нас много багов на проде, что сажает CSI и снижает доверие к продукту, а также растит расходы первой линии поддержки
• Решение: Надо выделить 50% ресурса человека на месяц исправление проблем
• Результат: Через месяц стабильность вырастет, снизится нагрузка на сапорт
• Риски: Рефакторинг может все разломать, но у нас обеспечено хорошее покрытие автотестами, которое позволит убедиться в совместимости

Практический шаблон коммуникации

1. ЦЕЛЬ: Зачем это нужно бизнесу?
2. КРИТЕРИИ: Что есть успех?
3. ГРАНИЦЫ: Чего не будем делать?
4. РЕСУРСЫ: Кто/что нужен для решения?
5. ДЕДЛАЙН: Когда нужен результат?

Общение в чатах

Ответы в чатах:

• Плохо: «Срочно скинь мне инфу по простоям сервака»
• Хорошо: «Нужны метрики загрузки сервера к 15:00. Формат CSV, топ-5 пиков. Успеешь?»

Обмен сообщениями:

• Telegram, Skype, Discord, etc.
• Мы общаемся в мессенджерах постоянно
• Большинство мессенджеров используются не только для работы
• Мессенджеры – один из каналов коммуникации с клиентами

Проблемы:

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

• Заводите папки или каналы (например, в Telegram)
• Рабочий канал приоритетен в рабочее время
• Каналы с внерабочими коммуникациями стоит заглушать на время работы
• Канал с клиентами лучше отделить от внутрикорпоративного канала

Асинхронное общение

• Доставленное и прочитанное сообщение провоцирует ждать ответа здесь и сейчас

Я прочитал – значит обработал:

• Не беритесь за сообщение, пока не готовы потратить несколько минут на его обработку
• Если работаете с сообщением, не переключайтесь
• Если прочитали сообщение, но не обработали его – верните его в непрочитанные
• Непрочитанное сообщение = точка работы

Две галочки ничего не значат:

• Если собеседник прочитал Ваше сообщение, это не означает, что он его обработал. Вероятно, он также пометил его непрочитанным
• Пользуйтесь напоминанием собеседнику.
• Но не через 5 минут. Напомнить можно через 12 часов. Если всё горит – позвоните
• Ваше сообщение точно подразумевало ответ? Не бойтесь уточнять

Поток мысли

• Увидеть начало мысли и потом ждать, когда человек выдаст продолжение
• Сжечь виброзвонок кучей мелких сообщений в 2-3 слова

Осознанные сообщения:

• Каждое сообщение — законченная мысль
• Сокращайте переключение между сообщениями. Одно большое сообщение лучше, чем 10 маленьких
• Используйте Slow Mode в Telegram. Он будет блокировать отправку более 1 сообщения за выбранный промежуток времени
• Отключайте активные оповещения для сосредоточения

Аудиосообщения

• Человек читает примерно в 2.7 раза быстрее, чем слушает

Никаких аудиосообщений:

• По тексту можно искать
• Текст не надо слушать на весь open space
• Сообщение в 1 минуту будет содержать информации где-то на 20 секунд чтения

Нарушение границ

• Грубое общение
• Фамильярности
• Время переписки

Этика общения:

1. В новом канале поздоровайтесь и представьтесь
2. Избегайте оценочных ответов на чужие сообщения типа «дурь», «фигня» и т.п.
3. «Нет» - это не законченная мысль. «Нет, потому что…» - гораздо лучше
4. Перечитайте сообщение ещё раз. Выдохните. И ещё раз перечитайте, прежде чем отправить
5. Эмоциям не место в рабочем чате
6. Общий чат вовлекает на одно сообщение N людей. Посмотрите на пункт 4 и подумайте ещё раз
7. В нерабочее время человек может не отвечать. Это нормально

Отсутствие результатов

• Общение в течение нескольких часов / дней / лет сваливается в никуда

Убираем риторику:

1. Если надо обсудить большой вопрос, обсудите лично, а не в группе
2. Не задавайте риторические вопросы, которые могут быть поняты буквально и увести дискуссию в дебри
3. По итогам обсуждения всегда приходите к шагам, которые надо предпринять
4. Мы сообщений должны быть интересны хотя бы 20% участников чата
5. Бегайте двусмысленностей. Выражайте мысли так, чтобы они были однозначно понятны

У каждого шага: цель, срок, ответственный

Резюме:

• Делите чаты на группы
• Контролируйте чтение сообщений
• Уважайте собеседника
• Не тратьте время группы на ерунду
• Соблюдайте этику общения
• Не используйте аудиосообщения

Практика:

1. День 1: Пишем обращения к команде и заказчикам по модели SCQA
2. День 3: Тестируем МЕСЕ-тексты в письме по решению задачи
3. День 5: Пробуем elevator pitch с руководителем
4. День 7: Собираем отзывы команды и заказчиков

---

[Процесс] Как формируется команда и почему она не едет

Что такое команда

Проблема: люди есть, а команды нет

• Нет общего видения - каждый работает над “своей” задачей в Jira, не понимая общей цели
• Конфликты и блокировки - один человек ломает работу другого. Коммуникация разрушена
• Низкая согласованность - решения принимаются изолированно, приоритеты у всех разные

Как появляется команда?

Критерий	DoR
Группа людей	Вначале всегда появляется некая группа людей, работающая над чем-то в схожей области
Есть правила работы	Люди стремятся к правилам, чтобы не сталкиваться лбами
Есть общая цель	Люди начинают понимать, что делают вместе что-то одно
Есть зоны ответственности	Люди понимают, что толкаться локтями и делать одно и то же - неприкольно
Есть роли	Помимо hands-on работы люди принимают на себя поведенческие и профессиональные роли
Есть личная и коллективная ответственность	Люди понимают, что несделанная ими работа - это провал
Есть самостоятельность в работе	Работают взрослые люди, которым не надо напоминать, что работа должна быть сделана [хорошо]

Команда

Это группа необходимых для решения задачи людей

• организованная для совместной работы
• имеющая единое видение для достижения общей цели
• способная работать вместе и разделять ответственность за результат

Размер команды

• Микрокоманда - 2-4 человека
  • Плюсы
    • Быстрые решения
    • Высокое доверие
    • Легкая координация
  • Минусы
    • Узкий набор навыков
    • Перегруз ключевых людей
• Оптимальный размер - 5-9 человек
  • Плюсы
    • Оптимальный баланс
    • Разнообразие ролей
    • Управляемая динамика
  • Минусы
    • Нужны явные нормы
    • Важна роль лидера
• Большая команда - 10+ человек
  • Плюсы
    • Широкие компетенции
    • Высокий ресурс
  • Минусы
    • Много коммуникаций
    • Риск подгрупп
    • Замедление решений

Правило Безоса

The 2 pizzas team

Команды или совещания должны быть достаточно небольшими, чтобы их можно было накормить двумя большими пиццами, обычно это означает от 5 до 8 (или максимум 10-15) человек

Ключевые аспекты правила:

1. Улучшенная коммуникация. В небольших командах меньше каналов связи, что позволяет быстрее принимать решения
2. Повышение производительности. Это смягчает эффект Рингельмана, при котором индивидуальная производительность снижается в больших группах
3. Повышение ответственности. Члены команды получают больше полномочий и несут большую ответственность за свои результаты
4. Фокус на инновациях. Небольшие группы могут быстрее экспериментировать и брать на себя большую ответственность за свои проекты
5. Снижение группового мышления. Небольшие команды часто способствуют более прямым, честным и продуктивным дискуссиям по сравнению с большими, застойными совещаниями

Как формируется команда

Модель Такмана

Модель придумана в 1965 американским психологом, работавшим в военно-морском медицинском исследовательском центре США

Плюсы:

• Простота и запоминаемость. Рифмующиеся названия стадий
• Универсальность. Подходит для описания самых разных групп
• Практическая применимость. Менеджеры сразу увидели в ней инструмент для работы с командами

Формирование

• Группа только собирается вместе
  • Люди вежливы, осторожны, присматриваются друг к другу
• Роли и правила не определены
  • Все ориентируются на лидера
• Главная задача участников
  • Понять, куда они попали и чего ожидать

Характерно:

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

Что делать:

• Создать безопасную среду, объяснить цели и роли

Конфликт

• Начинается борьба за влияние
  • Выясняются различия в ценностях и подходах
• Отстаивание позиций и авторитета
  • Люди начинают отстаивать свои позиции, оспаривать авторитет лидера и друг друга
• Точка роста команды
  • Это самый болезненный этап, но необходимый - без него группа не развивается

Характерно:

• напряжение
• соперничество
• снижение продуктивности
• разочарование

Что делать:

• Фасилитировать разногласия, закрепить договорённости

Роли в команде

Командные роли

Как развивается команда

Спиральная динамика

• Основу заложил американский психолог Клер Грейвз в 1950–70-х годах, изучая развитие ценностных систем человека
• В 1996 году его ученики Дон Бек и Крис Кован переработали идеи Грейвза и опубликовали книгу Spiral Dynamics, дав модели современный вид и цветовую кодировку

• Развитие
  • Люди, организации и общества развиваются через уровни мышления и ценностей
• Принцип
  • Каждый уровень возникает как ответ на определённые жизненные условия и проблемы
• Переход
  • Когда условия меняются и старый уровень перестаёт справляться, человек или система переходит на следующий

---

[Видео] Как выстроить микроклимат который будут вспоминать после перехода в другие команды

Мы здесь не навсегда

Истории роста

• Сколько работ вы уже сменили?
• Сколько из компаний, в которые хотелось бы вернуться?

Статистика

• Средний срок на одном месте: 2,5 года
• Сеньоры и руководители - меньше текучки, чем у мидлов

Уровень/Ситуация	Средний срок на месте
Junior IT (общий)	4-7 месяцев
Middle IT (общий)	1-2 года
Senior / Teamlead	2-3 года
«Идеальный» горизонт по оценке IT-спецов	5 лет
Редкие «старожилы»	10+ лет

Тимлид на российском рынке в среднем меняет работу раз в 2-3 года.

Это чуть реже, чем мидлы, но заметно чаще, чем хотели бы работодатели.

Основные триггеры - потолок по зарплате и позиции, выгорание от повышенной нагрузки и активный хантинг со стороны конкурентов

Alumni club

У бизнеса есть запрос - не терять ценные кадры с их экспертизой

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

Для чего Alumni:

• С помощью сообщества, компания может привлекать бывших сотрудников к участию в новых проектах
• А иногда - и трудоустроить их на взаимовыгодных условиях повторно

Типы команд

Хаос

лучшее, что могло с вами случиться!

Да, все горит. Но у вас есть кард-бланш

Если у вас его нет, срочно пишите «по собственному»

Что нужно делать:

• Остановить пожар
• Выработать базовую предсказуемость
• Найти и настроить критические цепи
• Начинать работать над качеством

Немного того, немного сего

Будет сложнее, но если себя зарекомендовать, то все пойдет!

• Люди уже привыкли так работать
• Какие-то вещи придется ломать
• Будет сопротивление
• Начинать лучше с низковисящих фруктов

Карго-культ

Команда работает по каким-то процессам, потому что: модно, надо, так было

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

Процессная команда

Классно, но менять что-то будет также тяжело

• Есть N процессов, обоснованных и защищенных
• За их исполнением следят
• Чтобы их поменять, надо защитить изменения

Подход

• Оцените тип своей команды по cynefin
• Подбирайте действия, исходя из типа

Достаточность процесса

Ситуация

Всё по книжке:

• Есть Jira / стендапы / ретро

Но:

• На ретро люди говорят “всё норм”, а в курилке - что всё плохо
• Задачи берутся, но никто не предупреждает, когда что-то идёт не так
• Тимлид уходит в отпуск - и команда встаёт

Проблема в доверии

Люди не доверяют друг другу и системе достаточно, чтобы эти процессы работали

Культура

Команда

Команда - это группа необходимых для решения задачи людей, организованная для совместной работы, имеющая единое видение для достижения общей цели, способная работать вместе и разделять ответственность за результа

Основное:

• Группа людей
• Есть правила работы
• Есть общая цель
• Есть зоны ответственности
• Есть роли
• Есть личная и коллективная ответственность
• Есть самостоятельность в работе

Культура

Культура - это объединяющий слой

• Культура - это не плакаты на стене и не корпоративные ценности в презентации
• Культура - это то, что происходит, когда никто не смотрит

Источники культуры

Культура от руководителя

• Есть процесс: на ретро любой может поднять любую проблему
• На ретро: разработчик поднял проблему
• Тимлид отвечает: «Ты сам виноват, надо было раньше говорить»

Всё - больше никто ничего не поднимает. Процесс есть, культура его убила

Культура от подчинённых

• Есть процесс: на ретро любой может поднять любую проблему
• На ретро: разработчик поднял проблему, но говорит, что все кругом виноваты, а он - нет
• Тимлид молчит

Команда взяла культуру в свои руки. Культура есть всегда. Но не всегда ей управляем мы

Культура идет от доверия

• В системе происходит проблема - ошибка на проде
• Ошибка случилась после релиза разработчика N

Недоверие:

• отчитать прилюдно разработчика N
• лишить его премии
• запретить разработчикам самостоятельно релизить
• забрать на себя ключевые решения по code review

Лидерство:

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

• Культура - это среда
• Хорошие процессы в плохой среде не работают
• Плохие процессы в хорошей среде - исправляются или уходят

Культура складывается каждый день

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

Составляющие культуры

Реакция на ошибки

• Неважно, почему «нет»; важно - что сделано, чтобы было «да»
• Почему так получилось? Руководитель ответственен за ошибки команды
• Ругай лично, хвали публично

Обратная связь

• Вы даете фидбэк, когда что-то сломалось?
• Вы даете фидбэк, потому что человек решил уходить?
• Вы даете фидбэк, потому что надо?

Что замечаете?

• Вы реагируете только на косяки?
• Вы реагируете только на то, что метрика упала?

Команда быстро оптимизируется по параметру «закрыть метрику», а не «сделать качественно»

За что хвалите

• За результат или поведение?

«Молодец, задача сдана» vs «Молодец, что предупредил заранее о риске»

Поведение в стрессе

• Когда горит дедлайн, вы становитесь резким и начинаете микроменеджить?

Команда лучше запоминает стрессовые моменты, чем спокойные

Формируем культуру явно

• Типовая ошибка: формировать культуру случайно, реагировать, как придётся
• Осознанность - понимание в любой момент времени, какой сигнал вы посылаете каждым действием

То, что очевидно тебе, неочевидно другим:

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

Начинать ретро с позитива:

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

Это ритуал, который меняет фокус внимания

Действия должны быть последовательны:

• Если вы один раз сказали «у нас открытая культура», а потом отчитали человека за неудобный вопрос - это конец
• Доверие строится годами, разрушается одним эпизодом
• Важна не только декларация, но и паттерн поведения

Стиль общения

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

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

Не регламенты, не орг-структура, а то, как вы разговариваете с людьми каждый день

Общение - это не просто фраза

Составляющие коммуникации:

• Информация
  • Что мы хотим передать партнеру
• Взаимоотношения
  • Формализованность отношений
  • Уровень близости
• Контекст
  • Ситуация
  • Способ донесения
• Обратная связь
  • Информация → Подтверждение о принятии → Действие

Люди (и вы тоже) имеют право на любую реакцию:

• сказать «нет»
• не объяснять причин
• прервать разговор
• изменить мнение
• совершить ошибку

Базовые правила коммуникации

1. Подготовка к коммуникации
   1. Структурированность информации
   2. Единое понятийное пространство
   3. Понимание уровня взаимоотношений
2. Ключевое условие
   1. Информация должна быть воспринята
3. Конструктивная подача
   1. Своевременность
   2. Адресность
   3. Факты и данные
   4. Решение проблем, а не человека

Стили коммуникации

Директивный стиль

• Люди перестают думать сами
• Ждут указаний
• Перестают предупреждать о проблемах - ведь это значит признать неудачу

Warning

• «Саша, сделай вот это так»
• «Почему ещё не готово?»
• «Я уже сказал как надо делать»

Коучинговый стиль

Люди берут ответственность, думают, предлагают, предупреждают

Success

• «Саша, как ты думаешь, какой подход здесь лучше?»
• «Что мешает двигаться быстрее?»
• «Что тебе нужно, чтобы решить это самому?»

Выбор стиля

• Коучинговый стиль не значит “всё решаем консенсусом”
• В кризис, когда нет времени - директива нормальна
• Но как режим по-умолчанию он убивает команду

Личные разговоры

• Культура идет от доверия
• Неотъемлемая часть доверия - возможность лично обсудить проблему

1-1

1-1 - это не статус по задачам:

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

Первое правило бойцовского клуба 1-1: Все, что сказано на этой встрече, не будет вынесено за её пределы без явного обозначения и согласия сторон

Пример

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

Аня не скажет об этом на daily. Аня скажет об этом заявлением по собственному

Что можно узнать на 1-1?

• Кто устал и почему
• Где есть скрытый конфликт внутри команды
• Кто чувствует себя недооценённым
• Какие процессы раздражают, но никто не говорит об этом публично
• Что мотивирует человека прямо сейчас

Как узнать?

• 0 минут раз в неделю лучше, чем час раз в месяц
• Доверие строится на регулярности, а не на длине
• И никогда не отменяйте 1-1 первым - это сигнал «ты не в приоритете»

«Не о чем говорить» - это симптом, а не норма

1. Встреча превратилась в статус по задачам
   1. Если каждый раз говорите только о работе - темы быстро иссякают. Переключитесь на человека: как он себя чувствует, что его заряжает, что раздражает, куда хочет расти
2. Человек не доверяет достаточно, чтобы говорить честно
   1. Молчание на 1-1 часто значит «я не уверен, что это безопасно». Особенно в начале
   2. Решение - задавать вопросы самому и не реагировать негативно на то, что слышите
   3. Доверие появляется после 3-5 встреч, не сразу
3. Встречи слишком редкие
   1. Если 1-1 раз в месяц - между ними накапливается столько, что непонятно с чего начать
   2. При еженедельных встречах темы появляются естественно

Банк вопросов

Про работу и команду:

• Что сейчас даётся труднее всего?
• Есть ли что-то, что тебя тормозит и что я мог бы убрать?
• Что в последнее время было особенно интересным?
• Есть ли кто-то в команде, с кем сложно работать? Почему?

Про рост:

• Чему ты хочешь научиться в ближайшие полгода?
• Что ты делаешь сейчас, что тебе не нравится делать?
• Где ты чувствуешь, что растёшь? Где - нет?

Про меня как тимлида:

• Что я мог бы делать иначе, чтобы тебе было проще работать?
• Есть ли что-то, что я делаю и что мешает тебе?
• Ты получаешь достаточно обратной связи от меня?

«Философские» - для более зрелых отношений:

• Если бы ты мог изменить одну вещь в команде - что бы это было?
• Что тебя держит в этой компании прямо сейчас?
• Что должно произойти, чтобы через год ты сказал «это был лучший год в карьере»?

Практика

Подготовка

Попросите сотрудника до следующей 1-1 записать одну вещь из каждой категории:

• что шло хорошо
• что было сложно
• что хочу обсудить с тимлидом

В разговоре

Идем от сотрудника

• Начинайте так: «Что хочешь обсудить сегодня?». Если человек говорит «не знаю» - у вас есть список своих вопросов
• Но сначала дайте ему пространство

Фиксация

Создайте файл, куда в течение периода вы и сотрудник сбрасываете вопросы, которые хотели бы обсудить

• не забудете
• будет возможность подготовиться

Не статусы

Если весь разговор про задачи - вы проводите второй стендап

Спрашивайте про человека:

• как он
• что его мотивирует
• что его тормозит
• чему хочет научиться

Открытые вопросы:

• «Что сейчас самое сложное в работе?»
• «Если бы ты мог изменить одну вещь в команде - что бы это было?»
• «Что тебе мешает работать лучше?»
• «Как ты себя чувствуешь в последнее время?»

Договорённости

• В общем документе после каждого 1-1 фиксируйте, кто что должен сделать
• Начинайте следующую встречу с: «В прошлый раз ты говорил X - как с этим сейчас?»

Это показывает, что вы слышали и помните

Командные мероприятия

Тимбилдинг

Главная ошибка:

Считать, что тимбилдинг раз в квартал заменяет ежедневную культуру

Совместный поход в караоке - круто, но работает далеко не всегда

Что работает:

• Хакатон или воркшоп: люди решают реальную задачу вместе, видят друг друга в деле, возникает уважение и доверие
• Неформальный обед/выезд без повестки: за едой люди говорят о жизни, а не о задачах - это сближает
• Честное ретро или «прожарка»: когда люди могут сказать «мне было тяжело» - это создаёт близость

Что не работает:

• Принудительный боулинг: Если половина команды интроверты - они страдают, но улыбаются. Эффект обратный.
• Корпоратив раз в год: Люди напиваются, танцуют, а в понедельник всё как было. Культура не живёт в одном событии
• Мероприятия без учёта людей: Спросите команду: что вы хотите делать вместе? Может, они хотят просто поиграть в настолки или сходить на квиз, а не в верёвочный парк

Итоги:

• Маленькие регулярные контакты важнее больших редких событий
• Пятнадцать минут после стендапа поговорить ни о чём - это тоже культура

Итог

1. Культура формируется годами
2. Культура есть всегда, но не всегда её контролируем мы
3. Стремимся к коучинговому стилю, но не забываем про директивы
4. 1-1 - регулярная встреча, но не для статусов по задачам
5. Тимбилдинг идет от команды, а не от необходимости его провести

---

[Не заполнен] Как нанимать и кому отказывать

---

[Прогресс] Онбординг и оффбординг

Какие задачи давать сотруднику после найма Тонкости испытательного срока или продолжение собеседования на практике План работ на 1, 2 и 3 месяца: что в него должно входить Допустимая продолжительность испытательного срока Как сделать плавный, но быстрый онбординг в продукт Как познакомить человека с командой, чтобы он быстро влился и не чувствовал смущения Начало самостоятельной деятельности Завершение испытательного срока Как подготовиться к увольнению сотрудника с первого дня работы, и зачем это нужно делать Набрался опыта и увольняется — как наладить процесс передачи экспертизы всей команде Как подготовить человека к выходу Как подготовить команду к выходу человека из нее

Найм

Найм - это лишь половина работы

Риски испытательного срока:

• 20% новых сотрудников уходят в первые 45 дней
• Стоимость замены сотрудника = 50–200% его годовой зарплаты (SHRM)

Ранний уход = дорогая ошибка

Почему люди уходят с ИС:

• Хаос
• Отсутствие плана
• Ощущение брошенности
• Несоответствие ожиданиям

Мысли новичка

1. Кто все эти люди?
   1. Зачем они здесь?
   2. Где кого найти?
   3. Кто здесь главный?
2. К кому обращаться, если…?
   1. Какие вообще правила игры?
   2. Когда мне ответят на мои вопросы?
   3. Нужно ли соблюдать субординацию?
   4. Я угадал?
3. Документация у вас есть?
   1. Что делать если нет?
   2. Где и как искать?
   3. А почему написано так, а я вижу другое?
4. Что означают эти буковки?
   1. FTE или ПШЕ?
   2. Всегда ли git flow - это git flow?
   3. А что у вас за скрам такой?
5. А че по ландшафту?
   1. Где описание архитектуру?
   2. С чего начать смотреть?
6. Зачем я здесь? Хочу ли здесь работать?

Проблемы

Проблема

• Огромный объем новой информации
• Невозможность обработать весь массив информации

Результат

• Стресс / паника
• Ошибки приоритизации
• Защитная реакция - сужение поля зрения
• Или решение уйти

Испытательный срок (ИС)

ИС - это не формальность, а двусторонняя проверка:

• компания смотрит на человека
• человек смотрит на компанию

В эту игру нужно играть вдвоём:

• Ожидания - договор, а не угроза
• На страте работы при первом же 1-1 нужно обозначить, что вы ждёте друг от друга
• Сотрудник должен с первого дня понимать критерии успеха

Пример плана ожиданий, который можно составить:

Задача	Описание	Критерии
Технические скилы
Работа с техническими решениями	Нужно усилить проработку архитектурных задач	1. Написаны минимум три TDR/Outline до конца года 2. Написание должно быть максимально самостоятельным (нужен отзыв) 3. Решения запущены в срок в соответствии с планом из Outline
Менеджерская работа
Горизонт планирования до года	Нужно сформировать роадмап на год	Есть план работ и роадмап с горизонтом в год
Цель команды	Каждая команда имеет понятные всем цели существования	Цели донесены до команды и понятны всем (отзывы от команды)
Работа с командой
Wellbeing	Показатели по командам в зеленой зоне	mNPS, eNPS
Операционка		Agile метрики
Perf Review	Пройти зимний перф, подготовив	Успешная самостоятельная защита
	Проработать развитие в M2	1. Разработан ИПР 2. Определены сроки промо 3. Выработан план роста по кварталам
Управление командой matching	Прямое управление командой	К метрикам опер ревью добавляем attrition rate
	Развитие преемника	Выработан ИПР для преемника
Отделить команды в операционном стриме	Команда должна отделиться от стрима	1. Выработать совместно с продактом точку разделения на базе продуктового плана 2. Согласовать и провести отделение в 2026
Карта компетенций	Сформировать карту развития компетенций для команд	Сформирована карта Есть факты промо
Увольнения	Получить опыт увольнения low перформеров	Если в команде будут факты низкой производительности, вовремя расстаться
TMM	Регулярная работа с TMM команд	TMM команд в технических областях не ниже 70%
Софт скилы
Донесение информации	Структурировать общение: 1. думать, кому, что и когда говоришь 2. говорить структурно, а не потоком 3. проработать общение с коучем 4. поддерживать прогресс в работе с руководителем	Продакты дают положительную обратную связь

Обратная связь:

• 1-1 каждую неделю
• Не нужно ждать конца ИС, понедельника или падающей звезды
• Если есть проблема - говорим сразу и без экивоков

---

Как правильно увольнять

---

[Видео] Как разрешать конфликты в команде (воркшоп)

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

Определения

• Мы все - индивидуумы
• Наши мнения не могут совпадать постоянно

Конфликт — это ситуация, в которой каждая из сторон занимает позицию, несовместимую и противоположную по отношению к интересам другой стороны

Не подразумевает ссору по умолчанию. Это просто столкновение двух интересов

Девиантное поведение - cовершение поступков, которые противоречат нормам социального поведения в том или ином сообществе

Пример

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

Когда здесь будет конфликт, а когда — девиация?

Классификация конфликтов

Причины конфликтов

1. Распределение ресурсов
2. Взаимозависимость задач
3. Различия в целях
4. Различия в способах достижения целей
5. Проблемы с коммуникациями
6. Различия в психологических особенностях
7. Недопонимание
8. Эмоции
9. Различия в ценностях
10. Конфликтный человек
11. Ваш вариант

Виды конфликтов

• По действию на работу команды / организации
  • конструктивные
  • деструктивные
• По содержанию
  • предметные
  • ценностные
  • беспредметные
• По характеру участников
  • внутриличностные
  • межличностные
  • между личностью и группой
  • межгрупповые
• По направленности
  • горизонтальные
  • вертикальные
  • смешанные

Вредность конфликтов

Деструктивный конфликт

Атака на личность, эмоции управляют ситуацией, нет движения к решению

Конструктивный конфликт

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

Отсутствие конфликта - чаще всего сигнал страха или равнодушия

Эскалация конфликта

• Гармония
• Конструктивный конфликт - самый лучший вариант
• Холодная война
• Борьба
• Война

Кейс: лечим диалог

Некорретный вариант:

• Тимлид: Ты вечно сдаёшь задачи в последний момент, команда из-за тебя горит
• Разработчик: Ну и что, зато я их сдаю. У других вообще баги в проде
• Тимлид: Ты вообще себя слышишь? Типичная отмазка

Корректный вариант:

• Тимлид:
• Разработчик:
• Тимлид:

Пороки команд

Пять пороков команды

• Автор: Патрик Ленсиони
• Формат: бизнес-роман
• Модель: пирамида причинно-следственных связей

Каждый порок вырастает из предыдущего - Это не список независимых проблем - это цепочка

Умные и мотивированные ≠ эффективная команда - Не по злому умыслу, а потому что не выстроены правильные условия

Ленсиони говорит не о плохих людях, а о плохой динамике

Пирамида пороков:

1. Недоверие
   1. Перед коллегами не извиняются
   2. Ошибки не признаются
   3. Жизнью коллег не интересуются
2. Боязнь конфликтов
   1. Проблемы не обсуждаются открыто
   2. На совещании скучно
   3. Решения принимаются формально
3. Безответственность
   1. Не интересны задачи коллег
   2. Никто не помнит о целях
   3. Принятые решения не выполняются
4. Нетребовательность
   1. Отсутствие взаимной критики
   2. Несоблюдение сроков и обещаний
   3. Отсутствие взаимоконтроля
5. Безразличие к результату
   1. Жертвы ради команды невозможны
   2. Атмосфера не зависит от результатов
   3. Успехи коллег не радуют

Кейсы

1. Команда приняла решение использовать новый стек Через неделю выясняется, что двое разработчиков продолжают писать на старом — «мы не были уверены, что решение окончательное»
2. Тимлид добивается высоких метрик своей команды Даже если это требует перетягивания ресурсов с соседней… На общих OKR это не отражается — у него всё зелёное

Решения

Порок	Решение
Недоверие	Не скрываем слабости и ошибки, обсуждаем любые вопросы
Боязнь конфликтов	Стремимся к конструктивным конфликтам
Безответственность	Ответственность на команде, взаимоконтроль
Нетребовательность	Требовательность к себе и коллегам
Безразличие к результату	Общая цель

Контроль конфликта

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

Методы управления конфликтами:

• структурные и организиционные
• коммуникационные и поведенческие

Коммуникационные методы

Уход от конфликта

• предмет разногласий не представляет большой ценности
• есть способ достичь цели без конфликта
• конфликт сейчас не может быть разрешен
• конфликт беспредметный
• оппонент намного «сильнее»
• оппонент не адекватен

Не стоит применять при предметном конфликте

Уступчивость

• предмет разногласий не представляет большой ценности
• уступая в одном - выигрывает в другом
• отношения с оппонентом важнее предмета разногласий
• оппонент намного «сильнее»
• оппонент прав

Не стоит применять, если решение не приемлемо

Принуждение

• жизненно важное значение предмета разногласий
• беспроигрышная позиция

Не стоит применять, если это не вопрос жизни или смерти

Компромисс

• хорошо понятны все «за» и «против»
• лучше синица в руках, чем журавль в небе
• нужно сберечь силы / отношения
• временное решение
• другие варианты не получились

Не стоит применять, если не исчерпаны другие варианты (половинчатость - источник новых конфликтов)

Сотрудничество

• проблема важна и мы готовы ее совместно решать
• найти взаимовыгодное
• партнерское решение
• «не ты против меня, а мы вместе против проблемы»

Самое идеальное решение

Девиации в поведении

Девиация - это систематическое отклонение поведения от норм команды или организации - это не конфликт

	Конфликт	Девиация
Природа	Событие / Столкновение	Паттерн / Привычка
Триггер	Конкретная ситуация	Размытый или отутствует
Видимость	Обычно заметен	Часто «фоновая»
Управление	Разрешение	Коррекция поведения

Примеры:

• хроническое опоздание на встречи
• игнор договорённостей о процессах (не ставит задачи в трекер)
• пассивная агрессия (“ну делайте как хотите”)
• “тихое увольнение” (quiet quitting)

Главная ошибка менеджера

Пытаться решить девиацию через конфликт

Это не работает, потому что у девиации, как правило, нет конкретного противника

Работа с девиациями

Амортизация

Не встречать агрессию в лоб, а “поглощать” её:

"Я слышу, что ты злишься. Давай разберём, что происходит"

Я-сообщение

Вместо ты-обвинения:

«Ты давишь на меня»

«Я чувствую давление, когда так говорят»

Пауза и переформулировка

Остановить накал:

«Давай я проверю, правильно ли я понял твою позицию...»

Кейс

На ретро участник говорит: “Да всё это бесполезно. Мы каждый раз обсуждаем одно и то же, ничего не меняется”

Манипуляция

Превращение логики в эмоцию

Вывод на лёгкую эмоцию

Вывод на тяжёлую эмоцию

• Самоидентификация
• Ценности
• Социальные установки
• Опыт, знания

Минусы манипуляций:

Кейс	Описание
Не работают вдолгую	Эмоция живет в организме 10-12 минут
Сжигают «карму»	Люди забудут, что вы делали, но запомнят, что они чувствовали по отношению к вам
«Карма» накапливается	Договариваться и решать проблемы будет сложнее и сложнее

Как выглядит Конструктивная конфронтация

Принципы конструктивизма:

1. Своевременность
2. Адресность
3. Данные и факты
4. Фокус на проблеме

Конфликт как ресурс развития

Вспомните конфликт, который в итоге дал что-то хорошее команде Что именно изменилось?

Что должно быть «встроено» в команду, чтобы конфликты работали на рост, а не на разрушение?

Что, если конфликт - это не проблема, которую нужно решить? Мы говорили о том, как работать с конфликтом, как его переводить в конструктив, как нивелировать агрессию. Это важно.

Но есть и другой угол зрения. Конфликт - это сигнал. И как любой сигнал, он несёт информацию, которой без него не было бы

Конфликт - это диагностика:

• Узкие места в процессах - если конфликт повторяется по одному и тому же поводу, проблема не в людях
• Несовпадение ожиданий - чаще всего конфликт означает, что люди имели в виду разное, не договорившись
• Зоны ответственности без хозяина - конфликты на стыке ролей почти всегда указывают на дыру в структуре

Кейс

Когда два разработчика спорят, кто должен писать тесты - это не конфликт личностей

Это сигнал, что в команде нет договорённости об ответственности за качество

Конфликт сделал проблему видимой. Без него она бы продолжала тлеть

Пережитый конфликт - это инвестиция в доверие:

• Команды, которые никогда не конфликтуют, часто доверяют друг другу меньше, чем те, которые прошли через жёсткое, но честное столкновение
• В конфликте люди узнают, как другой человек ведёт себя в стрессе, насколько он честен, умеет ли он слышать

Команды, которые умеют конфликтовать, принимают лучшие решения:

• Больше точек зрения - конфликт означает, что кто-то видит иначе. Это ресурс, а не помеха
• Меньше группового мышления - когда несогласие нормализовано, люди не соглашаются только ради мира
• Выше качество договорённостей - решение, прошедшее через честное столкновение позиций, устойчивее

Итог

Конфликт - это не то, чего нужно избегать. Это то, чему нужно учиться

• Конфликт без культуры - разрушение
• Конфликт с культурой - развитие
• Задача лидера - создать культуру
• Задача команды - ею пользоваться

Мы разобрали много инструментов, Но всё это работает только если есть договорённость: у нас можно не соглашаться. И это не слабость, это зрелость команды

---

Как принимать решения без последствий для других и презентовать их стейкхолдерам

---

Best practices по декомпозиции задач

---

[Видео] Метрики разработки

Визуальные эффекты

Мы не управляем тем, что не измеряем

Без приборов ты едешь вслепую и очень быстро схватишь штраф или останешься без топлива

Нужно точно задать себе вопрос: а эффективна ли наша команда?

Тимлид как предприниматель

Команда - это руки тимлида. Команда - это бизнес тимлида.

• Предприниматель не может вести бизнес без P&L, конверсий, CAC и LTV
• Тимлид не может вести команду без понимания, что работает, а что нет
• Разница: предприниматель теряет деньги, тимлид теряет время, качество и людей

«Оцифровка»- это не бюрократия. Это способность принимать решения на основе фактов, а не интуиции

Любая фича, любое действие должно приносить пользу

Без метрик ты не знаешь - приносится польза или нет

Если прилетает предложение, что “нам нужно провести рефакторинг”, то нужно понять:

• Что болит?
• Как это выражается в цифрах?
• Сколько времени (денег) будет проинвестировано?
• Что мы получим?
• Как мы поймем, что успех случился?

«Но ведь это же люди, а не механизмы!»

• Метрики созданы не для контроля
• Метрики созданы для понимания

Метрики

Что метрики дают тимлиду

• Диагностика
  • Что сейчас происходит в команде?
  • Где узкое место?
  • Почему фичи не едут?
• Разговор со стейкхолдерами
  • Как обосновать инвестиции в рефакторинг?
  • Почему в команде нужен ещё один разработчик?
  • Цифры убеждают там, где слова не работают
• Ретроспектива
  • Стало ли лучше после изменения процесса?
  • Окупился ли технический долг, который мы починили в прошлом квартале?

Что метрики НЕ делают

• Метрики - не полиграф и не KPI для штрафов
  • Метрики не отвечают на вопрос “Кто виноват” - они отвечают на “Что происходит”
  • Метрики не заменяют разговоры. Они дают тему для разговора
  • Метрики не мотивируют - они информируют. Мотивирует контекст и признание
  • Закон Гудхарта: “Когда метрика становится целью, она перестаёт быть хорошей метрикой”
• Метрики легко обмануть:
  • Если начать мерить количество строк кода → разработчики напишут больше кода
  • Если мерить количество закрытых тикетов → будут дробить задачи

Метрика меняет поведение. Всегда

Что можно мерять

• Бизнес и продукт
  • метрики, которые видит сейкхолдер
  • Revenue, Retention, DAU, NPS
• Команда и процессы
  • Метрики, которые видит тимлид
  • Velocity, Cycle Time, Lead Time
• Техническое качество
  • Метрики, которые видит инженер
  • Покрытие тестами, tech debt, MTTR

Тимлид - тот, кто должен понимать все три уровня и уметь переводить идеи между ними

DORA

DORA - это не набор KPI. Это диагностический инструмент

Метрика	Что измеряет	Элитный уровень
Deployment Frequency	Как часто команда деплоит в прод	Несколько раз в день
Lead Time for Changes	От коммита до прода	Меньше часа
Change Failure Rate	Процент деплоев, вызвавших инцидент	0–15%
MTTR (Mean Time to Restore)	Время восстановления после сбоя	Меньше часа

Google DevOps Research and Assessment (книга Accelerate, Форсгрен, Хамбл, Ким)

Если Lead Time - 3 недели, это не “плохой разработчик”, а сигнал: что‑то в цепочке сломано:

• процесс ревью
• деплой
• тестирование

SRE

Site Reliability Engineering - Надёжность систем должна обеспечиваться инженерными методами, а не героизмом дежурных

SRE-подход, разработан в Google в 2003 году Беном Трейнором

• Даже если в команде нет выделенного SRE - ответственность за надёжность лежит на Тимлиде
• SRE-метрики - это язык, на котором говорят с бизнесом о рисках:
  • Без этих метрик разговор о надёжности звучит как “нам нужно лучше тестировать”
  • С ними - “наш Error Budget исчерпан на 80%, следующий деплой несёт риск нарушить SLA”

SRE считается по трём метрикам:

Метрика	На что отвечает	Чем является	Примеры
SLI	что измеряем?	это конкретная метрика, которую вы измеряете	1. Доля успешных запросов (Success Rate) 2. Latency p99 3. Доступность (Uptime)
SLO	что обещаем себе?	это цель, которую вы ставите себе на основе SLI	1. Success Rate ≥ 99.5% 2. p99 latency < 300ms 3. Uptime ≥ 99.9% в месяц
SLA	что обещаем клиенту?	это формальное обязательство перед клиентом / бизнесом	1. Компенсация клиентам при uptime < 99.5% 2. Гарантированное время ответа поддержки

Нарушение SLA = финансовые или репутационные последствия

Правило:

• SLO всегда строже SLA. Если SLA = 99.5%, ваш SLO = 99.7%
• Это буфер, который даёт время реагировать до того, как нарушится договор с клиентом

Частая ошибка:

Команды думают, что SLA — это «чужое», для юристов и продаж

На самом деле:

Именно инженерная команда определяет, что реально достижимо

Error Budget: надёжность как ресурс

Если SLO = 99.9% uptime в месяц, значит допустимое время недоступности:

0.1% × 30 дней × × 24 часа = 43 мин/месяц

Это и есть Error Budget - бюджет на ошибки

SLO	Допустимый downtime / месяц
99%	~ 7 часов 18 минут
99.5%	~ 3 часа 36 минут
99.9%	~ 43 минуты
99.95%	~ 21 минута
99.99%	~ 4 минуты

Как использовать Error Budget:

• Бюджет тратится на каждый инцидент и каждый рискованный деплой
• Если бюджет исчерпан → команда замораживает новые деплои и фокусируется на надёжности
• Если бюджет в норме → можно двигаться быстрее, деплоить чаще, экспериментировать

Вместо “Нам нельзя деплоить по пятницам” → “Наш Error Budget позволяет ещё 2 деплоя высокого риска в этом месяце. Пятница - наш выбор, не запрет”

TOIL

TOIL - это ручная, повторяющаяся, автоматизируемая работа, которая не несёт долгосрочной ценности и растёт пропорционально нагрузке на систему

• Ручной деплой по чеклисту из 20 шагов
• Перезапуск сервиса при каждом spike нагрузки вручную
• Ежедневная проверка логов глазами
• Ручное заведение тикетов по алертам
• Добавление нового клиента через SQL-скрипт вместо UI

Метрика: % времени команды на Toil

Рекомендация Google:

• Не более 50 % рабочего времени SRE должно уходить на Toil
• Остальное - инженерная работа по устранению его источников

Для тимлида: Если команда тратит >30% времени на Toil - это сигнал к автоматизации, а не к расширению штата

Alerting Quality: метрика метрик

Проблема Alert Fatigue:

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

Если алертов слишком много - они перестают работать

Метрика	Описание	Норма
Alert-to-Incident Ratio	Сколько алертов приходится на один реальный инцидент	Близко к 1:1
False Positive Rate	Процент алертов, которые не требовали действий	< 10%
MTTD (Mean Time to Detect)	Среднее время обнаружения инцидента	Зависит от SLO
Actionability Rate	Процент алертов, по которым инженер реально что-то сделал	> 90%

Принцип хорошего алерта

Каждый алерт должен требовать немедленного человеческого действия. Если алерт можно проигнорировать → его не должно быть

Практика:

Раз в квартал проводить “Alert Audit”: пройтись по всем алертам и задать вопрос - “Что инженер должен сделать, получив этот алерт?” Если ответа нет → алерт удаляется или переводится в лог

Что такое хорошо? Как измерить техническое качество, а не количество падений?

Выбор метрик

Уровень продукта	Метрики
Стартап, early stage	TTM, retention первых пользователей
Продуктовая команда (growth)	Conversion rate, DAU/MAU, feature adoption, SLI
Platform / инфраструктура	MTTR, uptime, deployment frequency
Аутсорс / проектная работа	Velocity, budget burn rate, scope creep
Legacy-продукт	Tech debt coverage, MTTR, regression rate

Метрики должны отвечать на реальный вопрос, который сейчас стоит перед командой: Не "какие метрики правильные", а "что нам сейчас важно понять"

Продуктовые метрики для тимлида

Тимлид без продуктового мышления - исполнитель чужих решений

• Разработка - не самоцель. Каждая фича должна двигать продуктовую метрику
• Если тимлид не понимает, зачем делается фича - он не может приоритизировать, оценивать и защищать команду от scope drop
• Тимлид, который говорит на языке метрик - равный партнёр для Product Manager, а не подрядчик

Acquisition & Activation

Воронка: как пользователь попадает в продукт

Acquisition - привлечение

• CAC
  • Customer Acquisition Cost
  • Стоимость привлечения одного пользователя
• Traffic sources
  • Откуда приходят пользователи

Зачем тимлиду: Понять, каких пользователей ждать, какую нагрузку планировать

Activation - активация

• Activation Rate
  • Процент пользователей, совершивших ключевое действие: регистрация, первый заказ, первое сообщение
• Time to first value
  • Время от регистрации до «aha-момента»

Зачем тимлиду: Фичи онбординга, скорость загрузки, UX первого экрана - это напрямую влияет на эту метрику

Retention & Revenue

Остаются ли? Платят ли?

Retention - удержание

• DAU / MAU
  • Daily / Monthly Active Users
  • Соотношение DAU/MAU (Stickiness) — насколько продукт входит в привычку
• Churn Rate
  • Процент пользователей, прекративших использование
• Retention Curve
  • Как быстро уходят новые пользователи (D1, D7, D30)

Зачем тимлиду: Производительность, надёжность, UX - основные причины раннего churn

Revenue - выручка

• MRR / ARR
  • Monthly / Annual Recurring Avenue
• LTV (Lifetime Value)
  • Сколько денег приносит пользователь за всё время
• LTV / CAC
  • Ключевое соотношение: бизнес устойчив, если LTV > 3xCAC

Зачем тимлиду: Понимать, кто платит и за что, чтобы не убить монетизацию случайным изменением

NPS (Net Promoter Score)

Один вопрос: “Насколько вероятно, что вы порекомендуете продукт?” (0-10)

Формула:

Promoters (9-10) минус Detractors (0-6) = NPS

Бенчмарк для IT-продуктов: NPS выше 30 - хорошо, выше 50 - отлично

Связь с разработкой:

• Низкий NPS после деплоя → сигнал о деградации UX или производительности
• Отзывы в App Store / Google Play → незаслуженно игнорируемый источник багов
• Feature requests в поддержке → приоритизация бэклога

Метрики перформанса команды

Velocity

• Это количество story points (или задач), закрытых за спринт
• Используется для планирования: если средняя velocity - 40 points, значит планируем ~ 40 на следующий спринт

Cамая популярная и самая неправильно используемая метрика

Velocity - метрика для команды, не для менеджмента

• Story points - относительные оценки внутри команды.
• Сравнивать velocity двух команд бессмысленно Рост velocity не означает рост ценности. Можно быстрее делать не то
• Давление на velocity ломает оценки: разработчики начинают накручивать points

Правильное использование Velocity:

• Отслеживать тренд внутри одной команды за 6-8 спринтов
• Замечать аномалии (резкое падение - что случилось?)
• Использовать для планирования, не для оценки людей

Cycle Time и Lead Time

• Cycle Time
  • Время от начала работы над задачей до её готовности
  • Замедляет: блокеры, ожидание ревью, зависимости
• Lead Time
  • Время от появления идеи / запроса до деплоя
  • Замедляет: приоритизация, очередь бэклога, согласования

Зачем мерить:

• Cycle Time > 3–4 дней на небольшую задачу → сигнал о процессных блокерах
• Lead Time > 2–3 недель → сигнал об узком месте в приоритизации или деплое

Throughput

Throughput - это количество задач (или фич), завершённых за единицу времени (неделю, спринт)

В отличие от Velocity:

• не зависит от оценок,
• считается по фактическому результату

Work in Progress (WIP)

Измеряется количество задач одновременно “в работе”

Cycle Time = WIP / Throughput

Рост WIP → рост Cycle Time → падение скорости всей команды

Метрики здоровья команды

Перформанс команды - это не только скорость

Проблема

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

Решение

Метрики здоровья → ранние индикаторы

Метрика	Как собирать	Сигнал тревоги
eNPS (Employee NPS)	Квартальный опрос	Ниже 20
Turnover Rate	HR-данные	Выше 15% в год
Participation in 1-on-1	Ведёт ли человек записи, приходит ли	Нет повестки, пропуски
Sick days / unplanned absence	HR	Резкий рост
PR Review Time	GitHub / GitLab	Больше 2 рабочих дней

Как не превратить метрики в слежку

Метрики команды - для команды, а не против неё

Принципы безопасного использования

• Метрики агрегированы на уровне команды, не на уровне человека (кроме специальных случаев)
• Команда сама видит свои метрики - не только менеджер
• Обсуждение метрик происходит на ретро, а не на “разборе полётов”
• Падение метрики - повод для совместного анализа причин, не для назначения виновных

Пример правильного разговора: “Наш Cycle Time вырос с 3 до 6 дней за последний месяц Что изменилось? Давайте посмотрим вместе”

Здоровье команды

Метрики технического качества

Tech Debt - не просто “плохой код” Технический долг - накопленные решения, которые были быстрыми тогда, но теперь замедляют разработку и увеличивают риски

Инструмент / метрика	Что показывает
SonarQube / CodeClimate	Количество code smells, дублирование, сложность
Cognitive Complexity	Насколько сложно читать и понимать код
Age of oldest TODO / FIXME	Насколько давние «временные решения» висят в коде
Dependency staleness	Как устарели зависимости (npm audit, pip-outdated)
Время на новую фичу в проблемной области	Косвенный показатель: если задача в модуле X занимает в 3 раза дольше нормы

Покрытие тестами и стабильность

Тесты - это страховка. Страховка должна покрывать риски

• Test Coverage:
  • Процент кода, покрытого тестами
  • Бенчмарк: 70-80% - разумный уровень для большинства продуктов
  • Важно: 80% coverage не означает «всё важное покрыто».
  • Coverage по строкам ≠ coverage по бизнес-сценариям
• Flakiness Rate:
  • Процент тестов, которые иногда падают без изменений в коде
  • Flaky tests - самый дорогой вид технического долга: убивают доверие к CI/CD
  • Цель: 0% flakiness. Даже 5% flaky тестов парализуют пайплайн
• Regression Rate:
  • Процент деплоев, после которых появляются регрессии
  • Связь с DORA: высокий Change Failure Rate часто объясняется низким качеством тестов

Производительность системы как метрика качества:

• Cвязь с продуктом:
  • Amazon: +100ms latency → -1% revenue
  • Google: если страница грузится > 3 сек, 53% мобильных пользователей уходит
• Культура постмортема:
  • Каждый серьёзный инцидент - повод для blameless postmortem
  • Вопрос не «кто виноват», а «что в системе позволило этому случиться»
  • Метрики инцидентов должны улучшаться со временем - это признак зрелости команды

Ловушки и антипаттерны

Goodhart’s Law на практике

Метрика, ставшая целью, перестаёт быть метрикой

Метрика	Что происходит, когда она становится целью
Velocity (story points)	Разработчики завышают оценки
Количество закрытых тикетов	Задачи дробятся на микро-части
Test Coverage %	Тесты пишутся ради строк, а не ради смысла
Commits per day	Атомарные коммиты из одной строки
Lines of code	Раздутый, нечитаемый код

Решение:

Использовать несколько метрик одновременно. Манипулировать одной сложно - манипулировать пятью одновременно почти невозможно

Топ антипаттернов в рабте с метриками

Метрики без контекста

Cycle Time вырос на 40% - это плохо?

Зависит от того, что изменилось:

• увеличилась сложность задач
• добавился новый тип работы
• заболел ключевой разработчик

Измерять всё сразу

10 метрик, за которыми никто не следит - хуже, чем 3 метрики, которые реально обсуждаются каждую неделю

Метрики только для отчётов

Если данные готовятся для стейкхолдеров, но не используются самой командой - это не инструмент управления, это витрина

Сравнивать команды между собой

• разный контекст
• разная зрелость
• разные задачи

Сравнение демотивирует и не даёт полезной информации

Игнорировать качественные сигналы

Цифры фиксируют прошлое:

• 1-on-1
• ретроспектива
• наблюдение

→ ловят сигналы раньше, чем они проявятся в метриках

min жизнеспособный дашборд

Не нужно строить NASA. Нужно начать с трёх цифр

Уровень	Метрика	Где взять
Продукт	Retention D30 или ключевая конверсия	PM / аналитика
Команда	Cycle Time последних 20 задач	Jira / Linear / Trello
Технический	MTTR за последний квартал	Incident log / PagerDuty

Правило:

• Одна метрика на каждый уровень
• Смотреть на тренд, а не на абсолютное значение
• Обсуждать на ретро раз в 2 недели

Итоги

1. Тимлид - предприниматель. Команда без оцифровки - бизнес без P&L
2. Метрики бывают трёх уровней: продуктовые, командные, технические. Тимлид читает все три
3. DORA-метрики - универсальная точка отсчёта для зрелости DevOps-процессов
4. Velocity - для планирования, Cycle Time - для диагностики. Не путайте
5. Закон Гудхарта работает всегда: не давайте метрике стать целью
6. Начните с трёх метрик. Лучше три живых, чем двадцать мёртвых