Злые марсиане: путь от двух человек в кафе до офисов в Нью-Йорке, Сан-Франциско, Москве и Осаке

Поговорили с командой разработчиков Evil Martians про создание распределенной международной команды практически с нуля; инженерную «прокачку» стартапов; выход в Японию и о том, как зарабатывать на open source.

Навигация

• Распределенная команда с первого дня основания компании
• Как молодой компании без офиса получить крупного клиента
• Почему выгоднее работать со стартапами, чем с Fortune 500
• Как сервисной компании работать над собственными продуктами
• Commercial Open Source Software
  
• Почему решили открыть офис в Осаке для экспансии в Азии
• Особенности Японии и японского языка в Ruby

Буквально перед пандемией команда разработчиков «Злые марсиане» открыла свой четвертый офис — в японской Осаке. Поговорил с двумя марсианами — одним из основателей и CTO Ярославом Маркиным и Алексеем Ивановым — фронтендером и руководителем офиса в Японии.

Расскажите, что такое Evil Martians сегодня?

Злые марсиане занимаются разработкой интернет-продуктов для технологических стартапов и состоявшихся компаний и развитием собственных open source-продуктов. Мы разрабатываем, улучшаем и распространяем альтернативные и OSS-технологии. Если вы сегодня выходили в интернет, наверняка пользовались сайтом или продуктом, который построен с помощью наших проектов.

Для клиентов мы эффективны на стадии пивота (поиска работающей бизнес-модели) и агрессивного роста. Мы работаем с 2006 года. У нас полностью распределенная команда — но с офисами в Нью-Йорке, Сан-Франциско, Москве и Осаке. Open source и инженерная культура — определяющие черты команды.

Могу ошибаться, но кажется, что Evil Martians были распределенной командой с самого основания. С какими сложностями приходилось сталкиваться по мере роста распределенной команды?

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

Как таковых проблем именно с распределенностью не так много — в первую очередь, потому что мы всегда работали именно так: распределенно и асинхронно.

Действительно, у многих предпринимателей при попытке перехода на распределенную работу полностью ломаются паттерны поведения и контроля: люди пытаются поставить на компьютеры сотрудников программное обеспечение-шпион, или полностью контролировать присутствие на бесконечных звонках, которые в итоге превращаются в полный аналог open office.

Мы с самого начала учились делегировать и нанимали только тех людей, которые способны отлично сделать работу без микроменеджмента и умеют грамотно коммуницировать внутри команды.

Мое принципиальное мнение — офисная работа маскирует недостатки организации — как в целом, так и личной организации конкретного сотрудника — а удаленная работа может прекрасно показать, чего стоит сотрудник без постоянного контроля сверху и ложной уверенности «вижу в офисе — значит работает».

Когда вы начинали, полностью распределенные аутсорс-команды не были так популярны. Вам удалось получить очень сильных клиентов — не было ли у них опасений насчет того, что у компании нет централизованного офиса. Как работали с этими возражениями?

Уточним понятия: под аутсорсом (и аутстаффингом) обычно понимают команды или компании, которым можно отдать не ключевую часть продукта, чтобы снизить стоимости поддержки. К Марсианам — как к команде консультантов, разработчиков заказных приложений — чаще обращаются за разработкой целиком или ключевой части для того, чтобы как можно быстрее вырасти.

Начинающие сервисные компании сталкиваются с рядом мифов: якобы, большие компании не работают с индивидуальными предпринимателями, не работают с распределенными командами, для построения продаж обязательно нужны опытные люди в отрасли с толстой адресной книжкой… За многие годы мы так не смогли подтвердить эти мифы, хотя начинали командой из двух человек без офиса — работали в кафе.

Причина, по которой к нам обращались и обращаются предприниматели — прямые рекомендации от других предпринимателей и венчурных инвесторов, опыт — как коммерческий, так и open source, выступления и рассказы о наших проектах.

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

Впрочем, идиллия о полностью виртуальной команде без офиса все же разбивается о суровые законы: компании так или иначе нужен офис. Просто наши офисы для встреч, общения, брейнштормов — посещение полностью опциональное.

А как у вас происходит поиск и отбор клиентов? Проекты на стадии поиска работающей бизнес-модели имеют множество рисков. Кажется, что контракт с компанией из Fortune 500 сулит более привлекательнее перспективы за счет последующей поддержки.

Клиенты к нам, в основном, приходят по рекомендациям. А вот отбор — это уже интереснее. Нужно сказать, что с некоторыми категориями клиентов мы в принципе не работаем — это либо неэтичный бизнес, либо проект на стадии голой идеи, без должного опыта у фаундера или представления о том, как делать бизнес.

Дальше мы фокусируемся либо на стартапах с подтвержденным финансированием на стадиях пивота или роста, либо на состоявшихся компаниях, которые хотят сделать «внутренний» стартап.

