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

Я поговорила с экспертом в области разработки приложений на 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-разработчиков может быть более качественным, джунов в перспективе можно вырастить в крутых специалистов.

3 комментария

Ruslan Bakeyev

24.01.2022

"Если же ресурсов на такую команду нет, то наймите только тимлида и джуниоров."

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

- У вас будет уходить огромное количество времени на code review. Во многом потому что начинающих разработчик может не понимать архитектуру всего решения и следственно реализовывать определенную функциональность в слоях не предназначенных для этого. Или, например, писать простые вещи очень сложно и запутанно.
- Если вы рассматриваете джуна как инвестицию в будущее, то всегда имейте ввиду, что вы, будучи стартапом, не сможете предложить ему зарплату выше, чем это смогут сделать корпораты. Велика вероятность, что разработчик уйдет от вас при виде суммы даже на 20%-30% больше своей текущей. У более опытных разработчиков, как правило, финансовая ситуация уже чуть более комфортная, как и понимание того, что есть работа в корпоратах.
- Вы, как ведущий разработчик, ответственны за рост навыков джуниоров, и у вас будет уходить много времени (которого у вас точно нет работая над MVP) на развитие навыков.
- Работа в стартапах над MVP - это всегда гонка со временем и много задач, которые могут идти в разрез с вашими навыками или специализацией. Некоторые начинающие программисты могут быть не готовы к такому давлению и темпу психологически. Как следствие - снижение мотивации, ухудшение атмосферы в команде, и, возможно, даже потеря сотрудника.

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

Ответить