Не кодеры, а инженеры: как работает сервис ценой в $3 млрд с украинскими разработчиками

Calendly — американский стартап с украинскими разработчиками — в январе 2021 года оценили в $3 млрд (по этой оценке он привлек инвестиции в $350 млн). Он разрабатывает приложение – электронный календарь. Управляющий директор работающей над Calendly компании Railsware Сергей Королев в подкасте Product&Growth Show рассказал, как устроена эта работа — почему в компании нанимают инженеров, а не кодеров, и как эти инженеры потом работают в парах. Мы записали его основные мысли.

Сидели в квартире и думали, как заработать

Управляющий директор Railsware Сергей Королев

Railsware на рынке уже 14 лет, а начинали мы как компания «гаражного типа». Без инвестиций, но с большим желанием создавать продукты. Сидели в квартире и думали, как заработать на их создание. Сначала решили заняться консалтингом, что в результате принесло хорошие плоды: наш аутсорсинг превратился в хороший сервис consultancy, где мы разрабатываем продукты для стартапов.

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

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

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

У нас небольшая компания — порядка 100 человек. Мы решили сфокусироваться на создании продукта, контактировали с продуктовыми компаниями в США, перенимали опыт и подходы к работе.

В аутсорсинге продукт не взлетел бы

Calendly — это SaaS-приложение, которое работает по модели freemium. С его помощью можно быстро управлять свободными промежутками в календаре: другие пользователи могут назначать вам встречи и сохранять информацию в свой календарь Google или Microsoft Outlook.

Этот продукт мы создали с нуля, сейчас этот бизнес оценивается в $3 млрд. Продукт прекрасно показывает подход к созданию продукта в рамках consultancy-модели. Если бы фаундер — Топ Авотон — пошел в аутсорсинговую компанию, ему бы просто дали инженеров и продукт не взлетел бы.

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

Calendly

Клиент скандалил, говорил, что разорвет сотрудничество, если не сделаем как он говорит. Но у нас есть принцип: мы не делаем то, что клиент хочет, мы делаем то, что клиенту нужно. Бюджет был относительно небольшой, до $100 тысяч, риск был невелик, но мы в любой ситуации придерживаемся принципов, которые проповедуем.

Мы помогли Топу создать первый минимально жизнеспособный продукт и запустить. И он «выстрелил». Фактически продукт без всякого маркетинга с вложениями $500 тысяч стал популярным и генерировал миллионную выручку. Он продавал сам себя. Потому что продукт достаточно вирусный. Например, я присылаю тебе ссылку на ивент из Calendly, ты думаешь: «классный удобный продукт» — и тоже начинаешь им пользоваться.

Продукт начал терять в качестве, все начало рассыпаться

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

Второй «горб» начался, когда на фаундера начал давить инвестор. Говорил: «Собирай свою команду. Внешний сервис — это хорошо, но должна быть core-команда». Топ попробовал выполнить требование, мы даже помогли ему нанять своего СТО, но все опять пошло наперекосяк, и он снова вернулся к нам. С тех пор мы плотно работаем вместе, хотя у него уже есть своя команда. Топ ценит наше сотрудничество, он даже предлагал нам часть компании, чтобы мы сделали ему какие-то фичи. Но мы просто предложили сделать это в долг.

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

Продукт был запущен, потому что мы допустили нормальный факап

Mailtrap и Coupler — часть крыла Railsware, два продукта, которые мы полностью разрабатываем. Mailtrap на рынке достаточно долго, запущен лет семь назад, и был создан, потому что мы допустили нормальный факап: во время тестирования имейлов на стейджинге мы выслали целую пачку — 20 тысяч тестовых — реальным юзерам. Это могло нанести урон бизнесу. Мы подумали, что было бы здорово сделать фальшивый smtp-сервер, который охватывает весь исходящий smtp-трафик с тестовых серверов, чтобы такие ошибки не повторялись ни у нас, ни у других компаний.

Mailtrap

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

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

Нанимаем не кодеров, а инженеров

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

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

Почему так? Первые полгода любая команда может разрабатывать продукт, ровно до тех пор, пока не появляются «макароны» (запутанный код — прим.), пока не начнется усложнение системы и появляется необходимость структурировать код, данные, когда приходится думать, какие индексы создавать в базе данных, а какие – не стоит, как оптимизировать потоки данных. Для кодеров это становится очень сложно, и они переходят в другую компанию.

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

Мы разрабатывали свой процесс рекрутмента

Чтобы найти подходящих нам специалистов, мы разрабатывали свой процесс найма. Например, приходят на собеседование бизнес-аналитики, продакты. Ты им говоришь: «Я продакт-оунер, хочу построить такой кусочек продукта. Делайте, что хотите, но соберите требования с клиента». Тут и происходит коллапс. Люди в Google Docs пишут какие-то обрывки фраз для клиента, но это вообще не работает! Я знаю подходы, как инетрвьюировать, вытягивать знания, структурировать, формировать. А люди этого не знают.

Мы разочаровались. Год назад попробовали перезапустить процесс, снова попробовать нанять продактов, и пришли к тому же. Мы верим в продакта, который имеет технический бэкграунд, может сам написать SQL, знает, как с UX работать, понимает маркетинг — такой себе «осьминог». Таких специалистов сложно найти.

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

80–90% решений принимается коллегиально

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

Кроме того, все в компании взаимодействуют между собой горизонтально, а не так, что СТО спустил указание менеджеру, а тот — дальше по вертикальной иерархии. Когда вырабатываем стратегию компании, работаем над фичей, мы всегда в паре садимся и работаем. Не сказать, что у нас все идеально и гладко, но 80–90% решений принимается коллегиально. Нет такого, что кто-то проталкивает свое решение, потому что так захотелось. Сначала нужно успешно «продать» свою идею команде.