Hi-Tech

«Разработка языка Kotlin обошлась намного дороже, чем наш средний продукт»: интервью с главой JetBrains

Генеральный директор компании Максим Шафиров о конкуренции с Atlassian и Microsoft, стратегии на 10 лет и руководстве с точки зрения программиста.

В закладки

Аудио

В интервью он рассказал: Максим Шафиров попал в JetBrains в 2002 году десятым сотрудником, а в 2012 году занял пост гендиректора.

Максим Шафиров

О карьерном пути и управлении большой компанией

Как вы попали в компанию и стали гендиректором?

В компанию я пришёл довольно давно — в 2002 году, когда ей было около двух лет. Случайно. Тогда казалось, что компания уже большая: скоро перестанет помещаться в одну комнату. Я стал десятым сотрудником. Он всё ещё работает, но более умные люди его сейчас доводят до ума. Работал программистом — до сих пор горжусь тем кодом, который тогда написал.

Когда над проектом работает 15 человек, уже нужно не просто говорить, кому что делать, а хотя бы стремиться вовремя выпускать релизы, развиваться. В какой-то момент оказалось, что компании нужно какое-никакое руководство. Я ему: «Нет, конечно. Мы как-то разговаривали с Сергеем Дмитриевым (сооснователь JetBrains — vc.ru), и он говорит: «Не хочешь руководством заниматься?». Никогда не думал об этом. Не хочу. Я переспал с этой мыслью ночь, на следующий день пришёл и сказал: «Да, хочу». Я программист, о чём ты вообще?». Просто потому что это было нужно и мы без этого страдали.

В 2012 году ситуация повторилась, но уже не на уровне руководства разработкой проекта, а всей компании. Это было в 2004 году. Может быть, найдётся в компании кто-нибудь, кто его заменит? Сергей сказал, что хочет заняться другими проектами, развивать биоинформатику. Потому что надо. На следующий день я сказал: «Да, можно попробовать». Как-то естественно всё получилось — я никогда не ставил себе в качестве цели карьерный рост.

Сейчас вы пишете код или на это уже нет времени?

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

Как устроено управление компанией?

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

Любая команда разрабатывает продукт более или менее самостоятельно, планов сверху никто не спускает. В общем-то, компания так же и структурирована. Есть отдел разработки всех инструментов для . У нас есть отдел, который занимается разработкой всех IDE на базе платформы IntelliJ IDEA. Отдел разработки инструментов для команд. NET. Есть Kotlin, дизайн-студия, HR.

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

У каждого отдела есть руководитель, который подчиняется вам напрямую?

Мы не классическая иерархическая организация: я не ставлю им задачи, они не предоставляют мне отчёты. Слово «подчинение» немного не подходит. Чаще всего не один на один, а более крупной компанией — 10–15 человек. Мы встречаемся и решаем, что нужно делать.

В разных городах и странах чем-то отличается управление?

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

Есть разница в работе с людьми здесь и по видеосвязи?

Если мне пришла в голову какая-то мысль, здесь я спущусь на два этажа и поговорю с человеком. Конечно. Чем больше таких танцевальных па, тем сложнее коммуникация. А в Мюнхене — надо писать: «А можно я тебе позвоню?».

Или только смириться? Это можно как-то исправить?

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

Офис JetBrains в Петербурге

О стратегии и бизнесе JetBrains

Как распределяется выручка по странам?

Весь наш бизнес глобальный. Мы почти не выстраиваем маркетинг и продажи под конкретные страны. Больше всего мы зарабатываем в Штатах, где-то 40%. Поэтому, конечно, мы можем посчитать, где мы больше заработали, но это скорее показатель не того, насколько мы успешны, а того, насколько развит рынок в этой стране.

А в России?

3% в России, 4% — СНГ.

На какие метрики вы в своей работе смотрите в первую очередь?

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

То, что вы делаете сейчас, даст эффект только через полгода?

Скорее, горизонт — пять-семь лет. Через два-три года в лучшем случае.

