Увидеть новый и пока мало кому известный язык программирования в маленьком стартапе или пет-проекте у друзей — дело обыденное. Спросишь, зачем его взяли, скажут, что просто изучили из любопытства, понравилось и решили поэкспериментировать, потому что устали от вечных 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 говорил, что один и самых ключевых критериев успешной команды — это психологическая безопасность. Я могу брать на себя ответственность только если знаю, что я в безопасности.
Если человек откровенно токсичный, мы знаем, что он будет приносить команде больше разрушения — даже если он суперкрутой программист.
— Людей надо критиковать, чтобы они учились?
— Критиковать — это не совсем правильное слово. Обязательно нужна обратная связь. Мы здесь не для того, чтобы искать виноватых — мы здесь, чтобы делать работу качественно.
Автор: Артем Малышев
