Григорий Кошелев — Система перевода в ведущие инженеры-программисты с промокодами и комиссарами

Друзья, я вас еще раз приветствую здесь, в этом зале.

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

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

Иногда подходит к тебе твой начальник и говорит, что теперь ты, вот конкретно ты ведущий разработчик.

Во всех компаниях процессы разные, как я говорил.

Но давайте послушаем, как же это сделано в компании «Контур».

Григорий, тебе слово.

Спасибо.

Всем привет.

Сразу такой маленький дисклеймер.

Это мой первый нетехнический доклад на конференциях.

Надеюсь, что у нас получится все хорошо.

По доброй традиции контура у нас есть за лучший вопрос книжка.

Вот такая вот книжечка будет.

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

Я, соответственно, постараюсь ответить и потом выберу лучший.

Доклад.

Итак, система перевода ведущих инженеров и программистов с промодоками и комиссарами.

Звучит очень сложно, поэтому давайте сейчас попробуем понять вообще, про чем мы сегодня с вами сейчас поговорим.

Если кратенько, то я расскажу о том, как стать ведущим инженером в контуре.

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

Вчера был фейл-митап.

Кто уходил вчера на фейл-митап?

О, прикольно, вас было много.

Меня в этот раз Леша не позвал, поэтому я решил, что стендап будет немножко вот прям здесь.

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

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

Как стать ведущим инженера в Кондоре?

Для этого нужно написать промо-документ, то есть promotion doc, и после этого пообщаться с комиссией из ведущих инженеров.

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

Но если серьезно, то надо немножко историческую справку привести.

Я в одной компании уже работаю почти 9 лет.

Я пришел в контур в 2014 году и продолжаю там работать.

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

В 2023 году нас уже больше 1000 человек.

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

И где-то переломным моментом оказался 2019 год.

И сейчас давайте посмотрим, что было до и, соответственно, что стало после.

Давайте посмотрим, как вообще у нас устроены команды в контуре.

У нас есть менеджеры разработки.

Ну, это такие люди, которые ответственны за производственный процесс.

Ну, можно заметить, что они все загорелые ребята.

Значит, они очень хорошо работают.

Ну, и в команде у них есть какое-то количество джунов, мидлов.

Ну, какие-то из уровней могут отсутствовать.

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

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

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

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

Так вот, если вот некоторые инженеры растут, растут, в какой-то момент надо решить, типа что вообще-то он ведущий, он не ведущий.

Кто в этой ситуации может это сделать?

Ну, вот эти ребята имеют какое-то общение регулярно, потому что это одна команда.

И, соответственно, вот этот контекст о том, что вот такой-то инженер все-таки уже ведущий или нет, транслируется в руководителя.

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

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

Такая система, кажется, не очень хорошая.

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

И поэтому вот эти разработчики, ну, скорее всего, становятся ведущими.

Или нет.

Давайте поймем.

Вот в такой штуке вообще какие могут быть проблемы?

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

Особенно, когда таких ведущих уже в команде много, и у него есть насмотренность.

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

Как ему понять, является ли вот этот его разработчик ведущим или нет?

Ну, смотрите, если он угадал...

то кажется все хорошо, проблемы нет.

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

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

И тогда он демотивируется.

Но он до какой степени может демотивироваться?

В лучшем случае он такой скажет, ты плохой менеджер, я пойду в другую команду.

И это, наверное, хороший вариант.

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

Ну, наверное, это самый такой страшный вариант, и мы такого не хотим делать.

Ладно.

Ошибка второго рода.

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

Что в этой ситуации?

Ошибка второго рода, и другие инженеры из других команд демотивируются.

Почему?

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

И тут он понимает, что вот этот ведущий вообще не алё.

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

Ну и вот если мы сейчас поставим себя на место вот этого главного руководителя, то согласно аксиоме Экскобара, что тот вариант плох, что другой.

И с этим нужно, соответственно, что-то делать.

Алды помнят, да.

Так вот, что мы хотим сделать?

Мы хотим сделать оценку однородную и справедливую.

Звучит очень классно, давайте попробуем понять, что это такое.

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

Вроде логично.

И обратная ситуация.

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

Ну и про справедливость оценки.

История о том, что как-то мы должны суметь...

Проранжировать наших инженеров таким образом, чтобы где-то была вот эта граница.

Вот тут не ведущие, а там ведущие.

Вроде все понятно.

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

И, возможно, есть какие-то портреты.

Но самое такое естественное классическое деление — это темлит и техлит.

