Диагностика команды в преддверии больших изменений

Ольга: Мы расскажем о реальной истории из нашего опыта – о том, как мы проводили диагностику команды и готовили ее к проводимым изменениям.

Меня зовут Ольга Суховнина, я директор по персоналу. Больше 10 лет я реализую различные проекты по обучению, развитию сотрудников, адаптации, введению организационных изменений и другим очень важным HR-процессам. С 2019 года я отвечаю за HR-процессы в группе компаний «СофтБаланс».

Николай: Меня зовут Николай Гильченко. Я руковожу корпоративными проектами и подразделением, которое занимается автоматизацией бизнеса.

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

Сегодня мы:

• поговорим об изменениях и проблемах, которые им предшествуют;

• рассмотрим, какие методики для решения проблем можно использовать, и какие использовали мы;

• уделим довольно много времени такому способу отработки моделей взаимодействия, как деловая игра – расскажем, как мы ее проводили;

• и подведем итоги – расскажем, что у нас получилось и получилось ли что-то вообще.

Но сначала – небольшой эксперимент

Ольга: Прежде, чем мы начнем, попробуйте вспомнить три основные проблемы, с которыми вы сталкиваетесь в работе своей проектной команды. Неважно, в какой роли лично вы работаете в команде – главное, чтобы с вами работали другие роли.

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

Николай: Мы структурировали наши варианты в формате запросов, вопросов, восклицаний, чтобы сразу было понятно, в чем проблема:

• Первая категория с самыми простыми проблемами – это, как ни странно, нехватка квалификации, опыта, знаний. Что с этим делать? Вполне понятно: учиться, нарабатывать опыт, проходить тренинги и так далее – здесь все просто.

• Вторая категория – это регламенты, инструкции, описание порядка действий. Их, конечно, сначала нужно написать, но этого недостаточно – их еще нужно привести в действие. Не всегда это легко.

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

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

С чего все началось

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

Для начала некоторые исходные данные.

• Проектная команда: 20 человек, не очень большая,

• Роли: руководители проектов, аналитики, разработчики.

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

Хард-скилы действительно высокие – их тренировать особого смысла нет, персонал квалифицированный, сотрудники молодцы.

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

А тут оказалось, что с какого-то момента мы по локальным задачам:

• стали срывать сроки;

• выбились из бюджета;

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

Безусловно, первое воздействие со стороны менеджмента – это простые классические вещи типа:

• Переиграть составы команд – эти двое друг другом не уживаются, расходимся в разные команды, делаем разные проекты.

• Усилить контроль – проверять каждое действие: что сделали, что получилось, что будем делать завтра и так далее.

• Как это ни странно, еще больше подтянуть харды – предполагаем, что нужно еще больше квалификации.

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

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

И самое неприятное – на почве всего этого у нас ухудшается атмосфера в коллективе. Когда есть проблемы, их пытаются решить, и они не решаются – радости это не добавляет.

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

HR спешит на помощь. Диагностика и поиск решений

Ольга: И Николай пришел к нам в отдел персонала с вопросом, чем мы можем помочь.

Действительно, задача была интересная, потому что на первый взгляд вроде бы все хорошо – и с командой все в порядке, и с хардами. Видимо, что-то с софтами.

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

Для этого мы решили провести фасилитационную сессию.

Мы ее провели в четыре этапа – по отдельной сессии для каждой роли. Отдельно аналитики, отдельно разработчики, отдельно руководители проектов и общая итоговая сессия.

Основная цель была – дать людям возможность высказаться в свободном формате. В режиме мозгового штурма набросать проблемы, которые их беспокоят, и сложности – в чем они видят причину неэффективности. Для этого мы попросили их ответить на несколько ключевых вопросов:

• С какими сложностями в работе лично вы сталкиваетесь?

• Какие у вас обязанности в команде, за что вы отвечаете?

• Что с вашей точки зрения мешает продуктивной работе в команде?

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

А потом уже вместе с Николаем классифицировали ответы – разбили их на кластеры проблем в обезличенной форме. Это было важно, чтобы не было чьей-то конкретной жалобы, а была именно проблема.

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

Самой, наверное, важной частью здесь была подготовка – в Google-документе я собрала наши заметки по подготовке к сессии. Обращаю внимание – именно по подготовке, потому что проведение, методы, инструменты очень сильно зависят от вашей ситуации и вашей задачи. А именно подготовка плюс-минус универсальна.

Озвучу несколько самых ключевых моментов.

• Самое главное – нужно действительно погрузиться в вопрос. Нельзя просто прийти, задать вопросы и уйти. Нужно понять, как работает команда, какое взаимодействие, какие могут быть скрытые конфликты, какие могут быть противоречия между ролями. Кто в чем задействован, кто в чем заинтересован. Это помогло подготовить вопросы, это помогло максимально погрузиться в ситуацию, чтобы потом качественно поработать с результатами.

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

• И еще очень важный момент – это безопасная атмосфера. Сотрудники должны понимать, что это не дисциплинарная история, это действительно поиск решения, которое подойдет всем. Это помощь. И они должны четко понимать, что им ничего за это не будет – можно честно и открыто говорить. Если вы не готовы проводить сессии в таком формате, подумайте над инструментом – может быть вам нужен какой-то другой. Потому что результат будет, только когда коллеги готовы делиться, и они ничего не боятся.

