Я уже писал ранее, что не просто люблю настольные ролевые игры, а еще и использую их в качестве инструмента для решения командных проблем. С момента написания того поста, я провел пару десятков таких игр. Понял, что оригинальные правила Dnd не совсем подходят для моих целей. А еще научился выстраивать сюжет так, чтобы решать конкретные задачи. Работал над своими ошибками и анализировал результаты.

И в итоге, сформулировал свою методологию, которой готов делится. И презентовал я все это не где-нибудь а на TeamLeadConf2023. Кроме теории в докладе много практики — рассказываю про конкретные кейсы, настоящие командные проблемы, которые мне удалось решить за это время. С удовольствием делюсь записью выступления с вами 🤩 Интересно будет и тимлидам, и HR-ам и любителям ролёвок.

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

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

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

Третья волна

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

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

Тибилдинговый булшит

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

НРИ

И вот тут пришло время упомянуть НРИ, то есть настольные ролевые игры . Ведущий (Гейм Мастер) создает мир — описывает его правила, текущее состояние. Представляет персонажей фигурками на столе, рисует карту. А каждый игрок вживается в персонажа — это может быть волшебник или хоббит, космический пират или киборг. Это как RPG. Самая известная из таких игр Подземелья и драконы, сокращенно DnD.

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

Дисклеймер

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

Результат

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

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

Так пусть говорят что делают

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

Найти виноватого

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

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

С чего начать?

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

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

Окунитесь в проект

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

Дробите задачи

Идеальная задача занимает суммарно от 2-х до 6-ти часов. Но при этом имеет самоценность и видимый результат. Это не так мало, чтобы потонуть в потоке, ведь получается что в неделю один человек делает около десятка задач такого размера — это количество вполне может поместиться в “оперативной памяти”. Ну а команда из пяти-семи человек вполне сможет пройтись по списку недельных задач за час в формате «что-как-когда-какой результат».

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

Упростите митинги

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

• Введите регламент. Он должен быть реалистичным и вам придется следить за его выполнением
• Автоматизируйте сбор необходимо информации ко встрече. Например, настройте отдельную доску в Джира куда автоматом будет собираться вся информация, нужная на созвоне
• Если вопросы, которые вы будете задавать требуют обдумывания, то вышлите их адресно и заранее. По возможности, вместе с вопросом пришлите заготовку ответа — так исполнителю будет проще понять чего вы от него хотите
• Не допускайте споров

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

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

Don`t panic

Первым шагом предлагаю выполнить совет с обложки самоучителя «Автостопом по галактике». Худшее что можно сделать — начать паниковать и принимать кучу решений в попытке наверстать упущенное. Поспешные действия точно не помогут, зато легко могут все усугубить.

Команда

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

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

Проектные решения

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

Под такими решениями я понимаю, например, текущую архитектуру сервиса. Опору на внешние источники или зависимости. Договоренности о взаимодействии частей системы друг с другом, API, SOAP и т.д.

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

Процессы

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

Задача

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

Риски

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

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

Итоги

“И это все?” спросит внимательный читатель. Конечно, нет. Все проекты разные. Но эти шесть шагов, на мой взгляд, самый минимальный набор действий, которые стоит совершить до того, как можно садиться за анализ и делать какие-то выводы. Если пропустить какой-то из них, то это почти гарантированный способ не починить процессы, а сломать все еще больше.

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

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

Краткосрочная перспектива

Новые люди в проекте затормозят его, а не ускорят. Есть даже шутка: что 2 программиста сделают за 2 дня, то 4 программиста сделают за 4 дня.

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

Во-вторых, мы увеличиваем количество связей между людьми. Напомню, что оно растет экспоненциально. Для команды из 5 человек – 10 попарных связей, а для 7 уже 21 связь. Команде нужно общаться. Если вы думаете, что у вас схема «звезда», когда каждый разработчик взаимодействует только с PM-ом, то, скорее всего, вы ошибаетесь. В сложных, не детерминированных изначально системах, где в процессе работы принимаются проектные решения, попарное взаимодействие необходимо.

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

Среднесрочная перспектива

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

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

Долгосрочная перспектива

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

Что же, выхода нет?

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

Но ведь как-то команды растут?

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