Поднимите руки те, у кого не так.

Нет деления на техлит, темлит, а какое-то другое.

Есть такие?

Приходите, пожалуйста, в дискуссионку.

Хочу с вами поговорить.

Как вы это сделали?

Остальные тоже приходите, тоже послушаем вместе.

Так вот, что мы решили сделать?

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

И мы сделали такую первую версию промо-документа.

Ну, что-то типа такого сочинения, как «Я стал ведущим», но на самом деле нет.

Мы попросили описать задачи, цели, которые были у людей.

какие у них есть зоны ответственности, что значимого они на их взгляд, на их собственный взгляд сделали, и что делают их ведущими.

В общем, вот такие вот штуки попросили сделать.

Сразу ограничили это двумя страницами формата А4, чтобы люди сильно не фантазировали, и мы могли потом с этими результатами работать.

В итоге мы получили несколько портретов.

которые извлекли как раз из этих промодоков.

Первый из них это темблит.

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

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

В общем, какие-то такие идеи мы сюда сделали.

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

Но вот общая картина примерно такая.

То есть в целом, наверное, так, как и вы себе представляете TeamLead.

TeamLead, напротив, он не про людей, а про архитектуру, про технологии, в общем, все про это.

Что у нас там функциональные, не функциональные требования.

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

Ну и также он там ответственный за техническое качество.

Это означает, что там он

У него там есть бэклог технического долга.

И он делает так, чтобы вот этот бэклог технического долга, он сильно не разрастался.

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

В общем, вот такой техлит.

Понятно, в общем, крутой разработчик, есть своя зона ответственности.

Все классно.

И тут у нас появился еще третий портрет.

Фичелит.

Это про управление проектами.

То есть в нашем случае фича это целый проект.

Говоря в терминах agile, jira и прочего, это такие эпики.

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

Что-то делают аналитики, что-то делают тестировщики, что-то делают программисты.

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

Мы поняли, что вот такие фичелиды, они бывают двух видов.

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

Это первый тип фичелидов.

А второй, те, которые сами процессы не создают, но они могут офигенно затаскивать один проект за другим.

То есть, вот такие крутые разработчики.

Вот такой получился портрет с фичелидом.

Можно заметить, что...

У всех трех портретов в конце есть лид.

То есть человек о том, что умеет куда-то что-то кого-то вести.

Что-то или кого-то.

Ну, то есть людей, процессы, соответственно, технологию, архитектуру.

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

применяем не только для оценки, но и в целом для постановки тех или иных целей.

То есть мы можем сказать, вот у человека есть конкретно вот эта штука, которую он может прокачать.

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

Благодаря этому мы такую штуку сделали.

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

Это rocket science.

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

Вот какой бы сложной задачей ни оказалось, они типа такое затаскивают.

Ну и нам показалось, что такие люди тоже важны, и надо их отмечать.

И поэтому все четыре портрета для нас оказались равноценны.

То есть все ведущие важны, все ведущие ценны.

Вот примерно такой лозунг у нас был.

И так мы при этом жили.

Что ещё важно, вот с таким выделением портретов у нас реформировалась матрица компетенций.

У нас в 2019 году появилась матрица компетенций, где было огромное количество индикаторов, их больше было 100 штук.

Это сумасшествие, конечно.

А тут мы, получается, от этого огромного количества перешли к четырём портретам, четырём критериям для того, чтобы стать ведущим.

И вот это движение по вот этим трекам получилось, началось где-то с уровня такого middle-плюса.

То есть человек примерно уже на этом уровне,

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

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

Почему?

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

А как-то понять, в какой человек трек попадает из четырех, кажется, что задача становится значительно легче.

В общем, и так мы в ту сторону двигались.

Но по пути расскажу пару историй о том, как это было связано с промодоками.

И вот представьте, что приходят ведущие инженеры, комиссия, общаться с инженером.

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

Вот, говорят, ты там, говорят, вот такой-то сервис тащил, архитектуру, скажи, как это было.

Инженер такой смотрит на ребят и говорит, да, там так написано.

Оказалось, оказалось, что...

добрый менеджер написал промо-дог за разработчика.

И разработчик даже не читал, что он написал, такой типа, да, я тебе полностью доверяю, и все.

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

Менеджер просто все сделал, нужно просто в какой-то момент пообщаться.

В целом мы посчитали, что это нормально, и ничего страшного, если менеджеры так делают.

Но если у менеджеров много свободного времени.

Должны же они как бы что-то делать.

И мы решили в какой-то момент...

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

Дайте написать больше.

Мы спросили, сколько.

Она говорит, уберите ограничения.

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

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

И от одного из инженеров мы получили промодок на 54 страницы, шрифт Arial, 11-й font-size.

Представьте, сколько это текста.

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

Это как бы одна крайность.

Другая крайность оказалась такая.

В комиссию пришел промодок примерно вот такого содержания.

Ну как примерно?

Я его просто скопировал.

Ответ там был прямо написан.

Почему я ведущий?

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

Вот, ну ладно, окей, конечно, тут такая немножко шутка, все-таки человек такую еще ссылку приложил на свой промодок, который он сделал в Markdown, в Git, в GitLab сложил.

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

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

То есть там типа на Markdown отдельные поляшки, ты там заполняешь, все красиво, и не надо, соответственно, в Git что-то складывать.

И на самом деле мы сейчас примерно так и живем на данный момент.

То есть у нас есть сервис, который как раз матрица компетенций, и вот там эта штука делается.

Давайте двигаться дальше.

Еще одна четвертая история.

Вот кто знает, кто такие девелоперы-адвокаты?

Ну, вот есть, да, некоторое количество людей.

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

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

Я однажды выступал в роли такого девелопер-адвоката.

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

Я понял, какую ошибку я совершил.

Я не брал процент зарплаты ведущего для того, чтобы такую штуку сделать.

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

Видимо, лавочку прикрыли.

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

Возможно, он с ним знаком.

И может, грубо говоря, дать такой аппрув.

Ну, типа, вот этот точно ведущий, и я могу доказать, почему.

И вот так у нас появилась идея вот такого промокода ведущего, что если какое-то количество людей

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

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

В какой-то момент до меня долетела история, как человек в команде, он уже хотел стать ведущим, и такой всё время говорил, «Блин, ну, ребят, что-то какие-то промодоки, это слишком сложно, мне проще уволиться».

Ну, все говорили, «Да, отличная шутка, Жош».

Вот он просто взял и в какой-то момент уволился.

Мне кажется, это фейл, и так быть не должно.

Но, тем не менее, сейчас мы, и это, наверное, ранее, хотели в компании развивать культуру self-review.

То есть мы ждем от инженеров осознанности и рефлексии.

И в целом-то это вроде справедливое требование, потому что у меня будет на девупсе рассказ про SRE, и там на самом деле история в том числе про постмортемы.

Ведь в действительности, когда мы пишем постмортем после нашего факапа, мы как раз же проверяем и осознанность, и рефлексию.

Вроде нормально.

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

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

Так вот, про формат промодока.

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

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

Но мы решили, что это хороший вопрос, и давайте так его и сформулируем.

Поле, в котором надо просто писать, а почему я ведущий?

И подсказки, на что надо обращать внимание.

Расскажи, какие у тебя ключевые навыки,

кто ты думаешь, с кем ты себя ассоциируешь.

И, по сути, это такая главная точка входа уже для комиссии, что вот человек видит себя так, давайте с этим поработаем.

И в подтверждение нужно просто перечислить какие-то ключевые для себя результаты, чтобы он был один и более.

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

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

То есть человек такой снежинка, то есть все умеет.

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

Вот эта штука оказалась суперважной.

Тоже мы начали в какой-то момент заводить такую умную ОС.

Она, условно, называется Тима.

Тима моей мечты.

Спрашиваем тестировщиков, инженеров, менеджеров и аналитиков по соответственным задачам.

Более того...

К каждому из вот этих ролей мы задаем разные вопросы.

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

Соответственно, спрашивать его про архитектуру, наверное, не имеет никакого смысла.

Но тем не менее, допустим, про развитие людей вполне ок.

А с аналитиком нормально поговорить о том, как человек работает с формулировкой, как часто он приходит с какими-то предложениями или доработками аналитики.

Ну и тестировщик, в принципе, понятно.

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

А не то, что написал код, перекинул через забор к тестировщикам, и там пусть они как-то дальше разбираются.

То есть вот такие вещи, они позволили...

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

То есть вот этот момент оказался в нашей ситуации ключевым.

Так вот, давайте вернемся к основному лейтмотиву о том, что инженеры оценивают инженеров.

У кого точно так же в компании?

У кого инженеры оценивают инженеров в компании?

Ну, у вас много, то есть там вот...

Человек 20 подняли руки.

Спасибо.

Это действительно круто.

Вот мне непонятно, почему другие не подняли руки?

То есть у вас нет собеседований или его проводят менеджеры?

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

