Родился в 1981 в городе Улан-Удэ, республика Бурятия.

Всегда любил слушать и пересказывать. Ещё до того, как научился читать, наизусть рассказывал объемные стихи: сказка о царе Салтане (Пушкин), 4 глава Василия Теркина (Твардовский) и др. Затем, когда научился читать, запоем читал в основном художественную литературу.

Во время учебы, сначала в гимназии №33 Улан-Удэ, затем в Улан-Удэнском Колледже Железнодорожного Транспорта, затем в Иркутском Государственном Университете Путей Сообщения, очень интересовался всем, что связано с компьютерами. Будучи студентом увлеченно изучал технологии корпоративных сетей и сети Интернет. Когда появлялась возможность, подрабатывал системным администратором офисных сетей. Всегда искал возможности поэкспериментировать с серверной операционной системой FreeBSD. Также интересовался разработкой web-приложений.

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

Мой путь в IT-проектах начался в 2002 году, когда через ICQ я случайно нашел своего наставника - Андрей Шетухин (stellar). На мой вопрос “Почему ты помогаешь мне?” он ответил - “Мы всегда должны помогать начинающим”.

IT-специализация

Сначала это были сугубо IT-административные роли, всегда связанные с корпоративными локальными сетями (иногда связанными с необходимостью настраивать крайне сложное и дорогое оборудование Cisco), доступом сотрудников в Интернет и сервисами Интернет на базе FreeBSD (электронная почта на своём домене, web-сервер, файлообменник и т.д.). Чаще всего работа сама находила меня в виде full-time предложений и отдельных заказов. Иногда приходилось разрабатывать небольшие программы для обработки данных. В это время появился мой первый авторский IT-проект (sparrow) с открытым исходным кодом, который стал набирать популярность среди руководителей и системных администраторов организаций республики для раздачи и контроля доступа сотрудников в Интернет.

В 2003-2004 годах я работал в сервисном центре Комтек - крупнейшего компьютерного магазина в республике Бурятия. Занимался там сборкой и ремонтом компьютеров. За год собрал около тысячи компьютеров. С интересом изучал архитектуру x86 на ассортименте магазина, складской учет в 1С. Персонал магазина постоянно обращался ко мне за консультациями по подбору нестандартных конфигураций ПК и за помощью в поиске недостачи во время регулярной инвентаризации. А также по сарафанке приходили запросы и заказы по настройке sparrow и других сервисов Интернет на базе FreeBSD.

С 2005 года я занимался разработкой и поддержкой телематики в первом ISP республики Бурятия - ОАО “АК Мобилтелеком”. Участвовал во многих IT-проектах, в том числе для правительства республики. Например, хостинг электронной почты, полностью интегрированный в биллинг ISP с собственным удобным Webmail-приложением (которое оказалось проще разработать с нуля, чем интегрировать готовое). Сервера электронной почты доставляли в сутки в среднем тысячу писем, эффективно вычищая около 20 тыс спам-сообщений с помощью комбинированной системы фильтров, включая нейронную сеть на движке Bayes (dspam). Это позволило в том числе добавить в список услуг компании внешний анти-спам фильтр для клиентов, у которых свой хостинг электронной почты.

Что касается своих авторских IT-проектов, Sparrow обрел удобный web-интерфейс для руководителей по управлению доступом. Появились и другие IT-проекты с открытым исходным кодом (HotSpot-сервер, сервер интернет-радио). Но всё таки почти всё время уходило на IT-проекты компании, большинство из которых было так или иначе связано с интеграцией телематики в биллинг ISP. Так были успешно интегрированы web-хостинг, хостинг доменных имен, сеансовый доступ в Интернет (обслуживающий несколько тысяч абонентов одновременно), облачный диск для компьютеров с ОС Windows. Но были и самостоятельные IT-проекты: сервис зеркалирования портала правительства, система мониторинга потребления ресурсов ЖКХ, и др. При увольнении в 2012 был отмечен личным поощрением руководства (см. в отзывах).

