SCRUM, щеночки и 5 000+ скачиваний в Google Play: как мы делали немецкое приложение для владельцев домашних животных

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

Гениальные идеи об IT-продуктах приходят в голову не только программистам. Иногда это бывают люди, максимально далекие от IT: кондитеры, флористы, ветеринары… Им приходится непросто: за разработку даже минимального жизнеспособного продукта (MVP) обычно просят немалые деньги, а процесс работы человеку без специальных знаний неочевиден. На этом и растут недобросовестные подрядчики — клиент же все равно ничего не понимает, сойдет и так.

Мы в Purrweb против такого подхода. Если клиент заинтересован в подробностях, мы готовы показывать и объяснять каждый этап работ над проектом прямо в «реальном времени». В этом нам помогает методология ведения проектов SCRUM — работа идет короткими итерациями, клиент получает регулярные отчеты, а в конце каждого спринта — демо-версию продукта. Это позволяет избежать множества проблем на этапе финального согласования.

Трекер здоровья домашнего питомца — стартап для немецкого рынка

К нам обратилась ветеринар — у нее своя маленькая клиника в Германии. Она общалась с нами через технического менеджера, но им обоим был важен именно SCRUM-подход, чтобы держать разработку под контролем.

Идея — мобильное приложение Petbuddy, в котором владельцы домашних животных смогут:

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

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

С помощью приложения клиентка хотела закрыть несколько целей:

1. Дать владельцам животных возможность следить за показателями здоровья своих питомцев. Это больше гуманитарная цель
2. Привлечь в приложение своих текущих клиентов и увеличить количество повторных визитов (а значит LTV)

Ограничиваем бюджет

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

Чтобы и ее успокоить, и себя не обидеть, мы вывели конкретный срок на реализацию проекта — 3 месяца. По нашему опыту в разработке мобильных приложений, это оптимальный срок, за который можно сделать что-то осмысленное. После этого мы просчитали стоимость работы всех участников процесса (дизайнер, тимлид, два разработчика, менеджер проектов) в рамках 3-х месяцев и вывели стоимость проекта — 30 000$.

При этом мы понимали, что если брать в работу все «хотелки» заказчицы, количество работы может сильно увеличиться (по идее, за такой проект разумно брать все 50 000$), но бюджет и сроки растягивать уже нельзя.

Поэтому мы:

1. Выписали все хотелки, которые у нее были
2. Приоритезировали
3. Убрали то, что не влезло в 3 месяца и 30 тысяч
4. И только потом приступили к дизайну и разработке

Шаг первый — дизайн

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

Мы на это дело посмотрели и решили делать тестовый экран. Начали с одного из главных — профиля питомца.

Получился такой профиль:

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

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

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

Какие еще экраны можно использовать в таком приложении?

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

В приложении для владельцев домашних животных можно сделать акцент на ряде прикольных фич:

• контроль за весом питомца

• календарь важных встреч (когти подстричь, прививки и т.д.)

• калькулятор шоколада — он нужен, чтобы хозяин знал, не съел ли питомец смертельную дозу шоколада. Эту идею подала заказчица — она рассказала, что питомцы часто «подворовывают» шоколад и едят без спроса. А шоколад в больших дозах смертельно опасен для собак. Хозяева паникуют и бегут к врачу, хотя опасную дозу шоколада можно рассчитать самостоятельно исходя из веса питомца;

• объявление о пропаже — если питомец потерялся, можно сразу сообщить в специальную организацию и сохранить себе объявление в .pdf

• и, конечно, информация о ближайшей ветеринарной клинике

Каждое флоу (пользовательский сценарий) мы утверждали с Джесси, и он был как представитель стереотипов о немцах, очень скрупулезный. Поэтому в плане дизайна на этапе передачи в разработку ничего переделывать не пришлось. Но это скорее исключение — чаще всего невозможно сделать дизайн так, чтобы во время разработки не вылезли корректировки. Сейчас мы решаем это тем, что дизайнер после передачи дизайна в разработку все равно ходит с командой на ежедневные встречи и контролирует корректность реализации идей. Либо быстро вносит коррективы, если возникают технические ограничения.

Шаг второй — разработка

Здесь мы создаем архитектуру фронта и бэка, рисуем диаграммы базы данных и переходим непосредственно к разработке и готовому приложению.

Не буду углубляться в технические подробности: пройдусь по особенностям, с которыми мы столкнулись именно в этом проекте.

1. Мы делали дизайн приложения на английском, но на стадии разработки заложили архитектуру под мультиязычность. Отдали технарю на стороне заказчика файл со всеми текстами, которые нужно перевести. Они вернули нам перевод, мы внедрили. Разработка дизайна под язык, на котором ты не говоришь и не пишешь, это рядовая задача. Только вспомните эти длинные немецкие слова!
2. В какой-то момент Apple запретил доступ к App Store Connect (это специальный сервис для публикации приложений в App Store) без включенной двухфакторной авторизации. Поскольку мы находимся в России, а заказчица — в Германии, нам приходилось синхронизироваться с ней по времени через технического менеджера, чтобы получить код для входа.
   Это в принципе большое неудобство — запрашивать код у человека, который находится вне офиса: он наверняка занят делами, а вы тормозите свою работу, потому что не можете продолжать без кода. В нашем случае все усложнилось тем, что была разница во времени, а к заказчице вообще не было прямого доступа — то есть код мы запрашивали через менеджера, который тоже не бывает на связи 24/7.
3. Помучались  с авторизацией через Facebook, так как делали через AWS Cognito, а раньше с ней дела не имели. Конечно, можно было сделать авторизацию напрямую через Facebook API или использовать другие сервисы, с которыми мы уже знакомы. Но мы с менеджером заказчицы решили жить максимально в рамках сервисов AWS. Amazon обеспечивал нас сервером, облачной базой данных, файловым хранилищем, а тут еще и возможность авторизацию прикрутить — круто же?
4. Главная наша боль оказалась в калькуляторах, графике веса и пушах.

Говоря о пушах: мы забыли учесть их в оценке проекта на этапе продажи, поэтому эта часть (а именно кастомные пуши) делалась за наш счет.

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

Еще одна болевая точка — график веса питомца. У заказчика был миллион реквестов на этот счет. Проблема была в том, что графики (шкалы) нужно было адаптировать под веса разных животных. Например, Чихуахуа и Мастифа. У них совершенно разные весовые категории и вес колеблется тоже совершенно по-разному: у Чихуа — в пределах пары кило, а у Мастифа может достигать ста килограмм. Вот и нужно было шкалировать график так, чтобы он и то, и другое показывал. Вот мы и шкалировали 🙂

А что там со SCRUM?

Есть довольно популярная методика описания проекта в виде User Stories. Так вот, концепция User Stories подразумевает под собой разбиение приложения на большие функциональные блоки (эпики, epics), а затем эпики бьются на более мелкие пользовательские истории (user stories).

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

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

Результат

Для MVP, который создавался как нишевый проект с амбициями, результат получился неплохой — 4,5 из 5 в App Store и 4 из 5 в Google Рlay. При этом мы видим, что на Android приложение установили больше 5 000 пользователей.

Заказчица успешно выполнила свою задачу. Финансовых метрик тут пока нет, сейчас она ищет инвестиции под следующий этап — монетизацию. А вот социальная функция, я считаю, выполнена на ура.