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

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

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

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

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

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

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

Каковы преимущества для продуктовой(?) компании в увеличении штата?

Например, в возможности делать больше продуктов одновременно: yandex.ru/all.
Или более сложные продукты. Вряд ли на аутсорсе в принципе возможно делать проект масштабов Поиска.

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

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

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

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

В бинарных решениях невозможно договориться.

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

Латание дыр не так заметно

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

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

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

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

разворачивать несущийся по рельсам поезд — задача не из простых и быстрых

Это правда. Но разворачивать 100500 отдельных вагонов, спроектированных под разную ширину колеи — еще сложнее.

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

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

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

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

имитация бурной деятельности в компании не приветствуется и игнорируется

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

объективные причины неудач никому не интересны

Причины неудач и правда менее важны, чем сам факт удачи/неудачи. Но это явное отражения реального мира:
* достигли успеха -> заработали денег -> часть этих денег потратили на повышения/премии
* не достигли успеха -> денег на премии нет :(

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

Если коротко, то идея такая: люди, которые «просто поработали» просто получат зарплату, а те, кто поработал лучше других получит премию и (возможно) повышение.

Подробно про схему оценивания можно посмотреть в докладе veged Ревью: Как устроена система оценки производительности сотрудников в Яндексе.

пригласить vintage в здание 1 на ул. Казанской с докладом о $mol в вашей области ответственности?

Да, можем считать этот комментарий приглашением ;)
Детали готов обсудить в почте: tadatuta@yandex-team.ru.

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

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

… или просто стабильно увеличивать штат на заметный процент.

А какова величина этого шанса, что сообщество решит какою-либо проблему до вашего дедлайна?

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

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

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

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

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

заняться поддержкой и продвижением $mol хотя бы том же уровне на котором вы поддерживаете bem-react

Поддержкой bem-react мы занимаемся не только из любви к искусству, но и потому что сами его используем в собственных проектах в продакшене. Будет странно, если мы начнем активно развивать технологию, опыта с которой у нас нет. Но мы готовы помочь сообществу $mol консультациями по части интеграции с БЭМ, если таковые потребуются.

Мы ведем разработку и обсуждение максимально открыто на github: github.com/bem/bem-react

В документации репозитория описано и как подключиться к обсуждению/разработке и мотивация, почему все сделано именно так, как оно сделано: github.com/bem/bem-react/blob/master/docs/ru/Introduction/Motivation.md

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

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

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