Кто есть кто в команде: роли, зоны ответственности, кто что решает

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

Эта статья — карта. Не «должностные инструкции из HR-портала», а описание того, кто какие решения реально принимает, где проходят границы ответственности, почему в одной компании десять ролей, а в другой три человека несут все десять, и как за первые недели понять, к кому идти с конкретным вопросом.

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

Главное отличие: роль — это не должность и не человек

Три разных понятия, которые новички склеивают в одно:

• Должность — строка в трудовом договоре и в штатном расписании. «Ведущий инженер-программист». Влияет на зарплату и на грейд, почти не влияет на то, чем вы занимаетесь в понедельник.
• Роль — набор решений, которые вы имеете право принять, и обязательств, которые с вас спросят. «Владелец продукта» — это роль: право решать, что делаем следующим, и ответственность за то, что оно кому-то нужно.
• Человек — носитель. Один человек может нести три роли, одну роль могут делить трое.

Отсюда практическое правило: не спрашивайте «кто у нас такой-то по должности», спрашивайте «кто принимает решение про X». Формальная схема отделов почти всегда врёт про реальный поток решений.

Разница между ролью и грейдом — тоже важная и отдельная: сеньор и джун могут быть в одной роли «разработчик», но отличаться масштабом решений, которые им доверяют. Про это — Грейды.

Три зоны решений

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

Полезная формулировка, которую стоит запомнить:

Продукт отвечает на вопрос «что и зачем». Процесс — «когда и в каком порядке». Инженерия — «как». Каждый имеет право вето в своей зоне и право голоса в чужой.

Классические конфликты начинаются, когда границы нарушают:

• Продакт говорит «сделайте это за неделю» — он зашёл в зону «как» и «когда». Корректная форма его требования: «мне это очень нужно к запуску 14-го, что мы можем убрать?».
• Разработчик говорит «эта фича не нужна пользователям» — он зашёл в зону «что». Он может (и должен) сказать: «эта фича стоит три недели вместо трёх дней, вот почему; готовы платить?».
• Проектный менеджер говорит «давайте без тестов, чтобы успеть» — он зашёл в зону качества, где решение принимает команда. Корректно: «мы не успеваем, вот варианты — двигаем срок, режем скоуп, добавляем людей; какой выбираем?».

Это не про вежливость, а про то, чтобы решение принимал тот, у кого есть информация для него.

Карта ролей: кто вообще бывает

Дальше — по одной роли: чем человек реально занят, какие решения за ним, чего от него ждать и какая типичная патология у этой роли.

Продуктовые роли

Product Manager и Product Owner

Чем занят. Выясняет, какую проблему пользователя мы решаем, и в каком порядке. Ходит к клиентам и в аналитику, пишет и режет бэклог, защищает приоритеты перед бизнесом, объясняет команде, зачем задача существует. Отвечает не за «выпустили фичу», а за то, что фича изменила метрику или закрыла боль.

Что решает. Приоритет. Что делаем следующим, что не делаем вообще, что можно выбросить из релиза, если не успеваем. Это его вето.

Чего не решает. Как это реализовано, сколько это займёт, кто в команде что берёт.

PM или PO — в чём разница. Формально Product Owner — роль из Scrum: держит бэклог продукта и его приоритет (Scrum Guide). Product Manager — более широкая рыночная роль: стратегия, исследования, ценообразование, взаимодействие с рынком. На практике в России и СНГ это часто один человек, называемый как принято в компании; в крупном энтерпрайзе — два разных: PM думает про рынок и стратегию, PO переводит это в конкретные задачи для одной команды. Глубоко про эту работу — трек product-management, особенно приоритизация.

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

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

Аналитик: бизнес-аналитик и системный аналитик

Бизнес-аналитик (BA) работает на стыке бизнеса и команды: собирает требования у заказчика, описывает процессы «как есть» и «как будет», ищет противоречия, до которых у бизнеса не дошли руки. Системный аналитик (SA) ближе к инженерам: пишет спецификации API, схемы обмена данными, описывает интеграции, состояния объектов, обработку ошибок.

В стартапе аналитика чаще нет вовсе — его работу делят продакт и разработчик. В энтерпрайзе (банки, телеком, госсектор) аналитик обязателен: там интеграций десятки, и цена неточной спецификации — недели переделок в трёх смежных системах.

