Как мы за 2,5 месяца пересобрали готовое приложение и внедрили проектный менеджмент

Настроить менеджмент и поделиться экспертизой

Разработка этого мобильного приложения задумывалась как “точка входа” для родителей, которым нужны товары и услуги для детей, а искать подходящее среди разбросанной по интернету информации времени нет. Главная фича приложения — поиск организаций, которые предоставляют услуги для детей: от аттракционов с батутами до детских садов и спортивных секций. 

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

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

Смелое планирование

Мы начали обсуждать разработку мобильного приложения в конце августа. В этом проекте нам предстояло:

• посмотреть на код;
• исправить критичные косяки;
• вместе с разработчиками проекта доделать недостающие фичи; 
• подготовить приложение к полноценному релизу. 

Заказчик планировал зарелизить все к 15 сентября, но после ревью кода сроки оказались нереальными. Мы обозначили, что реалистичная дата релиза — 15 ноября: нужно было доделать уже живущие в приложении фичи, переделать кривые и сделать новые. Заказчик планировал “взлететь” с приложением в новогодние праздники: 10 дней в квартире с детьми — тяжелое мероприятие, которое точно нужно разбавлять батутами и другими развлечениями. 

Разработка мобильного приложения складывалась для нас в пять пунктов:

1. Код-ревью.
2. Оценка новой версии приложения.
3. Планирование работ и внедрение проектного менеджмента.
4. Разработка вместе с командой заказчика и обучение разработчика заказчика.
5. Передача приложения на поддержку заказчику. 

С нашей стороны в команду вошли проектный менеджер и фулстек-разработчик, а позже добавился фронтендер, со стороны заказчика — дизайнер, фронтендер и бэкендер. 

Непривычный стек и работа на всех фронтах

Фронт приложения написан на React Native, бэк — на Laravel. React Native для нас привычен, поэтому решили работать с тем, что есть. С Laravel пришлось повозиться: фреймворк PHP, а мы с PHP не работали последние четыре года. Нужно было справляться силами бэкендера заказчика — подключать к задачам и курировать его работу. 

Настраиваем менеджмент

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

Фронтендер команды заказчика:

“Раньше задачи решали самостоятельно, над планом и приоритетными задачами не думали. С появлением проектного менеджера появилось представление, что мы делаем и куда идем. Задачи стали решать быстрее.”

Для планирования скоупа внедрили скрам и двухнедельные спринты. В октябре перешли на недельные спринты, потому что заказчик планировал обновляться каждую пятницу. Мы заложили схему: 3 дня работаем над фичами, два дня  ̶з̶а̶л̶е̶ч̶и̶в̶а̶е̶м̶ ̶р̶а̶н̶ы̶ фиксим баги — старые и новые. Мы не только писали код, но и параллельно обучали ребят, чтобы после нашего ухода настроенные процессы продолжили работать. 

Урезаем скоуп

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

Так, в наш релиз не вошла связь в приложении с компанией-организатором: родитель может подобрать релевантные мероприятия и услуги, а вот связаться с организатором в самом приложении через чат пока не может. Не вошли в скоуп онлайн-оплата в приложении, подборка “вместе с этим смотрят” и внутренний блог со stories. 

Разбираемся в дизайне

Оказалось, код — не самое хаотичное и некорректное в проекте. Когда мы начали разбираться с дизайном проекта, поняли, что:

1. Это 657 слайдов в одной папке с названиями “Слайд 1”, “Слайд 2”. 
2. Скрины в архиве не связаны друг с другом. Грубо говоря, это просто папки с картинками.

Архив с родительскими сценариями — это 600 скринов неупорядоченных действий в сервисе, архив с организаторскими сценариями — это 400 аналогичных хаотичных скринов. Каждый раз, когда нам нужно было что-то поправить, мы выискивали конкретные скрины, отправляли их дизайнеру и ждали исправлений. 

Пытаемся работать с бэкэндером заказчика и разбираем код

Исходный код был плохим: кое-что работало с багами, кое-что не работало совсем. Существование готовой версии приложения нам никак не помогало, только мешало. 

Мы столкнулись с жуткими проблемами с неймингом: функция “функция” и “функция 1” или переменные “mad” и “bus” абсолютно ни о чем не говорят человеку, который с этим кодом работает не с начала. Правда, как показала практика, они ни о чем не сказали и человеку, который эти переменные придумал. Для кода в 1000 строк это проблема — его невозможно прочитать.

Когда мы начали работать, наш фронтендер и фронтендер заказчика быстро синхронизировались и работали сообща. С бэкендером было сложнее: он не всегда укладывался в сроки, и мы не могли валидировать его код, потому что он писал на Laravel/PHP. Нам приходилось доверять бэкендеру, если он говорил, что где-то проблемы — проверить это мы не могли. 

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

Одно из пожеланий заказчика — чередование в поисковой выдаче онлайн и офлайн-мероприятий. Но в списках сортировка стояла по геопозиции в связке с локацией пользователя. А у онлайн-мероприятия такого показателя нет. На бэке это сделать сложно, на фронте выглядит криво: есть 20 онлайн-мероприятий и два офлайн-события. Как сортировать и отображать? Нам удалось убедить заказчика, что это нежизнеспособное решение. Тогда мы сделали две отдельные табы под разные события. 

Мы столкнулись с проблемами в фильтрации. Одним из фильтров на третьем уровне были “категории”: вместо выбора, например, размера и цвета, покупатель на третьем уровне снова выбирал обувь это, аксессуары или одежда. Мы обнаружили этот баг вовремя и исправили.

Починить и отпустить

Проект занял 2,5 месяца фуллтайм работы и обошелся в ₽1 млн (мы работали на почасовой основе). Если бы мы отрефакторили код на старте, смогли сэкономить время, но заказчица была уверена, что это надолго. Код отрефакторен частично и работает почти как надо. 

Проектный менеджмент и планирование настроены — мы помогли команде перестроиться и поработали с ними в новом формате.

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

Команда планирует доделать:

• связь с организаторами мероприятий внутри приложения; 
• запись на прием; 
• пуши;
• онлайн-оплату;
• подборку “вместе с этим смотрят”. 

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

Комментарий заказчика проекта:

«Это был нестандартный проект, потому что Purrweb вели его не с начала. Я хочу отметить команду в плане проектного менеджмента: мы легко зашли, подключились к работе. Мы собрали билд и переработали процесс работы — это большой плюс. Дэйли каждый день добавили проекту прозрачности.»