Хабрахабр

Как нанимать людей в огромную компанию с непопулярным стеком. Разговор с Wrike

Спросишь, зачем его взяли, скажут, что просто изучили из любопытства, понравилось и решили поэкспериментировать, потому что устали от вечных Java/. Увидеть новый и пока мало кому известный язык программирования в маленьком стартапе или пет-проекте у друзей — дело обыденное. Net/JS на работе.

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

Они не закрыли глаза на недостатки JavaScript и даже не выбрали компромисс, вроде Flow или TypeScript — а пошли совсем радикальным путем. У Wrike, где около 400 разработчиков, другой подход. Переписали фронт на язык, который тогда вряд ли знала и тысяча человек, и, кажется, до сих пор абсолютно в себе уверены.

82. Wrike занял почетное третье место среди medium-компаний в рейтинге лучших работодателей в ИТ «Моего круга» со средней оценкой 4. В топ самых высоко оцениваемых качеств компании входят: социальный пакет, комфортные условия труда, отношения с коллегами, адекватная зарплата и профессиональный рост.

Потом он начал развивать бизнес в Америке, в Кремниевой долине. — Wrike основал Андрей Филев в 2007 году в Санкт-Петербурге. Тогда это была совершенно другая компания, а сейчас мы сильно выросли.

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

Это было 12 лет назад, и можно сказать, что мы приняли участие в формировании рынка подобных work management-систем. Мы начинали с простых вещей, но постепенно продукт стал расти. Сейчас Wrike используют свыше 18 000 компаний по всему миру.

— А та аутсорсинговая компания до сих пор существует?

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

— Там до сих пор им пользуются?

Да, до сих пор.

Что такое Wrike

Wrike — это платформа для управления проектами и совместной работы в очень широком смысле: от личного to-do листа вплоть до системы, которая подходит для огромных компаний.

Дополнения Wrike помогают управлять загруженностью команды в режиме реального времени или проводить сложные многоканальные маркетинговые кампании. Внутри можно создавать проекты с множеством задач и подзадач, настраивать отчеты для сбора данных, выводить диаграммы Ганта, отслеживать задачи в календаре, редактировать их одновременно с другими участниками. Есть расширения, например, для Adobe Creative Cloud. Есть API для интеграции в другие инструменты. Оно позволяет просматривать и комментировать файлы не выходя из системы.

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

— Расфокусировка на всех и для всего не делает хуже отдельные части?

Например, не хотим делать исключительно баг-трекинговые системы для разработчиков типа Jira. — Мы сознательно не идём в узкопрофильные ниши. Нам интересно делать универсальный продукт. Мы не хотим делать софт только для программистов или только для дизайнеров. При этом мы понимаем, что есть сильно специализированные кейсы, которые мы не охватываем.

Хотя мы, разрабатывая Wrike, используем его как систему для задач и баг-трекер. Но это и не наша цель — понравиться всем, или полностью занять нишу ИТ.

— То есть, можно взять баг-трекер быстрее, мессенджер быстрее, но это будет пять разных инструментов и синхронизироваться между ними сложно.

Atlassian с одной стороны. — Но тогда и конкурировать приходится со всеми. Slack как мессенджер — с другой.

— Да, сейчас только ленивый не разрабатывают системы управления проектами и продуктами.

— Но компаний, которые конкурировали бы с нами по всем пунктам, на самом деле, не так много.

— Atlassian разве не такой?

Например, для дизайнеров Jira слишком сложная.
Ее очень сложно кастомизировать. — Он больше заточен на ИТ-рынок. Мы же стараемся делать так, чтобы ты зашел на сайт, взял бесплатный аккаунт и все — с первого дня можешь использовать без проблем. Есть даже профессия — Jira Setup Manager.

— Но вы же говорите, что тоже тесно работаете с клиентами и тоже направляете менеджеров которые, налаживают процессы.

Есть менеджеры, которые помогут настроить Wrike уже под готовые процессы. Да, у нас есть команда Customer Success и Deployment-менеджеров, а также целая система туров, гайдов, электронных книг и всякой документации. Иногда сразу со многими (например, записывая вебинары). Иногда они работают с крупными клиентами one-to-one. Даже если человек зарегистрировал триал и не разобрался в продукте, у него будет возможность пообщаться вживую с кем-то из райкеров и понять, как что работает.

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

— Случалось, что с кем-то из больших клиентов было очень сложно?

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

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

У них покупатели заказывают запчасти. Или автомобильная компания Coil [название изменено]. Не будешь же каждому владельцу Coil делать свою учетную запись. Давать этим людям аккаунты Wrike — так себе идея. Но компания очень хотела, чтобы была удобная возможность работать с клиентами.

Но менеджеры поняли, что она улучшит продукт в целом. Мы, конечно, не сказали, что прямо сейчас для них сделаем такую фичу. Так появились «внешние формы запросов», для людей, у которых нет аккаунта Wrike.

