Роли в IT-команде

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

Кейс: на странице заказа нет номера

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

Номер мог потеряться в четырёх местах. Возможно, никто не решил его показывать. Возможно, для него нет места в эскизе экрана. Возможно, страница его не выводит. Возможно, сервер не прислал его странице. За каждое из этих мест отвечает своя роль.

Роль означает набор обязанностей и результатов, за которые человек отвечает в команде. Роль не равна должности и не равна человеку: в маленькой команде один человек совмещает несколько ролей, об этом ниже. Вопрос «кому идти» превращается в вопрос «в какой части пути потерялся номер».

Кто решает, что делать и как это выглядит

Первые роли отвечают за то, что вообще попадёт в работу и в каком виде. Product owner (владелец продукта) отвечает за то, что делает продукт и в каком порядке: он решает, что войдёт в ближайшую работу. В «Узелке» эту роль играет владелец магазина, а в заказной разработке её часто выполняет заказчик или его представитель (о нём в статье 01-02). Менеджер проекта отвечает за срок, ресурсы и порядок работ и убирает препятствия, из-за которых работа стоит. Дизайнер рисует, как выглядит и ведёт себя экран, и передаёт разработчикам макет: готовый эскиз экрана с размерами, цветами и состояниями. Системный аналитик превращает решения в требования, по которым работают остальные, подробно о нём в статье 01-04.

Роль	За что отвечает	С чем идут к ней в «Узелке»
Product owner	Что делает продукт и в каком порядке	Нужен ли номер заказа на странице «Спасибо» и что важнее: он или фильтр товаров
Менеджер проекта	Срок, ресурсы, порядок работ	Успеем ли исправить до выходных и кого взять на это
Системный аналитик	Требования: что именно должна делать система	Как записано, что показывают после оформления заказа
Дизайнер	Как выглядит и ведёт себя экран	Есть ли в макете место под номер и как он выглядит, если длинный

Эти роли отвечают на вопрос «что и как должно быть». Следующие отвечают на вопрос «как это устроено и сделано».

Кто строит систему и отвечает за её устройство

Архитектор отвечает за устройство системы целиком: из каких частей она состоит, как они связаны и выдержит ли она рост. Разработчиков обычно делят по тому, где работает их код. Фронтенд-разработчик отвечает за ту часть, которую видит пользователь: страницы, кнопки и поля, то есть всё, что работает в браузере. Бэкенд-разработчик отвечает за часть на сервере, то есть на компьютере, где работает сайт: правила, расчёты и работу с базой данных, куда сохраняются заказы. Как эти части связаны друг с другом, разбирает статья 01-05.

Роль	За что отвечает	С чем идут к ней в «Узелке»
Архитектор	Устройство системы: части, связи, запас на рост	Выдержит ли оформление заказов в день распродажи и где хранить заказы
Фронтенд-разработчик	Страницы и их поведение в браузере	Показывает ли страница «Спасибо» номер, который пришёл с сервера
Бэкенд-разработчик	Серверные правила и данные	Присваивается ли заказу номер и отдаётся ли он странице

В небольшом магазине отдельного архитектора обычно нет: решения об устройстве принимает старший разработчик. Но роль от этого не исчезает, потому что устройство системы кто-то всё равно решает. Типичная ошибка: идти с вопросом о внешнем виде кнопки к бэкенд-разработчику. Он видит данные и правила, а как выглядит кнопка, решили дизайнер и фронтенд.

Кто проверяет, запускает и слышит пользователей

Последние роли работают после того, как код написан. Тестировщик проверяет, что сделанное соответствует требованиям, и находит расхождения до того, как их увидят покупатели. DevOps-инженер отвечает за то, как программа попадает на серверы и как она там работает: копии сайта для проверки, перенос новых версий на рабочий сайт и наблюдение за его работой (подробнее в статье 01-09). Поддержка, которая принесла нам жалобу, принимает обращения пользователей и передаёт команде то, что не может решить сама.

Роль	За что отвечает	С чем идут к ней в «Узелке»
Тестировщик	Проверка результата по требованиям, отчёты об ошибках	Проверяли ли после оформления заказа, что виден номер, и где это записано
DevOps-инженер	Серверы, копии сайта для проверки, перенос новых версий	Когда исправление попадёт на сайт и можно ли проверить его на копии сайта
Поддержка	Обращения пользователей и передача ошибок команде	Сколько покупателей написали об этом и на каком шаге

