RPG в разработке — как создать команду с учётом особенностей ролей
Привет! Меня зовут Тимофей, я IT lead в QIWI. Но так было не всегда — например, год назад я в рамках того же продукта, что и сейчас, был продуктовым разработчиком в части бэкенда. Передо мной (так я был старожилом) поставили занятную задачку — собрать новую команду. В этом посте я хочу рассказать по ролевую модель Белбина, почему она (на мой взгляд) очень полезна для работы и для построения команд. А ещё о том, какие проблемы могут возникать в вашей компании, если в ней нет определенных ролей.
Как только мы начали нанимать ребят, стало возникать очень много вопросов о том, какие ребята нам нужны в команду. Казалось, что в целом мы примерно понимаем, сколько нам нужно бэкендеров и фронтендеров, это мы можем прикинуть из бэклога. Но есть же еще какие-то soft skills, нужно учитывать темпераменты людей, кто-то хорошо с кем-то дружится, кто-то — не очень.
Я понял, что у меня как у программиста понимание этой модели (почему некоторые команды складываются, а некоторые — вообще никак) почти никакого нет. Когда я был больше программистом, большинство моих вопросов мог решить Stack Overflow. Однако с вопросом «Как мне собрать идеальную команду, чтобы она здорово перформила?» даже он не смог мне помочь.
Так что мне пришлось заново изучать матчасть, я обращался за помощью к старшим коллегам, у которых уже был опыт руководителя, мне рекомендовали разную литературу, курсы, спикеров. Я изучил какое-то количество теорий, моделей, не все мне подходило. Я искал решение для вполне конкретной проблемы, которая у нас в команде была на тот момент. Мы с командой приходили на планирование, были какие-то запросы от бизнеса, но проработанность идей, гипотез, подходов, как это реализовать, зачастую не получалось обрести.
И вот эту проблему я очень хотел как-то решить, понять, что нужно сделать, чтобы команда на спринт входила уже с достаточно подготовленными задачами. В реализации чего-то понятного вопросов никогда не возникало, то есть ни с качеством кода, ни с тем, чтобы его написать вовремя, больших сложностей не было. Сложность была именно в том, где взять идеи, гипотезы, как перевести сырые запросы бизнеса на разработческий язык.
Штудируя литературу для руководителей, я наткнулся на книгу Рэймонда Мередита Белбина, это доктор психологических наук, ему около 96 лет, он всё ещё с нами. Книга называлась «Типы ролей командных менеджеров», я натыкался на нее во множестве мест и каждый раз сомневался: что за роли?
Ведь у нас в SCRUM уже есть понятные роли: product owner, разработчик, SCRUM-мастер. Что еще нужно? Зачем сущности плодить? С другой стороны, команды менеджеров. Тоже непонятно, что за команды менеджеров? У менеджеров бывают команды? У нас, вроде бы, не команда менеджеров. Зачем мне это?
В какой-то момент вселенная меня доконала, и я решил — время пришло. Раздобыл себе эту книгу и начал читать.
В чём суть
История о том, что существует эмпирическая модель, то есть не теоретическая, когда берут какие-то полярности и говорят, что все люди более или менее полярны. Эта модель построена в ходе анализа опыта успешных и неуспешных команд, которые занимались какими-то военными играми и всякими бизнесовыми штуками.
Получилось (сюрприз), что все люди похожи, но все же в чем-то они разные. Есть три группы командных ролей по типам либо способностей, либо индивидуально-личностных склонностей людей, может быть, «мотивационных моделей» (что людей мотивирует, от чего они кайфуют).
Интеллектуальные роли. Понятно, что такие люди кайфуют от того, что они делают что-то умное, сложное, интересное.
Социальные роли. Люди с такими ролями обычно кайфуют от взаимодействия, теплой атмосферы в коллективе, каких-то общих ваших командных посиделок, разговоров.
Третья группа — ребята, которые лучше всего мотивируются от результатов. Чего-то вы достигаете по бизнесу, теперь у вас столько-то пользователей, вы сделали фичу, благодаря которой оборот возрос на столько-то процентов — в общем, все, что связано с результатом.
Что еще было интересного в этой модели? Понятно объясняются все эти роли, какие они, какие у них сильные и слабые стороны. Для меня самым интересным было то, какие признаки проблем вы можете обнаружить в команде, если у вас не представлены определенные роли. Сейчас про это расскажу, но сначала пара полезных оговорок.
Во-первых, есть довольно много различных теорий, моделей по классификации, профилированию, разделению людей на какие-то группы. А раз есть много теорий, есть и много критиков этих теорий. На самом деле, критика довольно оправдана, потому что, как по мне, никогда нельзя использовать эти модели для лейблинга людей или ограничения: «Все, вот у тебя такая роль, ты выполняешь эти задачи, и ни шага влево-вправо». Думаю, этим вы этим только демотивируете людей, ограничив их развитие.
Во-вторых, обычно никакой человек не является тождественным какой-то определенной роли. Человек вообще штука многогранная, и пробовать описать человека двумя-тремя словами из разряда «Этот человек педантичный, а этот — творческий» — это очень сильное упрощение, тоже не рекомендую так делать. Обычно у каждого человека есть преобладающая роль, какая-то роль в коллективе, объем работы, который он будет на себя брать, но при этом остальные роли у него представлены в той или иной мере. Иными словами, он, в принципе, может заниматься чем угодно, тут вопрос мотивации.
Роли
Интеллектуальные роли
Первая роль — роль генератора идей — это штука, за которую я зацепился, когда думал про планирование при отсутствии идей.
Итак, представьте. Есть некая продуктовая цель, есть люди, которые готовы что-то запедалить, но вот идеи, как это педалировать, не хватает. Очевидно, чем занимаются генераторы идей — они генерируют идеи. Так как роль эта интеллектуальная, это обычно незаурядного ума личности, у них очень развито творческое мышление, они могут набрасывать бесконечно какие-то варианты, браться за предложение идей по решению достаточно сложных проблем.
Как у любой роли, здесь есть сильные и слабые стороны. Слабой стороной, наверное, можно назвать не такое высокое внимание к деталям, как, например, у ролей, которых драйвит реализация и результат. То есть эти ребята как бы парят над всей историей, которой вы занимаетесь, видят сверху все связи, поэтому могут хорошо работать с верхнеуровневыми абстракциями и идеями.
Про признаки недугов, на самом деле, я уже отчасти рассказал, это когда у вас застревает работа на этапе, когда эти идеи нужны. Казалось бы, с реализацией проблем нет, но при этом идеи не поступают. Еще как признак проблемы — у вас могут приходить сложные, запутанные вещи из разряда «Я без понятия, с чего начать решать проблему». Эти люди имеют навык генерировать идеи даже для непонятных проблем: они просто не боятся таких проблем, опять же, потому что, возможно, им не настолько важны глубина и детали.
Вторая роль, которая дополняет и уравновешивает генератора идей — роль аналитика, или стратега. В противоположность генератору, у которого очень развитое креативное мышление, у аналитиков и стратегов обычно преобладает критическое мышление. Это важно, потому что у вас может быть замечательный генератор, который принесет вам миллиард идей, вы начнете бросаться все это реализовывать, но не будет какой-то системы, не все идеи будут приводить вас к ожидаемому результату, так как генератор может что-то набросить просто из-за того, что это красиво и «хочется» или это интеллектуально сложно и «хочется».
Аналитик или стратег — как раз такой персонаж, который может уравновесить вашего генератора, охладить его пыл, показать, какова реальность на самом деле, поэтому одни идеи будут смотреться в ней хорошо, а другие — не очень, поможет всю эту историю взвесить и принять решение, отфильтровать идеи, которые вообще стоит начинать делать.
Признаки недугов — это как раз такие беспорядочные идеи, которые не все приводят к результату, это поверхностные и невзвешенные решения, когда мы бросаемся «из огня да в полымя». Еще он стратег потому, что как раз это аналитическое, критическое мышление может помочь ему в условиях хорошего понимания реальности заниматься среднесрочным и долгосрочным планированием. Признак недуга, когда у вас такого человека нет — среднесрочное и долгосрочное планирование отсутствует, то есть вы двигаетесь какими-то небольшими итерациями, но далеко идущего плана у вас нет.
Третья интеллектуальная роль, которая у нас есть — роль специалиста или эксперта. Она хороша тем, что это обычно ребята с очень сильными, глубокими знаниями в одной или нескольких областях. У них зачастую есть уникальная экспертиза, они могут решать уникально сложные проблемы, падения, анализировать отказы, быстро все это поднимать. Нюанс в том, что если ты в чем-то глубок и хорош, обычно нельзя быть таким во всем. То есть если ты куда-то инвестируешь основное свое время, скорее всего, у тебя будет не такой широкий кругозор.
Обязательно нужно поговорить про недуги. Если у вас нет такого человека, можно наблюдать, что вы, например, не приступаете или несмело приступаете к решению действительно сложных технических проблем, где нужна глубокая экспертиза, то есть у вас будут какие-то поверхностные архитектурные решения, поверхностные технические решения. Все зависит от вашего продукта, от вашей среды, может быть, для вас это и хорошо, может быть, они вам действительно не нужны.
Еще как пример недуга, который может быть: у вас может не очень быстро расти экспертиза в команде. Эксперт как центр знаний будет свои знания в процессе решения задач передавать другим. Если у вас такого человека нет, то другим придется искать иные источники знаний либо в других командах, либо на каких-то курсах, либо где-то еще, но в команде получить их они не смогут.
Социальные роли
Первая социальная роль, которая у нас есть, это роль души команды. Почему душа? Я могу вспомнить примеры таких людей из своей жизни — когда в компании кто-то рассказывает шутку, это, скорее всего, будет первый человек, на которого все посмотрят перед тем, как посмеяться. Вот такая странная штука.
Это центр компании, самый душевный, самый теплый человек, от него всегда больше всего отдачи, с ним всегда приятнее всего общаться. Собой он склеивает всю команду, потому что может очень чутко чувствовать индивидуальность людей, то есть ко всем может найти подход, всех может сплотить. В общем, очень хорошая история для командообразования.
Но есть, как говорится, нюанс. Скорее всего, так как у таких людей самый сильный мотиватор — социум, коммуникация, у них будет, вероятно, не самая глубокая техническая экспертиза. Я бы не сказал, что это недостаток, я бы вообще не сказал, что это что-то плохое, потому что их impact гораздо больше в других областях.
Еще стоит отметить, что такие ребята могут теряться в кризисных ситуациях. Опять же, это не очень критично, если у вас есть те, кто не теряется, например, те же специалисты. Признак недуга, который можно наблюдать в команде, если такой роли нет — команда без души. Если вас спросят: «Чем ваша команда особенная? Может быть, у вас есть какая-то своя движуха, своя тема, особенная манера общения, какая-то культура?», невозможно будет ответить, и, скорее всего, у вас не очень надолго будут задерживаться ребята в команде. В командах, которые дольше всего сохраняют свой состав, обязательно есть «душа».
Вторая социальная роль — исследователь ресурсов. Что он исследует и почему ресурсы?
На самом деле, эта роль очень похожа на генератора идей, он тоже приносит в команду идеи. Но, в отличие от генератора, эти идеи чаще всего придумывает не сам. Он исследует то, что находится вокруг вашей команды (другие команды, другие продукты, другие компании, другие рынки), и находит какие-то хорошие вещи, в которых он видит пользу и которые он вам в команду может принести.
Есть у него и свои слабые стороны: во-первых, он может радостно притащить вам вообще всё — что вам надо и не надо, может хватать все, что ему попадется под руку. Как всё это соотносится с вашей стратегией, бизнесом, техникой и архитектурой, ему не так важно. Еще он может быстро терять интерес к тому, что он принес. Скорее всего, он не будет это внедрять, внедрять за него это будет кто-то другой.
Чем плохо, когда такого человека нет? Опять же, зависит от масштаба бизнеса, количества команд и того, насколько вам это важно. Но на примере нашей компании могу сказать, что мы нанимаем обычно не в конкретную команду, мы нанимаем ребят в компанию.
Еще у нас такой трушный SCRUM«овский и Agile«овский подход — мы движемся бизнесовыми гипотезами. Мы начинаем ряд гипотез по типу «Попробуем сюда, сюда и сюда. Вот есть десять гипотез, десять команд». Стартанули, как всегда бывает, выстрелило три гипотезы, семь не выстрелили. Что делать с остальными семью командами? Кажется, что надо их раскидать по тем гипотезам, которые выстрелили.
Можно столкнуться с тем, что в каждой команде было что-то по-своему, везде разные процессы, разные best practice, разные инструменты, разные подходы. Таким образом, у вас время на вливание команды в новый продукт будет выделяться на изучение не только предметной области, но и всего зоопарка, который команда понаделала. Когда у вас есть исследователи ресурсов, они, скорее всего, сформируют определенные кросс-командные процессы, которые вам позволят распространить все хорошие идеи, все стоящие инструменты на все команды.
Итого у вас процесс перехода команды на другой продукт займет время только на изучение предметной области нового продукта, а вся техника, все инструменты и подходы будут одинаковыми, потому что исследователи растащили лучшее, что можно было найти, и распихали по своим командам.
Третья социальная роль, которая у нас есть, — роль координатора. Чаще всего в классической модели руководства это обычно называют «хорошим руководителем». Он крут тем, что он очень хорошо знает ребят, которые с ним работают, знает их сильные и слабые стороны. Он может эффективно распределять задачи, зная, что Вася хорошо делает очереди, Петя хорошо делает и оптимизирует базы данных. У него, как и у всех социальных ролей, хорошо развиты навыки коммуникации, широкий кругозор.
Какой тут нюанс? Опять же, все зависит от вашей организационной структуры компании. У нас так обычно получается, что в команде нет выделенной роли тимлида. Команда плоская, есть IT-менеджер в продукте на несколько команд, а вот в команде нет такого руководителя, то есть команды распределяют между собой задачи на планировании сами. Получается, что у каждого человека в команде должен быть свой маленький «координатор» в голове. Так эти маленькие координаторы, взаимодействуя между собой, распределяют задачи. Если у вас компания, где есть тимлиды, и как раз одна из его обязанностей — распределение задач, то человек с выраженной ролью координатора хорошо бы подошел на роль тимлида.
Что будет, если у вас нет ни в каком виде координатора, ни в голове у каждого, ни какого-то выделенного? На планировании я наблюдал несколько раз такую историю: происходит фрустрация при распределении уже готовых задач. Казалось бы, есть бизнес-гипотеза, план реализации, компоненты есть, даже список задач есть. Но когда просто нужно раскидать между людьми, ты наблюдаешь молчание, как будто все ждут, кто начнет, кто это должен делать, «А я сейчас себе заберу самое хорошее, кому-то не достанется» или наоборот «Я себе заберу опять какую-то скукотень». В общем, в каком-то виде эта роль в команде должна быть представлена.
Роли реализации
Первая — мотиватор, или шейпер. Мотивация через здоровое давление: обычно это смелый и энергичный человек, который хорошо понимает ваши цели, очень сильно их разделяет, может быть, даже сам их формулирует, то есть координатор и мотиватор рядом, потому что это руководящая позиция, руководитель — кто-то из них. Разница в том, что координатор более душевный, а мотиватор более «давящий», он никогда не полезет за словом в карман, он всегда скажет, когда кто-то где-то накосячил, когда вся команда накосячила. Он всегда укажет на какие-то недостатки, огрехи, что недосмотрели, что недоделали — в общем, даст здоровый «пендель», если по-простому.
Возможные трудности — «пендель» может быть слишком сильный, то есть можно перегнуть с давлением, и люди не захотят с тобой работать, потому что каждый день начинается с какого-то месилова. Кому такое нравится? Из-за того, что он сильно мотивируется от результатов, при недостижении результатов он сильно демотивируется, то есть тяжело переживает неудачи, а после серии каких-то неудач человек может просто выгореть.
Что будет с командой, если такого человека нет вообще, то есть если нет абсолютно никакого давления в сторону цели и здорового шейминга в сторону «А почему мы не выполнили цель?». Можно наблюдать некий инфантилизм команды в плане commitment«ов: «договорились, не выполнили — ну и ладно, ничего страшного, что-то сделали — и так сойдет». Мне кажется, здравое давление необходимо в хорошей команде для успеха.
Если говорить про SCRUM, Agile и разработку ПО, у нас есть роль, которая шире всего представлена, самая характерная для программистов, для разработчиков, — роль реализатора. Это такой «Вася», «рабочая пчелка», самый надежный человек, на которого можно положиться, самый дисциплинированный, самый нацеленный на результат, он обычно до победного конца этот результат и допиливает.
Какие сложности могут быть? Опять же, он может очень сильно перегореть. Может видеть, что мы что-то не успеваем, взяли слишком большую задачу, и начать работать вечером, или в выходной, или отпуск берет, чтобы в отпуске «спокойно поработать». В общем, может происходить такое самовыжигание, надо ребятам иногда давать фидбэк, что все нормально, все получается, необходимо чуть-чуть спокойствия.
Что будет, если у вас в команде нет реализатора? Да ничего у вас не будет. У вас будет много замечательных идей, красивых графиков, картиночек, но никакого кода, никакого рабочего продукта никогда вы не получите, поэтому это тот человек, который нужен вам всегда, везде и в первую очередь.
Закончу пост рассказом про роль контролера. Это педант, но мне больше всего нравится один из переводов — «одержимый». Это в хорошем смысле слова одержимый результатом и его качеством человек, самый внимательный к деталям. В конце спринта, когда у вас допилен весь код, он будет все это дело скреплять в общую картину, заставлять работать, допиливать какие-то последние баги, релизить, проверять, как там на prod«е это у пользователя. В общем, самый дотошный, самый финализирующий все человек, всегда все доводящий до конца.
Как и все роли, связанные с результатом, может перегорать, это выражается иногда в конце спринта так: «Какого черта я один этим занимаюсь, объединяю какие-то куски, почему вы это не проверили, почему мы опять не успеваем?». То есть некие раздражимость и нетерпимость, у него могут быть высокие требования к окружающим, которые он до какой-то поры может в себе сдерживать, но потом они рано или поздно вывалятся на всех.
Что будет, если в команде у вас вообще нет такой роли? Наверное, что-то у вас будет получаться, но можно наблюдать в продукте большое количество мелких несовершенств, то ли это баги, то ли это фичи, вроде бы так работает, пользователи не особо жалуются.
Еще одна проблема — срыв сроков, который уже происходит на последнем этапе разработки, за счет того, что куча индивидуалистов-реализаторов что-то наработала сама по себе, но в общую картину это никто не слепил.
Что в итоге
Мы поговорили про все девять ролей. Самый частый вопрос, который мне задают по этой модели: какие роли все-таки необходимы в наших реалиях, в Agile, в SCRUM? Все ли они нужны? А если их будет куча, уже девять человек?
Во-первых, как я отмечал, каждый человек может нести в себе две-три роли, совсем не обязательно брать девять человек на девять ролей.
Во-вторых, реализатор — самое важное, что вам нужно, сами по себе реализаторы могут начать немного приунывать, хорошо бы им добавить чего-то социального, какого-нибудь экстраверта в виде либо души команды, либо исследователя ресурсов, либо координатора, если у вас организационная структура это позволяет. История с идеями зависит от того, насколько понятные штуки вам поступают на вход: если у вас Agile и идеи не очень понятные, то генератор вам нужен. Если у вас есть генератор, то вам нужен аналитик, иначе вы понаделаете кучу каких-то левых идей. Педанта-контролера тоже хотелось бы иметь, но он может быть в первой роли реализатором, а во второй — педантом или наоборот. Так часто бывает, обычно человек большую часть спринта что-то делает, поэтому за ним не заржавеет.
Ну и главное — что в итоге со всем этим знанием делать?
Первое, что я обнаружил: есть же не только эти роли, есть в этой методологии еще и тест, проходя который, вы можете узнать свои основную и дополнительную роли. Я прошел этот тест и узнал, что я взял на себя по кусочку каждой роли, которую только можно было взять, то есть я попытался взять на себя в новой команде все.
Очевидно, когда пытаешься взять на себя все, получается в итоге примерно ничего.
Вы можете проверить себя и понять, есть ли у вас какие-то две-три основные внятные роли, понятны ли они вам самим, понятны ли они окружающим, занимаетесь ли вы той работой, которой хотите заниматься.
Второй способ это использовать — так я сейчас это использую: диагностика вашей текущей команды. Вы можете, во-первых, просто собрать свои наблюдения, во-вторых, попросить ребят из команды пройти то же самое тестирование, которое вы сами прошли. Затем рассказать им коротко про эту модель и составить карту команды — какие роли у вас есть сейчас, посмотреть, каких ролей вам, возможно, не хватает, есть ли у вас признаки проблем, связанные с нехваткой этих ролей, и принять решения по тому, что вам, возможно, надо кого-то добавить. Либо это какой-то человек, которого вы наймете или заберете из другой команды, либо какой-то человек из вашей команды увидит, например, что у вас нет педанта, а ему это подходит, он мог бы этим заниматься. Так вы можете сделать себе более сбалансированную команду и устранить какие-то проблемы.
И третья штука, которая у меня происходит прямо сейчас — формирование новой команды. Мне кажется, что нам надо начинать использовать какие-то похожие модели, связанные с темпераментом и анализом людей с софтовой части для формирования более сбалансированных команд на старте, чтобы у нас получались достаточно гладкие коллективы синергирующих друг с другом людей.
PS
Последнее, на что обращу внимание — можно разнести эту модель в пух и прах, сказать, что все ерунда, это не работает, но я скажу, почему мне показалось, что это может сработать.
Где-то год-полтора назад мы вместе с моей супругой стали жить в одной квартире, и есть у нас такое увлечение — мы любим выращивать растения. Но любим разные растения: я люблю суккуленты (типа кактусов, многолетняя трава), а супруга любит что-то побольше, пальмы, фикусы. Ее растения стоят в одной комнате, она за ними ухаживает, мои растения стоят в другой комнате, я за ними ухаживаю.
У нас было несколько инцидентов, когда кто-то решил поухаживать за чужими растениями, и получил впоследствии за это по голове, потому что каждый хорошо знает про свои растения и уход за ними. Другому лезть в эту историю не надо. То есть у нас образовался баланс разграничений индивидуальной ответственности: я отвечаю за это, ты отвечаешь за то, и мы оба знаем, что все растения будут политы, подстрижены и так далее.
Если накладывать это на данную модель, если у нас сбалансированная команда по ролям, мы знаем, что у нас ни в одной части работы нет просадок: ни в идеях, ни в реализации каких-то штук, ни в общении, ни в анализе, ни в контроле качества выпуска инкремента. Мне кажется, что если мы будем применять эту историю, то мы получим по-настоящему долгоживущие команды, с которыми мы сможем сделать крутые, долгоиграющие, эффективные и прибыльные продукты.
Посоветую ещё пару вещей в плане почитать и послушать.
Во-первых, книги самого Белбина.
Во-вторых, у нас есть подкаст под названием «Devone», где мы обсуждаем разные темы, иногда хардовые, иногда софтовые.
Пишите свои вопросы или замечания по методу в целом или по созданию команд в частности в комменты, буду рад ответить.
