Разработка в Uber. Как менеджерить 15 млн поездок в день

Всем привет! Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионала, с которым можно поговорить простым человеческим языком. Сегодня наш гость Андрей Неверов. Андрей был техническим директором TrackerPath, стартапа такого Uber для грузовиков в Америке. А теперь Андрей работает в самом настоящем Uber в Дании, руководит там программистами. Uber— это компания, которую вспоминают, когда хотят привести пример стартапа, который стал гигантской корпорацией, очень успешной, поднял сотни миллионов долларов, стоит десятки миллиардов долларов, миллионы клиентов. Но за всеми этими числами стоят живые люди, тысячи программистов, дизайнеров, менеджеров, которые, собственно, делают весь этот софт. Я хочу разобраться, как устроена работа в больших IT-корпорациях, как происходит взаимодействие внутри команды, как команды взаимодействуют между собой, как устроен карьерный рост в большой IT-корпорации. И мне кажется, что Андрей— идеальный гость для этого, потому что он сам побывал техническим директором стартапа, а теперь работает и видит разработку огромной IT-компании изнутри. Это подкаст студии Либо-Либо, и мы его делаем вместе с сервисом онлайн-образования Яндекс.Практикум. У Практикума есть курсы по разработке, по анализу данных, по веб-дизайну и по английскому языку. Если вы хотите освоить цифровую профессию, переходите на сайт Яндекс.Практикум и учитесь.

Меня зовут Андрей. Я руковожу командой разработки в компании Uber.

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

Два основных бизнеса, которые у нас есть— это ride-hailing (райдхейлинг), ну или такси, грубо говоря, и доставка еды.

То есть это и Яндекс.Такси, и Яндекс.Еда одновременно?

Да-да-да, Яндекс.Такси, Яндекс.Еда— это Uber.

А сколько человек сейчас в компании?

Сейчас в компании, наверное, 2025 сотрудников.

Нифига себе, как много. Сколько это офисов?

Ой, много офисов. Думаю, что процентов 70 сотрудников в Америке. У нас есть офисы в Европе, самый большой в Амстердаме. У нас есть офисы в Дании, в Болгарии, во Франции. У нас есть офис в Лондоне, в Индии, в Бразилии. Почти везде, почти везде.

Андрей, в России, я так понимаю, Uber продал свой бизнес Яндексу, то есть там какая-то была сделка, после которой это все просто стало Яндексом, да?

Да, Uber России не существует больше. Россия— это не единственный регион, где Uber так поступил. В Китае то же самое. Uber вышел из Китая через какое-то время после запуска и продал бизнес Didi. Ну, в общем, на тех рынках, на которых Uber понимает, что он проигрывает, намного выгоднее объединиться с конкурентом и иметь долю в конкуренте. Тогда конкурент будет расти, соответственно, доля Uber будет расти, как бы все круто.

Все довольны. Сколько вообще команд у тебя в офисе?

У нас в офисе сейчас, наверное, человек 60. Они поделены плюс-минус на команды по 5 человек, грубо говоря.

Можешь привести примеры команд? Чем они занимаются?

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

Прямо одна команда целиком отвечает за UberEats?

Нет, за UberEats отвечают много команд. Я, честно говоря, не знаю, сколько у нас мобильных разработчиков. Я думаю, что у нас, наверное, сотни по три на каждую платформу Android и iOS.

А как называется твоя команда?

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

версии кода Слушай, если говорить техническим языком, это CICD, да? Видимо, обвязка. Continuous Accretion, Continuous Deployment.

Типа да.

Но это backend, да? Это все софт, который на серверах, не на конечных телефонах, а на серверах работает?

Да, это все для backend-сервисов. Для мобильных сервисов у нас есть наша соседняя команда. Они занимаются похожими вещами, но для мобильных приложений.

Офигеть. То есть все бэкендеры Uber по сути являются твоими пользователями?

Да.

А сколько их? Ты представляешь вообще порядок?

Я думаю, что 3500-4000 человек, из них, наверное, порядка 700-800 человек, это всякая мобильная разработка. А все остальные, кто что-то программирует, веб там или бэкэнд, они пользуются нашими инструментами.

Охренеть, например, 2000 человек, даже больше. Сколько человек у тебя в команде?

Сейчас у меня 14 человек.

Погоди, у вас же команды не больше пяти.

Ну, они поделены внутри на три команды.

А можешь сказать, какая там структура? У них есть свои руководители? Или у тебя прям 14 direct reports (прямых подчинённых)?

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

Так же запрещено делать? Не больше семи же.

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

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

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

То есть эти 14 человек, они не являются подчинёнными этих трёх лидов?

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

В чём конкретно твои обязанности?

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

Исправление какое-то.

Да, это ты очень хорошо отметил. Исправление. Есть много разных систем. Все эти системы работают в некоем унисоне. Одна система может общаться с другой системой. Допустим, есть система, которая ведёт машину по маршруту. При этом, когда поездка закончена, эта система должна сказать другой системе, что «поездка закончена, пожалуйста, иди и сними вот это количество долларов с карты вот этого чувака». Потом платёжная система должна пойти в другую систему и сказать «Окей, слушай, база данных, а вот этот чувак, дай-ка мне привязанную к его аккаунту кредитную карту и запроцессить этот платёж». То есть они все друг с другом общаются по каким-то каналам коммуникации, и поэтому иногда бывает такое, что одна система сломалась и сломались все остальные системы, которые с ней пытаются разговаривать. Вот, и для того, чтобы такие вещи как-то чинить, им нужно либо выпустить новую версию кода, либо каким-то образом перезапустить эту систему в старые версии, которая до этого работала. И для этого всего, собственно, и нужны эти инструменты, которые мы делаем.

А сколько вообще отдельных сервисов внутри Uber?

3000. Больше 3000.

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

Ну не очень особенно. У нас человек 600, наверное, занимаются инфраструктурой, и они производят инструменты для других разработчиков Uber.

Ага, и у вас это один из инструментов таких?

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

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

Да, либо курьеров с едой, либо грузовиков с... Охренеть!

это почти полмиллиона Это больше, чем население Риги!

Да, вот это ковид, как бы у нас все упало, когда все это началось и все закрылось, к середине следующего года мы очень хотим дорасти до 600 тысяч, это реально безумное количество, вот, и в день типа у нас там от 10 до 15 миллионов поезд, ну вообще вот транзакции мы делаем, да, и по каждой из этих поездок нужно провести какие-то вычисления, какую-то работу, сохранить какие-то данные, проверить какие-то платежи, прочитать маршруты, чек, блин, выписать, в некоторых географиях, например, нужны физические чеки, и они не обязаны быть у водителя или у пассажира, но они обязаны присутствовать.—

Ну где-то стоят принтеры и печатают их, да?—

Да, и где-то стоят принтеры и херачат, типа. Это как бы одна вещь, да, то есть просто очень-очень-очень много поездок. А вторая, что Uber работает в очень-очень многих местах.

У всех разные законы.

Да, и везде есть разные законы, и везде есть вообще как бы все супер зарегулировано, вот. И есть одни правила, по которым Uber работает, допустим, в Лондоне, и совершенно другие правила, по которым Uber работает в Амстердаме.

А, это даже то, как интерфейс работает, да?

Даже то, как интерфейс работает, даже то, как оформляются водители. В Голландии, например, если ты хочешь работать водителем Uber, то тебе нужно получить специальную лицензию. Получение, которое занимает год. Но после того, как ты ее получаешь и начинаешь работать Uber, ты зарабатываешь довольно неплохие деньги. А, допустим, для того, чтобы начать водить для Uber в Америке, ничего не надо. Сел, типа, поехал. Ну, приложение поставил, нажал кнопку, поехал. И есть очень-очень-очень большая разница. Даже вот такой смешной пример. Вот моя команда занимается этими инструментами для других разработчиков. Если изменения кода касаются того, как Uber работает в Лондоне, то этот код должен выпускаться по другим правилам, отличным от тех, по которым он выпускается обычно.

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

Типа того. Потому что департамент транспорта Лондона обязал Uber использовать какой-то более надежный механизм выпуска новых фич, потому что там были какие-то проблемы в каком-то году. Была достаточно громкая история. На самом деле там просто были таксисты, которые ездили по поддельным документам. А Uber лакомая как бы цель для нападок всевозможных департаментов транспорта, потому что Uber работает намного лучше, чем все департаменты транспорта. Значит, провели какой-то аудит и обязали нас там применить какие-то там практики, какие-то поменять инструменты.

Ну как политическая история, как обычно.

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

Это тоже ваша команда?

Ну, мы много времени тратим на это.

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

