Команда разработки: роли, состав и зоны ответственности

Над одним проектом работают шесть человек, над другим — пятнадцать, и оба выпускают приложение в срок. Дело не в количестве, а в том, какие зоны ответственности закрыты и кто именно отвечает за результат каждого этапа. Дальше — из кого состоит команда разработки, что делает каждый специалист, кто подключается на каких этапах, какие роли остаются за бизнесом и какие вопросы задать подрядчику, чтобы понять, кто именно будет работать над проектом.

6 сентября 2026 Разработка 16 мин чтения

---

Что такое команда разработки и из кого она состоит

Команда разработки — это не список должностей в договоре, а набор закрытых зон ответственности. За каждый результат отвечает конкретный человек: за требования, за интерфейс, за код приложения, за серверную часть, за проверку перед выпуском, за срок и коммуникацию. Пока все зоны закрыты, проект движется. Как только одна остаётся ничьей, она всплывает в конце — обычно перед публикацией в магазинах приложений, когда исправление стоит дороже всего.

Ролей всегда больше, чем людей. В небольшом проекте один специалист закрывает две-три роли: аналитик пишет требования и ведёт приёмку, разработчик заодно настраивает сборку. В крупном одна роль делится между несколькими: два клиентских разработчика, два серверных, отдельный инженер по тестированию на каждое направление. Поэтому вопрос «сколько человек в команде» сам по себе не отвечает ни на что — значение имеет, какие роли закрыты и кем именно.

Базовый набор ролей для мобильного приложения интернет-магазина выглядит так:

• Менеджер проекта — срок, бюджет, коммуникация, порядок изменений.
• Бизнес-аналитик — требования, сценарии, описание интеграций.
• UX/UI-дизайнер — путь пользователя и внешний вид экранов.
• Клиентский разработчик — код приложения, которое видит покупатель.
• Серверный разработчик — данные, интеграции, нагрузка.
• Инженер по тестированию — проверка перед каждым выпуском.

Ещё три роли подключаются точечно, но без них проект тоже не доезжает: DevOps-инженер (сборка, стенды, публикация), технический руководитель (архитектура и стандарты кода) и специалист по продвижению в магазинах приложений (карточка, описания, ключевые запросы). Их не держат в проекте на полную загрузку — они входят на своих отрезках.

И есть вторая половина команды, о которой на старте вспоминают реже, — люди со стороны бизнеса. Владелец продукта принимает решения, контент-менеджер отдаёт описания и фотографии товаров, технический специалист заказчика выдаёт доступы к учётной системе. Эта часть подробно разобрана в разделе «Какие роли остаются за бизнесом», и именно она чаще всего оказывается узким местом по срокам.

Четыре формата команды: чем они отличаются

Закрыть роли можно четырьмя способами, и выбор между ними — это в первую очередь выбор того, кто отвечает за результат целиком. Дальше в таблице сроки сборки состава приведены в рабочих днях, чтобы форматы сравнивались в одних единицах.

У каждого формата своя сильная сторона, и она не всегда там, где кажется.

• Штатная команда выигрывает на длинной дистанции. Знания о продукте остаются внутри компании, а не уходят вместе с договором, и на третий год такая команда работает быстрее любой внешней — потому что помнит, почему когда-то было сделано именно так. Плата за это — постоянные расходы на людей независимо от того, есть ли сейчас поток задач.
• Отдельные исполнители дешевле всех на точечной задаче с понятным результатом: один экран, одна интеграция, разовая правка вёрстки. Как только задач становится больше трёх и они начинают зависеть друг от друга, экономия съедается согласованием работ между исполнителями.
• Аутстафф сильнее там, где процесс уже выстроен и не хватает только рук: свой менеджер, свои правила работы с кодом, своя приёмка. Мы закрываем такие задачи отдельными специалистами — Flutter-разработчиками, серверными разработчиками, инженерами по тестированию, дизайнерами и DevOps-инженерами.
• Команда под ключ закрывает случай, когда собственной технической функции нет или она занята другим. Состав закреплён за проектом с первого дня, ответственность за срок и результат — на одной стороне, и бизнесу не нужно управлять шестью специалистами одновременно.

У формата «под ключ» есть и обратная сторона, о которой честнее сказать сразу: знания о продукте накапливаются вне компании. Снимается это договорными вещами, а не доверием — доступ к исходному коду, актуальная документация, схемы интеграций и понятный порядок передачи проекта другой команде. Эти пункты стоит проверять до подписания, а не после. Развёрнутое сравнение с наймом внутрь мы разбирали в материале «Аутсорс-разработка или внутренняя команда», а модели работы в целом — в статье о сравнении моделей разработки.