Дорогая ошибка: считать, что тестировщик «ловит всё». Он проверяет то, что записано в требованиях. Если номера заказа в требованиях не было, то проверять его на странице было нечего.

К кому идти с вопросом

Вернёмся к жалобе. Номер заказа должен был пройти путь от решения до экрана, и на каждом шаге этого пути есть своя роль и свой результат. Идти нужно по этому пути в том порядке, в котором номер должен был появиться, а не к тому, кого проще застать.

Допустим, в требованиях сказано, что на странице «Спасибо» показывают номер, и в макете для него есть место. Тогда вопрос уходит к разработчикам. Бэкенд-разработчик быстро проверяет, есть ли у заказа номер на сервере и отдаётся ли он странице. Если да, вопрос переходит к фронтенд-разработчику: страница получила номер и не вывела. Если же про номер нигде не написано, вопрос возвращается назад, к product owner и аналитику, потому что разработчики сделали ровно то, что им передали.

С собой нужно принести то, что позволит ответить без переспросов: пример (номер заказа и время), что ожидали и что получилось, где это записано в требовании и в макете, что уже проверено. Так выглядит короткое обращение к бэкенд-разработчику Андрею (фронтенд-разработчика в этой команде зовут Лена):

Вы: Андрей, покупательница оформила заказ сегодня в 14:07, поддержка нашла его по её почте: номер 10482. На странице «Спасибо» номера нет, хотя по требованию и макету он должен стоять под заголовком. Скриншот приложила поддержка. Есть ли у заказа номер на сервере и отдаётся ли он странице?

Андрей: Смотрю. Номер присвоен, сохранён и отдаётся странице вместе с ответом об оформлении. Значит, вопрос к Лене: страница его не вывела.

Вы: Лена, заказ 10482, номер на сервере есть, на странице нет. Посмотришь, что приходит странице?

Такое обращение короткое и экономит день: адресат видит пример, ожидание и место в требованиях и не переспрашивает.

Один человек, несколько ролей и разные названия

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

Из этого следует правило: идти нужно к роли, а не к человеку. В «Узелке» вопрос про устройство сервера и вопрос про перенос новой версии на сайт уйдут к одному и тому же старшему разработчику, но это два разных вопроса с разными ответами, и в обращении стоит назвать, о каком из них речь. Такая схема работает, пока команда мала. В крупной компании на каждую роль приходятся отдельные люди, а иногда целые команды, и граница между ролями проходит жёстче.

Названия тоже различаются. Product owner в одной компании называется владельцем продукта, в другой менеджером продукта, а разработчика могут называть программистом или инженером. По названию должности роль определить нельзя, поэтому в новой команде полезно с первого дня выяснить, кто за что отвечает.

Где это встречается в работе

• Жалоба или ошибка. Нужно решить, в чью часть пути она попадает, и позвать нужную роль, а не всех сразу.
• Согласование изменения. Изменение затрагивает несколько ролей: product owner решает, нужно ли оно, дизайнер перерисовывает экран, разработчики оценивают работу. Без списка ролей кого-то из них забывают.
• Оценка срока. Менеджер проекта собирает оценки от дизайнера, фронтенда и бэкенда: срок одной роли не бывает.
• Первая неделя в новой команде. Выясняют, кто какую роль играет, и записывают это для себя, чтобы знать, у кого что спрашивать.
• Передача макета в работу. Дизайнер и разработчики вместе проходят макет и находят места, где поведение экрана не описано.

Итог

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

Что дальше

Одну роль мы разобрали лишь в таблице: системного аналитика. Чем он занимается и чем отличается от product owner и архитектора, объясняет следующая статья. Как задача проходит по цепочке от идеи до релиза и как общаться между ролями, разбирают отдельные статьи.

• 01-04. Роль системного аналитика: чем эта роль отличается от соседних.
• 01-06. От идеи до релиза: как задача проходит по ролям шаг за шагом.
• 01-08. Как общаться в команде: встречи, согласование, эскалации.

Источники

• Scrum.org, Руководство по Scrum 2020: обязанности product owner и разработчиков в команде.
• Atlassian, Что такое DevOps: как объясняют DevOps и связь разработки с эксплуатацией.