Что решает. Формулировку требования и его непротиворечивость. Аналитик — тот, кто имеет право сказать «это требование конфликтует с тем, что мы сделали в прошлом квартале».

Патология роли. Спецификация ради спецификации: тридцатистраничный документ, который никто не читает, зато формально «требования есть». Обратная патология — аналитик, который просто пересказывает слова заказчика в тикет. Подробнее про то, как выглядят работающие требования — Требования и аналитика.

Дизайнер и UX-исследователь

Продуктовый дизайнер — не «человек, который рисует красиво». Он проектирует поведение: какие состояния бывают у экрана, что видит пользователь при ошибке, при пустом списке, при медленной сети, что происходит при отмене. Хороший макет отвечает на вопросы, которые иначе всплывут у вас в середине спринта.

UX-исследователь — там, где он есть — проверяет гипотезы на живых людях до того, как команда потратит месяц. В большинстве команд эту работу делает дизайнер или продакт.

Что решает. Пользовательский сценарий и интерфейсные соглашения. Дизайнер имеет право сказать «так делать нельзя, это ломает паттерн всего продукта».

Как с ним работать. Практический совет, который экономит недели: получив макет, первым делом спросите про краевые состояния. Что если имя длиной 200 символов? Что если список пуст? Что если запрос идёт 8 секунд? Что если у пользователя нет прав? Отсутствие этих ответов — не вина дизайнера, а нормальный этап; хуже, если вы придумаете их сами молча, а потом переделаете дважды.

Патология роли. Дизайн, оторванный от технических ограничений: макет, который требует данных, которых нет ни в одном сервисе. Лечится ранним разговором дизайнера с разработчиком, а не героическим бэкендом.

Процессные роли

Project Manager / Delivery Manager

Чем занят. Сроками, зависимостями, рисками, бюджетом, коммуникацией со смежниками. Его вопрос — не «что делаем», а «что мешает это доделать и когда оно будет».

Что решает. План и последовательность работ, эскалацию проблем, привлечение людей извне, компромисс «срок — скоуп — ресурсы» (совместно с продактом).

Где встречается. В аутсорсе и энтерпрайзе — почти всегда: там есть договор, сроки и штрафы. В продуктовом стартапе — часто нет: функцию делят тимлид и продакт. Разница между типами компаний — Какие бывают проекты.

Патология роли. «Менеджер-статусометр»: тратит время команды на сбор статусов, которые можно было прочитать в трекере, но не снимает ни одного блокера. Признак хорошего PM — противоположный: вы говорите «жду доступ от смежной команды третий день», и через час доступ есть.

Про инструменты этой роли — оценки, риски, метрики потока — трек project-management, в частности риски и оценка и планирование.

Scrum Master / Agile coach

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

Что решает. Формально — ничего в продукте и ничего в технике. Его инструмент — влияние, а не власть, и это главное непонимание вокруг роли.

Честно о роли. В сильной зрелой команде отдельный скрам-мастер часто не нужен — его функции распределены. В команде, которая тонет в неявных конфликтах и хаотичных процессах, хороший скрам-мастер даёт эффект больше, чем ещё один разработчик. Плохой — производит ритуалы ради ритуалов, и тогда роль справедливо считают лишней. Подробнее про сам фреймворк — Agile и Scrum.

Инженерные роли

Разработчик

Ваша роль. Полезно понимать, что от вас ждут не «строк кода», а закрытых задач, доехавших до пользователя и не сломавших прод. Специализации:

• Бэкенд — бизнес-логика, данные, интеграции, надёжность. Чаще всего именно здесь живёт основная сложность системы.
• Фронтенд — интерфейс, состояние на клиенте, производительность в браузере, доступность.
• Мобильная разработка — плюс отдельная боль: релизный цикл через сторы, старые версии приложения у пользователей навсегда, offline-состояния.
• Fullstack — умеет и то и другое; в маленькой команде это нормальный дефолт, в большой чаще означает «основная специализация плюс способность не звать соседа по мелочи».

Что решает разработчик. Больше, чем кажется джуну. Выбор структуры кода, границы модуля, где обработать ошибку, что покрыть тестами, какой техдолг допустим. Каждое такое решение позже становится либо чужой лёгкой жизнью, либо чужим адом.

Тимлид, техлид и engineering manager — три разные вещи под одним словом

Самая частая путаница в русскоязычных командах: слово «тимлид» покрывает три разных набора ответственности, и в разных компаниях под ним понимают разное.

Что важно понять на практике. Если ваш тимлид совмещает обе роли — у него хронический конфликт приоритетов, и это объясняет, почему его ревью иногда приходит на второй день. Если у вас есть отдельный EM — с зарплатой, отпуском, обратной связью и карьерными вопросами идёте к нему, с архитектурой — к техлиду.

Что тимлид действительно решает. Кто делает какую задачу, что попадает в спринт со стороны техники, какой техдолг берём, кто дежурит, кто кого менторит, эскалация конфликтов. И — важно — тимлид переводит между тремя языками: он объясняет продакту стоимость технического решения и объясняет команде смысл продуктового.

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

QA-инженер

Чем занят. Не «ищет баги, чтобы вас наказать». Ищет риски: где система может повести себя не так, как ожидает бизнес, и что из этого дорого. Хороший QA приносит вопросы раньше кода: «а что при повторной отправке формы?», «а что с чужой валютой?».

Виды. Мануальный QA (исследовательское тестирование, приёмка, проверка сценариев), автоматизатор (пишет автотесты поверх продукта), SDET (инженер, который пишет и код продукта, и инфраструктуру тестирования). Глубже — трек testing и статья Тестирование глазами разработчика.

Что решает. Оценку риска релиза: «выкатывать это опасно, вот почему». Формальное право стопнуть релиз есть не везде, но право быть услышанным — есть всегда.

Главная ошибка джуна. Считать QA внешним контролёром и кидать ему «на проверку» всё подряд. Правильная модель: качество — общая ответственность, QA — усилитель, а не фильтр. Практический приём: перед передачей в тестирование пройдите сценарий сами и напишите в тикете, что проверили. Это экономит один-два круга возвратов и очень заметно меняет отношение к вам.

Патология роли. QA как «привратник»: команда перестаёт думать о качестве, потому что «есть кому проверить». Или обратная — QA, который проверяет только по чек-листу и не задаёт вопросов.

DevOps, SRE и platform engineer

Три слова, которые часто путают:

• DevOps — вообще-то культура и практика (см. dora.dev), но в вакансиях так называют инженера, который строит CI/CD, инфраструктуру, окружения.
• SRE (Site Reliability Engineering) — подход Google: надёжность как инженерная задача, бюджеты ошибок, SLO, дежурства. Каноничная книга бесплатно доступна: sre.google/books.
• Platform engineer — строит внутреннюю платформу, которой пользуются продуктовые команды: шаблоны сервисов, самообслуживание, «золотые пути».

Что решают. Правила эксплуатации: как выкатываем, что мониторим, какие лимиты, кого будят ночью. Имеют вето на «выкатим руками в пятницу вечером».

Как с ними работать. Худшее, что можно сделать, — считать их сервис-деском («поднимите мне стенд»). Лучшее — приходить с контекстом: «нужен доступ к такому-то топику для такой-то задачи, вот тикет». Практики этой зоны — трек devops, особенно наблюдаемость и дежурства.

Архитектор

Чем занят. Решениями, которые дорого менять: границы сервисов, выбор хранилища, протоколы взаимодействия, стратегия миграции. Формулирует и фиксирует их — обычно в виде ADR (architecture decision record, см. adr.github.io).

Где встречается. В крупных компаниях — отдельная роль, иногда целый отдел архитектуры. В командах поменьше архитектурные решения принимают техлид и сильные разработчики совместно.

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

Данные: аналитик, дата-инженер, ML-инженер

• Аналитик данных — отвечает на вопросы бизнеса числами: сколько пользователей отвалилось, сработал ли эксперимент. Часто именно он показывает, что фича, на которую ушёл месяц, никем не используется.
• Дата-инженер — строит пайплайны и хранилища, чтобы эти числа вообще существовали и были достоверны (data-engineering).
• ML-инженер / дата-сайентист — модели и их эксплуатация.

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