Когда какой формат оправдан

Пять ситуаций, в которых выбор обычно очевиден.

1. Мобильного канала пока нет, нужно запуститься. Внутри компании нет ни разработчиков, ни человека, который умеет ими управлять. Формат — команда под ключ: состав закреплён, срок зафиксирован, у бизнеса остаётся приёмка и решения по продукту.
2. Приложение есть, его делал другой подрядчик, развитие остановилось. Здесь сначала нужна не команда, а понимание состояния: аудит кода или аудит приложения показывает, что можно развивать, а что придётся переписывать. Состав подбирается уже под ответ.
3. Своя команда есть, но упирается в сроки. Процесс выстроен, задач больше, чем рук. Формат — отдельные специалисты в вашу команду на срок пика, с выходом после него.
4. Продукт стал основным каналом продаж. Когда через приложение проходит заметная доля выручки, компания обычно начинает строить внутреннюю команду и оставляет внешней стороне отдельные направления — сложные интеграции, нагрузку, сопровождение.
5. Нужна одна конкретная доработка. Добавить оплату долями, поменять экран корзины, подключить новую службу доставки. Полноценный состав здесь избыточен: задача закрывается точечно, по часам.

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

Роли и зоны ответственности: кто за что отвечает

Ниже — девять ролей, из которых собирается любая команда мобильной разработки. Для каждой указано, за что человек отвечает и какой результат остаётся у бизнеса после его работы. Именно результат, а не процесс: документ, макет, собранное приложение, отчёт — то, что можно взять и проверить.

Менеджер проекта

Держит срок, объём и деньги в одном месте. Собирает план работ, ведёт статусы, заранее говорит о том, что поедет, и оформляет изменения объёма — а они появляются на любом проекте. Главный признак работающего менеджера: заказчик узнаёт о сдвиге срока за две недели до него, а не в день сдачи. Он же единственная точка входа для бизнеса: чтобы задать вопрос по проекту, не нужно помнить, кто именно из шести специалистов сейчас этим занят.

Бизнес-аналитик

Переводит «хотим приложение как у крупных сетей» в описание, по которому можно писать код и считать часы. Разбирает сценарии до деталей, которые всплывают потом: что происходит с корзиной, если товар закончился при оформлении; как считается бонус при частичном возврате; какие поля обязательны при заказе на юридическое лицо. Результат его работы — техническое задание и схемы интеграций. Это же документ, который потом защищает обе стороны при споре об объёме работ. Отдельно эту функцию мы закрываем услугой бизнес-аналитики для IT-проектов.

UX/UI-дизайнер

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

Клиентский разработчик

Собирает то, что покупатель держит в руках: экраны, переходы, работу без сети, скорость прокрутки каталога. На Flutter один специалист закрывает сразу несколько целевых платформ — приложение для iOS и Android, сборку для RuStore и других сторов, а при необходимости и веб-версию из того же кода. Отсюда прямое следствие для состава: там, где при раздельной разработке нужны два специалиста с разными языками, работает один. Детали технологии — на сайте flutter.dev, требования магазинов — у Apple и Google.

Серверный разработчик

Отвечает за всё, что происходит после нажатия кнопки: где лежат товары и заказы, как они попадают в учётную систему, что произойдёт в день распродажи. Его зона — обмен данными между приложением и системами компании: 1С, CRM, склад, эквайринг, службы доставки, маркетплейсы. Здесь же живут два вопроса, которые всплывают позже всего: устройство обмена данными и поведение под пиковой нагрузкой.

Инженер по тестированию

Проверяет продукт до того, как его проверит покупатель. Роль часто пытаются сэкономить — «разработчики проверят сами». На практике человек редко находит ошибку в собственном коде: он проходит сценарий так, как задумывал, а не так, как ходит покупатель. Инженер по тестированию собирает план проверок, ведёт список ошибок и постепенно переводит повторяющиеся денежные пути в автоматические сквозные тесты, чтобы перед каждым выпуском не проходить всё руками. Подробнее — в материале о тестировании мобильных приложений и в услуге тестирования и QA.

DevOps-инженер

