Методика подсказывает, что при наличии достаточного количества внедрений, оптимизировать стоимость унификации особого смысла нет. А вот на оптимизации внедрений действительно важно сосредоточиться.
При распределении новичков вы как-то учитываете запрос самих команд на пополнение?
Конечно. Мы предлагаем поработать именно в тех командах, которые сейчас ищут себе людей. В Яндексе таких команд всегда заметно больше, чем человек успеет обойти за время буткемпа.
Не получается ли так, что была команда из ребят, которые все в московском офисе, а в ходе ротации пришел человек из, условно, новосибирского офиса.
Такое случается и такие моменты всегда согласуются с командами. Бывает, что команда говорит «извини, но мы не готовы сейчас расширятся на новый город». Но все понимают, что чем сильнее распределена команда, тем быстрее она в итоге сможет закрыть свою вакансию. Мы стараемся выстраивать все процессы так, чтобы взаимодействие между офисами требовало минимум накладных расходов.
А тимлиды команд тоже могут ротироваться?
Ротироваться могут все, если хотят. Здесь работает очень простой принцип — лучше человек поменяет команду внутри компании, чем поменяет компанию. Тем более, если это опытный тимлид.
Каковы преимущества для продуктовой(?) компании в увеличении штата?
Например, в возможности делать больше продуктов одновременно: yandex.ru/all.
Или более сложные продукты. Вряд ли на аутсорсе в принципе возможно делать проект масштабов Поиска.
Однако реальность такова, что
а) компания стабильно растет по количеству разработчиков
б) время работы людей в компании выше, чем в среднем по рынку
Возможность поменять команду без смены компании — это дополнительный способ не скучать и все время заниматься тем, что тебе на данный момент интересно.
На текущий момент мы активно предлагаем переходы между командами Поиска.
При этом ротация в другие юниты разрешена, но требует прохождения внутреннего собеседования.
Но как ни удивительно, это удается. И пример с внедрением Реакта — это как раз очередная иллюстрация. Архитектурная команда договорилась с командой скорости, что найдет такой способ его внедрить, что быстродействие не пострадает. Кроме того, команда, отвечающая за консистентность дизайна, валидирует, что в переходный период компоненты на новом и на старом стеке будут выглядеть одинаково. И так далее.
Латание дыр не так заметно
Латание слабо заметно, если нет метрики cicletime поставки фич в продакшен, которая неизбежно будет ухудшаться, если не разгребать легаси или если нет метрики про факапы.
У нас помимо этого есть сквозная метрика на баги с жестки SLA на их исправление.
В итоге нет никаких проблем с заметностью всех подобных активностей.
Нет смысла что-то сильно менять в одном проекте, если завтра ты перейдёшь в другой, а там опять те же грабли разбросаны.
Не совсем так. Скажем, переход из условной команды про скорость в команду про архитектуру или покрытие автотестами не предполагает смену проекта, а только смену области ответственности.
разворачивать несущийся по рельсам поезд — задача не из простых и быстрых
Это правда. Но разворачивать 100500 отдельных вагонов, спроектированных под разную ширину колеи — еще сложнее.
Если же собирать сбалансированные команды людей, где каждый хорош в чём-то своём, то в результате есть риск получить синергию.
Так ведь именно эту задачу и решает наш подход! Мы отбираем людей по базовым универсальным навыкам, а потом подбираем им виртуальную команду под их персональные скиллы.
Зарплата (как и премия) не зависит от команды и выставляется по результатам собеседований. Вероятность получения премий никто не скрывает, но оффер формулируется ровно с тем, что мы готовы предложить человеку изначально.
имитация бурной деятельности в компании не приветствуется и игнорируется
Имитация действительно игнорится, т.к. есть четкие вычислимые метрики успеха.
объективные причины неудач никому не интересны
Причины неудач и правда менее важны, чем сам факт удачи/неудачи. Но это явное отражения реального мира:
* достигли успеха -> заработали денег -> часть этих денег потратили на повышения/премии
* не достигли успеха -> денег на премии нет :(
При этом здравый смысл никто не отменяет и, если всем участникам обсуждения очевидно, что проделана грандиозная работа, но по независящим от разработки причинам успех не достигнут, то какой-то компромис, конечно, будет найден.
Если коротко, то идея такая: люди, которые «просто поработали» просто получат зарплату, а те, кто поработал лучше других получит премию и (возможно) повышение.
Я не могу отвечать за весь Яндекс. В моей области ответственности проекты с нуля случаются раз в сто лет. Вероятность переписывания существующих проектов, где я принимаю участие, на $mol на текущий момент стремится к нулю.
Как известно, есть ложь, наглая ложь и статистика ;)
При желании можно сравнивать количество коммитов в день, количество коммитов от менее активных контрибьюторов или наоборот гордиться, что коммитов так мало, потому что ядро более-мене стабилизировалось (или в основном идет во внутренней системе контроля версий определенной корпорации ;)
Еще можно считать количество сопутствующего кода, статей, обучающих видео и так далее.
Статистика благодушно позволит защитить совершенно любую точку зрения )
Но вот с аргументом про Ангуляр действительно невозможно спорить.
… или просто стабильно увеличивать штат на заметный процент.
А какова величина этого шанса, что сообщество решит какою-либо проблему до вашего дедлайна?
Предположу, что примерно на 2 порядка выше, чем в случае с фреймворком, где на 2 порядка меньше контрибьюторов.
Кроме того, несравнимо выше шанс, что когда один конкретный автор фреймворка устанет им заниматься, комьюнити не даст ему загнуться (нужно понимать, что переезд со стека на стек в масштабах Яндекса — это миграция на несколько лет).
Как минимум по тем же причинам, по которым мигрируем с собственного стека технологий, базирующегося на соглашениях, на явное — ниже порог входа, гораздо выше поддержка всевозможных инструментов (в частности мы повсеместно переходим на TypeScript), размер сообщества (а значит — шанс, что в ближайшем будущем проблемы будут исправлены, а новые фичи внедрены) и так далее.
Сложно утверждать, что современный Реакт — это предел мечтаний. Но если проследить его эволюцию, видно, что и ядро, и экосистема развиваются достаточно быстро, благодаря огромному сообществу.
Мы верим, что именно сообщество со временем позволит Реакту получить все лучшее из других миров, как это когда-то произошло с jQuery. А потом, как и jQuery, Реакт выйдет на пенсию. Но еще до этого все забудут несколько сотен опередивших свое время фреймворков ;)
заняться поддержкой и продвижением $mol хотя бы том же уровне на котором вы поддерживаете bem-react
Поддержкой bem-react мы занимаемся не только из любви к искусству, но и потому что сами его используем в собственных проектах в продакшене. Будет странно, если мы начнем активно развивать технологию, опыта с которой у нас нет. Но мы готовы помочь сообществу $mol консультациями по части интеграции с БЭМ, если таковые потребуются.
Ровно по такой логике мы и проектировали компоненты раньше. И до сих пор большая часть кодовой базы по-прежнему реализована на идеях, схожих с MAM.
К моему личному сожалению, безграничная гибкость БЭМ-стека новым разработчикам «заходит» хуже, чем явные импорты, пусть даже и требующие рефакторить компоненты каждый раз, когда становится понятно, что вовремя забыли позаботиться о кастомизации на будущее.
Конечно. Мы предлагаем поработать именно в тех командах, которые сейчас ищут себе людей. В Яндексе таких команд всегда заметно больше, чем человек успеет обойти за время буткемпа.
Такое случается и такие моменты всегда согласуются с командами. Бывает, что команда говорит «извини, но мы не готовы сейчас расширятся на новый город». Но все понимают, что чем сильнее распределена команда, тем быстрее она в итоге сможет закрыть свою вакансию. Мы стараемся выстраивать все процессы так, чтобы взаимодействие между офисами требовало минимум накладных расходов.
Ротироваться могут все, если хотят. Здесь работает очень простой принцип — лучше человек поменяет команду внутри компании, чем поменяет компанию. Тем более, если это опытный тимлид.
Например, в возможности делать больше продуктов одновременно: yandex.ru/all.
Или более сложные продукты. Вряд ли на аутсорсе в принципе возможно делать проект масштабов Поиска.
а) компания стабильно растет по количеству разработчиков
б) время работы людей в компании выше, чем в среднем по рынку
Возможность поменять команду без смены компании — это дополнительный способ не скучать и все время заниматься тем, что тебе на данный момент интересно.
При этом ротация в другие юниты разрешена, но требует прохождения внутреннего собеседования.
Но как ни удивительно, это удается. И пример с внедрением Реакта — это как раз очередная иллюстрация. Архитектурная команда договорилась с командой скорости, что найдет такой способ его внедрить, что быстродействие не пострадает. Кроме того, команда, отвечающая за консистентность дизайна, валидирует, что в переходный период компоненты на новом и на старом стеке будут выглядеть одинаково. И так далее.
Латание слабо заметно, если нет метрики cicletime поставки фич в продакшен, которая неизбежно будет ухудшаться, если не разгребать легаси или если нет метрики про факапы.
У нас помимо этого есть сквозная метрика на баги с жестки SLA на их исправление.
В итоге нет никаких проблем с заметностью всех подобных активностей.
Не совсем так. Скажем, переход из условной команды про скорость в команду про архитектуру или покрытие автотестами не предполагает смену проекта, а только смену области ответственности.
Это правда. Но разворачивать 100500 отдельных вагонов, спроектированных под разную ширину колеи — еще сложнее.
Так ведь именно эту задачу и решает наш подход! Мы отбираем людей по базовым универсальным навыкам, а потом подбираем им виртуальную команду под их персональные скиллы.
Имитация действительно игнорится, т.к. есть четкие вычислимые метрики успеха.
Причины неудач и правда менее важны, чем сам факт удачи/неудачи. Но это явное отражения реального мира:
* достигли успеха -> заработали денег -> часть этих денег потратили на повышения/премии
* не достигли успеха -> денег на премии нет :(
При этом здравый смысл никто не отменяет и, если всем участникам обсуждения очевидно, что проделана грандиозная работа, но по независящим от разработки причинам успех не достигнут, то какой-то компромис, конечно, будет найден.
Подробно про схему оценивания можно посмотреть в докладе veged Ревью: Как устроена система оценки производительности сотрудников в Яндексе.
Да, можем считать этот комментарий приглашением ;)
Детали готов обсудить в почте: tadatuta@yandex-team.ru.
При желании можно сравнивать количество коммитов в день, количество коммитов от менее активных контрибьюторов или наоборот гордиться, что коммитов так мало, потому что ядро более-мене стабилизировалось (или в основном идет во внутренней системе контроля версий определенной корпорации ;)
Еще можно считать количество сопутствующего кода, статей, обучающих видео и так далее.
Статистика благодушно позволит защитить совершенно любую точку зрения )
Но вот с аргументом про Ангуляр действительно невозможно спорить.
… или просто стабильно увеличивать штат на заметный процент.
Предположу, что примерно на 2 порядка выше, чем в случае с фреймворком, где на 2 порядка меньше контрибьюторов.
Кроме того, несравнимо выше шанс, что когда один конкретный автор фреймворка устанет им заниматься, комьюнити не даст ему загнуться (нужно понимать, что переезд со стека на стек в масштабах Яндекса — это миграция на несколько лет).
Мы верим, что именно сообщество со временем позволит Реакту получить все лучшее из других миров, как это когда-то произошло с jQuery. А потом, как и jQuery, Реакт выйдет на пенсию. Но еще до этого все забудут несколько сотен опередивших свое время фреймворков ;)
Поддержкой bem-react мы занимаемся не только из любви к искусству, но и потому что сами его используем в собственных проектах в продакшене. Будет странно, если мы начнем активно развивать технологию, опыта с которой у нас нет. Но мы готовы помочь сообществу $mol консультациями по части интеграции с БЭМ, если таковые потребуются.
В документации репозитория описано и как подключиться к обсуждению/разработке и мотивация, почему все сделано именно так, как оно сделано: github.com/bem/bem-react/blob/master/docs/ru/Introduction/Motivation.md
Всегда рады конструктивной критике и предложениям!
К моему личному сожалению, безграничная гибкость БЭМ-стека новым разработчикам «заходит» хуже, чем явные импорты, пусть даже и требующие рефакторить компоненты каждый раз, когда становится понятно, что вовремя забыли позаботиться о кастомизации на будущее.