Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть