Как разработать сервис онлайн-психотерапии в Англии и не поехать кукухой

Не остановиться на дизайне

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

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

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

Дашборд клиента в веб– и мобильном приложении

Неестественный отбор

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

• Профессиональное образование по специальности (уровень магистра или доктора наук);
• Опыт работы по специальности от 3 лет
• Индемнитет на сумму не менее £1,000,000 (страховка на профессиональное возмещение, залог);
• DBS-сертификат — аналог нашей справки об отсутствии судимости;
• Удостоверение личности с фотографией (ID).

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

• выставлять слоты для не менее 5 сеансов в неделю;
• поддерживать календарь актуальным;
• отвечать пациентам (на прием или отмену брони есть 6 часов).

Если врач отклоняет больше 5 заявок подряд, с ним связывается администрация сервиса. У нее есть право заблокировать аккаунт специалиста. 

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

Чат-бот с помощью наводящих вопросов помогает подобрать психотерапевта

Чем удивить

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

• Кастомные фичи: календарь, заметки, видеозвонки, чат. Почти все из этого можно было взять “снаружи” и интегрировать, но заказчику было важно разработать свое. Так мы и сделали.

Клиент может дать доступ к своим заметкам психотерапевту, если считает это необходимым

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

Свернув видео-звонок, клиент может записать что-то в заметках внутри приложения

С технической стороны мы взяли фреймворки и инструменты, проверенные десятками наших проектов:

• Фронтенд веб-сервиса — писали на Next.js (чтобы была возможность для индексации сайта в поисковиках);
• Бэкенд — на Nest.js + GraphQL;
• База данных — PostgreSQL;
• Мобильное приложение — React Native.

Делим по ролям

Мы разделили разработку на 14 спринтов:

1. Архитектура фронтенда и бэкенда.
2. Авторизация. Здесь для самой авторизации взяли Auth0 и SendGrid для отправки письма после регистрации. Auth0 мы обычно используем, если есть авторизация через соцсети (в нашем случае — для пациентов) и если нужно собрать авторизацию быстро. SendGrid взяли, потому что у него легкий API и удобные шаблоны писем. 
3. Онбординг.
4. Флоу поиска терапевта.
5. Создание графика работы терапевта.
6. Дашборд пациента.
7. Чат.
8. Видеочат.
9. Платежи. Начиная с этого спринта мы параллельно делали еще и мобильное приложение, поэтому в этот спринт вошли: архитектура мобильной версии, регистрация и онбординг.
10. Фидбек по сессии терапевта и управление доходами. Для мобильной версии: поиск и подбор терапевта.
11. Админ-панель и почтовые уведомления. Поиск и подбор терапевта для мобильной версии.
12. Интеграция страховок. Дашборд пациента и управление доходами терапевта в мобильной версии.
13. Предрелизная подготовка и фикс багов. Чат и видеочат для мобильной версии.
14. Настройка поведенческой аналитики. В мобильной: предрелизная подготовка, фикс багов и релиз.

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

Дашборд клиента показывает историю сеансов, заметки, хранилище материалов от психотерапевта, цели клиента и пройденные опросники

Терапевту доступно его расписание, чат, календарь, доход от работы и пациенты. Администратору — запросы на регистрацию, зарегистрированные терапевты и информация по пациентам (это требование HIPPA и GDPR.

Много возможностей — много экранов. И вот здесь мы немного обсчитались.

Всем экраны

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

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

Поскольку мы делали не MVP, а полноценный продукт, откладывать задачу не могли. Заказчику было важно выйти на высококонкурентный рынок сразу с готовым приложением, поэтому мы доработали и эту возможность. 

Не все гладко со страховками

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

Когда мы запросили у менеджера HealthCode описание API их сервиса, нас ждало разочарование. Документ, который нам прислали, был сумбурным набором устаревших описаний. Толку от него не было совсем. Тимлиду разработчиков пришлось в длительной переписке с техподдержкой Healthcode клещами доставать необходимые данные о работе API.

Все это усложнялось тем, что для API HealthCode использует устаревший формат ответов сервера на запросы — SOAP. Наше приложение (да и весь прогрессивный мир) работает с форматом JSON. Пришлось написать модуль, который трансформировал бы запросы от сервера в современный формат. На это ушло достаточно много времени. 

Протестировать работу API Healthcode мы смогли, только когда реальный клиент попробовал оплатить услугу страховкой. «Песочницу» для тестов API Healthcode тоже не предусматривает. Поэтому мы с замиранием сердца ждали первой оплаты от клиента и сильно обрадовались, когда она прошла успешно. Правда в Великобритании много страховых компаний, поэтому впоследствии бывало, что оплаты не проходили. Такие случаи мы разбирали case by case с техподдержкой Healthcode и добивались правильной работы интеграции.

Второй менеджер

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

Это приводило к конфликтным ситуациям: на старте мы договаривались о решениях, уходили их прорабатывать, возвращались показывать результаты. А на презентации заказчик просил сделать реализованное совсем иначе, хотя на старте принимал договоренности. Такие переделки — время и деньги, что не всегда очевидно для человека не из разработки. С его точки зрения «это легко» и «решается строчкой кода».

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

Поэтому в таких ситуациях мы не привыкли молчать. Я пригласила клиента на «исповедь». Мы 1,5 часа говорили друг с другом на чистоту, чтобы сделать взаимодействие приятным, прозрачным и комфортным для обеих сторон.  

Итогом переговоров стал такой экшн план. С нашей стороны:

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

Со своей стороны заказчик:

• Отказывается от микроменеджмента и отслеживает прогресс от спринта к спринту, участвует в дейли.
• Приоритезирует задачи на старте и не вкидывает срочные задачи в начатый спринт.
• Проявляет уважение к нашим оценкам на задачи. 

После взаимного принятия таких «правил игры» работа над проектом пошла гораздо более продуктивно. Если разногласия и возникали, мы быстро их решали благодаря фиксации договоренностей в переписке после созвонов.

Школа переговоров и программирования

Проект занял 8 000 часов. Мы выкатили сервис на прод в середине апреля 21 года. Один из партнеров привела в приложение первых пользователей из офлайна и сама проводит консультации. Недавно в сервисе появился новый терапевт (это происходит не быстро, потому что отбор тщательный). Сейчас на платформе работают 30 психотерапевтов, а зарегистрированных пользователей уже больше 1000.

Сейчас заказчик занимается маркетингом и продвижением приложения, а мы продолжаем работать с проектом на поддержке — доделываем задуманные фичи:

• Чат-бот, который помогает пользователю выбрать терапевта. Задает вопросы и на основании ответов предлагает специалиста.
• Пуш-уведомления с напоминаниями о записи или о сообщениях в чате с терапевтом. 

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

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

1. Фиксируйте договоренности текстом после каждого созвона. 
2. Не бойтесь чего-то не учесть. Все учесть невозможно, но с хорошей командой можно быстро внедрить недостающее.
3. Сторонние интеграции — это боль менеджера. Проговорите с заказчиком риски, можете даже позвать его с вами на звонок с представителями интегрируемого сервиса. 
4. Если чувствуете давление, поговорите с заказчиком открыто, объясните, что микроменеджмент не помогает. И постарайтесь сделать свою работу максимально прозрачной: давайте подробные ежедневные и спринтовые отчеты.