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

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

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

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

Junior
Middle
Senior
Предложение руководить → Перекос в менеджмент
Тимлид

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

Зачастую нет

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

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

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

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-лид, сеньор команды):
- Что я делаю хорошо стабильно?
- Где конкретно результаты хуже ожиданий?
Тест на повторяемость
- если проблема единичная или эмоциональная - это неуверенность
- Если системная и подтверждается метриками - это пробел

Выводы

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

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

Проблема

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

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

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

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

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

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

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

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

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

длится 30 мин - 2 часа

вход за 10–15 мин

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

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

Отвлекая человека, мы рушим его поток

Вход и перезагрузка контекста - минимум полчаса

Точно вопрос такой срочный, что не работает асинхронно?

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

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

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

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

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

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

Ложная многозадачность - это когда мы ухватились за всё, но ничего по-итогу не сделали.

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

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

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

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

Наполнение мозга

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

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

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

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

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

Книги

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

Самурайские приёмы

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

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

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

Примеры систем:

Автоматическая система

Когда мы идём по улице или водим машину - мы думаем о своём

Задача: Бита и мяч вместе стоят $1.10 иразницамеждуихценой$ 1. Сколько они стоят по-отдельности?

Сознательная система

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

Утечки “бензина”:

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

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

Наступает “Информационная паника”
- Мы нашли новый фреймворк, который стал популярным. У нас запустился процесс FOMO (fear of missing opportunities). Мы побежали его учить.
импульсивность и ошибки
Действия “по умолчанию” без размышлений

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

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

Режим Eco

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

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

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

Software as a memory

Obsidian
Todoist
Remember the milk

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

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

Книга

Дэвид Ален - Как привести дела в порядок. Искусство продуктивности без стресса. Она описывает техники пустого инбокса и списка задач. Краткое описание:

Нам прилетает задача и до тех пор, пока мы её не прочитаем, мы храним её в inbox.

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

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

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

Дано:

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

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

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

Список задач в табличке

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

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

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

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

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

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

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

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

Таймбоксинг

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

В сутках всего 24 часа. Работать каждый день по 16 часов не получится, так как 8 часов мы спим, тратим время на еду, на дорогу, на семью и имеем дополнительные пожинатели времени.

Важность

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

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

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

Люфт

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

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

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

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

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

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

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

Приоритеты

Правило трёх

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

А как же освободить ещё больше времени?

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

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

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

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

Японская техника "5 почему" позволяет дойти до реального ответа.

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

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

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

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

Задачи
Полномочия

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

Как делегировать:

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

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

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

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

Бояться, что ничего не сделают
Не возвращаться в срок
Не давать вводные
Задавать сроки директивно
Не отвечать на вопрос “Зачем?”

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

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

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

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

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

Задача
Ответственные
Статус
Приоритет
Дедлайны
Идеи
История

Инструменты

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. Декомпозиция задачи
Обновление информации
1. Постоянное обновление статуса (standups, встречи по планированию, и тд)
2. Своевременное обозначение проблем и обсуждение их решения
3. Бэкап исполнителей
Выдача результата
1. Анализ проблем проекта
2. Оценка производительности команды
3. Соответствие оценок команды и реальных показателей

Встречи

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

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

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

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

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

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

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

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

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

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

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

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

Кто виноват?

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

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

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

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

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

Принцип:

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

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

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

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

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

Например:

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

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

Ты проецируешь свою ясность на других

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

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

Кейс

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

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

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

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

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

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

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

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

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

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

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

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

Кейс

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

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

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

Что думаете?

Проблемы:

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

Принципы

SCQA

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

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

Пример:

Situation - команда сдаёт спринты на 60%
Complication - теряем 2 недели на переделки
Question - как ускорить delivery без выгорания?
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?

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

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

Шаблон elevator pitch

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

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

Пример:

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

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

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

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

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

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

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

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

Проблемы:

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

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

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

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

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

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

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

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

Поток мысли

Увидеть начало мысли и потом ждать, когда человек выдаст продолжение

Сжечь виброзвонок кучей мелких сообщений в 2-3 слова

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

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

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

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

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

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

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

Грубое общение

Фамильярности

Время переписки

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

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

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

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

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

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

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

Резюме:

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

Практика:

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

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

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

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

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

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

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

Команда

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

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

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

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

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

The 2 pizzas team

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

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

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

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

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

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

Плюсы:

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

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

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

Характерно:

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

Что делать:

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

Конфликт

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

Характерно:

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

Что делать:

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

Нормализация

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

Характерно:

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

Что делать:

Поддержать нормы, поощрять открытый диалог

Производительность

Команда работает эффективно и слаженно
Роли гибкие
- Участники самостоятельны, лидер может делегировать
Энергия направлена на задачу
- На выяснение отношений она не тратится. Не все группы достигают этого этапа

Характерно:

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

Что делать:

Давать сложные задачи
отмечать достижения

Завершение

Задача выполнена
- Группа прекращает существование
Рефлексия
- Участники переживают это по-разному: кто-то с удовлетворением, кто-то с сожалением или тревогой
Важно правильно “закрыть” команду
- Достижения и дать людям осмыслить опыт

Характерно:

подведение итогов
эмоциональное расставание
рефлексия

Модель Дрекслера-Сиббета

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

Модель Дрекслера–Сиббета (1988) создавалась как практический инструмент для консультантов и фасилитаторов. Алан Дрекслер и Дэвид Сиббет разрабатывали её в прикладном контексте организационного развития, и она изначально предназначалась для работы “в поле”

Такман
- Вопрос: Через что проходит группа?
- Формат: Карта стадий
Декслер-Сиббет
- Вопрос: Что мешает команде работать эффективно и как это починить?
- Формат: Диагностический и фасилитационный инструмент

Откаты назад

Что вызывает откаты:

Смена лидера или ключевого участника
Резкое изменение задач / приоритетов
Реорганизация или слияние команд
Долгий кризис или неопределённость

Что делать:

Признать откат, не паниковать
Повторно пройти этапы сознательно
Усилить коммуникацию и ретро-встречи

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

Что такое роль

Cотрудник - это:

Специалист
Коллега
Член команды
Эксперт
Коллега
Поставщик ценностей
Офисный работник
Участник какого-то процесса
Носитель знаний

Роль - это набор ожидаемых поведений, функций и ответственностей, которые человек берёт на себя в контексте совместной работы.

Роль отвечает на вопрос: “Что именно ты делаешь для того, чтобы команда достигла цели?”

Роль != Должность

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

Гибкость:

Один человек → несколько ролей

Одна роль → несколько людей

Например, человек с должностью "middle" фактически играет роль неформального лидера

Виды ролей

Функциональные роли

Связаны с профессиональной экспертизой и задачами

Что человек умеет и за что отвечает содержательно:

пишет код
ведёт финансы
общается с клиентами

Совмещение функциональных ролей:

I-shaped - эксперт только одной области
- shaped - поверхностно разбирается во многих областях, но ни в одной не является экспертом
T-shaped - Разбирается во многих областях и является экспертом в одной из них

Некоторые рроли не стоит совмещать, потому что между ними должен быть конфликт интересов.

Поэтому не очень круто, когда продакту подчиняется техническая команда

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

Связаны с тем, как человек ведёт себя в группе.

Какой вклад вносит человек в групповую динамику:

генерирует идеи
удерживает фокус
снимает напряжение
доводит до конца

Откуда берутся роли?

Роли возникают из трёх источников:

Назначаются - формально закреплённые зоны ответственности
Забираются - человек сам занимает нишу, которая никем не заполнена
Приписываются - группа неосознанно ожидает от человека определённого поведения, и он даже иногда ему следует

Без ясных ролей возникают три типичные проблемы:

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

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

Роли по Белбину:

Действие - роли, нацеленные на действие	Взаимодействие - Социальные роли	Мышление - Интеллектуальные роли
Формирователь - Напористый, динамичный	Координатор - Зрелый, уверенный лидер	Генератор идей - Творческий, нестандартный
Исполнитель - Практичный, надёжный	Командный игрок - Дипломат, поддерживает команду	Исследователь - изучает внешние возможности
Педант - Аккуратен, доводит до конца	Специалист - Экспертные знания в нише	Аналитик-стратег - объективен, критичен

Роли в применении на команду

Функция	Роль
Руководство командой, организация работы	Мотиватор, Координатор, Душа команды
Генерация идей	Генератор идей, Исследователь
Проверка и улучшение идей	Аналитик
Выполнение работы	Специалист, Педант, Исполнитель

Распределение ролей:

Один человек переключается между 1-3 “любимыми” командными ролями
Эффективно исполняются роли, где есть склонность
Роли исполняются вне зависимости от обязанностей и оплачиваемости

Результаты:

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

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

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

Основу заложил американский психолог Клер Грейвз в 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. Структурированность информации
2. Единое понятийное пространство
3. Понимание уровня взаимоотношений
Ключевое условие
1. Информация должна быть воспринята
Конструктивная подача
1. Своевременность
2. Адресность
3. Факты и данные
4. Решение проблем, а не человека

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

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

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

Warning

“Саша, сделай вот это так”

“Почему ещё не готово?”

“Я уже сказал как надо делать”

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

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

Success

“Саша, как ты думаешь, какой подход здесь лучше?”

“Что мешает двигаться быстрее?”

“Что тебе нужно, чтобы решить это самому?”

Выбор стиля

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

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

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

1-1

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

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

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

Пример

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

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

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

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

Как узнать?

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

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

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

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

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

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

Про рост:

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

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

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

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

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

Практика

Подготовка

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

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

В разговоре

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

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

Фиксация

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

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

Не статусы

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

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

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

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

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

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

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

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

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

Тимбилдинг

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

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

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

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

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

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

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

Итоги:

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

Итог

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

`[Видео]` Как нанимать и кому отказывать

Пример

Что имеем?

3 программиста
+2 больших новых продукта с кодовой базой
Документация? Was ist das?
Деньги есть, но держаться всё равно надо
Имеющийся и один новый продукт не должны останавливать работу
Три недели воркшопов с общим пониманием того, что есть

К чему пришли:

3 продуктовые команды разработки общей численностью 25+ человек
Scrum во всех командах разработки, DevOps по Kanban
Релизы 3+ раза в неделю
2 сайта, 2 приложения, 1 система интеграции
Много-много инстансов в Amazon Web Services
Документация, тесты, CI/CD и много контейнеров
Построили и запустили HelpDesk
Переезжаем в российские облака

История найма:

"Чем больше интервью, тем больше наймов" К.О.

“Не факт” Жизненный опыт

Найм – это такой же процесс со своим жизненным циклом

Процесс найма

Обоснование
Портрет
Описание вакансии
Этапы собеседований
Оффер
Испытательный срок

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

Важно иметь ИПР для сотрудника после найма
ИПР усиливает слабые стороны, опираясь на сильные

Обоснование найма

Задач много - надо решать

Задач всегда больше, чем ресурса
Работа занимает весь выделенный под нее ресурс

Моделирование команды

Список CJM Бэклог Экспертная оценка Проектный план

Проверка на кейсе

Интеграция с API алгоритма машинного обучения

Разработка и настройка клиента для связи нашего микросервиса с алгоритмом DS-команды. Гарантированное и безопасное получение данных для последующей демонстрации пользователю

Бэкенд - 3 спринта
Фронтенд 1 спринт
QA - 1 спринт

Создание главной страницы для демонстрации результатов алгоритма

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

Бэкенд - 2 спринта
Фронтенд - 2 спринта
QA - 1 спринт

Считаем деньги

ЗП - 300 000 рублей на руки в месяц
Gross – 344 827 рублей
Отчисления – 452 724 рубля в месяц
Стоимость найма – от 3-х ЗП

6 338 136 рублей в год

Поэтому важно задать себе вопрос:

То, что будет делать человек, принесет хотя бы столько же?

Описание вакансии

Default: у Вас не будет HR

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

Как делать не нужно

How to

Знайте, что будет делать будущий специалист:

Для начала опишите область ответственности специалиста

В идеале – иметь матрицу компетенций

Напишите об этом в описании:

Чем будет заниматься человек?
С кем он будет взаимодействовать?
Какие процессы есть в компании?

Описание компании - это здорово! Но большинство людей идут за взаимодействием и опытом

Не лгите!

Если у Вас нет тестирования, не надо указывать его в описании

Ваша компания не Google*:

В большие компании часто идут ради строчки в резюме
Люди чаще всего узнают о компании в момент прочтения вакансии

Не надо устраивать огород требований, если Вы не ищете евангелиста технологии

Знайте, что будет делать будущий специалист
Напишите об этом в описании
Проверяйте прозрачность требований и фраз
Следите за рынком и ценами
Не лгите!
Ваша компания не Google*
Не поленитесь нажать F7

Рынок работодателя

Когорты поиска:

Уровень	Описание
Junior	Рынок работодателя, жёсткие воронки, высокий порог входа, можно заменить AI
Middle	Рынок работодателя, уход от тестовых, нужно уметь думать
Middle+	Рынок соискателя, удаленка, снижение нефункциональных требований
Senior	Рынок соискателя, удаленка, система бонусирования, масштабные задачи