С 2012 года доля разработки в общем объеме моей работы резко увеличилась. Моя роль в проектных командах была чаще backend, реже web-fullstack разработка. Так я разработал web-оснастку для тестирования и анализа производительности NexentaOS на разных конфигурациях “железа”, модуль сопряжения web-интерфейса продажи авиабилетов с системой дистрибьютора Amadeus, сервис рассылки email-сообщений с высоким уровнем прохождения спам-фильтров, небольшую CMS для простого сайта политической организации, и др.

Знакомство и общение с опытными разработчиками сильно изменило и мои методы и применяемые технологии. Так я переключился с ОС FreeBSD на более подходящую для разработки связку Debian/Ubuntu + CentOS. Вместо mercurial начал применять git. Высокая нагрузка и web-fullstack заставили сначала перейти с cgi/fast_cgi perl на PSGI/Plack, а затем и сменить язык - так я изучил и начал применять nodeJS с автоматическим тестированием.

Переход в менеджмент IT-проектов

В 2014 году появилась возможность взять на себя роль тимлида в команде разработчиков учебного центра Константина Довлатова. За 1.5 года мы разработали и внедрили LMS в учебный процесс. Я делал один из ключевых компонентов системы - сервис видеосвязи для участников курса (замена проблемного skype). В команде было 6 человек, включая меня, которые работали с самого начала полностью удаленно друг от друга.

Интересно, что основная ценность моей работы оказалась не в разработке, а в управлении. Причем не только в управлении командой, но и в управлении требованиями. На определенном этапе разработки UX-макетов, один из заказчиков (администратор школы) в ответ на мой вопрос “Что ещё нужно проработать?” ответил “Ничего. Я уже поскорее хочу начать этим пользоваться”. Проектный менеджер, Виталий Козлов (см. отзывы), оценил мою роль в этом процессе больше похожей на Product Owner, чем тимлид. И если до этого мой наставник по разработке, Андрей Шетухин, передал мне в высшей степени скептическое отношение к Agile-подходам, то здесь у меня возник некоторый интерес.

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

Я начал копать и изучать всё про Agile, чтобы найти ответы на эти вопросы. Глубину Agile я почувствовал после просмотра роликов про Scrum от Collab.NET (например, этот). Откуда взялся этот человек в пиджаке с галстуком? Откуда он знает существующий пользовательский опыт в таких подробностях? Откуда у него столько времени и денег на разработку? Одно я понял для себя - наличие такого человека в команде разработчиков очень сильно снижает риск, что результат будет бесполезен. У меня возникла идея, что взяв на себя эту роль, я смогу стать ближе к фабрике IT-продуктов, и поэтому я начал поиск соответствующих вакансий.

Agile

Поиски привели меня к Илье Павличенко на тренинг PSPO. Сказать, что я многое понял, значит ничего не сказать. Стало очевидным, что без погружения в такие темы, как ценностное предложение, бизнес-модель, возврат инвестиций, маркетинг, продажи, удержание (retention), customer development, и другие продуктовые и даже бизнесовые темы я не смогу разобраться в том, как делать действительно полезное программное обеспечение. Я успешно сдал экзамен и получил сертификат PSPOI (см. мой профиль на scrum.org) и это в том числе помогло найти работу в роли PO в компании MST. Решал технический бэкграунд, опыт работы в управлении разработкой и наличие сертификата.

Компания смогла выйти на рынок автоматизации торговли FMCG с продуктом для мобильных торговых команд и их менеджмента. Но была огромная проблема с разработкой: результат хронически не совпадает с ожиданиями владельца бизнеса, сильно завышенные и постоянно увеличивающиеся сроки поставки, хронический срыв этих сроков, множество критичных дефектов (которые не исправляются месяцами), очень сильная зависимость бизнеса от конкретных людей в команде, “сломанный телефон” и конфликты в команде (когда разработчики не могут договориться, хотя сидят рядом друг с другом). Вместе со всем этим запрос от владельца - хочу Agile. И в качестве решения, предложенного ему внешним Agile-коучем - открытие вакансии владельца продукта (PO).

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

