3 типа команд в Agile: универсалы, специалисты и гибридная команда
Начнем с основ: вся суть Agile-подхода в разработке программного обеспечения заключается в двух правилах. Во-первых, быть настоящей командой, и во-вторых, активно коммуницировать. В отличие от традиционного подхода, который основывался на больших командах, четком разграничении ролей и индивидуальной работе каждого, в Agile-командах всё гибко и прозрачно: они работают как единый организм и подменяют друг друга, где нужно.
В идеальном мире Agile-подхода у команд существует 3 типа структуры — рассказываем про каждую отдельно.
Универсалы
Такие команды — это хакеры, которые взломали ход времени. Иначе мы не можем объяснить, как успевают работать за троих и делать всё хорошо. Обычно, в составе команды разработчиков-универсалов есть люди, которые могут занимать сразу несколько ролей и работать с разными частями программного обеспечения. Например, в стартапе универсальный специалист может одновременно работать и на фронте, и на бэкенде, и переключаться между задачами.
Такой тип работы подходит для аутсорсинга разработки программного обеспечения, небольшим IT-командам, которые готовят технически простые проекты в сжатые сроки.
Специалисты
В отличие от универсалов, эти ребята не многозадачны. Они, скорее, обладают экспертизой только в одной области, хорошо делают свою работу, и не обмениваются ролями и задачами с другими участниками команды. В Agile-командах такого типа по разработке программного обеспечения каждый специалист работает над своей частью продукта.
Теперь представьте, сколько может занимать коммуникация и управление процессами разработки, когда в команде есть только один человек, который может ответить на экспертный вопрос из своей области. Поэтому специалисты лучше всего подходят для сложных и инновационных проектов, где нет жёсктих дедлайнов и нужны экспертные знания.
Гибридная команда
Это комбо-команда, которая объединяет под одной крышей как специалистов широкого профиля, так и экспертов в одной области. Как вы могли догадаться, наличие такой структуры команды по разработке программного обеспечения обходится дорого. Плюс, чем больше людей, тем больше времени потребуется на операционные процессы.
Но, если ваша цель — надежный и многосоставной продукт, оно того стоит. Такой подход обеспечивает качественную разработку программного обеспечения для больших сложных проектов, это подтверждает наш опыт и даже научные исследования.
Гибридный формат организации команды разработчиков лучше всего подходит для масштабных проектов с большим бюджетом.
Как это работает в Purrweb
На самом деле, три четко разграниченных типа команд существуют только в книгах по Agile. В реальности команда разработчиков — это сложный микроорганизм, со своими правилами и особенностями. Со временем мы четко разделили роли в IT-команде и наладили быструю и прозрачную коммуникацию внутри. Это позволяет нам работать с любыми проектами, вне зависимости от сложности, размера и бюджета.
В составе команды разработчиков Purrweb есть разные специалисты: универсальные фулстек солдаты и те, кто работает только с фронтендом или бэкендом. Одна из наших главных ценностей — инвестиции в людей. Мы стараемся давать членам команды возможность расти и совершенствовать свою экспертизу. Иногда кто-то сужает свой фокус с нами, а кто-то, наоборот, расширяет набор навыков. Часть наших программистов приходили работать только на клиентской части или на сервере, а позже выросли в мастеров на все руки.
Какие бывают роли в IT-командах
Чтобы лучше понять управление процессами разработки, нужно знать не только схему, по которой построена команда разработчиков, но и кто есть кто в ней.
Вот классический набор:
- владелец продукта
- проектный менеджер
- аккаунт-менеджер
- UI/UX дизайнеры
- разработчики
- QA инженеры
Владелец продукта (product owner, PO)
Этот человек лучше всех знает, как должна будет выглядеть окончательная версия продукта. Когда у команды есть вопросы про идею или саму разработку программного обеспечения, они идут к владельцу продукта за советом и финальным словом.
В некоторых компаниях, при аутсорсинге разработки программного обеспечения, роль проектного менеджера отведена клиентам. Потому что кто может лучше рассказать про идею, чем тот, кто её придумал?
Аккаунт-менеджер
Эти люди не участвуют в разработке программного обеспечения, а общаются с клиентами. Их главная задача — выстраивать коммуникацию с заказчиком и поддерживать долгосрочные отношения. Они сопровождают весь процесс, общаются с клиентами, показывают им отчеты и иногда даже поздравляют с днем рождения и спрашивают про детей. Для аккаунт-менеджера основным KPI является то, насколько заказчик доволен работой и процессом разработки программного обеспечения.
Проектный менеджер (project manager, PM)
Известен также как мастер на все руки и гуру задач! Проектные менеджеры — это посредники в разработке программного обеспечения. Они связывают между собой команду, следят за дедлайнами и периодически проверяют, не нарушился ли рабочий процесс. Во время работы задачи могут прилетать каждую секунду, поэтому легко можно что-то потерять или забыть про срок сдачи. Если такое происходит, на место приходит проектный менеджер, который разбирается, в чем была проблема, и как сделать так, чтобы она больше не повторилась.
Если вы слышите, как кто-то кричит: «Нам нужно ускориться», «Давайте сначала просчитаем риски», «Что-то работает не так», — вероятно, проджект-менеджер где-то близко.
UI/UX дизайнеры
Эта часть команды просыпается утром и сразу думает о пользователе. Она подключается к разработке программного обеспечения на ранних этапах и следит, чтобы все в приложении было простым и понятным. Им помогают UI/UX копирайтеры, которые следят за текстом в решении и знают, как уместить важное объявление в push-уведомление, чтобы его открыли и прочитали.
Разработчики
Тут всё просто: они отвечают за задачи, связанные с разработкой программного обеспечения. Программисты создают приложения на основе технических требований и собирают архитектуру приложения. Обычно для одного проекта нужно сразу несколько разработчиков: те, кто работают на фронтенде, бэкенде, и фулстек-универсалы.
QA инженеры
Quality assurance — обеспечение качества продукта. Тестировщики ищут и удаляют баги с самого начала, а также следят, чтобы решение хорошо работало на каждом этапе процесса разработки программного обеспечения.
Как это работает в Purrweb
На пути к идеальной структуре мы сделали несколько ошибок и многому научились. Этот опыт помог нам узнать больше об управлении процессами разработки и разграничивать роли в IT-команде.
Было время, когда у нас не было аккаунт-менеджера, и процесс работы с новыми клиентами был хаотичным. Первый контакт происходил с менеджером по продажам, затем они передавали проджект-менеджеру, которые взаимодействовали и с командой, и с заказчиками сразу. Нам потребовалось время, чтобы вырасти и понять, что мы упустили. Теперь у нас есть отдельные люди, который работают только с продажами, только с клиентами, и только с командой внутри.
В Purrweb мы доверяем роль владельца продукта нашим заказчикам, потому что они знают подробности идеи лучше нас. Это не означает, что мы нанимаем их на работу 😅 Когда к нам приходит клиент, у него есть идея, а у нас — экспертиза и опыт. Поэтому мы даем возможность заказчикам «владеть продуктом»: отвечать на наши вопросы и выбирать финальные концепты, при этом учитывая наши советы и предложения.
Что касается дизайнеров, то тут мы тоже выработали четкую схему. На каждый проект по разработке программного обеспечения мы назначаем двух специалистов, которые работают в связке: сотрудничают и дополняют опыт друг друга. Также, у нас есть ведущие дизайнеры, которые обучают новичков и одобряют концепции дизайна для решений.
У разработчиков Purrweb тоже есть свои правила: в их команде есть тимлид, который отвечает за управление процессом разработки и контролирует промежуточные результаты. Кроме того, мы предпочитаем сами обучать новичков работать с фулстеком 😈.
Как понять, что перед вами эффективная организация команды разработчиков?
Когда вы только погружаетесь в разработку программного обеспечения и знакомитесь с командой, то уже с первого взгляда можно понять, будет ли сотрудничество приятным и полезным для обеих сторон. Вы спросите, как? Рассказываем!
При аутсорсинге разработки программного обеспечения следует обратить внимание на несколько вещей:
- Налажена ли у них коммуникация? Посмотрите, как члены команды общаются между собой. Да, программисты не роботы и столкновения на рабочем месте неизбежны, даже при разработке программного обеспечения. Но в здоровых, хорошо организованных командах есть инструменты, как договариваться и разрешать конфликты. Можно сразу спросить: «Ребята, а как вы коммуницируете между собой? Какие приложения используете, чтобы оставаться в курсе рабочего процесса?». Если вам расскажут про Slack, Jira и Targetprocess — направление уже верное.
- Как они распределяют рабочие роли? Главное правило хорошей Agile-команды — отсутствие хаоса. Процесс разработки программного обеспечения должен быть структурирован, а каждый участник — знать, что он должен делать и к кому обращаться за советами. Чтобы проверить, как это устроено, вы можете просто спросить команду, как выглядит их рабочий процесс, кто отвечает за каждый шаг и кому вы можете задать вопрос о промежуточных результатах.
- Есть ли у них общие цели? Большинству Agile-команд не нужны четкая иерархия и строгий контроль, потому что у них общие цели и они знают, ради чего работают каждый день. Например, в Purrweb наша цель — помочь стартапам быстро проверить свои бизнес-идеи, и если вы спросите кого-либо из нашей 100 членов команды, они скажут вам тоже самое.
- Могут ли они быть независимыми? При разработке программного обеспечения строгий надзор не приносит никакой пользы ни клиенту, ни команде. Чтобы следить за каждым движением, со стороны заказчика потребуется много времени, которого у стартаперов обычно нет. А для команд пристальный контроль может демотивировать и мешать креативности. В общем, хорошая команда должна уметь работать независимо, чтобы вам не приходилось тратить все силы на управление процессами разработки.
Итоги
Cо временем, в Purrweb, нам удалось сформировать сильную профессиональную команду. Мы не можем сказать, к какому из трех типов организации команды разработчиков мы относимся, но мы нашли индивидуальную схему, которая работает для нас и делает процесс эффективным.
Наша команда создает мобильные приложения и веб-решения с фокусом на минималистичный и грамотный UI/UX-дизайн. Мы — команда полного цикла, и это означает, что у нас в составе есть все необходимые люди для разработки программного обеспечения: разработчики, UI/UX-дизайнеры и копирайтеры, QA инженеры и проджект-менеджеры. Так что вам не потребуется нанимать кого-либо еще для проверки своей идеи.
Хотите познакомиться с нашей командой и получить помощь в проверке идеи для вашего стартапа? Напишите нам!
