От идеи до нового продукта. Или как мотивировать разработчика

Этой весной международная IT-компания VRP Consulting опубликовала на AppExchange новое приложение — PatientX. Решение представляет собой бесплатную платформу, которая упрощает взаимодействие медицинских учреждений с их пациентами.

Этот релиз стал логическим завершением конкурса Lightning Challenge Bolt-2019. Расскажем, с чего все начиналось и что то ждет продукт в будущем.

Осенью прошлого года в VRP Consulting прошел внутренний конкурс Lightning Challenge Bolt, участникам которого предлагалось придумать идею приложения и презентовать ее.

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

С этой идеей Сергей попал не только в десятку финалистов, но и стал победителем конкурса.

Через неделю после финала над приложением начала работать команда из 4 разработчиков, дизайнера и бизнес-аналитика.

Спустя три месяца PatientX было опубликовано на AppExchange.

Как оно работает и какие новые возможности появятся в следующем релизе? Об этом и другом мы поговорили с автором идеи — Сергеем Козаком.

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

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

В свою очередь в календаре врача появляется новая запись, он также видит по дням запланированные приемы и свою степень загрузки.

Как происходит общение? Сейчас переписка выглядит, как в стена в Вконтакте или Facebook. Есть какая-то запись — запланированный прием, под которой находятся комментарии — вопросы пациента и ответы врача. Эту переписку видят только они. Мы решили, что такой формат будет удобнее, потому что каждый вопрос связан с конкретным случаем (приемом) и не теряется в общем чате.

Мы с командой ещё раз посмотрели мою презентацию и от чего-то отказались (например, от страховок), что-то улучшили, что-то добавили. У нас есть идеи, как усовершенствовать пакет.

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

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

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

Платформа лежит на Community Cloud, мы работали с Aura-компонентами и таким стандартным Salesforce-функционалом, как Event Calendar и CMS Collection. В дальнейшем будем подключать другие календари.

Для видеосвязи мы используем технологию WebRTC (видеосвязь через окно браузера) и разместили сам функционал на Visualforce-страничке — это связано с техническими особенностями.

Мы решили сделать дизайн нейтральным и минималистичным, выбрав за основу белый цвет с синими элементами. Кастомизировать проще на белом холсте, чем на ярких и сложных цветовых сочетаниях. Цветовая гамма в Community настраивается быстро и легко благодаря Design Tokens: в Community Builder вы задаете основные цвета, а стандартные и кастомные компоненты наследуют заданные цвета кнопок, фона, шрифта, ссылок и размеры шрифта.

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

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

Перед публикацией приложения на AppExchange нужно обязательно пройти проверку на Security review.

Как мы готовились? Сначала проверили свой код здесь, используя бесплатную версию с установленным лимитом. Мы несколько раз проверяли, исправляли и думали, что этого будет достаточно. Затем отправили пакет на AppExchange Security Review.

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

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

После первой проверки (а мы к тому времени добавили некоторые фиксы) можно было размещать продукт на AppExchange. Дело в том, что при небольшом проценте изменений кода разрешается публикация приложения без повторного AppExchange Security Review.

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

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

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

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