Ну да, нажал кнопку, и оно поехало. Я обожаю, когда люди говорят, блин, какого хера, я нажал кнопку, оно поехало, и я такой, yes! Значит, мы свою работу неплохо сделали. Если ты нажал, оно поехало. Но количество всякой машинерии, которая в этом задействована, оно огромное.

Чем больше компания, чем больше у неё клиентов, тем сложнее это всё. Им нужны инструменты для того, чтобы разрабатывать инструменты, для того, чтобы... Короче, это просто

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

Андрей, а насколько команды автономны? То есть насколько решения принимаете вы внутри, а насколько они диктуются сверху руководству?

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

Бизнесовых, высоковыровневых.

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

Всё, что сейчас ты рассказал, это происходит внутри одного офиса или это глобальная история?

Не, это глобальная история, это вся компания это делает, вся инженерная часть компании.

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

Ну, в Excel он там в каком-то... В Excel? Ну, да, в табличке какой-то. Да, это, короче, на самом деле это прикольная тема, как вы устанавливаете коммуникации такого рода, когда у тебя десятки и сотни человек в них участвуют. И никто ещё не придумал ничего лучше, чем табличка в Excel, если честно. Значит, у нас были попытки внедрить какую-то систему, чтобы это всё трекалось, но это всё не работает. Ну, как бы у нас куча людей, которые пришли из других больших компаний, из Facebook, из Google, из Netflix, из Amazon. И все, кто в этом участвовал, говорят, чуваки, сделайте табличку в Excel и давайте без этой всей хуйни.

А можешь какой-нибудь пример привести, кроме переезда в дата-центр, еще какой-нибудь пример задачи такой высокоуровневой?

У нас есть компьютеры, на которых запущены программы, которые позволяют Uber работать. Эти компьютеры, они могут быть либо физическими компьютерами, которые стоят в дата-центре, либо виртуальными компьютерами, которые запущены в облаке. Ну и на каждом из этих компьютеров запущены какие-то приложения. У нас есть проблема, что мы плохо понимаем, где чего запущено. Не в том плане, что мы не знаем, где что запущено, а нам сложно регулировать нагрузку. И поэтому у нас есть какая-то часть компьютеров, которая греется физически сильнее, чем остальные. А если они нагреются достаточно сильно, то они расплавятся. А это засада, потому что если компьютер расплавится, нужно купить новый и заменить его, а это стоит денег. Правильно? Поэтому нам нужно хорошо понимать, как нам равномерно распределять нагрузку на все эти компьютеры. Вот. И моя команда, в частности, Я думаю, что в течение всего следующего года будет делать целую пачку фич, связанных именно с тем, как мы будем контролировать и распределять эту нагрузку. Учитывая, где мы запущены, запущены ли мы в облаке или мы на физическом железе, какие программы исполняются на этом железе. То есть там миллион всяких разных факторов, которые мы должны будем учесть для того, чтобы как-то эту проблему решить.

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

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

Вот.

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

Как работает Operations? У вас внутри есть прямо админ? Или админ— это отдельный департамент, который отвечает своим каким-то боссам? Как это сделано?

У нас сделано это следующим образом. Во-первых, есть инфраструктурная команда, это мы. Безусловно, мы достаточно все хорошо, особенно более опытные разработчики, они хорошо понимают, как вся фигня работает. Поэтому если что-то происходит, то очень часто нас тоже зовут подключиться и помочь. Значит дальше есть команды, просто разработческие команды, которые делают какие-то свои штуки, они сами отвечают за то, как это всё работает. Если что-то падает, то это их обязанность пойти и это поднять обратно и починить. При этом у каждого большого подразделения разработческого есть некая небольшая группа людей, к которым можно обратиться, если как бы совсем дела плохо идут. То есть типа что-то упало, мы не понимаем, что происходит.

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

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

Теперь я хочу про мобильную разработку. Мобильное приложение нативное или кроссплатформенное?

Там есть детали, но если высокоуровневое, то нативное, да.

Сколько команд работает над мобильным приложением всего? Ты уже сказал, что это около 300 человек на каждую платформу, да?

Да, но я не знаю, сколько точно там команд. Как бы тут какая штука-то, команда отвечает за какую-то бизнес функцию, за какой-то бизнесовый функционал. Если этому функционалу нужны мобильные разработчики, значит в команде будут мобильные разработчики. Поэтому нет как бы, ну есть некое ядро мобильных разработчиков, которые программируют какой-то Я не знаю, честно говоря, сколько это, но я думаю, что это не так много людей, 5, 10, 15, 20, но я точно не знаю. А все остальные занимаются какими-то своими бизнесовыми штуками.

