Хочу продуктовую команду и можно без хлеба

Продуктовая команда и роли

Типичная продуктовая команда, если рассматривать её через призму гибких методологий и моего видения выглядит следующим образом:

ПрОдукт/Product Owner — создает новые идеи для продукта, чтобы решать проблемы пользователя продукта или увеличить прибыть продукта/компании.

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

Руководитель проекта/Delivery manager/IT Project manager — организовывает процессы работы в команде, отвечает за сроки и порядок выполнения фич, контролирует доставку фич до прода (пользователя). Работает и транслирует команде принятую методологию. Выполняет функции Scrum-master’a но влияет на команду, работает с ней, а не просто «фасилитирует и передвигает карточки».

Очень важно: Держит команду в тонусе. Решение конфликтов, модерирование встреч, выстраивание внутри команды, именно команды способной решить любую задачу. Подбор людей. Должен разбираться в бизнес слое продукта и понимать как работает продукт на системном уровне не хуже тестировщика.

Аналитик/System analyst — раскладывает бизнес требования на текущее поведение системы, систематизирует и структурирует требования. Проектирует решение.

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

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

Бекендер/Backender — отвечает за основную логику продукта, за его бизнес поведение, скорость работы и отказоустойчивость.

Очень важно: Должен хорошо понимать и системный уровень продукта, а также разбираться в бизнес слое. Не делать необдуманных решений, при подборе решения под задачу лучше сделать 1-2 прототипа и сравнить, чем в последствии понимать, что выбранное решение было ошибочным. Проводить ревью аналитики.

Фронтендер/Frontender — отвечает за реализацию UI. «Переносит макеты в код :)». Созданные компоненты должны быть легко переиспользованы. Создает логику работы с бэкендом.

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

Тестировщик/QA — Отвечает за качество в продуктовой команде, а это значит отвечает и влияет почти на всё. Ревью идей на оценке, ревью требований аналитики, ревью дизайнов. Ревью тест кейсов (если у вас больше 1го тестировщика). Разбирает проблемы с прода, воспроизводит их, что помогает быстрее разработке найти источник проблемы.

Очень важно: QA всегда должен быть заточен на то, что он является двигателем команды к качеству. Да х**к, х**к и продакшен бывает часто, но указать, что нужно запланировать рефакторинг тех или иных моментов. Завести баги с которыми можно выйти в прод, но не забыть, что их нужно исправить. Ревью всего в команде делает QA отличным источником знаний особенно в случаях: «Как это работает, судя по коду не должно вообще работать»

Views: 12

Share this article
Shareable URL
Prev Post

Игровые приемы. «Города». Categories game

Next Post

Красиво делать, некрасиво не делать. Или как формируется внутренняя культура разработки

Добавить комментарий
Read next