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

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

Менеджер проекта или продукта

Связующее звено между заказчиком и командой. Планирует работу, следит за сроками и приоритетами, проводит демонстрации, решает, что делать при изменении требований. Именно с ним заказчик общается чаще всего. Без этой роли разработчики отвлекаются на согласования, а заказчик не понимает статус.

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

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

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

Проектирует, как пользователь проходит сценарии, и рисует интерфейс. Создаёт прототип, дизайн-систему, все состояния экранов, готовит макеты для разработчиков. Хороший дизайнер мобильных приложений знает правила iOS и Android.

Мобильные разработчики

Варианты состава:

• Нативная разработка — отдельные специалисты для iOS (Swift) и Android (Kotlin)
• Кроссплатформенная — разработчики Flutter или React Native, которые делают обе платформы, при необходимости с нативными доработками

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

Бэкенд-разработчик

Создаёт серверную часть: API, базу данных, бизнес-логику, интеграции с учётными системами и платёжными сервисами, уведомления, админку. Часто именно серверная часть составляет большую долю работы, хотя заказчик её не видит.

Frontend-разработчик

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

Тестировщик

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

DevOps-инженер

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

Какие роли можно совмещать

1. Менеджер и аналитик — на небольших и средних проектах
2. Бэкенд и DevOps — при простой инфраструктуре
3. Бэкенд и разработка админки — при стандартных функциях управления

Совмещать мобильную разработку и тестирование того же кода не стоит.

Как работает команда

Чаще всего работа идёт короткими итерациями — спринтами по одной-две недели:

• В начале спринта команда выбирает задачи из списка приоритетов
• Каждый день короткая синхронизация внутри команды
• В конце спринта демонстрация заказчику работающих функций
• Обсуждение, что улучшить в процессе

Заказчик видит прогресс регулярно и может поменять приоритеты до того, как работа сделана не так.

Что важно заказчику

• Знать, кто конкретно работает над проектом и какая у них загрузка
• Иметь доступ к трекеру задач и репозиторию
• Присутствовать на демонстрациях
• Иметь одного контактного человека со своей стороны

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