Характеристики когорт:

Уровень	Опыт	Описание
Junior	0-1 год опыта	1. Нужен ментор 2. Высокая конкуренция 3. Низкий оффер
Middle	1-3 года опыта	1. Самостоятелен 2. Сбалансированный рынок 3. Стандартный оффер
Middle+	3-5 лет опыта	1. Лидит задачи 2. Дефицит на рынке 3. Хороший оффер
Senior	5+ лет опыта	1. Системное мышление 2. Высокий дефицит 3. Рынок кандидата

Распределение по рынку

Джунов на рынке ~50% соискателей
Вакансий для джунов ~15%, что равно более чем трёхкратному разрыву
Дефицит Senior x2.5 и спрос сильно больше предложения

Почему так много джунов?

Бум IT-курсов последних лет выпустил на рынок огромное количество начинающих специалистов
При этом компании крайне редко готовы вкладываться в их обучение - нет времени, ресурсов, выделенных менторов
Конкуренция за джун-вакансии в 2024–2025 годах выросла в 5–10 раз по сравнению с 2020-м

Почему дефицит Middle+ и Senior?

Опыт не масштабируется быстро
Senior с нужным стеком и архитектурным мышлением — редкость
Они живут в режиме “рынка кандидата”

Такие специалисты зачастую не ищут работу активно: их хантят напрямую или переманивают офферами

Что такое Middle+?

Это неформальный, но очень распространённый грейд

Он обозначает специалиста, который перерос из Middle, но ещё не имеет полного набора компетенций Senior - особенно в части системного дизайна и технического лидерства

Именно этот переход считается самым сложным в карьере разработчика

Выводы

Джунам стоит целиться в компании с программами стажировок и выделенными менторами - они реально существуют, просто их меньше
Middle-специалистам выгодно специализироваться в нишах с дефицитом (ML, безопасность, embedded, DevOps)
Работодателям дешевле вырастить Middle+ из своего Middle, чем искать на рынке
Сеньоры часто не доходят до рынка, а переходят по знакомству

Где искать?

Места для поиска:

hh
telegram
linkedin
мой круг
знакомые / нетворкинг
сохранённые списки

Так же можно искать кандидата через HR Аутсорс

HR аутсорс: бутики

Ниша, а не масса. Бутиковые рекрутинговые агентства в IT выигрывают там, где крупные не хотят возиться: редкие стеки (Rust, Erlang, embedded), узкие роли (Staff Engineer, Principal Architect), специфические индустрии (fintech, defence, медтех).
Глубокая экспертиза. Хороший бутик знает рынок изнутри - рекрутер сам бывший разработчик или годами в одной нише. Кандидаты это чувствуют и охотнее общаются, чем с “универсальными” агентствами.
Скорость и качество воронки. 3–5 релевантных кандидатов вместо 30 случайных. Клиентам с дефицитом времени это ценнее, чем объём.
Доверие и рекомендации. В IT сообществе репутация распространяется быстро. Один довольный CTO приводит трёх следующих.

Кому подходит?

Клиентам: стартапы, продуктовые компании без сильного HR, компании в нишевых доменах
Рекрутерам: если есть реальная экспертиза в стеке или индустрии, а не просто “мы нанимаем всех”

Успех бутикового найма в IT зависит от одного:

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

Правила и ограничения:

Ищите везде
Поиск продолжает и дополняет описание
Забудьте про большой HR-аутсорс
Никаких Tinder!
Только честная информация (работает в обе стороны)
Пользуйтесь внешним опытом

Собеседования

Не существует “правильного” собеседования:

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

Этапы

Bigtech
- Контакт с HR
- Скрининг
- Платформа
- Алгоритмы
- Знакомство с командой
Small & Medium Business (aka SMB)
- Контакт с HR
- Tech
- Знакомство с командой

Воронка

Занимательные вопросы:

Почему Вы ушли с предыдущего места работы?
Чем Вы гордитесь?
Кем Вы видите себя через пять лет?
Вы готовы приезжать к 8:30?
Вы готовы ездить в офис?

Как сравнивать двух кандидатов

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

Нужно иметь список схожих вопросов

У нас должен быть чеклист вопросов кандидату

Пример этапов из Бигтеха

Что объединяет все эти задачи?

Разверните на доске бинарное дерево
Самолёт летит быстрее по ветру или против него?
Сколько мячей влезает в автобус?
Почему канализационные люки круглые?
Что будет, если кинуть световой меч в унитаз Звезды Смерти?

Они нужны там, где процесс ради процесса

Чеклист

Smalltalk
Конкретные вопросы о предыдущем опыте работы
1. Что делал?
2. Какая нагрузка?
3. Что ты сделал сам?
Задачи
1. Задача 1 (что проверяем, что ожидаем увидеть)
2. Задача 2 (что проверяем, что ожидаем увидеть, пример кода, который даём)

Задачи

Спросив у кандидата, что значит SOLID, вы не проверите, умеет ли он программировать

Прочитать плохой код
Найти нарушения
Объяснить рефакторинг

Итого

Цените время кандидата (да и своё тоже)
Стройте процесс найма
Задавайте вопросы с определённой целью
Вы не Google
Знайте качества кандидата, которые вам нужны
Давайте обратную связь

Оффер

Оффер - это не конец найма, а начало отношений

Для начала человек может торговаться
Между оффером и выходом на работу человек может передумать
Часто компании не останавливают собеседования после оффера

Юридически: в РФ — это документ “бумажка”

Как можно сделать оффер лучше:

Повысить ЗП
Добавить бонусы / плюшки
Пересмотреть условия (удаленка, работа не из РФ)

Что делать между оффером и первым днём:

Написать лично - не HR, а ты как тимлид (но согласуй)
Дать понять, что его ждут конкретно
Ответить на вопросы, которые он боялся задать на интервью

А еще — написать должностную инструкцию

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

Начало работы

Испытательный срок - продолжение найма.

Ни одно собеседование не даёт 100% гарантии идеального соответствия

Человек мог:

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

Первый день и первая неделя

У человека есть 2–3 дня, чтобы решить:

“я правильно выбрал” или “надо искать дальше”
Онбординг - это не “вот компьютер, разберёшься”
Минимум: понятная задача на первую неделю, назначен buddy, есть с кем поговорить

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

Структурированная проверка - нужен план
Чекпоинты: через 2 недели, через месяц, в конце срока
На каждом чекпоинте: что ожидалось, что получилось, что скорректировать

Типы взаимодействия с новичками

Тип	Описание	Что нужно
Самостоятельный	Опытный, уже всё знает, не любит микроменеджмент.	1. Ошибка: пытаться всё объяснять и контролировать каждый шаг 2. Нужно: дать контекст и не мешать
Ведомый	Джун или человек после большого перерыва. Нужна структура, частая обратная связь, чёткие задачи	Ошибка: бросить в воду и ждать, что сам выплывет
Звезда с другой планеты	Сильный специалист, но из другой культуры или индустрии. Знания есть, контекста нет	Нужен buddy и много разговоров о “как у нас принято”
Тихий	На интервью был активным, на работе молчит. Это не значит, что всё хорошо	Нужны регулярные 1-1 с первой недели

Итоги

Что проверить на каждом этапе:

Обоснование: зачем нужен человек, чем это выгодно бизнесу
Портрет: конкретные задачи, нужный уровень, тип личности
Вакансия: живой язык, честное описание, чёткий must have
ДИ: зоны ответственности и метрики успеха готовы до выхода
Интервью: проверены харды + поведение + культурный фит
Оффер: личный контакт между оффером и выходом
Первая неделя: есть задача, есть buddy, есть чекпоинт
Испытательный срок: минимум три чекпоинта с конкретной обратной связью

`[Видео]` Онбординг и оффбординг

Найм

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

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

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

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

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

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

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

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

Проблемы

Проблема

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

Результат

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

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

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

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

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

Ожидания - договор, а не угроза
На страте работы при первом же 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 каждую неделю
Не нужно ждать конца ИС, понедельника или падающей звезды
Если есть проблема - говорим сразу и без экивоков

”Первые 90 дней” - Майкл Уоткинс

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

Автор: профессор Harvard Business School
Аудитория: менеджеры и руководители, которые только что получили новую должность - внутри компании или в новой организации
Центральная идея: первые 90 дней определяют, станете ли вы успешным на этой позиции или нет
Это период, когда цена ошибки низкая, а возможность влиять на восприятие - максимальная

Точка безубыточности

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

В среднем это происходит на 6-й месяц, по мнению М. Уоткинса

Задача: сократить этот срок

STARS-модель

Это диагностика ситуации, в которую ты входишь:

Start-up - строишь с нуля
Turnaround - спасаешь тонущее
Accelerated growth - масштабируешь
Realignment - меняешь курс
Sustaining success - поддерживаешь хорошее

Под каждую ситуацию - своя стратегия входа

Принцип “сначала учись, потом делай”

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

Это контринтуитивно, но критически важно

Ранние победы

Задача: Выбрать 1-2 видимых результата в первые 90 дней Цель: Создать кредит доверия у команды и руководства

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

`[Тк РФ, ст. 70]` Правила и ограничения испытательного срока

Испытание при приеме на работу:

Юридически (в РФ) ИС может длиться до 3 месяцев для рядовых, до 6 - для руководителей
Но де-факто эффективный онбординг в продукт занимает 3-6 месяцев для сложных ролей

Разграничьте “испытательный срок” и “период полной эффективности”

Испытательный срок
Адаптация
Полная производительность

Результат испытания при приёме на работу:

Работодатель
- Имеет право уволить до истечения ИС, предупредив письменно за 3 дня с указанием причин
- Без согласия профсоюза и выходного пособия
Работник
- Имеет право обжаловать решение работодателя в суде
- Расторгнуть трудовой договор по собственному желанию, предупредив за 3 дня

ИС истек + работа продолжается = испытание пройдено → Расторжение трудового договора только на общих основаниях

Должностная инструкция

Первый и последний оплот при увольнении сотрудника

Читали ли вы их?
Знаете где и найти?
Насколько они совпадают с тем, что вы реально делаете?

Очень сложно формализовать полномочия, обязанности и требования в ИТ

Документ обоюдоострый!
Подходите внимательно и практикуйтесь
Прикладывайте ДИ к конфликтам и проблемам: “Она бы помогла?” → Если “нет” - дописывайте

Общие правила для всех защитят вас в случае конфликтов с сотрудником

Подготовка к началу работы

Подготовка команды

Готовим команду заранее
1. Определяем потребность
2. Создаем ожидания
Определяем наставника
Даем ориентиры по календарным срокам

Представление сотрудника другим

Очно
- Письменно
- Кто, зачем, с кем
Ситуационно

Помните: Всё, что Вы скажете о сотруднике, определит начало его работы

Навешивайте правильные ярлыки!

Первая неделя

Первые дни - самые уязвимые

Нужно дать:

Безопасность
Быстрые победы

Чек-лист первой недели:

Доступы к инструментам (день 1)
Intro 1-on-1 с менеджером (день 1)
Welcome-встреча с командой (день 1–2)
Знакомство с продуктом и кодовой базой / процессами (день 2–3)
Первая маленькая задача с реальным результатом (день 3–5)
1-on-1 с менеджером (день 5)

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

Наставник
Подборка материалов
Задание
Встреча + обратная связь

Первые 30-60-90 дней

Период	Фокус	Цель
1 месяц	Учись	Понять продукт, команду, процессы
2 месяц	Делай	Первые самостоятельные результаты
3 месяц	Улучшай	Инициативы, обратная связь, план роста

Онбординг в продукт

А что за продукт?

Самая частая ошибка - “читай документацию”

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

Демо продукта с командой (не в записи, а живое).
- Команда показывает основные CJM в реальном времени. Заодно и стабильность проверят
Eat your dog’s food.
- Самостоятельное использование как пользователь
Разбор архитектуры / бизнес-логики с наставником.
- Отлично подойдет парная работа (например, pair programming)

Buddy

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

Это не руководитель и не ментор. Это “дружелюбный сосед” с единственной функцией: снизить тревожность нового человека и ускорить его вхождение в контекст.

Роли

Роль	Кто	Зачем
Менеджер	Руководитель	Ставит задачи, оценивает результат
Ментор	Опытный коллега	Развивает профессионально, долгосрочно
Buddy	Коллега из команды	Отвечает на рутинные вопросы, помогает освоиться

Почему это важно?

Новый сотрудник боится задавать “базовые” вопросы руководителю → это воспринимается как некомпетентность
Итог: тратит часы на самостоятельный поиск или допускает ошибки
Buddy снимает этот барьер

Пример: “Как писать в Slack - официально или нет?” - нормально спросить у buddy, неловко - у директора

На практике

Назначение Buddy

Назначается до выхода нового сотрудника
Buddy знает заранее — это не сюрприз

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

2-3 встречи в неделю в первый месяц, потом по необходимости
горизонт: обычно 30-90 дней

Buddy не несёт ответственности за результат

