Сбалансированная разработка в очень больших командах. Доклад Яндекса
Когда продукт большой, разработчики скатываются в крайности:
- слишком красивый код — медленные релизы,
- слишком много внимания процессам — мало внимания разработке,
- быстрая отправка новых фич в продакшен — слишком плохой код,
- слишком много внимания автотестам — сложно вносить изменения,
- забота о скорости интерфейса — уход от новых фич,
- улучшение UI — мало внимания к архитектуре кода.
В докладе я рассказал, как избежать этих крайностей и добиться успешной работы в команде.
— Хочется поговорить про то, как жить в больших командах. Большая команда — это когда людей даже больше, чем в этом зале.
И хочется, чтобы они работали так же слаженно, как эти ребята на гифке:
У меня не очень большая команда, но я чуть-чуть подсмотрел, что с большими командами происходит в компании в целом, и как раз этим хочу с вами поделиться.
Чтобы представить масштаб, придется рассказать достаточно очевидные вещи. Что Яндекс — это чуть больше, чем страничка с поиском. Нас много, больше 10 тыс.
И среди этих «много» бо́льшая часть — разработчики. Мы делаем много разных продуктов, не только для веба. Есть всякое про товары, про машины, про покушать, железяки всякие, искусственный интеллект. И в этом всём участвуют разработчики. Даже если, казалось бы, речь про машины или про еду.
У нас много сервисов. Они на слайд не влезают. Надеюсь, я вас убедил, что Яндекс очень большой. Большими штуками достаточно сложно управлять.
Важный момент. То, что я буду дальше говорить, — во-первых, очень сильное упрощение; во-вторых, у меня провалы в памяти, поэтому что-то я перевру; в-третьих, какие-то вещи я сознательно чуть-чуть подтасую для связности рассказа, и т. д. Сильно не придирайтесь. Общие идеи, между тем, будут верны.
Начну с очень старых времен. Я тогда только-только пришел в Яндекс. Тогда он был устроен сильно иначе, чем сейчас. Деление было по специализациям — прикольно для разработчиков. Выглядело примерно так. Компания структурно делилась на менеджеров, они сами между собой что-то делали. Были и другие специализации. Дизайнеров, на самом деле, на тот момент еще не было, но смысл это передает. И, конечно же, были разработчики. Внутри этой структуры оно потом нарезалось на ещё более мелкие фрагменты.
Разработчики были с пилами или с плоскогубцами. Были чуваки в кепках со смузи, чуваки в касках похардкорнее, дизайнеры, которых тогда не было, и менеджеры, которым доставалось за всех. Они поэтому ходили подготовленные.
Если углубиться в эту историю, то внутри иерархия была примерно такой. Был в самой крепкой каске чувак, которому доставались все шишки. У него в подчинении были суровые менеджеры, потом менее суровые. Утрирую, но идея понятна. И такая же иерархия работала для каждой специализации.
Чуваки со смузи в кепках точно так же работали, и это прикольно. Ты разработчик, ты подчиняешься другому разработчику, он понимает, что ты делаешь, он тебя хвалит примерно за то, что ему самому нравится. Классно.
Но предположим, какому-то продакту приходит в голову идея. А у него в подчинении только другие менеджеры — это если ему повезло и у него хоть кто-то есть в подчинении. Все остальные ему вообще не подчиняются, а идею как-то нужно реализовывать.
И он говорит: «Товарищ главный дизайнер, у меня классная идея. Мне нужен дизайнер». Тот ответит: «Ну, во-первых, идея у тебя странная, во-вторых, у меня все дизайнеры заняты. Приходи в Q5».
Если менеджер ему в этот момент поверит, у него ничего не будет. Если он настойчивый, талантливый и готов сквозь все трудности пробираться — возможно, он убедит этого главного дизайнера. Тот скажет — ладно, через два месяца этого чувака возьмешь, он должен освободиться. Чувак, конечно, сроки завалит и освободится через четыре месяца, но хотя бы появится шанс на развитие процесса.
Потом этот менеджер пойдет к главному разработчику, скажет: «У меня есть классный дизайн, офигенная идея. Мне нужен бэкэндер». И всё это будет продолжаться: «Бэкэндер занят, идея у тебя так себе, дизайн плохой».
В итоге он, может, получит себе команду разработки и что-нибудь сделает. С одной стороны, таким образом выживает только самая классная идея, с другой стороны, что-то сделать действительно сложно.
Но для разработчика это классно. Разработчиков оценивают другие разработчики. Разработчики, конечно же, любят всё техническое. А про продуктовое пускай менеджер сначала убедит, что это классная идея. И благодаря тому, что все разработчики в одной структуре, друг с другом общаются, у всех есть общие тусовки, очень хорошо налажен обмен технической экспертизой. С продуктовой экспертизой всё не очень классно, но who cares? И много всякого исследовательского, потому что это по фану. Оценивать будут другие разработчики, которым это тоже по фану. Можно изобретать кайфовые технологические штуки.
Очевидно, у такого подхода есть проблема. Разработчики не сильно переживают про то, что там с продуктом, потому что менеджерам они не подчиняются. Менеджерам по каске настучат, если что-то пойдет не так, но на разработчиков они особого влияния не имеют. А продактам, в свою очередь, достаточно сложно это поменять. Они могут, по сути, только уговаривать, убеждать, и как-то танцами доказывать, что их идея классная. Тогда разработчик в нее поверит и, конечно, сделает всё зашибись.
Но получается так, что из этой большой грядки разработчиков приходится кого-то случайно выхватывать, каждый что-то интересненькое делает —, но собрать большую и сложную, постоянно взаимодействующую штуку проблематично.
А пока все это происходит, компания берет и вырастает вдвое за год. И нужно что-то делать. Как говаривал Аркадий Волож, управлять компанией — это как жарить котлетку. Её нужно постоянно переворачивать.
Структура компании меняется. Вместо того, чтобы делить всех по специализации, делят по продуктам. И менеджер становится гораздо более важным чуваком.
Получается приблизительно такая схема, если сильно упрощенно и сильно утрированно. У нас есть какой-то большой кусок продукта, внутри он распадается на более мелкие части, и уже для каждой части выделяется полностью укомплектованная команда. Там есть дизайнеры, разработчики, менеджеры, и все они этот продукт делают.
Казалось бы, проблему полечили, но есть новая проблема. Команды могут быть достаточно мелкие, и там будет натурально один фронтэндер, один бэкэндер, один дизайнер, половина аналитика, еще кто-то. Им банально не с кем поговорить об их предметной области, и вроде бы это и не требуется. Они пилят свой проект, но все изобретения, которые они получают в процессе, им некому передать, им некого спросить, как сделать лучше. Они не знают, что делают за соседней стеной, и, возможно, делают то же самое. Более того, они прямо натурально делают то же самое.
У менеджера вроде больше власти, но он ведь не так хорошо понимает все тонкости разработки. Талантливый разработчик при желании может ему рассказать, что без полного переписывания проекта вообще никуда. А у менеджера дальше какой выбор? Либо он ему поверит, либо он ему это запретит, все останутся недовольны. В общем, есть проблема.
Хочется это всё как-то сбалансировать с точки зрения продукта. Например, есть команда у какого-то продукта и она, допустим, считает, что важен красивый код. И пока они затачивают этот код до идеала, понятно, откладываются релизы. Не круто. Или команда считает: «Ладно, лишь бы были классные процессы, а код как-то сам случится». На самом деле, нет, сам не случается. Тоже нужно, чтобы за этим, чтобы кто-то следил.
Или команда говорит: «Нам нужно очень быстро двигаться вперед, нам важно, чтобы мы катили фичи каждый день», но в этот момент ускользает из внимания качество кода. Или команда говорит: «Ладно, мы в прошлый раз уже походили по граблям, поняли, что качество — это важно. Давайте всё покроем автотестами». На каждую фичу пишут автотесты, но теперь эти тесты надо запускать на каждый пул-реквест, и они долго выполняются, и всё становится медленно.
Или: «Мы знаем, что наши пользователи, если интерфейс работает медленно, уходят. Давайте мы будем делать интерфейсы быстрыми». Но тогда получается, что каждая новая фича — это лишний код, который нужно передать по сети и выполнить, и он замедляет интерфейс. «Тогда давайте не делать новые фичи — будет быстрее всё работать». Или: «Пользователь любит, когда красиво. Давайте делать красиво». Но становится неважно, что там внутри.
В поисках этого баланса оказывается, что снова нужно что-то менять. А тем временем команда снова драматически растет.
Как это обычно решается? Берут модное слово. Мы тоже его взяли. У нас достаточно распространен примерно скрам, но с собственными изобретениями. Про что там говорится? Там говорится, что давайте мы классно укомплектуем команды таким образом, чтобы все были ответственными за конечный результат, там была вся нужная экспертиза. И дадим этой команде самой выбирать, какие задачи нужно делать в первую очередь, выбирать, какие у них должны быть внутри процессы. И вообще продукт важнее процессов. Вот это всё. Вроде звучит хорошо. Вроде даже решает часть проблем.
Но всё равно есть проблема. Например, предполагается, что такие скрам-команды постоянно подстраиваются под происходящее вокруг, постоянно меняются (меняется их состав, они могут постоянно формироваться, расформировываться), и в принципе не существует никакого общего места, где бы агрегировалась история развития сотрудника.
То есть есть какой-то разработчик и у него есть какие-то сильные стороны, он где-то жжет. И вот он переходит в новую скрам-команду, и там про эти сильные стороны не знают, и не начинают там ими сразу пользоваться. И, наоборот, возможно, он в чем-то не дотягивает, не существует никого, кто бы про это знал, следил, чтобы он в этом прокачался, и следил бы, чтобы проект не пострадал от того, что у него нет там экспертизы.
И есть решения, которые мы сейчас стараемся применить в отдельном кусочке компании и посмотреть, что будет. Идея следующая. Существует некоторая достаточно стабильная структура, в которой есть связи между разработчиком и его руководителем, тоже разработчиком. Всё как в самом начале, когда руководитель понимает, что ты делаешь, разделяет с тобой интересы, может тебе что-то посоветовать с точки зрения того, как тебе эффективнее работать и где-то помочь. Вот эти связи сохраняются долгосрочно в течение нескольких лет.
Чтобы отвечать потребностям продукта, наряду с такой постоянной стабильной структурой по-прежнему формируются быстрые виртуальные скрам-команды под каждый продукт, и даже под каждый отдельный аспект продукта. Сейчас расскажу про это подробнее.
Команды временные, быстрые, они могут фокусироваться на каких-то самых критичных в данный момент штуках.
Выглядит это примерно так. Вот у нас есть какой-то маленький кусочек, например веб. И внутри, если заглянуть, целая куча людей, которые этот веб пилят.
Вот как происходит балансирование всей этой истории. Есть зелененькие чуваки, они отвечают за то, чтобы интерфейсы были быстрые. И всё, что их интересует — это чтобы по метрикам скорости всё было максимально классно. Всё остальное пускай будет как угодно. Но есть другие чуваки, которым в принципе не так важна скорость, но важно за какой-то период времени мы успели запустить в продакшен кучу новых классных фич для пользователя. И теперь уже невозможна ситуация, что чуваки скажут: «Скорость важнее всего. Ничего не запускайте». Потому что для той команды это принципиально неприемлемо.
Но и наоборот, команда, которая отвечает за фичи, не может теперь накидать кучу нового кода и сказать: «Вот нам надо было запустить фичи, всё стало медленнее, но зато мы фичи запустили». Они друг с другом будут договариваться, как-то друг другу помогать, и в итоге всё будет хорошо. Синие чуваки пишут тесты, неистово, постоянно. И всё покрыли тестами, и тестов теперь много, и все они работают медленно. А чувакам всё равно, потому что они только за покрытие отвечают.
Но здорово, что есть другие, которые говорят: «А нам важно, чтобы в целом процесс разработки был быстрый. От момента, как мы поставим задачу, до момента, как ее начнут использовать наши пользователи, этот промежуток времени должен сокращаться». И они будут договариваться, и всё станет хорошо. Они будут помогать людям, которые пишут тесты, чтобы эти тесты выполнялись быстрее.
Кто-то отвечает только за то, чтобы всё архитектурно было здорово. Причем им, возможно, не приходится даже думать о том, что прямо сейчас происходит в коде. Они могут думать в терминах: «А куда всё должно двигаться через полтора года?» — и уже прямо сейчас сосредотачиваться на этом будущем. Но при этом будет кто-то, кто подтюнит круглые уголки, поправит тени и будет думать про анимацию, чтобы пользователь уже завтра был счастливее. И когда такое распределение ответственности есть, и каждая команда взаимно дополняет друг друга, получается баланс.
В этом всем есть несколько ролей. Я уже про это примерно сказал, но, тем не менее, это важная штука. У каждого есть его непосредственный руководитель, который про него всё знает и следит за тем, чтобы человек рос профессионально, рос личностно и был счастлив. Вместе с тем, есть руководитель такой команды, который говорит о том, чтобы покрытие тестами росло, и всё остальное менее важно. И когда такие две роли одновременно встречаются, получается более-менее хорошо.
Причем есть дополнительные разные штуки. В такой ситуации оказывается, что для разработчиков, занимающихся одним и тем же продуктом, собранных из разных структур в такую виртуальную команду, получается гораздо больше внимания от разных руководителей. И суммарно этот опыт позволяет и продукт сделать лучше…
…и перенести потом на другие продукты, на которые смотрят структурные руководители, какие-то изобретения, получившиеся в процессе работы этой большой команды. Или наоборот, то есть эти стрелки можно развернуть в обратную сторону, и это тоже будет справедливо. Получается перетекание и экспертизы, и способ как-то удобно пересобирать команды в тот продукт, где это сейчас важнее. Таким образом увеличивается количество внимания разным продуктам от самых опытных товарищей в компании.
ОК, вроде договорились, как всё должно работать. Но если у нас есть начальник структурный и начальник про продукт, как потом оценить, получилось ли всё хорошо? Про это подробно рассказывал Сергей Бережной на позапрошлом Субботнике. Я в двух словах повторю общую идею.
Решение о том, хорошо ли поработал конкретный человек, принимается, во-первых, в сравнении с другими участниками процесса, во-вторых, коллегиально всеми заинтересованными. То есть в этом участвует и его структурный руководитель, который следит за тем, как он развивается на долгосрочном отрезке, и человек, который отвечает за сиюминутные продуктовые задачи и оценивает не в терминах того, что человек сильно старался и ночей не спал, а в терминах того, как действительно он достигал поставленные цели. И это такой способ, который нам на текущий момент кажется наиболее справедливым. Неважно, как ты постарался. Если ты в сравнении с другими не особо чего-то достиг — извини. И наоборот, если ты выделяешься, даже особо не напрягаясь — красавчик, давай тебя похвалим. Такой баланс нам кажется рабочим, хорошим.
Дополнительные преимущества. Когда мы договорились, что можем очень быстро собирать отдельные команды, перегруппировывать людей под каждую конкретную необходимость, то становится критически важным, чтобы этот переход был максимально простым. А это возможно, только если всё хорошо описано, задокументировано. Само такое построение форсирует необходимость документации. А при написании документации продукты автоматически становятся качественнее в целом. Такая вот польза в две стороны.
Кроме обмена экспертизой, переходы людей позволяют сделать разные продукты более похожими друг на друга — и в терминах того, как они выглядят, и в терминах того, как они устроены внутри. От этого тоже можно выигрывать — пользователям понятнее, как пользоваться системами, потому что они только что на другом проекте пользовались похожей штукой. И естественно, можно наконец-то реиспользовать наработки.
Такие команды фокусируются на каждом аспекте отдельно: либо пишут тесты, либо отвечают за скорость, либо за красоту —, но они по-прежнему не могут забить на то, что происходит у соседей. Дело в том, что их руководитель является ответственным за разработчиков в других командах, а еще они, возможно, сами вскоре перейдут в другую команду. Им очевидно, что, условно, завтра это их коснется. Поэтому при фокусировке не теряется ответственность за всё целиком. Как следствие — переходить между проектами достаточно легко.
У людей при этом есть куча возможностей для роста. Потому что в структуре, где всё отлито в граните и не перемешивается, люди в какой-то момент приходят к ситуации, что им уже всё понятно. Они на этом проекте всё попробовали и просто плывут по течению. им не требуется каждый раз над собой делать резких усилий. А если им постоянно приходится менять команду, постоянно менять угол продолжения своих талантов, автоматически растет их экспертиза, все это суммарно усиливает систему в целом. И вообще, это не скучно. Вряд ли вы с этим не согласитесь.
Конечно, можно сказать: «А как у вас с тем, чтобы все технологии в итоге были одинаковые, если все равно в самом верху есть деление по продукту?». Эту проблему мы пытаемся решить тем, что собрали такую же виртуальную команду самых высоких руководителей. Они гордо назвали себя комитетом, следят за тем, чтобы всё по возможности сводилось к одинаковому. То есть на любом уровне работает идея вынуть из разных уголков компании разных людей, объединить их по какому-то признаку, чтобы сделать нечто, до этого принципиально невозможное.
ОК, мы наделали множество маленьких команд. Есть разработчик, ему надо выбрать, куда же пойти. Как ему сделать этот выбор? Только на то, чтобы узнать, что где происходит, нужно потратить кучу времени, а у тебя проект.
Чтобы эту проблему решить, у нас теперь есть Буткемп. К нам приходит новый разработчик и вместо того, чтобы сразу попасть в какую-то команду и там навсегда остаться, он две недели пробует себя в одной команде, две недели в следующей. И так за восемь недель он получает достаточно широкий кругозор, чтобы дальше сделать осознанный выбор. А у команд, в свою очередь, тоже есть клевая возможность — они выбирают человека не по резюме и короткому собеседованию, а еще смотрят, как он проявил себя в деле, могут сказать: «Да, красавчик, нам нравится. Оставайся».
Допустим, мы нанимаем и сразу даем человеку этот выбор — ходить между командами. Тогда как мне, ответственному за команду, убедиться, что человек, который ко мне придет, вообще мне подходит? Ведь я не могу всех каждый раз пересобеседовать. Вроде проблема. Раньше у меня была команда, я всех кандидатов лично мог спросить всё, что мне было интересно, и принять решение. А сейчас человек походил в одну команду, походил в другую, пришел ко мне. И у меня уже вроде нет выбора. Но на самом деле, это тоже достаточно легко решается — просто мы собрались, обсудили, какие требования от кандидата нас бы всех устраивали, и ровно такие требования мы спрашиваем со всех. Поэтому если человек прошел собеседование куда-то, скорее всего, мне он тоже подойдет.
Резюме: виртуальные команды — это хорошо, они позволяют сбалансировать разработку, сделать так, чтобы всё гармонично развивалось и в плане продукта, и в плане людей. Если у вас похожий масштаб — попробуйте. Вдруг у вас тоже полетит.