У кого инженеры-программисты проводят собеседования?

Вот, вас уже очень много.

То есть в действительности как-то вот эту оценку инженеры вроде умеют делать.

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

Вот кто согласен с этой гипотезой?

Супер.

Вот смотрите, но вот эта штука говорит о том, что любой ли инженер способен оценить любого?

Наверное, нет.

И давайте поэтому немножко сделаем эту формировку чуть более строгой.

Что инженер способен оценить инженера, у кого грейд меньше, ну либо такой же, как у него.

Но как бы тоже вопрос на самом деле спорный.

Если предположить, что вот эта история...

то на самом деле надежды на этот мир у нас будет немного.

Почему?

Расскажу небольшую байку с обратной стороны.

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

Я особо не был в курсе, чем он занимается, какая у него команда, из чего он в контуре не работает.

Просто вот разработчик.

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

Ну и рассказывал некоторые истории с этого собеседования.

Одна из историй такая была, вот говорит, я вот решил его поспрашивать про сборку мусора, вот, и кандидат говорит, что вот объект, который лоцирован где-то у нас в хипе, он вообще может пропустить ген 0, ген 1 и собираться сразу сборщиком мусора ген 2.

Окей, я на него посмотрел и говорю, так лох же, как бы, все норм.

Вот он говорит, так я тебе и говорю, он вообще тупой.

И вот это вот одна из историй, это прямо true story.

Возможно, кто-то от вас слышал это в виде анекдота.

Вот вы знаете теперь, откуда эта история пошла.

И да, он вот таких вот историй несколько порассказывал.

У меня потом изжога была весь день.

И вот я понял, что все-таки...

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

И вот этот подход для нас оказался, как нам кажется, совершенно правильным.

Итак, давайте про комиссию.

Много раз говорил, комиссия-комиссия из ведущих инженеров.

Как она выглядит?

В ней есть четыре мага 80-го уровня, ведущих инженера-программиста.

Мы даем им кандидатов так, чтобы пара ведущих могла оценить одного разработчика.

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

У нас есть, как мы помним, формализованная обратная связь, соответственно, мы там можем большой контекст собрать.

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

Все.

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

Все.

Этого переводим, а этого, допустим, нет.

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

Он выглядит следующим образом.

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

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

То есть

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

В общем, вот такая вот комиссия у нас получилась.

И какие требования к комиссарам мы предъявляем?

Ну, во-первых, это должны быть

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

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

Я сейчас на примере просто покажу, как это выглядит.

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

И мы, соответственно, пару комиссаров собираем таким образом.

Допустим, один это C-Sharp разработчик тоже из электронного документа оборота, совершенно другая команда, там довольно большое направление.

А другой фронтендер из базовой инфраструктуры.

То есть вот пересечение есть фронтендер-фронтендер, они как-то смогут друг друга понять.

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

И в итоге, что здесь важно?

О том, чтобы мы лично пообщались с кандидатом.

Вот по описанию можно себе представить, как, допустим, промоут выглядит в Гугле.

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

Получилось, не получилось.

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

Про это я еще позже расскажу.

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

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

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

Так вот, давайте посмотрим.

С 2020 года, получается, у нас эти комиссии запустились, продолжаются по сей день.

И как, соответственно, у нас...

Вообще вот эта комиссия работает, сейчас немножко статистики приведу.

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

Вот в днях.

Но вот оказалось, что половина разработчиков примерно рабочую неделю тратит, то есть 3 и более дней.

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

Вот непонятно, много это или мало, то есть как сделать так, чтобы это было меньше.

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

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

Типа, прям необходимо пообщаться, то есть ты как кандидат в ведущие хочешь пообщаться с людьми.

64% говорили да, что это необходимо.

36% говорили, что скорее нужно пообщаться.

И вот внезапно ни один не сказал, что не нужно общаться или там скорее не нужно.

То есть все были уверены, что так или иначе пообщаться стоит.

И вот как раз вот это сравнение с Google показалось для нас очень важным.

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

Вот.

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

К сожалению, ссылочку на эту историю я здесь не привожу.

Так вот, важный момент тоже такой.

Комиссары комиссии решили, что человек ведущий или не ведущий.

Вот вопрос типа «А уверен ли я вообще в своем решении?»

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

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

И внезапно 60% комиссаров полностью уверены в своем решении, а 40% нет.

Мы пытались понять, почему 40%,

100% уверенности нет.

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

Вот такой интересный феномен мы увидели.

А второй момент о том, что вот эта комиссия, это же не то, что мы там собрали как-то в начале вот этих людей с посохами и шляпах, и вот они живут 300 лет.

Нет, на самом деле вот эта комиссия, она постоянно обновляется, и вот когда мы только начинаем комиссию в 2020 году,

И вот сейчас, то есть я посмотрел за последний год, довольно существенное количество комиссаров, это те, которые проходили комиссию в 2020-2021 году.

То есть они прошли комиссию и через пару итераций сами стали комиссарами.

То есть получается вот такая система стала самооценивающейся.

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

Это в целом очень похоже на...

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

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

Это такой удивительный факт в каком-то смысле.

Вот, ну смотрите, вот комиссары уверены в своем решении.

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

Вот кто думает, что статистика такая же?

Сомневаюсь.

А кто думает, что комиссары уверены в чужом решении больше, чем в своем?

Есть вот как бы такие?

Ага.

А кто думает, что ситуация наоборот, и вообще не доверяют решениям других комиссий?

Спасибо.

Сомневаться — это хорошо.

Давайте посмотрим, в какую сторону это работает.

Оказалось, вот такая вот интересная статистика о том, что, ну да, можно заметить, что количество вот этих полностью уверенных, их подсократилось до примерно 50.

То есть скорее доверяю 50 на 50.

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

Ну потому что я же Д'Артаньян, а остальные сами понимаете кто.

Кстати, моя оценка попала в среднее внезапно.

Вот.

Может быть, без меня там было бы 2,5%.

Или там 2.

Ну, окей.

Ну, это понятно почему.

Потому что, как бы, когда ты делаешь свою работу, ты как бы в ней полностью уверен.

А как сделали другие люди, это под вопросом.

Но мы как раз над этой метрикой стараемся работать.

Как успешно, пока говорить рано.

Все-таки тут недостаточно много данных.

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

Вот тут я сейчас не привожу...

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

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

Это вроде логично.

Тем не менее, есть интересная статистика.

У нас 100% людей, которые пошли в комиссию, но не прошли, вот эти люди,

Когда они подаются повторно, допустим, через полгода или через какой-то другой период, 100% людей проходят повторно комиссию.

То есть важный момент.

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

Вот это, кажется, офигенный результат.

Но мы тоже часто стараемся сверяться с реальностью и проверять, а не сошли ли мы с ума.

Как это лучше всего сделать?

Например, поговорить с другими людьми.

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

И в этом году у нас на конфуре тоже мы проводили...

Вот такой постер от системы оценки инженеров.

И призвали.

Ребята, если вам есть что сказать, вы хотите о чем-то поговорить, приходите и пообщаемся.

Так вот.

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

И это мне кажется очень круто.

И я, работая, продолжая работать в компании, я как раз это в том числе очень сильно ценю.

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

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

Кто думает, что много людей говорят, что мы неправы?

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

Вот два человека.

Я не вижу, кто, но это, мне кажется, ребята из контура, нет?

Здесь, к сожалению, я вас не вижу.

Так вот, ноль человек сказали, что мы делаем что-то неправильно.

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

Вот такой интересный факт.

Так вот, как же в итоге становятся ведущими инженерами в контуре?

То есть, в принципе, получается несколько относительно первого слайда.

Ситуация поменялась.

У нас ведущий по-прежнему подает, кандидат ведущий, оговорочка, подает промодок.

Мы собираем обратную связь с него.

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

Эту обратную связь мы, соответственно, отправляем к комиссии.

Комиссия проводит встречу с кандидатом.

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

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

И уже после этого комиссия выносит решение.

Если комиссия выносит положительное решение, все супер.

Если решение отрицательное, внезапно у кандидата есть возможность подать апелляцию.

Он говорит, я не согласен, потому что комиссия не поработала с такими-то вещами.

Он подает апелляцию, и мы, соответственно, еще проводим примерно неделю для того, чтобы что-то с этим сделать.

В общем, такая получается система.

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

То есть вот это тоже для нас тем не менее важно, чтобы мотивация людей сохранялась.

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

Про это я чуть ранее говорил.

Так вот, тема, кажется, действительно такая неоднозначная.

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

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

Я не знаю, это, мне кажется, только в Твиттере бывает больше ее.

Что ж, на этом, наверное, все.

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

Если поэтому интересно, заходите, подписывайтесь.

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

Спасибо.

Гриша, спасибо большое.

Слушай, а я нашел, как вам попасть к ведущим, я уже ведущий, у меня даже на бейджике это написано.

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

Да, это очень хороший вопрос.

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

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

И потом сразу люди становились ведущими, то есть получали должность льда.

Так вот, ну, вот как-то даже naming грейдов подсказывает, что что-то неправильно, потому что, смотрите, у нас есть junior, middle,

Senior lead.

Так вот, senior по-русски это старший.

И в принципе в мире вот так оно присутствует.

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

У нас появились там с некоторых пор старшие инженеры-программисты.

И в целом, если ты дорос до старшего, ты можешь не брать там супер большую ответственность и дальше не расти, и как бы всем будет хорошо.

Можно ли остановиться на предыдущей ступеньке?

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

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

Согласен, я тоже так думаю.

Слушай, есть компании, в которых 17 грейдов и выше, ну это вообще жесть.

Друзья, задавайте вопросы, пожалуйста, я вот вижу, первые уже есть.

Здравствуйте, спасибо за доклад.

Три маленьких вопроса.

Первое, как я понял, было два опросника, один для кандидатов, которые переходят на ведущего, и, соответственно, комиссаров.

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

Какое количество людей заполнили вот эти анкеты?

Да, да.

Ну, суммарно, давайте так, порядок людей, которые ответили на анкету, среди комиссаров это, наверное, человек 70, а среди кандидатов, наверное, человек 40-50.

Комиссары активнее заполняют обратную связь.

Ну и количество комиссаров их больше, чем кандидатов.

Это текущего года или это в начале?

Статистику, да, я забыл про это сказать.

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

Получается, с середины 2022 по текущий 2023 год.

Спасибо.

А еще такой вопрос.

Предположим, если человек хочет перейти на техлида, были у вас такие ситуации, что сейчас нет проекта, где необходим этот техлид?

Смотрите,

Контур — это та компания, у которой все время запускаются какие-то новые продукты, поэтому нет такой ситуации, когда, типа, техлит не нужен.

Вот.

И с теми людьми, например, такая же история.

То есть вот когда я приходил в Контур, наверное, там у нас было порядка, наверное, 40 команд.

Я сейчас боюсь соврать, но, типа, такой где-то порядок.

Сейчас их у нас больше 100.

Там что-то 100, 120, где-то так.

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

И нет такого, что ты, типа, вырос, и дальше некуда деваться.

Но!

Это очень хорошо.

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

Вот это проблема.

И вот в этой ситуации как раз мы приходим и смотрим, как это можно решить.

Либо в текущем проекте все-таки там есть какой-то у них следующий левел-ап, но не всегда в проекте бывает такое.

Бывают проекты, у которых состояние поддержки.

И в этой ситуации мы развиваем горизонтальную мобильность.

Это что означает?

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

Я по совместительству являюсь функциональным руководителем.

В некотором количестве разработчиков, то есть у меня в функциональном подчинении порядка 40 человек, вот в год 20% людей вот этих вот между собой как-то перемещаются внутри компании.

То есть 20% за год.

Я считаю, что это очень крутой результат в плане мобильности.

То есть это стажировки, переходы.

Человек может прийти на стажировку, например, и вернуться обратно в свою команду, а может перейти на стажировку и в итоге там осесть и остаться.

То есть такое тоже происходит.

Ну плюс там еще и шаринг знаний между командами происходит.

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

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

А у вас были идеи сделать это в виде какой-то платформы, ну, то есть, где, например, можно получать ачивки, что-то там, внутренний LinkedIn, как-то так, чтобы, или, например, интегрировать свою сеть социальную внутреннюю?

Чтобы этот процесс был непрерывным.

Если человек хочет пройти вот этот субъект, он там что-нибудь нажимает.

То есть как-то это все сделать.

Типа какая-то геймификация у этой системы.

Ну что-то такое, да, допустим.

И оно будет непрерывно давать картину полную.

Я понял.

Это, кстати, хорошая идея.

У нас, получается, есть отдельно существует социальная своя сеть, в которой, да, там всякие ачивки есть и прочее.

Да-да-да.

И есть вот этот сервис, где мы даем друг другу обратную связь, где занимаемся тем, что ставим друг другу цели.

Или ты себе ставишь цели, и их валидирует функциональная зона, или твой менеджер.

Правильно говорить, не «или», а «и».

Это происходит совместно.

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

Возможно, да, надо вот как-то в эту сторону завернуть.

Просто этих магов отображать, короче.

Идея хорошая, да.

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

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

Смотрите, вот пришел разработчик младшим, ну, младшим инженером.

Через год он стал мидлом.

И вот смотрите, он оставался с должностью инженер-программист, инженер-программист, потому что мидл, мидл плюс, должность одна и та же.

А в какой-то момент становился ведущим.

И получается, что у человека за всю его карьеру вот эта смена должности по инженерному треку, она всего по сути одна.

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

Так вот.

И это как-то довольно грустно.

То есть ты такой работаешь, работаешь, работаешь, а вот такого типа вот этой ачивки, о которой была речь, ты как бы не видишь.

Но когда вот мы сделали должность старшего, люди сразу заметили, что это круто.

То есть ты работаешь, там, хоп, у тебя первый промоут произошел.

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

Это в этом плане кажется тоже классно.

И вот это перекликается с идеей вот этих ачивок, что человек хочет увидеть, что вот что-то поменялось.

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

пирамиды масла, должно быть какое-то признание.

Спасибо, Гриш.

Спасибо за доклад.

Хотел уточнить по поводу профилей.

Вы сказали, что фичи льды делятся на два подтипа, которые тех специалистов хорошо тащат по коду и по процессу.

Разве у вас процесс не выстроен?

Как он на своей фиче выстроил отдельный процесс от остальных фич?

Это очень хороший вопрос.

Вот у нас во многих проектах вообще фичеледами внезапно являются аналитики.

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

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

В разных проектах, в разных направлениях оно по-разному.

Внезапно оказывается, что там специфика разработки в разных направлениях, она своя.

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

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

Типа, разработка запустилась, грубо говоря, вот в этом году.

Это вообще какое-то новое направление.

И там такой дух стартапов происходит.

То есть там у Эдо это активное масштабирование, а здесь такой дух стартапа.

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

Но я согласен с тем, что, вообще-то говоря, если мы...

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

Но, как я говорю, у нас есть второй трек фичелида.

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

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

Но важный момент, кстати, вот фичелит по описанию уже похоже на менеджера такого, да, классического.

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

И в целом это справедливо.

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

Он должен за архитектуру зарешать и проработать с нефункциональными требованиями и прочее.

Это тем не менее тоже остается.

В первую очередь мы говорим о том, что инженер должен оставаться инженером.

Спасибо.

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

Уходят в менеджеры, в менеджеры проектов.

Это такое происходит.

Вот, например, я из ведущего инженера перерос в функционального руководителя.

То есть, грубо говоря, это тоже ответственность за людей.

То есть это тоже такой своего рода people-менеджер.

Ну, то есть это к тому, что это не потолок.

Дальше тоже можно расти.

Да.

Но вообще мы считаем, что инженер-программист, это нет у него потолка.

Ты можешь расти дальше, дальше и дальше.

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

Спасибо за доклад.

Мне интересно, как часто можно подаваться на повышение грейда в год?

Да, это хороший вопрос.

И смотрите, если говорить про цепочку от джуниора к старшему, у нас есть пересмотры два раза в год.

Один он фиксированный зимой, в феврале условно, плюс-минус полмесяца-месяц.

А второй, мы называем его синхронным, потому что он растянут во времени с весны по конец осени.

Почему именно так?

То есть раньше у нас было четко...

раз в полгода, а здесь сделали один плавающий.

Потому что, ну, какие-то результаты, которые, да, вот это, кстати, важный момент оценки, что у нас вся оценка идет от результата.

Есть результат, есть промоут.

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

Так вот, возвращаясь к этой оценке, то есть почему именно плавающий второй?

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

В сентябре или октябре.

И получается, что тебе нужно пропустить цикл и ждать подкрепляющей обратной связи, что тебя запромотили еще 4 месяца, например, с октября по февраль.

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

Это вот по поводу от джуниора до старшего.

А вот из старшего ведущего у нас ограничения какого-то нет.

То есть, типа, если пришел в одну комиссию и не прошел,

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

Такого ни разу не было.

Но люди как-то сами понимали, в какой момент надо податься, интуитивно или еще как-то, и успешно переводились.

Никто эту систему не абьюзил в этом случае.

И еще один вопрос.

Сколько часов тратит компания на то, чтобы апнуть человека?

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

Потом еще дать фидбэк и кажется, что это достаточно много времени занимает.

Спасибо, это очень классный вопрос.

Наверное, этот вопрос заслуживает книги, потому что время оценки... Спасибо.

Очень классный вопрос.

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

Ну, типа, понятно, у нас понятный процесс, все хорошо.

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

Мы могли просто катнуть одно приложение, все хорошо.

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