Делает так, чтобы сборка приложения появлялась сама и всегда одинаково. Настраивает автоматическую сборку по каждому изменению кода, поднимает тестовый стенд, готовит учётные записи и сертификаты для публикации в магазинах. На небольшом проекте эта роль занимает несколько дней на старте и дальше подключается точечно, но если её не закрыть, команда вручную собирает сборки и теряет по часу на каждой. Отдельно понадобится и проверка под нагрузкой, если ожидаются распродажи.

Технический руководитель

Принимает решения, которые дороже всего менять потом: как устроена архитектура, где хранятся данные, какие внешние сервисы подключаются, что делаем сами, а что берём готовым. Проверяет код команды и держит единые правила, чтобы через год продукт можно было передать другим людям без археологии. На проекте средней величины эта роль занимает часть времени одного человека, а не отдельную ставку.

Специалист по продвижению в сторах

Отвечает за то, найдут ли приложение после публикации. Собирает описания и скриншоты, подбирает запросы, готовит карточку под требования площадок и следит за отзывами. Роль подключается за пару недель до выпуска и остаётся после — работа с карточкой идёт постоянно, а не разово. Требования площадок различаются, и RuStore проверяет сборку по своим правилам.

Составы под разные проекты: от первого приложения до сети

Один и тот же набор ролей раскладывается на разное количество людей. Ниже — три типовых состава и то, что в них обычно совмещается.

Правило, которое работает на любом объёме: совмещать можно роли, которые не проверяют друг друга. Аналитик и приёмка — сочетаются. Дизайнер и клиентский разработчик — сочетаются. Разработчик и тестировщик его же кода — нет, потому что проверяющий должен смотреть на продукт со стороны покупателя, а не автора.

Какие роли остаются за бизнесом

Даже когда команда закреплена за проектом целиком, четыре роли остаются у заказчика. Их нельзя передать наружу, и по нашему опыту именно они чаще всего сдвигают срок.

• Владелец продукта — одна точка решений. Человек, чьё «да» окончательное. Когда решения принимают пятеро, правки начинают спорить между собой, а команда переделывает один экран трижды.
• Ответственный за контент. Описания, фотографии и характеристики товаров нужны раньше, чем кажется: пустой каталог невозможно нормально проверить, а на демонстрации он выглядит недоделанным.
• Технический специалист с доступами. Учётная система, CRM, эквайринг, аккаунты в магазинах приложений. Ожидание доступа к 1С — типовая причина недельной паузы в работе команды.
• Ответственный за приёмку. Тот, кто проходит готовые сценарии и подтверждает, что они работают так, как договаривались. Без такого человека приёмка растягивается на месяц переписки.

Хорошая практика — зафиксировать эти четыре роли поимённо в самом начале, вместе с составом команды подрядчика. Другие частые сложности на стороне заказчика собраны в материале об ошибках заказчика при разработке приложения.

Кто подключается на каких этапах

Команда не работает в полном составе все дни проекта. Люди входят и выходят по этапам — от этого зависит и загрузка, и смета.

Две вещи из этой таблицы стоит запомнить. Первая: аналитик и менеджер работают на проекте почти всегда, а разработчики — на своём отрезке, поэтому «команда из десяти человек» никогда не означает десять человек ежедневно. Вторая: пятый этап зависит не только от подрядчика — если приёмка на стороне бизнеса не назначена, срок публикации плывёт независимо от того, насколько быстро написан код. Пошаговая версия процесса — в материале об этапах разработки мобильного приложения и в статье о жизненном цикле продукта.

Сколько стоит команда разработки и из чего складывается смета

Стоимость команды считается тремя способами, и разница между ними — в том, кто несёт последствия неточной оценки объёма.

Первые две модели подробно сравнивались в материале «Time & Materials или Fix Price». Про третью скажем отдельно, потому что она напрямую меняет состав команды.

Модель FITTIN состоит из трёх частей. Первое — единоразовая интеграция модульной платформы под бренд: до 30 рабочих дней, от 525 000 ₽ по тарифу ПРО для одного направления. Второе — ежемесячные лицензионные платежи от 150 000 ₽, в которые уже включены все затраты на техническую поддержку команды FITTIN: мониторинг работы, обновления модулей и обновления безопасности. Своя команда разработки при этом не нужна. Третье — новый функционал и доработки, они считаются отдельно по часам, с оценкой и сметой до начала работ. Полные условия по трём направлениям — на странице тарифов.

