Когда продукт большой, разработчики идут на крайности: - слишком красивый код - медленные релизы, - слишком много внимания к процессам - мало внимания к развитию, - быстрая отправка новых функций в производство - слишком плохой код, - слишком много внимания к автотестам - сложно вносить изменения, - забота о скорости интерфейса - избегание новых функций, — Улучшение пользовательского интерфейса — мало внимания к архитектуре кода.
В докладе я объяснил, как избежать этих крайностей и добиться успешной командной работы.
— Я хотел бы поговорить о том, как жить в больших коллективах.
Большой коллектив – это когда людей еще больше, чем в этом зале.
И я хочу, чтобы они работали так же слаженно, как эти ребята на гифке: 
У меня не очень большая команда, но я получил небольшое представление о том, что происходит с большими командами в компании в целом, и именно этим хочу с вами поделиться.
Чтобы представить себе масштаб, придется рассказать вполне очевидные вещи.
Этот Яндекс — это не что иное, как страница поиска.
Нас много, более 10 тысяч.
И среди этих «многих» большинство — разработчики.
Мы делаем много разных продуктов, не только для Интернета.
Здесь есть все о товарах, об машинах, о еде, всякой технике, искусственном интеллекте.
И во всем этом участвуют разработчики.
Даже если, казалось бы, речь идет об автомобилях или еде.
У нас много услуг.
Они не помещаются на слайде.
Надеюсь, я убедил вас, что Яндекс очень большой.
Большими делами управлять довольно сложно.
Важная точка.
То, что я скажу дальше, — это, во-первых, очень сильное упрощение; во-вторых, у меня провалы в памяти, поэтому я что-то исказлю; в-третьих, я намеренно буду немного передергивать некоторые вещи, чтобы сделать рассказ связным и т. д. Не будьте слишком придирчивы.
Однако общие идеи будут верными.
Начну с очень старых времен.
Я только что пришел в Яндекс.
Тогда оно было устроено совсем иначе, чем сейчас.
Разделение было по специализациям — круто для разработчиков.
Это выглядело примерно так.
Структурно компания была разделена на менеджеров, они что-то делали между собой.
Были и другие специальности.
На самом деле дизайнеров тогда еще не было, но смысл передает. И, конечно же, были разработчики.
Внутри этой конструкции ее затем разрезали на еще более мелкие фрагменты.
У разработчиков были пилы или плоскогубцы.
Были чуваки в кепках-смузи, чуваки в жестких касках, дизайнеры, которых тогда не существовало, и менеджеры, которые доставали это всем.
Поэтому они пошли подготовленными.
Если углубиться в эту историю, то внутренняя иерархия была примерно такой.
Был парень в сильнейшем шлеме, который нанес все удары.
В его подчинении были суровые менеджеры, затем менее строгие.
Я утрирую, но идея ясна.
И для каждой специализации работала одна и та же иерархия.
Смузи-парни в кепках сделали то же самое, и это круто.
Вы разработчик, вы отчитываетесь перед другим разработчиком, он понимает, что вы делаете, он вас хвалит примерно за то, что ему самому нравится.
Прохладный.
Но предположим, что у какого-то продукта родилась идея.
А другие менеджеры у него в подчинении только - то есть, если ему повезет и у него будет хоть кто-то в подчинении.
Все остальные ему совершенно не подчиняются, но идею как-то надо реализовать.
А он говорит: «Товарищ главный конструктор, у меня есть классная идея.
Мне нужен дизайнер».
Он ответит: «Ну, во-первых, твоя идея странная, а во-вторых, все мои дизайнеры заняты.
Приходи на Q5».
Если менеджер поверит ему в этот момент, у него ничего не будет. Если он будет настойчив, талантлив и готов преодолеть все трудности, возможно, он убедит этого главного конструктора.
Он скажет, ладно, через два месяца ты заберешь этого чувака, он должен быть свободен.
Чувак, конечно, пропустит срок и выйдет через четыре месяца, но зато будет шанс, что процесс разовьется.
Потом этот менеджер пойдет к главному разработчику и скажет: «У меня классный дизайн, классная идея.
Мне нужен бэкенд».
И всё это будет продолжаться: «Бэкендёр занят, идея у тебя так себе, дизайн плохой».
В конце концов он может собрать команду разработчиков и что-нибудь сделать.
С одной стороны, таким образом выживает только самая крутая идея, с другой стороны, действительно сложно что-то сделать.
Но для разработчика это здорово.
Разработчиков оценивают другие разработчики.
Разработчики, конечно, любят все техническое.
Что касается продуктового магазина, пусть сначала менеджер убедит вас, что это отличная идея.
А благодаря тому, что все разработчики находятся в одной структуре, общаются между собой, у всех есть общие тусовки, очень хорошо налажен обмен техническими знаниями.
С продуктовой экспертизой всё не очень круто, но кого это волнует? И много исследований, потому что это весело.
Его оценят другие разработчики, которым он тоже понравится.
Вы можете изобретать крутые технологические вещи.
Очевидно, что в этом подходе есть проблема.
Разработчиков не особо беспокоит, что происходит с продуктом, поскольку они не отчитываются перед менеджерами.
Менеджерам в касках сообщат, если что-то пойдет не так, но они не имеют большого влияния на разработчиков.
А для продуктов, в свою очередь, изменить это довольно сложно.
Они могут, по сути, только уговорить, переубедить и как-то танцем доказать, что их идея крутая.
Тогда разработчик в это поверит и, конечно, все сделает правильно.
Но получается, что из этого большого патча разработчиков приходится кого-то случайным выхватывать, каждый делает что-то интересное — а вот собрать большую и сложную, постоянно взаимодействующую вещь проблематично.
И пока все это происходит, компания берет на себя управление и за год увеличивается вдвое.
И что-то нужно делать.
Как говорил Аркадий Волож, управлять компанией — это все равно, что жарить котлету.
Его нужно постоянно переворачивать.
Структура компании меняется.
Вместо того, чтобы делить всех по специализации, они делят по продуктам.
И менеджер становится гораздо более важным чуваком.
В результате получается примерно следующая диаграмма, если сильно упростить и сильно преувеличить.
У нас есть большой кусок продукта, внутри он разбивается на более мелкие части, и под каждую часть выделяется полностью укомплектованная команда.
Есть дизайнеры, разработчики, менеджеры, и все они делают этот продукт. 
Казалось бы, проблему вылечили, но появилась новая проблема.
Команды могут быть совсем небольшими, и естественно будет один фронтендер, один бэкенд, один дизайнер, половина аналитика и еще кто-то.
Им просто не с кем поговорить о своей предметной области, да и, похоже, этого и не требуется.
Они работают над своим проектом, но им некому передать все полученные в процессе изобретения, не у кого спросить, как это сделать лучше.
Они не знают, что делают за соседней стеной, и, вероятно, делают то же самое.
Более того, они делают то же самое естественным образом.
У менеджера вроде бы больше власти, но он не так хорошо разбирается во всех тонкостях разработки.
Талантливый разработчик при желании может сказать ему, что без полного переписывания проекта никак.
Какой выбор будет у менеджера дальше? Либо он ему поверит, либо он ему запретит, все будут недовольны.
В общем, есть проблема.
Хотелось бы как-то сбалансировать все это с точки зрения продукта.
Например, есть команда по определенному продукту и она, например, считает, что красивый код — это важно.
И пока они доводят этот код до совершенства, релизы по понятным причинам задерживаются.
Не круто.
Или команда думает: «Ладно, пока есть классные процессы, и код как-то сам произойдет».
На самом деле нет, этого не происходит. Нам также нужен кто-то, кто будет следить за этим.
Или команда говорит: «Нам нужно очень быстро двигаться вперед, нам важно, чтобы мы выкатывали фичи каждый день», но в этот момент качество кода ускользает от внимания.
Или команда говорит: «Ладно, мы уже в прошлый раз прошлись по граблям, поняли, что качество важно.
Давайте покроем все автотестами».
Автотесты пишутся для каждой фичи, но теперь эти тесты приходится запускать для каждого пул-реквеста, и они выполняются долго, и все становится медленным.
Или: «Мы знаем, что наши пользователи уйдут, если интерфейс будет медленным.
Давайте сделаем интерфейсы быстрыми».
Но потом получается, что каждая новая фича — это лишний код, который нужно передать по сети и выполнить, а это замедляет работу интерфейса.
«Тогда не будем делать новые фичи — все будет работать быстрее».
Или: «Пользователь любит, когда красиво».
Но не важно, что внутри.
В поисках этого баланса оказывается, что снова нужно что-то менять.
Тем временем команда снова резко растет. 
Как это обычно решается? Они верят модному слову.
Мы его тоже взяли.
В нашей стране Scrum довольно распространен, но с нашими собственными изобретениями.
Что это говорит? Там написано, что давайте хорошо укомплектуем команды, чтобы каждый отвечал за конечный результат, была вся необходимая экспертиза.
И мы предоставим этой команде самой выбирать, какие задачи нужно делать в первую очередь, выбирать, какие процессы у них должны быть внутри.
И вообще, продукт важнее процессов.
Вот и все.
Звучит отлично.
Кажется, это даже решает некоторые проблемы.
Но есть еще проблема.
Например, предполагается, что такие Scrum-команды постоянно адаптируются к тому, что происходит вокруг них, постоянно меняются (меняется их состав, они могут постоянно формироваться или расформировываться), и в принципе не существует общего места, где история развития сотрудника является агрегированным.
То есть есть какой-то разработчик и у него есть какие-то сильные стороны, он где-то горит. И вот он переходит в новую Scrum-команду, а они об этих сильных сторонах не знают и не сразу начинают ими пользоваться.
И, наоборот, возможно, ему чего-то не хватает, нет никого, кто бы об этом знал, позаботьтесь, чтобы он в этом совершенствовался, и сделайте, чтобы проект не пострадал от того, что у него нет экспертизы.
там.
И есть решения, которые мы сейчас пытаемся применить в отдельном звене компании и посмотрим, что получится.
Идея заключается в следующем.
Есть некая достаточно устойчивая структура, в которой есть связи между разработчиком и его менеджером, тоже разработчиком.
Все как в самом начале, когда руководитель понимает, чем ты занимаешься, разделяет твои интересы, может что-то посоветовать в плане того, как работать эффективнее и где-то помочь.
Эти связи остаются долгосрочными в течение нескольких лет. Чтобы удовлетворить потребности продукта, наряду с этой постоянной стабильной структурой, для каждого продукта и даже для каждого отдельного аспекта продукта по-прежнему формируются быстрые виртуальные Scrum-команды.
Сейчас я расскажу вам об этом подробнее.
Команды временные, быстрые, они могут сосредоточиться на самых важных вещах на данный момент. 
Это выглядит примерно так.
Вот у нас есть какой-то небольшой кусочек, например паутина.
А внутри, если посмотреть, там целая куча людей, перерезающих эту паутину.
Вот как вся эта история уравновешивается.
Есть зеленые ребята, они отвечают за то, чтобы интерфейсы были быстрыми.
И всё что их интересует, это чтобы по скоростным метрикам всё было как можно круче.
Пусть все остальное будет таким, каким ты хочешь.
Но есть и другие ребята, которым в принципе не так важна скорость, но важно, что за период времени нам удалось запустить в производство кучу новых крутых фич для пользователя.
И теперь уже невозможно, чтобы чуваки говорили: «Скорость важнее всего.
Ничего не запускайте».
Потому что для той команды это принципиально неприемлемо.
А наоборот, команда, отвечающая за фичи, не может теперь накинуть кучу нового кода и сказать: «Нам пришлось фичи запускать, все стало медленнее, но мы хотя бы фичи запустили».
Они договорятся друг с другом, как-то помогут друг другу, и в конце концов все будет хорошо.
Синие чуваки постоянно и яростно пишут тесты.
И тестами все покрыли, а тестов сейчас много, и все они работают медленно.
Но чуваков это не волнует, ведь они отвечают только за освещение.
Но здорово, что есть другие, которые говорят: «Для нас важно, чтобы общий процесс разработки был быстрым.
С момента, когда мы ставим задачу, до момента, когда наши пользователи начинают ею пользоваться, этот период времени должен быть сокращен».
И они придут к согласию, и все будет хорошо.
Они помогут людям, которые пишут тесты, чтобы эти тесты выполнялись быстрее.
Кто-то отвечает только за то, чтобы все было архитектурно правильно.
Более того, им, возможно, даже не придется думать о том, что происходит в коде прямо сейчас.
Они могут думать такими категориями: «Куда все должно пойти через полтора годаЭ» - и сосредоточьтесь на этом будущем прямо сейчас.
Но в то же время найдется кто-то, кто подкорректирует закругленные углы, подправит тени и подумает об анимации, чтобы пользователь был счастливее завтра.
А когда такое распределение ответственности, и каждая команда дополняет друг друга, получается баланс.
Во всем этом есть несколько ролей.
Я уже кое-что говорил об этом, но, тем не менее, это важная вещь.
У каждого есть свой непосредственный руководитель, который знает о нем все и следит за тем, чтобы человек рос профессионально, рос личностно и был счастлив.
При этом есть лидер такой команды, который говорит, что охват тестированием должен увеличиться, а все остальное менее важно.
И когда такие две роли встречаются одновременно, получается более-менее хорошо.
Кроме того, есть еще разные вещи.
В такой ситуации получается, что разработчики, работающие над одним и тем же продуктом, собранные из разных структур в такую виртуальную команду, получают гораздо больше внимания со стороны разных менеджеров.
А в совокупности этот опыт позволяет нам делать продукт лучше.
.
а затем перенести на другие продукты, на которые смотрят структурные менеджеры, некоторые изобретения, ставшие результатом работы этого большого коллектива.
Или наоборот, то есть эти стрелки можно повернуть в обратную сторону, и это тоже будет верно.
Получается, есть поток экспертизы, и способ как-то удобно пересобрать команды в продукт там, где это сейчас важнее.
Это увеличивает количество внимания к разным продуктам со стороны самых опытных товарищей по компании.
Хорошо, мы, кажется, договорились о том, как все должно работать.
Но если у нас есть структурный начальник и менеджер по продукту, как мы тогда сможем оценить, все ли получилось хорошо? Об этом подробно рассказал на позапрошлом субботнике Сергей Бережной.
Повторю в двух словах общую мысль.
Решение о том, хорошо ли выполнил свою работу конкретный человек, принимается, во-первых, в сравнении с другими участниками процесса, а во-вторых, коллективно всеми заинтересованными сторонами.
То есть в этом участвует как его структурный менеджер, который следит за тем, как он развивается в долгосрочной перспективе, так и человек, который отвечает за непосредственные задачи продукта и оценивает не с точки зрения того, что человек старался и не спал на работе.
ночь, а с точки зрения того, как он на самом деле достиг своих целей.
И именно этот метод кажется нам наиболее справедливым на данный момент. Если ты выделишься, даже не слишком стараясь – красавчик, давай тебя похвалим.
Нам кажется, что этот баланс работает и хорош.
Дополнительные преимущества.
Когда мы договорились, что можем очень быстро собирать отдельные команды, перегруппировывать людей под каждую конкретную потребность, становится критически важно, чтобы этот переход был максимально простым.
А это возможно только в том случае, если все хорошо описано и задокументировано.
Сама конструкция обуславливает необходимость документации.
А при написании документации продукты в целом автоматически становятся лучше.
Это двусторонняя выгода.
Помимо обмена опытом, переходы людей делают разные продукты более похожими друг на друга — как с точки зрения того, как они выглядят, так и с точки зрения того, как они работают внутри.
Вы также можете извлечь из этого пользу — пользователи более четко понимают, как использовать системы, потому что они только что использовали подобную вещь в другом проекте.
И конечно, мы наконец сможем повторно использовать наработки.
Такие команды уделяют внимание каждому аспекту отдельно: они либо пишут тесты, либо отвечают за скорость, либо за красоту — но забыть о том, что происходит у соседей, все равно не могут. Дело в том, что за разработчиков в других командах отвечает их менеджер, а сами они вскоре могут перейти в другую команду.
Для них очевидно, что, условно, это коснется их завтра.
Поэтому при фокусировке ответственность за все дело не теряется.
В результате переключаться между проектами довольно легко.
В то же время у людей есть много возможностей для роста.
Потому что в конструкции, где все отлито в граните и не перемешано, люди в какой-то момент приходят к ситуации, когда им уже все понятно.
В этом проекте они перепробовали все и просто плывут по течению.
им не нужно каждый раз совершать над собой резкие усилия.
И если им постоянно приходится менять команду, постоянно менять ракурс продолжения своих талантов, их экспертность автоматически растет, все это в целом укрепляет систему в целом.
И в целом не скучно.
Вряд ли вы с этим согласитесь.
Конечно, вы можете сказать: «А как добиться того, чтобы все технологии в итоге были одинаковыми, если на самом верху все равно существует разделение по продуктамЭ» Мы пытаемся решить эту проблему, собрав такую же виртуальную команду из высших лидеров.
Они с гордостью называют себя комитетом, следя за тем, чтобы все сводилось к одному и тому же, насколько это возможно.
То есть на любом уровне работает идея вывести разных людей из разных частей компании, объединить их по какому-то признаку, чтобы сделать то, что раньше было принципиально невозможно.
Хорошо, мы создали много маленьких команд. Есть разработчик, ему нужно выбрать, куда идти.
Как он может сделать этот выбор? Просто чтобы узнать, что и где происходит, нужно потратить много времени, и у вас есть проект. Для решения этой проблемы теперь у нас есть Учебный лагерь .
К нам приходит новый разработчик и вместо того, чтобы сразу попасть в команду и остаться там навсегда, он две недели пробует свои навыки в одной команде, а в следующей — две недели.
Итак, за восемь недель он приобретает достаточно широкий кругозор, чтобы сделать дальнейший осознанный выбор.
А у команд, в свою очередь, тоже есть классная возможность – они выбирают человека не по резюме и небольшому собеседованию, а еще и посмотрев, как он себя показал в бизнесе, могут сказать: «Да, красавец, он нам нравится».
.
Оставаться.
" Допустим, мы нанимаем и сразу даем человеку такой выбор — перемещаться между командами.
Тогда как я, человек, ответственный за команду, могу убедиться, что человек, который ко мне приходит, вообще мне подходит? Ведь я не могу каждый раз брать интервью у всех.
Похоже на проблему.
Раньше у меня была команда, я лично мог расспросить всех кандидатов обо всем, что меня интересовало, и принять решение.
И вот человек присоединился к одной команде, присоединился к другой и пришел ко мне.
И у меня, кажется, больше нет выбора.
Но на самом деле это тоже довольно легко решить – мы просто собрались, обсудили, какие требования к кандидату нас всех устроят, и требуем от всех абсолютно одинаковых требований.
Поэтому, если человек где-то проходил собеседование, скорее всего, он мне тоже подойдет. Резюме: виртуальные команды — это хорошо, они позволяют сбалансировать разработку, сделать так, чтобы все развивалось гармонично как по продукту, так и по людям.
Если у вас есть похожие весы, попробуйте.
Вдруг оно полетит и к вам.
Теги: #Управление разработкой #Управление проектами #ИТ-компании #ИТ-компании #Управление продуктом #agile #scrum #виртуальные команды #большие команды
-
Причины Anr И Как Этого Избежать
19 Oct, 24 -
Скрепка + Блог = Дом И Слава
19 Oct, 24 -
Ленивая Обработка Команд В Социальной Игре
19 Oct, 24
