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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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