Увидеть новый и пока мало кому известный язык программирования в маленьком стартапе или пет-проекте у друзей — дело обыденное. Спросишь, зачем его взяли, скажут, что просто изучили из любопытства, понравилось и решили поэкспериментировать, потому что устали от вечных Java/.Net/JS на работе.
Но если компания говорит о себе фразами в духе «международный бизнес», «офисы по всему миру», «культ продуктивности», «нам важен результат, а не процесс», «нам нужны горящие глаза и стремление развиваться» — обычно от них не ждешь сюрпризов. Некоторые даже вводят стоп-листы на новые технологии, пока те не наберут вес в индустрии. На вопросы о минусах инструментов уклончиво говорят: «главное люди, а не языки».
У Wrike, где около 400 разработчиков, другой подход. Они не закрыли глаза на недостатки JavaScript и даже не выбрали компромисс, вроде Flow или TypeScript — а пошли совсем радикальным путем. Переписали фронт на язык, который тогда вряд ли знала и тысяча человек, и, кажется, до сих пор абсолютно в себе уверены.
Wrike занял почетное третье место среди medium-компаний в рейтинге лучших работодателей в ИТ «Моего круга» со средней оценкой 4.82. В топ самых высоко оцениваемых качеств компании входят: социальный пакет, комфортные условия труда, отношения с коллегами, адекватная зарплата и профессиональный рост.
— Wrike основал Андрей Филев в 2007 году в Санкт-Петербурге. Потом он начал развивать бизнес в Америке, в Кремниевой долине. Тогда это была совершенно другая компания, а сейчас мы сильно выросли.
В начале у Андрея была аутсорсинговая компания. В ней начали искать софт, который позволил бы более эффективно работать — управлять временем и ресурсами. По-настоящему классного инструмента на тот момент не нашлось, и появилась идея создать свой. Тогда и родился Wrike.
Мы начинали с простых вещей, но постепенно продукт стал расти. Это было 12 лет назад, и можно сказать, что мы приняли участие в формировании рынка подобных work management-систем. Сейчас Wrike используют свыше 18 000 компаний по всему миру.
— А та аутсорсинговая компания до сих пор существует?
Да, называется Murano Software. Но она к нам не имеет отношения. Wrike — полноценная компания одного продукта, которая была экспериментом в рамках аутсорсинговой компании, но очень быстро взлетела и отделилась.
— Там до сих пор им пользуются?
Да, до сих пор.
Что такое Wrike
Wrike — это платформа для управления проектами и совместной работы в очень широком смысле: от личного to-do листа вплоть до системы, которая подходит для огромных компаний.
Внутри можно создавать проекты с множеством задач и подзадач, настраивать отчеты для сбора данных, выводить диаграммы Ганта, отслеживать задачи в календаре, редактировать их одновременно с другими участниками. Дополнения Wrike помогают управлять загруженностью команды в режиме реального времени или проводить сложные многоканальные маркетинговые кампании. Есть API для интеграции в другие инструменты. Есть расширения, например, для Adobe Creative Cloud. Оно позволяет просматривать и комментировать файлы не выходя из системы.
Wrike не стремится сделать акцент на определенной функции, индустрии или профессии. Он позиционируется, как универсальный инструмент для всего — вплоть до замены почтовой системы, мессенджера, базы знаний, баг-трекера и многого другого.
— Расфокусировка на всех и для всего не делает хуже отдельные части?
— Мы сознательно не идём в узкопрофильные ниши. Например, не хотим делать исключительно баг-трекинговые системы для разработчиков типа Jira. Мы не хотим делать софт только для ��рограммистов или только для дизайнеров. Нам интересно делать универсальный продукт. При этом мы понимаем, что есть сильно специализированные кейсы, которые мы не охватываем.
Но это и не наша цель — понравиться всем, или полностью занять нишу ИТ. Хотя мы, разрабатывая Wrike, используем его как систему для задач и баг-трекер.
— То есть, можно взять баг-трекер быстрее, мессенджер быстрее, но это будет пять разных инструментов и синхронизироваться между ними сложно.
— Но тогда и конкурировать приходится со всеми. Atlassian с одной стороны. Slack как мессенджер — с другой.
— Да, сейчас только ленивый не разрабатывают системы управления проектами и продуктами.
— Но компаний, которые конкурировали бы с нами по всем пунктам, на самом деле, не так много.
— Atlassian разве не такой?
— Он больше заточен на ИТ-рынок. Например, для дизайнеров Jira слишком сложная.
Ее очень сложно кастомизировать. Есть даже профессия — Jira Setup Manager. Мы же стараемся делать так, чтобы ты зашел на сайт, взял бесплатный аккаунт и все — с первого дня можешь использовать без проблем.
— Но вы же говорите, что тоже тесно работаете с клиентами и тоже направляете менеджеров которые, налаживают процессы.
Да, у нас есть команда Customer Success и Deployment-менеджеров, а также целая система туров, гайдов, электронных книг и всякой документации. Есть менеджеры, которые помогут настроить Wrike уже под готовые процессы. Иногда они работают с крупными клиентами one-to-one. Иногда сразу со многими (например, записывая вебинары). Даже если человек зарегистрировал триал и не разобрался в продукте, у него будет возможность пообщаться вживую с кем-то из райкеров и понять, как что работает.
— Вообще, внедрение продукта в компанию с тысячами пользователей — это та еще задача.
— Случалось, что с кем-то из больших клиентов было очень сложно?
Обычно чем больше компания, чем больше у нее рабочих процессов — тем тяжелее работать. Мы, конечно, не аутсорс. Не бывает такого, что приходит какой-то толстосум и говорит: «вот вам много денег, сделайте мне такую штуку». Наши продакт-менеджеры сами определяют пути развития продукта. Но бывают клиенты с интересными запросами.
В Airbnb, например, используют платформу в очень необычных кейсах. Каждая квартира и, каждый человек, который ее арендует— это отдельный проект в Wrike.
Или автомобильная компания Coil [название изменено]. У них покупатели заказывают запчасти. Давать этим людям аккаунты Wrike — так себе идея. Не будешь же каждому владельцу Coil делать свою учетную запись. Но компания очень хотела, чтобы была удобная возможность работать с клиентами.
Мы, конечно, не сказали, что прямо сейчас для них сделаем такую фичу. Но менеджеры поняли, что она улучшит продукт в целом. Так появились «внешние формы запросов», для людей, у которых нет аккаунта Wrike.
— Получилось, вы делали для Coil [название изменено], а подошло и всем остальным?
— Не совсем. Мы одновременно анализировали рынок и строили гипотезы — эта задача лежала в потенциальном роадмапе. Если бы был запрос, который совсем нам не подходит, мы бы не стали делать.
Внутренняя структура Wrike
Мы работаем по Scrum. Компания разделена на команды по фичам — примерно по 10 человек. Они разного состава, но в каждой есть бэкенд, фронтенд, скрам-мастер, QA, автоматизатор QA, UX-дизайнер, продакт оунер, продуктовый аналитик (аналитики иногда бывают на несколько команд). Такой состав полнофункционален и может сделать фичу от и до.
Есть внутренние команды, которые делают фреймворки, компоненты, дизайн-киты, занимаются переходом с одной версии языка программирования на другую.
Некоторые команды являются общими для всей компании. Например, это SysOps, которые занимаются серверной инфраструктурой, и DevOps — они занимаются деплоем и доставкой продукта. Релизы у нас от одного до 3 раз в сутки.
Еще частично используем уже известную всем структуру Spotify с гильдиями. Например, фронтенд, где состоят фронтендеры из всех команд. Есть фронтенд-лиды, которые занимаются менеджментом, архитектурой. И есть лиды гильдий.
Мы пока не дошли до того, чтобы выделять их из команд. Но вообще это логично и органично. Сейчас люди, обладая высокими техническими архитектурными навыками, находятся в инфраструктурных командах.
Wrike — это не совсем про бюрократизированную структуру. Но это не значит, что у нас творится хаос. Если человек делает то, что ему нравится, и делает это хорошо — то возможности для роста у него будут независимо от того, какую он занимает должность.
— А в каком офисе что делается?
— В Питере и Воронеже инженерные r’n’d офисы. В Питере у нас 400 человек, в Воронеже — 40. Есть офисы в Сан-Хосе, Сан-Диего. В этом году откроется офис в Праге. Недавно расширили офис в Дублине. В январе этого года открылся офис в Мельбурне, в Австралии.
— В американских офисах у нас отдел продаж, маркетинг, менеджеры (CSM). В Дублине тоже CSM и продажи. Есть еще команда аналитиков. В Петербурге — самый большой и объединяющий офис. Здесь у нас менеджеры по работе с клиентами, продакт-менеджеры, аналитики, дизайнеры, разработка и бэк-офис.
— Все работают в офисах или вы открыты к удаленке?
— Удаленные скрам-команды — это очень сложно. Нам хочется, чтобы люди были рядом и контактировали между собой. В департаментах, которые могут предполагать удаленную работу (например, Customer Support), мы ребят не сильно ограничиваем.
— Удаленка в разработке — спорный момент. Сейчас много о ней говорится, в англоязычных твиттерах постоянно обсуждают эту тему. Есть «за» и «против». На наш взгляд, «против» больше. Мне, как менеджеру команды, было бы тяжело обеспечивать продуктивность и общий дух, растить и коучить удаленных сотрудников.
У нас достаточно гибкий график, люди не сидят в офисе строго с десяти до шести. Если есть стендап, то будь добр — приди, а уже когда он пройдет и сколько будет длиться, команды выбирают сами. Если что-то случается, тоже без проблем — человек пишет, что работает из дома.
— Когда продукт международный, от разработчиков часто требуют хорошо знать английский, чтобы говорить с заказчиками.
— У нас нет заказчиков, мы же не аутсорс. Компания международная, и часть коммуникаций, действительно, ведется на английском, но это касается не всех. Для разработчиков в России у нас нет специального требования знать английский.
Раз в месяц есть митинги, на которых мы рассказываем обо всех изменениях в компании и финансовых показателях. Общение с саппортом происходит на английском. Тикеты с багами клиентов тоже, конечно, на английском языке. Для тех, кто хочет подтянуть или выучить язык, такая возможность есть – у нас ведутся постоянные занятия с преподавателями, для сотрудников они бесплатные.
Но мое мнение — если разработчик не вчера начал разрабатывать, он знает английский хотя бы на уровне чтения документации. Без языка ты даже не можешь погуглить ничего.
Может, конечно, у разработчиков не true British accent и нет Оксфорда за плечами, но изъясниться и прочесть что-нибудь они обычно могут.
Почему Dart лучше JavaScript и TypeScript
— Сейчас все это большая сложная система. Но она выросла из внутренней разработки очень давно и с тех пор много менялась. Из-за этого не осталось архитектурных просчетов, которые теперь мешают жить?
— Конечно, проект большой. У нас на бэкенде то ли полтора, то ли два миллиона строк кода на Java. На фронтенде тоже сопоставимо. Но я не знаю ни одного человека, который может спроектировать систему на пять лет вперед, и она будет развиваться не перестраиваясь.
Бывает, что-то падает. Иногда мы понимаем, что два года назад были глупее. Но это естественно с точки зрения инженера. А как иначе?
— Поэтому есть внутренние команды, которые периодически занимаются переписыванием старых частей.
— Да, я иногда говорю, что нам надо сесть и порефакторить, а то стрельнет так, что все отстрелит. Садимся и рефакторим. Мешает архитектура — делаем архитектуру.
— Что у вас за стек?
— На бэкенде Java. База данных SQL. На фронтенде интересная штука. Когда-то давно у нас был JavaScript, но мы поняли, что он вообще не масштабируется и выбрали Dart.
— Что-что выбрали??
— Dart. Да, это нормальная реакция. Типизированный язык от Google, которому сейчас уже почти семь лет. Мы наверное самые главные евангелисты этого стека в России.
— Самые главные или единственные?
— Кстати, сейчас он активно развивается. Гугл запустил Flutter — это такой мобильный фреймворк, написанный как раз на Dart. Есть Russian Dart Community, которое мы создали и поддерживаем. Там уже около полутора тысяч человек. Конечно, по меркам JavaScript это не особо внушительно, но и немало.
В декабре прошлого года мы организовали конференцию DartUp — был огромный зал и пришло много людей. И многие реально используют Dart в продакшене. Язык постепенно развивается, и это очень круто.
— Так что мы сейчас на коне. Говорить «в мире», наверное, претенциозно, но, на самом деле, так и есть. DartUp — это самая большая конференция по Дарту в мире. Даже больше, чем у Google.
— На конференции было около трехсот человек. Хотя еще два года назад казалось, что мы одни в поле воины.
— Это все любопытно, но как работать на таком масштабном проекте, если не наймешь людей, нет ни библиотек, ни фреймворков.
— Это заблуждение. Недавно мы взяли в команду человека, для которого Dart вообще был первым языком программирования.
— В Dart все есть. Это язык из разряда C# и Java — там все что нужно, встроено. И это вообще неправда, что там все пусто и катаются перекати поле. Там встроено даже больше, чем в некоторых двадцатилетних языках. Библиотеки, инструменты, поддержка фреймворков — Angular там тоже есть.
Конечно, нет инфраструктуры, как на JS. Но проблема в том, что, когда люди пишут миллионы библиотек, получаются миллионы плохих библиотек. И, может, только сто нормальных.
А если библиотеки пишет Google, который использует Dart в AdWords и AdSense, то среднее качество гораздо выше.
Прелесть языка в том, что он простой и Си-подобный. То есть мы нанимаем разработчиков на C++, C#, Java, JavaScript — кого угодно. Мы не требуем знания Dart. Естественно, на улице не найти дарт-разработчика.
В моей команде есть разработчик с опытом Си шарпа, дотнета. На фронте он никогда даже не писал. И он за пять дней запилил фичу. Потому что язык такой, как будто ты писал на нем всю жизнь.
По-хорошему, разработчики-инженеры пишут бизнес-логику, неважно на каком языке.
— Но люди не начинают писать как на своем старом языке? Те же JS-ники пришли с динамического языка на статический.
— Поэтому у нас процесс отбора не самый простой. Но справедливый и честный.
— Ок, почему язык хорош?
Я бы сказал он один из самых жестко типизированных, которые компилируются в JS. Когда мы года четыре назад сидели на фронтенде и нас было человек 8 — ты можешь хоть обмазаться всякими линтерами, правилами, всем на свете — а он все равно будет что-то пропускать. Нужна была статическая типизация, максимально строгая.
На Dart если что-то напишешь неправильно, сразу это поймешь. В нем более раннее обнаружение ошибок, которое позволяет даже не тестируя код понимать, работает он или нет.
Во встроенной библиотеке нет хаоса, когда одно обновилось, а другое отвалилось. Потому что вместе с языком поставляется SDK, который гарантирует, что после обновления все работает. Не нужно подключать миллион библиотек, чтобы получить потоки и стримы — все уже там.
Сейчас на свете два языка, которые позволяют писать под все платформы —под мобильные, под бэкенд, под десктоп, под веб. Это JS и Dart. У JS минусов известно сколько. А у Dart огромный плюс — типизация.
Поэтому остается только один жестко типизированный язык, который позволяет писать под все платформы с нормальным тулингом. Многие в пример приводят Kotlin, но для веба — это не очень.
— Теперь не жалеете что, например, TypeScript не выбрали?
— Не теперь, а в принципе не жалеем. Я советую посмотреть доклад Виктора Логова из JetBrains на конференции HolyJS [Вероятно, спикер перепутал имя, и речь шла о докладе Антона Лобова].
Они делают поддержку TypeScript в своих продуктах, и он там просто разносит TS по полочкам, аргументированно. И после этого вообще нет желания его брать. Складывается ощущение, что фичи в нем появляются по принципу «Давайте вот это добавим? А давайте».
— Чтобы я поверил, расскажите что плохо в Дарте? Не может быть, что все идеально.
Запросто. Есть проблемы, но не с языком, а с Google. Они внутри используют достаточно много инструментов, которые не шарят наружу. У нас сейчас есть прямой канал с Google, мы состоим в ряде внутренних организаций, и они потихоньку отдают эти инструменты.
Но это актуально только для нас, для очень большой кодовой базы.У маленьких проектов вообще проблем нет.
— После опыта с Dart вы не захотели Java заменить на Go?
— Зачем? Dart мы выбрали по определённым параметрам. Это было взвешенное решение.
— Один из наших спикеров говорит, что есть компании, которые переписывают все на новые технологии, а есть компании, которые зарабатывают деньги. Переписывание не должно быть самоцелью. Есть бизнес-задачи, и есть инструменты, которые должны их реализовывать.
— Мы экспериментируем с разными технологиями. Если в какой то момент поймём, что Go работает лучше, то попробуем.
На фронтенде мы идем в сторону независимых приложений. На бэкенде — монорепозиторий. В этом есть много плюсов, но есть и определенные минусы — об этом можно долго говорить. Мы смотрим в сторону микросервисной архитектуры, исходя из того, что будет полезно в наших условиях.
Микросервисная архитектура хорошо работает там, где мало связей. Если у тебя много связей, то микросервисы превращаются в боль. Серебряной пули нет. Для этого у нас есть целая команда, которая исследует, что лучше всего использовать в наших условиях.
Найм инженеров, а не знатоков языка
— Кем надо быть, чтобы к вам попасть?
— Мы берем людей, которые заинтересованы в том, что они делают. Это уже клише — про горящие глаза. Тем не менее, это важно. Даже если ты хороший разработчик, но тебе все равно, что пилить, лишь бы работать с десяти до шести и получать деньги — с большой вероятностью это нам не подойдет.
— Мы берем людей, которые хотят учиться, развиваться. Если считаешь, что уже всего достиг и теперь король мира — это тоже не наш вариант.
— Так как у нас достаточно хороший канал фидбека от разработчика к бизнесу и обратно, то подход «нате, работайте» не очень подходит. Мы стараемся нанимать людей, которые готовы предложить свое видение, у них есть мнение и вопросы.
Это движет проект вперед намного быстрее, чем если нанять трех супер-сеньоров, которые говорят «мое рабочее время вышло и вообще вы платите мне недостаточно». Они сделают меньше, чем человек, который за сутки на хакатоне запилит проект, доведет его до продакшена.
— Мы ищем людей, которым не все равно, которые заинтересованы двигаться вперед.
— Вот я к вам пришел, сказал, что я весь такой целеустремленный, у меня много своего мнения, горят глаза. Я еще прыснул в них чем-нибудь, чтобы поблескивали, говорю, берите меня. Вот так и возьмете?
— Собеседования не такие простые. Мы создаем условия, близкие к рабочим процессам, и смотрим, как человек себя показывает. Если ты разработчик, то будешь писать код. Если эйчар — будешь собеседовать.
— На собеседовании разработчик будет писать код?
— Да, я знаю, это сейчас очень обсуждаемо.
Понятно, что мы смотрим на несколько показателей, когда собеседуем разработчиков. Но наш стек не самый типичный, и кодовая база большая, поэтому кроме горящих глаз мы ждем, что человек как инженер умеет разбираться в сложных концепциях, независимо от языка.
Если человек говорит: «Я React-программист», — это уже звучит странно. То есть если не React, ты не разберешься?
Мы стараемся давать задачи, которые сами делаем каждый день. Они не требуют суперзнаний о предметной области. Мы не спрашиваем, что такое замыкание в JS. Можем спросить: «Вот у тебя есть Jira и Wrike. Как ты синхронизируешь данные между ними?»
Неважно, на каком языке кандидат напишет эту задачу — хоть на Go, хоть на чем угодно. Можно даже просто нарисовать, что где взять и куда положить. Скорее, мы набираем инженеров, чем специалистов по языкам.
— Если пришел человек с гениальным инженерным мышлением и решил задачу так, что вам очень нравится, но у него нет «горящих глаз и вот этого всего», он попадет в компанию?
— Это лукавый вопрос. Если он крутой инженер, значит глаза горят. Не бывает кода в вакууме. Не бывает людей, которые решают олимпиадные задачки, и их все устраивает. Любой программист — эгоист и нарцисс. Просто у него это выражается в коде. Любому человеку хочется, чтобы результаты его труда были видны и приносили пользу людям.
А из этого вытекает то, что человеку не все равно, что делать. Почему, например, тяжело найти людей в банковскую и финансовую сферы? Там бывает скучновато. Я не говорю за всех, но делать платежки для австралийского банка… Пусть там будет суперархитектура — спроси любого, и почти каждый тебе скажет «не хочу».
— В банках скучно. А у вас весело?
— Пока даже чересчур.
Мне нравится Wrike тем, что постоянно появляются новые задачи, на которые я могу влиять. Не бывает, что за нас все уже придумали. Мы всегда обсуждаем, высказываем свое мнение, вкладываемся в каждую фичу, в каждую итерацию.
— Задачи между командами сильно отличаются?
— Специфика бывает совсем разная. Одна команда делает Gantt-чарт. У них там Canvas, своя логика. Команда, которая делает одновременное редактирование задач, как в Google Документах — там и математика, и Dart на бэкенде. От команды к команде стек один, но применение совершенно разное.
— Если человек говорит, что устал в своей команде и хочет что-то другое, получит ли он это от простого перехода?
— Конечно. Переходы бывают часто и любые. Люди становятся из бэкендеров фронтами, инженеры становятся продакт-оунерами. Когда я пришел в Wrike, меня поразило количество горизонтальных связей между командами. Люди постоянно общаются, куда-то вместе ходят, тусят.
— Как так получилось? Большая компания, 400 человек в офисе. Как они сдружились?
— Это вопрос подбора и культуры. Про культуру тяжело говорить — это эфемерные вещи. Ты их чувствуешь, но описать словами не можешь. Во время подбора есть этап Cultural fit, когда мы смотрим, насколько человек подходит команде.
— Что там за критерий. Как вы определяете, подходит или нет?
— Есть ТОП-5 тупых вопросов на собеседовании. Один из них — кем вы себя видите через пять лет. Он звучит не очень, но в другой формулировке полезен. Например, какие у тебя цели, чего ты вообще хочешь? И если человек может их сформулировать, это уже плюс.
— Если человек сказал, но вам не понравилось, чего он хочет?
— Редко такое бывает, что человек хочет чего-то сильно противоположного нашим ценностям. Если скажет, что хочет петь или на лыжах кататься, тогда да, это будет странно.
Наша задача — искать людей, которые хотят делать работу хорошо, приносить пользу и развиваться. А развитие невозможно в вакууме. Надо общаться. Вместе с другими людьми ты достигаешь большего. Если просто приходить, не здороваясь садиться за свои места, восемь часов работать и уходить — то для собственного развития вы сделаете гораздо меньше.
— То есть плохо, если человек ничего не ответит?
— Нет. Мы не поставим на нем крест. Все люди чего-то хотят.
— Я просто пытаюсь понять, можно ли не пройти этот этап собеседования?
— Легко. Мы немного фрики в плане продуктивности и достижения целей, мы ищем людей себе подобных. Есть те, кому нравится быть в процессе, а есть люди, которым нравится результат. Мы про второе.
— Вот еще почему можно не пройти. Wrike — это safe place. Тот же Google говорил, что один и самых ключевых критериев успешной команды — это психологическая безопасность. Я могу брать на себя ответственность только если знаю, что я в безопасности.
Если человек откровенно токсичный, мы знаем, что он будет приносить команде больше разрушения — даже если он суперкрутой программист.
— Людей надо критиковать, чтобы они учились?
— Критиковать — это не совсем правильное слово. Обязательно нужна обратная связь. Мы здесь не для того, чтобы искать виноватых — мы здесь, чтобы делать работу качественно.
