Комментарии 25
Подробно про схему оценивания можно посмотреть в докладе veged Ревью: Как устроена система оценки производительности сотрудников в Яндексе.
имитация бурной деятельности в компании не приветствуется и игнорируется
Имитация действительно игнорится, т.к. есть четкие вычислимые метрики успеха.
объективные причины неудач никому не интересны
Причины неудач и правда менее важны, чем сам факт удачи/неудачи. Но это явное отражения реального мира:
* достигли успеха -> заработали денег -> часть этих денег потратили на повышения/премии
* не достигли успеха -> денег на премии нет :(
При этом здравый смысл никто не отменяет и, если всем участникам обсуждения очевидно, что проделана грандиозная работа, но по независящим от разработки причинам успех не достигнут, то какой-то компромис, конечно, будет найден.
Из статьи складывается впечатление, что получившаяся организация не имеет недостатков. Однако:
Они друг с другом будут договариваться, как-то друг другу помогать, и в итоге всё будет хорошо.
… и жили они долго и счастливо. Наивно полагать, что люди вдруг перестанут быть людьми. Станут винтиками, работающими исключительно на общее благо, но не на свои потребности. Что предъявляемые к ним требования не будут противоречивыми. И конечно, что они не будут продавливать те решения, которые выгодны лично им. Уверен, далеко не все поддерживают текущее внедрение Реакта, например. В бинарных решениях невозможно договориться. Тут либо один продавливает своё, а другой сдаётся, либо наоборот. Ну либо битва затягивается и по шапке получают оба, а решение принимается рандомное.
Если ты выделяешься, даже особо не напрягаясь — красавчик, давай тебя похвалим.
Что приводит к тому, что промоутится тот, у кого больше визибилити. Тут важно понимать, что выстраивая систему обратной связи вы фактически решаете, какие метрики будут оптимизироваться в ущерб всем остальным. Хороший антипример — Гугл, где разработчикам выгоднее пилить новые фичи, а не латать дыры в существующих. Латание дыр не так заметно. И особенно обидно, когда дыры в архитектуре сделаны не тобой, но ты от них огребаешь. И понимаешь, что что-либо сильно исправить не получится, так как нужно много с кем договариваться. А у этих много кого ни времени, ни желания.
Кроме обмена экспертизой, переходы людей позволяют сделать разные продукты более похожими друг на друга — и в терминах того, как они выглядят, и в терминах того, как они устроены внутри.
У этой медали есть и обратная сторона — стагнация. Внедрение инноваций становится существенно более сложным процессом. Внедряются они с боем, с запозданием. И хорошо, если "договорились" о правильном пути. А если путь оказался ошибочным, то разворачивать несущийся по рельсам поезд — задача не из простых и быстрых. В этом свете возможность в разных проектах использовать разные подходы без лишних проволочек, позволяет куда быстрее экспериментировать и отметать нежизнеспособное, рискуя лишь одним проектом, а не всеми.
они, возможно, сами вскоре перейдут в другую команду. Им очевидно, что, условно, завтра это их коснется. Поэтому при фокусировке не теряется ответственность за всё целиком.
Или наоборот — безответственность. Нет смысла что-то сильно менять в одном проекте, если завтра ты перейдёшь в другой, а там опять те же грабли разбросаны. Собственно, опыт аутсорсинговых/консалтинговых компаний показывает, что если разработчик является приходящим, то культура программирования быстро скатывается в бездну. Мало кто является скаутом, чтобы оставлять место после себя чище, чем оно было до.
мы собрались, обсудили, какие требования от кандидата нас бы всех устраивали, и ровно такие требования мы спрашиваем со всех.
Так какие требования-то? Есть разные типы людей. И у них лучше получаются разные вещи. Кто-то хорош в проектировании, но плохо кодит. Кто-то наоборот. Кто-то зажигает на субботниках, а кто-то двух слов связать не может. Кто-то обожает писать тесты, а кто-тот их ненавидит. Если всех грести одной гребёнкой — легко получить серую массу посредственностей. Если же собирать сбалансированные команды людей, где каждый хорош в чём-то своём, то в результате есть риск получить синергию.
В бинарных решениях невозможно договориться.
Но как ни удивительно, это удается. И пример с внедрением Реакта — это как раз очередная иллюстрация. Архитектурная команда договорилась с командой скорости, что найдет такой способ его внедрить, что быстродействие не пострадает. Кроме того, команда, отвечающая за консистентность дизайна, валидирует, что в переходный период компоненты на новом и на старом стеке будут выглядеть одинаково. И так далее.
Латание дыр не так заметно
Латание слабо заметно, если нет метрики cicletime поставки фич в продакшен, которая неизбежно будет ухудшаться, если не разгребать легаси или если нет метрики про факапы.
У нас помимо этого есть сквозная метрика на баги с жестки SLA на их исправление.
В итоге нет никаких проблем с заметностью всех подобных активностей.
Нет смысла что-то сильно менять в одном проекте, если завтра ты перейдёшь в другой, а там опять те же грабли разбросаны.
Не совсем так. Скажем, переход из условной команды про скорость в команду про архитектуру или покрытие автотестами не предполагает смену проекта, а только смену области ответственности.
разворачивать несущийся по рельсам поезд — задача не из простых и быстрых
Это правда. Но разворачивать 100500 отдельных вагонов, спроектированных под разную ширину колеи — еще сложнее.
Если же собирать сбалансированные команды людей, где каждый хорош в чём-то своём, то в результате есть риск получить синергию.
Так ведь именно эту задачу и решает наш подход! Мы отбираем людей по базовым универсальным навыкам, а потом подбираем им виртуальную команду под их персональные скиллы.
И пожалуй я в такой «системе» работать не особо хочу. Но это какое-то внутреннее и не до конца сформировавшееся/сформулированное «не хочу».
И хорошо бы посмотреть как оно всё будет через год-два-пять.
Из статьи не очень понятно, речь о том что можно перебегать только между подкомандами Поиска, или из Авто в Маркет тоже?
Яндекс это компания каких-то крайностей. Будь целью отжать у Яндекса остатки умных кадров, я бы форсил аналогичную схему. В самом деле, работать в формате типичных "галер", где качующий между проектами стаф это тупо ресурсы, с матричным менеджментом, персональными планами развития, и разной мотивационной ерундой, согласятся не все. Кто по сообразительнее уйдет на рынок, благо интересных предложений достаточно.
а) компания стабильно растет по количеству разработчиков
б) время работы людей в компании выше, чем в среднем по рынку
Возможность поменять команду без смены компании — это дополнительный способ не скучать и все время заниматься тем, что тебе на данный момент интересно.
Спасибо за развернутый ответ. Вопрос возник вот почему. Недавно чистил контакт лист на телефоне. Спустя пять лет больше половины контактов из Яндекса теперь работают в других компаниях. Ребята были очень толковые, поэтому был немного удивлен. Допускаю, что выборка может быть не репрезентативной или пять лет это дольше, чем в среднем по рынку.
Рост по количеству разработчиков полезен аутсорс компаниям, процессы которых вы вероятно адаптируете. При частых ротациях производительность людей закономерно падает на время адаптации и дело тут не только в технологиях. Но аутсорс эти моменты легко конвертирует в доходы, увеличивая сроки и продавая все больше светлых) голов с красивыми тайтлами. Каковы преимущества для продуктовой(?) компании в увеличении штата?
Каковы преимущества для продуктовой(?) компании в увеличении штата?
Например, в возможности делать больше продуктов одновременно: yandex.ru/all.
Или более сложные продукты. Вряд ли на аутсорсе в принципе возможно делать проект масштабов Поиска.
1. Вы говорите, что есть bootcamp, новый разработчик ходит по командам, работает по 2 недели в каждой и выбирает ту, что больше понравилась. Но, обычно, у нас есть спрос на новых людей в определенных командах больше, а в других меньше. А разработчик выберет команду, где сейчас расширение команды и не требуется особо. При распределении новичков вы как-то учитываете запрос самих команд на пополнение?
2. Идея с виртуальными командами и ротацией интересна. Не получается ли так, что была команда из ребят, которые все в московском офисе, а в ходе ротации пришел человек из, условно, новосибирского офиса. И из-за этого им нужно сильно менять процессы в команде? Я понимаю, когда более менее равномерно распределенная команда или полностью локализованная. Но как вы организуете эту ротацию с учетом нескольких локализованных команд, если у вас таковые есть, конечно.
3. Еще один вопрос про виртуальные команды. А тимлиды команд тоже могут ротироваться? Или в этой точке команды неизменными остаются.
При распределении новичков вы как-то учитываете запрос самих команд на пополнение?
Конечно. Мы предлагаем поработать именно в тех командах, которые сейчас ищут себе людей. В Яндексе таких команд всегда заметно больше, чем человек успеет обойти за время буткемпа.
Не получается ли так, что была команда из ребят, которые все в московском офисе, а в ходе ротации пришел человек из, условно, новосибирского офиса.
Такое случается и такие моменты всегда согласуются с командами. Бывает, что команда говорит «извини, но мы не готовы сейчас расширятся на новый город». Но все понимают, что чем сильнее распределена команда, тем быстрее она в итоге сможет закрыть свою вакансию. Мы стараемся выстраивать все процессы так, чтобы взаимодействие между офисами требовало минимум накладных расходов.
А тимлиды команд тоже могут ротироваться?
Ротироваться могут все, если хотят. Здесь работает очень простой принцип — лучше человек поменяет команду внутри компании, чем поменяет компанию. Тем более, если это опытный тимлид.
Сбалансированная разработка в очень больших командах. Доклад Яндекса