Интервью: как стартапу разработать мобильное приложение и избежать ошибок

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

На первом этапе необходимо провести тщательный анализ рынка и понять:

• Какие продукты существуют в выбранной нише;
• Почему «залетели» одни продукты, а другие прогорели;
• Изучить продукты конкурентов, их преимущества и недостатки;
• Какую особенность продукта может предложить ваш стартап, которой нет у конкурентов.

Правильное ТЗ должно включать полное описание функциональности продукта. В ТЗ входит выбор платформы (iOS, Android, Web, Desktop) и приоритизация фич на основе анализа конкурентов. Это один из самых важных этапов, так как на его базе создаются функциональные и нефункциональные требования, а также закладывается общая архитектура продукта. Затем на основе требований и архитектуры будет формироваться команда.

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

Если же бюджет ограничен (что, к сожалению, свойственно стартапам), придется прибегнуть к услугам фрилансеров. Однако в этом случае может пострадать качество, так как скилы фрилансеров не всегда отвечают желаемым требованиям.

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

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

Тут же начинаем создание UX/UI дизайна.

В первую очередь важно определить, по какой методологии будет происходить разработка — Scrum или Kanban.

• Scrum — это двухнедельные спринты, результатом которых должны стать либо окончание разработки фичи, либо выпуск релиза.

• Kanban подразумевает итерационный выпуск релизов без привязки ко времени и дедлайнам.

Роман считает, что стартапу лучше использовать метод Scrum, чтобы видеть конкретные результаты с периодичностью в 2 недели.

• На начальном этапе разработки крайне важно определить, какую систему контроля версий (или стратегию «бранчевания») вы выберете: в каких ветках будут работать разработчики, в каких ветках будут первые релизы. Это необходимо, чтобы потом не запутаться, что будет загружаться в продакшн в первую очередь, а что — позже, если разработчики параллельно делают какие-то фичи.

• После того как разработчик заканчивает создание фичи, код попадает на тестирование в отдел QA (Quality Assurance). Если проверка прошла успешно, то дальше выполненный функционал отправляется в релиз и ждет выпуска (если вы выбрали Scrum). Если используется Kanban, то фича будет релизиться сразу.

Если на этапе тестирования возникают проблемы, отдел QA дает фидбек разработчику, задача ему возвращается, он ее фиксит и снова отправляет тестировать код.

• Мягкий запуск продукта. Продукт лучше выпускать на ограниченное количество пользователей (например, бета-версию в App Store или Google Play Store), чтобы как можно быстрее получить фидбек от реальных пользователей. На этом этапе нужно исправлять баги, краши, собирать отзывы и узнавать, что нравится пользователям, а что нет.

• Далее вы дорабатываете MVP по приоритету выбранных фичей, которые вы составили ранее.

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

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

Совет: сразу определитесь с методологией разработки (Scrum или Kanban). Чем быстрее выпускаем релизы, тем быстрее получаем фидбек от пользователя и дорабатываем продукт.

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

Совет: постройте поэтапную работу и собирайте фидбек на каждом этапе разработки:

• Проверка кода на тестах;
• Фидбек от QA;
• Выпускаем бета-версию, получаем фидбек от бета-тестировщиков;
• Выливаем в продакшн, получаем фидбек от всех пользователей, в том числе Crashlytics и отзывы в App Store и Google Play Store.

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

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