Как я сходил в больницу и пришлось создать стартап

Эмиль Гайнанов занимался обслуживанием компьютерной техники в Магнитогорске. Однако идея для стартапа у него «выросла» не из этого бизнеса. Рассказываем историю компании-разработчика медицинской информационной системы Medods, которая стала участником программы Yandex Cloud Boost.

История проекта началась в 2013 году. Как-то раз я подхватил простуду и решил поехать в частную клинику, чтобы сделать рентген легких. Поскольку клиника была в другой части города, то после процедуры, я спросил в регистратуре, не могли бы они отправить результаты мне на email и у нас состоялся примерно такой диалог.

Стоит ли говорить, что ни на следующий день, ни через день результатов я так и не получил. Пришлось с температурой ехать через весь город только для того, чтобы получить небольшой клочок бумаги, на котором написано «сердце и легкие в норме». У меня появилось ощущение, что в этой ситуации что-то не так и ее можно исправить. Тогда я и загорелся идеей сделать личный кабинет пациента, через который можно взаимодействовать с клиникой, например, записываться на прием или получать результаты исследований.

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

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

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

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

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

Итак, после года работы мы получили продукт с базовой функциональностью, который можно было пытаться продавать. Первая версия Medods выглядела довольно аскетично и была лишена множества необходимых функций. Хотя мы установили минимальную цену, продавать его было адски сложно. На большинство вопросов потенциальных покупателей в стиле «а есть ли в программе это или вот это?» звучал ответ «нет» или в лучшем случае «данный функционал в разработке» или «планируется в будущем».

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

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

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

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

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

Мы начали выбор сервиса и остановились на одном небезызвестном облачном провайдере Digital Ocean. Силами нашего талантливого DevOps-инженера мы совершили довольно сложный процесс миграции. Доступный нам функционал позволил закрыть практически все наши потребности. Заметно улучшилась управляемость и объем трудозатрат на обслуживания парка виртуальных машин. Однако было и то, что нас не вполне устраивало — сервис периодически падал без каких-либо предварительных уведомлений и на нас обрушивался шквал звонков от клиентов, которым мы не могли никак помочь, поскольку восстановление работы находилось вне нашей компетенции. Кроме того, нас не устраивала коммуникация, по сути, мы могли только писать тикеты на почту технической поддержки и получали ответ в лучшем случае через несколько часов, даже если ситуация была критической. Все это заставило нас задуматься о смене поставщика облачных услуг.

На тот момент Яндекс уже запустил свой облачный сервис. Лично я довольно лояльно отношусь к Яндексу как к компании в целом — мы решили попробовать переехать к ним. Дождались, когда у них будет доступен Kubernetes, и мигрировали в Яндекс.Облако.

Остановлюсь немного подробнее нам том, что мы используем и для каких целей. Итак, внутри Kubernetes у нас находится несколько сотен инстансов нашего приложения. Каждое приложение разделено на отдельные сервисы, отвечающие за выполнение различных задач, таких как, например: интеграция с кассовым и медицинским оборудованием, интеграции с лабораторными информационными системами, API, аутентификация пользователей и другие задачи. Обмен сообщениями между этими сервисами осуществляется с помощью брокера сообщений Apache Kafka, который на данный момент располагается на отдельной виртуальной машине в Yandex Compute Cloud. В ближайшее время мы планируем задействовать для этих целей Managed Service for Apache Kafka, а также перенести базы данных в Managed Service for PostgreSQL.

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

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

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

Важные мысли о том, на что нужно обращать внимание при развитии своего продукта:

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

Подписывайтесь на блог Яндекс.Облака, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Что сейчас активно читают наши подписчики:

#стартапы #бизнес #историиуспеха #machinelearning