Николай: По итогу у нас получился довольно большой список проблем – важно, что эти проблемы, по сути, выявили, выдвинули, назвали сами сотрудники.

Сами же сотрудники придумали огромное количество решений этих проблем – набросали довольно большой список вариантов.

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

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

И мы стали с ним жить какое-то время.

К сожалению, выяснилось следующее.

Да, правила придумала команда, она с ними согласна, она их приняла – все здорово. Распечатали, повесили на стенку – все видят.

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

Поскольку мы не готовы были оттачивать новые правила взаимодействия на наших рабочих проектах, нам понадобился некий тестовый стенд – тестовая платформа, где мы смогли бы проиграть все эти правила, не боясь что-то сломать.

Деловая игра. Как мы поняли, что нам нужен нестандартный подход к решению задач

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

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

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

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

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

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

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

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

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

• Более того, мы перемешали сотрудников: сделали разработчиков – аналитиками, а аналитиков – руководителями проекта или разработчиками, чтобы каждый на себе прочувствовал, каково живется другому.

Последним этапом игры, когда уже были получены результаты, мы провели рефлексию с командой, где разбирали: что получилось, что не получилось и почему.

И здесь все сработало – коллеги часто упоминали историю про правила команды:

• «Если бы мы сделали так, тогда бы у нас получилось»;

• Или «Мы сделали по правилам – поэтому у нас и вышло».

Это оказалось действительно максимально наглядной историей.

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

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

Что делать, если вы не можете сами такое придумать:

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

• Есть провайдеры, которые могут разработать игру или тренинг под ваш запрос.

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

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

Итоги и выводы. Что получилось в результате и чем это может быть полезно всем

Николай: Подведу некоторые итоги и выводы. Что это дало для команды?

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

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

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

• Ну и безусловно после этого мероприятия команда перешла на несколько иной формат общения. Пока непонятно, насколько хватит этого мероприятия, чтобы этот формат общения оставался – тем не менее результат такой есть.

И часто все хотят еще увидеть некие цифровые результаты. Безусловно, все это очень непросто здесь вывести. Ну мы постарались очень примерно и условно с каким-то допущением дать эти результаты.

• У нас в работе (и у вас в работе, наверное) есть такой показатель как итерация. Для нас он важный. На слайде я показал, насколько по результатам мероприятия изменилось количество итераций – сколько раз задача циркулирует между аналитиком и разработчиком. Количество итераций уменьшилось в 2,5 раза. Это очень существенная цифра, она очень заметная в работе. Мы серьезно это увидели.

• Плюс, у нас сократилось количество «пустых» коммуникаций: всевозможные ненужные, лишние совещания, на которых происходит обсуждение, но не происходит ничего более (ни выработки, ни результата и т.д.). Экономия в неделю составила до 8 часов на команду. Это важно понимать – что у каждого участника команды освободилось по восемь часов.

• Мы стали активнее пользоваться «быстрыми решениями» – не писать письма, не писать в мессенджерах, не устраивать долгую переписку. 10 минут – договорились, не договорились, а дальше уже какие-то действия.

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

Ольга: Что еще дополнительно «подсветил» проект.

• Как ни банально, но, видимо, это все очень актуально – коммуникация всему голова. Вам кажется, что вы общаетесь с командой, но часто оказывается, что этого недостаточно.

• Кто когда-то интересовался вопросами организационной психологии, инженерной психологии, слышали про эксперимент Элтона Мэйо, который в начале 20-го века проводил эксперименты на электрической фабрике. Они меняли условия работы работникам фабрики и замеряли, как повышается или изменяется их эффективность. Главным открытием этих экспериментов было то, что не только изменение условий труда влияли на продуктивность, на продуктивность влияло само внимание к сотрудникам. Когда их спрашивали: удобно им или неудобно, нравится или не нравится, как им лучше, какие у них проблемы и т.д. – уже само это внимание от руководства повышало мотивацию и продуктивность работы. 100 лет прошло, но ничего не меняется – вашим и нашим сотрудникам все еще очень важно, чтобы с ними разговаривали, спрашивали их мнение и прислушивались к их проблемам.

• Фасилитационные сессии – это отличный инструмент, чтобы пообщаться со своей командой в открытую.

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

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

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

• Безусловно, мы пересмотрели те регламенты и инструкции, которые у нас были. Что-то выкинули, что-то изменили, что-то добавили, что-то еще добавляем.

• Так как взаимодействие и быстрая коммуникация позволили нам ускориться, мы были вынуждены (в положительном смысле вынуждены) посмотреть на то, как мы сами автоматизированы, и здесь немного ввели изменения с точки зрения софта, которым мы сами пользуемся, чтобы он позволял нам работать быстрее.

И в конце – основная мысль, которую мы хотели донести:

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

Вопросы и ответы

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

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

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

Или просто попробовать с каждым индивидуально поговорить – провести индивидуальные сессии и потом уже сделать общую групповую.

Николай: У нас двадцать человек, но по ответам я все равно угадывал, кто что ответил. Здесь нет никакой тайны. Есть отдельные яркие индивидуумы, которые отвечают вполне понятным стилем. Но когда вам ответили, вы перед тем как транслировать это на остальную команду, можете эти ответы перефразировать и обезличить.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".