Кого выбирать в Buddy?

Подходит:

Проработал в команде 1+ год - знает контекст
Не перегружен своими задачами
Открытый, терпеливый, позитивно относится к компании

Не подходит:

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

Онбординг в команду

Столько людей!

Смущение и изолированность - враги скорости адаптации
Социальная интеграция так же важна, как профессиональная

Инструменты:

Coffee chat - 15 мин с каждым членом команды в первые 2 недели
Карта команды: кто чем занимается, к кому по каким вопросам
Явное обозначение неформальных норм (“у нас принято…“)
Участие в командных ритуалах с первого дня (ретро, планёрки, демо)

Начало самостоятельной работы

Когда отпускать контроль?

Момент перехода от “делаю с поддержкой” к “делаю сам” - критический

Отпустить рано - развалить безопасноть
Отпустить поздно - развалить рост

Сигналы готовности

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

Situational Leadership

Не существует одного правильного стиля управления

Хороший менеджер меняет подход в зависимости от готовности конкретного человека к конкретной задаче

Разработали Пол Херси и Кен Бланшар в 1969 году. Бланшар позже популяризировал концепцию в книге “The One Minute Manager” и отдельной книге “Leadership and the One Minute Manager”

Готовность человека к задаче определяется двумя параметрами:

Компетентность — умеет ли он это делать
Мотивация — хочет ли он это делать

Уровень	Компетентность	Мотивация	Кто это
R1	Низкая	Высокая	Новичок-энтузиаст
R2	Средняя	Низкая	Разочаровавшийся новичок
R3	Выше средней	Низкая	Опытный, но неуверенный
R4	Высокая	Высокая	Мастер с мотивацией

Уровень	Кто это	Лидерство	Стиль
R1	Новичок-энтузиаст	S1	Директивный Много указаний, мало поддержки Менеджер говорит что, как и когда делать Пример: “Сделай вот это, вот так, к пятнице” Новичок хочет работать, но не знает как - ему нужна структура, а не автономия
R2	Разочаровавшийся новичок	S2	Коучинговый Много указаний + много поддержки Менеджер объясняет решения, вовлекает в диалог Пример: “Давай разберём вместе, почему я предлагаю именно этот подход” Человек уже столкнулся с трудностями, энтузиазм упал - нужно и направлять, и поддерживать

R3	Опытный, но неуверенный	S3	Поддерживающий Мало указаний + много поддержки Менеджер помогает, но не диктует Пример: “Ты знаешь как - я рядом, если нужно” Человек умеет, но сомневается в себе - нужна уверенность, а не инструкции
R4	Мастер с мотивацией	S4	Делегирующий Мало указаний + мало поддержки Менеджер ставит цель и уходит Пример: “Вот результат, который нам нужен — ты знаешь что делать” Человек и умеет, и хочет — избыточный контроль его демотивирует

Ошибки:

Большинство менеджеров застревают в одном стиле и применяют его ко всем одинаково

Чаще всего:

S1 (микроменеджмент)
S4 (полное делегирование)

Последствия: Опытному говорят “как дышать” → уходит от скуки и недоверия Новичку дают автономию → тонет и уходит от стресса

В онбординге

Онбординг - это движение сотрудника по шкале R1 → R4, и задача менеджера - двигать свой стиль вместе с ним


Неделя 1–2 → R1 → S1:	чёткие инструкции, никакой неопределённости
Месяц 1–2 → R2 → S2:	объяснять решения, поддерживать диалог
Месяц 2–3 → R3 → S3:	давать пространство, быть рядом
После 3 мес → R4 → S4:	делегировать, доверять

Когда начинать самостоятельную деятельность?

Не по календарю, а по реальному уровню готовности человека

Окончание испытательного срока

Финальная встреча:

Завершение испытательного срока - не формальная подпись
Это полноценная структурированная беседа

Структура финальной встречи:

Что получилось (конкретные примеры)
Что требует развития
Взаимная обратная связь: что понравилось / не понравилось сотруднику
Цели на следующий квартал
Официальное подтверждение: “Ты в команде” (или нет)

После испытательного срока зафиксируйте:

что человек знает
что умеет
какие зоны роста

Это база для следующего performance review

Если есть - приложите это к матрице компетенций

Не надо экивоков

Людям надо говорить
- Но делай это потому что тебе не всё равно, а не потому что ты хочешь быть правым
Хорошая обратная связь держится на двух осях:
- Care Personally - тебе важен человек как личность, не только как ресурс
- Challenge Directly - ты говоришь правду прямо, не смягчаешь и не замалчиваешь

			пример
Obnoxious Aggression	нет заботы + прямой вызов	1. Говоришь правду, но грубо и без уважения 2. Краткосрочно может работать, долгосрочно разрушает доверие	Это плохая работа, переделай
Radical Candor	высокая забота + прямой вызов	1. Говоришь правду, потому что человеку важно её знать 2. Это то, к чему нужно стремиться	Этот отчёт слабый, вот конкретно почему - давай разберём
Manipulative Insincerity	нет заботы + нет прямоты	1. Говоришь то, что хотят услышать, из политических соображений 2. Лесть без содержания 3. Самый токсичный квадрант
Ruinous Empathy	высокая забота + нет прямоты	1. Жалеешь человека и не говоришь неприятного 2. Самая распространённая ошибка менеджеров 3. Человек не растёт, проблема накапливается, потом взрывается	”Всё нормально” - когда на самом деле не нормально

Во время испытательного срока:

Менеджер видит проблему на второй неделе, но молчит - “человек только пришёл, неловко”
В итоге на финальной встрече выдаёт список претензий
Для сотрудника это шок

Radical Candor требует говорить сразу и по-маленьку - не копить

При оффбординге:

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

Exit interview без Radical Candor бесполезен

Оффбординг

Если человек уходит из компании, то:

есть риск потери репутации
есть риск потери экспертизы
создается стресс для команды

Готовимся к увольнению с первого дня Это звучит парадоксально

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

Знания не должны жить только в голове одного человека
Документация - это страховка
Bus factor (если этот человек “попадёт под автобус” - что произойдёт?)

Самый болезненный сценарий - уходит senior с уникальными знаниями

Как выстроить процесс передачи?

Как так получилось, что знания только у него?
1. Документация была?
2. Почему все завязано на одного человека?
3. Как развязать?
Shadowing: преемник работает рядом последние 2-4 недели
Runbook / playbook на ключевые процессы
Запись видео-объяснений (Loom, Notion)
Exit interview с фокусом на знания, а не на эмоции

Передача экспертизы

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

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

Как подготовить самого человека к выходу

Чек-лист для сотрудника:

Завершение текущих задач или чёткая передача
Документирование незакрытых вопросов
Прощальная встреча с командой (по желанию сотрудника)
Отзыв / рекомендация (если заслужили)
Доступ к документам, которые могут понадобиться после (NDA, трудовая и т.д.)

Как подготовить команду к выходу

Команда реагирует на уход коллеги по-разному:

тревога
перераспределение нагрузки
демотивация

Менеджер должен управлять этим процессом

Действия менеджера:

Объявить об уходе честно и своевременно (не в последний день)
Объяснить, как будут перераспределены задачи
Дать команде время попрощаться
Провести ретроспективу: что потеряли, что можно улучшить

Exit interview

Правильный exit interview:

Проводит HR или нейтральный человек, не прямой руководитель
Вопросы открытые: “Что мы могли сделать лучше?”
Результаты агрегируются и анализируются
Тренды доносятся до руководства

Итоги

Хороший менеджер думает о выходе сотрудника с первого дня - и именно поэтому сотрудник остаётся дольше
Готовьтесь к увольнению с первого рабочего дня
Испытательный срок - продолжение найма

Что почитать:

index	Книга / Источник	Автор
1	The First 90 Days	Michael Watkins
2	Radical Candor	Kim Scott
3	An Elegant Puzzle	Will Larson
4	Work Rules!	Laszlo Bock
5	The Manager’s Path	Camille Fournier
6	Drive	Daniel Pink

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

Мы растем из таких же специалистов

Ты - бро
Ты сделал столько с этими людьми

Ну как я могу уволить?

Почему тимлид должен уметь увольнять

“Хороший человек” - это не должность.

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

Не хотеть увольнять - нормально, но:

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

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

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

Скрытая стоимость неувольнения:

Демотивация команды
Технический долг
Токсичность

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

Книга дня

"Радикальная прямота" - Ким Скотт

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

Увольнение - это финальная точка управленческого цикла, а не его сбой. Сбой - это когда мы постоянно увольняем и нанимаем новых людей.

Токсичная экологичность

Мы все здесь друзья:

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

Например Есть инженер, который считает себя крепким мидлом, но постоянно косячит

Сказать ему, что он работает плохо - он обидится

Сказать ему, что надо бы работать получше - он не поймет

А завтра он еще попросит прибавку к зарплате!

По итогу:

Имеем слабого инженера
Он не растет
Команда смотрит и не понимает, а зачем тогда стараться им

Функции руководителя

Планирование
Организация
Мотивация
Контроль

Увольнение - подзадача функции организации.

У руководителя есть 2 задачи:

Делать работу сегодня
Обеспечить возможность делать работу завтра

Руководитель работает руками команды.

Плохая рука - это нарушение всей системы.

Увольнение - подзадача управления ресурсами.

Люди важны. Но компания - это бизнес:

Руководитель ориентируется на успех бизнеса
У руководителя есть функции и есть задачи для этого
Увольнение - задача оптимизации бизнеса

Менеджер - тоже человек

Постоянный внутренний конфликт менеджера и человека
Всегда можно найти оправдания для сотрудника
Кто-то вообще не умеет принимать сложные решения
Мало принять решение, нужно еще его реализовать
- Нужно собраться и начать реализовывать то, что начал
Люди реагируют по-разному.
- Некоторые могут пойти в штыки и отбиваться, доказывая обратное
Увольнять - сложно. Никто не любит

Откуда берётся внутреннее сопротивление:

Страх реакции сотрудника
Чувство вины (“Я мог сделать больше”)
Избегание конфликта как черта характера
Неуверенность в правильности решения

Как работать с этим:

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

Радикальная прямота

Сразу увольнять?

Нет. Мы должны прийти к решению

Только если не был крайне сильный косяк со сливом данных или угрозой для жизни :)

Концепция:

Хороший менеджер должен уметь одновременно:

Искренне заботиться о человеке как о личности (Care Personally)

Прямо бросать вызов - говорить правду, даже если она неудобна (Challenge Directly)

Это не противоречие. Это и есть Radical Candor - зона, где забота и прямота существуют вместе.

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

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

Когда “доброта” вредит

По итогу:

Имеем слабого инженера
Он не растет
Команда смотрит и не понимает, а зачем тогда стараться им

Разрушительное сочувствие

За что мы увольняем?

Зачем вы нанимали сотрудника?
- Чтобы делал то, что вам надо, и так, как вам надо
За что увольняем?
- Систематическое невыполнение задач, ради которых он был нанят

Очень редко можно правильно принять решение об увольнении в моменте

Ошибка или проступок

Общие черты
- Неправильное действие (или бездействие) сотрудника
- Неудовлетворительный результат
Ошибка
- Правильное действие нигде не описано
- Правильное действие не следует из требований к квалификации сотрудника
Проступок
- Правильное или неправильное действие было описано
- Или правильное действие следует из требований к квалификации сотрудника

Несоответствие работы кодстайлу

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

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

Реакция:

За ошибки нельзя наказывать
- Нужно исправлять процесс и доносить обратную связь
За проступки нельзя не наказывать
- Наказание в зависимости от ситуации

За ошибки не наказывают:

Если ошибки повторяются?
Обработать ошибку сотрудника - задача руководителя
Необработанная ошибка сотрудника - проступок руководителя
Если ошибка обработана, но сотрудник ее повторяет - или она некорректно обработана, или проступок

Кейс

Ваш подчиненный Саша решил работать из дома
Потому что знал, что вас сегодня не будет в офисе
Но вы узнали об этом факте

Ошибка или проступок?

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

Путь на выход

45 татуировок менеджера - Максим Батырёв

Концепция:

Учить
Лечить
Мочить

Учить

Сотрудник не справляется с возложенными задачами и допускает ошибки

Почему? Возможно, у него нет нужных знаний или инструментов

Действия:

онбординг
менторство
обучение
парная работа
чёткие ожидания
сроки

4 причины почему сотрудник что-то не делает или делает не так:

Не знает / не понимает - Учить
Не умеет - Учить
Не может - Учить
Не хочет - Лечить

Лечить

Знания есть, но есть системные проблемы:

мотивация
поведение
коммуникация
личные обстоятельства

Я дал ему честный шанс измениться? Пришёл ли я к человеку с персональным планом, сроками и ясными требованиями?

Предупреждение
1. Донести фидбэк
2. Объяснить, что взаимоотношения под угрозой и мы можем расстаться
3. Обозначить цели и сроки по исправлению - обычно это 1-2 месяца
4. Определить свое участие и помощь
Последний шанс
1. Донести фидбэк
2. Объяснить, что следующий шаг - увольнение
3. Обозначить цели и сроки по исправлению

