Во втором выпуске — Максим Мизотин, CTO и сооснователь Collectly. На этот раз мы сконцентрировались исключительно на текстовом формате интервью и поговорили с Максимом о специфике рынка мед. услуг США и развитии его проекта.

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

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

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

С 2010 года, после запуска Obamacare, количество счетов, которые выставляют здесь за различные мед. услуги, растет год от года, поэтому сейчас вопрос собираемости стоит наиболее остро. Быстро принимать оплату от клиентов с минимальными издержками хотели бы все, но решений на рынке практически нет. Этим мы и занимаемся: строим продукт, объединяющий в себе платежную систему, биллинг и систему менеджмента процесса со стороны клиники.

Какие у вас были предпосылки для работы в этой нише? Почему B2B-проект?

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

Как вы подступились к решению проблемы потенциальных клиентов? Какие ошибки допустили на первых этапах реализации проекта?

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

Перебирали разные отрасли, но наиболее перспективными нам казались банки. Они выдают кредиты, и у них большое количество просроченных выплат. Однако от этого направления нам пришлось отказаться по ряду причин. Но в итоге перестроили продукт под сферу здравоохранения. Решение приняли, когда узнали, сколько инвойсов выставляют доктора и клиники в США.

Как вы взаимодействуете с ними? Пришлось ли кастомизировать решение под каждый кейс или оно универсально и встраивается в любой бизнес-процесс? Нужно ли клиникам что-то менять на своей стороне для работы с Collectly?

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

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

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

Поговорим о конкурентах — как выглядят продукты в вашей нише? Чем ваш отличается от них в том числе с технологической точки зрения?

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

Какой технологический стек вы используете? Менялся ли он в ходе разработки?

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

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

Как менялся состав команды? Как в целом вы взаимодействуете с ИТ-специалистами Какие методологии вы используете для управления разработкой? Стартапы должны работать быстро, оперативно развивать продукт — расскажите, как у вас построен процесс запуска в продакшн?

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

Стоит сказать, если продукт получается действительно новым, а не очередным uber-клоном или пародией на фейсбук, то почти все задачи, которые будут вставать перед разработчиками, являются нестандартными. Если сравнивать рабочий процесс с жизнью команды условной веб-студии, то новый продукт, конечно же, поменяет привычки людей, будь то просмотр котиков или медицинский биллинг. Поэтому ключевой навык для разработчика в продуктовом стартапе — это умение быстро обучаться на практике и работать с новыми вызовами.

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

Пока мы используем scrum с максимально короткими спринтами по неделе. DevOps организован так, чтобы разработчики релизили код сами, как только он проходит необходимые этапы (тесты, ревизии кода, QA и так далее).

Сегодня вы обслуживаете более 300 клиник и обрабатываете 150 тыс. платежей в день. Как вы справляетесь с ростом нагрузки на ИТ-инфраструктуру?

Мы довольно давно внедрили Kubernetes и CI/CD. Они решают проблему горизонтального масштабирования, и разработчики не тратят время на релизы.

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

Он будет искать лучших инженеров, ориентированных на глобальный рынок. Нам нужен подход к работе с ориентацией на результат, высокий уровень ответственности и мотивации к профессиональному росту. Так сложилось, что на глобальном рынке труда вы соревнуетесь уже не с лучшими из России, а с лучшими из лучших. Но у разработчиков из России есть преимущество — здесь всё еще сохранилась хорошая техническая школа. Однако, как я говорил ранее, только технической подготовки недостаточно, soft skills на высоком уровне не менее важны, чем hard skills.

Какие у вас планы по развитию проекта? Что можете сказать о перспективах формирования русскоязычного блока из ИТ-специалистов?

Планируем выйти на IPO через 3–4 года. В ближайшее время расширим команду до 15 инженеров. Но к размещению на бирже это число точно превысит сотню.

Другие мои B2B-интервью, материалы по контент-маркетингу и не только:

• Новый B2B-подкаст: как работает аутсорсинг бухгалтерии

• Почему контент-маркетинг в ИТ — это испытание на выносливость

• Что нужно знать технологическим компаниям, запускающим блог

• Зачем нужны простые привычки: пример с прогулкой

• Картинг в СССР — о появлении такого DIY-хобби