Роли, о которых забывают, но которые вас остановят

• Информационная безопасность. В банке, финтехе, медицине и госсекторе имеет прямое вето. Может запретить библиотеку, внешний сервис, схему хранения. Узнавать об этом лучше на этапе проектирования, а не за день до релиза.
• DBA. Там, где база большая и общая, миграции проходят через него. Он единственный, кто помнит, что этот индекс строится четыре часа с блокировкой.
• Технический писатель. Документация, релиз-ноуты, справка. Там, где его нет, пишете вы.
• Поддержка (support, L1/L2). Первыми узнают, что вы сломали. Ваш лучший источник информации о реальных пользователях — см. Поддержка и техдолг.
• Юристы и комплаенс. Персональные данные, возрастные ограничения, лицензии зависимостей.
• Спонсор проекта. Тот, чей бюджет. Обычно вы его не видите, но именно от него зависит, живёт ли проект в следующем квартале.

Как роли взаимодействуют на одной задаче

Абстрактная схема ничего не объясняет. Вот реальный путь одной средней фичи — «добавить оплату частями» — и кто в какой момент включается.

Три вещи, которые тут стоит заметить:

1. Разработчик разговаривает с продактом напрямую про стоимость. Это ключевой момент фичи: именно диалог «4 недели против 1» изменил решение. Если бы разработчик молча начал делать полную версию, команда потеряла бы три недели.
2. QA включился до кода, а не после. Его список краевых случаев дешевле получить в начале.
3. Никто не «передал задачу через стену». Роли пересекаются во времени; последовательность на диаграмме — не конвейер, а разговор.

Кто владеет задачей в каждый момент

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

Почему это важно джуну: если владелец задачи непонятен — она стоит. Классическая ситуация: разработчик написал вопрос в комментарии к тикету и ждёт. Владельца в этот момент нет: разработчик считает, что мяч у аналитика, аналитик не увидел уведомление. Задача не двигается неделю, и никто не виноват.

Приём против этого: вопрос всегда адресный и с дедлайном — не «а как тут должно работать?», а «@Иван, нужен ответ по частичному возврату до среды, иначе делаю по варианту А и опишу это как допущение в тикете». Диффузия ответственности — реальный, изученный эффект (классический обзор — Darley & Latané, 1968); в трекере он выглядит именно так.

Модели распределения ответственности: RACI и DACI

Когда людей и ролей становится много, компании начинают формализовать, кто за что отвечает. Две модели, которые вы встретите:

RACI — для каждой работы или решения фиксируют:

• R (Responsible) — кто делает руками;
• A (Accountable) — кто отвечает за результат; должен быть ровно один;
• C (Consulted) — с кем советуются до решения;
• I (Informed) — кого уведомляют после.

DACI — вариант для конкретных решений: Driver (двигает процесс принятия), Approver (утверждает), Contributors, Informed. Удобен, когда решение одно, а мнений много.

Честно о таких матрицах. В стартапе RACI никто не рисует — и правильно, при пяти людях это оверхед. В энтерпрайзе матрица часто существует в презентации и не совпадает с реальностью. Ценность не в документе, а в разговоре, который его порождает: команда впервые вслух проговаривает, что «за релиз отвечают все» означает «за релиз не отвечает никто».

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

Почему в маленькой команде ролей меньше, а в большой больше

Это не про бюрократию, а про арифметику коммуникации.

При n людях число пар, которым нужно синхронизироваться, — n(n-1)/2. Три человека — три канала, все всё знают из воздуха, роли не нужны. Десять человек — сорок пять каналов, и «все всё знают» физически невозможно. Роли, владельцы зон и явные интерфейсы между людьми — способ не оплачивать все связи.

Отсюда классические выводы, которые вы будете слышать всю карьеру:

• Закон Брукса: добавление людей в опаздывающий проект задерживает его ещё больше (Фред Брукс, «Мифический человеко-месяц») — новые люди сначала потребляют внимание старых.
• Закон Конвея: структура системы повторяет структуру коммуникации организации (оригинальная статья Мелвина Конвея). Три команды, пишущие компилятор, напишут трёхпроходный компилятор. Практическое следствие — «обратный манёвр Конвея»: хочешь такую архитектуру — построй под неё команды.
• Размер команды ~5–9 человек — не мистика, а точка, после которой стоимость координации растёт быстрее пользы от лишних рук.

