Типичная продуктовая команда, если рассматривать её через призму гибких методологий и моего видения, выглядит следующим образом.
Роли в продуктовой команде
Продукт/Product Owner — создаёт новые идеи для продукта, чтобы решать проблемы пользователя или увеличить прибыль продукта/компании.
Очень важно: всегда должен общаться с командой в формате: «У пользователя есть проблема, мы решаем проблему пользователя, мы помогаем пользователю достигнуть...».
Руководитель проекта/Delivery manager/IT Project manager — организует процессы работы в команде, отвечает за сроки и порядок выполнения фич, контролирует доставку фич до прода (пользователя). Работает и транслирует команде принятую методологию. Выполняет функции *Scrum-master*'а, но влияет на команду, работает с ней, а не просто «фасилитирует и передвигает карточки».
Очень важно: держит команду в тонусе. Решение конфликтов, модерирование встреч, выстраивание внутри команды, именно команды, способной решить любую задачу. Подбор людей. Должен разбираться в бизнес-слое продукта и понимать, как работает продукт на системном уровне, не хуже тестировщика.
Аналитик/System analyst — раскладывает бизнес-требования на текущее поведение системы, систематизирует и структурирует требования. Проектирует решение.
Очень важно: чтобы проектирование решения было не в отрыве от команды. Решение всегда лучше проектируется всей командой, потому что один человек не может удержать все нюансы продукта в голове.
Дизайнер/UI|UX designer — отвечает за визуальное отображение и удобство функционала для пользователя. Работает с прототипами, собирает фидбэк от пользователя и думает над улучшениями.
Очень важно: работа через дизайн-систему, любые новые компоненты должны создаваться и проходить ревью через продукта и фронтендеров. UI не должен быть разношёрстным, UX должен быть основан на стандартных паттернах и не заставлять пользователя привыкать к новым и новым поведениям внутри одного продукта.
Бекендер/Backender — отвечает за основную логику продукта, за его бизнес-поведение, скорость работы и отказоустойчивость.
Очень важно: должен хорошо понимать и системный уровень продукта, а также разбираться в бизнес-слое. Не делать необдуманных решений, при подборе решения под задачу лучше сделать 1–2 прототипа и сравнить, чем впоследствии понимать, что выбранное решение было ошибочным. Проводить ревью аналитики.
Фронтендер/Frontender — отвечает за реализацию UI. «Переносит макеты в код :)». Созданные компоненты должны быть легко переиспользованы. Создаёт логику работы с бэкендом.
Очень важно: ревью дизайна через призму наличия компонентов в дизайн-системе и создания новых. Упрощать фантазию дизайна в зависимости от сроков задачи, не давать плодить компоненты-«одиночки». Диктует бэкенду контракты взаимодействия.
Тестировщик/QA — отвечает за качество в продуктовой команде, а это значит отвечает и влияет почти на всё. Ревью идей на оценке, ревью требований аналитики, ревью дизайнов. Ревью тест-кейсов (если у вас больше одного тестировщика). Разбирает проблемы с прода, воспроизводит их, что помогает быстрее разработке найти источник проблемы.
Очень важно: QA всегда должен быть заточен на то, что он является двигателем команды к качеству. Да, хк, хк и продакшен бывает часто, но указать, что нужно запланировать рефакторинг тех или иных моментов. Завести баги, с которыми можно выйти в прод, но не забыть, что их нужно исправить. Ревью всего в команде делает QA отличным источником знаний, особенно в случаях: «Как это работает, судя по коду не должно вообще работать».