У обеих «категорий» есть свои особенности: действительно, у «чистых» стартапов больше неопределенности, но и наше «плечо» больше: мы можем сформировать техническую и продуктовую культуру, непосредственно общаться со всей продуктовой командой и ключевыми пользователями, словом, полностью сделать стартап как продукт на самой его увлекательной стадии. Zero to hero — как раз про такой случай.

Большие, состоявшиеся компании куда более стабильны, цепочка принятия решений в них может быть сложнее; но, как правило, мы работаем с пассионариями внутри таких компаний — продуктовыми менеджерами и специалистами, которым хочется сделать свою компанию еще лучше и добиться потрясающих результатов.

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

И, кстати, это позволяет нам избежать сложной корпоративной политики больших компаний — всех этих долгих согласований и процессов эскалации задач.

Еще вопрос про стартапы на стадии роста. Помимо технической реализации, какую еще дополнительную ценность даете командам на стадии роста? Вы участники известных истории роста — Rocketbank, Groupon, OnboardIQ. Помогаете ли командам с продуктовой экспертизой, стратегией, маркетингом?

Техническая реализация — лишь часть того, что мы даем стартапам, независимо от их стадии.

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

Такой цикл повторяется постоянно. Не похоже на всего лишь техническую реализацию.

Но для многих стартапов мы сотрудничаем исключительно по технической составляющей — как правило, у них уже есть продуктовые менеджеры, технический директор, свои дизайнеры.

Мы помогаем с реализацией и программированием, развертыванием и администрированием, оптимизацией, технической культурой и обучением сотрудников. А часто получается так, что мы приходим к клиенту техническими консультантами, но становимся продуктовой командой или ее незаменимой частью.

Наверное, в истории стартапа часто возникает момент, когда становится эффективнее содержать свою команду, чем делегировать разработку сервисной компании. Как происходит передача разработки в таком случае?

После многих лет работы с классными стартапами и большими компаниями мы точно знаем, на каких стадиях стартапа наши услуги нужнее всего (а то и вовсе незаменимы) и в чем наша ценность.

На стадии поиска бизнес-модели — быстро делать итерации продукта, не теряя в качестве кода, скорости разработки и поддерживаемости, когда нанять инженеров в только что возникший стартап сложно или некому (кто будет оценивать инженеров? как понять, что все пошло не так?), а результат нужен срочно.

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

Поэтому вопрос «Марсиане или своя команда» у заказчика не стоит. И Марсиане, и команда. Мы считаем себя частью команды, работаем как часть команды, помогаем нанимать, интервьюировать и обучать сотрудников, от инженеров-джуниоров до технических директоров. Наши образовательные курсы Brainwashing начались как раз с потребности разом дать «левел ап» инженерам нескольких наших заказчиков.

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

Тут нет перетягивания каната, нет конфликта с заказчиком — мы с самого начала работы понимаем цель заказчика и когда сотрудничество с нами максимально выгодно.

Конечно, и на стадии post-growth мы сохраняем отношения: образовательные курсы, короткие презентации по приложению или новым технологиям, ускорение кода или инфраструктуры, DevOps-поддержка инфраструктуры или создание спин-оффов.

Как сервисной распределенной команде работать над внутренними продуктами? Наверняка, помогая стартапам, вы часто вынашиваете идею своего проекта. Под внутренними проектами подразумеваю не open source, а например, Amplifr. Сложно ли сервисной команде поддерживать свой SaaS-продукт?

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

Стиль работы не меняется — асинхронное-по-умолчанию общение, ответственность и проактивность каждого члена команды, высокие требования к документированию и культуре разработки. Каждый инженер в команде, как правило, работает полное время лишь над одним проектом (если не оговорено иное) — для фокусирования и качества. Поэтому вопрос совмещения и переключения внимания не стоит.

Amplifr («Амплифер») — наш продукт для публикаций и аналитики в социальных сетях, им пользуются крупные рекламные и SMM-агентства, популярные СМИ и многие другие компании. В самом начале над ним работала марсианская команда, но у него уже давно есть собственная. Конечно, мы продолжаем делиться опытом и помогать по мере возможности.

Все новые марсианские продукты относятся к интересной области, которую сейчас называют COSS (Commercial Open Source Software, коммерческий опенсорс), или Open Core.

Это не стартапы-сервисы, а программные продукты для софтверных и интернет-компаний — в первую очередь, разработчиков и администраторов — основанные на открытом исходном коде. Коммерческая часть, как правило, сводится к платной поддержке, созданию решений под заказчика, или к продаже расширенной, платной версии с дополнительными возможностями.

У Марсиан это, в первую очередь, imgproxy, AnyCable, Astrograph, Logux. У них есть открытая версия, у некоторых есть и коммерческая, с расширенной функциональностью. Для всех мы предоставляем возможность коммерческой поддержки и внедрений, которыми мы занимаемся как для крупных онлайн-сервисов, так и для небольших стартапов.

