На «Мегамозге» в очередной раз «Советы основателя».
Разговор с Олегом Балбековым – генеральным директором компании Evrone и сооснователем сервиса Vexor.io получился интересным и длинным. Отчасти потому, что у Олега и его команды действительно обширный и глубокий опыт в разработке продуктов и проектов в сети, отчасти, потому что мы уже пересекались в рамках различных конференций, проводимых в Москве и не только.
Любая компания, занимающаяся заказной разработкой, «мечтает» однажды начать делать собственные продукты. У нас все достаточно тематично, то есть мы делаем проекты, используя основную технологию (для нас это «Ruby» и «Ruby On Rails»), мы проводим конференцию, посвященную данной технологии («RailsClub»), и мы делаем продукты для программистов, которые мы «выстрадали».
От редакции: если у вас есть желание принять участие в рубрике «Советы основателя», пишите нам на editor(at)megamozg.ru
Разговор с Олегом Балбековым – генеральным директором компании Evrone и сооснователем сервиса Vexor.io получился интересным и длинным. Отчасти потому, что у Олега и его команды действительно обширный и глубокий опыт в разработке продуктов и проектов в сети, отчасти, потому что мы уже пересекались в рамках различных конференций, проводимых в Москве и не только.
Любая компания, занимающаяся заказной разработкой, «мечтает» однажды начать делать собственные продукты. У нас все достаточно тематично, то есть мы делаем проекты, используя основную технологию (для нас это «Ruby» и «Ruby On Rails»), мы проводим конференцию, посвященную данной технологии («RailsClub»), и мы делаем продукты для программистов, которые мы «выстрадали».
В определенный момент мы просто осознали, что у нас появляется огромное количество внутренних проектов, которые помогают нам в разработке ПО, часть из которых постепенно начинает «отпочковываться» и формироваться в полноценные продукты. Таких продуктов у нас несколько: первая проба пера была в рамках проектов «Thinkwith.me» (система рисования тикетов для таск-менеджеров) и «Pulse.guru» (система мониторинга прогресса в разработке), после у нас параллельно запустились три проекта: Vexor.io, на который мы сейчас тратим много сил и времени, уделяя ему максимум возможного внимания, track2win.ru (сервис геймификации процессов разработки), и еще один продукт, который мы вот-вот выпустим на рынок: Teatro.io (облачные тестовые сервера для разработчиков).
Это и есть наша концепция: мы создаем ПО, мы делаем продукты, которые помогают нам в создании этого ПО, и мы поддерживаем конференции, которые помогают нам «прокачиваться» и развивать не только собственную разработку, но и сообщество разработчиков в целом
Vexor.io начинался как OpenSource-проект, а продуктом и коммерческим продуктом он стал в первую очередь тогда, когда преобразился в SaaS-решение. Любое из них требует инвестиций времени и сил, то есть оплаты тех ресурсов, которые были затрачены на его создание. И так как это Continuous Integration сервис, бесплатным он стать не может, так как каждый тест нагружает наши сервера, которые стоят денег.
Vexor.io хорош в первую очередь тем, что не ограничивает пользователя по выделенным ресурсам и умеет отдавать их быстро и в необходимом объеме с поминутной оплатой.
Ведь интенсивность разработки различается от проекта к проекту. Есть проекты с огромным количеством тестов, есть проекты с небольшим количеством тестов. Есть проекты с огромным количеством тестов и которым для тестирования нужно очень много ресурсов, но эти проекты уже не разрабатываются активно, и эти ресурсы нужны только 2 раза в месяц, когда в проект вносят багфиксы.
Представьте себе, что вечером каждой пятницы, примерно за 3 часа до конца рабочего дня, начинается огромный поток тестирования. Все хотят выложить свои фичи и пойти отдыхать.
Vexor как раз создавался для подобных задач, когда выделить ресурсы для тестирования нужно прямо сейчас, много и ровно на 10 минут.
И, с другой стороны, вы не тестируете по ночам и в воскресенье (по понятным причинам) и вам не придется платить за неиспользуемые мощности.
Стартапы — это хорошо и интересно, но мы на данном этапе не отказываемся от заказной разработки, так как это в первую очередь понятные и предсказуемые деньги. Собственные продукты, особенно на старте, непредсказуемы. А жить надо...
В Evrone, в 2012 — 2013 годах, «так сложилось», что из-под наших пальцев выходило в среднем по «стартапу» раз в 3 месяца. Ребята просто делали продукты, потому что им это нравилось. На выходных, фактически, ради удовольствия. Прикольно взять и «запилить» по-быстренькому SAAS-продукт, который даже оказывается полезен внутри компании. Таких продуктов у нас набралось с добрый десяток за все время существования Evrone.
В какой-то момент я остановил это. В первую очередь потому, что это трата времени, нервов и ресурсов. Я долго скептически или с юмором относился ко всем идеологиям типа «lean-startup», к тестировании идей, их валидировании, прототипировании продукта, валидировании рынка, предварительной проверкой бизнес-концепций и так далее. Мы всего этого не до конца понимали и делали и делали продукты в первую очередь потому, что умеем. Зачем проверять идеи? «Это нужно, наверное, тем, кто не умеет писать код», – думали мы. Тем самым стартаперам со смузи в коворкингах, которые только и умеют, что писать презенташки в кейноте.
В какой-то момент мы выросли и поняли, что больше мы так поступать не можем и не будем. Мы действительно начали тестировать продукты до того, как создаем их. Хватит экспериментировать для себя, нужно экспериментировать на рынке. С пониманием идеи, ее валидации, затем прототипировании, проверке конверсий, попытке первых продаж и так далее. И действительно, в современном рынке без всего этого просто невозможно сделать успешный продукт. Пустая трата денег на кодинг для удовольствия – прекратилась.
Кстати, побывав во ФРИИ, мы увидели огромное количество людей с абсолютно аналогичными проблемами. Люди делают продукт, но у них нет понимания ни внутренней экономики, которая должна «сходиться», у них нет понимания потребителя и того, почему он захочет платить за это деньги и т.д. При этом все ребята талантливые, с прямыми руками и хорошими навыками программирования. Это хороший опыт, в результате которого вы больше никогда не будете мотивировать себя одним только «это прикольно».
Все эти годы было много споров: что лучше? PHP или Ruby, языки/платформы/решения и так далее. Сейчас рынок изменился и все понимают, что лучше «то», что «лучше» подходит под данную конкретную задачу и позволяет её выполнить
Меня, к примеру, уже невозможно переубедить и заставить принять точку зрения иную от того, что Ruby On Rails – это идеальное средство для создания веб-ориентированных проектов, и в первую очередь MVP, где требуется иногда безболезненно менять направления разработки и т.д.
При этом, я соглашаюсь, что Ruby хорош не для всего. Функциональные языки программирования нас и меня лично сейчас интересуют даже больше, именно поэтому мы организуем новую конференцию fpconf.ru
Хорошо известны и широко используются такие практичные функциональные языки, как Erlang, Scala, Clojure. Стремительно набирает популярность когда-то исключительно академический Haskell. На этих языках пишутся критически важные компоненты высоконагруженных систем, всё, что должно работать надёжно, параллельно и быстро. Одним слово — эффективно.
И сообщество сейчас понимает, что одним языком программирования сыт не будешь. То есть сыт будешь, но задачу не решишь. Есть подходящее решение к каждой отдельной задачи. Поэтому FPconf сегодня собирает и привлекает даже большее внимание, так как аудитория и её профессионализм растёт.
На мой взгляд, если вы – компания, которая занимается продуктом и зарабатывает деньги, используя какую-то технологию, типа Ruby On Rails, то вы обязаны отдавать «обратно» часть дохода и своей энергии на развитие данной технологии и сообщества
Это те «основы», которыми мы живем в Evrone – поэтому мы делаем конференции, инвестируем в OpenSource-проекты, помогаем тематическим ресурсам и подкастам. Мы, кстати, очень благодарны компаниям, которые мыслят похожим образом. За время существования RailsClub у нас появилось много постоянных спонсоров и партнеров, которые помогают нам в организации мероприятия. Приятно знать, что в России есть компании, которым не все равно на развитие сообщества.
Текущей платформе, CloudPayments.ru, с которой мы работаем для финансовых транзакций, пришлось поменять собственную инфраструктуру и модель работы для того, чтобы мы смогли работать вместе (например, для рекурентного безакцептового списания нефиксированных средств с кредитных карт)
Казалось, делать международный стартап из России — самоубийство. Но сейчас мы с Vexor не ощущаем никаких проблем, которые мешают нам развиваться. Пока нет даже каких-либо «репутационных рисков», связанных со страной нашего происхождения. Инструмент есть инструмент, и если уровень качества и сервиса устраивает клиента, то он будет спокоен и переживать не будем. Да, мы не кричим о том, что мы из Москвы, которая в России, но и не скрываем этого факта.
Всякий раз, когда я общаюсь с друзьями на профессиональные темы, они крутят у виска и говорят: «Зачем тебе строить бизнес в России, открой оффшор и не парься», «Валите в Европу, вам тут нечего делать», «Вам не место в этой стране».
На самом деле у меня нет какой-либо принципиальной позиции, мол, хочу только в России, совсем нет. Мы совершенно не боимся «забраться на трактор» и свалить. В данный момент строительство бизнеса в России – это в первую очередь наше любопытство в поиске ответа на вопрос: «А можно ли сделать успешную международную компанию здесь, у нас, или нельзя?». И сталкиваясь с огромным количеством достаточно «странных» проблем, вроде российских бухгалтеров, отказывающихся работать с инвойсами, и продолжая русскими платежными системами, не работающими с сайтами на английском языке, мы понимаем, что это не так просто.
В целом, я думаю, что мне потребуется максимум месяц для того, чтобы «стать европейцем», зарегистрировать какой-нибудь оффшор и перестать иметь проблемы с Российской действительностью. Но нам сейчас действительно просто любопытно, и мы отвели себе пару месяцев для того, чтобы разобраться и понять детально, возможно ли строительство международного IT бизнеса «в этой стране» или пора валить.
Во время акселерации во ФРИИ мы в основном тестировали различные приемы и подходы к развитию нашего сервиса, различные гипотезы. Сейчас мы, конечно, уже понимаем, чего хотим, и активно двигаемся по направлению к собственным целям
Когда у тебя есть бизнес, в котором ты хорошо зарабатываешь и находишься в зоне комфорта, но также у тебя есть проекты, которые тебя волнуют, но находятся в состоянии неопределенной перспективы – ты можешь потратить 3 месяца в режиме полной концентрации над этой идеей (или продуктом) и спустя это время понять, «взлетает» или нет. ФРИИ помогает сделать в первую очередь это – сфокусироваться на продукте.
ФРИИ дало нам знания, инвестиции и «ускорение». Мы с Vexor.io действительно закрыли и белые пятна в собственных знаниях, и по-другому посмотрели на все происходящее.
Один из самых крутых инструментов ФРИИ – это «публичное порицание», когда раз в неделю я должен был отчитываться о собственных успехах перед коллегами по цеху. Которых, в отличие от широкой публики, сложно «обмануть» или «ввести в заблуждение», даже имея такую цель. Так или иначе, говоря о том, что ты делал целую неделю, ты не хочешь выглядеть идиотом, который бил баклуши. А цифры вообще не врут. Поэтому варианта попасть во ФРИИ и бездельничать — нет.
Программист не должен быть менеджером и не должен быть аналитиком. Но он не должен быть полностью замкнутым и должен быть в состоянии разговаривать с коллегами или клиентом
За время работы в индустрии я осознал, что существует два типа «рубистов», но, возможно, это применимо и ко всем разработчикам в целом. Они либо зациклены на себе и собственном внутреннем мирке, либо нет. Есть даже целые компании и команды таких, зацикленных, разработчиков. При этом люди не выходят в свет, не читают, не «опенсорсят» и совсем не ходят на конференции. В моей жизни было несколько эпизодов, когда, к примеру, к тебе приходит сотрудник, просидевший на одной позиции в банке, предположим, лет 5. Ruby-разработчик, уточним. И он обижается на тебя за то, что ты не берешь его на работу: «У меня 5 лет опыта!» – говорит он. Но, выясняется, что человек правил формы и ковырял RedMine, не слышал про три новых версии языка и т.д. Это очень грустно и очень плохо. Необходимо смотреть по сторонам, необходимо участвовать в OpenSource – это учит писать «правильный» код.
Между «нанимать долго» и «увольнять быстро» я выбираю нечто среднее. На самом деле, для себя я уже давно определил срок, который мне необходим для того, чтобы установить, что человек неподходящий — это 1 год. Этот срок выливается из практики и, возможно, это долго для такой небольшой структуры, как у нас, но так как и нанимаем мы не быстро, год – максимальный срок. За год можно выяснить все что угодно, от того, насколько ленив человек, какой он в общении и так далее. Слава Богу, у нас есть возможность нанимать только адекватных людей, так как мы заранее приблизительно знаем, кто и что из себя представляет. В первую очередь благодаря нашим конференциям и знаниям сообщества.
На собеседованиях я всегда спрашиваю: «Откуда вы знаете, что пишете код правильно?». Просидев 5 лет в банке, не участвуя в открытых проектах, не посещая конференции и не общаясь с коллегами – вы не сможете ответить на этот вопрос
Человек, который много читает, много общается, участвует в opensource-разработке и смотрит по сторонам, однажды сможет создать продукт, который взорвет мир.
От редакции: если у вас есть желание принять участие в рубрике «Советы основателя», пишите нам на editor(at)megamozg.ru
mckalech
Очень круто. Большинство студий и в плюс то не могут выйти, а тут люди жгут кучу времени на сторонние проекты и получают огромную отдачу от этого