Мочить

Лечили - не помогло → Учили - не помогло → Решение принято (дальше вопрос “Как?”, а не “Надо ли?“)

Я могу честно сказать, что сделал всё возможное?

PIP

Performance Improvement Plan - формализованный план с конкретными целями, сроками и метриками.

Формализованный план с конкретными целями, сроками и метриками

Как надо: “Обеспечивать покрытие в Х% тестов после ревью PR”

PIP != ИПР

Первое - это конкретные цели, сроки и метрики, по которым мы поймём, что человек улучшился

Второе - это план развития в нормальной ситуации

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

Радикальная прямота: если решение уже принято - PIP нечестен. Лучше прямо сказать об этом

Структура:

Конкретные ожидания
Измеримые метрики
Сроки
Точки контроля
Последствия

Когда пора принять решение

Сигналы, что время пришло

Профессиональные маркеры:

Систематическое недовыполнение после обучения и PIP
Отсутствие роста при наличии ресурсов и времени
Регулярный срыв договорённостей (дедлайны, качество, коммуникация)
Несоответствие роли при отсутствии подходящей альтернативной позиции

Поведенческие и командные маркеры:

Токсичное поведение, которое не меняется после обратной связи
Систематический подрыв решений команды или менеджера
Другие сотрудники теряют мотивацию из-за этого человека
“Bus factor” наоборот: человек стал незаменимым через удержание информации, а не через ценность

"Если бы этот человек завтра сам уволился - я почувствовал бы облегчение или панику?"

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

Разговор

Убедитесь, что решение окончательное
1. Разговор об увольнении - не место для сомнений
2. Если есть колебания, это ещё не тот разговор. Сначала честный фидбек
Согласуйте с HR и юридической стороной
1. Документация: фидбек, PIP, предупреждения - всё должно быть зафиксировано
2. Трудовое законодательство: сроки уведомления, компенсации, формулировки
Подготовьте фактическую базу
1. Нам нужно опираться не на наши ощущения “ты ненадёжный”, а на конкретные факты, которые мы собирали долгое время “ты трижды сорвал дедлайн”.
2. Никаких сюрпризов: если вы работали честно, человек не должен быть шокирован. Просто настали последствия его решений.
Спланируйте логистику
1. Время: начало недели (не пятница вечером - оставьте человеку время действовать)
2. Место: приватная встреча, никакого публичного унижения
3. Длительность: 20-30 минут достаточно, это не дискуссия
4. Кто присутствует: менеджер + HR, не больше
Подготовьте себя эмоционально
1. Принять, что человек будет расстроен - это нормально
2. Ваша задача: ясность и уважение, а не утешение

Структура разговора об увольнении

BLUF - Bottom Line Up Front

Открытие без прелюдий
Причина - честно и конкретно
Условия расставания
Пространство для человека

Первые 30 секунд должны дать человеку главную информацию

Краткий скрипт:

Мы провели анализ фактов с HR и по результатам твоего плана развития, мы приняли решение, о том, что прекращаем сотрудничество. Причина состоит в том, что <набор фактов>. Со своей стороны предлагаем такие выходные условия: <пособия для выплаты>. Так обстоит ситуация. Хочешь ли ты что-нибудь уточнить?

Открытие без прелюдий

✅ “Я хочу сообщить тебе о нашем решении. Мы расстаёмся”
❌ Никаких “У меня есть хорошие и плохие новости” - это издевательство

Причина - честно и конкретно. Мы должны опираться на факты, которые уже обсуждались:

✅ “Мы несколько раз говорили о [X]. Изменений не произошло. Это привело нас к этому решению”
❌ Не “ты плохой”, а “эта роль - не твоя”

Условия расставания

Дата последнего рабочего дня
Компенсации, справки, рекомендации
Что происходит с доступами, проектами, передачей дел

Пространство для человека. Нужно дать время на реакцию - молчание, вопросы, эмоции:

✅ “Я понимаю, что это тяжело. Если у тебя есть вопросы - я отвечу”
❌ Не защищаться, не спорить, не утешать избыточно

Чего не надо делать:

❌ Извиняться за решение
❌ Говорить “это не личное” (для человека - очень личное)
❌ Давать ложную надежду (“может, что-то изменится”)

Риски

А вы думали он так сразу согласится?

Юридические:

ТК РФ
Трудовая инспекция
Суд

Безопасность:

Доступы - может дропнуть базу данных
Контакты - может увести клиентов к себе или перепродать контакты

Репутационные:

Токсичность
Отзывы
Сарафанное радио

Варианты увольнения

По соглашению сторон

Наиболее частый цивилизованный вариант
Договариваются условия, оба подписывают - юридически чисто

По инициативе работодателя

Грубые нарушения, фиксированные и доказанные
Требует документации, может оспариваться
Потребует 2-4 месяца на увольнение
Часто заканчивается выплатой “парашюта”

Мягкий выход (по собственному)

Сотрудник сам понимает ситуацию
Менеджер создаёт условия для самостоятельного решения уйти
Довольно тонкая игра
Это не манипуляция, а честный сигнал. Разница в том, что человеку дают полную информацию о ситуации и право принять решение самому

Ротация

Проблема в несоответствии роли, не человека
Не всегда возможно, но сохраняет человека в компании

Сокращение

Выплаты 2-6 ЗП
Но можно предложить помощь

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

Выход

Последние дни - тоже часть менеджерской работы

Передача знаний
Доступы и безопасность
Рекомендации
Финальная встреча

Передача знаний:

Документация процессов, кодовой базы, контактов
Structured handover: кто принимает задачи, в какие сроки
Снижение Bus Factor как прямой результат хорошего offboarding’а

Доступы и безопасность:

Чёткий план отзыва прав (координация с IT и HR)
Не в день увольнения - это унизительно, если человек работает до конца

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

Если сотрудник работал добросовестно - рекомендательное письмо это минимум уважения
Честная рекомендация != фальшивая. Можно рекомендовать с фокусом на сильных сторонах

Финальная встреча (exit interview):

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

Afterlife

Бывших коллег не бывает

IT-мир маленький
- Люди встречаются снова - как заказчики, партнёры, коллеги
“Alumni network”
- Уволенные сотрудники могут стать амбассадорами компании или вернуться в другой роли

Что помогает сохранить нормальные отношения:

Честность в процессе (человек знал причины)
Уважительный процесс расставания
Выполненные обязательства (компенсации, рекомендации, сроки)

Что разрушает отношения навсегда:

Увольнение без предупреждений и обратной связи
Публичное унижение или сплетни после
Невыполнение договорённостей

Работа с командой после увольнения

Команда всё видела. Что теперь?

Команда формирует выводы о менеджере и компании по тому, как произошло увольнение. Если человека водили по столу лицом, то вся команда об этом точно узнает.
Молчание менеджера порождает слухи и тревогу (“Кто следующий?“)

Что сказать команде:

Пункт	Ответ
Факт:	“[Имя] больше не работает с нами”
Уважение к уволенному:	Никакого разбора полётов публично
Ответ на тревогу:	“Ситуация не влияет на остальных членов команды”
Планы:	“Вот как мы закроем образовавшийся пробел”

Чего не делать:

❌ Не объяснять детально причины - это нарушение приватности
❌ Не делать из этого показательную историю (“Вот что бывает, если…“)
❌ Не затягивать с коммуникацией - слухи быстрее вас

Долгосрочная работа с командой:

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

Итоги

Увольнение - это акт менеджерской зрелости

Вовремя - не затягивать после того, как решение созрело
Честно - человек понимает причины, они не стали сюрпризом
Уважительно - формат, место, слова соответствуют достоинству человека
Подготовлено - юридически, логистически, эмоционально
Продолжено - команда услышала нужное, offboarding завершён

Хороший менеджер - это менеджер, который умеет завершить сотрудничество так, чтобы сотрудник ушёл с ясностью, а не с обидой

Хороший менеджер не избегает увольнений

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

Определения

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

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

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

Девиантное поведение (девиации) - cовершение поступков, которые противоречат нормам социального поведения в том или ином сообществе. Когда в рамках конфликта персона может применять оскорбления, рукоприкладства, вредительства - это нужно присекать.

Пример

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

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

Девиация - если оба коллег начали отбирать друг у друга этот кусок.

Конфликт - возникает сразу, как они вошли на кухню и увидели этот кусок пиццы.

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

Конфликт - это не ссора. Это столкновение интересов. Ссора - это одна из форм проявления конфликта.

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

Распределение ресурсов
Взаимозависимость задач
Различия в целях
Различия в способах достижения целей
Проблемы с коммуникациями
Различия в психологических особенностях
Недопонимание
Эмоции
Различия в ценностях
Конфликтный человек
Ваш вариант

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

По действию на работу команды / организации
- конструктивные - нацелен на достижение результата при разных интересах
- деструктивные - ультимативное выполнение условий одной из сторон
По содержанию
- предметные - за кусок пиццы
- ценностные - Kanban vs Agile vs Scrum, отношение к языкам и кодстайлу
- беспредметные - HolyWar, беспричинные, вокруг какой-то вещи
По характеру участников
- внутриличностные - как провести время вечером: зал или кино (+ это ценностный конфликт)
- межличностные - два человека за последний кусок пиццы
- между личностью и группой - противопоставление команде
- межгрупповые - команда с командой
По направленности
- горизонтальные - линейные специалисты
- вертикальные - между руководителем и подчинённым
- смешанные - между разными группами

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

Нам вредны деструктивные и беспредметные конфликты:

Мне не нравится этот парень, он меня бесит.

Зал или кино - что выбрать?

Это полезный конфлит

Во время него, мы вырабатываем свою систему ценностей

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

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

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

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

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

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

Гармония - базовое состояние, когда нет конфликтов
Конструктивный конфликт - гармония переходит в конфликт, когда сталкиваются интересы И это самый лучший вариант
Холодная война - конфликт есть, но каждый делает по-своему в рамках зоны своей ответственности, потому что никто не хочет выходить в открытую конфронтацию
Борьба - люди уже начинают искрить
Война - деструктивный конфликт

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

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

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

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

Андрей, Тимлид: У нас была задача N в спринте и она была сдана в последний момент. Это не очень круто, так как таким образом команда подвергается риску и мы можем выпустить её некачественно. Ребят, какие будут предложения о том, как мы можем это исправить?
- Уходим от личности к проблеме
- Все могут успеть высказать своё мнение и мы можем в конце спросить: “Максим, как ты думаешь, что могло помешать сдать задачу раньше?”
Максим, Разработчик: В этом спринте было найдено много багов в проде, которые пришлось экстренно закрывать, а времени на основную задачу почти не хватило.
Андрей, Тимлид: Предлагаю подумать над вопросом, почему у нас так много багов на проде. Что нужно сделать, чтобы не множить баги и разгрузить Максима, чтобы он не тратил на них столько времени?

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

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

Автор: Патрик Ленсиони

Формат: бизнес-роман

Модель: пирамида причинно-следственных связей

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

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

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

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

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

Каждый порок развивается каскадом. С пороками нужно работать постепенно и быстро.

Кейсы

Команда на 1-1 подсвечивает, что определённый сотрудник ведёт себя безответственно - редко делает MRы, мало пишет кода, пишет плохой код. Нам НЕ нужно приходить на 1-1 к человеку и говорить, что команда не любит оного - нужно со всех собрать факты и сформировать единую фактуру. Нужно сказать: “Я собрал фактуру за последние N месяцев и заметил, что качество кода и фичей начинает сильно вредить продукту. Давай попробуем определить твои блокеры и проблемы, которые приводят к таком результату.”
Команда приняла решение использовать новый стек. Через неделю выясняется, что двое разработчиков продолжают писать на старом — “мы не были уверены, что решение окончательное”
- У этой группы есть недоверие к команде насчтёт работы с новым стеком
- У них есть боязнь конфликтов, потому что ребята не подсветили наличие проблем
- Безответственность проявляется в том, что другие члены команды не обращают внимания на то, что те ребята пишут на старом стеке
- Нетребовательность. Никто не требует переключиться на новй стек.
Тимлид добивается высоких метрик своей команды. Даже если это требует перетягивания ресурсов с соседней… На общих OKR это не отражается - у него всё зелёное.
- Недоверие. Со стороны тимлида к своим коллегам и коллегам из других команд, чтобы подтянуть их работать быстрее над задачами его команды. Не верит, что в других командах есть более приоритетные задачи и что они вообще занимаются полезной деятельностью.
- Безразличие к результатам. OKR зелёный в его команде, а не в команде его коллег, которые занимались преимущественно задачами его команды.

Решения

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

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

К деструктиву прийти очень легко:

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

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

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

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

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

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

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

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

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

Предмет разногласий не представляет большой ценности
Уступая в одном - выигрывает в другом. Мы уступили тут, а потом он нам уступит в другой ситуации.
Отношения с оппонентом важнее предмета разногласий
Оппонент намного “сильнее”
Оппонент прав

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

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

Принуждение

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

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

