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

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

<i>Команда Medods</i>
Команда Medods

Началось все с простуды

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

  • Мне обязательно приезжать за результатом в клинику? Не могли бы вы отправить результат мне на электронную почту?
  • Эм... Я не знаю, наверное, нет...
  • Странно, а почему?
  • Подождите, сейчас я выясню... Лена, мы можем отправить результат рентгена на электронную почту? Ну вообще у нас нужно приезжать лично. Ну ладно, напишите вашу почту вот здесь.
  • Хорошо, вот мой адрес, я буду ждать.

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

<i>Команда Medods</i>
Команда Medods

Пользовательский опыт во главе угла

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

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

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

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

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

В начале мы часто говорили покупателям «нет»

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

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

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

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

Первые вызовы и немножко удачи

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

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

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

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

<i>Команда Medods</i>
Команда 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 и бизнесе.

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

2626
24 комментария

Наш стартап также получился из-за проблем с медициной. 
Это не стеб. 
Моя мама болела диабетом лет так 20. К сожалению, ситуация проходила мимо моего осознания проблемы. Пила таблетки, колола  инсулин, сахар, давление... Но однажды ночью я услышал, как она тихо плакала у себя в комнате. Вытянул на разговор, она показала почерневшие пальцы на ногах и объяснила, что это начинается "сухая гангрена". Дальше отрежут, потом стопы, и т. д. Так часто заканчивается диабет. Мировая медицина бессильна. Я попробовал свой способ (было увлечение аминокислотами/ пептидами) хоть как то ей помочь. Сначала ушла диабетическая подошва. Потом почернение ног. Потом стал уменьшаться сахар. Мама вместо двух инъекций в день стала делать одну. Сахар уменьшился, стал 9-10 ммоль/л. Она перестала делать инъекции инсулина. Сахар продолжал падать, стал 5,3-4,3  ммоль/л. Это за период 2003-2010 гг. Причем три из них были уже без инъекций. 
По сарафанному радио приходили и другие кейсы, примерно с десяток. За 2004 по 2016 гг сделаны различные анализы по способу, в том числе и!!! - доклинические. Сегодня я пытаюсь с небольшой командой сделать стартап, найти деньги на клинические испытания (по факту я уже давно их делаю), и на сертификацию метода. Но, к сожалению, сегодняшние инвесторы, избалованные халявными смарт АйТи технологиями, вааа ще не понимают, на что я прошу деньги. Это просто трындец, тупизм инвестклимакса. На программы распознавания лиц в метро у ДПиИР Москвы деньги есть, а на реальную проблему здоровья - нет. 
При этом в мире - 400 млн. больных диабетом. И скорость приращения больных больше, чем прирост народонаселения. Сто лет кололи  инсулин, сейчас можно доработать и применить методику, но деньги есть только у толстолобиков. Частные инвесторы, млять... 

6
Ответить

Комментарий недоступен

3
Ответить

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

5
Ответить

Комментарий недоступен

2
Ответить

Ребята с 2013-го так живут и их, очевидно, всё устраивает 😏

Зачем вдруг подрываться и что-то менять? 🤔

1
Ответить
5
Ответить

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

1
Ответить