Владелец нарисовал следующую картину будущего для компании и меня лично. Дословно он сказал: “Я хочу чтобы ты запускал проекты, набирал под них команды и затем контролировал все эти процессы”. Он хотел компанию с миллиардной капитализацией. Этот вижн на все 100 соответствовал фабрике IT-продуктов, которую я хотел ещё в самом начале своего трудового пути.

Но роль PO никак не давалась. Мне удавалось решать процессные вещи, а продуктовые (на которые я изначально пришел), так и оставались для меня неуправляемыми. Однако, владельцу бизнеса явно стало сильно легче. Он сфокусировался на продажах и выручка вместе с клиентской базой выросла в несколько раз. Под сильно возросшие ожидания клиентской базы команда разработки также выросла, и в пике достигала 17-ти человек. Коммуникации в продуктовой группе, а также между разработкой и бизнесом (маркетинг, продажи, саппорт, аккаунтинг), благодаря переформатированию команд стали проще и эффективнее.

Получается, что бизнесу помогает не Scrum-фреймворк, а лично я своими ручными и системными усилиями по наведению порядка. Осознав это, я мягко перевел процесс разработки на Kanban-метод и это позволило перевести решение проблем с результатами и сроками с ручного режима на системную основу. Jira была заменена на более подходящий для этого Kaiten. Время поставки сократилось в разы, количество дефектов вместе со временем их исправления также сильно снизились. Некоторые детали этого перехода изложены в одном из моих вебинаров (см. запись).

Для Scrum-фреймворка в MST также нашлось применение. Компания регулярно проигрывала тендеры из-за отсутствия функционала с предзаказами для торговых представителей. А основная команда разработки была сильно перегружена ожиданиями от клиентской базы. Мы собрали команду из 5 человек, в которую из существующей перешли только двое разработчиков - остальные были наняты с рынка и имели лишь небольшой опыт. Для обратной связи подключили людей из бизнеса (маркетинг, продажи, саппорт, аккаунтинг), и за несколько месяцев был получен отличный результат.

Затем этот подход повторялся не раз под конкретную бизнес-задачу. В результате, к концу 2019 года я неплохо разобрался в Scrum-фреймворке, особенно в продуктовой его части. Подтверждением этого является не только опыт, но и сертификаты PSMI, PSPOI, PSPOII и PSPOIII (см. мой профиль на scrum.org). Мне стало понятно, откуда берется владелец продукта для разработки в уже существующей компании. Это человек, который смог получить бюджет на решение какой-то бизнесовой задачи, решение которой требует привлечения разработчиков. И владельцу продукта не всегда нужен Scrum-фреймворк, иногда достаточно Kanban-метода.

Бизнес и предпринимательство

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

Поэтому владелец бизнеса хотел иметь универсальный продукт, который либо сразу попадает в эти ожидания, либо его можно доработать с предсказуемыми результатом и сроками (тот самый запрос на Agile). В результате, когда росла выручка, рос и бэклог и сложность продукта, росла и команда разработчиков, и соответственно росли расходы. Но поскольку клиенты платили не за разработку, а за подписку на продукт (как результат доработки), расходы росли сильнее, чем выручка. Неоднократно было так, что даже после добавления ожидаемого функционала в продукт, клиенты так и не воспользовались им (не говоря уже об оплате). Получается, что клиенты делают свои проекты и эксперименты за счет MST. И значит главная проблема у нас не в разработке, а где-то в бизнесе.

Решать её мы пошли в акселератор ФРИИ. Результат не получили, но получили много уроков про управление бизнесом в IT. И снова, сказать, что я многое понял, значит ничего не сказать. Я и раньше очень четко для себя понял, что разработчики не создают продукт, они его автоматизируют (продукт != продакшн). Но тут я узнал, что к моменту привлечения разработчиков продукт уже должен быть на рынке, хотя бы в виде холостых продаж. Отсюда и владелец продукта в стартапе - один из тех 2-3 человек, которые выводили продукт на рынок.

