Skunk Works курильщика, или собственный лоу-код на страже продаж
С вами Саша Хрущев, технический директор IT-компании WINFOX, и мы продолжаем рассказывать историю нашего лоу-код продукта.
Из первого материала вы узнаете, как зародилась идея сделать Приладу и как мы все провернули. Эта статья про то, как развивается продукт в последние годы: инсайты, сложности, результаты и все такое.
Часть 1. Skunk Works
Когда я был молод, полон сил и остро нуждался в деньгах, меня занесло на собеседование в одну крупную компанию, которая занималась разработкой софта для энтерпрайза и телекома. Я собеседовался на очень интересную должность — что-то вроде техлида в R&D-отдел. Отдел занимался не фундаментальными исследованиями, а разрабатывал вполне прикладные инновационные решения — этакий Skunk Works.
Skunk Works — дочернее предприятие Lockheed Martin, конструкторское бюро, которое разработало самые выдающиеся самолеты Локхидов. Со временем выражение «Skunk Works» стало обозначать некую пиратскую команду гиков, которая реализует безумные инновационные проекты в сжатые сроки.
Все работало так. Продажник приезжает в условную Индонезию и начинает впаривать существующие решения. Клиент ему говорит:
— Это, конечно, здорово, но у нас вообще-то особенности рынка, такой-то бизнес-процесс, нам нужно вот это и вот это.
— Кстати, у нас тут новый релиз выходит. В нем как раз будет та фича, которая вам нужна, и еще пара приятных бонусов, — отвечает продажник, а сам под столом набирает сообщение шефу R&D со списком фич, которые надо через пару недель показать потенциальному клиенту.
С этого момента начинается настоящая жара. R&D-команда пашет без сна и выходных, пока продажник чилит на пляжах. Через неделю разработчики выкатывают новые фичи. Продажник заряжен. Клиент заинтересован. Контракт подписан. В идеальном случае, конечно.
Концепция настолько запала мне в душу, что я даже пытался внедрить ее на тогдашнем месте работы, но не нашел понимания. И пришлось отложить все до лучших времен. До времен WINFOX.
Кстати, собеседование я тогда прошел, но предложенный уровень денежной мотивации совершенно не соответствовал ни моим ожиданиям, ни должности, ни уровню нагрузки.
Часть 2. Я — скорость
После тучных 2010-х, ковида и СВО рыночек довольно быстро порешали, как могли. Пока в других странах рынок диктует условия, In Soviet Russia все наоборот — условия диктуют рынку.
В какой-то момент крупный бизнес перестал интересоваться аутсорс-разработкой как таковой. Никто не хочет вкладываться в долгострой, чтобы сделать круто и не как у всех, но когда-то потом, если есть конкретные бизнес-задачи, которые надо решать здесь и сейчас. Наверное боятся, что завтра очередной китаец съест какую-нибудь кракозябру или прилетят инопланетяне.
Наряду с этим появился острый запрос на готовые продукты, решения, конструкторы. Даже кейсы уже работают не так, как раньше: «Здорово, что вы делали что-то похожее, но нам надо готовое и еще вчера». Плюс импортозамещение, когда к клиенту надо придти с тем, что у него уже есть и работает.
Еще до всего этого мы искали свою миссию и конкурентное преимущество. И выдвинули гипотезу: «Мы не можем сложно, как Х. Мы не можем дешево, как Y. Зато мы можем офигеть как быстро».
У нас даже был положительный опыт блиц-проектов с выводом в продакшн за две-три недели, но мы отреклись от этой идеи. Компания заматерела, обросла процессами и бюрократией, а заказчики стали уже не такими отбитыми. Но отреклись, как оказалось, лишь на время, пока снова не потребовалось в корне менять подход и перестраивать процессы, чтобы не вылететь с рынка.
Сегодня наша цель — убедить клиента, что мы можем дать ему именно то, что он хочет, и в нужные сроки, а не показать готовый продукт. За совсем готовым решением — это в нишевые продукты, конструкторы, вот туда вот. На CodeCanyon, на худой конец.
Да, в плане того же ритейла, наша Прилада и близко не может конкурировать с Imshop.io. Но нашим клиентам это и не надо.
За первые пять лет существования мы разрабатывали вообще все — от биллинга до соцсетей, от игр до промышленной автоматизации. Когда нас спрашивали, можем ли мы сделать фейсбук, но чтобы он был как Вайлдберис и с оплатой биткоинами, мы отвечали: «Подержите мое пиво». Мы даже могли сделать, чтобы бабушка выскакивала и кричала: «Наркоманы!». Вопрос лишь в цене и сроках.
Такая неразборчивость вышла нам боком, зато помогла набраться опыта в разных сферах, собрать значительную кодовую базу и отчасти запихнуть ее в наш лоу-код продукт. Пусть криво-косо и на морально-волевых, но мы начали крафтить рабочие прототипы для особенно важных клиентов.
Часть 3. Fox Works
Одно дело — собрать на коленке пару прототипов для изначально лояльных клиентов и в комфортные сроки. Другое дело — сделать то же самое со сроками «до вчера» и без «вот здесь не смотрите — тут рыбу заворачивали», чтобы это можно было показывать ЛПР, не раздавая тонны кринжа. А уж возвести все в абсолют и породить некий процесс внутри компании вообще звучит как лютый вызов.
Но все не так плохо, когда у тебя есть Прилада. Тот самый продукт, который пока не востребован на рынке именно как лоу-код решение, но является классным инструментом быстрого прототипирования.
Однако даже с нашей Приладой без системного подхода получалось не очень.
Например, простое развертывание того, что уже есть, занимало непозволительно долгое время. Подготовить среду, задеплоить, подтянуть домены и сертификаты, собрать, залить сборки на сервера, протестировать… На это уходило до двух суток. В условиях, когда на все про все есть не больше недели, возиться с такой ерундой даже больше двух часов никуда не годится. А быстро найти что-то нужное для конкретного прототипа в кодовой базе, фичах, ветках — тот еще квест.
И у нас созрел план. Вот он:
Ревью наработок и подготовка шаблонов
Учения по развертыванию типичного демо
Формализация процесса
В ходе ревизии и учений мы получили инсайты, которые немедленно взяли в работу.
Пересмотрели подход к роутингу.
Обнаружили кучу недокументированных функциональных возможностей, значительная часть которых валяется в бэклоге как нереализованные.
Функциональность шаблонов и подключаемых библиотек, которые были разработаны лет пять назад (но понадобились сейчас), оказалась не совсем рабочей.
Имеем пул поддоменов, привязанных к демостендам, которые тоже нужны сильно заранее.
Наскребли по сусекам набор готовых шаблонов.
Сформировали — и частично реализовали — новые требования к разработке:
у любого компонента, который подразумевает интеграцию, должен быть режим эмуляции: например, если у тебя нет кассы, твой кассовый сервер должен уметь делать вид, что она есть;
новый уровень логирования и отладки (больная тема для Прилады в целом);
некоторые дополнительные фичи и настройки, которые сокращают риск накосячить в спешке так, что демка упадет в самый неподходящий момент.
Сформировали и отладили сам процесс презентаций:
формат и таймлайн презентации;
первичный внутренний прогон с обязательной записью видео;
непосредственный показ клиенту.
сбор обратной связи.
После доработок и улучшений в продукте и процессе нам удалось выйти на показатель два-три дня на демо.
Этого времени оказалось вполне достаточно: примерно столько же сейлз может заговаривать зубы клиенту, не вызывая подозрений.
Это дало неплохой буст как Приладе, так и нашим успехам в подготовке демо и последующим продажам. За полгода мы собрали и продемонстрировали больше десяти решений. Вот эти решения:
учетная система для крупного производственного холдинга;
система управления рисками и внутренним аудитом для финтеха;
интерактивный ИИ-тренажер для обучения банковских операционистов (да и вообще любых специалистов, которые занимаются клиентским обслуживанием и продажами);
сервис протоколирования совещаний с последующей автоматической постановкой задач и трекингом;
система автоматического обслуживания клиентов для ЖКХ и лифтов;
облачное решение для фитнес-центров;
интеграционная шина для сервиса спортивной аналитики;
несколько решений онлайн-торговли для ритейла.
Определенно, киллер-фича Прилады в том, что если у клиента уже есть какое-то доступное извне решение, например, интернет-портал, наш лоу-код продукт может спарсить весь нужный контент.
Показать клиенту нужный продукт — круто. Показать клиенту продукт с его данными — бесценно. Для развития Прилады участие в таком процессе само по себе ценно, так как по ходу рождается много интересных технических решений.
Мелкие костыли и подпорки работают как мутации в процессе эволюции, а авральный режим только ускоряет этот эволюционный процесс.
Какие-то решения закрепляются и становятся частью Прилады. Например, такие странные и опасные на первый взгляд штуки вроде потока, который не завершится, пока кто-то не обработает все порожденные им события. Другие решения мы забываем как страшный сон сразу после презентации.
Эпилог
Не все, конечно, проходило и проходит гладко. Вот из последнего.
Клиентский сайт на битре, выдающий невалидные HTML-страницы, от которых у нашего парсера сносит крышу. Пришлось выгружать все страницы, править их руками и потом кормить ими парсер.
Шикарное демо, но контракт мимо из-за того, что мы не успели вовремя податься в реестр отечественного ПО.
Не смогли провести презентацию, так как MS Teams отказался показывать экран и передавать звук одновременно. Записывали видео и отправляли его клиенту. Теперь мы всегда записываем видео заранее.
В следующей статье расскажу о развитии нашего продукта, технологиях, архитектуре и бэклоге фичей.
