Команда для разработки мобильного приложения: кто нужен на каждом этапе

Сначала распределите работу, а потом считайте людей

Начните с главного пользовательского пути. Что должен сделать человек: купить товар, записаться на услугу, начать урок или вызвать курьера? Для каждого шага кто-то должен определить правило, продумать интерфейс, реализовать его, проверить обычный и неудачный сценарии, а затем поддерживать работу.

В Scrum Guide небольшая кросс-функциональная команда описывается как группа, в которой есть навыки для создания полезного результата. Не обязательно строить проект строго по Scrum. Но принцип важен: приоритеты должен определять один ответственный за продукт, а команда должна уметь довести задачу до работающей версии.

В небольшом проекте один человек может закрывать несколько строк. Но сама работа никуда не исчезает.

Владелец продукта: человек, который держит цель

Это не обязательно отдельный сотрудник с должностью «продакт-менеджер». Им может быть основатель, руководитель направления или менеджер со стороны студии. Главное, чтобы у человека было право принимать решения.

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

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

Дизайнер: не украшает экраны, а собирает понятный сценарий

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

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

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

Разработчик мобильного приложения: работа на настоящем устройстве

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

Кроссплатформенный подход может уменьшить дублирование работы, если он подходит продукту. Но он не отменяет различия iOS и Android: подписки, глубокие ссылки, уведомления, работа в фоне и требования магазинов всё равно нужно проверять. В документации Flutter можно посмотреть техническую основу такого подхода, но выбор технологии должен следовать ограничениям продукта, а не рекламному обещанию.

Серверный разработчик и технический руководитель: невидимая часть продукта

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

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

В статье о серверной части мобильного приложения мы объясняем, почему функция не заканчивается на видимом экране. Если сотруднику нужно одобрить, изменить, вернуть деньги или проверить действие пользователя, админ-панель должна попасть в ту же смету.

Тестирование и публикация: обычного сценария недостаточно

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

Отдельно назначьте человека, который отвечает за аккаунты магазинов, скриншоты, тексты, сведения о конфиденциальности, аналитику и ответы на вопросы при проверке. Сверьтесь с правилами проверки приложений Apple и рекомендациями Android по базовому качеству приложения. Код может быть готов, а приложение ещё не готово к отправке в магазин.

Какой состав команды нужен для MVP?

У сфокусированной первой версии должны быть закрыты пять направлений: продукт, дизайн, мобильное приложение, сервер и качество с публикацией. Это может быть три человека, пять специалистов или команда студии, в которой отдельные специалисты подключаются на конкретном этапе. Важнее не число, а способность довести полный сценарий до запуска.

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

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

Какие роли можно объединить

В небольшом продукте основатель может вести приоритеты, опытный разработчик Flutter совмещать мобильную разработку и техническое руководство, а дизайнер готовить пользовательские потоки и набор компонентов. Серверный разработчик может самостоятельно вести простую инфраструктуру.

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

Перед наймом небольшой команды проверьте:

1. Назначен ли ответственный за каждое важное решение?
2. Есть ли у каждой роли пользователя полный сценарий, включая ошибки?
3. Может ли кто-то проверить результат независимо от автора?
4. Назначены ли владельцы доступов, инфраструктуры, аналитики, магазинов, поддержки и передачи проекта?
5. Понятно ли, что произойдёт, если ключевой специалист станет недоступен?

Как состав команды влияет на бюджет

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

Для реализованного продукта Appfyl использует такие ориентиры планирования: 1-1,5 млн рублей для сфокусированного MVP, 1,5-3,5 млн рублей для среднего проекта и 3,5-7 млн рублей для крупного проекта. Это ориентиры Appfyl, а не средние цены рынка. Итог зависит от цели, пользовательских потоков, админ-панели, интеграций, данных и требований к выпуску. В статье о бюджете мобильного приложения отдельно разобраны разработка, хостинг, внешние сервисы, поддержка и развитие.

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

Что спросить до подписания договора

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

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

Как Appfyl собирает команду

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

Подход Flutter-first подходит многим кроссплатформенным продуктам, но не является обязательным правилом. Технология, команда и проверки должны соответствовать продукту. Посмотрите публичные кейсы Appfyl, а затем опишите задачу в инструменте оценки приложения.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы