Иногда может показаться, что команда разработчиков, с которой вы работаете, говорит на другом языке 😅 Они называют людей непонятными аббревиатурами, вроде PO, PM, PMM, и обсуждают Agile, Kanban и Scrum. Без паники, сейчас мы расскажем, что это значит! В Purrweb мы занимаемся разработкой программного обеспечения с 2014 года. На протяжении этого времени мы экспериментировали с ролями в команде и пробовали несколько способов коммуникации, до тех пор пока не нашли то, что подходит именно нам. В этой статье мы поделимся своим опытом организации команды разработчиков и расскажем, какие роли существуют в IT команде. Вы узнаете, на что обращать внимание при аутсорсинге разработки программного обеспечения, и как собрать команду и избежать основных ошибок. Поехали!
Время чтения: 6 минут
Ищете слаженную команду разработки?
Поможем с дизайном и разработкой приложений для бизнеса и стартапов
Начнем с основ: вся суть Agile-подхода в разработке программного обеспечения заключается в двух правилах. Во-первых, быть настоящей командой, и во-вторых, активно коммуницировать. В отличие от традиционного подхода, который основывался на больших командах, четком разграничении ролей и индивидуальной работе каждого, в Agile-командах всё гибко и прозрачно: они работают как единый организм и подменяют друг друга, где нужно.
В идеальном мире Agile-подхода у команд существует 3 типа структуры — рассказываем про каждую отдельно.
Такие команды — это хакеры, которые взломали ход времени. Иначе мы не можем объяснить, как успевают работать за троих и делать всё хорошо. Обычно, в составе команды разработчиков-универсалов есть люди, которые могут занимать сразу несколько ролей и работать с разными частями программного обеспечения. Например, в стартапе универсальный специалист может одновременно работать и на фронте, и на бэкенде, и переключаться между задачами.
Такой тип работы подходит для аутсорсинга разработки программного обеспечения, небольшим IT-командам, которые готовят технически простые проекты в сжатые сроки.
В отличие от универсалов, эти ребята не многозадачны. Они, скорее, обладают экспертизой только в одной области, хорошо делают свою работу, и не обмениваются ролями и задачами с другими участниками команды. В Agile-командах такого типа по разработке программного обеспечения каждый специалист работает над своей частью продукта.
Теперь представьте, сколько может занимать коммуникация и управление процессами разработки, когда в команде есть только один человек, который может ответить на экспертный вопрос из своей области. Поэтому специалисты лучше всего подходят для сложных и инновационных проектов, где нет жёсктих дедлайнов и нужны экспертные знания.
Это комбо-команда, которая объединяет под одной крышей как специалистов широкого профиля, так и экспертов в одной области. Как вы могли догадаться, наличие такой структуры команды по разработке программного обеспечения обходится дорого. Плюс, чем больше людей, тем больше времени потребуется на операционные процессы.
Но, если ваша цель — надежный и многосоставной продукт, оно того стоит. Такой подход обеспечивает качественную разработку программного обеспечения для больших сложных проектов.
Гибридный формат организации команды разработчиков лучше всего подходит для масштабных проектов с большим бюджетом.
На самом деле, три четко разграниченных типа команд существуют только в книгах по Agile. В реальности команда разработчиков — это сложный микроорганизм, со своими правилами и особенностями. Со временем мы четко разделили роли в IT-команде и наладили быструю и прозрачную коммуникацию внутри. Это позволяет нам работать с любыми проектами, вне зависимости от сложности, размера и бюджета.
В составе команды разработчиков Purrweb есть разные специалисты: универсальные фулстек солдаты и те, кто работает только с фронтендом или бэкендом. Одна из наших главных ценностей — инвестиции в людей. Мы стараемся давать членам команды возможность расти и совершенствовать свою экспертизу. Иногда кто-то сужает свой фокус с нами, а кто-то, наоборот, расширяет набор навыков. Часть наших программистов приходили работать только на клиентской части или на сервере, а позже выросли в мастеров на все руки.
Чтобы лучше понять управление процессами разработки, нужно знать не только схему, по которой построена команда разработчиков, но и кто есть кто в ней.
Вот классический набор:
Этот человек лучше всех знает, как должна будет выглядеть окончательная версия продукта. Когда у команды есть вопросы про идею или саму разработку программного обеспечения, они идут к владельцу продукта за советом и финальным словом.
В некоторых компаниях, при аутсорсинге разработки программного обеспечения, роль проектного менеджера отведена клиентам. Потому что кто может лучше рассказать про идею, чем тот, кто её придумал?
Эти люди не участвуют в разработке программного обеспечения, а общаются с клиентами. Их главная задача — выстраивать коммуникацию с заказчиком и поддерживать долгосрочные отношения. Они сопровождают весь процесс, общаются с клиентами, показывают им отчеты и иногда даже поздравляют с днем рождения и спрашивают про детей. Для аккаунт-менеджера основным KPI является то, насколько заказчик доволен работой и процессом разработки программного обеспечения.
Известен также как мастер на все руки и гуру задач! Проектные менеджеры — это посредники в разработке программного обеспечения. Они связывают между собой команду, следят за дедлайнами и периодически проверяют, не нарушился ли рабочий процесс. Во время работы задачи могут прилетать каждую секунду, поэтому легко можно что-то потерять или забыть про срок сдачи. Если такое происходит, на место приходит проектный менеджер, который разбирается, в чем была проблема, и как сделать так, чтобы она больше не повторилась.
Если вы слышите, как кто-то кричит: «Нам нужно ускориться», «Давайте сначала просчитаем риски», «Что-то работает не так», — вероятно, проджект-менеджер где-то близко.
Эта часть команды просыпается утром и сразу думает о пользователе. Она подключается к разработке программного обеспечения на ранних этапах и следит, чтобы все в приложении было простым и понятным. Им помогают UI/UX копирайтеры, которые следят за текстом в решении и знают, как уместить важное объявление в push-уведомление, чтобы его открыли и прочитали.
Тут всё просто: они отвечают за задачи, связанные с разработкой программного обеспечения. Программисты создают приложения на основе технических требований и собирают архитектуру приложения. Обычно для одного проекта нужно сразу несколько разработчиков: те, кто работают на фронтенде, бэкенде, и фулстек-универсалы.
Quality assurance — обеспечение качества продукта. Тестировщики ищут и удаляют баги с самого начала, а также следят, чтобы решение хорошо работало на каждом этапе процесса разработки программного обеспечения.
На пути к идеальной структуре мы сделали несколько ошибок и многому научились. Этот опыт помог нам узнать больше об управлении процессами разработки и разграничивать роли в IT-команде.
Было время, когда у нас не было аккаунт-менеджера, и процесс работы с новыми клиентами был хаотичным. Первый контакт происходил с менеджером по продажам, затем они передавали проджект-менеджеру, которые взаимодействовали и с командой, и с заказчиками сразу. Нам потребовалось время, чтобы вырасти и понять, что мы упустили. Теперь у нас есть отдельные люди, который работают только с продажами, только с клиентами, и только с командой внутри.
В Purrweb мы доверяем роль владельца продукта нашим заказчикам, потому что они знают подробности идеи лучше нас. Это не означает, что мы нанимаем их на работу 😅 Когда к нам приходит клиент, у него есть идея, а у нас — экспертиза и опыт. Поэтому мы даем возможность заказчикам «владеть продуктом»: отвечать на наши вопросы и выбирать финальные концепты, при этом учитывая наши советы и предложения.
Что касается дизайнеров, то тут мы тоже выработали четкую схему. На каждый проект по разработке программного обеспечения мы назначаем двух специалистов, которые работают в связке: сотрудничают и дополняют опыт друг друга. Также, у нас есть ведущие дизайнеры, которые обучают новичков и одобряют концепции дизайна для решений.
У разработчиков Purrweb тоже есть свои правила: в их команде есть тимлид, который отвечает за управление процессом разработки и контролирует промежуточные результаты. Кроме того, мы предпочитаем сами обучать новичков работать с фулстеком 😈.
Новости и актуальные тренды из мира стартапов в нашем Telegram-канале Стартап-пикап.
Когда вы только погружаетесь в разработку программного обеспечения и знакомитесь с командой, то уже с первого взгляда можно понять, будет ли сотрудничество приятным и полезным для обеих сторон. Вы спросите, как? Рассказываем!
При аутсорсинге разработки программного обеспечения следует обратить внимание на несколько вещей:
Cо временем, в Purrweb, нам удалось сформировать сильную профессиональную команду. Мы не можем сказать, к какому из трех типов организации команды разработчиков мы относимся, но мы нашли индивидуальную схему, которая работает для нас и делает процесс эффективным.
Наша команда создает мобильные приложения и веб-решения с фокусом на минималистичный и грамотный UI/UX-дизайн. Мы — команда полного цикла, и это означает, что у нас в составе есть все необходимые люди для разработки программного обеспечения: разработчики, UI/UX-дизайнеры и копирайтеры, QA инженеры и проджект-менеджеры. Так что вам не потребуется нанимать кого-либо еще для проверки своей идеи.
Хотите познакомиться с нашей командой и получить помощь в проверке идеи для вашего стартапа? Напишите нам!
Насколько публикация полезна?
Оцени эту статью!
15 оценок, среднее 4.6 out of 5.
Оценок пока нет. Поставьте оценку первым.
Так как вы нашли эту публикацию полезной...
Подписывайтесь на нас в соцсетях!
Читать
Ваша заявка уже у нас :)
Обычно ответ занимает от 12 до 24 рабочих часов.
Может, вы хотите запланировать онлайн встречу?
Извините, что-то пошло не так при отправке запроса.
Попробуйте позже.