На «Мегамозге» в очередной раз «Советы основателя».

Разговор с Олегом Балбековым – генеральным директором компании Evrone и сооснователем сервиса Vexor.io получился интересным и длинным. Отчасти потому, что у Олега и его команды действительно обширный и глубокий опыт в разработке продуктов и проектов в сети, отчасти, потому что мы уже пересекались в рамках различных конференций, проводимых в Москве и не только.

Любая компания занимающаяся заказной разработкой «мечтает» однажды начать делать собственные продукты. У нас все достаточно тематично, то есть мы делаем проекты используя основную технологию (для нас это «Ruby» и «Ruby On Rails»), мы проводим конференцию посвященную данной технологии («RailsClub») и мы делаем продукты для программистов, которые мы «выстрадали».

В определенный момент мы просто осознали, что у нас появляется огромное количество внутренних проектов которые помогают нам в разработке ПО, часть из которых, постепенно, начинают «отпочковываться» и формироваться в полноценные продукты. Таких продуктов у нас несколько: первая проба пера была в рамках проекта «Pulse.guru» (система мониторинга прогресса в разработке), после у нас параллельно запустились два проекта: Vexor.io, на который мы сейчас тратим много сил и времени, уделяя ему максимум возможного внимания, и еще один продукт, который мы вот-вот выпустим на рынок: Teatro, облачные тестовые сервера для разработчиков.

Это и есть наша концепция: мы создаем ПО, мы делаем продукты которые помогают нам в создании этого ПО и мы поддерживаем конференцию, которая помогает нам «прокачиваться» и развивать не только собственную разработку, но и других, дружественных нам, людей


Vexor.io начинался как OpenSource-проект, а продуктом и коммерческим продуктом он стал в первую очередь тогда, когда преобразился в SaaS-решение. Любое из них требует инвестиций времени и сил, то есть оплаты тех ресурсов, которые были затрачены на его создание. И так как это сервис «continuous»-тестирования, бесплатным он стать не может, так как каждый тест нагружает наши сервера, которые стоят денег.

Vexor.io хорош в первую очередь тем, что не ограничивает пользователя по выделенным ресурсам и умеет отдавать их в необходимом объеме с поминутной оплатой. И, хотя, мы прямой конкурент «TravisCI», именно в этом и заключается основное отличие нашего продукта.

Вечером каждой пятницы, примерно за 3 часа до конца рабочего дня по московскому времени, начинается огромный поток тестирования. И, с другой стороны, не делая тесты в воскресенье (по понятным причинам) вам не придется платить за неиспользуемые мощности.

Интенсивность разработки различается от проекта к проекту. Есть проекты с огромным количеством тестов, есть проекты с небольшим количеством тестов. Никакой разницы нет, если есть возможность сэкономить.

Во время акселерации во ФРИИ мы в основном тестировали различные приемы и подходы к развитию нашего сервиса, различные гипотезы. Сейчас мы, конечно, уже понимаем, чего хотим и активно двигаемся по направлению к собственным целям


Тестов у нас сейчас десятки тысяч, их количество активно растет, хотя «настоящих» пользователей активно использующих CI-сервисы сейчас немного в принципе, и у нас, и на рынке.

Но даже с учетом всего вышесказанного – мы не отказываемся от заказной разработки, так как это в первую очередь понятные и предсказуемые деньги. Собственные продукты, особенно на старте, непредсказуемы. А жить надо.

Примерно в 2012 году «так сложилось», что из под наших пальцев выходило в среднем по «стартапу» раз в 3 месяца. Ребята просто делали продукты, потому что им это нравилось. На выходных, фактически, ради удовольствия. Прикольно взять и «запилить» по-быстренькому SAAS-продукт, который даже оказывается полезен внутри компании. Таких продуктов у нас набралось с добрый десяток за все время существования Evrone.

