Я пообщался с основателями стартапа ElectroNeek: Сергеем (CEO), Дмитрием (CIO) и Михаилом (CTO). В конце интервью — видео, где в прямом эфире собирают робота.
— Дмитрий, пришли, пожалуйста фотку для КДПВ, где вы все вместе.
— Не поверишь, мы так вживую и не встретились еще все за два года)
ElectroNeek разрабатывает экосистему программных продуктов, с помощью которых можно создать роботов, которые повторяют любые действия офисных сотрудников за компьютером с любыми приложениями, которые на нём установлены. Таким образом можно полностью или частично роботизировать процессы в компании. Специализацией ElectroNeek является работа с системными интеграторами и IT-командами, создающими центры компетенций RPA, иными словами, их продукты предназначены для тех, кто разрабатывает роботов в большом количестве, а не решает несколько конкретных локальных автоматизационных задач.
RPA (роботизированная автоматизация процессов) — это технология, которая помогает автоматизировать повседневные, повторяющиеся задачи. RPA позволяет эмулировать действия обычного пользователя за компьютером, в буквальном смысле. Вы навели мышку на кнопку и кликнули, потом клавиатурой ввели текст и нажали «Enter». Ровно это и есть RPA. По мере увеличения спроса RPA-вендоры стали развивать свои решения, чтобы предоставить более гибкие механизмы автоматизации. Появились интеграции с языками программирования, с технологиями вроде OCR, всерьез думают о внедрении машинного обучения. Роботов теперь можно запускать одновременно, по расписанию, удаленно и т.д. Примеры кейсов: раз, два, три, четыре, пять.
— Что такое робот?
Михаил: Роботизация — это эмуляция человека. Человека можно эмулировать в разных ипостасях. Можно физически. Робот ходит как человек. Робот кликает по монитору как человек. Набирает текст как человек. Никогда нет полной эмуляции человека. Но аспект эмуляции человека и есть роботизация.
— Михайл, вас хантил Яндекс, но вы всё же решили работать в ElectroNeek, какая у вас мотивация работать в стартапе, а не на теплом гарантированном месте?
Михаил: Когда работаешь в стартапе — ты сам кузнец своего счастья, а в компании ты ограничен.
— Михаил, как тебя схантили?
Михаил:К тому моменту, я уже год как ушел из Акрониса, я перестал видеть свой вектор развития, хотел изучал разные технологии, делал pet-проекты. Мне хотелось делать что-то своё и я искал себе команду. А тем временем Димитрий и Сергей искали себе CTO и кинули клич по своим знакомым. Я был знаком с Дмитрием с университета, хотя особо и не общались, так и сконтачились. Я был готов к этому предложению.
Мне нужно было понять, верю я в проект или не верю. Мы встретились с Сергеем в кафе, он мне очень поверхностно описал, что это из себя представляет Electroneek, а после встречи я самостоятельно изучил тему RPA подробнее, посмотрел конкурентов.
Мы ещё раз созвонились, уже втроём. С Сергеем мы в живую рядом сидели, а Дмитрий в это время был в Америке. Мы общались о продукте, как они это видят, куда планируют развиваться, для кого это, за счёт чего мы будет выделяться и зачем на рынке «ещё один конструктор роботов».
Я увидел, что спрос есть, как минимум, в России. Дмитрий рассказал о глобальном рынке, в частности про США. Он до этого работал в Ernst & Young и занимался там RPA для Fortune 500 rкомпаний, так что хорошо представлял себе спрос.
Сергей и Дмитрий решили отличаться от конкурентов простым и удобным UX, сделать роботизацию более доступной для компаний любого размера. Мне нужно было знать, понимают ли мои потенциальные кофаундеры, какой будет интерфейс, в чем именно его классность. Я услышал честный ответ «Мы не знаем». Ребята в моменте не знали, что именно должно быть, но планировали пробовать и выяснять.
Для меня была важна такая честность и открытость. Мне понравилось, что они честно рассказали о ситуации. Это важно для будущих взаимоотношений. Сказать всё как есть, и если человек адекватный, он поймёт. Когда вы честны, если где-то косяк вылезет, сразу можно смотреть на то, как решать проблему, независимо от того, кто накосячил.
— Как выглядел Electroneek до твоего прихода в проект?
Михаил:До меня был рабочий прототип, который можно было показывать. Это был проект на GitHub, чтобы показать, что они примерно хотят сделать.
Когда я пришёл, мне показали прототип, рассказали о конкурентах, о задачах, которые нужно решать и попросили сделать хорошо. Не на коленке, а вдолгую, чтобы это можно было развивать. Но времени долго сидеть разрабатывать не было, нужно было быстрее в бой. Нужно было бежать к клиентам, нужно было привлекать деньги. Поэтому с первых дней я начал писать код. С Electron я был знаком уже на тот момент. (Electron — это фреймворк, который позволяет писать десктопные приложения используя веб-стек технологий.)
— В чем особенность разработки RPA продукта от остальных?
Сергей: Чем отличается разработка RPA-платформы от продукта «сам в себе». RPA платформа, в частности ElectroNeek — это средство разработки. Средство по созданию чего-то по взаимодействию с чем-то третьим. Это не отдельный продукт как CRM, которая сама в себе и только иногда по API взаимодействует с чем-то третьим.
Пользователь на базе ElectroNeek создает программное решение (робота), который будет взаимодействовать с другими продуктами, которые меняются постоянно: браузеры, десктопы. Ты не контролируешь то окружение, с которым будет взаимодействовать результат разработки. Это накладывает огромные требования к качеству, к UX, к выработке продуктовых решений.
— Зачем ещё один RPA-продукт на рынке?
Сергей: часто к нам приходят люди и говорят: «Зачем вы разрабатываете, когда можно зайти на какой-нибудь веб сайт, скачать готовый модуль RPA кликера и его делать?». Да он сможет открыть блокнот, освоится с интернет-эксплорером, откроет Гугл. Но как только ты пойдешь дальше (как только появится XPath или селекторы), разные варианты сайтов, государственных или SaaS экосистем, ты столкнешься с тем, что оно не готово и не работает. А дальше, если ты занимаешься развитием собственной платформы, тебе это нужно подстраиваться под изменения, а если всё уже зашито намертво, то ты не можешь гибко подстраиваться к изменениям. Это у нас было на пилоте.
— Как выбирали стэк технологий?
Михаил: Проект подразумевал, что будет и десктопная и web-части, классический front, классический back и десктопное приложение. И по-началу, проект не подразумевал большую команду. Я понимал, что первые несколько месяцев я буду один, расширения грандиозными темпами мы не планировали.
Мне нужно было обеспечить какую-то многостаночность, чтобы 1-3 человека могли делать всё. Потому мы выбрали Electron. Он позволяет на одном и том же языке (у нас это TypeScript) писать десктопное приложение, backend и frontend.
В будущем можно сделать специализацию, но на старте очень удобно, когда каждый человек может делать всё.
Как правило есть проблема переключения контекста с бекэнда на фронтенд. К примеру, бэк на питоне, фронт на JavaScript, популярная комбинация. И даже если это совмещает в себе один человек, ему затратно и тяжело будет переключаться с одного языка на другой. А когда решаешь одну задачу, то переключаешься часто, это не удобно. Мы от этого избавились, при переключении ничего не меняется: один язык, один подход, даже выглядит все одинаково.
Дальше я поискал библиотеки, которые могут сразу закрыть часть моих задач, а не пытался написать все сам.
На старте не нужно пытаться что-то навелосипедить. Возьмите готовое, если оно отвечает вашим требованиям. Возможно, потом вам действительно придётся этот кусок вытащить и заменить на своё. Но при этом у вас сразу будет какая рабочая штука.
Я взял готовую библиотеку для визуализации. У нас основной продукт — это среда разработки, и там есть визуализация блок-схем. Естественно, я не писал её сам, а взял открытую библиотеку joinjs. Она позволяет работать на уровне svg. С помощью векторных картинок рисовать интерфейсы.
Мы давно уже на ней сидим. Иногда думаем от неё избавится, это можно сделать в любой момент, но пока она все задачи выполняет и нагрузку держит.
Важно писать всё модульно, чтобы можно было выкинуть какой-то кусок и не запутаться в собственной паутине кода. Модульный подход позволяет быстро избавляться от библиотек.
Наша программа не просто редактор блок-схем, она конкретную задачу решает — автоматизирует десктоп. Ты с её помощью управляешь десктопными приложениями.
Важная часть нашей программы — низкоуровневая библиотека по взаимодействию с приложениями, как кнопку нажать, картинку считать, скриншот создать.
Я взял стандартную библиотеку на C# UIAvtomation, ею же в тот момент пользовались наши конкуренты. Недавно мы ее заменили на более современную.
У этой библиотеки была обертка, довольно узкий API, который мы использовали. Потом мы эту библиотеку смогли выкинуть, прикрепить новую и адаптером к этому API приклеить. Это быстро безболезненно происходит, так и надо делать.
— Как реализовывали фичи?
Михаил: Я пообщался с кофаундерами, у них был опыт интеграции решения конкурента, они понимали, какие фичи нужны. Они дали мне список фичей, которые часто использовали. Я стал их делать одну за другой.
Буквально через месяц или два мы начали делать пилотный проект для Почты России.
Мы решили для них задачу по автоматизации выгрузки. У них было десктопное приложение для HR по управлению резюме. Там не было никакого интерфейса, а нужно было вытащить оттуда все резюмешки. Там не было API, базы данных и они не могли их вытащить.
Мы просто прокликивали это приложение, скрэпили данные оттуда и складывали на диск.
Принципиальное решение было не сложным, я написал алгоритм за несколько часов, но весь дьявол в деталях. Куча нюансов: документы разных типов, каких-то типов полей может не быть и тд. На допил я потратил ещё какое-то время.
По каждой фиче я задавал себе вопрос, какое решение мне сейчас нужно, чтобы в будущем я мог решать задачи такого рода. Если фича проходила этот фильтр, я ее добавлял. На старте фичи добавляются без особого обсуждения. Кодовая база маленькая, добавил, попробовал, удалил, это легко.
Когда приложение уже большое, на каждую фичу нужно обсуждение. На что фича повлияет, не сломает ли она что-то, а есть ли у нас другой способ. На старте пилить фичи легко, они ничего не ломают, потому что ломать ещё нечего.
— Какой масштаб работы был для почты России?
Михаил: Приложение содержало всех сотрудников Почты России по всей стране. Руками это прокликать невозможно.
Что делал наш робот. Он заходил в поиск с пустыми фильтрами. В результате — список всех сотрудников со скроллом на несколько экранов. На каждый элемент списка на листе нужно кликнуть, открывалось окно, там часть данных и несколько кнопок, которые открывали другие окна. Все окна надо было пооткрывать, все данные соскрепить, окна обратно позакрывать и перейти к следующему элементу в списке. И такими итерациями все стащить. Вот примерная суть процесса.
Пилот был обоюдно-бесплатный и до состояния продакшн мы доводить не стали. Для себя мы сделали proof of concept: на платформе можно решать такие-то задачи, можно с этим идти привлекать деньги, можно клиентам продавать и на ходу допиливать. Этим мы и стали заниматься.
— Как привлекали инвестиции?
Михаил: Нам нужен был рабочий прототип, который бы впечатлял инвесторов. Интерфейс решения для Почты России не был красивым, его делал я, а я не дизайнер. Я сделал под себя, IDE WebStorm Dark mode.
Ранние этапы прототипа
ElectroNeek в 2021
Инвесторы умеют применять фантазию. Им можно показать кривой прототип и рассказать, как он изменится и они поймут. Прототип может быть даже забагованный и глючить, но главное — это показать зерно смысла, чтобы инвестор уловил суть. Клиентам надо показывать уже готовый и красивый продукт. Адекватные люди понимают отличие MVP от конечного продукта. А с неадекватными лучше не работать. Инвесторов «берешь надолго», с адекватными людьми работать приятно.
— Что из себя представляли демонстрации инвесторам?
Михаил: Допустим, я написал новый функционал, и завтра с утра его надо демонстрировать инвесторам. Я понимаю, что в таком виде это показывать нельзя. Может подглючивает что-то, может примера хорошего нет, чтобы показать функционал. Сижу дописываю ночью, придумываю примеры, вылавливаю баги, чтобы утром это хорошо выглядело. Утром прихожу не спавши на демонстрацию. Показываю инвесторам продукт. Почти без сна, зато успешно.
Первое время без этого никак. Нет нормального процесса разработки, когда есть полноценная dev среда, тестовая среда, стендинг, продакшн. Есть только одна среда, она тебе и стендинг и продакшн. Ты один и твоя задача делать быстрее. И работаешь ты как хирург, который только приготовился к операции и «вскрыл» код, а ему говорят: «ну, давай зашивай быстрее и пошли».
Приходилось делать все и успевать. Пока приложение маленькое, оно хорошо лежит в голове, хороший разработчик в состоянии все сделать сам и ничего не упустить. Когда приложение вырастает, уже невозможно без QE обходиться.
Сергей: У нас были ограниченные ресурсы, мы получили всего 150 000 долларов из них наличными дошло 70 000. Это все что было, чтобы допилить прототип до нормального продукта и показать первые продажи в России и в США. Потом подняли 0,5 млн долларов. Мы показали быстрые продажи. В нас поверили инвесторы.
Михаил: Как только появились деньги — стали расширять команду, чтобы сделать побыстрее хороший продукт. Что значит «хороший»? На ранней стадии не нужен идеальный продукт, хотя его можно сделать. Это ошибка. Многие умеют делать идеально, но это долго. Если быстро и хорошо, то слишком дорого. Все сразу невозможно. Соответственно, здесь надо сделать достаточно хорошо. Достаточно хорошо — чтобы продавалось.
Можно делать продукт с багами, если они не критические, не стреляют в ногу, а фичи получается добавлять быстрее. Люди покупают продукт с багом, видят баг, репорт о нем, мы его исправляемся тут же. Люди видят фидбэк. Проблемы нет.
— Как вы нанимаете разработчиков?
Михаил: Я больше обращаю внимание на способности, а не на опыт. Опыт важен, но разработка — дело такое, где постоянно надо чему-то учиться. Когда в проект придётся затащить новую библиотеку, вероятность того, что ты ее знаешь, будет не очень высока. Знания важны базовые. Нам нужно было знание TypeScript, переучивать на другой язык долго. Фреймворк желательно знать. Мы используем от Angular.
Нам важно чтобы человек мог быстро решить сложную задачу без ошибок, или с ошибками, которые легко исправить, которые вылезут при прогоне. Человек должен уметь многое продумать. Если он в состоянии многое продумать, понять, какие вообще есть корнер-кейсы, то это круто.
Часто бывает, что люди пишут программу, а о каких-то кейсах просто не подумали. А кто он них будет думать? QA о них тоже может не подумать. А потом они стрельнут. При этом изначальных данных достаточно, чтобы эти корнер-кейсы предугадать. Это для меня отличие перспективного разработчика от неперспективного: какое количество корнер-кейсов на старте он способен предвосхитить.
— Сколько сейчас людей?
Михаил: Шесть человек — ядровая разработка, которые непосредственно платформу делают. Четыре человека, которые на платформе делают переиспользуемые решения. Они используют именно платформу, плюс дополнительные инструменты на скриптовых языках, и делают конкретные проекты. Я сейчас только про разработчиков говорю. Ещё есть отдел QA, отдельно продуктовая команда.
— Как ты перешел от написания кода к управленческим обязанностям CTO?
Михаил: После получения инвестиций я ещё несколько месяцев активно писал код. QA мы хоть и наняли, но я в них особо не был уверен. Я сам писал код-ревью.
Потом я увидел на канбан доске, что я — узкое горлышко. И понимаю, что пора отпустить вожжи, принять, что проблемы будут проходить мимо меня в продакшн.
Я ревьюил самые критичные вещи. Стал полагался на QA. Это был постепенный процесс отпускания контроля. Когда ты пропускаешь через себя все, ты уверен в результате. Ты все видишь, можешь сам отловить все проблемы. Но это не масштабируемая история. Она хороша на старте, дальше от неё надо потихоньку избавляться. Так я постепенно отпускал, ревьюил только критичные места, а потом вообще перестал писать и ревьюить. Сейчас все это делают без меня.
— Вот вы смирились с падением качества, что дальше?
Михаил: Смотрим, нет у меня больше опции ревьюить код, это мы уже проходили. Что я ещё могу? Теперь можно процессные вещи налаживать.
Допустим, разработчики мёрджат не очень качественные фичи в основную ветку. Наверно с ревью что-то не так. Посмотрим. Смотришь, что люди ревьюят. Ага, вот на это внимание ребят обратить. Переходишь к инструкциям. Отлаживаешь процессы. Ищешь слабые места. Не пытаешься делать работу, а создаешь процессы.
Вот тут разработчики ревьюят, а фичи по прежнему мёрджат не очень. Давайте добавим тестирование фичи перед тем как её мёрджить. Добавили. Что получилось? Теперь QA не успевает их тестировать. Окей, наверно не все фичи надо таким образом тестировать, а только самые опасные, которые влияют на весь проект. Ты балансируешь
Тут нет шаблона для разных компаний, но общий подход один — тестировать свою систему и процедурно исправлять узкие горлышки. Тогда это уже масштабируемая история.
Моя задача найти узкое место, где процессная проблема, с людьми поговорить и внедрить рабочее решение.
В идеале, если я в отхожу в сторону, то всё работает. На старте так невозможно. Шаг в сторону, все сломалось. А сейчас должно быть так, что я на месяц отошёл и ничего не сломалось.
— Как понять когда надо нанимать специального человека?
Михаил: Хватает ли на это узкое горлышко человека? Если человек хотя на 70% будет загружен этой задачей, то можно нанять. Если человек тебе нужен на 5% времени, то наверно, ты пока сам с этим справишься.
— Чем ты сейчас занимаешься?
Михаил: Я по прежнему занимаюсь процессами. И ещё долго буду ими заниматься.
Занимаюсь обсуждением фичей, как и Сергей. Это то, куда растёт наш продукт. Он пропускает это через свою призму, я через свою.
Мы разработчики, которые пишут инструмент для разработчиков. Я не в состоянии уследить за всеми фичами, что мы делаем, но важные, сложные, критичные или интересные я анализирую и даю фидбэк продуктовой команде, которая с его учетом оптимизирует фичу. Я не занимаюсь описанием, а слушаю, что собираются делать и даю фидбэк. Сергей в плане фичей занимается тем же самым. Это то, что мы пока точно не отпустим. Важно понимать, куда движется продукт, куда мы его развиваем.
— Как ты учишься?
Михаил: Сначала я четко формулирую проблему. Жизненный опыт многое уже позволяет решать. Я уже знаю гораздо больше, чем на момент выпуска из университета, но все равно есть проблемы, которые я не понимаю как решить.
Для начала я разбираюсь в чем проблема. Допустим, у меня нет какого-то инструмента. Гуглю, смотрю YouTube или какой-то курс, выясняю, как делают профессионалы в конкретной области.
Например, как тестировать большие приложения, когда очень много ручного тестирования? Не успеваем, что делать?
Если ты в прошлом не крутой QA, то опосредованно понимаешь что к чему, но каких-то нюансов можешь не знать. Открываю ютуб, слушаю часовую лекцию QA с многолетним опытом, понимаю, что из услышанного можно применить, пробую, анализирую. Если подошло, оставляю.
Все знать невозможно. Задача любого руководителя научится все, что возможно, делегировать и так, чтобы оставить за собой контрольную функцию.
Задать рамки, в которых люди работают, и контролировать результат в этих рамках. Решения они принимают самостоятельно.
Если на проде какая-то проблема, решение может быть принято без меня. QA говорит, что задача критичная и может принять решение откатить. Мне не нужно для этого просыпаться. Главное, чтобы люди понимали рамки.
— Совет самому себе в молодости?
Михаил: Мне на старте казалось, что сначала надо очень многому научиться. Чего-то я ещё не знаю. Не умею писать веб-сайт, не умею писать бекэнд. Мне хотелось сначала курс какой-то пройти или университет закончить. На самом деле нет. Возьми и попробуй. Гугл отличный инструмент, там вообще все есть. Решай проблемы точечно. Не умеешь конкретно это делать, конкретно это и научись делать. Не умеешь ты nginx настраивать, вот конкретно это и изучи.
Всего не изучишь. Слишком трудозатратно проходить многонедельный курс по программированию. Лучше начни программировать. Те проблемы, которые будут у тебя возникать, их и решай. Так быстрее. А ещё сильнее погружаешься в проблему, чем читая книжку. Если прочитал от корки до корки 600 страниц, то знания будут поверхностные. На опыте знания глубже.
Я «открыл для себя Гугл», в том смысле, что я могу со своими знаниями, делать сложные вещи, гугля, и находя точечные решения для затыков. Я так и развивался в дальнейшем.
Книги я читал выборочно. Когда решал проблему, находил фрагмент, где описывается решение. Статьи так же. Лекции тоже можно не целиком смотреть. Лекции бывают на 4 часа. Найди тайм код, посмотри только интересный фрагмент, его может быть достаточно.
— Расскажите про Service Organization Controls (SOС)?
Сергей: Если вы хотите делать приложение SaaS на американском рынке, особенно что-то, что будет работать в компаниях больше 200-500 человек, сразу возникнет вопрос про SOC (Security Organization Control). Пока его у тебя нет, все его спрашивают. Это история, которая причесывает политики организации распределение по уровню прав и доступа, как проектировать код, приходят аудиторы, проверяют.
Пока его у тебя нет, все нормальные клиенты его спрашивают и не подписывают договор. Как только он появляется, и ты говоришь «вот он у нас есть, хотите пришлем отчет», клиенты отвечают, что не надо, «не хотим читать отчет».
Он делается четыре месяца, приводится в порядок, проходит проверки. Набор мероприятий, который затрагивает весь технологический стэк. Михаил может рассказать, он драйвил этот процесс полностью.
Михаил: Мы организация, которая предоставляет сервис клиентам. SOС — это про то, какие внутри нас есть инструменты, чтобы обеспечить безопасность, доступность и непрерывность работы сервиса и сохранность данных. Все те вещи, которые интересуют крупных клиентов и мало интересуют маленькие организации.
Если наш клиент — крупная организация, то отсутствие SOС, может быть для них проблемой. Их регламент не позволяет работать с тобой. Поэтому в определенный момент у нас это всплыло.
Либо у тебя есть эта сертификация, SOС (она ещё дорого стоит для начинающего стартапа), либо компания присылают тебе многостраничный опросник о том, как у вас обеспечена безопасность. Ты его читаешь и половину из этого не понимаешь.
Заполнять его можно долго, т.к. сходу не всегда понятно о чем речь. Плюс пока заполняешь, понимаешь, что у нас этого нет. И вот этого нет. И вот этого тоже нет. И смысла уже нет отправлять этот опросник. И вроде не так сложно сделать, чтобы эти вещи были. Но этим надо заниматься.
В какой-то момент, мы поняли, что к нам приходят такие клиенты, мы долго заполняем их опросники, а в результате сделки нет. Решили разобраться с этим вопросом.
Эта сертификация — мониторинг, непрерывный процесс. Не то, что ты один раз сделал и все. Ты должен регулярно проставлять какие-то «галочки». У тебя данные всегда шифруются при передаче. У тебя данные, которые на серверах всегда в зашифрованном виде, на случай, если на жесткий диск куда-то пропадёт, то никто оттуда ничего не вытащит. Таких примеров там много и более изощренных тоже.
Когда начинаешь гуглить, как этого добиться, находишь простыню на 60 листов А4, что и как нужно делать. И каждый пункт нужно разбирать, потому что ты его не понимаешь. Выглядит как очень долгая работа.
Окей, таким путём мы будем долго идти. А может найдём компанию, которая нам упростит жизнь? Наши компанию. На тот момент мы уже были в Y Combinator. Мы задали этот вопрос ребятам оттуда, нам подсказали выпускников YC, которые автоматизируют эту историю. Услуга не бесплатная, но мы купили у них услугу. Это некоторая админка, в которую ты интегрируешь все свои сервисы. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, у кого что. Программа сама изучает, где у тебя какие настройки, и говорит что и где тебе не хватает. Ты точечно исправляешь и автоматом закрываются все пункты, что в этой простыне есть.
После этого приглашают аудитора, который подтверждает, что все действительно есть и ставит «зачёт». Вот так мы упростили себе жизнь.
Для больших компаний эта формальность, без которой они не могли идти дальше и сотрудничать с нами. Ну и как плюс, реальное повышение безопасности клиентов.
— Расскажи про Y Combinator глазами разработчика?
Михаил: Мне не очень понятно было для чего нужен YC. Понятно было что это престиж. А конкретную цель мне было тяжело понять. Читал про то, как там может быть. Мне тяжело было представить, какой полезный опыт там можно было бы получить. Относился достаточно скептически к тому, что я как профессионал прокачаюсь. Но я понимал, что для компании в целом это полезная веха.
Если говорить по результату. Мы получили больше бизнесовых преимуществ. Так же помогли техническими ресурсами и до сих пор помогают. Сделали более правильную инфраструктуру в облаке.
Главный вывод в этой истории: если вы готовы использовать те продукты, которые предоставляет YC, готовы углубиться в их понимание, то это будет большим плюсом.
Мы закончили YC в марте 2020, закрыли раунд 2,5 млн долларов. Начался существенный рост и команды разработки, и задач.
— Как вы пришли к той продуктовой команде которая есть сейчас?
Михаил: У нас продукты достаточно сложные, нужно быть разработчиком, чтобы понимать продукт для разработчиков. Нужно понимать с позиции разработчика, какие фичи внедрять, как их используют наши клиенты. С другой стороны стоит быть хорошим бизнесменом, исследователем рынка. Совмещать все эти компетенции. С этим есть некоторая сложность.
Сергей: Мы за последние 4-5 месяцев с марта по август, сначала взяли одного продакт-менеджера который имел опыт в RPA. Мы поработали с ним несколько месяцев и не получили результата. Мы не нанимали продакт-менеджера из серии «мы тебя наймем и сразу польется золото», мы хотели прийти к четкому пониманию, какие фичи мы делаем, они нужны для захвата будущего рынка, для решения конкретных проблем клиента, для апсейла. Мы брали продакта на вполне измеряемые метрики и это обговаривали. К сожалению, оба продакта скатывались. Наша вина тоже в этом есть. Мы нанимали людей которые предлагали сделать фичу, «потому что она красивая.» А сколько она денег принесет? Ну, тяжело посчитать… А кому она поможет? Как она поможет выигрывать текущие сделки или хотя бы их не проигрывать? У нас не получалось выстроить такую историю.
К чему в итоге мы пришли. Супер комфортная для нас схема, она очень драйвит нашу компанию.
У нас есть UX-продакт-менеджер, технологический продакт-менеджер, у нас есть Head of Engineering, есть CTO, есть CEO как представитель бизнеса. У нас сформирован продуктовый офис, где продукт «нарезан» на разные части. UX, анализ новых фич, инжиниринг. Мы с Михаилом выполняем роль фасилитаторов в случае приоритезации. Я еще отвечаю за sales-фичи. Дмитрий смотрит на то, как продуктовые фичи транслируются или могут транслироваться в маркетинговые возможности и инструменты, такие как наша глобальная библиотека ботов, созданных клиентами и партнерами.
У нас возникают спонтанные сессии для обсуждения серьезных задач. У нас также есть еженедельный полуторачасовой звонок, где мы планируем следующий спринт, который уже распределен по приоритетам внутри компании. Новые фичи у нас залетают по трем трекам: баги — чиним то, что не работает, тормозит продажу или мешает текущим клиентам; UX — чиним текущее, потому что мы знаем, что продукт всегда можно улучшить; добавляем новое в продукт, что позволит в будущем быть более эффективными. В таком фреймворке и работаем. Мы бы хотели прийти к одному человеку, который занимается всем продактом, но пока нам кажется, что это тяжело.
Хочется посоветовать будущим предпринимателям, особенно технарям, не пытаться рассматривать только одну опцию (что CEO должен найти продакт оунера), а что есть формат распределенного взаимодействия, который дает результат.
— Можно ли при помощи вашего робота фармить в компьютерных играх, клики в ютюбе?
Дмитрий: На нашей базе один клиент сделал робота, который включает чайник.
Сергей: Робот любую кнопку может нажать. Мы даем средство разработки. Что на нём строят клиенты — это на ответственности людей. Можно построить всё что угодно.
Сергей: Была у нас одна история. Клиент купил услугу, а потом написал: «Я специально выбрал самую не развитую в ИТ направлении девушку в нашей компании, „Олю“. И вот „Оля“ смогла с помощью ElectroNeek создать робота. Если „Оля“ смогла, то любой в моей компании сможет. Я у вас покупаю продукт!» Это высокий показатель простоты использования. Хотя в основном у нас пользуются разработчики junior или middle уровня. Они получают продукт, в любом стэке (веб, десктоп, есть API или нет), создать приложение (робота?), это свобода, которую дает наш продукт.
Дмитрий: Когда попадает продукт к инвесторам на раннеей стадии, то там историия с «Олей» повторялась, есть свои «Оли» среди инвесторов. Были ситуации когда в продукт залезали партнеры топовых американских фондов (Гэри Тэн из Initialized, бывший партнер YC и инвестор в Coinbase и Instacart). Партнер руками начал собирать робота.
