Разберём управленческий кейс — собирательный, но каждая деталь в нём встречается в жизни регулярно. Сначала ситуация, затем диагноз, план входа по горизонтам 30/60/90 и разбор каждой проблемы по отдельности. В конце — отдельная секция с методологиями и приёмами, которые здесь работают.
Кейс
Компания. Маркетплейс, ~120 инженеров. Команда распределённая: сотрудники от UTC+1 до UTC+6, рабочее время — по UTC+4, язык — русский. Иерархия: CTO → руководитель направления → тимлид → разработчик; в направлении 2–4 команды. Команды сами выбирают внутренний процесс — обязательны только общий интерфейс приёма задач и умение управлять ожиданиями стейкхолдеров.
Последний год ушёл на возвращение стабильности: инженерная культура заметно выросла (перестали прятать инциденты, начали отвечать за свои системы), но тестирование по-прежнему в основном ручное, выкатки полуручные, мониторинг лоскутный. У части функциональности нет владельцев, между командами случаются конфликты владения. Сейчас компания после долгой финансовой стагнации разворачивает продуктовый подход — и новые продуктовые инициативы конфликтуют с достройкой текущих систем; за сроки и приоритеты приходится биться. Многие сервисы написаны без архитектурной мысли: дублирование, противоречащая логика, размытые границы. Тимлиды в большинстве «зелёные» — роль появилась недавно. Найм идёт медленно; текучка небольшая, половина ушедших за год — уволены за недостаток навыков.
Ситуация. В домене «коммуникации с покупателями» две команды: «Уведомления» и «Шаблоны и рассылки». Ты выходишь лидом в «Уведомления» — 11 человек, кроссфункциональная (4 BE, 2 FE, 2 Mobile, 2 QA, 1 SA), укомплектована. Вводные:
- Прошлый тимлид не справился и вернулся в эту же команду разработчиком (решение наполовину добровольное). Хочет работать в экспертной роли — вести кросс-проекты как staff-инженер.
- Несколько человек ведут себя токсично на ревью кода и в технических спорах.
- В команду льётся поток мелких задач от других команд — уведомления нужны всем, — и он вытесняет приоритетные задачи самой команды.
- Команда систематически набирает больше, чем делает; часть взятого уходит в долгий ящик. Стейкхолдеры считают команду ненадёжной и не готовы опираться на её суждения.
- Продакт-овнер при слабом прошлом лиде забрал себе планирование, оценки и внешние коммуникации. Он перегружен, в контекст команды не успевает, команда чувствует недоуправление, отношения напряжённые.
Диагноз: одна система, а не пять проблем
Соблазн — увидеть пять независимых пунктов и завести пять задач. На деле это одна петля, и крутится она так: прошлый лид не держал контур управления → PO вынужденно забрал планирование и коммуникации → у PO нет времени на контекст → решения о составе спринта принимаются поверхностно → команда берёт всё, что просят (отказывать некому и не на основании чего) → обещания не выполняются → доверие стейкхолдеров падает → каждый стейкхолдер продавливает свои «мелкие срочные» напрямую, в обход приоритетов → поток чужих задач вытесняет свои → обещания снова не выполняются. Токсичное ревью и история с экс-лидом — отдельные кадровые мины, но они тоже подпитываются общим ощущением «никто не рулит».
Из диагноза следует стратегия: восстанавливать контур управления обязательствами — кто принимает работу, на каком основании, что обещаем и как держим слово. Не «ускорить команду», не «переписать процессы», не «разобраться с токсиками» в первую неделю. Доверие стейкхолдеров чинится только предсказуемостью, а предсказуемость — это управляемый поток входа и честная ёмкость.
Чего не делать в первые недели
- Не менять процесс сразу. Команда пережила слабого лида и перехват управления PO; третья встряска за год без диагностики — кредит доверия в минус.
- Не воевать с PO за полномочия. Он не узурпатор — он держал то, что падало. Полномочия возвращаются договорённостью и постепенно, не манифестом.
- Не начинать с «починки» токсиков и экс-лида. Пока у тебя нет фактов и отношений — есть только ярлыки из передаточного контекста.
- Не обещать стейкхолдерам новые сроки. Каждое невыполненное обещание нового лида тратит невосполнимое. Первые недели обещание одно: «разберусь и вернусь с планом — вот дата».
Первые 30 дней: диагностика и контракты
1:1 со всеми одиннадцатью. Один формат вопросов: что работает, что бесит, что бы поменял первым, кому доверяешь в команде, что тебя здесь держит. Из одиннадцати разговоров карта команды складывается точнее, чем из любого отчёта. С экс-лидом и «токсичными» — те же вопросы, без особого статуса встречи.
Контракт с PO. Открытый разговор: «ты тащишь чужую работу, я пришёл её забрать — давай спланируем передачу». Письменно: планирование и оценки — лид (с PO как источником приоритетов), внешние коммуникации по выполнению — лид, приоритеты и продуктовые решения — PO. Передача по одной зоне за раз, не всё сразу: PO должен увидеть, что новая рука держит, прежде чем отпустить.
Контракт с экс-лидом. Самая деликатная договорённость, делается в первые две недели — дальше позиции зацементируются. Подробно — ниже.
Замер потока. Две-три недели просто считать: сколько задач пришло извне, от кого, сколько своих, сколько закончили. Эта статистика — фундамент всего следующего: и планирования от ёмкости, и разговора со стейкхолдерами, и квоты на внешнее.
Одна маленькая видимая победа. Что-то, что болит у команды и чинится за неделю: автодеплой одного сервиса, доска без столбца-свалки, отменённая бессмысленная встреча. Сигнал «новый лид → что-то меняется к лучшему» важнее самого изменения.
Дни 30–60: управление потоком
Единая точка входа для чужих задач. Интерфейс приёма: задача от другой команды попадает не разработчику в личку, а в одну очередь с шаблоном (что, зачем, к какому сроку, что будет, если не сделать). Это не бюрократия — это перевод невидимого потока в видимый. Половина «срочного» отваливается на этапе заполнения трёх полей.
Квота ёмкости. Фиксированная доля мощности на внешние запросы — например, 20% — и дежурный по очереди, который в свою неделю занимается только ими. Остальная команда защищена от дёрганья; внешние заказчики получают предсказуемый канал вместо лотереи «кого поймаю в чате». Квота — публичная: «ваша задача взята, очередь такая, будет тогда-то».
Планирование от фактической пропускной способности. Берём в спринт столько, сколько команда фактически закрывала в последние недели (вчерашняя погода), а не сколько «должны успеть». Первые итерации это выглядит позорно мало — и именно тут ломается петля overcommit: выполненное обещание ценнее амбициозного.
WIP-лимит. Меньше начатого одновременно — быстрее заканчивается начатое. «Долгий ящик» из кейса — это незавершёнка, размазанная по доске; лимит на колонку «в работе» физически не даёт ей образовываться.
Нормы ревью. Письменные правила (про код, а не про автора; предложение вместо требования; блокирующее замечание = нарушение стандарта или дефект, остальное — на усмотрение автора) и перевод вкусовых споров в стандарт — подробнее ниже.
Дни 60–90: восстановление доверия
Публичный регулярный статус. Короткая еженедельная сводка стейкхолдерам: что взяли, что закончили, что не возьмём и почему, что в очереди и когда. Скучно, повторяемо, без сюрпризов — ровно так выглядит надёжность снаружи.
Обещания только из статистики. «Сделаем к пятнице» произносится, только если это следует из фактической пропускной способности с буфером на пожары. Всё остальное — «в очереди, ориентир такой-то». Через два месяца выполненных скучных обещаний команда снова получает право на суждение — то самое, которого стейкхолдеры сейчас не дают.
Ретроспективы с одним изменением за раз. Не «давайте улучшим всё», а одно изменение процесса за итерацию, с проверкой через две недели: сработало/нет.
Первые инженерные инвестиции. Когда поток управляем, появляется ресурс на причины пожаров: автотесты на критический путь уведомлений, мониторинг на необслуживаемые сервисы, автоматизация выкатки. По одной инвестиции за итерацию, из квоты команды — теперь её есть кому защищать.
Экс-лид в команде
Риск очевиден: «теневой лид», к которому команда ходит по привычке, и который — сознательно или нет — обесценивает решения нового. Но в кейсе есть и актив: человек хочет экспертную роль и кросс-проекты, то есть сам предлагает себе позицию, не конкурирующую с твоей.
Договорённость в явном виде: его мандат — кросс-проекты и техническая экспертиза (вот список), не входящие в зону прямых решений лида (приоритеты, люди, обещания); несогласие с решениями — лично тебе, не в общем канале; в ревью он участник на общих правах, не последняя инстанция. И симметричное обязательство с твоей стороны: реальные кросс-проекты, видимость его экспертного статуса, поддержка движения в staff-трек. Срок проверки договорённости — месяц-полтора, на регулярных 1:1. Если работает — у тебя сильнейший союзник с контекстом, которого нет ни у кого. Если нет — это уже разговор с руководителем направления о переводе в другую команду: два центра власти команда не переживёт.
Токсичное ревью
Сначала отделить жанры: резкость по делу (грубая форма, верное содержание) лечится нормами формы; доминирование (ревью как площадка статуса, придирки к мелочам, передавливание в спорах) — индивидуальной работой.
Механика из трёх слоёв. Первый — письменные нормы ревью (выше). Второй — вынос вкусовых споров в стандарт: половина войн на ревью — это форматирование, нейминг и любимые конструкции; зафиксированное в style guide правило с кодом проверяется автоматически на каждом PR и перестаёт быть предметом спора вовсе — спорить со стандартом можно, но в PR к стандарту, а не в каждом ревью. Третий — 1:1 с конкретными примерами: не «ты токсичный», а «вот тред, вот формулировка, вот её эффект — заблокирован джун на три дня; жду вот такой формы». Рецидив после двух таких разговоров — уже дисциплинарный разговор с участием руководителя направления, и это нормально проговорить заранее.
Поток чужих задач — глубже
Квота и дежурный (выше) — механика. Под ней два системных вопроса.
Первый: почему мелкие задачи вообще летят сюда? Если каждой команде нужны правки в уведомлениях — возможно, у платформы уведомлений нет нормального API самообслуживания (шаблоны, которые соседняя команда может править сама). Лучший ответ на поток задач — продукт, который делает эти задачи ненужными; это и есть аргумент для PO в борьбе приоритетов.
Второй: конфликты владения. «Часть функциональности не имеет владельцев» из кейса — источник вечных «а кто это сделает». Зоны владения стоит зафиксировать письменно на уровне домена — карта владения сервисами и данными ровно для этого существует (роль архитектора, context map). Задача без владельца по карте — задача руководителя направления, а не дежурного твоей команды.
Перегруженный PO — глубже
Передача обязанностей — не одномоментный акт, а три шага по каждой зоне: смотрю, как делаешь ты → делаем вместе → делаю я, ты в копии. Порядок передачи — от внутреннего к внешнему: сначала планирование и оценки (видно только команде, цена ошибки мала), потом коммуникации по статусам, последними — обещания сроков наружу. На каждом шаге у PO остаётся то, что он должен делать по роли: приоритеты, ценность, продуктовые гипотезы. Финальное состояние фиксируется письменно — кто за что, чтобы через полгода не расползлось обратно. И регулярная синхронизация лид+PO раз в неделю: тридцать минут, приоритеты и риски, без команды.
Методологии и приёмы
Сводка инструментов, использованных в разборе — что взять в практику:
| Приём | Что даёт | Где в кейсе |
|---|---|---|
| План 30/60/90 | Структура входа: диагностика → поток → доверие; защита от хаотичных правок | Весь план выше |
| 1:1 со всеми при входе | Карта команды из первых рук, отношения до проблем | Первые 30 дней |
| Контрактинг ролей | Письменное «кто за что» вместо молчаливых ожиданий | PO, экс-лид |
| Передача через «смотрю → вместе → сам» | Полномочия переходят без провала качества | Возврат обязанностей от PO |
| Вчерашняя погода | Планирование от факта, а не от амбиций; лечит overcommit | Дни 30–60 |
| WIP-лимиты (Kanban) | Меньше незавершёнки, быстрее поток | «Долгий ящик» |
| Единая точка входа + шаблон запроса | Невидимый поток становится видимым и фильтруемым | Чужие мелкие задачи |
| Квота ёмкости + дежурный | Защита фокуса команды при сохранении сервиса соседям | Чужие мелкие задачи |
| Еженедельный публичный статус | Предсказуемость как продукт; доверие из скучной регулярности | Дни 60–90 |
| Нормы ревью + стандарт вместо споров | Вкусовые войны уходят из PR в style guide | Токсичное ревью |
| Обратная связь на конкретных примерах | Разговор о поведении, а не о личности | Токсичное ревью |
| Ретро «одно изменение за раз» | Эволюция процесса без встрясок | Дни 60–90 |
| Карта владения (context map) | Задачи без владельца получают адрес | Конфликты владения |
| Маленькая видимая победа | Кредит доверия команды новому лиду | Первые 30 дней |
Общий знаменатель: почти всё это — превращение неявного в явное. Неявные ожидания → контракт ролей; невидимый поток → очередь с шаблоном; ощущение ёмкости → статистика; вкусовые споры → стандарт; устные договорённости → письменный статус. Команда из кейса страдает не от злых людей и не от слабых технологий — от неявности, в которой каждый достраивает картину сам.
Что почитать дальше
- Что делает архитектор — соседняя роль: карта владения и context map, которые закрывают конфликты владения из кейса.
- Executable engineering standard — как стандарты с автопроверкой убирают вкусовые споры из ревью.
- ADR — журнал решений; работает и для организационных договорённостей.
- Батч-процессинг: разбор кода — пример того, как «глубокий разбор кейса» выглядит в инженерном жанре.