«Теrrапия» для Taist

Дмитрий Фалалеев: Добрый день! Меня зовут Дмитрий Фалалеев, я руководитель проекта Firrma.ru. Вы смотрите очередную серию программы «Теrrапия». Суть программы очень простая: к нам приходит руководитель молодого проекта за советом к двум экспертам. Сегодня у нас очень интересная программа. У нас — небезызвестный на рынке человек, которого зовут Антон Белоусов. Он пришел со своим новым проектом Taist. И он будет задавать вопросы двум экспертам. Первый — Станислав Протасов, вице-президент и сооснователь компании Acronis. Второй — Сергей Топоров, инвестиционный менеджер LETA Capital. И, Антон, я тебя прошу презентовать свой проект, рассказать, что, зачем и почему и за каким советом ты пришел.
Антон Белоусов: Спасибо, Дима! Спасибо, коллеги! О проекте: какую проблему решаем?

Коротко: проект позволяет кастомизировать «облачные» b2b-сервисы.

Чуть длиннее: любой софт, который бизнес использует, — это инструмент решения каких-то задач в рамках каких-то процессов. У каждого бизнеса эти процессы свои, и ему в идеале нужен софт, который написан только под него. Такой софт делается, это заказная разработка. Но куча софта «коробочного» делается одними разработчиками и продается большому количеству клиентов. И этот софт нужно под потребности конкретного клиента «затачивать», адаптировать. Это называется «кастомизация». Софт традиционный, не «облачный», любой так можно сделать, в него такие механизмы закладываются. Это не очень дешево, но приемлемо. Любой — это значит от Microsoft Word до SAP и всего, что между ними. Все это можно очень сильно «заточить» под потребности конкретного бизнеса. «Облачный» софт так кастомизировать нельзя по техническим причинам. Он вертится на сервере у разработчика в одном месте, и под конкретного клиента его менять не получается. И в результате только очень крупные компании способны «облачный» софт «заточить». Это «облачные» ERP-системы типа NetSuite или IQMatics, которые также на этом стараются специализироваться, Salesforce и Google. Ну и к ним добавляются SharePoint и SAP. Все остальные компании и их клиенты имеют с этим огромные проблемы: софт не полностью подходит под процессы конкретного заказчика. Простой пример для наглядности, последний. Когда я к съемкам передачи готовился, презентацию делал изначально в формате 4:3, мне нужно было переделать на формат 16:9. В интернете обнаружилось, что есть плагин к Microsoft Power Point, который это делает автоматически. Почему он был создан конкретным любителем? Потому что ему приходилось по работе такую задачу делать много раз, конкретно это его специфика. Мне это надо сделать один раз, кому-то приходится много раз, он заморачивается, создает такой плагин. А для «облачных» средств создания презентации, соответственно, такого плагина нет, технически это невозможно сделать пока. Таких примеров очень много. Они специфичны для конкретного бизнеса, и в сумме их накапливается очень много. Это одна из причин того, почему сами разработчики софта все фичи, все пожелания от клиентов не делают. Их слишком много, захламляется продукт, становится очень дорого и продавать, и поддерживать его. И все мечтают о том, чтобы вокруг себя создать платформу, экосистему некую, которая будет сама продукт двигать. И я эту тему знаю не понаслышке, я кастомизацией занимался со всех сторон: и работой в небольшом системном интеграторе, и со стороны разработчиков «коробочных» продуктов, и со стороны клиента как менеджер по автоматизации, внедряя различный софт и «затачивая» его под потребности конкретной организации. И идея проекта несколько лет рождалась, постепенно, исходя их тех задач, которые я решал. И также ко мне в ходе проекта присоединялись «адвайзеры», Ник Михайловский и Алексей Соловьев, которые точно так же по своему профессиональному опыту проблему понимают очень хорошо. И в итоге мы придумали, как эту проблему решить разом, в принципе, для всего «облачного» софта — создать некую платформу, которая позволяет в итоге делать то же самое, что происходит в мире «коробочного» софта: дорабатывать «облачные» приложения силами клиента или силами подрядчиков под конкретно него, не завися от вендора. В принципе, рынок большой, и все те процессы, налаженные на традиционном софте, позволяют это все перенести в «облако», на «облачный» софт, который сейчас стремительно развивается. О технологии расскажу, наверное, в ходе ответов на вопросы.
Как это все планируется продавать? В принципе, все процессы переносятся на «облака». В итоге самые «жирные», самые крупные клиенты — это крупные организации, у которых есть либо свои отделы внутренней автоматизации, которые как раз такими вещами занимаются, либо их обслуживают различные VAR (Value Added Resellers), консалтеры, системные интеграторы, продающие организации софт вместе с контрактами по поддержке, по кастомизации. В этом случае чеки могут скромно исчисляться десятками или сотнями тысяч долларов на платформах, которые позволяют все это дело выполнять. Но до этого дойти всегда очень непросто, поэтому предполагается изначальный рост снизу. И самый первый сегмент — это либо одиночные веб-разработчики, которые пользуются сервисами под свои нужды и у которых тоже много «хотелок», с них начинать. И параллельно это организации, использующие небольшие «облачные» CRM и т. д., которые здесь и сейчас тоже готовы первыми кастомизациями заниматься.
Альтернативы. Пока прямых конкурентов нет. Я уверен, что, как и все идеи, всё развивается параллельно. Кто-то, наверное, такую тему на уровне стартапа «пилит». Существующих игроков больших нет, есть альтернативы. Первая — то, что мы называем «внутренние платформы кастомизации». Это как раз то, что создали крупные вендоры для себя и что является критическим фактором их успеха, как, например, в случае с Salesforce. Вторая ключевая альтернатива — это создание одиночных расширений к браузеру на заказ. Интересно, что эта тема уже начинает развиваться. Компании сами [делают] или заказывают какие-то расширения к браузеру, которые решают ровно одну их потребность под один конкретный софт. Мы, по сути, наиболее к такому подходу близки, просто мы позволяем не возиться с кучей сервисных задач и в десятки раз сокращаем разработку и поддержку всего этого дела. И конечно, сразу всплывает вопрос «Чем вы отличаетесь от проектов, которые направлены на интеграцию?». Это Zapier, IFTTT. Суть в том, что эти проекты позволяют интегрировать различные «облачные» сервисы чисто на уровне данных. В общем, задачу сделать так, чтобы конкретную программу, в которой все на 90% хорошо, сделать подходящей под процессы на 100%, чтобы избежать человеческих ошибок и потери времени, они не решают.
Наше текущее состояние: мы на самом деле несколько раз, работая с клиентами, с партнерами, в общем, с рынком, поворачивали, меняли бизнес-модель. В итоге мы очень быстро нашли ответы на те риски, которые мы считали изначально самыми сложными технологически. Все это не так. Все риски реально бизнесовые. Несколько раз приходилось из-за этого бизнес-модель менять. В итоге мы подтвердили, что такая проблема уже начинает осознаваться бизнесами, что они готовы за нее платить, что вендорам действительно тоже выгодно с нами работать. И у нас в итоге есть некие первые результаты. Это такой нулевого уровня traction. И сейчас мы определили четко, на каких сегментах мы будем фокусироваться. Это параллельно и в России, и на Западе. И есть четкие цели, условно говоря, на три месяца. И наша цель — показав определенный traction, через примерно три месяца поднять вопрос о посевных инвестициях. Без результатов нет смысла разговаривать, да.
Д. Ф.: Ты пришел с каким-то конкретным вопросом?
А. Б.: Да, я пришел с конкретным вопросом. С одной стороны, мы много, да, наработали, и кажется, что мы все такие умные. С другой стороны, мы можем просто чего-то не видеть. Может, что-то подскажут. А конкретный вопрос такой. Мы сейчас понимаем, что до самых «жирных» клиентов и партнеров, которые работают через интеграторов и консалтеров, нужно дорасти постепенно. Вопрос: есть ли какой-то хак, можно ли как-то это дело обойти и можно ли выходить на них напрямую? Пока первоначальные контакты говорят, что нет, что до крупного системного интегратора, чтобы он нас использовал и перепродавал, можно дорасти только последовательно, показав более большие по масштабу success stories, и уже с очень зрелым продуктом. Есть ли какие-то хаки?
Д. Ф.: Станислав?
Станислав Протасов: На этот вопрос трудно ответить, потому что два самых интересных слайда мы отложили.
А. Б.: Технология.
С. П.: Нет, не технология, а скорее там, где было написано про 10+ пользователей SMB. Я пока понять не могу. Можно еще раз, с самого начала. Вот я SMB. Вы ориентируетесь с этим проектом на DevTools, допустим. Это мне относительно близко, мы используем пару DevTools. Соответственно, клиент — это SMB, да? То есть это маленькая разработческая компания, десять программистов.
А. Б.: Это самый начальный сегмент, на который мы можем выйти здесь и сейчас.
С. П.: Отлично. Вот у меня команда — десять программистов. Зачем вы нам?
А. Б.: Вот пример: они, скажем, какую-нибудь JIRA используют?
С. П.: Отлично, пусть будет JIRA, используют JIRA.
А. Б.: Живой пример: ребята из Parallels, — может быть, там структура общая или аналогичная, — использовали там всю жизнь JIRA, которая хостится у них на серверах, она жутко кастомизируемая и т. д.
С. П.: Из Parallels?
А. Б.: Я просто пример привожу живой.
С. П.: Я про них читал в журнале просто, о`кей.
Д. Ф.: Да ладно! В каком?
С. П.: «Мир ПК».
А. Б.: Вот есть большая компания, в которой используется JIRA. Сначала — про большую. Соответственно, у большой компании есть ресурс, отдел внутренней разработки, который ее «затачивает» очень сильно. Если после этого люди приходят в маленькую компанию и приносят с собой понимание, как нужно строить процессы, а у маленькой компании средств на эту JIRA нет и ей приходится покупать «облачную» JIRA, у людей понимание и привычка строить процесс, автоматизировать есть, а что-то сделать они уже не могут, потому что JIRA в «облаке» не «затачивается». С помощью нашей платформы ребята взяли и первый аддон за час сделали реально, который под их понимание процесса подходит.
Д. Ф.: Но это не очень частная ситуация?
С. П.: Нет, это вполне реальная ситуация. Действительно такая проблема есть. Я, единственное, тогда не до конца понимаю, что в «облаке» можно «заточить», чтобы… Вот маленькая команда, да? Пусть не JIRA — или JIRA, «облачная» система для менеджмента, реквайрмента и прочего. Они хотят ее поменять, чтобы из нее, скажем, репорты было удобно получать, или workflow сменить.
А. Б.: Да, можно, например…
С. П.: Что они будут делать? Просто одно дело — работать со своей инсталляцией, ты там просто код меняешь, а другое дело… Вы что, позволяете код поменять провайдеру или как?
А. Б.: Вот. Это важная часть про технологию. Код «облачного» сервиса, по сути, из двух частей состоит — на сервере и на front-end. У всех современных сервисов на front-end уже достаточно сильная логика. И изначальное предположение было, что, меняя код на front-end, то, что загружается в браузере, уже доступно клиенту для изменения… Было предположение, что, меняя только этот код, можно достаточно сильно поменять и добавить функционал, достаточно сильно «заточить» продукт. И оно подтвердилось. Реально, когда загружается «облачный» сервис в браузер пользователя, то, внедряясь в этот код, который загружен, можно очень много разных вещей сделать. Можно в workflow устроить дополнительные шаги, проверки какие-то дополнительные. Можно в интерфейс встроить вызовы другого сервиса, добавить дополнительные поля. В общем, все, о чем крупные вендоры типа IQMatics или Salesforce пишут: дополнительные поля, проверки, встроить вызовы вашего сервиса с вашего сервера, — можно сделать.
С. П.: О’кей, я понял. Код аддона где живет, откуда он?
А. Б.: Код аддона живет у нас на сервере, в «облаке». То есть, если говорить buzzwords, то это PaaS — такая «облачная» система для разработки. А клиент, наш клиент — это расширение к браузеру, одно на всех.
С. П.: Ага, то есть я должен поставить ваше расширение…
А. Б.: К браузеру, да.
С. П.: А каким образом это расширение определит, что это мне нужен аддон, а не, скажем, Сергею?
А. Б.: Да, и вы заходите на наш сайт, выбираете нужные вам аддоны и включаете их. Включаете и затем начинаете работать так: вы зашли на…
С. П.: Подожди, получается, что у вас центральный каталог аддонов и, прежде чем я начну пользоваться своей JIRA, я должен к вам на сайт зайти, залогиниться и сказать, что мне — для JIRA аддон.
А. Б.: Да, да.
С. П.: Но получается тогда, что для всех, для моей компании и для его компании, JIRA-аддон будет одинаковый, нет?
А. Б.: Вы себе включили один аддон, Сергей себе включил другой аддон. Аддоны в списке разные. Мало того, там есть аддоны, которые выложены в публичный доступ, а вы можете создать сами себе, он будет виден только вашей команде, и, соответственно, включать его сможете только вы. А в будущем, поскольку это все достаточно хорошо интегрируется с существующей инфраструктурой…
С. П.: А кто этот аддон сделал, я сам? Это же мне нужна кастомизация.
А. Б.: Да, первый вариант, наш начальный сегмент: веб-контора разработчиков может сама под себя сделать, как обычно и делаются аддоны к JIRA, ко всем DevTools. Они сами под себя делают. Если говорить про бизнес, у бизнес-компании, которая торговлей занимается или небольшим производством, часто нет возможности самим такое сделать, а бывает, кстати, что есть. Если нет, они в этом случае передают это фрилансерам, подрядчикам каким-то.
С. П.: Если мы говорим о DevTools, то это, наверное, все-таки люди будут делать сами. Потому что, во-первых, специфика работы, а во-вторых, это рабочий инструмент.
А. Б.: Да, но это в случае, если люди хотят, как сказать… Если это использует контора разработчиков для себя, то да. А если это использует… Вот у нас сейчас основное количество пользователей — российский сервис «МойСклад», это бэк-офис для электронной коммерции, для торговли. Первые аддоны, пробные, на которых мы обкатывали, что будут платить, мы им сами делали. Потом те из них, кто технически что-то способен сделать, сделали сами, потом начали обращаться…
С. П.: А что они меняли? Чтобы тоже было понятно, чтобы на примере каком-то.
А. Б.: Да, пример: там сейчас работает интернет-магазин, который доставляет товары по России своими экспедиторами, и у менеджера там задача стандартная такая: когда он принимает заказ, ему нужно назначить экспедитора, кто куда поедет. Ему для этого приходится делать одно и то же: зайти в карточку заказа, посмотреть, в какой город, вернее, скопировать адрес, зайти в «Яндекс.Карты», вставить свой адрес, вставить этот, нажать кнопку «Получить карту» и, соответственно, прикинуть дальше, кто туда поедет, видя другое расписание. Ребята сделали это все так, что работает следующим образом: заходишь в карточку товара, видишь маршрут сразу, то есть прямо встроены туда «Яндекс.Карты». Там достаточно сложный back-end, причем хранение данных у нас реализовано кастомное. Вот один из примеров, который сильно сокращает время как раз в самый пиковый момент — в момент первоначальной обработки заказа.
С. П.: А код, соответственно, они должны на ваш сервер загрузить.
А. Б.: Да.
С. П.: А этот код в конечном итоге все-таки на клиентской стороне выполняется, да?
А. Б.: Да.
С. П.: В браузере?
А. Б.: Да.
С. П.: Это JavaScript?
А. Б.: Да, это JavaScript.
С. П.: И платящий здесь человек — это как раз эта компания, которая…
А. Б.: …которая использует аддоны. Здесь суть в следующем…
С. П.: То есть, если я «девелоплю» сам для себя, я плачу за использование?.. Есть просто некая несправедливость: я там работал, еще и деньги кому-то плачу.
А. Б.: Если вы «девелопите», вы как девелопер за это не платите. А дальше происходит следующее…
С. П.: А как пользователь?
А. Б.: А как пользователь вы платите. То есть, если в компании из десяти человек один аддон создал и компания хочет, чтобы этот аддон использовала только она, то она, соответственно, платит. Мы ей даем платформу частной разработки, как какая-нибудь Apprenda и прочие, но только конкретно для аддонов.
С. П.: Частная разработка? То есть там есть какое-то IDE — Integrated Development Environment?
А. Б.: Да, автоматически IDE подхватывается. Есть режим локальной разработки, когда весь код хранится локально, расширение его подхватывает и тут же в браузере это видно.
С. П.: То есть я могу просто расширению сказать: а сейчас бери с локального диска. Когда разрабатываю, отрабатываюсь, а потом вам просто публикую.
А. Б.: Публикуете, да. Это на Salesforce так.
С. П.: О’кей. А расширение для каких браузеров у вас?
А. Б.: Оно сейчас сделано только для Google Chrome. И причина очень простая: пока нет причин масштабироваться на другие. Это вопрос чисто горизонтального масштабирования.
С. П.: Почему нет? У Google Chrome сколько — 40%?
А. Б.: Google Chrome вообще сейчас самый популярный, а для наших ранних последователей…
С. П.: Но у него меньше 50%, тем не менее.
А. Б.: Да, меньше 50%. А сейчас просто нет задачи с 200 тыс. до 500 тыс. пользователей увеличить. Сейчас пока есть задача раскачать, а раскачивается она лучше всего как раз на тех людях, которые Google Chrome пользуются.
С. П.: Почему?
А. Б.: Потому что это как раз либо разработчики, либо более или менее технически продвинутые люди, которым эта тема интересна.

И у нас есть факты, когда у неразработческих контор, того же «МоегоСклада», несколько сотрудников на Google Chrome сидит, несколько — на Firefox. Они, чтобы использовать очень простой аддон, все переходят на Google Chrome, если конкретно для работы. Эта проблема у них даже не встает. Мы думали, что мы будем терпеть требования «Сделайте для Firefox!» и говорить: «Мы пока не будем для вас делать». А оказалось, что пока даже люди переключаются.

С. П.: Нет, я не про Firefox. Есть определенные люди с Internet Explorer, есть люди с Safari. Я пользуюсь Safari, например. Мне Google Chrome не очень нравится. Они и с NSA сотрудничают.
А. Б.: А здесь важен момент какой? Что сейчас вся эта тема нужна в первую очередь на рабочее место, то есть это не людям, которые ходят…
С. П.: О’кей, я понял,
А. Б.: Понятно, это рабочий инструмент.
С. П.: То есть требования от компании могут быть.
А. Б.: Мало того, Google Chrome наиболее продвинутый.
С. П.: А что вы дальше не пошли? Если вы уж так сделали, засунули бы вы в это же «облако» и этот браузер ваш, Google Chrome, с вашим расширением, а человеку бы просто дали туда заходить и кнопки нажимать?
А. Б.: А в этом проблемы какой-то нет у людей пока. Мы пляшем только, решая какую-то конкретную проблему, которая есть здесь и сейчас.
С. П.: О’кей, хорошо. Нет, просто тогда проблема браузера исчезает, понимаете? То есть, если у вас браузер на ваших же серверах, у вас же все равно есть сервера и инфраструктура?
А. Б.: Да, да. Но сейчас это «облачный» сервер, там с Heroku без проблем, а браузер класть нужно уже на другой уровень. Но здесь какой ключевой момент есть? При выходе на крупных клиентов у них возникают всегда требования по интеграции с их инфраструктурой, типа с Active Directory и пр. И, например, Google Chrome замечательно это умеет делать. Так что, когда компания решила для своего колл-центра на 200 человек выкатить какое-то расширение, чтобы нельзя было не через него работать, это будет делаться в одну кнопку, и это действительно по-другому не обойдешь. То есть админ включил, это всем выкатилось, все работают, даже не думая, что там что-то можно изменить. Это если работать так, нормально интегрироваться. Когда браузер в «облаке», это уже сложнее, и нам придется под всех свои какие-то версии браузеров поддерживать.
С. П.: Не-не-не. Вы не поняли.
А. Б.: Может быть.
С. П.: Я имею в виду, вы поставили свой Google Chrome в нужной вам версии, с нужным вам расширением в «облако», а человек использует Safari, чтобы просто видеть это. То есть это существенно проще.
А. Б.: Да, я вас понял. Это проще для человека, это решает проблему «не хочу или не могу переключаться с одного браузера на другой», но мы пока объективно с этой проблемой не сталкивались.
С. П.: Ну, понятно.
А. Б.: Когда мы с ней столкнемся, мы будем решать, как ее обойти.
С. П.: О’кей. Так, ну, теперь понятно. А какой вопрос-то у вас был?
Д. Ф.: Я минут десять назад перестал понимать, что вы говорите, в принципе.
А. Б.: Вопрос по итогам первого общения с крупными интеграторами. Они говорят, что им нужны истории успеха, референс-кейсы какие-то. Это во-первых. А во-вторых, более крутой и продвинутый продукт. Как раз всякие интеграции с инфраструктурой и прочее, определенный механизм надежности. И из этого мы поняли, как туда дойти поэтапно, на каждом этапе уже зарабатывая и получая прибыль. Но есть ли способ перепрыгнуть?
С. П.: Но есть ли способ попасть туда раньше.
А. Б.: Да.
С. П.: А зачем вам эти интеграторы? То есть деньги вам платят люди из небольших или средних бизнесов.
А. Б.: Но это наш начальный сегмент. Мы понимаем, что на начальном уровне у нас есть предположение, определенным образом обкатанное, что можно продавать по цене примерно 1,5-2,0$ за рабочее место в месяц как платформу. Потому что над ней надо еще что-то надстроить, и за это дополнительно придется платить. А крупным компаниям можно продавать по гораздо более существенной цене. Но там это идет в стандартном формате: интегратор и консалтер ее перепродает по существенной цене, а дальше от него зависит, какую он сверху маржу сделает, сколько кастомизаций и т. д. И там ценник для компании может быть, скажем, 10$ за человека. И когда продается на тысячу компаний, это гораздо большие деньги.
Д. Ф.: Все банально, в общем-то.
Сергей Топоров: Но тут же вопрос доверия к тебе возникает очень сильно.
Д. Ф.: У кого, у тебя?
С. Т.: У интегратора и у меня, в частности.

Если ты пришел к интегратору и говоришь: «Вот, ребята, у нас пять клиентов, мы стартап, у нас три человека, вы не хотите ли в „Сибнефть“ какое-нибудь „облачное“ решение наше поставить? Но не факт, что мы не закроемся через три месяца…» И вы как дальше поддерживать весь этот вопрос будете?

Наверное, хак есть: жениться на дочери кого-нибудь из «Газпрома» и заставить это...
А. Б.: Уже не получится.
Д. Ф.: Уже поздняк.
С. Т.: Но таким прямым методом, наверное…
С. П.: Все дочери кончились?
Д. Ф.: Нет, я надеюсь на другое, потому что Антон женат уже.
А. Б.: Я уже знаю, с кем мне строить жизнь, да.
С. П.: Понятно.
А. Б.: Наверное, да. Из этого следует, что нужно им показать, что у нас все хорошо с будущим.
С. Т.: Как минимум что вы действительно не закроетесь. Без этого-то точно никакого прохода выше…
А. Б.: Да, да. Поэтому, исходя из того, что ты сказал, мы вроде ничего не упускаем. Действительно, нужно расти постепенно.
С. П.: Нет, ситуация очень простая. Тут хака никакого нет. Тут может быть то, что называется share lag, то есть, может, случайно повезет, какие-то люди захотят и поверят. Потому что вопросы «закроются — не закроются» существуют, но есть методы их решения. Скажем, source code и вся инфраструктура — ее можно слить, положить в Escrow, для того чтобы в случае банкротства компания типа «Сургутнефтегаза» получила весь код и могла с ним что-то делать. Но тем не менее там есть такая проблема, что, когда имеешь дело с большим клиентом, в котором работают тысячи и десятки тысяч человек, sales cycle становится намного дольше с такими решениями. То есть типичный sales cycle для работы, скажем, с провайдерами, телекомом, — это годы. В случае стартапа, когда через два месяца надо думать, поднимать или не поднимать инвестиции, — это бесконечность. Нельзя заниматься год тем, чтобы обивать пороги. Поэтому, наверное, действительно нет смысла сейчас как-то очень много усилий прилагать, пытаясь продать «слону» то, что есть сегодня. Работайте с теми людьми, которые быстро принимают решения. Это хороший, в общем-то, сегмент — SMB. Они, возможно, не много платят, но если они действительно видят в этом какую-то пользу для себя, они будут платить очень долго. И Heroku — хороший пример проекта, который так развивался. Для своих основателей он однозначно был очень успешным в конечном итоге.
А. Б.: Согласен.
Д. Ф.: А лайфхака нет никакого, к сожалению.
А. Б.: Нет, это не к сожалению, это даже скорее к успокоению.
С. П.: Чудеса бывают, но проблема в том, что не с нами.
А. Б.: О’кей. Какие-нибудь просто мнения?
Д. Ф.: Мне хочется услышать фидбек Сергея. А то уже 15 минут слушает, как и я, с открытым ртом, что происходит.
С. Т.: На самом деле еще интересный момент. Когда мы говорили о кейсах SMB, которые не разработческие, которые до конца не понимают, как я, как компания, которая логистикой занимается, вообще понятия не имею о том, что как разрабатывают. Я взял заказал фрилансеру. Я хочу что? Чтобы он мне решение выкатил и я дальше не парился. Он мне говорит: «Я выкатываю тебе решение, еще ты платишь 3$ в месяц». То есть такой кейс нормальный в твоем понимании? И зачем фрилансеру, допустим, не готовое решение самому поставить, не своих десять часов разработки — и 3$ потом тебе будут уходить, а не ему, а 300 часов доработать самостоятельно этот большой плагин, решающий эту задачу, и клиенту впарить ее в десять раз дороже и все деньги себе получить?
А. Б.: Тут интересный ключевой момент — это про «в десять раз дороже». Реально получается так, что если это делать с нуля, то затраты где-то в десять раз больше, причем на решение одних и тех же задач, если много плагинов делать. И клиент за это не готов платить. А если делать с нашей помощью, то затрат гораздо меньше, и уже начинают стыковаться и клиент, и запросы фрилансера.
С. П.: Я согласен на самом деле с этим, потому что, особенно если говорить о мелком бизнесе, в десять раз больше — это уже тысячи долларов. Для небольшого бизнеса это психологически непросто.
С. Т.: И второй момент еще: Антон говорил, что какой-то фрилансер или еще кто-то, кто сделал уже плагин под компанию, дальше если не оплачивает, тот падает в какой-то общий стор, который могут дальше все использовать. Правильно я понял в теории?
А. Б.: Есть разные варианты. Если не оплачивается?
С. Т.: Ну да. Ты говорил, что если кто-то не платит, то компания в одном случае может у себя полностью оставлять этот плагин, в другом случае он идет всем в доступ и т. д.
А. Б.: Нет, есть изначально просто разные варианты. Можно делать плагины и публиковать их, и ими будут пользоваться другие. И те, кто пользуется, все равно платят не за конкретный плагин, а за платформу в целом. То есть они могут пять, могут десять использовать, а платят одно и то же. Это первое, это в случае опубликованного. В случае когда этот плагин, аддон делается для компании для частного использования, никуда больше не вылезает, она пока платит, она может использовать. Перестала платить — у нее просто недоступно стало. Начала платить — опять имеет возможность им пользоваться. Это внутри достаточно тривиально все решается, да.
С. Т.: А ты думаешь, эти аддоны, которые для общего пользования, насколько популярны будут? У вас изначально посыл был, что каждая компания хочет кастомизировать под себя, то есть под свои бизнес-процессы. А тут получается, что есть некий бизнес-процесс, который всем вроде и нужен, раз это в общем доступе, но сама компания-производитель этого решения почему-то не включает в свои процессы.
А. Б.: Тут есть интересный момент. Во-первых, то, что нужнее всего компании, — это, как правило, то, что нужно часто ей… Или, короче, очень сложно найти кого-то, кому еще это нужно. Там достаточно сильные кастомизации, которые из десяти шагов делают один или два. Кнопка «Сделать мне хорошо». А с другой стороны, много потребностей, которые есть у ряда клиентов, одни и те же, но их все равно вендор делать не будет, потому что это слишком небольшая часть клиентов либо это усложняет продукт в использовании, в поддержке и т. д. И мы не заставляем компании обязательно выкладывать в открытый доступ. Просто, как правило, по крайней мере, разработчики любят, чтобы их труд использовало максимально большее количество людей. И те, кто кастомизирует DevTools, точно готовы все это дело выкладывать.
С. П.: А если считать, что не обязательно компания, которая использует, является той компанией, что разрабатывает, разработчики как деньги получают за свой труд? Им с этих 3$ что-то достается?
А. Б.: Разработчики в такой модели получают как фрилансеры: они один раз сделали — им заплатили.
С. П.: Это, я думаю, будет обидно людям.
А. Б.: А тут, знаете, есть какой момент: мы в любом случае хотим прийти к варианту, когда еще развивается то, что можно назвать таким AppStore.
С. П.: Ну да.
А. Б.: Когда сделал и получаешь со многих. И мы на самом деле с этого начинали. Поэтому мы первый аддон продавали сами. Просто мы что поняли? Что на начальном этапе, когда есть проблема курицы и яйца, когда нет еще ни большой базы пользователей, нет базы разработчиков, эту тему раскрутить сложно. Мы пока не можем сказать разработчику, что мы его продуктовые риски решаем: мол, ты с помощью нас угадаешь, что надо сделать, и получишь большую базу.
С. П.: Я понимаю.
А. Б.: Но мы к этому придем.
С. П.: Это понятно, потому что сейчас пытаться завлечь разработчиков будет тяжело. Но если им начать платить сразу по модели revenue share за то, что они что-то сделали, наверное, их это сделает лояльными. Нет?
А. Б.: Вообще, сейчас, на первом этапе, лучше, чтобы были разработчики, которые делают для себя и лояльны за счет того, что они свои проблемы решают и плодами их труда кто-то пользуется. И на этом уровне все равно все будет бесплатно, такой уровень бета-версии. Платить бизнесы начнут тогда, когда они, скажем, либо что-то захотят сделать чисто для себя, либо начнут использовать больше какого-то порогового значения аддоны, скажем начиная с двух. И тогда они не конкретному разработчику… Для разработчика не очевидно, ему должны платить или нет.
С. П.: О’кей, понятно. А такой вопрос: а как вендоры относятся? Ну, тот же «МойСклад» рад?
А. Б.: Да, это очень важный вопрос. Мы вообще изначально… «МойСклад», грубо говоря, рад, если коротко. Они изначально дали нам доступ в их комьюнити писать. Мы, соответственно, там выбрали идеи, которые как тестовые [предполагалось] сделать. Сделали. Люди начали этим активно пользоваться. Потом произошел следующий интересный момент: мы начали за это дело брать деньги, люди начали платить, а кто-то не стал платить, а начал возмущаться, почему «МойСклад» у себя эту фишку не сделает бесплатной. Там конкретно довольно типовая на самом деле функция. Там раскрашивание строк таблицы документов в соответствии со статусами, чтобы быстро ориентироваться в ней можно было. И «МойСклад» в итоге сделал такое, и Аскар нас сразу предупреждал: «Если я решу, что что-то будет нужно сделать…» Он это сделал, и большая часть пользователей все равно осталась нашей пользоваться, потому что…
С. П.: У вас красивей цвета?
А. Б.: Нет, потому что, как сказать, не красивее цвета, а, например, вендору приходится все время на компромиссы идти. Он делает так, что если эта фишка уже есть, то чтобы она кому-то была полезна в целом, не мешала.
С. П.: О’кей, понятно.
А. Б.: И он сделал ее в ограниченном варианте: есть колоночка, в которой цветная метка. А мы сделали так, что она фигачит сразу на всю таблицу, и тем, кому это реально надо, это сильно жизнь упрощает.
С. П.: О’кей.
А. Б.: У них такой вариант всегда остается. И в итоге мы там же опубликовали, в сообществе, что мы партнеры, что обращайтесь к нам с кастомными заказами, и они кастомные запросы тоже на нас переводят. Потому что вендору эта тема выгодна.
С. П.: Да.
А. Б.: Это с него снимает кучу головняка. А у меня как у продакт-менеджера со стороны вендора доходило до того, что мне присылали кусочек кода JavaScript и CSS и говорили: «Вот это сюда вставьте и смотрите, как у вас все заиграет». Я понимаю, что это правильно, что это даже можно для всех выкатить, но у меня есть куча причин, почему мы это не сделаем в ближайшее время.
С. П.: Хотя бы потому, что это надо оттестировать.
А. Б.: Да, это в процесс нужно включить. Кроме того, есть куча пожеланий, и ты понимаешь, что этому человеку или бизнесу это очень надо, но в продукт в целом оно не полезет всем.
С. П.: Но, по идее, если «МойСклад» показывает, что вендор смотрит на это положительно, то, наверное, другие SaaS-вендоры тоже будут так относиться.
А. Б.: Да, и сейчас ситуация, когда мы с пулом SaaS-вендоров у нас проговорили, например «Мегапланом» или QSoft, их группа продуктов, с которыми общий язык нашли, то есть договорились, что мы можем дальше вместе делать. И у меня сейчас какая задача? У меня задача — допилить продукт, чтобы их программисты видели, что это серьезная тема. Потому что сейчас документация — один Google Doc, разросшийся и уже отстающий от жизни, не изначально понятный сайт. Мы просто готовим продукт к выходу на более широкий круг, да. А с ними понимание есть. Это особенно вендоры в наиболее конкурентных отраслях, типа CRM или управление задачами, проектами. Они сильнее всего понимают важность экосистемы вокруг их продукта, когда это позволяет их клиента «залончить» фактически, он не начинает прыгать между похожими сервисами в поисках конкретных функций.
С. П.: Конечно.
С. Т.: В 37signals сходи, которые как раз отказываются кастомизировать принципиально.
А. Б.: А знаешь, это один из примеров.

Мы просто для продвижения сделаем аддон для 37signals.

Они пытались такую штуку сделать изнутри, тоже некую платформу по изменению их интерфейса, и это очень убого получается, потому что со стороны вендора это сложная штука. У них в определенные места что-то можно встроить, и не все подряд, и, в общем, это плохо задачу решает. Но такие примеры есть. Мы сделаем аддон и в их список аддонов, я думаю, встанем. Это один из вариантов продвижения. Другой — на венчурных инвесторов. Может, для тебя пример характерный: с CrunchBase наверняка вы работаете как бесплатной базой стартапов. Мы, например, регулярно там что-то ищем, есть мой коллега, который регулярно по определенному срезу проводит выборки, смотрит, что изменилось, и он по-всякому этот CrunchBase шерстит. Ему инструментов не хватает, чтобы какие-то сохраненные запросы поиска делать или теги на них навешивать свои и т. д. Это вообще наша тема. Поэтому один из аддонов, который мы сделаем просто для инвесторов, будет в CrunchBase. Поэтому у нас в целом накоплено, что надо делать, и сейчас мы этим очень активно начинаем заниматься с новыми разработчиками.
Д. Ф.: Я думаю, мы лайфхак не нашли, но, по-моему, неплохо поговорили. Поэтому я предлагаю, может быть, тогда уже в кулуары вынести, если вдруг у кого-то остались вопросы. Потому что у нас программа, к сожалению, не резиновая, и приходится говорить о том, что она завершена. Спасибо большое, что вы были с нами! Мне кажется, что был очень интересный разговор. Половину из вещей я не понял, совсем даже, о чем была речь. Но мне показалось, что все остались довольны беседой более или менее. Спасибо большое, смотрите нас дальше!
А. Б.: Спасибо!