Как меняются роли по мере роста компании

Ни одна колонка не «правильнее» другой. Это разные точки компромисса между скоростью и предсказуемостью, и они честно рассмотрены в статьях Энтерпрайз изнутри и Стартап изнутри.

Что стоит понять сейчас:

• В маленькой команде роль «продакт» никуда не девается — её просто несёт основатель вечером после звонков. Отсутствие роли не означает отсутствие работы; означает, что работа делается урывками и часто плохо.
• В большой компании узкие роли дают глубину экспертизы и защиту от героизма, но платой становятся передачи ответственности между людьми — каждая из них это очередь, ожидание и потеря контекста.

Как устроены команды: разные способы нарезать людей

Feature team против component team

• Feature team (кросс-функциональная) — команда, которая может довести пользовательскую ценность до конца сама: в ней есть бэкенд, фронт, QA, доступ к дизайну. Плюс: мало зависимостей, короткий путь до пользователя. Минус: меньше глубина экспертизы, риск, что несколько команд по-разному правят один и тот же код.
• Component team (компонентная) — команда владеет частью системы (биллинг, поиск, платформа). Плюс: экспертиза и качество внутри компонента. Минус: любая пользовательская фича требует синхронизации трёх команд, и появляется роль, которая эту синхронизацию тянет.

На практике почти везде гибрид: продуктовые команды сверху, платформенные и инфраструктурные снизу.

Team Topologies — язык, который сейчас используют

Мэттью Скелтон и Мануэль Пайс предложили словарь, который прижился (teamtopologies.com):

• stream-aligned — команда, привязанная к потоку ценности (основной тип);
• platform — делает внутренние сервисы для других команд;
• enabling — временно помогает другим командам освоить новое;
• complicated-subsystem — держит сложную подсистему, требующую редкой экспертизы.

Плюс три типа взаимодействия: сотрудничество, «как сервис», фасилитация. Ценность модели в том, что она даёт словарь для разговора «почему нам всё время мешает соседняя команда».

Про «модель Spotify»

Вы обязательно услышите про сквады, гильдии, чаптеры и трайбы. Полезно знать честный контекст: эта модель описана в статье 2012 года, и сама Spotify публично признавала, что описанное не работало у них так, как выглядело на картинке (см. разбор Ерика Кнаберга и последующие публикации инженеров компании). Копировать чужую структуру, не скопировав их контекст и людей, — самая частая и самая дорогая ошибка при реорганизациях. Про масштабирование фреймворков — Фреймворки масштабирования.

Практика: к кому идти с вопросом

Самая полезная часть статьи для первых месяцев работы.

И несколько правил, которые сильно повысят вашу репутацию за первые недели:

1. Сначала 20 минут сами, потом спрашивайте. Не два дня и не две минуты. Формулируйте так: «искал здесь и здесь, нашёл вот это, застрял на этом».
2. Спрашивайте в общем канале, а не в личке. Ответ увидят другие, останется след, отвечающий не один. В личку — только личное.
3. Ответ по важной вещи фиксируйте в тикете. Устная договорённость через месяц не существует, а спорить придётся именно через месяц.
4. Не пересказывайте позицию отсутствующей роли. «Продакт вроде хотел так» — источник половины переделок. Спросите продакта.
5. Уважайте асинхронность. Дёргать SRE в личку при работающем инцидент-канале — верный способ получить репутацию человека, которого избегают.

Типичные ошибки джуна в работе с ролями

• Считать, что раз задача в трекере — она продумана. Часто нет. Роль, которая должна была её продумать, была занята. Вопрос «а что если…» на старте — не наглость, а работа.
• Воспринимать ревью и баги как оценку личности. Ревьюер и QA работают с кодом, не с вами. Про это подробно — Разработка.
• Молча не соглашаться. Худший сценарий: вы считаете решение плохим, ничего не говорите, делаете, оно ломается. Правильно: возразить один раз аргументированно, услышать решение и дальше выполнять его качественно (принцип «disagree and commit»).
• Путать тимлида с менеджером, а менеджера — с врагом. У руководителя нет цели вас поймать; у него есть цель, чтобы команда выдавала результат и не разбегалась. Это чаще всего совпадает с вашими интересами.
• Ждать, что кто-то придёт и расскажет контекст. Не придёт: у всех своя очередь задач. Контекст добывают вопросами.
• Идти к «главному» через голову своего лида. В большинстве компаний это дорого стоит репутационно и почти никогда не ускоряет решение.