— Получилось, вы делали для Coil [название изменено], а подошло и всем остальным?

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

Внутренняя структура Wrike

Компания разделена на команды по фичам — примерно по 10 человек. Мы работаем по Scrum. Такой состав полнофункционален и может сделать фичу от и до. Они разного состава, но в каждой есть бэкенд, фронтенд, скрам-мастер, QA, автоматизатор QA, UX-дизайнер, продакт оунер, продуктовый аналитик (аналитики иногда бывают на несколько команд).

Есть внутренние команды, которые делают фреймворки, компоненты, дизайн-киты, занимаются переходом с одной версии языка программирования на другую.

Например, это SysOps, которые занимаются серверной инфраструктурой, и DevOps — они занимаются деплоем и доставкой продукта. Некоторые команды являются общими для всей компании. Релизы у нас от одного до 3 раз в сутки.

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

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

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

— А в каком офисе что делается?

В Питере у нас 400 человек, в Воронеже — 40. — В Питере и Воронеже инженерные r’n’d офисы. В этом году откроется офис в Праге. Есть офисы в Сан-Хосе, Сан-Диего. В январе этого года открылся офис в Мельбурне, в Австралии. Недавно расширили офис в Дублине.

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

— Все работают в офисах или вы открыты к удаленке?

Нам хочется, чтобы люди были рядом и контактировали между собой. — Удаленные скрам-команды — это очень сложно. В департаментах, которые могут предполагать удаленную работу (например, Customer Support), мы ребят не сильно ограничиваем.

Сейчас много о ней говорится, в англоязычных твиттерах постоянно обсуждают эту тему. — Удаленка в разработке — спорный момент. На наш взгляд, «против» больше. Есть «за» и «против». Мне, как менеджеру команды, было бы тяжело обеспечивать продуктивность и общий дух, растить и коучить удаленных сотрудников.

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

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

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

Общение с саппортом происходит на английском. Раз в месяц есть митинги, на которых мы рассказываем обо всех изменениях в компании и финансовых показателях. Для тех, кто хочет подтянуть или выучить язык, такая возможность есть – у нас ведутся постоянные занятия с преподавателями, для сотрудников они бесплатные. Тикеты с багами клиентов тоже, конечно, на английском языке.

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

Может, конечно, у разработчиков не true British accent и нет Оксфорда за плечами, но изъясниться и прочесть что-нибудь они обычно могут.

Почему Dart лучше JavaScript и TypeScript

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

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

Иногда мы понимаем, что два года назад были глупее. Бывает, что-то падает. А как иначе? Но это естественно с точки зрения инженера.

— Поэтому есть внутренние команды, которые периодически занимаются переписыванием старых частей.

Садимся и рефакторим. — Да, я иногда говорю, что нам надо сесть и порефакторить, а то стрельнет так, что все отстрелит. Мешает архитектура — делаем архитектуру.

— Что у вас за стек?

База данных SQL. — На бэкенде Java. Когда-то давно у нас был JavaScript, но мы поняли, что он вообще не масштабируется и выбрали Dart. На фронтенде интересная штука.

— Что-что выбрали??

Да, это нормальная реакция. — Dart. Мы наверное самые главные евангелисты этого стека в России. Типизированный язык от Google, которому сейчас уже почти семь лет.

— Самые главные или единственные?

Гугл запустил Flutter — это такой мобильный фреймворк, написанный как раз на Dart. — Кстати, сейчас он активно развивается. Там уже около полутора тысяч человек. Есть Russian Dart Community, которое мы создали и поддерживаем. Конечно, по меркам JavaScript это не особо внушительно, но и немало.

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

Говорить «в мире», наверное, претенциозно, но, на самом деле, так и есть. — Так что мы сейчас на коне. Даже больше, чем у Google. DartUp — это самая большая конференция по Дарту в мире.

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

— Это все любопытно, но как работать на таком масштабном проекте, если не наймешь людей, нет ни библиотек, ни фреймворков.

Недавно мы взяли в команду человека, для которого Dart вообще был первым языком программирования. — Это заблуждение.

Это язык из разряда C# и Java — там все что нужно, встроено. — В Dart все есть. Там встроено даже больше, чем в некоторых двадцатилетних языках. И это вообще неправда, что там все пусто и катаются перекати поле. Библиотеки, инструменты, поддержка фреймворков — Angular там тоже есть.

Но проблема в том, что, когда люди пишут миллионы библиотек, получаются миллионы плохих библиотек. Конечно, нет инфраструктуры, как на JS. И, может, только сто нормальных.

А если библиотеки пишет Google, который использует Dart в AdWords и AdSense, то среднее качество гораздо выше.

