Александр Бабицкий | Тимлид на практике
06.05 · ред.
Разбор кейса. Когда ownership ломает
#ЧтоСделалБыТы, новая рубрика на канале — управленческие кейсы из практики. Буду делиться сложными ситуациями и вариантами их разбора.
#️⃣ КейсУ вас в команде есть опытный синьор. Проект сложный, высокий приоритет, много кода в монолите, зависимости от других команд. Под задачу этот человек подходит идеально: погружается глубоко, видит нюансы, может брать на себя ответственность.
Техническое задание есть, но оно «плавает»: то уточняется, то дополняется. Много узких мест и неопределённости. Вы совместно сформировали архитектурное решение, но потом отошли, подстраховать параллельно идущие проекты. Он начал уверенно. Коммуницировал, копал, документировал, писал код.
Но через пару месяцев темп просел. Сроки перестали быть понятными. Команды делают задачи нехотя и без энтузиазма. Он, один в этой зоне, без бэкапа. Бизнес продолжает накидывать новые требования. И вдруг, он берёт больничный. Без обсуждений. На несколько недель.
Вы — тимлид. Что делать? Снять его — нельзя. Подставить кого-то еще из команды — некого. Взять всё на себя — вы и так на пределе.
А что бы сделали вы в такой ситуации? Пишите в комментариях — это кейс, в котором нет однозначного ответа.
A. Создаю буфер через “теневого исполнителя” Понимаю, что синьора нельзя дальше перегружать, но и снять его резко тоже нельзя. Договариваюсь с разработчиком из другой команды (пусть даже не на 100% подходящим), чтобы он начал в фоне разбираться в задаче, документации и зоне ответственности. Да, это временные издержки и есть риски. Но нужен второй человек, чтобы снизить “single point of failure”.
B. Сажусь с синьором и рисую “карту боли” Провожу с ним глубокое 1:1, не про прогресс, а про износ. Что именно отнимает у него силы? Где хаос? Где тупик? Вместе выстраиваем новую структуру задач: • что можно отложить • что можно делегировать • где нужен фреймворк, чтобы меньше принимать решений руками А дальше, выступаю на уровне бизнеса, чтобы защитить новую реальность.
C. Замораживаю проект и пересобираю ожидания Да, это крайняя мера. Но если понимаю, что проект в текущем виде ломает людей и не имеет шансов на успешное завершение, иду на управленческую перезагрузку. Собираю стейкхолдеров, доношу объективную картину: “Так работать нельзя. Мы не вытянем. Или мы меняем подход, или вы получаете выгоревшую команду и нерабочую фичу”. Иногда зрелость — это не тянуть, а ставить жесткие рамки.
Альтернативные версии, жду в комментариях.
Такие кейсы происходят чаще, чем кажется. И не всегда видно, что за красивым словом “ownership” стоит человек, который больше не вывозит. Иногда лучшая поддержка — это не мотивация. А оптимизация системы.
#ЧтоСделалБыТыАлександра Раловец
· 07.05
Александр Бабицкий, добрый день! Подскажите, как дописаться вам в личку?)
ответить
Айлин Михайлова
· 06.05
Проблема не в синьоре, а в системе, которая допустила single point of failure. Вот как бы я выстраивала решение:
1. Срочные меры: стабилизация — Не трогать синьора пока он на больничном — любые попытки "разобраться" сейчас только усугубят выгорание. — Временный shadow-режим: подключить того, кто сможет хотя бы поддерживать статус-кво (даже junior под контролем архитектора извне). — Заморозка скоупа: договориться с бизнесом, что новые требования принимаются только через formal change request (даже если это Excel-таблица).
2. Системные изменения: устраняем root cause — Декомпозиция ownership'а: если зона критична, в ней должно быть минимум два погруженных человека. Даже если второй — external consultant. — Процессный контроль: плавающее ТЗ — это индикатор слабого product-менеджмента. Вводим жесткие gate между этапами: "Сначала sign-off на архитектуру, потом код". — Метрики усталости: если тимлид "на пределе", а синьор сгорает — это failure системы управления. Ввожу регулярные check-in'ы не только про progress, но и про capacity.
3. Долгосрочная стратегия: пересмотр governance — "Нельзя снять синьора" — это антипаттерн. Любая зона должна иметь план ротации, иначе компания берет на себя технические и репутационные риски. — Инвестиции в resilience: если проект высокоприоритетный, но зависит от одного человека — это не проект, а technical debt в чистом виде.
ответить
еще контент в этом сообществе
еще контент в этом соообществе
Александр Бабицкий | Тимлид на практике
06.05 · ред.
войдите, чтобы увидеть
и подписаться на интересных профи