Кроме этого, я понял роль венчурных инвестиций, без которых не сделать успешный ISV. Ещё один судьбоносный инсайт для меня был в том, что услуги трекера предпринимателей в акселераторе очень сильно резонируют у меня с услугами Scrum Master-а для владельца продукта в стартапе (см. ролики раз, два и три). Это побудило меня пойти учиться в Академию Трекеров (см. сертификат), и в целом фокус моего профессионального развития сместился в сторону бизнеса. Я захотел досконально разобраться в том, как надо создавать или менять бизнес, чтобы IT-продукт был максимально ценным, а бизнес на нем - максимально эффективным.

После акселератора в начале 2020 года владелец MST резко поменял своё отношение к будущему компании. Та картина, которая была у него в 2016 году, рассыпалась. И он сказал мне, что вероятно мы больше не пойдем туда никогда. Вместе с инсайтом про трекера это всё побудило меня уйти в свободное плавание, чтобы набрать как можно больше опыта про создание и вывод продукта на рынок.

Я работал с внутренним предпринимательством ещё с 2016 года. В MST мы пробовали запускать разработку продуктов на рынки страхования, HR, краудинвестинга, edtech и др. Но эта работа была всегда на втором месте после разработки основного продукта компании MST. Сейчас же эта работа стала приоритетом №1. В результате, за 2 с небольшим года я поучаствовал в нескольких стартапах, параллельно зарабатывая деньги на консультациях и бизнес-трекинге. Ни один из стартапов не полетел, но опыт я получил, о чем и расскажу далее.

ПКСН “КОПИКУПИ”

Строго говоря, КОПИКУПИ - это не стартап, и даже не бизнес. Это кооператив. Но у него также есть бизнесовые составляющие: продвижение, консультации и сбор взносов в обмен на пользу для пайшиков. Ребята позвали меня к ним наладить процессы продвижения и консультирования (по сути, маркетинга и продаж). Они были убеждены, что с продуктом и его полезностью всё хорошо, и надо что-то делать с рекламой и воронкой. И это было очевидно - воронка в bitrix24 представляла из себя огромное бессвязное количество карточек на около 20-ти колонках. До начала накопления доходили только те, кто пришел по сарафану, а остальные задавали кучу вопросов и даже не открывали программу.

Когда мы начали выстраивать воронку продаж в bitrix24, то не смогли найти точку перехода лида в сделку. Это момент открытия программы? Или первый взнос в неё? Или момент выдачи займа на покупку? В поисках ответа на этот вопросы мы получили первый инсайт. Текущее позиционирование “кредит под 0%” приводит не тех лидов. Они приходят взять займ, а им приходится делать противоположное - начинать откладывать и накапливать. Мы поменяли позиционирование на “копилки на жилье и автомобиль с ускорением покупки” и выстроили воронку.

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

Разбирая механику доставки ценности, мы и раньше сталкивались с непредсказуемым выходом на займ. Но сейчас это стало главным ограничением. И мы никак не могли преодолеть его. Любая фиксация этого момента во времени или в деньгах немедленно создавала слабо управляемые финансовые риски для всей системы. Мы ушли в финансовое моделирование системы и увидели там некоторый пирамидальный эффект - прямую зависимость выдачи займа от притока новых клиентов. Однако, за счет того, что система замкнута на себя (средства не выводятся во-вне) и административные расходы очень низкие, последствия этого эффекта существенно ниже, чем в других внешне похожих системах (ЖК BestWay Coop, и др.).

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

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

CapitalSharing Auto

