Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Сергей Никоненко, операционный директор в Purrweb, показывает особенности разработки приложения для зарубежного рынка, и зачем заказчикам SCRUM.
Гениальные идеи об IT-продуктах приходят в голову не только программистам. Иногда это бывают люди, максимально далекие от IT: кондитеры, флористы, ветеринары… Им приходится непросто: за разработку даже минимального жизнеспособного продукта (MVP) обычно просят немалые деньги, а процесс работы человеку без специальных знаний неочевиден. На этом и растут недобросовестные подрядчики — клиент же все равно ничего не понимает, сойдет и так.
Мы в Purrweb против такого подхода. Если клиент заинтересован в подробностях, мы готовы показывать и объяснять каждый этап работ над проектом прямо в «реальном времени». В этом нам помогает методология ведения проектов SCRUM — работа идет короткими итерациями, клиент получает регулярные отчеты, а в конце каждого спринта — демо-версию продукта. Это позволяет избежать множества проблем на этапе финального согласования.
К нам обратилась ветеринар — у нее своя маленькая клиника в Германии. Она общалась с нами через технического менеджера, но им обоим был важен именно SCRUM-подход, чтобы держать разработку под контролем.
Идея — мобильное приложение Petbuddy, в котором владельцы домашних животных смогут:
Все это имеет смысл в европейских странах, где развито чипирование домашних животных и регулярные визиты к ветеринару. Германия — как раз такая страна.
С помощью приложения клиентка хотела закрыть несколько целей:
Часто агентства придерживаются почасовой модели оплаты, и мы в том числе. Но наша клиентка с таким никогда не сталкивалась и ее беспокоило, что финальная стоимость работ не определена.
Чтобы и ее успокоить, и себя не обидеть, мы вывели конкретный срок на реализацию проекта — 3 месяца. По нашему опыту в разработке мобильных приложений, это оптимальный срок, за который можно сделать что-то осмысленное. После этого мы просчитали стоимость работы всех участников процесса (дизайнер, тимлид, два разработчика, менеджер проектов) в рамках 3-х месяцев и вывели стоимость проекта — 30 000$.
При этом мы понимали, что если брать в работу все «хотелки» заказчицы, количество работы может сильно увеличиться (по идее, за такой проект разумно брать все 50 000$), но бюджет и сроки растягивать уже нельзя.
Поэтому мы:
Технический менеджер Джесси, который представлял клиентку, пришел к нам с логотипом, палитрой и вайфреймами. Wireframe — это схема страницы или экрана, на ней расположены примерные блоки, которые заказчик хотел бы увидеть в финале.
Мы на это дело посмотрели и решили делать тестовый экран. Начали с одного из главных — профиля питомца.
Получился такой профиль:
Следующий этап стал переломным. Пришел фидбек, что нужно использовать изначальную палитру. Ну и, немного покряхтев, я изменила цвета с оранжевых оттенков на синие:
В результате победил темно-синий вариант, а оранжевые элементы стали больше тяготеть к желтому:
«С заказчицей мы общались не напрямую, поэтому основной процесс утверждения нас не коснулся. В целом им все нравилось, были правки только по логике расположения блоков и каким-то небольшим моментам вроде палитры».
Иногда заказчики сами не знают, какие экраны и функции нужно заложить в приложение. У них есть смутные идеи — мы их докручиваем, согласовываем и забираем в работу. В этом случае получился как раз такой кейс.
В приложении для владельцев домашних животных можно сделать акцент на ряде прикольных фич:
1. Контроль за весом питомца
2. Календарь важных встреч (когти подстричь, прививки и т.д.)
3. Калькулятор шоколада — он нужен, чтобы хозяин знал, не съел ли питомец смертельную дозу шоколада. Эту идею подала заказчица — она рассказала, что питомцы часто «подворовывают» шоколад и едят без спроса. А шоколад в больших дозах смертельно опасен для собак. Хозяева паникуют и бегут к врачу, хотя опасную дозу шоколада можно рассчитать самостоятельно исходя из веса питомца;
4. Объявление о пропаже — если питомец потерялся, можно сразу сообщить в специальную организацию и сохранить себе объявление в .pdf
5. Информация о ближайшей ветеринарной клинике
Каждое флоу (пользовательский сценарий) мы утверждали с Джесси, и он был как представитель стереотипов о немцах, очень скрупулезный. Поэтому в плане дизайна на этапе передачи в разработку ничего переделывать не пришлось. Но это скорее исключение — чаще всего невозможно сделать дизайн так, чтобы во время разработки не вылезли корректировки. Сейчас мы решаем это тем, что дизайнер после передачи дизайна в разработку все равно ходит с командой на ежедневные встречи и контролирует корректность реализации идей. Либо быстро вносит коррективы, если возникают технические ограничения.
Здесь мы создаем архитектуру фронта и бэка, рисуем диаграммы базы данных и переходим непосредственно к разработке и готовому приложению.
Не буду углубляться в технические подробности: пройдусь по особенностям, с которыми мы столкнулись именно в этом проекте.
Говоря о пушах: мы забыли учесть их в оценке проекта на этапе продажи, поэтому эта часть (а именно кастомные пуши) делалась за наш счет.
С калькуляторами подсчета калорий и шоколада тоже пришлось повозиться. Для них нужны формулы подсчета, а у клиента их не было. Поэтому пришлось «расковырять» существующие на рынке калькуляторы и вытащить логику работы из них. Иногда мы руками подбирали константы, чтобы все работало корректно.
Еще одна болевая точка — график веса питомца. У заказчика был миллион реквестов на этот счет. Проблема была в том, что графики (шкалы) нужно было адаптировать под веса разных животных. Например, Чихуахуа и Мастифа. У них совершенно разные весовые категории и вес колеблется тоже совершенно по-разному: у Чихуа — в пределах пары кило, а у Мастифа может достигать ста килограмм. Вот и нужно было шкалировать график так, чтобы он и то, и другое показывал. Вот мы и шкалировали 🙂
Есть довольно популярная методика описания проекта в виде User Stories. Так вот, концепция User Stories подразумевает под собой разбиение приложения на большие функциональные блоки (эпики, epics), а затем эпики бьются на более мелкие пользовательские истории (user stories).
Деливерить эпиками — это круто, так как можно закончить одну изолированную часть приложения и только потом приступить к следующей. Если делать много эпиков параллельно, то идет расфокус и как-то протестировать промежуточные результаты тяжело. В итоге приложение можно будет нормально протестировать только в конце всех работ, что слишком рискованно и чревато бесконечным количеством багов. В этом кейсе мы пришли к разработке эпиками только в конце проекта — мы не в первый раз практикуем SCRUM, но еще есть чему поучиться.
Так что финальная боль — куча мелких багов, то, от чего мы надеемся уйти, когда сразу начнем деливерить эпиками. Мы не закладывали день багфиксов в спринтах и к последним двум накопилось много мелких, но важных задачек. Пришлось взять немного больше времени на последний спринт, хотя предыдущие выполнялись без задержек.
Для MVP, который создавался как нишевый проект с амбициями, результат получился неплохой — 4,5 из 5 в App Store и 4 из 5 в Google Рlay. При этом мы видим, что на Android приложение установили больше 5 000 пользователей.
Заказчица успешно выполнила свою задачу. Финансовых метрик тут пока нет, сейчас она ищет инвестиции под следующий этап — монетизацию. А вот социальная функция, я считаю, выполнена на ура.
.webp)