Как за две недели понять реальную расстановку сил

Формальная схема отделов вам не поможет. Помогут наблюдения:

1. Кто апрувит пул-реквесты в вашей части кода. Открывайте историю: git log, список ревьюеров в последних тридцати PR. Это ваш реальный технический авторитет, независимо от его должности.
2. Чей комментарий закрывает спор в тикете. После чьей реплики обсуждение заканчивается — тот и принимает решения.
3. Кого зовут на встречу, когда всё горит. Список участников инцидента — самая честная организационная схема в компании.
4. Кто говорит «нет» и это принимается. Право вето — главный признак владельца зоны.
5. Кто знает, почему код такой. Носитель истории. Обычно он же самый ценный источник для вас в первые месяцы. Найти его несложно: git log --format='%an' -- <файл> | sort | uniq -c | sort -rn.
6. Спросите прямо на первой неделе. «Кто принимает решения по этому сервису? С кем согласовывают изменения схемы БД?» Это нормальные вопросы для новичка, и они экономят вам месяцы. Подробнее про вход в команду — Первые 90 дней.

Роли и ваша карьера

Три практических следствия:

• Роль — это не приговор. Переход разработчик → техлид, разработчик → продакт, QA → SDET, аналитик → продакт — обычные траектории. Что для них нужно — Как расти и Карьерные треки.
• Роль влияет на вознаграждение, но не определяет его. Одна и та же роль оплачивается по-разному в разных типах компаний и на разных грейдах; как устроены вилки, грейды и бонусы и как самостоятельно исследовать рынок — в статье Зарплата и своя цена.
• На собеседовании вас будут оценивать в том числе на понимание ролей. Вопрос «что делать, если продакт требует срок, который вы считаете нереальным» — это вопрос ровно об этом. Обе стороны стола разобраны в Как проходить собеседования и Как проводить собеседования.

Мини-итог

• Роль — это зона решений и ответственности, а не должность. В команде из трёх человек все роли есть, просто они собраны в трёх головах.
• Три зоны: продукт («что и зачем»), процесс («когда и в каком порядке»), инженерия («как»). Конфликты почти всегда — нарушение границ зон.
• У каждой задачи в каждый момент должен быть ровно один владелец. Если владелец непонятен, задача стоит, и это никак не отображается в трекере.
• «Тимлид» в русскоязычных компаниях покрывает три разные роли — техлид, менеджер людей и всё сразу. Уточните, какая у вас, это меняет, с чем к нему приходить.
• Число ролей растёт вместе с командой не из-за бюрократии, а потому что число каналов коммуникации растёт квадратично.
• Реальную расстановку сил видно не в оргсхеме, а в том, кто апрувит PR, чей комментарий закрывает спор и кого зовут на инцидент.

Что почитать

• Фред Брукс, «Мифический человеко-месяц» — про людей, коммуникацию и почему проекты опаздывают.
• Мэттью Скелтон, Мануэль Пайс, «Team Topologies» — teamtopologies.com.
• Камилла Фурнье, «Путь менеджера» (The Manager’s Path) — про роли техлида и EM изнутри.
• Scrum Guide — первоисточник про роли в Scrum, 13 страниц.
• Google SRE Book — про роль SRE и границы с разработкой.
• Мелвин Конвей о законе Конвея — оригинал 1968 года.
• dora.dev — исследования о том, какие командные практики реально коррелируют с производительностью.

Что дальше

Какие бывают проекты: продукт, аутсорс, аутстафф, внутренняя разработка, госсектор — разберём, как одни и те же роли меняются до неузнаваемости в зависимости от того, кто платит за разработку и чем она заканчивается: продуктовая компания, аутсорс по договору, аутстафф, внутренний ИТ-отдел и госзаказ.