Суть проекта - коллективные инвестиции в доходные автомобили. Целевая аудитория - непрофессиональные инвесторы, которые хотят инвестировать часть своего дохода от трудовой деятельности. Они не могут позволить себе купить автомобиль, но накапливать на автомобиль тоже не хотят по причине инфляции и потери времени. В CSA (сокр. название проекта) они могут купить дольку от доходного автомобиля начиная от 10 тыс руб и выше за один раз и начать получать доход почти сразу же (на след день).

Я взял на себя всю техническую часть, обслуживание после продажи и частично маркетинг - разгрузил CEO по части SMM. Маркетинг и продажи делали партнеры. Мы подключили к проекту одну из управляющих компаний в Калининграде и эксперта по запуску доходных автомобилей. За 4 месяца успешно собрали около 2х млн руб, запустили на линию два доходных автомобиля.

Клиенты-инвесторы после продажи работали полностью со мной и тем MVP, который я сделал в google spreadsheets. Они видели там все свои взносы с прогнозом по возврату согласно своего тарифа, а также сам тариф с условиями. CEO, который занимался продажами, видел сводную таблицу по всем клиентам - кто сколько внес, когда, и т.д.

Через два месяца после запуска рост замедлился - мы уперлись в размер базы самих основателей. Мы ожидали, что сарафана хватит, чтобы выйти на ТБУ. Но его не хватило. Пока мы искали каналы привлечения, у нас кончились деньги и мы закрыли проект. Автомобили продали, инвестиции клиентам вернули.

Topto

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

Но позже в процессе общения с потенциальным партнером из Кыргызстана пришла идея попробовать менее развитые рынки СНГ, в частности Кыргызстан. Там очень высокая ставка кредитования (острая проблема) и небольшой рынок, на котором будет легче начать. В результате мы с ним основали компанию заново с продуктом взаимного кредитования на покупку жилья на рынке Кыргызстана. “Топто” на кыргызском языке означает “вместе”. У нас был пример КОПИКУПИ и знание о том, как сделать лучше. И ещё ярким свидетельством того, что мы сделали правильный выбор, было не меньше десятка разных финансовых пирамид, которые успешно функционировали на территории КР (Кыргызская Республика) - это значит, что проблема очень серьезная.

Мы начали изучать рынок. На самом деле на рынке уже были похожие продукты от трёх местных банков, а также жилищно-сберегательная кредитная госпрограмма. Наш продукт отличался гибкостью - клиенту не надо было накопить 50% от стоимости, чтобы получить займ без подтверждения дохода. Чем больше он накопит, тем меньше переплата. Период накопления может быть всего 3-5 месяцев (первоначальный взнос + существенная разница по ежемесячному платежу до и после покупки).

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

В финансовой модели мы воспроизводили тысячи рандомных копилок, чтобы максимально снизить риск и найти оптимальную модель. Копилок было сначала 5 тысяч, потом 10, 20 и 30 - больше google spreadsheet не смог переварить. В общей сложности мы сделали около ста разных наборов/моделей, выявили оптимальные параметры и создали калькулятор депозитно-кредитного продукта: клиент вносит предполагаемую цену жилья, свой ежемесячный платеж и получает срок покупки. Либо наоборот, можно было задать цену жилья и срок покупки, и калькулятор выдает ежемесячный платеж. Были также вариации с разными ежемесячными взносами до и после покупки (для тех, кто хочет переехать со съемного жилья в своё). Хорошая экономика выходила на взносах в районе 13-15% годовых, что было чуть ниже ипотечных ставок на рынке.

С таким продуктом мы пошли в рынок. Подняли чуть менее миллиона рублей ангельских инвестиций и начали экспериментировать. Сделали небольшой лэндинг и стали поливать его трафиком из instagram. Цена лида оказалась просто смешной - менее 25 руб. В лидов мы делали холостые продажи с целью проверить ценностное предложение. Из почти ста интервью мы получили 5 лидов, готовых внести деньги и начать копить. Таким образом мы достаточно хорошо проверили рынок. Профиль ЦА оказался следующим: семейные люди с детьми и серой/черной зарплатой, которые уже прошлись по банкам и получили отказы.

Ограничение сместилось в сторону продукта. Нам с одной стороны нужны средства, чтобы компенсировать ожидаемый дисбаланс по срокам накопления и возврата. С другой стороны нам уже сразу нужен инфраструктурный партнер, без которого мы не можем предоставить финансовые услуги (депозит и кредит), так как требования к такой форме организации слишком жесткие (с нуля создавать не вариант).

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

Smile.IT

Проект был запущен ещё в 2021 году как CRM-система для стоматологий. Идея была в том, чтобы привнести в сферу стоматологий передовой опыт маркетинга, продаж и обслуживания с помощью IT-продукта. Основатель провел несколько десятков интервью с владельцами небольших стоматологических клиник, и выявил острую проблему, за которую они готовы платить - администратор клиники. Это наемный человек, который не разбирается в стоматологических услугах, но тем не менее он является по сути лицом клиники. От администратора зависит почти вся воронка продаж и весь сервис вокруг лечения.

В начале 2022 года, когда я присоединился к проекту, его идея состояла в том, чтобы через разработку чат-бота для популярных мессенджеров и соцсетей снизить зависимость стоматологических клиник от администратора. Пусть он занимается чаем-кофе и записью в расписание, а всю остальную коммуникацию возьмет на себя чат-бот. При необходимости чат-бот переключит диалог на доктора (для сложных случаев), а когда клиент будет готов записаться - переключит на администратора. И поскольку владелец уже нашел клинику, готовую к эксперименту, мы сразу же приступили к разработке чат-бота, чтобы посмотреть, как будет работать такая коммуникационная система.

Я взял на себя продукт (внедрение, поддеркжа, разработка), а партнер - маркетинг и продажи. Мы посмотрели разные готовые решения для чат-центров и чат-ботов, в конечном итоге остановились на AmoCRM. В Amo есть всё, что нам было нужно: и чат-центр, и воронка, и sale-bot. Когда в скрипт sale-bot была добавлена, если не ошибаюсь, 120-ая карточка, с клиникой связались из AmoCRM и спросили что за интересный проект у них? Сейчас я понимаю, что это глупость. Но мы, испугавшись что у нас украдут идею, быстро перенесли данные и отказались от AmoCRM в пользу полностью своего решения на NodeJS. Это не выглядело сложно, и чтобы проверить идею мы могли начать с любого из мессенджеров. Мы начали с Telegram.

Около 2х месяцев у меня ушло на то, чтобы разработать чат-бота в Telegram. Причем 80% времени ушло не на код, а на тексты для бота. Оказалось, что в клиниках нет такого понятия, как проблема и решение. У них есть диагноз, прогноз и услуга. Нам пришлось, ни много ни мало, привнести продуктовый подход в их достаточно консервативную сферу. В процессе разработки мы осознали, что гораздо проще, дешевле и быстрее можно проверить коммуникацию с клиентами вручную в мессенджерах и соцсетях клиники. Импульсивно принятое решение стоило нам 2 месяца времени, но лучше поздно чем никогда.

Мы приняли решение сесть в воронку вручную. Я сам физически находясь в клинике, консультировал клиентов в чатах, при необходимости подключая докторов, и когда пациент был готов, записывал его в расписание через администратора. Тексты для чат-бота, которые мы написали вместе с руководством клиники, очень сильно помогли мне в консультациях. В результате за 1.5 месяца я проконсультировал около 70-ти лидов. Мы получили конверсию чуть больше 20% в консультацию в кресле и интересные инсайты.

Чат-бота в Telegram мы всё равно доделали и выпустили в свет, но уже не рассматривали его как продукт. Скорее как интересную игрушку (он до сих пор работает). Руководство клиники его не купили, потому что он реализован только для Telegram (нужно было делать ещё WhatsApp и Instagram Direct) и далеко не все клиенты хотят коммуницировать в чате, многие хотят разговаривать по телефону (нужно делать суфлера - версию чат-бота для администратора). Но самое главное заключается в том, что чат-бот находится в самом начале воронки. А чтобы повлиять на выручку через первичных пациентов, нужно приложить в разы больше усилий, чем через вторичных. Получается, что мы начали не с того конца воронки.