Кусками бизнеса, и у них есть и мобильные разработчики, и бэкендеры, и может быть фронтендеры тоже.

Да-да-да. Ну то есть представь, допустим, ты занимаешься проблемой рекомендации доставки еды. То есть человек открывает приложение UberEats и мы хотим порекомендовать ему места, где мы предполагаем, откуда ему захочется заказать еду. Вот это твоя бизнес-задача. Ты можешь в легкую померить влияние того, что ты делаешь, на прибыль. Потому что если у тебя рекомендации лучше, люди будут заказывать больше и так далее. Ты можешь померить, сколько времени у людей занимает сделать заказ. как устроено приложение удобно, то тебе не надо будет 200 раз там нажимать на какие-то меню, а ты оп-оп-оп нажмешь, и у тебя все заказалось. Как ты говоришь, кнопку нажал, оно приехало, да? Это все можно как бы померить, и потом, если для реализации этих вещей тебе нужны мобильные разработчики, значит у тебя в команде будут мобильные разработчики. Если тебе нужны веб-разработчики, будут веб-разработчики. Ну а дальше, если у тебя эта бизнес-область, она вырастает, то дальше уже можно там, допустим, На мобильном направлении стало столько задач, что прям нужно еще больше ресурсов. Ну, может быть, у тебя там организуется отдельная мобильная команда из там пяти, условно, человек. Но это зависит, опять же, от бизнеса.

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

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

Я несколько недель назад наткнулся на Twitter-тред про то, как чувак рассказывает, какой был ад-переход с Objective-C на Swift. Не знаю, заметил ли ты его.

Да, я видел. Хороший тред. Я его прочитал и такой, да, это

все так. Нужно дать небольшой контекст для мамы. Objective-C— это язык, на котором разрабатывали приложение для iPhone 10 лет. Потом Apple сказала, вот у нас новый язык называется Swift, он очень классный, делайте на нем. И инженеры в Uber сказали, а давайте все на нем перепишем, и классно будет, как раз все старое выкинем, сделаем заново, классно, правильно. И начали это делать, и в какой-то момент оказалось, что язык слишком сырой, и многие вещи вообще сделать просто физически невозможно. объем приложения начал там... практически попал в лимит объема приложения для айфона, который грузится без Wi-Fi, и, короче, там полный ад. Меня больше всего смущал тот момент, когда он говорит... я пошел к своему руководителю и сказал, чувак, типа, полный ад, надо все сворачивать и делать как раньше, просто типа потихонечку изменять. И он сказал, это сделать невозможно, потому что тогда меня уволят, и уволят моего руководителя, и вообще тебе будет полный пиздец. Как так может быть? Это звучит просто супер, что решение принимается не потому что они полезные, а потому что кого-нибудь за это уволят. А как же no-blame-culture и вот это все?

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

Там еще был Travis Kalanick.

А, ну это совсем другой Uber. Да, Uber очень интересно в этом плане рос, назовем это так. Uber всегда был и остается компанией с, скажем так, подмоченной репутацией. И был миллион скандалов, с чем только не было этих скандалов. Был этот огромный скандал с девушкой, которая обвинила кого-то там в домогательствах. Это вообще самый, наверное, громкий скандал, после которого Трэвиса выгнали. И то, что происходило тогда, мне сложно, честно говоря, оценивать, потому что меня не было в компании, я как бы не знаю. Но люди говорят, что такое случалось.

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

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

Какой ценой.

Значит, моральная сторона вопроса, главное, чтобы всё росло, да. Я не знаком лично с Трэвисом Каланником, но надо признать, что он смог построить компанию, которая росла, да. Но моральная сторона вопроса как бы остаётся, да. И теперь мы стараемся очень сильно поменять эту культуру, да. Я бы очень не хотел, чтобы какие-то события, похожие на 17-й год, это когда был весь этот скандал, с сексуальными намогательствами повторилось. Возвращаясь обратно к тому, с чего мы начали, с технической точки зрения, я уверен, что так всё и было. Uber уже не юный / Uber ещё юн. Стартап, он уже большой, и бизнес уже большой, и внутри до сих пор всё равно ещё полный бардак и жопа. То есть очень много процессов ещё не оцифровано достаточно, И у тебя достаточно много способов делать вещи, договариваться с людьми и принимать какие-то решения. Куча способов влиять на то, как, в моем случае, инженерная часть компании работает. Допустим, когда мы решали переезжать на Jira, я принимал участие в в процессе обсуждения того, стоит ли нам это делать. Просто потому, что чуваки написали письмо, эй, любой, у кого горит от того, что происходит сейчас, присоединяйтесь и помогите нам принять взвешенное решение. Ну и там была какая-то группа из 15-20 человек, которым было не насрать, которые сели, посмотрели, что происходит, подумали, какие инструменты вообще бывают, попробовали гитхаб, Jira попробовали, прототипы какие-то сделали, там GitLab попробовали, что-то еще там было, Asana попробовали, вот. И в конце концов сели и такие, не, ну вот такой дорогой пойдем. И такого в Uber довольно много. Очевидно, что с течением времени Uber будет все больше и более бюрократизированный, но сейчас именно классный момент, когда у тебя уже огромная компания и все, что ты делаешь, ну как бы, блин, непосредственно влияет на то, как все работает.

Типа, вы придумали, как сделать штуку, которая сейчас пользуется, там, 35 тысяч программистов.

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

Ты для этого не обязан быть VVP-ов чего-нибудь.

Да, нет такого, чтобы тебе приходит какой-нибудь там директор и говорит тебе, так, вот эту кнопку программируй синей или whatever. В этом как бы крутость.

Класс. Как результат называется?

А сколько вообще разрядов бывает? Наверное формально 8.

Восьмой самый верхний или восьмой самый нижний?

Восьмой самый верхний.

То есть тебе дофига куда можно расти или восьмой это CTO?

Ну восьмой это CTO. Нет, но инженерный менеджер второго уровня это типа не уровень 2 в иерархии. Это типа пятый какой-то уровень в иерархии. Блин, про карьерные лестницы. Давай расскажем людям, что такое карьерные лестницы в больших корпорациях вообще и нахера это надо. Потому что иначе это вообще какой-то разговор слепого с глухим, люди просто не поймут, о чем речь. Значит, в больших технических компаниях, в частности американских, и насколько я помню, Google был одним из тех, кто начал как-то формализовывать это все, есть так называемые карьерные лестницы. У этих карьерных лестниц есть много ступеней, много уровней. И сделано это для того, чтобы человек, придя в компанию, мог оставаться в ней долго и рос сквозь эти уровни. Соответственно, с уровнями у него растет зарплата, у него растет уровень его обязанностей, он отвечает за более важные вещи и так далее. Для того, чтобы перейти с уровня на уровень, есть некий процесс, как это происходит. И в соответствии с тем, какой у тебя уровень, ты получаешь определенное количество денег в виде зарплаты, в виде бонусов, в виде стока, в виде всего, чего только можно. У меня уровень шестой.

И что тебе нужно для того, чтобы подняться на уровень выше?

Есть некая структура, которая описывает примерно, что мы ожидаем от людей на определенных уровнях. И это доступно всем сотрудникам, и любой сотрудник может посмотреть, сравнить с этим табелем о рангах себя. Часто люди сравнивают своих коллег. И поговорить со своим менеджером по поводу того, мол, а где я вообще? Где я нахожусь? И что мне сделать, чтобы в этой области мне быть более успешным и соответствовать следующему уровню?

У тебя был такой разговор с твоим менеджером?

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

То есть это ты сейчас тренируешься?

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

А можешь привести пример?

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

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

Да.

И сколько у тебя их будет?

У моего руководителя три менеджера и один разработчик.

Три менеджера. Слушай, это звучит как бы гораздо более релаксной работой, чем у тебя.

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

В целом понятно, как в армии.

Как в армии, да-да-да.

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

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

То есть тебе часть зарплаты выдают акциями?

Да. Причем достаточно значительно.

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

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

Офигеть. Реальный прям инцентив. У меня есть один финальный вопрос, который мы задаем всем гостям. Что ты читаешь в интернете? Или слушаешь, или смотришь?

Есть прекрасный блог такого человека, которого зовут Фёдор Борщов.

Качай издеваться, это мой партнёр.

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

Андрей, спасибо тебе большое. Было очень интересно.

Спасибо.

Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс.Практикум. На подкасте мы работали редакторы Юлия Яковлева и Андрей Борзенко, продюсер Павел Боровков, звукорежиссер Нина Мамонтова (?). За джингл спасибо Алексею Зеленскому.