Компромисс

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

Амортизация

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

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

Я-сообщение

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

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

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

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

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

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

Кейс

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

Подожди, я ощущаю твоё разочарование. Что было сделано в прошлый раз для решения этой проблемы? Может, мы не туда пошли?

Человек рассказал, что мы сходили в … и так нельзя.

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

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

Манипуляция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кейс

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

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

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

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

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

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

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

Итог

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

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

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

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

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

Откуда берётся “очевидность”:

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

Что получают от тебя коллеги?

Проклятие Знания

Когда ты что-то знаешь → ты не можешь представить, каково это - не знать. В итоге мы приходим к:

Это же очевидно
Мы всегда так делали
Я объяснил на стендапе фич

Почему Тимлиду важно принимать решения?

Тимлид

Вырос из технической экспертизы (разработчик, DevOps, QA…)
Имеет опыт работы в n лет
Хочет расти, амбициозен
Понимает, что можно сделать лучше с позиции инженера

Исполнитель – стремится к результату Руководитель – стремится к результату чужими руками

Решения

Решение - это выбор одной стратегии действий из нескольких

Даже, если мы ничего не делаем, мы всё равно принимаем решение

ƒ(вводные) -> результат

Характеристики решений

Качество решения определяется требованиями системы

То, что мы плохо контролируем

Риски - потенциально существующая возможность потери ресурсов в результате реализации решения

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

То, что для нас неочевидно

Контекст
- Почему это решение вообще нужно
Логика
- Как ты пришёл к выводу
Ожидания
- Что конкретно должно измениться в поведении / работе

Объясняй не только “что”, но “зачем” и “почему именно так”

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

Кейс

Выработка решения относительно потребности в ERP системе

Система:
- Компания, которая хочет получить ERP решение
Решение:
- Как и какой ERP выбрать?
Характеристики решения:
- Например:
  - бюджет
  - уровень автоматизации
  - интеграция с N программами

Уровень неопределённости: высокий

Процесс достижения результата

Проблема → Требования → Цель → Решение → Исполнение → Результат

ITIL 4 Continual Improvement Model

What is the vision?

Зачем нужен зафиксированный Scope

Scope:

Чёткое понимание границ со стороны всех заинтересованных лиц
Оптимизация бюджета и плана управления ресурсами
Снижение рисков Предотвращение разрастания объёма
Управление ожиданиями заинтересованных лиц
Создание процесса подачи запросов на изменения

Кейс

Scope ERP решения:

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

Фундамент решения

Решения на основе опыта:

Личный опыт
Групповой опыт
Опыт сообщества
Привлечённый опыт

Личный опыт:

Решили проблему → Получили опыт → Рефлексия → Схема

Наш опыт – это альбом схем решения по схожим параметрам

Личный опыт = подбор схемы

Паттерны проектирования очень похожи на это


Паттерн	поведение на основе схемы
Фреймворк	программа на основе схемы
Алгоритм	шаги применения схемы

Но у команды опыт-то свой!

“Мы же договорились!” Самая опасная фраза в управлении

Анатомия недопонимания

На каждом переходе - потери смысла
Чем сложнее задача, тем больше искажений

Намерения → Слова → Интерпретация → Действие

Типичные ошибки менеджера

Слишком высокий уровень абстракции (“сделайте хорошо”)
Договорились устно - не зафиксировали письменно
Не проверили понимание: “Всё понятно?” → “Да” — не работает
Объяснили один раз и считают, что этого достаточно
Не обозначили приоритеты среди нескольких задач

Техника “повторения назад” (teach-back)

Попросить человека пересказать задачу своими словами
Не “Ты понял?”, а “Расскажи, как будешь делать”
Позволяет поймать расхождение до начала работы

Письменная фиксация договорённостей

Коротко:

что решили
кто делает
к какому сроку
что считается результатом

Формат:

сообщение в Slack
тикет в трекере
Decision Log

Золотое правило: “Если не записано - не договорились”

Проверка реализации

Не ждать дедлайна - делать промежуточные чекпоинты
Вопрос не “Как дела?”, а “Покажи, что есть на данный момент”
Ранний сигнал расхождения - дешевле исправлять

Эргодичность

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

Проблема эргодичности

Правильный вопрос не “Какова средняя доходность?”, а “Что будет со мной конкретно, если не повезёт несколько раз подряд?”

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

Систематическая ошибка выжившего

Получается, опыт обесценивается?!

Групповая работа сталкивает схемы разных людей Процесс: Конструктивный конфликт Цель: Системное решение

Опыт сообщества Коллег может не оказаться → Специалист идёт в сообщество “А как решалась задача у них?”

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

Привлечение опыта

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

Кейс

В компании нет опыта внедрения ERP
Пытаемся найти на рынке спецов/команды, которые работали в схожих проектах
???
PROFIT!

Так будет не всегда

Неопределенность

Условия неопределённости:

Стохастическая - Есть информация о распределении вероятности
Поведенческая - Есть информация о влиянии поведения на результат
Природная - Имеется информация только о возможных результатах
Априорная - Нет никакой информации

Устранение неопределённости:

Любой тип неопределённости → Стремимся свести к стохастической

Принцип непознаваемости

Нельзя ничего познать на 100% Нам надо принять решение в условиях отсутствия 100% информации

Собственный research

Получаем экспертизу → Тратим время и деньги
Исследуем с учётом нюансов бизнеса → Можем не найти решения
Растим команду → Можем пойти не в ту сторону

Консалтинг

Получаем дополнительный опыт → Тратим деньги
Снижаем риски → Можно ошибиться в консалтинге
Не тратим время на исследование → Рост команды слабее

Кейс

В компании нет опыта внедрения ERP

Исходные данные
1. Текущая экспертиза устраивает
2. Менять команду нет желания
Стратегия
1. Ищем консалтинг, который расскажет нам, как выработать решение

Риски

Не существует на 100% прозрачных проектов

Risk Value = Probability of Event x Cost of Event

Правила

Выбирать из одного решения нельзя
Идеального решения не существует
Используем групповые решения
Везде будут свои факторы неопределённости и рисков
Лучшее выбирается в сравнении

Аналитика

От интуиции к данным - и обратно Данные не принимают решения - они снижают неопределённость

Почему “принять решение на данных” сложнее, чем кажется

Данных слишком много или слишком мало
Данные противоречат друг другу
Данные есть, но непонятно, что из них следует
Соблазн подтверждать уже принятое решение (confirmation bias)

Минимальный аналитический цикл

Последовательность:

Вопрос
Данные
Интерпретация
Гипотеза
Решение
Проверка

Ключевой шаг, который пропускают: Формулировка вопроса до сбора данных

достаточные данные

Уровень уверенности: Понятие “confidence level” для принятия решения
Матрица принятия решения:

Ценра ошибки	Стоимость сбора данных	Правильное действие
Дёшево исправить	Дорого собирать	Действуй быстро
Дорого исправить	-	Инвестируй в анализ

Когда “хватит анализировать”? → Признаки analysis paralysis

Практические инструменты

Метрики как основа:
- Что измеряем, чтобы понять успех
A/B-подход:
- Если можно - тестируй на части
Post-mortem и ретро
- Как источник данных о прошлых решениях

Правила

Данные отвечают на вопрос “Что происходит?”
Менеджер отвечает на вопрос “Что делать?”
Аналитика снижает риск, но не отменяет ответственность за решение

Фреймворк принятия решений

SWOT

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

SWOT - это не документ, а разговор

S - Strengths (сильные стороны)
W - Weaknesses (слабые стороны)
O - Opportunities (возможности)
T - Threats (угрозы)

Внутренние факторы (S/W) vs внешние (O/T)

Как проводить SWOT быстро

Формат - 30-60 минут с командой или самостоятельно
Фокус - на решении, а не на компании в целом
Правило - не более 3-5 пунктов в каждом квадранте - иначе всё теряется

Из SWOT - в решение: SO/ST/WO/WT стратегии

Ошибки при использовании SWOT

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

Кейс

S - ERP известна на локальном рынке
W - Высокая стоимость лицензии
O - Можно нанимать команду в будущем
T - Решение может не подойти для иностранных партнеров

Cynefin

Cynefin ["канэвин"] – это модель, определяющая тактики поведения в разных средах Любое явление или проблема могут быть отнесены к одному из контекстов → это помогает объяснить происходящее и принять эффективное решение

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

Важно: Не методология, а способ думать о контексте

Clear / Simple
- Простое / Очевидное
- Причина и следствие известны
- Best Practice → Воспринимай → Классифицируй → Реагируй
Complicated
- Сложное
- Причинно-следственные связи требуют анализа, предполагается участие нескольких экспертов, объединенные знания которых помогут найти правильное решение проблемы
- Good Practice → Анализируй → Воспринимай → Реагируй
Complex
- Комплексное
- Причинно-следственные связи становятся понятны только в ретроспективе
- Emergent Practice → Исследуй → Воспринимай → Реагируй
Chaotic
- Хаотичное
- Связи неопределены
- Novel Practice → Действуй → Воспринимай → Реагируй
- Опыта решений проблем из этой области не существует
Confused
- Disorder
- Не знаем, в каком домене находимся → опасная зона
- Мы уже научились снижать неопределённость

Правила

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

Шаги:

Определи домен перед выбором инструмента
В Complex - запусти несколько маленьких экспериментов
В Chaotic - сначала стабилизируй, потом анализируй

“Правильный ответ зависит от того, в какой ситуации ты находишься”

ADKAR

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

Сопряжена больше с внедрением принятого решения
Схожа с ITIL 4 Continual Improvement

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

A - Осознание необходимости изменений
D - Желание поддержать изменения
K - Знание о том, как меняться
A - Умение применять навыки и поведение
R - Закрепление изменений

Почему изменения не приживаются

Запустили → Объявили → Забыли проверить

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

Awareness

Цель: Сформировать понимание необходимости изменений

Ключевые вопросы:

Что будет, если ничего не менять (риски, упущенные возможности)
Показываем контраст: текущее состояние vs целевое будущее
Отвечаем на вопросы о сути, сроках и масштабе перемен
Руководство транслирует единую позицию, без разночтений

Desire

Цель: Мотивация и личное решение участвовать в изменениях

Ключевые вопросы:

Что ценно для конкретных людей, каковы их ценности и мотивы?
Что ценного получат сотрудники как личности?

Knowledge

Цель: Знать, как добиться результата

Компоненты знания:

Обучение навыкам и способам поведения, необходимым для изменений
Доступную и достаточную информацию о том, как использовать новые процессы, системы, инструменты
Информирование о том, какие новые роли и ответственности связаны с изменениями

Ability

Цель: Формируется навык и способность действовать соответствующим образом. Сотрудникам необходима возможность реализовать свои знания на практике

Что помогает закрепить умение:

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

Reinforcement

Цель: Закрепление позитивных изменений

Инструменты закрепления:

Хвалите и вознаграждайте сотрудников за успехи
Празднуйте победы
Собирайте фидбэк

Причина необходимости решения

Ключевые вопросы:

Какую боль мы хотим убрать?
Какие цели преследуем?

Любой продукт внедряется не просто так!

Составляющие

Сколько денег потратим и сколько сэкономим / заработаем?
Какими шагами будет внедряться решение?
Рассказываем, где таймлайн расширен ввиду рисков
Рассказываем о команде. Надо показать, где и какой ресурс задействован
Нововведения часто воспринимаются жёстко (“сейчас-то всё работает”)

Workarounds

Workarounds - это временное обходное решение, которое снимает боль сейчас

Примеры:

хардкод значения
ручная сверка данных раз в неделю
отдельный скрипт “пока не починим”

Не устраняет причину - только симптом

Почему workaround’ы опасны:

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

Матрица: когда workaround допустим

	`Цена проблемы высокая`	`Цена проблемы низкая`
`Быстро исправить корень`	Исправляй корень	Исправляй корень
`Долго исправлять корень`	Workaround + план на fix	Workaround (приемлемо)

Workaround без плана на устранение причины - это не решение, а отложенная проблема

Как вести учёт “костылей”:

Фиксируй в трекере: что это, зачем, до какого момента
Назначай ответственного и дедлайн ревью
Регулярно пересматривай список: что выросло в приоритете?
“Технический долг” - это нормально, но им нужно управлять

Признаки того, что команда застряла в пожаротушении:

Большинство задач - реактивные, не плановые
“У нас нет времени сделать нормально” - постоянная фраза
Одни и те же проблемы повторяются
Команда устаёт, мотивация падает

Выход из режима “пожаров”:

Выдели время на системные решения: 20% спринта / итерации
Проводи root cause analysis после инцидентов
Приоритизируй: не всё срочное - важное
Покажи команде разницу: “мы решили проблему” vs “мы её закрыли на время”

Итоги

Не выбирай одно из одного
Анализируй это
Применяй фреймворки
Привлекай опыт
Не затягивай

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

У нас можно не соглашаться

Это не слабость, это зрелость команды

`[Видео]` Ликбез по фреймворкам

Фреймворк или религия

Глобальное есть два лагеря:

Фреймворки
Свой путь

Боль тимлида:

Мы Agile-компания, работайте итерациями
Product Owner хочет все и сразу
Дедлайн вчера
Команда не понимает, что за ритуалы такие и горит

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

Agile

Agile Manifesto

Поиск лёгких методов
- 17 разработчиков собрались, чтобы обсудить “лёгкие” методы разработки
До этого
- Водопад, тяжёлые RUP-процессы, годовые циклы планирования

Главная боль: ПО устаревало быстрее, чем его успевали написать по спецификации

	>
Люди и взаимодействие	важнее	Процессов и инструментов
Работающий продукт	важнее	Исчерпывающей документации
Сотрудничество с заказчиком	важнее	Согласования условий контракта
Готовность к изменениям	важнее	Следования первоначальному плану

Важнее != Исключает

12 принципов Agile

4 кластера Agile:

О ценности для клиента
- Главный приоритет - раннее и непрерывное предоставление работающего ПО
- Изменение требований приветствуется даже поздно
О темпе и качестве
- устойчивый темп работы
- постоянное внимание к техническому совершенству
- простота - искусство не делать лишнего
О людях и взаимодействиях
- мотивированные люди > процессы
- личный разговор > любого документа
- рефлексия и адаптация регулярно
О самоорганизации
- Лучшие архитектуры и требования рождаются в самоорганизующихся командах

Agile - это философия, а не методология

Ценности - Manifesto

Принципы - 12 принципов

Практики - Scrum, Kanban, XP, SAFe…

Многие компании внедряют практики, не понимая ценностей → Это как выучить нотную грамоту, но не слышать музыку

Agile нельзя внедрить

Agile - не набор инструкций, а набор ценностей. Ценности нельзя установить приказом
Распространённая ошибка: Купить Jira + провести ретро + назвать себя “Agile-командой”
Состояние Cargo Cult: Делаем ритуалы, не понимая зачем

Agile в Cynefin

Agile-фреймворки оптимальны для Complex домена - там, где требования меняются, а правильный ответ не известен заранее

Применимость фреймворков

Waterfall

Незаслуженно демонизированный подход

Уинстон Ройс в статье “Managing the Development of Large Software Systems” (1970) описывал водопад как антипример и тут же предлагал итеративный подход

Индустрия прочитала только первую половину

Когда Waterfall оправдан:

Требования зафиксированы и не изменятся: Госконтракт с ТЗ
Цена ошибки на поздних этапах критически высока: медицина, авиация, космос
Регулятор требует полной документации решений: банки, страхование

Какую зону Cynefin хорошо закрывает Waterfal:

Waterfall - правильный инструмент для домена Complicated (сложное, но познаваемое)
В домене Complex (комплексное, требования возникают в процессе) - он ломается структурно, а не из-за плохого исполнения

Где Agile вреден?

Кейсы

Жесткие регуляторные требования

Там где аудит требует полной документации решений:

Банки
Медицина
Авиация

“Рабочий продукт важнее документации” здесь буквально незаконно

Фиксированные контракты

Fixed Price / Fixed Scope контракт + Agile = = постоянный конфликт ожиданий
Agile предполагает изменяемые требования, контракт — нет

Но никто не отменяет итерационного подхода

Когда церемоний > работы

Команда проводит > 20% рабочего времени на митингах, связанных с фреймворком
Ретро превратилось в формальность - действия не выполняются
Планирование спринта занимает полдня, но план устаревает к среде
Люди приходят на стендап “чтобы отметиться”

Если у вас это есть - это не значит, что Scrum плохой. Это значит, что Scrum плохо настроен или не подходит именно сейчас

Agile и технический долг

“Работающий продукт” ≠ “Качественный продукт”

Постоянное давление доставлять ценность в конце каждого спринта стимулирует срезать углы
Технический долг накапливается быстрее, чем в Waterfall - просто незаметно, итерация за итерацией
Definition of Done - не включает code review или тесты
Рефакторинг - никогда не попадает в спринт
“Мы разберёмся с этим позже” - стандартная фраза

Extreme Programming (xp)

XP отвечает на это жёсткими техническими практиками:

TDD,
Pair programming
Continuous integration

Именно потому, что авторы Agile понимали этот риск

xp

Agile с зубами

Кент Бек, 1996–1999 - проект Chrysler Comprehensive Compensation System (C3)
Бек заметил: когда практики, которые и так работают, доводишь до предела - результат улучшается нелинейно

Отсюда название:

Extreme - не “экстремальный” в смысле опасный, а “доведённый до крайности”

Практики из книги “Extreme Programming Explained” (1999) до сих пор актуальны:

TDD
CI/CD
Refactoring
Conding Standard

Ценности

Сommunication
Simplicity
Feedback
Courage - одна из немногих методологий, где честно назвали то, что мешает большинству команд:
- страх показать незаконченный код
- страх сказать “я не знаю”
- страх выбросить неудачное решение
Respect

Практики

Практика	Описание
TDD	Тест пишется до кода - код пишется, чтобы тест прошёл
Pair Programming	Два разработчика за одним компьютером, одновременно
Refactoring	Постоянное улучшение структуры кода без изменения поведения
Continuous Integration	Код интегрируется в основную ветку несколько раз в день
Collective Code Ownership	Любой разработчик может изменить любой код в проекте
Coding Standard	Единый стиль кода для всей команды - без исключений
Simple Design	Всегда выбирать простейшее решение, которое работает

XP Ориентирован на техническ ую часть, а не на бизнес

Поэтому в настоящее время встречается не как самостоятельный фреймворк, а как набор практик

Scrum

Три столпа:

Transparency - Прозрачность
- весь процесс виден всем участникам
Inspection - Инспекция
- регулярная проверка прогресса
Adaptation - Адаптация
- изменение подхода при отклонении

Ценности:

Commitment
Courage
Focus
Openness
Respect

Без ценностей Scrum

Без Courage невозможна честная ретро
Без Openness невозможна прозрачность

Команды, которые пропускают ценности и берут только артефакты - получают тот самый Cargo Cult

Роли в Scrum

Product Owner

Максимизирует ценность продукта
Единолично владеет Product Backlog и расставляет приоритеты
Отвечает на вопрос “Что делаем?”

Ключевой риск: PO не может быть комитетом - решение принимает один человек

Scrum Master

Служит команде, PO и организации
Устраняет препятствия (impediments)
Обучает правильному применению Scrum

Ключевой риск: Не PM, не секретарь, не лид - частая путаница в командах

Developers

Кросс-функциональная команда, которая создаёт Increment
Самоорганизуются вокруг технических решений

Оптимальный размер: 3-9 человек

Тимлид не нужен?!

В Scrum Guide три роли:

Product Owner
Scrum Master
Developers

Тимлида нет

Значит, ответственности тимлида никуда не делись - они просто не распределены

У Тимлида работы гораздо больше

Это SDLC фреймворк

Люди
- Найм и увольнение
- Психологический климат команды
- Разрешение конфликтов внутри команды
Рост
- Карьерное развитие разработчиков
- Менторинг и рост junior-ов
- Performance review
Техника
- Технические решения и архитектура
- Связь с другими командами технически

Важно:

Scrum описывает, как поставлять продукт Scrum не описывает, как управлять людьми

Ошибки распределения ролей в Scrum

Ошибки

Тимлид = Scrum Master

Самый частый. Формально логично - оба “помогают команде”

Проблема:

SM служит команде и не имеет власти

Тимлид управляет людьми и несёт ответственность за их рост → Это конфликт интересов, встроенный в роль

Пример напряжения:

SM должен защищать команду от внешнего давления

Тимлид должен транслировать ожидания бизнеса вниз → Одновременно - нельзя

Тимлид = старший разработчик в Developers

Технически честнее - тимлид кодит и влияет на решения изнутри команды

Проблема:

Неформальная иерархия никуда не исчезает. Команда всё равно смотрит на него за решениями

Self-organization в такой команде - иллюзия

Тимлид существует параллельно Scrum

Организация сохраняет тимлида в качестве “инженерного менеджера” вне Scrum-ролей

Это честнее всего - но требует явного разграничения:

Тимлид отвечает за людей
SM за процесс
PO за продукт

Зрелый Scrum

Тимлид в Scrum-команде → это инженерный менеджер, чья зона - люди и техническое направление
Scrum-роли → это операционный слой, роли не пересекаются, если разграничены явно

Проблема:

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

Артефакты Scrum

Product Backlog

Набор всех-всех-всех существующих и рождающихся “хотелок” пользователей

Ориентир: Product Goal — долгосрочная цель продукта

Sprint Backlog

Набор задач на указанную итерацию разработки

Фокус вокруг: Sprint Goal - цель конкретного спринта

Increment

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

Связь

Product Goal: Прирастить конверсию A на Х% → Sprint Goal: Дать возможность пользователю размещать заказы нового типа на Desktop → Increment: Ушел в релиз и запущен А/Б тест с новыми типами заказов

А как понять, что инкремент готов?

Да, вы зарелизили. Но вот тут еще не нажимается кнопочка…

Definition of Done

DoD - это явное командное соглашение о том, что значит “готово”

Отсутствие чёткого DoD - главный источник технического и продуктового долга в Scrum-командах

DoD - это не формальность “задача закрыта в Jira”

Что такое хорошо?

Плохой DoD	Хороший DoD
Код написан	Код написан
	Протестирован QA
	Покрыт unit-тестами (>80%)
	Пройден code review
	Задеплоен на staging
	Документация обновлена

Два уровня готовности:

Acceptance Criteria
- Условия, при которых конкретная задача считается выполненной правильно
- Отвечает на вопрос: “Мы сделали то, что просили?”
Definition of Done
- Условия, при которых любая задача считается готовой к поставке
- Отвечает на вопрос: “Мы сделали это достаточно хорошо?”

AC vs DoD:

Acceptance Criteria (пишет PO под эту задачу):
- Пользователь может зарегистрироваться через email и пароль
- Email валидируется на корректный формат
- Если email уже занят — показывается понятное сообщение об ошибке
- После регистрации пользователь автоматически входит в систему
- На указанный email приходит письмо с подтверждением
Definition of Done (написан командой 1 раз для всех задач):
- Код написан и соответствует Coding Standard
- Пройден code review минимум одним разработчиком
- Unit-тесты написаны, покрытие новой логики ≥ 80%
- Задача прошла тестирование QA на staging-окружении
- Нет известных критических багов
- API задокументировано (если применимо)
- Задача задеплоена на staging

Пример: фича “Регистрация пользователя”

AC and DoD:

Фильтр качества
- Задача по регистрации сначала проходит DoD
Фильтр правильности
- Потом PO проверяет AC
Задача может пройти DoD, но не пройти AC: → код качественный, но функционал реализован не так, как просили
Задача может пройти AC, но не пройти DoD: → функционал правильный, но нет тестов и code review - в Increment не идёт

Задача готова = DoD complete AND AC complete

Церемонии Scrum

События

Sprint Контейнер для всех событий 1-4 недели
Sprint Planning Договориться о Sprint Goal и плане ≤ 8 часов
Daily Scrum. Синхронизация и план на день 15 минут
Sprint Review Инспекция Increment - адаптация Product Backlog ≤ 4 часа
Sprint Retrospective Инспекция команды + план улучшений ≤ 3 часа
Product Backlog Refinement (aka Grooming) Разбор и оценка будущих задач ≤ 4 часа в неделю

Ошибки в реальности


PO единолично приоритизирует бэклог	PO - согласующий орган из 5 стейкхолдеров
SM устраняет организационные препятствия	SM ведёт протокол и бронирует переговорки
Команда самоорганизуется	Тимлид раздаёт задачи как и раньше
Sprint Goal - 1-2 чётких цели	Sprint Goal - “делаем всё из бэклога”
Ретро приводит к изменениям	Ретро приводит к стикерам на стене

Идеальные условия для Scrum

Чеклист:

Продукт развивается, требования меняются
Есть выделенный, доступный Product Owner
Команда кросс-функциональна (не нужно ждать другую команду для базовых задач)
Цикл обратной связи от пользователей < 1 месяца
Руководство готово принять самоорганизацию команды
Команда стабильна (низкая текучка в среднесрочном периоде)

Красные флаги:

Команда - центр затрат (cost center) без прямого влияния на продукт
Требования фиксированы контрактом
“PO” - это должность, которую совмещает занятой руководитель

ScrumBut

У нас Scrum, но с адаптацией

Исключение	Что теряем
”…без ретро - нет времени”	Механизм улучшений
”…спринты у нас 2 месяца”	Быструю обратную связь
”…PO недоступен - решаем сами”	Приоритизацию по ценности
”…Тимлид всё равно решает, кто что делает”	Самоорганизацию

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

Почему так?

Корень проблемы: Scrum меняет власть

Scrum требует передачи ответственности за ЧТО делать PO (часто болезненно для менеджмента)
Scrum требует передачи ответственности за КАК делать команде (часто болезненно для тимлидов)
Scrum делает проблемы видимыми, а организации часто не хотят их видеть