Роли при этом не исчезают — меняется то, кто их закрывает. Каталог, корзина, оплата, лояльность, push-уведомления и интеграции с 1С и маркетплейсами уже собраны в модулях платформы и поддерживаются командой FITTIN. За проектом закрепляются аналитик, дизайнер, Flutter- и серверные разработчики, инженер по тестированию и менеджер — они занимаются тем, что отличает конкретный магазин: его сценариями, его интеграциями, его оформлением. Это и есть содержание фразы «команда под ключ»: не абстрактный доступ к специалистам, а поимённый состав, закреплённый за проектом на весь срок работ.

Как формируется бюджет в целом — в материалах «От чего зависит стоимость разработки» и «Бюджет и сроки: чек-лист», а расходы после запуска — в статье о стоимости поддержки приложения.

Десять вопросов, которые проверяют команду подрядчика

Состав, который показывают на переговорах, и состав, который выйдет на проект, совпадают не всегда. Проверяется это до подписания, десятью вопросами.

1. Кто конкретно будет в команде — имена и роли? Ответ «выделим специалистов нужного уровня» означает, что состав ещё не определён.
2. Эти люди закреплены за проектом или делят время между несколькими? Второй вариант допустим, но тогда стоит знать долю времени.
3. Кто мой единственный контакт по проекту? Если менеджера нет, его роль незаметно переходит к вам.
4. Кто отвечает за требования и в каком виде я их получу? Ответ должен быть документом, а не устной договорённостью.
5. Есть ли отдельный инженер по тестированию? Если проверяют разработчики, это стоит знать до начала, а не после первого выпуска.
6. Как оформляется изменение объёма? Работающий ответ — письменная оценка в часах до начала работ по новой задаче.
7. Что происходит, если специалист уходит? Спросите про замену, про передачу дел и про то, где хранятся знания о проекте.
8. Кому принадлежит исходный код и где он лежит? Доступ к репозиторию с первого дня — нормальная практика.
9. Что остаётся на моей стороне? Честный подрядчик назовёт четыре роли из раздела выше сам.
10. Что происходит с командой после запуска? Сопровождение, дежурство, срок реакции на сбой — это обсуждается до старта, а не в день публикации.

Отдельно стоит посмотреть на прошлые проекты подрядчика в вашей отрасли и на то, как он показывает результат: цифрами или общими словами. Практические ориентиры — в материалах «Где найти хорошего разработчика» и «Чек-лист заказа разработки». Насколько команда справляется с потоком задач, показывают и обычные рабочие показатели — их разбирает статья про 15 метрик разработки.

Кейсы: какие составы работали на реальных проектах

Три проекта, где состав команды был продиктован задачей, а не наоборот.

Ещё один срез даёт кейс Gulliver Family: через приложение проходит 80% мобильного трафика, и оно приносит 50% общего дохода ритейлера. Когда канал даёт половину выручки, вопрос «кто отвечает за сбой в субботу вечером» перестаёт быть техническим и становится вопросом состава команды и дежурства. Остальные проекты — в разделе кейсов. Как в целом устроен спрос в онлайн-ритейле, регулярно разбирает Data Insight.

Итог: команда разработки на одной странице

Короткая версия всего сказанного:

1. Считайте не людей, а закрытые зоны ответственности. Ролей девять, людей может быть пять или пятнадцать.
2. Шесть ролей — основа: менеджер, аналитик, дизайнер, клиентский и серверный разработчики, инженер по тестированию. DevOps, технический руководитель и специалист по сторам подключаются точечно.
3. Совмещать можно роли, которые не проверяют друг друга. Разработчик и тестировщик его же кода — не тот случай.
4. Четыре роли остаются у бизнеса всегда: владелец продукта, контент, доступы, приёмка. Их отсутствие двигает срок сильнее, чем скорость написания кода.
5. Формат выбирается по вопросу «кто отвечает за результат целиком». Штатная команда сильнее вдолгую, отдельные исполнители — на точечной задаче, аутстафф — при готовом процессе, команда под ключ — при запуске с нуля.
6. Проверяйте состав до подписания — поимённо, с ответом на вопрос о закреплении за проектом и о замене специалиста.
7. Договаривайтесь о том, что после запуска, в тот же момент, что и о разработке: сопровождение, дежурство, срок реакции.

Что делать дальше:

• Посчитать состав и порядок бюджета под свою задачу — калькулятор стоимости разработки; сравнить условия — тарифы.
• Зафиксировать объём до старта — разработка технического задания и бизнес-аналитика проекта.
• Понять состояние существующего продукта — аудит кода, аудит UX/UI или комплексный аудит интернет-магазина.
• Усилить свою команду отдельными специалистами — Flutter-разработчики, инженеры по тестированию, DevOps-инженеры; передать сопровождение — техническая поддержка приложений.
• Обсудить проект и получить состав под задачу — контакты.

