P-012
Тимлид, проджект и продакт: где заканчивается власть каждого
В стартапе роли смазываются: тимлид пишет ТЗ, продакт контролирует сроки, а проджект решает, какую фичу делать первой. В корпорации — наоборот: три человека могут месяц согласовывать, кто из них должен написать письмо клиенту. Между этими крайностями — ежедневная работа, где тимлид постоянно сталкивается с вопросом: «Это моя зона или я лезу не туда?»
Разобраться с границами — задача номер один для нового тимлида. Иначе вы превратитесь в прокси между командой и менеджментом, потеряв техническое влияние, или, наоборот, начнете микроменеджерить продуктовые решения, за которые не несете ответственности.
Продакт: он решает, что делать
Продакт-менеджер отвечает за ценность. Его ключевой вопрос: «Зачем мы это делаем и что получит бизнес?» Он определяет приоритеты фич, формулирует гипотезы, анализирует метрики и общается с пользователями.
Граница его власти заканчивается там, где начинается вопрос «Как именно это реализовать?» Он может сказать: «Нужна интеграция с платежной системой для снижения отказов в корзине». Но он не должен решать, будете ли вы использовать готовый SDK или писать собственный шлюз. Это выбор команды и тимлида.
Проджект: он решает, когда и сколько
Проджект-менеджер управляет ограничениями. Его зона — сроки, бюджет, ресурсы, риски и коммуникации между стейкхолдерами. Он следит, чтобы к релизу все было готово, устраняет блокеры, организует встречи и планирование.
Власть проджекта заканчивается на границе «как мы работаем внутри команды». Он может требовать оценку задач в часах или сторипоинтах, но не должен навязывать методологию разработки или лезть в code review. Если проджект начинает решать, какой фреймворк выбрать или кто из разработчиков должен писать тесты — он вышел за рамки.
Тимлид: он решает, как и кем
Тимлид стоит между бизнесом и технологиями. Его ответственность — техническое качество, архитектурные решения, развитие команды и процесс разработки внутри команды.
Конкретно:
- Выбор технологий и подходов к реализации
- Качество кода и технический долг
- Найм, онбординг и развитие разработчиков
- Процессы внутри команды (git-flow, code review, CI/CD)
Граница власти тимлида — техническая реализация продактовых требований. Если продакт говорит «что», а проджект — «когда», то тимлид решает «как» и «кем».
Где проходит линия
Проблемы начинаются в трех зонах:
Приоритеты vs Техдолг. Продакт толкает фичи, тимлид тянет за refactoring. Здесь нет автоматического права вето ни у одной из сторон. Тимлид должен аргументировать риски в бизнес-терминах («без этого релиз занимает две недели вместо двух дней»), а не просто говорить «код плохой».
Сроки vs Качество. Проджект давит на скорость, тимлид отвечает за стабильность. Граница — Definition of Done. Тимлид определяет критерии готовности, проджект планирует сроки с учетом этих критериев.
Процессы vs Люди. Проджект хочет больше статусов и отчетов, тимлид защищает команду от бюрократии. Компромисс: тимлид обеспечивает прозрачность (понятные статусы задач), проджект не требует лишней отчетности.
Один практический вывод
Тимлид не начальник продукта и не подчиненный проджекта. Его роль — технический партнер с правом голоса. Чтобы не превратиться в исполнителя чужих решений, закрепите за собой формальное право согласовывать любые требования с точки зрения технической реализуемости и времени на разработку. Это право должно быть зафиксировано: в должностной инструкции, в регламенте команды или хотя бы в письменном соглашении с продактом и проджектом. Без этого «границы» останутся размытыми, а вы — ответственным за провалы, в которые вас поставили чужие решения.
Подписывайтесь на наш Telegram-канал: разбираем реальные кейсы тимлидов, разбираемся в конфликтах ролей и делимся практическими шаблонами, которые можно внедрить завтра.