Расскажите, как вышли на рынок Японии? Почему вы выбрали именно Осаку для регионального офиса в Японии, а не Токио?

В компании, которая началась с проектов на языке программирования Ruby, автор которого — японец Юкихиро Мацумото, увлечение Японией неудивительно. Сразу несколько марсиан серьезно увлечены японской культурой: серьезно учат язык (с экзаменами), путешествуют по стране, выступают на японских конференциях.

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

При экспансии на новый рынок важнее выбрать ключевую страну, чтобы начать работу и знакомство с рынком. Выбор конкретного города в ней менее важен. Тем более, что у нас распределенная команда, и чаще всего мы знакомимся и начинаем работать с заказчиками удаленно.

Поэтому мы исследовали рынок и нашли три кластера стартапов в Японии — Токио, Кансай и Фукуока. Мы планировали часто участвовать в мероприятиях этих регионов. Осака находится в Кансае, примерно посередине между Токио и Фукуокой, поэтому отсюда можно быстро ездить и туда, и туда. Отсюда же удобно и покорять Азию — Гонконг, Сингапур, Южную Корею, ведь рядом с Осакой есть международный аэропорт, в отличие от Фукуоки.

Наконец, нужен был город, где удобно работать и жить, так что выбор пал на не самый большой и дорогой для проживания мегаполис. Помогли еще личные обстоятельства: супруга нашего ключевого сотрудника в Японии — Алексея — получила работу в Осакском университете: она преподает японскую культуру.

Как думаете, есть ли какой-то японские особенности в Ruby, может, какие-то параллели с японским языком или культурой?

В целом нет — Ruby сам по себе не вызывает ассоциации с чем-то японским, а если ты не знаешь, что он родом из Японии, то сам никогда и не догадаешься. Возможно, это связано с тем, что его автор Юкихиро Мацумото вдохновлялся международными языками программирования — Smalltalk, в частности. По его словам, он хотел создать язык «более мощный, чем Perl, и более объектно-ориентированный, чем Python».

Так что в Ruby максимум есть пара японских названий компонентов где-то глубоко под капотом. А вот сторонние библиотеки для Ruby чаще обычного называются по-японски с транслитерацией на английский язык, даже если их создатели — не японцы. Тут каноничный пример — очень известная библиотека Nokogiri («пила» с японского) для работы с XML-данными и слоганом «XML как жестокость — если не решит ваших проблем, значит вы недостаточно много его используете». Но и так как на Ruby много пишут в самой Японии (и не только для веба), то и библиотек, созданных японцами, тоже больше обычного, а для них японские названия, наверное, чуть более ожидаемы.

Интересное решение относительно выбора места для азиатского офиса. Я обычно замечал региональные отделения в Сингапуре и Гонконге, а Японию обычно все как-то обособленно рассматривали. С какими трудностями сталкивается иностранная IT-компания на рынке Японии?

У Марсиан есть клиенты по всему миру. Мы работали и работаем с компаниями в США, России, странах Европы и Южной Америки, Японии, и имеем входящие запросы на разработку из еще большего количества стран, включая Японию, Сингапур и Гонконг. Локальный офис сильно помогает находиться примерно в одном часовом поясе с клиентами из этих стран и иметь возможность хотя бы время от времени проводить личные встречи. Кроме того, хорошая практика — первое время работать над проектом бок о бок с заказчиком — например, прямо в его офисе, чтобы лучше познакомиться и наладить отношения. Работать с потенциальными клиентами в Азии из России и США довольно сложно как из-за разницы в часовых поясах, так и из-за времени и стоимости авиаперелетов. Япония в этом смысле подходит гораздо лучше — перелеты ближе и дешевле, а часовые пояса близки.

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

Но тут случился COVID-19, и большинство этих мероприятий было отменено. Тем не менее, сейчас мы работаем с японским клиентом, который пришел по рекомендации.

Как строится работа с японскими клиентами? Пришлось ли в команду нанимать человека с японским?

Японского в нашей жизни и правда стало много. Дело даже не языке для взаимодействия в процессе работы — у нас есть люди со знанием японского уровня N1 (advanced) в штате, они помогают с переговорами и текущими коммуникациями. Тексты договоров, соглашения о неразглашении и прочие документы тоже нужно составлять на японском.

Пока получается справляться своими силами, в единичных случаях привлекаем внешних юридических консультантов. Но если количество клиентов и договоров вырастет, будем думать о поиске людей в команду.

Злые марсиане хорошо знакомы по всему миру как разработчики множества полезных для девелоперов продуктов open source и гуру в Ruby on Rails, Go и других языках. Экспансия в другие страны, тем более в такую сложную, как Япония — это еще один повод гордиться русскими инженерными практиками.

Я пишу про работу над цифровыми продуктами в Азии в свой ламповый канал в телеграмме «Мобильная Азия» и на vc.ru. В основном освещаю технологии и бизнес, и иногда беру такие интервью.

#разработка #продукты