То есть мы нанимаем разработчиков на C++, C#, Java, JavaScript — кого угодно. Прелесть языка в том, что он простой и Си-подобный. Естественно, на улице не найти дарт-разработчика. Мы не требуем знания Dart.

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

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

Те же JS-ники пришли с динамического языка на статический. — Но люди не начинают писать как на своем старом языке?

Но справедливый и честный. — Поэтому у нас процесс отбора не самый простой.

— Ок, почему язык хорош?

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

В нем более раннее обнаружение ошибок, которое позволяет даже не тестируя код понимать, работает он или нет. На Dart если что-то напишешь неправильно, сразу это поймешь.

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

Это JS и Dart. Сейчас на свете два языка, которые позволяют писать под все платформы —под мобильные, под бэкенд, под десктоп, под веб. А у Dart огромный плюс — типизация. У JS минусов известно сколько.

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

— Теперь не жалеете что, например, TypeScript не выбрали?

Я советую посмотреть доклад Виктора Логова из JetBrains на конференции HolyJS. — Не теперь, а в принципе не жалеем.

И после этого вообще нет желания его брать. Они делают поддержку TypeScript в своих продуктах, и он там просто разносит TS по полочкам, аргументированно. А давайте». Складывается ощущение, что фичи в нем появляются по принципу «Давайте вот это добавим?

Не может быть, что все идеально. — Чтобы я поверил, расскажите что плохо в Дарте?

Есть проблемы, но не с языком, а с Google. Запросто. У нас сейчас есть прямой канал с Google, мы состоим в ряде внутренних организаций, и они потихоньку отдают эти инструменты. Они внутри используют достаточно много инструментов, которые не шарят наружу.

Но это актуально только для нас, для очень большой кодовой базы.У маленьких проектов вообще проблем нет.

— После опыта с Dart вы не захотели Java заменить на Go?

Dart мы выбрали по определённым параметрам. — Зачем? Это было взвешенное решение.

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

Если в какой то момент поймём, что Go работает лучше, то попробуем. — Мы экспериментируем с разными технологиями.

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

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

Найм инженеров, а не знатоков языка

— Кем надо быть, чтобы к вам попасть?

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

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

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

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

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

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

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

— На собеседовании разработчик будет писать код?

— Да, я знаю, это сейчас очень обсуждаемо.

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

То есть если не React, ты не разберешься? Если человек говорит: «Я React-программист», — это уже звучит странно.

Они не требуют суперзнаний о предметной области. Мы стараемся давать задачи, которые сами делаем каждый день. Можем спросить: «Вот у тебя есть Jira и Wrike. Мы не спрашиваем, что такое замыкание в JS. Как ты синхронизируешь данные между ними?»

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

— Если пришел человек с гениальным инженерным мышлением и решил задачу так, что вам очень нравится, но у него нет «горящих глаз и вот этого всего», он попадет в компанию?

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

Почему, например, тяжело найти людей в банковскую и финансовую сферы? А из этого вытекает то, что человеку не все равно, что делать. Я не говорю за всех, но делать платежки для австралийского банка… Пусть там будет суперархитектура — спроси любого, и почти каждый тебе скажет «не хочу». Там бывает скучновато.

А у вас весело? — В банках скучно.

— Пока даже чересчур.

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

— Задачи между командами сильно отличаются?

Одна команда делает Gantt-чарт. — Специфика бывает совсем разная. Команда, которая делает одновременное редактирование задач, как в Google Документах — там и математика, и Dart на бэкенде. У них там Canvas, своя логика. От команды к команде стек один, но применение совершенно разное.

— Если человек говорит, что устал в своей команде и хочет что-то другое, получит ли он это от простого перехода?

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

Большая компания, 400 человек в офисе. — Как так получилось? Как они сдружились?

Про культуру тяжело говорить — это эфемерные вещи. — Это вопрос подбора и культуры. Во время подбора есть этап Cultural fit, когда мы смотрим, насколько человек подходит команде. Ты их чувствуешь, но описать словами не можешь.

Как вы определяете, подходит или нет? — Что там за критерий.

Один из них — кем вы себя видите через пять лет. — Есть ТОП-5 тупых вопросов на собеседовании. Например, какие у тебя цели, чего ты вообще хочешь? Он звучит не очень, но в другой формулировке полезен. И если человек может их сформулировать, это уже плюс.

— Если человек сказал, но вам не понравилось, чего он хочет?

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

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

— То есть плохо, если человек ничего не ответит?

Мы не поставим на нем крест. — Нет. Все люди чего-то хотят.

— Я просто пытаюсь понять, можно ли не пройти этот этап собеседования?

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

Wrike — это safe place. — Вот еще почему можно не пройти. Я могу брать на себя ответственность только если знаю, что я в безопасности. Тот же Google говорил, что один и самых ключевых критериев успешной команды — это психологическая безопасность.

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

— Людей надо критиковать, чтобы они учились?

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть