Роли в IT-команде: кто есть кто и за что отвечает

Вячеслав Степанов — проджект-менеджер, ментор · 5 октября 2026

В первый же день в IT-команде новичок слышит: «спроси у техлида», «это к продакту», «QA вернул задачу», «бэк не готов». Проджект-менеджер работает со всеми этими людьми каждый день, и первое, что ему нужно, — понимать, кто за что отвечает и кто что решает. Ниже — основные роли в IT-команде, граница ответственности между ними, путь задачи через команду и то, как проджект выстраивает работу с каждым. Видео-версия — мой открытый урок, сразу ниже.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Из кого состоит IT-команда

IT-команда разработки — это несколько специалистов, каждый из которых отвечает за свою часть продукта. Кто-то решает, что нужно пользователю, кто-то пишет код, кто-то проверяет, что всё работает, кто-то выкатывает новую версию на серверы. Проджект-менеджер связывает всех в единый процесс и отвечает за то, чтобы команда довела дело до релиза.

В Scrum состав описан коротко. Scrum Guide — официальное руководство по Scrum — говорит, что Scrum-команда состоит из одного продакт-оунера, одного скрам-мастера и разработчиков и обычно насчитывает не больше 10 человек. «Разработчики» здесь — все, кто делает продукт: программисты, тестировщики, дизайнеры. В живых компаниях ролей больше и называются они конкретнее.

Основные роли и за что они отвечают

• Проджект-менеджер (Project Manager, PM) — координирует работу команды, ведёт спринты, следит за сроками и блокерами, держит связь с заказчиком и руководством. Отвечает за то, чтобы команда довела задачи до релиза. Подробнее о профессии — в статье как стать проджект-менеджером.
• Продакт-оунер (Product Owner, PO) — владелец продукта. Решает, что команда делает и зачем, но не как. Ведёт бэклог, расставляет приоритеты, общается со стейкхолдерами и пользователями.
• Техлид (Tech Lead, TL) — технический руководитель команды разработки. Принимает архитектурные решения, проверяет чужой код (код-ревью) и отвечает за его качество.
• Бэкенд-разработчик (Backend, BE) — делает серверную часть, которую пользователь не видит: расчёты, хранение данных, проверку прав. Экран отправляет запрос — бэкенд его обрабатывает и возвращает ответ.
• Фронтенд-разработчик (Frontend, FE) — делает то, что пользователь видит в браузере или приложении: экраны, кнопки, формы. Данные фронтенд берёт у бэкенда и показывает.
• Тестировщик (QA, Quality Assurance) — проверяет фичи перед релизом, ищет баги и пишет тест-кейсы. Последняя линия перед тем, как изменения увидят пользователи.
• Дизайнер (UX/UI-дизайнер) — отвечает за то, как продукт выглядит и как им пользоваться. Рисует макеты экранов, чаще всего в Figma, и ведёт библиотеку элементов интерфейса.
• DevOps-инженер — отвечает за серверы, автоматическую сборку и выкатку продукта. Следит, чтобы новая версия доехала до пользователей и её можно было быстро откатить, если что-то пошло не так.

Отдельная роль Scrum — скрам-мастер. По Scrum Guide он отвечает за то, чтобы команда работала по Scrum: помогает с процессом и убирает препятствия. В небольших продуктовых командах выделенного скрам-мастера часто нет, и его функции берёт на себя проджект-менеджер.

Роли в больших командах и компаниях

• Бизнес-аналитик (BA) — выясняет, что нужно бизнесу и пользователям, и описывает требования к фичам.
• Системный аналитик (SA) — превращает пожелание бизнеса в точное техническое описание: какие поля, какие правила, что происходит в необычных ситуациях. По его документу пишут код и тест-кейсы.
• ML-инженер — разрабатывает системы машинного обучения.
• SRE (Site Reliability Engineer) — отвечает за надёжность и стабильность сервиса.
• CTO (Chief Technology Officer) — главный технический руководитель всей компании.
• Руководитель PMO (Head of PMO) — руководитель отдела проджект-менеджеров: нанимает их, помогает в адаптации и сложных проектных ситуациях.

В маленьких командах роли совмещают. Отдельного аналитика может не быть: продуктовую часть аналитики берёт продакт-оунер, техническую — бэкенд-разработчик. DevOps часто общий на несколько команд, и к нему ходят через заявки. Дизайнер нередко делит время между двумя продуктами.

Кто что решает

Это главная граница, которую нужно понимать проджекту:

• Продакт-оунер решает, что делать и зачем: какие фичи важнее и какую ценность они дают.
• Проджект-менеджер решает, когда и в каком порядке: превращает приоритеты в план спринта, следит за сроками и рисками.
• Техлид решает, как сделать технически. Технические споры решаются через него.
• Исполнитель отвечает, сколько займёт его задача. Оценку даёт тот, кто будет делать.

Граница между проджект-менеджером и продакт-оунером в маленьких командах часто размыта. Но на собеседовании важно показать, что ты её видишь: проджект не выбирает за продакта, что делать, и не оценивает за разработчика, сколько это займёт.

Как задача проходит через команду

Упрощённо путь новой фичи выглядит так. Продакт-оунер приносит идею и ставит её в приоритет. Аналитик описывает требования. Дизайнер рисует макет. Бэкенд и фронтенд пишут код, техлид проверяет его. Тестировщик проверяет результат по критериям приёмки. DevOps выкатывает новую версию пользователям.

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

Как проджект-менеджер работает с каждой ролью

Как это выглядит в повседневной работе, я разбирал в статьях про дейлик и про груминг.

Первая неделя: знакомство с командой

В IT-компании новый проджект первые 1–2 недели тратит не на задачи, а на знакомство с людьми. Главный инструмент — встречи один на один (1 to 1): личный разговор с каждым членом команды. Цель — понять, кто что делает, у кого какие боли и как всё устроено.

Простой шаблон повестки для первой встречи:

1. Коротко представиться: кто ты, какой у тебя опыт.
2. Узнать роль человека: что именно делает и за что отвечает.
3. Какие задачи у него сейчас в работе.
4. Что нравится и что раздражает в работе, какой формат общения удобен.
5. Что мешает работать.
6. Какие цели на ближайшее время.
7. Чем проджект может помочь и чего от него ждут.
8. Немного личного — увлечения, прошлый опыт. Это для отношений, а не для дела.

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

Типичные ошибки

• Проджект лезет в технические решения. Спорит с разработчиками о том, как писать код. Лекарство — технические вопросы решает техлид, проджект следит за сроками и рисками.
• Проджект оценивает за команду. «Ну это дня на три» — это догадка. Лекарство — оценку даёт исполнитель, а проджект спрашивает, из чего она складывается.
• Проджект решает приоритеты за продакта. Двигает задачи в бэклоге по своему усмотрению. Лекарство — что важнее, решает продакт-оунер; проджект приносит ему факты и риски.
• Пропуск знакомства. Новый проджект сразу ставит задачи людям, которых не знает. Лекарство — встречи один на один в первую неделю.
• Технический спор идёт мимо техлида. Разработчики приходят к проджекту рассудить их. Лекарство — направить спор к техлиду и зафиксировать решение.

Частые вопросы