И хотя с обязанностями разработчиков все довольно ясно, с бизнес-менеджерами, менеджерами по продукту и другими сотрудниками все может запутаться.
В этой статье мы расскажем, как команды разработчиков программного обеспечения структурируют свою работу, каковы роли и обязанности каждого члена команды и как узнать, хорошо ли ваша команда работает с вашим продуктом.
Три подхода к структуре продуктовой команды Начнем с основ. Есть несколько способов организовать гибкую команду разработчиков продукта - универсальная, специализированная и гибридная.
Универсальная Команда, состоящая из людей с широким набором навыков и опыта, называется «универсальной». Такие команды обычно несут ответственность за непрерывную разработку всего проекта или отдельной функции. Это наиболее распространенная структура проектной команды для аутсорсинговых компаний.
Плюсы универсального подхода
- Каждый член команды хорошо разбирается в продукте, поэтому может сосредоточиться на его улучшении в целом.
- Каждый человек достаточно компетентен, чтобы выполнять свою работу без зависимости от других.
Минусы универсального подхода
- Поскольку никто не обладает конкретными знаниями, иногда бывает необходимо привлечь нового члена команды в середине проекта.
Специализированная
В состав «специализированной» группы по продукту входят специалисты с суперсекретным набором навыков, умеющие решать узкие задачи. Каждый профессионал в своей нише и поэтому несет полную ответственность за свой элемент проекта. Такой порядок также довольно распространен для команд разработчиков программного обеспечения.
Плюсы такого подхода
- Глубокое знание каждого элемента проекта.
- Команда может очень быстро построить сложные высококачественные системы.
Минусы данного подхода
- Поскольку каждый работает индивидуально, есть вероятность, что компоненты не подходят с первых итераций.
- Возможны пробелы в общении из-за отсутствия общих знаний.
Гибридный
«Гибридная» структура команды проекта - это, по сути, комбинация универсалов и специалистов. Такие команды работают над проектом в целом, но при необходимости могут сузить круг своих задач. Гибридный подход - лучшее из обоих миров.
Плюсы гибридного подхода
- Есть как специалисты, которые создают отдельные компоненты, так и универсалы, которые следят за интеграцией системы.
- Процесс разработки максимально эффективен.
Минусы гибридного подхода
- Может быть сложно скоординировать людей с разными подходами к рабочему процессу.
- Создание гибридной команды занимает много времени и очень дорого.
Типовая структура команды разработчиков программного обеспечения
В идеальном мире каждый имел бы в штате горстку специалистов широкого профиля и специалистов, и они бы очень хорошо ладили друг с другом. Но реальность такова, что у каждого бизнеса есть ограничения - время и бюджет. Вот почему большинство аутсорсинговых команд разработки программного обеспечения являются универсальными.
Так кто именно составляет эти команды? Пройдемся по ключевым позициям.
Cхема структуры команды аутсорсинга разработки программного обеспечения
Бизнес-аналитик (BA)
- Это тот, кто отвечает за формулировку целей, анализ и документирование основных процессов и систем, а также обеспечение согласованности бизнес-модели и технологий. BA - это все для всех. Они оценивают, что работает, а что не работает, и задают направление развития бизнеса.
Менеджер проекта (PM)
- Этот человек отвечает за планирование и выполнение. PM несет ответственность за выполнение работы. Они также заботятся о построении отношений между клиентом и различными подразделениями организации. Менеджеры проекта контролируют все процессы, делегируют задачи другим членам команды и следят за тем, чтобы все не сбились с пути.
Дизайнер UX
- Это тот, кто разрабатывает способ взаимодействия пользователей с продуктом. Они гарантируют, что все функции решают проблемы людей и достигают бизнес-целей. А именно они определяют, как будет выглядеть продукт и как он будет работать. Основное внимание в UX-дизайнере уделяется функциональности и удобству использования.
Разработчики (Front-end / Back-end)
- Это люди, которые и занимаются кодированием. В то время как разработчики интерфейса работают над элементами продукта, ориентированными на клиента, разработчики внутреннего интерфейса заботятся о его функциональности, а это все, чего не видит пользователь.
Инженер по обеспечению качества (QA)
- Это тот, кто тестирует продукт, чтобы убедиться, что он хорошо работает, соответствует стандартам качества и требованиям клиентов. QA - это как окончательный редактор, в котором уделяется пристальное внимание мельчайшим деталям. Они обнаруживают ошибки на раннем этапе, чтобы команда могла исправить их до того, как они попадут к пользователям.
Чем отличается структура команды Agile разработчиков?
На первый взгляд, у Agile-команды есть еще несколько дополнительных рабочих ролей. Но давайте на секунду вспомним Agile Manifesto .
- Люди и взаимодействие важнее процессов и инструментов
- Рабочее программное обеспечение над исчерпывающей документацией
- Сотрудничество с клиентами вместо переговоров по контракту
- Реагирование на изменения вместо следования плану
Основное различие между традиционной и гибкой структурой команды заключается в том, как люди взаимодействуют друг с другом.
Традиционная команда против Agile-команды
Традиционная команда - Управление проектами сверху вниз. Менеджер проекта несет ответственность за выполнение работы.
- Команды могут работать над несколькими проектами одновременно.
- Организация оценивает индивидуальную производительность
- Четкие роли и должности
- Нет ограничений по размеру команды
- Сотрудники называются человеческими ресурсами
Agile команда
- Самоорганизованная и самоуправляемая команда. Роль PM - тренировать команду, устранять препятствия и не отвлекаться.
- Команды сосредотачиваются на одном проекте за раз.
- Организация оценивает работу команды
- Кросс-функциональные команды, навыки важнее званий.
- От трех до девяти человек в команде.
- Сотрудников называют талантами .
Роли и обязанности в команде Agile разработки программного обеспечения
Владелец продукта
- Обычно является ключевым участником проекта. Это тот, кто глубоко знает пользователя и продукт и отвечает за внутреннюю сторону разработки. Их задача - убедиться, что конечный продукт / услуга соответствует потребностям клиента. PO следит за командой, поддерживает и координирует ее работу, а также обеспечивает выполнение всех требований к продукту.
Скрам Мастер
- Прежде всего, давайте определимся с Scrum. Это методология, которая помогает гибким командам самоорганизовываться и адаптироваться к изменениям в соответствии с принципами гибкой разработки. А Скрам-мастер - это владелец процесса, который координирует работу команды. Он помогает и мастер управляет всем, что происходит в команде.
Команда разработчиков
- Это группа штатных или преданных разработчиков, которые вместе работают над проектом. Как и в традиционной команде, в группу Agile-разработчиков входят разработчики внешнего и внутреннего интерфейса, дизайнеры UX и тестеры QA. Они работают над продуктом в тесном сотрудничестве.
Характеристика эффективной команды программистов
Посредственная команда никогда не создавала ни одного выдающегося продукта. Таким образом, самая большая задача каждой организации - обеспечить, чтобы их люди были мотивированы работать с максимальной отдачей. И хотя практически каждый может найти квалифицированных сотрудников, не каждой организации удается создать благоприятную среду для совместной работы, позволяющую процветать своим командам.
Как сказать, что ваша команда эффективна? Ищите следующие черты
- Они хорошо общаются. Коммуникация всегда лежит в основе командной работы, независимо от отрасли, и разработка программного обеспечения не исключение. В отличных командах у людей есть все необходимые инструменты и процессы для регулярного здорового общения.
- Они работают ради общей цели. Хорошие команды не нуждаются в строгом управлении сверху вниз. У них четкие цели и общая миссия. В такой среде успех команды воспринимается как успех каждого человека.
- У них есть четко определенные обязанности. В то время как команда разделяет общую цель, каждый человек точно знает, что ему нужно сделать, чтобы все это работало. Ожидания, роли и зоны ответственности определены с самого начала, и люди несут ответственность друг за друга за достижение прогресса.
- У них сильная культура. Наличие сильной культуры означает развитие профессиональных связей, поддержку и уважение друг к другу, а также чувство комфорта в компании друг друга. Такие команды с удовольствием проводят время вместе как на работе, так и вне офиса.
- Их не нужно контролировать. Управление сверху вниз постепенно уходит в прошлое, потому что великие команды с общими целями и общим видением не нуждаются в продвижении. Они делают свою работу хорошо, потому что хотят, а не потому, что их заставляют.