В какой-то момент я остановил это. В первую очередь потому, что это трата времени, нервов и ресурсов. Я долго, скептически или с юмором, относился ко всем идеологиям типа «lean-startup», о тестировании идей, их валидировании, прототипировании продукта, валидировать рынок, проверять конверсии и так далее. Мы этого не делали и делали продукты в первую очередь потому, что умеем. Зачем это нужно? «Это нужно, наверное, тем кто не умеет писать код» – думал я. Тем самым стартаперам со смуззи в коворкингах. Это им нужно делать генераторы лэндингов и лить на него «директовый» траффик. В конце прошлого года мы поняли, что больше мы так поступать не можем и не будем. И мы действительно начнем тестировать продукты до того, как создаем их. Хватит экспериментировать для себя, нужно экспериментировать на рынке. С пониманием идеи, ее валидации, затем прототипировании, проверке конверсий, попытке первых продаж и так далее. И действительно в современном рынке без всего этого просто невозможно сделать успешный продукт.

Побывав во ФРИИ, мы увидели огромное количество людей с абсолютно аналогичными проблемами. Люди делают продукт, но у них нет понимания ни внутренней экономики, которая должна «сходится», у них нет понимания потребителя и того, почему он захочет платить за это деньги и т.д. При этом все ребята талантливые, с прямыми руками и хорошими навыками программирования. Это хороший опыт, в результате которого вы больше никогда не будете мотивировать себя одним только «это прикольно».

Все эти годы было много споров: что лучше? PHP или Ruby, языки/платформы/решения и так далее. Сейчас рынок изменился и все понимают, что лучше «то», что «лучше» подходит под данную конкретную задачу и позволяет её выполнить в срок. Меня, к примеру, уже невозможно переубедить и заставить принять точкую зрения иную от того, что Ruby On Rails это идеальное средство для создания веб-ориентированных проектов, и в первую очередь MVP, где требуется менять направления разработки и т.д.

При этом, я соглашаюсь, что Ruby хорош не для всего. Функциональные языки программирования нас и меня лично сейчас интересуют даже больше, именно поэтому мы организуем секцию „FP-conf“ в рамках „РИТфест“. Erlang, Scala, Closure и прочее-прочее-прочее, включая академические решения, вроде Haskell. Именно на этих языках сегодня пишутся наиболее высоконагруженные компоненты высоконагруженных систем: правильно, параллельно, быстро. Одним слово — эффективно.

И сообщество сейчас понимает, что одним языком программирования сыт не будешь. То есть сыт будешь, но задачу не решишь. Есть подходящее решение к каждой отдельной задаче. Несмотря на всё это RailsClub растет, и количество посетителей конференции также увеличивается год от года. FPconf сегодня собирает и привлекает даже большее внимание, так как аудитория и её профессионализм растёт.

Забавно, но люди приходят на конференции с уже достаточно взрослыми детьми. Я думаю, это яркий показатель


На мой взгляд, если вы – компания, которая занимается продуктом и зарабатывает собственные деньги используя какую-то технологию, типа Ruby On Rails, то вы обязаны отдавать «обратно» часть этого дохода на развитие и технологии и сообщества. Это те «основы», которыми мы живем в Evrone – поэтому мы делаем конференции и инвестируем в OpenSource-проекты. Культивируем и пропагандируем, так как только таким образом можно развить сообщество и технологии. Ваша энергия выльется в увеличение вашей будущей прибыли, улучшение мировой инфраструктуры.

Сейчас мы с Vexor не ощущаем никаких проблем, которые мешают нам развиваться. Нет даже репутационных рисков, связанных со страной нашего происхождения. Инструмент – есть инструмент, и если уровень качества и сервиса устраивает клиента, то он будет спокоен и переживать не будем. Да, мы не кричим о том, что мы из Москвы, которая в России, но и не скрываем этого факта. Но, вообще, строительство бизнеса в России – это в первую очередь наше любопытство в поиске ответа на вопрос: «А можно ли сделать успешную международную компанию здесь, у нас, или нельзя?» И сталкиваясь с огромным количеством достаточно „странных» проблем, вроде российских бухгалтеров работающих со счетами их спецификой и продолжая русскими платежными системами не работающими с сайтами на английском языке, мы понимаем, что это не так просто.

Текущей платформе, с которой мы работаем для финансовых транзакций, пришлось поменять собственную инфраструктуру и модель работы для того, чтобы мы смогли работать вместе (например по безакцептному списанию средств с кредитных карт)


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