Scrum is like a mirror. If you don't like what you see, don't blame the mirror

Джефф Сазерленд (соавтор Scrum)

Три честных позиции

Позиция 1: Полный Scrum
- Принять все роли, события, артефакты и ценности. Требует организационной поддержки. Работает, когда условия подходят
Позиция 2: Осознанный ScrumBut
- Явно зафиксировать, что берём и что не берём, и почему. Понять, какую проблему мы при этом решаем и от какой защиты отказываемся
Позиция 3: Kanban или другой фреймворк
- Признать, что Scrum не подходит контексту, и выбрать другой инструмент. Это не поражение — это зрелость

Scrum + XP

Синергия

Scrum-давление: Доставлять работающий продукт каждые 2 недели

Без XP → технический долг:

срезаются тесты
откладывается рефакторинг
Definition of Done размывается

"Scrum без технических практик XP - это рецепт накопления долга"

(Джефф Сазерленд)

Почему XP не заводится?

Когда XP сложно внедрить:

Команда не пишет код → Аналитики / Дизайнеры / DevOps без разработки
Сильное сопротивление Pair Programming → “Это не наш стиль работы”
Legacy-кодовая база без тестов → TDD там болезненно стартовать

Решение - взять отдельные практики осознанно:

Тесты, CI/CD и Code Review - минимальный набор из XP-духа, доступный любой команде независимо от фреймворка

CI без автотестов не бывает

Интеграция показывает, что изменения не испортили ничего

Kanban

Из завода Toyota - в IT

Принцип Just-in-Time: Производить только то, что нужно, когда нужно

Истоки (1940‑е): Тайити Оно создал Kanban на заводах Toyota для управления производственными запасами
Адаптация для IT (2000‑е): Дэвид Андерсон перенёс систему в сферу разработки (книга “Kanban”, 2010 г.)

Отличие от Scrum

Scrum: работа организована в итерации (спринты) с фиксированной длиной Kanban: работа организована как поток - непрерывный, без жёстких временных рамок

Шесть практик Kanban

Visualize

Визуализация

Сделать весь рабочий процесс видимым:

доска с колонками
карточки задач

Limit WIP

Ограничить незавершённую работу

Установить явные лимиты на количество задач в каждой стадии. Это главный механизм Kanban

Manage Flow

Управлять потоком

Измерять и оптимизировать скорость прохождения задач через систему

Make Process Policies Explicit

Сделать политики явными

Каждая колонка должна иметь чёткое определение:

что значит “в разработке”
что нужно для перехода “на ревью”

Implement Feedback Loops

Создать петли обратной связи

Регулярные встречи:

Kanban Meeting (аналог Daily),
Service Delivery Review,
Operations Review

Improve Collaboratively

Улучшать совместно

Постепенные, эволюционные улучшения - каи-дзен (kaizen), а не революционные изменения

WIP Limit

Без WIP limit
- 10 задач в “In Progress”
- Все зависли, никто ничего не доделывает
С WIP limit
- 3 задачи максимум
- Задачи доходят до “Done” быстрее

