Продуктовая команда и роли
Типичная продуктовая команда, если рассматривать её через призму гибких методологий и моего видения выглядит следующим образом:
ПрОдукт/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 отличным источником знаний особенно в случаях: “Как это работает, судя по коду не должно вообще работать”
