P-010
Карта ответственности тимлида без корпоративной воды
Новый тимлид обычно получает должность так: «Вася, ты теперь тимлид». И всё. Никакого регламента, границ, понимания, за что отвечаешь лично, а за что — команда. Через месяц Вася тонет в митингах, код-ревью и разборе конфликтов, не понимая, успевает он или проваливает всё подряд.
Карта ответственности — это не бумажка для HR. Это рабочий инструмент, который показывает: где твоя зона влияния, где зона команды, а где ты превращаешься в микроменеджера.
Алгоритм построения карты
Шаг 1. Разделите три зоны
- Зона прямой ответственности (вы лично даёте результат)
- Зона делегирования (команда решает, вы контролируете)
- Зона наблюдения (влияете косвенно, не вмешиваетесь без причины)
Шаг 2. Для каждой зоны пропишите артефакты Не «развитие команды», а «каждый разработчик имеет актуальный план развития на квартал». Не «качество кода», а «покрытие тестами критичных модулей не ниже 80%».
Шаг 3. Определите частоту проверки Ежедневно, еженедельно, ежеквартально. Если проверяете всё каждый день — вы микроменеджер. Если раз в год — вы фигурант.
Шаг 4. Зафиксируйте критерии успеха Чёткое условие: при каком результате зелёный свет, при каком — красный. Без «посмотрим по ситуации».
Зоны ответственности: разбор
Люди
- Найм и адаптация (вы несёте ответственность за то, чтобы вакансия закрывалась в срок и новичок выходил на плановую продуктивность)
- 1-1 (регулярность и качество обратной связи, не «поговорили про жизнь»)
- Развитие (планы развития, рост до следующего грейда, мотивация)
Процессы
- Delivery (предсказуемость сроков, отсутствие сюрпризов в последний день спринта)
- Качество (стандарты кодирования, код-ревью, техдолг под контролем)
- Коммуникации (внешние зависимости, стейкхолдеры, отсутствие информационных вакуумов)
Техника
- Архитектурные решения (где вы решаете сами, где — tech lead, где — команда голосует)
- Стабильность продакшена (on-call ротации, инциденты, postmortem)
- Инструменты (эффективность используемых инструментов, не «у нас всегда так было»)
Примеры из практики
Пример 1. Граница в найме Вы отвечаете за то, чтобы в команде нужное количество людей нужного уровня. Но вы не отвечаете за то, что кандидат принимает оффер — это зона HR и зарплатной политики компании. Ваша задача: дать честный фидбек о кандидате, обеспечить техническое собеседование без токсичности, помочь адаптироваться в первые месяцы.
Пример 2. Техдолг Команда решает, какой техдолг брать в спринт. Вы отвечаете за то, чтобы этот техдолг был виден в бэклоге, оценён и не накапливался критической массой. Если команда игнорирует техдолг три спринта подряд — вы вмешиваетесь и меняете процесс, а не начинаете писать код за них.
Пример 3. Конфликт в команде Два разработчика не делят архитектурное решение. Вы не решаете за них, чей вариант лучше (это техническая экспертиза). Вы отвечаете за то, чтобы решение было принято по установленной процедуре (спор, прототипирование, голосование или арбитраж старшего инженера), и чтобы конфликт не превратился в саботаж.
Чек-лист для самопроверки
Если у вас нет карты:
- [ ] Я могу за 30 секунды объяснить, за что отвечаю лично, а за что — команда
- [ ] Я знаю, какие решения принимаю сам, какие делегирую, а какие игнорирую
- [ ] У меня есть список артефактов, по которым меня оценивает руководство
- [ ] Я понимаю, когда мне пора вмешаться, а когда — наблюдать
Если карта есть:
- [ ] Зоны не пересекаются («я отвечаю за качество, но тесты пишет команда» — это пересечение, его надо развести)
- [ ] Каждая зона имеет метрику или критерий проверки
- [ ] Карта актуализирована за последний квартал (рост команды меняет зоны)
- [ ] Команда знает вашу карту и понимает границы
Типичные ошибки
Смазывание границ «Мы все за всё отвечаем» — значит, никто ни за что не отвечает. Если в инциденте postmortem пишет «команда», а не конкретный человек — вы не выстроили ответственность.
Ответственность без полномочий Вы отвечаете за сроки релиза, но не можете влиять на приоритеты бэклога. Или отвечаете за качество, но не можете отклонить задачу без тестов. Такая карта — фикция. Либо забирайте полномочия, либо снимайте ответственность.
Микроменеджмент под видом контроля Проверяете код каждого разработчика ежедневно? Это не контроль качества, это вы не доверяете процессу код-ревью и не обучаете команду. Перенесите эту зону в «развитие процессов», а не «личная проверка».
Игнорирование метрик «Я чувствую, что команда демотивирована» — не критерий. «Текучка выше 10% в квартал, 1-1 пропущены двое из пяти» — критерий. Абстракции в карте ответственности превращают её в декларацию.
Практическое задание
1. Возьмите лист А4. Разделите на три колонки: «Я», «Команда», «Внешний мир». 2. Заполните: что конкретно вы делаете каждую неделю (не «руковожу», а «провожу 1-1, согласовываю план найма, ревьюю архитектуру»). 3. Для каждого пункта задайте вопрос: «Что будет, если я этого не сделаю?» Если ничего — выкидывайте. Если катастрофа — оставляйте в «Я». Если замедлится, но не остановится — переносите в «Команда». 4. Для зоны «Я» напишите, как вы понимаете, что справляетесь: какой артефакт, какая метрика, какая частота проверки. 5. Покажите карту одному из разработчиков. Если он удивлён вашими полномочиями или говорит «а я думал, это вы делаете» — переделывайте.
Это ваша рабочая версия на ближайшие три месяца. Не идеальная методология, а конкретная карта для конкретной ситуации.
Что дальше
В Телеграме разбираем живые кейсы: как отказаться от зоны, которую де-факто контролируете, но де-юре не должны; как согласовать карту с руководителем, который считает, что «ты же тимлид — значит, за всё отвечаешь»; как менять карту при росте команды с 3 до 10 человек.
Подписывайтесь. Практика без воды.