company_banner

Сбалансированная разработка в очень больших командах. Доклад Яндекса

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

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



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

    И хочется, чтобы они работали так же слаженно, как эти ребята на гифке:



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

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

    И среди этих «много» бо́льшая часть — разработчики. Мы делаем много разных продуктов, не только для веба. Есть всякое про товары, про машины, про покушать, железяки всякие, искусственный интеллект. И в этом всём участвуют разработчики. Даже если, казалось бы, речь про машины или про еду.



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

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

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



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



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



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



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

    И он говорит: «Товарищ главный дизайнер, у меня классная идея. Мне нужен дизайнер». Тот ответит: «Ну, во-первых, идея у тебя странная, во-вторых, у меня все дизайнеры заняты. Приходи в Q5».

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

    Потом этот менеджер пойдет к главному разработчику, скажет: «У меня есть классный дизайн, офигенная идея. Мне нужен бэкэндер». И всё это будет продолжаться: «Бэкэндер занят, идея у тебя так себе, дизайн плохой».



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



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



    Очевидно, у такого подхода есть проблема. Разработчики не сильно переживают про то, что там с продуктом, потому что менеджерам они не подчиняются. Менеджерам по каске настучат, если что-то пойдет не так, но на разработчиков они особого влияния не имеют. А продактам, в свою очередь, достаточно сложно это поменять. Они могут, по сути, только уговаривать, убеждать, и как-то танцами доказывать, что их идея классная. Тогда разработчик в нее поверит и, конечно, сделает всё зашибись.

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

    А пока все это происходит, компания берет и вырастает вдвое за год. И нужно что-то делать. Как говаривал Аркадий Волож, управлять компанией — это как жарить котлетку. Её нужно постоянно переворачивать.



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

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



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

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



    Хочется это всё как-то сбалансировать с точки зрения продукта. Например, есть команда у какого-то продукта и она, допустим, считает, что важен красивый код. И пока они затачивают этот код до идеала, понятно, откладываются релизы. Не круто. Или команда считает: «Ладно, лишь бы были классные процессы, а код как-то сам случится». На самом деле, нет, сам не случается. Тоже нужно, чтобы за этим, чтобы кто-то следил.

    Или команда говорит: «Нам нужно очень быстро двигаться вперед, нам важно, чтобы мы катили фичи каждый день», но в этот момент ускользает из внимания качество кода. Или команда говорит: «Ладно, мы в прошлый раз уже походили по граблям, поняли, что качество — это важно. Давайте всё покроем автотестами». На каждую фичу пишут автотесты, но теперь эти тесты надо запускать на каждый пул-реквест, и они долго выполняются, и всё становится медленно.

    Или: «Мы знаем, что наши пользователи, если интерфейс работает медленно, уходят. Давайте мы будем делать интерфейсы быстрыми». Но тогда получается, что каждая новая фича — это лишний код, который нужно передать по сети и выполнить, и он замедляет интерфейс. «Тогда давайте не делать новые фичи — будет быстрее всё работать». Или: «Пользователь любит, когда красиво. Давайте делать красиво». Но становится неважно, что там внутри.

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



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



    Но всё равно есть проблема. Например, предполагается, что такие скрам-команды постоянно подстраиваются под происходящее вокруг, постоянно меняются (меняется их состав, они могут постоянно формироваться, расформировываться), и в принципе не существует никакого общего места, где бы агрегировалась история развития сотрудника.

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

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

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



    Команды временные, быстрые, они могут фокусироваться на каких-то самых критичных в данный момент штуках.



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



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

    Но и наоборот, команда, которая отвечает за фичи, не может теперь накидать кучу нового кода и сказать: «Вот нам надо было запустить фичи, всё стало медленнее, но зато мы фичи запустили». Они друг с другом будут договариваться, как-то друг другу помогать, и в итоге всё будет хорошо. Синие чуваки пишут тесты, неистово, постоянно. И всё покрыли тестами, и тестов теперь много, и все они работают медленно. А чувакам всё равно, потому что они только за покрытие отвечают.

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

    Кто-то отвечает только за то, чтобы всё архитектурно было здорово. Причем им, возможно, не приходится даже думать о том, что прямо сейчас происходит в коде. Они могут думать в терминах: «А куда всё должно двигаться через полтора года?» — и уже прямо сейчас сосредотачиваться на этом будущем. Но при этом будет кто-то, кто подтюнит круглые уголки, поправит тени и будет думать про анимацию, чтобы пользователь уже завтра был счастливее. И когда такое распределение ответственности есть, и каждая команда взаимно дополняет друг друга, получается баланс.

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

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



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



    ОК, вроде договорились, как всё должно работать. Но если у нас есть начальник структурный и начальник про продукт, как потом оценить, получилось ли всё хорошо? Про это подробно рассказывал Сергей Бережной на позапрошлом Субботнике. Я в двух словах повторю общую идею.

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



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

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

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

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



    Конечно, можно сказать: «А как у вас с тем, чтобы все технологии в итоге были одинаковые, если все равно в самом верху есть деление по продукту?». Эту проблему мы пытаемся решить тем, что собрали такую же виртуальную команду самых высоких руководителей. Они гордо назвали себя комитетом, следят за тем, чтобы всё по возможности сводилось к одинаковому. То есть на любом уровне работает идея вынуть из разных уголков компании разных людей, объединить их по какому-то признаку, чтобы сделать нечто, до этого принципиально невозможное.

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

    Чтобы эту проблему решить, у нас теперь есть Буткемп. К нам приходит новый разработчик и вместо того, чтобы сразу попасть в какую-то команду и там навсегда остаться, он две недели пробует себя в одной команде, две недели в следующей. И так за восемь недель он получает достаточно широкий кругозор, чтобы дальше сделать осознанный выбор. А у команд, в свою очередь, тоже есть клевая возможность — они выбирают человека не по резюме и короткому собеседованию, а еще смотрят, как он проявил себя в деле, могут сказать: «Да, красавчик, нам нравится. Оставайся».

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

    Резюме: виртуальные команды — это хорошо, они позволяют сбалансировать разработку, сделать так, чтобы всё гармонично развивалось и в плане продукта, и в плане людей. Если у вас похожий масштаб — попробуйте. Вдруг у вас тоже полетит.
    Яндекс
    330,61
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 25

      +2
      Неважно, как ты постарался. Если ты в сравнении с другими не особо чего-то достиг — извини.
      Что-то это напомниает:
      «В центре этой проблемной корпоративной культуры находилась система управления под названием stack ranking. Все бывшие и нынешние сотрудники Microsoft, с кем я общался, – буквально каждый, – называли эту систему самым деструктивным внутренним процессом в Microsoft, который изгнал из компании немыслимое число сотрудников. Система, именуемая также «моделью результативности», «гауссовой кривой» или просто «оценкой сотрудников», работала (с некоторыми вариациями) примерно так: каждое подразделение было обязано обозначить определенную долю сотрудников как самых сильных, сильных, средних, ниже среднего и слабых.

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

      Если бы Microsoft удалось нанять в одно подразделение ведущих руководителей мира высоких технологий еще до того, как они стали бы известными, – Стива Джобса из Apple, Марка Цукерберга из Facebook, Ларри Пейджа из Google, Ларри Эллисона из Oracle и Джеффа Безоса из Amazon, – то, независимо от их результатов, в ходе одного из раундов оценки двое из них получили бы оценки ниже среднего, а одного бы считали просто позором.

      По этой причине, рассказывали менеджеры, многие суперзвезды в Microsoft делали все возможное, чтобы не попасть в одну команду с другими блестящими разработчиками, из страха, что это повредит их месту в рэнкинге. И у этой оценки были реальные последствия: лидеры рэнкинга получали бонусы и повышение, а те, кто оказался внизу, не получали ничего, или им вовсе указывали на дверь.» — Почему компании отказываются от лучших сотрудников?
      В Майкрософт от этого отказались, но традиции живы. Недаром, бывший директор по технологиям Яндекса — Михаил Парахин — выходец из Майкрософта.
        0
        Ничто не ново под луной.

        @ «А вы друзья, как ни садитесь, Все в музыканты не годитесь»
        (Цитата из басни И.А. Крылова «Квартет» 1811г)
        0
        Неважно, как ты постарался. Если ты в сравнении с другими не особо чего-то достиг — извини.

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

          Подробно про схему оценивания можно посмотреть в докладе veged Ревью: Как устроена система оценки производительности сотрудников в Яндексе.
            +3
            Это значит что вместо объективной оценки по заслугам и достижениям, устраиваются крысиные бега: кто больше всех рвал жопу. Учитывая ограниченный бюджет и мотивацию, порождаемую такой системой, фактически да, рано или поздно пишется ПСЖ.
              0
              устраиваются крысиные бега: кто больше всех рвал жопу

              ну вот из текста-то как раз понятно, что именно рваньё жопы малоинтересно: «Неважно, как ты постарался». Это вообще можно воспринять неоднозначно: как то, что имитация бурной деятельности в компании не приветствуется и игнорируется, как и то, что объективные причины неудач никому не интересны.
                0
                имитация бурной деятельности в компании не приветствуется и игнорируется


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

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


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

                При этом здравый смысл никто не отменяет и, если всем участникам обсуждения очевидно, что проделана грандиозная работа, но по независящим от разработки причинам успех не достигнут, то какой-то компромис, конечно, будет найден.
                  0
                  понятно, а ещё такой вопрос: когда кандидата принимают на работу, то с ним заранее обговаривают зарплату, независимо от того, в какую команду он залезет? Учитываются ли предполагаемые премии в этой сумме?
                    0
                    Зарплата (как и премия) не зависит от команды и выставляется по результатам собеседований. Вероятность получения премий никто не скрывает, но оффер формулируется ровно с тем, что мы готовы предложить человеку изначально.
            +5

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


            Они друг с другом будут договариваться, как-то друг другу помогать, и в итоге всё будет хорошо.

            … и жили они долго и счастливо. Наивно полагать, что люди вдруг перестанут быть людьми. Станут винтиками, работающими исключительно на общее благо, но не на свои потребности. Что предъявляемые к ним требования не будут противоречивыми. И конечно, что они не будут продавливать те решения, которые выгодны лично им. Уверен, далеко не все поддерживают текущее внедрение Реакта, например. В бинарных решениях невозможно договориться. Тут либо один продавливает своё, а другой сдаётся, либо наоборот. Ну либо битва затягивается и по шапке получают оба, а решение принимается рандомное.


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

            Что приводит к тому, что промоутится тот, у кого больше визибилити. Тут важно понимать, что выстраивая систему обратной связи вы фактически решаете, какие метрики будут оптимизироваться в ущерб всем остальным. Хороший антипример — Гугл, где разработчикам выгоднее пилить новые фичи, а не латать дыры в существующих. Латание дыр не так заметно. И особенно обидно, когда дыры в архитектуре сделаны не тобой, но ты от них огребаешь. И понимаешь, что что-либо сильно исправить не получится, так как нужно много с кем договариваться. А у этих много кого ни времени, ни желания.


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

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


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

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


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

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

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


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

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

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

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

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


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

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

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

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

              Так ведь именно эту задачу и решает наш подход! Мы отбираем людей по базовым универсальным навыкам, а потом подбираем им виртуальную команду под их персональные скиллы.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Было и правда интересно, особенно если это будет не просто перечисление проблем, а еще и предложение вариантов, как их исправить.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Это не более чем уход от ответственности.
                    Я как-то раз увольнялся с работы по причине высокой степени её галерности. Было: постоянное тушение пожаров, навешивание чужих обязанностей, хамское поведение заказчиков, неадекватные сроки и требования, полная неотлаженность процессов и прочее. Руководитель же постоянно предъявлял, что я неполитично себя веду, что не беру трубку в 10 часов вечера и не спешу делать чужую работу. После того, как я принёс заявление, он произнёс эту самую мантру: а расскажи, какие ты увидел проблемы, и как ты бы их исправил. Мне, говорит, как руководителю, интересно на будущее. Я ответил, что это больше не мои проблемы и пусть он думает сам, как их исправлять. Я и по сей день так считаю, что проблемы организации — это не мои проблемы, потому что мне ну очень легко распроститься с организацией и их проблемами.
                0
                Интересно. Много узнаваемо. Некоторые вещи узнаваемы до боли. Некоторые вещи всё-таки похожи на сказку и не особо верится что оно так работает и/или не приведёт к проблемам в ближайшем будущем.

                И пожалуй я в такой «системе» работать не особо хочу. Но это какое-то внутреннее и не до конца сформировавшееся/сформулированное «не хочу».

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

                  Из статьи не очень понятно, речь о том что можно перебегать только между подкомандами Поиска, или из Авто в Маркет тоже?

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

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

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

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

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


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

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


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

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

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

                      3. Еще один вопрос про виртуальные команды. А тимлиды команд тоже могут ротироваться? Или в этой точке команды неизменными остаются.
                        +1
                        При распределении новичков вы как-то учитываете запрос самих команд на пополнение?

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

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

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

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

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

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

                        Самое читаемое