Важен грамотный баланс между расходованием средств инвесторов и реализацией всех планов. Расширяться нужно под заработок. Нельзя нанимать 20 человек на задачу, которую могут сделать двое, только потому что 20 человек сделают это быстрее. В то же время если ваши задачи действительно соответствуют загрузке 20 высококлассных специалистов, выполнение задач которыми приносит вам деньги, это оправданно.

ФРИИ дало нам знания, инвестиции и «ускорение». Это действительно так и это чистая правда. Но важно то, что этим можно пользоваться только в ситуации, если ты умеешь этим пользоваться. Даже деньгами нужно уметь пользоваться, что, кстати, составляет проблему среди тех участников программы акселерации, которых я видел. Мы с Vexor.io действительно закрыли и белые пятна в собственных знаниях и по-другому посмотрели на все происходящее.

Когда у тебя есть бизнес, в котором ты хорошо зарабатываешь и находишься в зоне комфорта, но у тебя есть проекты (или не проекты, а идеи) с неясной перспективе – ты можешь потратить 3 месяца в режиме полной концентрации над этой идеей (или продуктом) и спустя это время понять, «взлетает» или нет. ФРИИ помогает сделать в первую очередь это – сфокусироваться и выяснить.

Ответственность в работе важна. И не только в рамках ФРИИ, хотя там она процветает в рамках «программы общественного порицания», когда раз в неделю я должен был отчитываться о собственных успехах перед «пацанами». Которых, в отличие от широкой публики, сложно «обмануть» или «ввести в заблуждение» даже имея такую цель. Это traction meeting, но так или иначе говоря о том, что ты делал целую неделю, ты не хочешь выглядеть идиотом, который бил баклуши. А цифры вообще не врут.

Между «нанимать долго» и «увольнять быстро» я выбираю нечто среднее. На самом деле для себя я уже давно определил срок, который мне необходим для того чтобы установить, что человек неподходящий — это 1 год. Этот срок выливается из практики и, возможно, это долго для такой небольшой структуры, как у нас, но так как и нанимаем мы не быстро, год – максимальный срок. За год можно выяснить все что угодно, от того, насколько ленив человек, какой он в общении и так далее. Слава богу у нас есть возможность нанимать только адекватных людей, так как мы заранее, приблизительно, знаем кто что из себя представляет. В первую очередь благодаря нашим конференциям и тому, что основная технология именно Ruby On Rails c широким и открытым сообществом.

Программист не должен быть менеджером и не должен быть аналитиком. Но он должен быть в состоянии разговаривать, и иногда — с клиентом. Это даже касается не абстрактной «современности», а использования определенных методологий, вроде Scrum


За время работы в индустрии я осознал, что существует два типа «рубистов», но возможно это применимо и ко всем разработчикам в целом. Они либо зациклены на себе и собственном внутреннем мирке, либо нет. Есть даже целые компании и команды таких, зацикленных, разработчиков. При этом люди не выходят в свет, не читают, не «опенсорсят» и совсем не ходят на конференции. В моей жизни было несколько эпизодов, когда, к примеру, к тебе приходит сотрудник просидевший на одной позиции в банке, предположим, лет 5. Ruby-разработчик, уточним. И он обижается на тебя за то, что ты не берешь его на работу: «У меня 5 лет опыта!» – говорит он. Но, выясняется, что человек правил формы и ковырял RedMine, не слышал про три новых версии языка и т.д. Это очень грустно и очень плохо. Необходимо смотреть по сторонам, необходимо участвовать в OpenSource – это учит писать «правильный» код.

На собеседованиях я всегда спрашиваю: «Откуда вы знаете, что пишете код правильно?». Просидев 5 лет в банке, не участвуя в открытых проектах, не посещая конференции и не общаясь с коллегами – вы не сможете ответить на этот вопрос


Человек, который много читает, много общается, участвует в opensource-разработке и смотрит по сторонам, однажды сможет создать продукт, который взорвет мир.

От редакции: если у вас есть желание принять участие в рубрике «Советы основателя», пишите нам на editor(at)megamozg.ru

Комментарии ()