НаПоправку.ру — как мы за 5 месяцев сделали приложение с функционалом сайта, который создавали 5 лет

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

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

В конце 2019, планируя активно начать привлечение платного трафика, мы всерьез подошли к вопросу повышения возвратности и лояльности пользователей. И приложение могло бы стать потенциальным решением этой проблемы. CustDev показал, что лояльные пользователи НаПоправку чаще бы обращались к сервису, будь у них приложение, которое не дало бы им забыть о нас за то время, пока у них нет потребности во враче. Также это совпало с привлечением инвестиций от фонда VNV Global. Вопрос ресурсов был решен.

1. Делаем полнофункциональное приложение, дублируем весь функционал сайта (на самом деле, делаем даже больше фишек, чем на сайте). Мы думали о наших лояльных пользователях. Зачем им усеченный функционал в приложении? Это неудобно и скорее разочаровывает. Вся затея могла провалиться.

2. Срок — работающее приложение к сентябрю 2020. Он определялся как управленческая цель. Мы хотели выпустить приложение 1 июля, чтобы до сентября (сезон высокого спроса в сфере медицины) стабилизировать продукт, настроить платный маркетинг и к концу года накопить данные по окупаемости.

3. Делаем приложение нативным и привлекаем студию. Создание приложения своими силами заняло бы слишком много времени. В команде агентства над проектом работало до 8 разработчиков одновременно. Для нас не было ни смысла, ни времени искать их в штат - для развития и поддержки не нужна такая большая команда. Решили — это тот самый случай, когда аутсорс оправдан.

4. Сами делаем только API, все остальное — отдаем на откуп агентству. У нас было укрупненное ТЗ, в которое включили требование по выбору языков (Swift для iOS и Kotlin для Android). Дизайн, архитектуру, тестирование — должно было взять на себя агентство.

С этим мы вышли после январских праздников и занялись выбором партнёра.

• уложиться в бюджет;

• успеть в сроки (релиз к 1 июля);

• качественные работы в личных портфолио членов предлагаемой нам команды (дизайнер, проджект-менеджер);
• достойное место в рейтинге студий (Рейтинг Рунета, Tagline, Ruward, Clutch);
  
• позитивный фидбек от компаний-заказчиков (мы действительно звонили им и уточняли рекомендации. Конечно, согласовав это со студией);
  
• готовность интегрировать в работу наших разработчиков, когда мы их найдем. Для них был свой скоуп задач, не из ТЗ агентства.
  

1. Long list на основе рейтингов и портфолио. Попали 16 компаний.

2. Коммерческие предложения мы получили от 12 из них.

   Смотрели на смету и график работ. Одни не готовы были подписаться под сроком в 4,5 месяца. Другие — показывали уровень детализации на уровне итоговой стоимости проекта и вилки по продолжительности работ — было понятно, что при такой проработке вероятность не попасть в сроки и деньги стремится к 100%.

3. Личные и онлайн встречи.

   Мы знакомились непосредственно с менеджером проекта и дизайнером, смотрели их портфолио. На этот этап не прошли те, кто в ответ на наш запрос, просто прислал письмо со сметой и стоимостью, не задав нам ни одного вопроса. Была удивлена, что кто-то рассчитывает продать проект на 17 млн.руб., ограничившись коммерческим предложением в тексте емейла, ни разу не поговорив! И даже если смета была внятной, мы интуитивно не готовы были по такой крупной сделке принимать решения заочно. Далее не прошли и те, кто переборщил с деталями и «въедался в печенки» по каждой фиче — переговоры не должны заменить первый этап работы над проектом.

4. Запрос рекомендаций по реализованным проектам.

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

5. Финалистов было двое. Как мы выбрали? Стало понятно, что вторая компания для нас слишком фундаментальна, нацелена на работу с большими и структурированными бизнесами, а нам нужен гибкий предпринимательский подход: скорость, готовность подстроиться, услышать и вписаться в твои сроки и требования. Выбранное агентство подкупило нас интересом к самому проекту и нашему бизнесу. Они практически единственные, кто спрашивал: «А зачем вам приложение в принципе?». Остальных интересовали сугубо прикладные вещи: какие версии ОС будем поддерживать, какая будет авторизация…

Из интересного: разброс ценовых предложений от 12 компаний за один и тот же скоуп работ был от 2,5 млн. до 25 млн.руб.

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

• Гибкость и маневренность: возникали ситуации, когда нас нужно было подстраховать и забрать в разработку какие-то функции, которых не было ни в каком ТЗ и забрать сейчас, а не через три месяца.

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

• Были готовы работать с «рыбным API». Многими агентствами разработка приложения параллельно с работой заказчика над АПИ воспринималась как крайне рискованная затея и они сразу снимали с себя любые обязательства по срокам и пытались убедить нас — либо прийти к ним с уже готовым АПИ, либо передать эту часть работы им. Хотя никакой проблемы в этом не было. Наших партнеров полностью устроила предложенная механика. В реальности мы не столкнулись с проблемами АПИ, и оно нисколько не затормозило релиз приложения.
• Фокус на срок. Сроки были крайне важны. И агентство нас услышало. Был выстроен отличный проджект-менеджмент. В какой-то момент я поняла, что они переживают за дедлайн даже больше, чем я и смогла полностью «отпустить» этот процесс из-под своего контроля.

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

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

Запись к врачу и на услугу — это самый сложный функционал сайта и приложения и он отличается от схемы «тонкий клиент», когда нужно просто сходить в АПИ, получить данные и вывести — никакой хитрой логики.

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

В изначальном ТЗ были диплинки, но для студии это тоже оказалась непростая задачка. Они оказались в тупике. Тогда наш СТО просто сам стал погружаться в вопрос — рисовал схемы, разбирался как трансформировать URL в код для iOS и Android, понял что делать этого не нужно, а нужно в АПИ на бекенде написать сервис, который будет разбирать эти урлы, конвертировать их в экраны и конкретные параметры, возвращать обратно в приложение.

• Такие сложные и эксклюзивные штуки, как пуши и диплинки нестандартны для студии. Это делают продвинутые приложения инхаус. С эксклюзивом могут быть заморочки, особенно когда ни одна из участвующих сторон не в теме.

• Наши фейлы — это обратная сторона плюсов от взаимодействия. Отпускать агентство в свободное плавание даже с хорошим проектным менеджером — опасно!

  Контроль и обсуждение новых задач — обязательно нужны.

• Доказали, что «рыбное API» — это 100% рабочая схема.

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

Наше приложение вышло 31 июля, что на две недели позже срока, рассчитанного студией в самом начале переговоров. Итого: сайт, которому 5 лет, мы воплотили в приложении за 5 месяцев! Прожили опыт «заказной разработки», порадовались тому, что она может делаться на принципах партнерства, и в целом очень довольны своим выбором. Сейчас приложение полностью в руках наших внутренних разработчиков, и мы продолжаем работу над ним. Впереди очень много новых задумок и функций.