Вы знаете, как будет выглядеть компания и в какую точку она придёт через пять-семь лет?

Мы начинали как IDE для одного вполне специфичного, но очень конкретного, платёжеспособного и растущего рынка Java-программистов. Я знаю, а вот насколько это верно, конечно, никто не знает. И кажется, сейчас практически всё, что имеет для нас финансовый интерес, мы покрыли, горизонт роста закрыт. Потом росли горизонтально — делали всё то же самое для людей, которые занимаются тем же, но с использованием другого языка программирования.

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

Сейчас мы продаём продукт в основном компаниям, но он консьюмерский, b2c. Есть и дополнительный вариант роста. Он уже уговаривает своё начальство, чтобы ему разрешили это купить. Потому что эмоциональное решение о покупке принимает конечный потребитель-программист.

Это уже будет классический b2b-продукт, и нам с ним придётся непросто с точки зрения продвижения на рынке. Мы хотим стать компанией, которая имеет серьёзный вес на рынке инструментов для команд, причём не только команд разработчиков. Но мы постараемся.

Как вы к ним находили подход? У вас довольно много очень крупных клиентов — Citibank, Google, Twitter, Wikipedia.

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

Менеджеры? Если ваши основные продукты для разработчиков, кто на втором месте?

Upsource для code review. У нас уже есть YouTrack, есть TeamCity — это продукт для сборки. Пока всё, но есть ещё один большой продукт в разработке.

«Продукт закончен», — думали мы 14 лет назад. Когда мы начинали делать TeamCity в 2005 году, идея была такая: мы сделали IDE и всё, что можно было сделать в IDE для индивидуального разработчика. Например, такую же интегрированную среду, но для команд. Что ещё можно сделать? Был такой инструмент, назывался CruiseControl, но работать в нём было неудобно. Начать решили с того, что было наиболее востребовано в тот момент и отсутствовало на рынке — это Continuous Integration.

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

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

Насколько сервис YouTrack может чувствовать себя конкурентом Jira по функциональности и охвату аудитории?

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

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

И ребята планируют развиваться дальше. Тем не менее YouTrack довольно успешный, денежку приносит, мы им сами пользуемся с большим удовольствием.

О расстановке сил на рынке

Кого JetBrains считает своим основным конкурентом?

Что касается инструментов для разработки — это Atlassian и в последнее время Microsoft. Для разных продуктов разные конкуренты. Visual Studio Code активно набирает популярность. Она стала много вкладываться в работу с девелоперами, есть инструменты для команд.

У вас есть стратегия войны?

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

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

Лампочка с подсказками в Intellij IDEA

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

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

Мы считали, что это уже общеизвестные факты, все этим пользуются и объяснять не нужно. Будем стараться образовывать пользователей, такие вещи нужно обязательно популяризировать. И сам продукт нужно делать проще. Так вот — нужно.

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

Чем ваши продукты принципиально отличаются от продуктов Microsoft?

Microsoft не строит бизнес на девелоперских инструментах. Важно смотреть, где та или иная компания извлекает прибыль, что она в конечном итоге продаёт. Microsoft с помощью инструментов привлекает разработчиков в свою экосистему. Точно так же, как Google, не продаёт поиск, например. Или офисные программы. А потом продаёт сервера на Azure. То есть мы что делаем, то и продаём. А наш клиент — программист. Мне кажется, что это очень выгодное отличие.

Почему я должна переходить с Visual Studio в ваш продукт? Но для пользователя оно не слишком очевидное.

У нас есть сотрудники, которые на примерах объясняют, почему это имеет смысл. Для этого есть маркетинг. Обычно людей цепляют какие-то мелочи.

Atlassian, Microsoft и вы. Почему на рынке так мало экосистем для разработчиков?

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

Так что это тяжёлый бизнес. Программисты, как ни странно, очень не любят платить за софт.

О Kotlin, работе с Google и отзывчивости

Есть у вас продукт, который вы сейчас не монетизируете, но в перспективе хотели бы?

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

На чём он может зарабатывать, кроме инструментов?

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

Но на сайте у вас пока нет отдельной IDE для Kotlin, вы предлагаете использовать для него IDEA?

Попробую объяснить. И да и нет. При этом у каждой машины своя платформа, свои библиотеки, среда исполнения. Вообще, язык нужен для перевода кода из структурированного текста в формат, который понимает и может выполнять машина. Ещё мы работаем над компилятором в нативный код, можно будет писать приложения для iOS. Kotlin пока может работать в двух средах исполнения: Java — например, для приложений на Android, и JavaScript — например, для фронтенда.

Язык — дело вторичное, важна платформа. То есть выглядит так, будто у нас есть IDE для каждого языка, но на самом деле это не так. А Kotlin — везде. Вот это IDE для Android, вот это IDE для Java Server Side, это IDE для фронтенда, это IDE для scientific-вычислений и так далее. Под Java-платформу можно писать часть на Java, часть на Kotlin. И на всех платформах он родной. Фронтенд тоже: можно писать часть на JavaScript, часть на Kotlin.

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

Когда?

Пару лет, я думаю, это займёт.

Помимо возможности писать приложения для iOS, над которой вы сейчас работаете, есть ли ещё области, которые пока не охвачены Kotlin?

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

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

IDEA — open-source-продукт, но, наверное, Google не могла просто её взять и сделать что-то своё. Как началось сотрудничество с Google?

По лицензиям абсолютно ничего такого тут нет. Вообще могла.

Но она почему-то так не сделала.

Eclipse — это тоже open-source-проект, но чтобы интегрировать в него специфичный инструментарий для Android, нужно было сделать API. Да, в 2011 году команда Google пришла к нам и сказала, что хочет разработать IDE, но делать на базе Eclipse (IDE для Java от Eclipse Foundation — vc.ru) её тяжело.

Они пришли к нам и наладили коммуникацию, мы просто оказались более отзывчивыми. И этот API команде Google никак не удавалось протащить, не было коммуникации. Но никаких денег там не было. Мы даже отдали им собственный плагин для Android, они его открыли для разработчиков — с этого и начали.

А как Google заметила Kotlin?

Потом кто-то из энтузиастов попробовал написать что-то на Kotlin под Android, и что-то пошло не так, сломалось. Получилось довольно смешно: когда мы начали разрабатывать Kotlin, то про Android не думали вообще. Опять же, проявили некоторую отзывчивость. Нам сообщили, мы поправили, нам сообщили что-то новое, мы поправили ещё.

Поэтому когда Android-программисты получили красивый, удобный и функциональный язык, они стали долбить Google: выскажите своё официальное мнение — можно ли на этом писать? Ещё у Android на Java сложилась такая ситуация: версия языка всегда отставала от того, что было у остальных разработчиков на Java. Не будет ли проблем в будущем?

Может быть, не сразу отвечает, но на ус мотает. Команда Android в Google внимательно слушает сообщество. И в какой-то момент, видимо, накопилась некая критическая масса, пора было выразить свою позицию по этому поводу.

Опять же, можно было просто взять и начать пользоваться Kotlin, от нас тут ничего не нужно было, как и от них. Они обратились к нам. Но они хотели пойти дальше, сделать ставку на Kotlin и оформить всё легально — чтобы в случае, если кто-нибудь недоброжелательный вдруг купит компанию JetBrains, Google не оказалась в некомфортной ситуации.

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

В 2016 году в СМИ пошли первые слухи о том, что Google хочет заменить Java на Kotlin из-за конфликта с Oracle.

Тогда никаких разговоров об этом не было. Да, было очень забавно читать. Но пишете ли вы на Kotlin, на Java, на Python, на чём угодно — используются всё те же самые API. Сама постановка вопроса о том, что язык нужен Google для того, чтобы избежать лицензионных проблем с Oracle, не имеет ни малейшего основания, потому что претензии Oracle состояли в копировании API.

Звучал и такой вариант: «А давайте мы тогда вообще просто заменим Java на Swift». Замена языка никаким образом не затрагивает предмет спора между Google и Oracle. Никто на это никогда не пойдёт. Но это значит, что все приложения под Android можно выкинуть в мусорное ведро.

Но когда вы читали эти статьи в 2016 году, то прикидывали, может ли Kotlin сейчас заменить Java?

Никаких технических препятствий не было. Да, конечно.

Сколько человек работает над Kotlin?

73.

Как шла разработка? Вы разрабатывали язык около семи лет — это долго для языка?

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

С языком так не работает: если он меняется, то написанные на старой версии языка программы перестают работать. Разработчики придерживаются такой идеи: надо сперва что-нибудь сделать, а потом уже изменениями приводить это в нужное состояние. Если вендор языка позволяет себе такие выкрутасы, то скоро пользователей у него не останется, если только это не Apple.

Каждые пару лет выходит новая версия Swift, которая с предыдущей не совместима: пожалуйста, переписывайте ваши программы. Apple может себе такое позволить, со Swift ровно так и происходит. Но от Apple программисты не денутся никуда и никогда, а мы так не можем.

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

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

Мы максимально постараемся помочь с миграцией с одной версии на другую, но ничего не обещаем. Мы в своё время просто явно сказали пользователям: сейчас язык будет меняться. 0 изменения закрыты. А после релиза 1. Теперь всё, что написано на Kotlin, будет компилироваться и в следующей версии компилятора будет работать так же.

То есть мы накопили базу, решили, что правильно, что неправильно, что оставить, что выкинуть — вот и получилось столько времени.

Во сколько вы оцениваете общие затраты на разработку?

Где-то $30–35 млн.

Это можно сравнить со стоимостью разработки IDE?

Для новой IDE, скажем, нужно 80% того же кода и 20% уникального. В случае с Kotlin у нас гораздо меньше переиспользования по сравнению с другими продуктами. Kotlin дороже, чем средний продукт, много дороже. В Kotlin очень много писали нового, много чего перепродумывали.

Что-то вроде Azure или AWS? У вас есть IDE, есть язык, есть много продуктов для разработчиков, и вы рассказали, что собираетесь охватывать также менеджеров, а как насчёт, например, облака?

Пока не приходило в голову. А потом рекламу продавать, если доводить до абсурда? Лет через 20 давайте синхронизируемся, может, мы передумаем. Своё облако — это свои сервера, совсем не наш бизнес.

Офис JetBrains в Петербурге

О роли основателей в компании и жизни идеи от рождения до закрытия

Пока вы управляете компанией, чем занимаются основатели?

У него есть интересные мысли, как можно по-другому вообще устроить образование, чтобы учиться было интереснее и эффективнее. Сергею Дмитриеву интересна биоинформатика, aging, образование как концепция. Другой основатель — Евгений Беляев — делает образовательный продукт в виртуальной реальности, который называется CoSpaces. У него есть проекты в этой сфере — и свои, и те, в которые он инвестировал. Ещё один основатель, Валентин Кипятков, лицензию пилота получил.

Некоторые из своих проектов они делают в рамках компании, некоторые — вне.

Как устроен процесс принятия решений на стратегическом уровне, они в нём участвуют?

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

Откуда берутся идеи для новых продуктов, кто их придумывает, кто утверждает и как устроен процесс?

Тот же самый Сергей пришёл и говорит: «Что нового можно было бы сделать для программистов?». Давайте я на примере Kotlin расскажу, потому что это было смешно. Я такой: «Вы чего вообще, куда? И один коллега — Дима Жемеров — говорит: «Самая крутая штука, которую можно сделать для программистов, — это язык программирования». Мы никогда не потянем и не сделаем его популярным». Где мы, а где язык программирования? Ну а на следующее утро я пришёл и сказал: «Всё, делаем».

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

Для другого продукта в принципе достаточно, если у него есть пользовательская база. Есть ещё дополнительный нюанс в разработке языка, который становится мультипликатором всех рисков. Язык либо мегапопулярен, либо он не нужен. Это оправдывает инвестиции и времени, и денег.

А есть какие-то продукты, которые вы закрыли?

Давно, правда. Да. Это новостной агрегатор, десктопный инструмент, в котором можно было читать почту, фиды, новостные группы, RSS. Был такой продукт, назывался Omea. Открыли исходный код, и он даже до сих пор, по-моему, живёт. Мы его закрыли, потому что было непонятно, как привлечь более широкую аудиторию.

Сколько вы на нём потеряли?

Ещё был давно большой продукт, назывался Fabrique. Это не повлияло критически ни на что. Но пока мы его делали, а делали мы его долго, обновился стэк технологий, и необходимость в продукте отпала. Это фреймворк и IDE для разработки именно серверных приложений сразу с UI. Решили, что, наверное, не жилец. Мы его закрыли за несколько недель до планируемой даты релиза. Конечно, можно было начать с нуля всё делать, но зачем?

То есть закрываете проекты вы редко.

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

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

Какой продукт вы считаете самым доходным?

IDEA.

А второй?

Всё скучно, да? ReSharper. Но у нас не так, всё накапливается потихоньку. Понимаете, бывают продукты с каким-то космическим ростом. Чем дольше продукт на рынке, тем больше он зарабатывает.

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

Это IDE для . Rider. С ним тоже смешная история. NET. Но это игра в догонялки: Visual Studio добавляет какую-то функциональность, мы добавляем больше. У нас вообще-то есть продукт ReSharper — плагин для Visual Studio. Visual Studio до сих пор ориентирована на 32 бита, памяти потребляется не более чем 2 ГБ — и мы вдвоём просто перестали помещаться. Всё было нормально, но тут выяснился вот какой нюанс: Visual Studio потребляет ресурсы, память, CPU и так далее, а мы добавляем сверху.

Она показывает хорошую динамику. Подумали — и решили сделать свою IDE, Rider называется. И GoLand показывает хорошую динамику — в частности, потому что сам рынок растёт очень хорошо.

Сотрудники компании используют только продукты компании?

Это означает, что, наверное, ты что-то не то делаешь, хотя мне известны люди, которые предпочитают только легковесные редакторы. Разрабатывать IDE и не пользоваться этой же IDE — странно. Во всяком случае, даже если это так, то это не проблема. Чтобы кто-то использовал VS Code, мне не известно.

Люди сидят тут сутками? Насколько в компании распространён трудоголизм?

Наверное, мы уже не стартап. Кто как. Просто потому что было ужасно интересно. Когда мы начинали, я действительно уходил в 2–3 часа ночи, работал и в субботу, и в воскресенье. И нет, народу не очень много. Сейчас у нас тут по субботам кружок по робототехнике, сотрудники приводят своих детей, и я тоже со своими прихожу в офис.

То есть руководство не поощряет трудоголизм.

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

О культуре в компании и найме сотрудников

Вы позволяете сотрудникам заниматься сторонними проектами?

Есть масса пользы в том, что люди приобретут новый опыт. Да. А если им это запрещать, они будут считать, что компания их ущемляет, не даёт заниматься тем, что им интересно, и уйдут куда-нибудь. Они будут более интересующимися и мотивированными. День в неделю можешь заниматься чем хочешь. У нас есть такая тема, как в Google, — 20%. Хотя загорать на пляже 20% времени не поощряется.

То есть разработка.

У нас есть люди, которые работали в поддержке, а 20% тратили на дизайн — нравился он им. Не всегда. Иногда человек работает много лет в одной команде, и вроде как его всё устраивает, но хочется попробовать что-нибудь другое, перейти в другую команду — но страшно. А потом переквалифицировались в дизайнеров интерфейсов.

Тогда он говорит: «Давай я один день в неделю буду работать у вас». Вдруг не справлюсь, вдруг там всё плохо устроено или начальник злой, или коллеги на обед не ходят вместе. Иногда говорят: «Нет, что-то мне у вас не нравится». Иногда переходят совсем. Мы так не планировали, но вот так с этим правилом получилось. И уходят назад.

Это как-то отразилось на настроении коллектива? Насколько я вижу, после того как Kotlin стал известным, компания тоже стала более известной в широких кругах.

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

Но сотрудников стало проще искать, наверное?

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

Какие основные источники кадров?

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

А хакатоны не проводите?

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

Какие качества у него должны быть? Как вы можете понять, что человек вам подходит? Какие компетенции?

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

Но есть же какие-то общие ценности во всей компании?

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

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

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

Куда я могу попасть? Как может выглядеть карьерная лестница в компании?

На моё место.

Могу?

Я же попал. Да. Если он сидит в своём углу, никуда не показывается, то карьерной лестницы у него нет — но ему и не надо. Обычно так это выглядит: приходит человек, начинает что-то делать.

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

Куда дальше?

У нас нет заранее продуманной иерархии, скорее мы просто идём от имеющегося. Как сложится. Структура образуется только там, где она необходима.

Что он дальше будет делать? Допустим, тимлид подумал, что на позиции он достиг потолка или перегорел.

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

Что должно для этого случиться? Вы говорите, что вас гипотетически кто-то может заменить.

Продемонстрировать способность спокойно взаимодействовать с массой людей. Человек должен продемонстрировать видение, понимание того, чем компания может заниматься дальше. Да и хватит, пожалуй. Возможность заразить своими идеями, чтобы кто-то по собственной воле подхватывал и шёл что-то делать дальше.

И одновременно с этим вы тоже какие-то ошибки можете совершить, которые приведут к замене?

Руководство компанией для меня не самоценность или самоцель. Да. Если такой человек появится и я увижу все эти свойства в нём, поверю в него, то вообще нет проблем.

Остались бы в компании? Если бы это произошло, чем бы вы стали заниматься?

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

Из каких частей он строится, какие задачи вы решаете? Можете описать свой типичный рабочий день?

Почта, Slack, митинги и работа в IDE.

О России на глобальном рынке и о покупке других компаний

Как вы оцениваете российское техническое образование?

С одной стороны, грех жаловаться. Становится лучше. А с другой стороны, в западных университетах гораздо более фундаментальные курсы по Computer Science. Я здесь учился, как и 99% моих коллег. Но мы активно нагоняем.

Что бы вы изменили в российском образовании, чтобы оно стало ещё лучше?

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

Если посмотреть на Россию на международной ИТ-арене, как вы оцениваете страну с точки зрения и мозгов, и компаний, которые имеют российские корни и пытаются конкурировать?

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

Это хорошо работает, прямо прекрасно. Мы офис в Мюнхене открывали именно по этим соображениям, чтобы люди, которые хотят уехать из России, не должны были увольняться из компании. Можно за них порадоваться, но чем больше компания, тем меньше личного участия в результате. Часто люди, которые отсюда уезжают, устраиваются в очень большие фирмы — Google, Facebook, Microsoft. Здесь они могли бы сделать что-то более impactful.

Как часто бывает такое, что из вашей компании люди уходят и открывают свою компанию?

Например, есть такой Фёдор Коротков. Бывает, но я не считал. Есть люди, которым надо в Долину съездить. Он уехал от нас в 2013 году. Потом сделал свой продукт, который с нами конкурирует. Он работал в Twitter, потом в Airbnb. Он очень хороший чувак, я всё жду, когда его можно будет обратно забрать.

Забрать — купить компанию или нанять его обратно?

Покупка компании — у нас пока эта мышца не очень работает. Как получится.

Экспериментировали?

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

То есть если бы вы кого-то покупали, то ради технологий и аудитории, возможно, но не ради специалистов?

Всё, что полезного есть в нашей индустрии в смысле технологий, уже с открытым исходным кодом. Ради технологии покупать никакого смысла нет.

Так, ради людей нет смысла покупать, ради аудитории тоже.

Мы пока не умеем. Ради людей есть смысл покупать, надо просто научиться.

То есть проблема в вас, а не в том, что люди по-другому мыслят?

Да, абсолютно, проблема в нас.

#интервью #jetbrains

Показать больше

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

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

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

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