То есть получается, что из-за того, чтобы получить возможность масштабироваться горизонтально,

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

Так вот, здесь примерно так же.

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

Это был осознанный шаг.

Можно ли сделать дешевле или нет?

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

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

Вот прямо сейчас у меня ответа нет на этот вопрос.

Мы сейчас в процессе находимся.

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

То есть вот

Через полгода я, может быть, вот... А, тоже убрали мою презентацию.

Там, как раз, где вот канал, я обязательно туда про это напишу.

Потому что вопрос действительно классный.

И про это, да, вот туда я напишу.

Потому что очень классный вопрос.

И вот стоимость этого всего, это действительно очень важный момент.

Еще и как считать это сложно.

То есть там, о господи, сколько там копий было сломано.

Я думал, тот вот старичок, это выгоревший менеджер.

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

Так, у нас еще есть вопрос.

Да, да, да.

Друзья, у кого еще есть вопросы?

Пока несут микрофон.

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

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

Это было понятно, что такое может произойти.

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

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

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

Слушай, ну это круто на ваших объемах.

Спасибо за доклад.

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

Вот этот момент как-то учитывается?

Тоже хороший вопрос.

Смотрите, вот четвертый портрет про Rocket Science.

Он называется Rocket Science, про технические сложности сдачи.

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

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

Мы даже название-то для него не придумали.

Как это, блин, назвать?

Что это такое должно быть одним словом?

Непонятно.

Вот этот момент.

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

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

Видимо, имелось в виду все-таки, что согласованность.

А, да, смотрите, если человек донес свою идею, продал ее и реализовал, это очень похоже на фичи Лида, кстати, внезапно.

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

Вот он пришел с этой идеей, продал ее команде, организовал процесс так, что в конце получилось, получил эти метрики и в конце показал, смотрите, как классно, то есть результат продемонстрировал.

Это очень крутой пример на Лида.

Прям вот это топ.

Я раньше думал, что фичеридов не существует.

Вот, типа, до вот этой комиссии.

Это все выдумка.

Да, это выдумка, типа, вот.

Хотя просто другие, я говорю, в промодок это почему увидели?

Потому что некоторые фичериды, они написали, вот я вот такой-то, и это меня убедило.

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

Гриш, у нас еще там есть?

Да, еще такой вопрос.

Спасибо за доклад.

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

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

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

то собеседование выглядит немножко по-другому, наверное, процесс найма.

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

Или наоборот, им сложнее, и там, не знаю, люди... Не знаю.

Тоже классный вопрос.

К сожалению, у меня нет еще одной книги.

Нет, достаточно.

Но вопрос действительно очень классный.

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

Здесь есть некоторый элемент доверия.

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

Ну там время на написание промодока, конечно, какое-то потребуется, но вот именно само общение с комиссией, оно у нас в среднем по статистике это час.

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

Если там есть какие-то вопросы, там, конечно, она может увеличиться.

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

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

Но понятно, что там дальше есть история про испытательный срок.

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

Ну, вот так, да.

Слушай, а у вас это только с технической стороны?

Только технические специалисты у вас проходят такую модерацию и становятся ведущими?

Или у вас и для менеджеров, для других каких-то профессий тоже есть это?

Я точно знаю, что у тестировщиков вот эти истории с промоутом, по-моему, они начались раньше, то есть у них там были свои эти комиссии.

Я не знаю, как они выглядят, к сожалению, но точно у них есть.

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

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

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

Потом туда добавились различные инженерные роли, инженер эксплуатации, вот это туда добавилось.

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

И вот мы постепенно вот так вот расширяемся.

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

Продукты, которые контур продает.

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

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

Но тем не менее, комиссии, они у нас стали сквозные.

То есть мы и тех ребят тоже через эту комиссию проводим.

Есть же и DevOps, и все остальные.

DevOps, да, они все идут по вот этой инженерной нашей схеме.

Поэтому я сказал, это не комиссия инженеров-программистов, она именно из инженеров.

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

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

С...

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

Да-да-да, то есть мы метрики такие собираем, вот с этим работаем.

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

Вот есть кто-нибудь, у кого идеально с метриками в проекте?

Вот, ну, также вот у нас проект, в котором не все идеально.

Слушай, там есть люди.

О, прикольно.

Приходите в дискуссию, поговорим про это.

Гриша, спасибо тебе большое.

Всем спасибо.

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

Плюс там сейчас будет еще онлайн.

Я думаю, оттуда тоже прилетит довольно-таки много вопросов.

Да, спасибо.