Вопросы и ответы

Сколько человек нужно в команде для мобильного приложения интернет-магазина?

Для первого приложения обычно достаточно пяти: менеджер проекта, аналитик, дизайнер, клиентский разработчик и инженер по тестированию — при условии, что базовые функции каталога, корзины и оплаты берутся готовыми, а не пишутся с нуля. Магазину с интеграциями, программой лояльности и несколькими способами доставки нужно семь-восемь человек, сети с несколькими городами и заказами на юридические лица — десять и больше. При этом одновременно на проекте работают не все: аналитик и менеджер заняты почти всегда, разработчики — на своём отрезке.

Можно ли обойтись без бизнес-аналитика?

Формально да, и на маленьком проекте эту роль иногда закрывает менеджер или сам владелец продукта. Но работа никуда не исчезает: кто-то всё равно должен описать, что происходит с бонусами при возврате и какие поля обязательны при оформлении на юридическое лицо. Разница в том, где эти вопросы всплывут — в документе до начала работ или в переписке во время приёмки, когда изменение стоит дороже. По нашему опыту чем больше интеграций с учётными системами, тем раньше окупается отдельный аналитик.

Чем менеджер проекта отличается от владельца продукта?

Менеджер проекта отвечает за то, чтобы работы шли в срок и в бюджете, и находится на стороне исполнителя. Владелец продукта отвечает за то, что именно делается и зачем, и находится на стороне бизнеса. Менеджер спрашивает «успеваем ли», владелец продукта отвечает «что важнее, если не успеваем». Совмещать эти роли в одном человеке не стоит: тогда решение о сокращении объёма принимает тот, кто отвечает за срок, а это разные интересы.

Нужен ли отдельный инженер по тестированию, если проверяют разработчики?

Разработчики проверяют свой код и находят в нём часть ошибок — но проходят сценарий так, как задумывали, а не так, как ходит покупатель. Отдельный человек нужен ровно за этим взглядом со стороны, а ещё за тем, чтобы проверка перед выпуском была одинаковой каждый раз, а не «посмотрели, что успели». На небольшом проекте это может быть частичная загрузка одного специалиста, но роль должна быть закреплена за конкретным человеком, а не за всеми сразу.

Что значит «команда закреплена за проектом» и чем это отличается от аутстаффа?

Закреплённая команда — это поимённый состав, который работает над проектом весь срок и управляется менеджером на стороне подрядчика: он же отвечает за срок и результат целиком. Аутстафф устроен иначе: специалисты входят в вашу команду и работают под вашим управлением, ответственность за результат остаётся у вас. Первый вариант подходит, когда своей технической функции нет, второй — когда процесс выстроен и не хватает только рук. Стоит уточнять на переговорах, какой из двух вариантов вам предлагают: формулировка «выделим команду» одинаково подходит к обоим.

Сколько времени занимает сборка команды на проект?

Подбор шести специалистов в штат занимает несколько месяцев, отдельные исполнители находятся за дни, специалисты в вашу команду выходят обычно в течение одной-трёх недель. Команда подрядчика под ключ собирается быстрее всех, потому что состав уже существует и распределяется между проектами — при работе на нашей платформе интеграция под бренд укладывается в срок до 30 рабочих дней вместе с публикацией в магазинах приложений. Сравнение вариантов запуска — в материале о разработке приложения под ключ.

Что происходит с командой после запуска?

Состав уменьшается, но не исчезает. После публикации нужны реакция на сбои, обновления под новые версии операционных систем и требования магазинов приложений, доработки по обратной связи покупателей. Обычно остаётся дежурный разработчик, частичная загрузка инженера по тестированию и менеджер. В платформенной модели эта часть входит в ежемесячную лицензию: мониторинг, обновления модулей и обновления безопасности выполняет команда FITTIN, а новый функционал считается отдельно по часам.

Как понять, что над проектом работают именно те люди, которых показали на старте?

По трём признакам, которые видно уже в первый месяц. Первый — доступ к репозиторию и история изменений: там видно, кто и что писал. Второй — регулярные встречи, на которых говорят сами специалисты, а не только менеджер. Третий — оценка задач в часах до начала работ и отчёт по отработанным часам после. Если все три пункта на месте, состав проверяется без специальных усилий; если ни одного — это стоит обсудить до того, как проект дойдёт до середины.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.