Закон Литтла (Little's Law):

Среднее время выполнения = WIP / Throughput

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

WIP Limit вынуждает доделывать, а не начинать новое
Это меняет культуру: Я взял задачу → Я завершил задачу

Scrum vs Kanban


	Scrum	Kanban
Тип работы	Продуктовая разработка, новые фичи	Поддержка, ops, непредсказуемый поток
Планирование	Итерационное (спринты)	Непрерывное (по готовности)
Роли	Три чётких роли	Нет обязательных ролей
Изменения в процессе	Только после спринта	В любой момент
Метрики	Velocity, Sprint Goal completion	Lead Time, Throughput, WIP
Зрелость в команде	Нужна структура и дисциплина	Нужна культура завершения

Как применять фреймворки

Принцип Каизен

Маленькие шаги, которые закрепляются

Содержит 3 правила внедрения изменений в процесс:

Одно изменение за раз

Нельзя одновременно вводить WIP Limit, новый формат Daily и ретроспективу
→ Непонятно, что помогло, а что нет

Явная гипотеза

“Мы вводим WIP Limit = 3, потому что думаем, что это сократит среднее время выполнения задачи с 5 до 3 дней. Проверим через 4 недели”

Период стабилизации

Любому изменению нужно дать время, чтобы “отстояться”
Минимум 3–4 итерации (или 4–6 недель), прежде чем делать выводы

Как объяснить боссу, почему вы не делаете “настоящий Scrum”

Структура аргументации (BLUF):


Bottom Line	”Мы используем гибридный подход, потому что у нас два принципиально разных типа задач”
Факты	”Наш поток новых фич предсказуем и итеративен — там работает Scrum. Поток поддержки непредсказуем и требует немедленной реакции — там WIP-лимиты и SLA работают лучше спринтов”
Что нас защищает	”У нас есть метрики: Throughput и Lead Time по поддержке, Velocity по фичам. Мы видим изменения”

Итоги

Agile - философия Это не набор инструкций. Scrum и Kanban - инструменты, которые реализуют Agile-философию
Контекст определяет инструмент. Cynefin помогает понять, в каком домене работает
Частичный Scrum честнее, чем Cargo Cult Scrum. Осознанный ScrumBut лучше, чем делать все по форме и ничего по сути
WIP Limit - самый недооценённый инструмент. Введите его в своей команде - и вы увидите, где настоящие узкие места
Ретроспектива и DoD работают вне любого фреймворка. Начните с них, если всё остальное слишком сложно

`[Видео]` Best practices по декомпозиции задач

Нарезать слона надо

Большая задача пугает нас
Её нельзя решить за один такт
Она решается постепенно
Поэтому она дробится на части

И вот тут уже кроется ряд ошибок

Дайте нарезать задачу своему сотруднику

Что пойдет не так:

Задача оказалась в 3 раза больше оценки
Фича “готова”, но не работает как целое
Разработчик заблокирован, потому что не ясно что делать дальше
Задача висела в In Progress две недели
Спринт закрыт, но у пользователя ничего не изменилось

Проблема предсказуемости

Чем крупнее задача, тем хуже оценка
Человеческий мозг плохо работает с большими неопределёнными объёмами
Оценка “2 недели” на монолитную задачу - это почти всегда угадывание

Проблема обратной связи

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

Проблема мотивации и flow

Задача, которая не закрывается неделями → демотивирует
“Сделано” - это топливо для команды

Нет закрытий - нет энергии

Надо делать больше!

Незавершённая работа - это не прогресс
Это замороженные инвестиции

Надо увеличивать пропускную способность

Большие задачи - это не плохо
Но они опасны, если не управлять ими правильно

Декомпозиция И ее слабые места

Когда декомпозиция не помогает

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

Одной декомпозицией не обойтись

Декомпозиция - это инструмент

Как молоток:

Он полезен, когда нужно забить гвоздь
Но если вы не знаете, куда забивать - молоток не поможет

Прокачиваем декомпозицию

Иерархия задач

Задачи делаются для достижения целей
Цели тоже надо помнить
А еще цели можно делить

Epic

Цель на месяцы
Владелец: PO/TeamLead

Нужен для описания образа большого результата

Метрика DTB

На ключевую метрику команды (DTB) нельзя повлиять напрямую. Но можно выкатывать фичи, которые её улучшат

Например:

Нам нужна система уведомлений

Флаг: “Система” - что-то большое и непонятное

Система уведомлений

Сейчас пользователь не получает никаких сигналов от системы после ключевых действий:

создание заказа
смена статуса
брошенная корзина

Проблемы:

Пользователь уходит с сайта и не возвращается, потому что нет напоминания

Поддержка получает избыточный поток запросов “Что с моим заказом?”

Мы теряем окно повторного касания в момент наибольшей вовлечённости

Ключевая гипотеза:

Триггерные уведомления возвращают часть этих пользователей и конвертируют их в покупателей, увеличивая тем самым DTB (Daily Target Buyers) - ежедневное количество совершивших покупку

Метрика	Baseline	Target	Срок
DTB (Daily Target Buyers)	~140 чел/день	≥ 175 чел/день (+25%)	+90 дней после релиза
Conversion rate брошенной корзины	8%	≥ 14%	+60 дней
Return rate после триггерного письма	—	≥ 20%	+60 дней
Кол-во тикетов в поддержку “где мой заказ”	~320/мес	≤ 180/мес	+30 дней

От эпика — к реализации

Эпик задал нам направление для работы
Эпик нельзя положить в спринт
Теперь надо углубляться в реализацию

User Story

User Story - это бизнес описание, которое нужно перевести в технические аспекты

Как пользователь, хочу получать push и email о статусе заказа, чтобы не спрашивать лично у поддержки

Шаблон:

Как [роль пользователя]

Я хочу [действие / возможность]

Чтобы [ценность / цель]

Иерархия задач

Как резать

декомпозиция

Вертикальная vs Горизонтальная

Фича “Корзина интернет-магазина”:

Горизонтально
- Сначала БД
- Потом API
- Потом UI
Вертикально
- Добавить товар
- Удалить товар
- Изменить количество
- Применить промокод

	`Горизонтальная`	`Вертикальная`
`Принцип`	По слоям системы	По ценности для пользователя
`Пример`	Frontend / Backend / DB	Авторизация через email → через Google → через SSO
`Результат итерации`	Готовый слой, не работающий как целое	Работающий, но узкий сценарий
`Риск`	Поздняя интеграция, сюрпризы	Дольше видно “полную картину”
`Рекомендация Agile`	Избегать	Предпочтительна

Вертикальная декомпозиция

Каждый вертикальный slice должен быть:

deployable
valuable

Его можно выкатить и он несёт ценность сам по себе

Горизонтальная декомпозиция

Горизонтальная декомпозиция - не всегда зло
Иногда она неизбежна (например, при работе с легаси или при поднятии инфраструктуры)

Но это должно быть осознанное решение, а не дефолтный подход

Техники декомпозиции

По сценариям использования Happy Path → Edge Cases

Принцип: Сначала основной сценарий, потом граничные случаи

Пример: Авторизация → восстановление пароля → блокировка после N попыток

По данным data-driven split

Принцип: Если логика одна, но данные разные - делить по типу данных

Пример: Обработка платежей (Карта → Кошелёк → Рассрочка)

По операциям CRUD

Принцип: Каждое действие - отдельной задачей

Пример: Создание → Чтение → Обновление → Удаление

По ролям / пользователям

Принцип: Одна фича реализуется отдельно для каждой роли

Пример: Admin → User → Guest

Spike Исследовательская задача

Если задача не понята - сначала spike с параметрами:

явный timebox (например, 4 часа)
явный output (решение / документ / ADR)

Задача, которую нельзя оценить, не готова к декомпозиции → Сначала spike, потом нарезка

Spike - это не признак слабости команды. Это честность:

“мы не знаем, поэтому сначала исследуем, а потом планируем”

Плохой вариант - сделать вид, что знаем, и получить сюрприз в середине спринта

Признаки хорошей декомпозиции

Задача нарезана хорошо, если:

Каждую подзадачу можно взять в работу независимо
Подзадача закрывается за 1-2 дня (максимум - 3-5)
Понятно, кто берёт каждую подзадачу
Видно, какие задачи зависят от каких (граф зависимостей)
Есть явный output: что именно будет сделано
Можно сказать, что задача “готова” по конкретному критерию

Задача нарезана плохо, если:

Подзадача формулируется как процесс (“работать над X”), а не результат
Подзадача не имеет владельца
Все подзадачи можно делать только последовательно (нет параллелизма)
Закрытие подзадачи не приближает видимо к готовности фичи

Как правильно описать задачу

Что убивает задачи ещё до старта

“Сделать авторизацию” - Что именно? email? OAuth? 2FA?
“Починить баги на странице заказов” - Сколько багов? каких? приоритет?
“Улучшить производительность” - До каких метрик? по каким страницам?
“Интеграция с платёжной системой” - Какой? какой API? sandbox или prod?

Что происходит дальше:

Разработчик трактует задачу по-своему

Тимлид получает не то, что ожидал

Переделка → потеря времени → взаимное раздражение

Неопределённость задачи - это не проблема разработчика

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

Как тимлид - это часто вы

User Story

User Story - не серебряная пуля, но хороший старт

Пример:

Как незарегистрированный пользователь

Я хочу войти через Google-аккаунт

Чтобы не тратить время на создание нового аккаунта

Частые ошибки User Story

Роль = “пользователь” (кто конкретно?)
Ценность = “чтобы это было” (это не ценность)
Одна story покрывает 5 сценариев

INVEST

Это не строгий стандарт, а набор вопросов для самопроверки

Буква	Значение
I	Independent - независима от других
N	Negotiable - детали обсуждаемы
V	Valuable - несёт ценность
E	Estimable - можно оценить
S	Small - маленькая
T	Testable - можно проверить

Если хотя бы три пункта не выполнены - задача требует доработки перед взятием в спринт

Анатомия хорошей задачи

Фундамент:
- Контекст Почему эта задача вообще нужна? Что происходит без неё?
- Что нужно сделать Конкретный результат: не “работать над X”, а “реализовать Y”
Границы и проверка
- Что НЕ нужно делать (out of scope)
  - Явные ограничения
  - Что специально выносим за рамки
- Acceptance Criteria
  - Критерий 1 (проверяемый)
  - Критерий 2
  - Критерий …
Технические детали / ссылки
- API-документация
- Дизайн-макет
- Связанные задачи
Определение готовности (DoD)
- Пройдены тесты
- Ревью
- Задеплоено в staging и т.д.

Нарезали! Поехали?

Проблема

Тимлид декомпозировал задачу идеально:

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

Но команда всё равно “застревает” или делает не то

Нет shared understanding

Каждый понимает свою подзадачу, но никто не видит, как части складываются в целое

Результат:

архитектурные конфликты
повторная работа
“я думал ты это сделаешь”

Лечение:

event storming
task kickoff
короткий walk-through по доске перед стартом

Нет приоритизации внутри декомпозиции

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

Лечение: Явный порядок с учётом зависимостей

Нет культуры “задача не моя, но я помогу”

Разработчик закончил свой кусок, остальные ещё нет. Он берёт новую задачу вместо того, чтобы помочь коллегам завершить фичу

Лечение: WIP-лимиты, командная ответственность за спринт (а не за персональные задачи)

Роль тимлида

Кто должен декомпозировать?

Тимлид нарезает всё	Команда нарезает сама
Быстро	Медленнее
Команда не понимает контекст	Команда вовлечена
Команда не развивается	Команда развивается

Ситуационная матрица

Ситуация	Рекомендация
Новая команда / джуниоры	Тимлид декомпозирует, объясняет логику
Зрелая команда	Декомпозиция на грумингах совместно
Кризис / сжатые сроки	Тимлид нарезает быстро, команда уточняет
Технически сложная задача	Spike ведёт самый опытный + ревью командой

Ошибки тимлида

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

Event Storming

Проблематика

Система уведомлений выглядит простой, пока не начинаешь разбирать edge cases:

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

Event Storming вытаскивает эти сценарии на поверхность до того, как они стали багами в проде

Event Storming - Изначально - инструмент для проектирования domain-driven систем

Сегодня используется шире:

для онбординга
декомпозиции
выявления узких мест в бизнес-процессах

Автор метода: Альберто Брандолини, 2013

Как у меня в команде:


События	Domain Events	Значимые события, происходящие в системе, которые изменяют её состояние (“пополнен баланс”)
Команды	Commands	Действия/инструкции, инициируемые пользователем или другим событием и приводят к изменению состояния системы (“создать заказ”, “разместить объявление”)
Агрегаты	Aggregates	Группы связанных объектов, которые обрабатываются как единое целое для выполнения команды или реакции на событие (“набор услуг по продвижению вакансии”)
External Systems	External Systems	Взаимодействие с внешними системами или сервисами, которые участвуют в процессе (CRM партнера)
Роли	User Roles	Роли или типы пользователей, взаимодействующих с системой (“модератор”)
Политики	Policies	Бизнес-правила или процессы, которые определяют, как система должна реагировать на события или команды (“правило отмены платежей”)
Вопросы	Questions	Открытые вопросы или неопределённости, которые требуют уточнения или дополнительного исследования (“как мэтчить разраба и программиста”)
Боль	Issues	Проблемы или узкие места, обнаруженные в процессе модерирования (“нельзя вернуть платеж по закрытым кварталам”)

Принципы

Domain Events - что происходит в системе

Зафиксировать события-триггеры уведомлений:

OrderCreated
OrderStatusChanged (→ confirmed / shipped / / delivered / cancelled)
CartAbandoned (через какое время? как определяем?)
CheckoutStarted → CheckoutAbandoned
UserRegistered
PaymentFailed
PaymentSucceeded

Commands - кто или что инициирует событие

Для каждого события определить источник:

действие пользователя
внутренний триггер (таймер)
внешняя система (платёжный шлюз)

Policies — бизнес-правила отправки

Здесь обычно вылезают самые важные вопросы:

Через сколько минут после CartAbandoned отправляем письмо?
Если пользователь уже вернулся и купил - отменяем письмо?
Сколько раз максимум можно напомнить про корзину?
Если PaymentFailed - кому уведомление: пользователю, менеджеру, обоим?
Как обрабатывать пользователей, которые отписались от одного типа писем, но не от другого?

Read Models - что видит пользователь

Набросать, как выглядит письмо / пуш для каждого сценария:

что в subject
что в теле
есть ли CTA-кнопка
куда она ведёт

External Systems - внешние зависимости

Зафиксировать все внешние точки:

email-провайдер
платёжная система
сервис аналитики (для UTM)
GDPR-сервис управления согласиями

Артефакты

Артефакт	Описание
Карта событий	Полный список Domain Events с источниками и триггерами
Таблица политик	Бизнес-правила для каждого типа уведомления
Список открытых вопросов	То, что не удалось решить на сессии - уходит в Spike
Черновая декомпозиция	Первый набросок Stories, который потом уточняется на грумингах

DoR, DoD, Acceptance Criteria

Три контракта: DoR, Acceptance Criteria, DoD

DoR

Definition of Ready (DoR) - это командное соглашение о минимальном наборе условий, при которых задача может быть взята в спринт или в работу

Это не бюрократия - это защита команды от работы вслепую

Типовой DoR для IT-команды:

Задача описана (есть контекст, scope, out of scope)
Acceptance Criteria сформулированы и согласованы
Задача оценена командой (story points / t-shirt size)
Дизайн / макет готов (если применимо)
Зависимости от других команд / сервисов прояснены
Задача помещается в один спринт

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

Задача попала в спринт без выполненных пунктов - это технический долг планирования. Часто именно так появляются задачи, которые “завязли”

Антипаттерн:

DoR существует на бумаге, но на планировании его никто не проверяет → “Ну мы же примерно понимаем”

DoR - это “право вето” у команды. Если задача не готова - она не идёт в спринт, даже если PO очень хочет. Это не конфликт, это договорённость

DoD

Definition of Done (DoD) - это командный стандарт качества, применяемый к каждой задаче

Он не зависит от конкретной фичи - это “планка” для всего, что выходит из команды

Пример DoD для backend-команды:

Код написан и соответствует code style команды
Unit-тесты написаны (покрытие ≥ N%)
Code review пройдено (минимум 1 аппрув)
Интеграционные тесты пройдены
Задеплоено в staging / test-среду
Документация обновлена (если применимо)
Acceptance Criteria проверены и закрыты
PM / тимлид подтвердил

AC

Acceptance Criteria (AC) - это конкретные, проверяемые условия, при выполнении которых User Story считается реализованной с точки зрения заказчика / пользователя

Форматы

Given / When / Then (BDD-стиль)

Given [начальное условие]
When [действие пользователя]
Then [ожидаемый результат]

Пример:

Given пользователь не авторизован

When он нажимает “Войти через Google”

Then система перенаправляет его на OAuth-страницу Google

Checklist (проще, быстрее)

Пример:

Кнопка “Войти через Google” отображается на странице входа

После авторизации пользователь попадает на дашборд

Если авторизация провалилась — показывается сообщение об ошибке

Новый пользователь автоматически создаётся в системе

Когда использовать тот или иной формат

BDD-стиль
- QA-автоматизация
- Сложная бизнес-логика
Checklist
- Большинство обычных задач
- Быстро и понятно

Признаки плохих AC

текст	вопрос
”Работает корректно”	Что значит корректно?
”Быстро загружается”	Сколько миллисекунд?
”Интуитивно понятный интерфейс”	Для кого?

Правило одной строки

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

DoD vs AC

	`DoD`	`Acceptance Criteria`
`Что проверяет`	Как сделано (процесс и качество)	Что сделано (функциональность)
`Применимость`	Ко всем задачам	К конкретной задаче
`Кто формирует`	Команда (раз, надолго)	PO + команда (на каждую story)

Диаграмма Гантта и её упрощения

Диаграмма Гантта - инструмент планирования, показывающий задачи на временной шкале с указанием длительности, порядка и зависимостей

Применимость

Проекты с фиксированными дедлайнами и зависимостями
Кросс-командная координация
Стейкхолдеры требуют timeline-отчётности
Waterfall или hybrid-проекты

Избыточность

Agile-команды с 2-недельными спринтами
Продуктовая разработка с постоянно меняющимися приоритетами
Небольшие команды, где всё на виду

Три системные проблемы классического Ганта

Иллюзия точности Ганта Создаёт ощущение предсказуемости. Но если оценки были риблизительными - весь план некорректен → “Красиво нарисованная неправда”
Устаревание Первое же изменение требований делает Ганта неактуальным. Поддерживать его вручную - трудоёмко. Часто команды просто перестают это делать
Скрытые зависимости Ганта Показывает задачи, но плохо показывает людей и риски. Два параллельных блока могут требовать одного специалиста - и это не видно

Gantt Lite

Грубая визуализация по месяцам / кварталам без детализации по дням
Показывает “что после чего”, а не точные даты.
Инструменты: Miro, Notion, даже PowerPoint
Кому: стейкхолдерам, для синхронизации видения

Sprint board + Backlog

Назначение: Кто что делает прямо сейчас - на Канбан-доске
Горизонт: Текущий и следующий спринт
Кому: Команде, для ежедневной работы

Dependency map (граф зависимостей)

Не таймлайн, а граф: какие задачи блокируют какие
Позволяет приоритизировать “Критический путь”

Критический путь

В любом проекте есть цепочка задач, задержка любой из которых задерживает весь проект - это и есть критический путь.

Три ключевых вопроса:

Что нельзя начать, пока не готово X?
Какая задача блокирует наибольшее количество других?
Где самое тонкое место (один человек, внешняя зависимость, неизвестная сложность)?

Итоги

Декомпозиция - инструмент, не цель. Нарезайте задачи, когда понимаете, что делаете - иначе получите много маленьких неопределённостей
Вертикальная нарезка лучше горизонтальной. Каждый слайс должен нести ценность сам по себе
Задача без описания - не задача. Контекст, scope, out of scope, AC - минимальный набор
INVEST как чеклист, а не догма. Используйте как инструмент самопроверки
DoR, DoD, AC - три разных контракта. У них разные участники и разные цели. Смешивать их - ошибка
Гантт уместен не везде. Для большинства agile-команд достаточно roadmap + Kanban board + dependency map
Тимлид не декомпозирует за команду. Тимлид учит команду декомпозировать. Иначе он бутылочное горлышко

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

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

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

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

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

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

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

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

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

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

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

Стоит сразу начать собирать метрики, а не постфактум, чтобы можно было чётко понять, что приносит эффект.

Нам нужно провести рефакторинг приложения, чтобы оно работало быстрее.

Быстрее относительно чего?

Зачем?

Что нам это даст?

И старое приложение работает быстро.

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

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

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

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

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

Если к нам придут и скажут, что "мы делаем мало PR", то:

Команда начнёт больше делать работы? - Маловероятно.

Команда просто оптимизирует PR, чтобы делать их больше и на каждый чих? - Да.

Когда мы требуем не ценность, а метрику, то на выходе мы получаем метрику.

Метрики

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

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

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

Метрики - не полиграф и не 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 минуты

И как укладываться в 4 минуты downtime в месяц? Тут уже инжинеры подходят к вопросам эскалиривания, резервирования, рекавери, на которые отвечает System Design.

Как использовать 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) - сколько денег приносит пользователь за всё время
- По-сути, пользователь должен оплачивать 3 стоимости его привлечения, чтобы окупить себя и других пользователей
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 в поддержке → приоритизация бэклога
Dog Fooding - нужно самим пользоваться своим продуктом, чтобы понимать, приносит ли он удовольствие или нет.

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

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 net promoter score - оценка удовлетворённости работника
- Оценивает: уровень доверия компании, насколько хорошо принимают решения, насколько его решения оценивают и принимают, насколько компания заставляет перерабатывать
mNPS - manager net promoter score - это доверие менеджеру

Метрика	Как собирать	Сигнал тревоги
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
ретроспектива
наблюдение

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

Нужно полагаться на то, что говорит команда, слышать их tone of voice. Зачастую команда раньше подсветит какие-то проблемы, нежели чем сдвиг по метрике.

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

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

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

Правило:

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

Итоги

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

Base

Проводник

Teamlead Balun Courses

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

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

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

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

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

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

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

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

Динамика

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

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

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

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

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

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

Выводы

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

Проблема

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

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

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

Наполнение мозга

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

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

Режим Eco

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

Software as a memory

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

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

Список задач в табличке

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

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

Таймбоксинг

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

Важность

Люфт

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

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

Приоритеты

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

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

Инструменты

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

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

Встречи

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

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

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

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

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

Кейс

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

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

Кейс

Принципы

SCQA

MECE

Результат

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

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

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

Проблемы:

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

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

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

Команда

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

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

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

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

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

Конфликт

Нормализация

Производительность

Завершение

Модель Дрекслера-Сиббета

Откаты назад

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

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

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

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

`[Видео]` Как нанимать и кому отказывать