Прикладные истории: как найти своего разработчика, погрузиться в код и сделать своё приложение
Продолжаем серию полезных текстов о том, как мы выпустили новое приложение буше. В прошлый раз говорили про подготовку к обновлению, а сегодня с головой погружаемся в процесс. Сколько времени потребовалось на разработку, как найти тех, кто напишет код и какие в этом всём могут быть подводные камни — в новой главе «прикладных историй».
Разработчик, ау
Когда мы точно поняли, что хотим меняться в лучшую сторону, встал вопрос — кто нам тут всё поменяет? Как рассказывает Ксения Михайлова, руководитель отдела развития бизнеса буше, рисерч начался с банального рейтинга рунета: кто что делает, на кого обратить внимание.
Прошлое приложение было написано на кросс-платформенном языке, а в новом хотелось бы этого избежать. То есть нужно было писать код с нуля, и ещё под две операционные системы. В итоге под наш запрос попали и откликнулись три команды. Всем им дали одинаковое ТЗ и стали ждать, какой драфт ребята смогут по нему сделать.
— И вот две компании сделали плюс-минус одно и то же. Немного скучно: доставка, ничего такого. А KOTELOV, разработчик, с которым мы начали работать, они прям накрутили, навертели. Провели аналитику рынка, предложили кучу разных фич. Такой подход, который меняет бизнес, — делится Ксения.
В итоге после долго поиска в ноябре 2022 года началась работа. Если разбивать по этапам, то выглядит это так:
- Сначала согласовывали дизайн всех экранов будущего приложения. Занимались этим весь декабрь;
- В январе появился код и первые тестовые сборки — стали тыкаться, тестировать, править;
- 88 сборок спустя, поняли, что всё готово!
Докручивать и допиливать можно до бесконечности, а нам в какой-то момент уже не терпелось сделать релиз. Поэтому, когда поняли, что весь функционал старого приложения работает, а основные новые фичи — тоже, решили, что пора обновляться. Сейчас версия приложения больше, чем MVP, а новый большое драфт наработок уже в работе.
буше одно, приложения два
Как сделать приложение с новыми разработчиками, но не потерять старую аудиторию? Сложный вопрос. Мы, например, изначально решили, что будем делать не просто обновление, а целый апп с нуля. Чтобы гостям не пришлось самостоятельно скачивать что-то, а просто дождаться автообновления. На бумаге — очень удобный вариант, однако в этом нашлись свои подводные камни.
Вот простой сценарий: пользователь установил старое приложение сто лет назад (условно!), тут ему прилетает апдейт с новым приложением. Он заходит — всё красиво. Только надо заново авторизовываться. И вот тут случаются подводные камни: забыл телефон, забыл почту, забыл всё. И это не вина пользователя (безусловно), это наш промах.
Поэтому уже после релиза у нас были ежедневные расследования о том, какой, у кого и когда аккаунт был привязан. Так что если будете делать что-то новое, не забудьте плотно связать его со старым! А вот ещё несколько практичных советов о разработке на собственном опыте:
- На более поздних этапах к тестировке можно подключить «человека со стороны». Так, у нас это был один из управляющих. Он впервые увидел приложение и свежим взглядом оценил, что ему удобно, а что — нет;
- Как говорит Ксения, «надо думать о пользователе». При чём не просто строить теории о том, что ему понравится, а проводить аналитику и подтверждать свои гипотезы. Но нельзя забывать и о привычках юзеров: конечно, многие по началу будут говорить, что раньше было лучше — это естественно. Поэтому опираться полностью тут тоже проигрышная стратегия. Найти баланс между тем, что гипотетически хочет пользователь и тем, что ему действительно нужно — сложная, но решимая задача;
- Не стоит бояться голого макета в начале разработки — все ещё успеет наполниться и даже, возможно, поменяться.
Этот текст про то, как мы разрабатывали своё приложение. В следующей части расскажем о том, как рассказать всему миру об обновлении, что делать чтобы перетянуть пользователей и при чём тут хакатон.