Понимая теперь основную ценность администратора в клинике, мы начали искать другую клинику, где есть соответствующая проблема. Как я теперь понимаю, это была ещё одна ошибка - нужно было искать те клиники, у которых проблема в начале воронки (наша разработка им может подойти) и пробовать упаковывать продукт в них. Есть вероятность, что мы бы не нашли. Однако, есть вероятность, что нашли бы. Но мы нашли другую клинику с проблемой в конце воронки и там уже начали работать на возврат и удержание клиентской базы. На это ушло ещё 1.5-2 месяца экспериментов, в результате чего, применяя разные подходы, я получил конверсию в возврат от 2.5% до 50% и первую сделку.

Надо было ещё хотя бы одну продажу в тот же сегмент, и поэтому основатель занялся продажами, а я начал делать MVP. Владелец клиники ожидал, что теперь выручка не будет проседать, когда он отсутствует в клинике. Но конверсия, которая делается вручную, не может сделать хоть сколько нибудь значимый объем загрузки. Нужно было обучить (и даже где-то заставить) докторов и администраторов делать дополнительную работу в программе учета: собирать данные о состоянии полости рта на осмотрах, составлять планы лечения и использовать их для возврата. Кроме этого приходилось воевать с самой программой учета - находить способы измерить конверсию и выделить выручку от возврата, а также общаться с их службой техподдержки по найденным дефектам.

Параллельно мы делали продажи, в результате чего состоялась сделка с ещё одной клиникой. Она была совсем не похожа по проблематике: запись на месяц-два вперед, 6 кресел и все постоянно заняты. Однако владельцу клиники так сильно понравилась идея продукта, что он предоставил свою клинику для наших экспериментов. И это, скорее всего, была ещё одна ошибка - наша существующая концепция MVP не давала ему никакой ценности в моменте. А сделать ему весь наш будущий продукт (сбор и обработка информации о пациентах, возврат, чат-центр, IP-телефония и др.) на существующих решениях на рынке оказалось неподъемной задачей, особенно для меня в одиночку и параллельно с другой клиникой.

Тем не менее, мы согласились зайти к нему, чтобы проверить, не вызовет ли отторжения новая система коммуникации у докторов и администраторов? Никаких бизнес-эффектов ни мы, ни владелец не ожидали. Нам просто было интересно, как это будет работать. В результате мы внедрили ему IP-телефонию, попутно заменив старый WiFi на новый (чтобы обеспечить качественную связь), разобрались в его самописной программе учета (на базе конфигурации 1С:Стоматология), выявили его УТП, подобрали предложения по чат-центрам и сделали пилотное внедрение двух решений. От доработок в 1С мы отказались из-за их излишней сложности, и поэтому проверить концепцию продукта на его клинике не удалось. От внедрения чат-центра отказался владелец из-за его достаточно высокой цены.

Выводы

Выводы, которые я сделал по части IT-проектов в целом и IT-стартапов в частности, вынесены в отдельную статью.

Что касается меня самого, то фабрика IT-продуктов - это средство, а не цель. За 20+ лет я понял, что мне не так важно какой продукт делать и в какой сфере. Для меня важно, чтобы он приносил много ценности обществу и, соответственно, много денег его владельцу. Наибольшую ценность я приносил и продолжаю приносить там, где предприниматель подумывает о своём IT-проекте, или уже находится в процессе поиска/разработки IT-продукта. Причем IT-проект не должен быть обязательно стартапом. Это может быть какое-то внутреннее изменение в уже успешной компании, которое, тем не менее, не получается успешно осуществить в рамках обычного проектного управления из-за слишком высокой степени неопределенности и/или запутанности.