Проверенный способ вовлечь команду и улучшить процесс: инструкция «делай раз, делай два»

<сорри, картинку не успеваю нарисовать, статья здоровая получилась>

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

Вот э фак из сессия ретроспективы?

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

Если при этом описании вы внутренне содрогнулись — понимаю вас. Скорее всего, вы представили себе т. н. «разбор полетов» — разъёб-сессию, на которой задают неприятные вопросы типа: «А почему мы просрали эту задачу?» или «Почему Иванов не сделал то, что должен был?», и после которой все выходят немного изнасилованными. Мало кому хочется что-то в таком роде повторять.

Ретроспектива в корне отличается от «разбора полетов» тем, что, несмотря на название, направлена в будущее. Цель ретроспективы — не выяснить, кто где обосрался. Какой в этом прок? Разве мы можем метнуться в прошлое, и не обосраться тогда, в тот раз? Что мы можем, это договориться о том, что делать, чтобы в дальнейшем обсёров было меньше. И этому очень поможет, если в ходе сессии никто не будет чувствовать себя мудаком и «слабым звеном».

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

Шобы шо?

(Очень люблю, кстати, вопрос, вынесенный в заголовок раздела, и часто его задаю: прям глазооткрывающий иной раз. Если кто не понял, имеется в виду, «ради чего?», «что в этом ценного?»).

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

Ретроспектива — это как раз ваше решение договориться о том, как работать лучше, эффективнее.

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

Приведу пример.

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

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

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

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

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

Что произошло? Я просто сказал команде: ребята, это наше общее дело, мы должны фигачить вместе. Есть идеи, что улучшить — вэлкам, я готов поддерживать, но отсидеться не получится. И вместе со всеми работал над этим процессом.

Окей, как это правильно делать?

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

  1. Вводная: цели сессии, тайминг, установочные вопросы. Очень важно проговорить это в самом начале, чтобы люди понимали: что происходит, зачем они здесь, чего от них ожидают, когда их отсюда выпустят. Если этого не сделать, вы посреди сессии получите внезапно покидающих аудиторию участников, или вопросы: «а что мы вообще делаем?» и пр. Не гуд.
  2. Айсбрейкер. Небольшое групповое обсуждение, которое помогает участникам расслабиться, заскочить на флоу совместной работы. Хорошо работают штуки типа: «расскажи про себя две правды и одну ложь, а мы угадаем, где что», или «расскажите о чем-то замечательном, что произошло у вас за <период ретроспективы>». Важно, что после айсбрейкера люди на позитиве, открыты и им начинает нравиться происходящее. Что будет, если вы пропустите эту стадию? Большой шанс, что кто-то из участников будет сидеть в позиции «глухой обороны», тухлить и вообще сливать сессию. Можете проверить, но лучше не пренебрегать айс брейкерами.
  3. Насколько вы счастливы тем, как мы сработали за <период ретроспективы>? Здесь можно построить «гистограмму счастья»: команда клеит стикеры на горизонтальной оси 1 — 5, стикеры один над другим. Получается, что если на оценке 3 — четыре стикера, то столбик «3» — высотой в четыре стикера. На других оценках — другое количество стикеров, в результате получается столбчатая диаграмма. Обсуждаете с командой, кто какой стикер приклеил и почему. Зачем это нужно? Это очень наглядно показывает, что не «все ОК». Если оценка не 5 из 5, то явно с чем-то можно поработать. Без этого шага у вас может не оказаться предмета для разговора: например, все говорят «да нормально, не хуже, чем у других». А тут вы можете сказать: «Что надо, чтобы было 5 из 5»?
  4. Делим маркерную доску на две части, слева пишем: что нам помогает достичь 5 из 5 с точки зрения качества процесса, справа — что нам мешает. Каждый член команды должен написать на стикерах минимум N факторов и на ту, и на другую сторону доски. Почему именно на стикерах, почему нельзя на словах? Потому что это ненавязчиво заставляет даже самых застенчивых что-то написать: хочешь не хочешь, а вынь да положь N стикеров. Это УБЕР важно. Ну, кроме того, позволяет избежать непродуктивной дискуссии, когда все друг друга перебивают.
  5. Каждый клеит свои стикеры и рассказывает, что он думает по этому поводу. В этом обсуждении ваша задача — поддерживать фокус на улучшении процесса. Задача группы не в том, чтобы зафиксировать, что <ФИО> обосрался, а выявить сбои в процессе, который надо всем вместе пофиксить. Это очень важно, даже если у вас невероятная культура результативности, и обратную связь все на завтрак едят. Если срач и «разбор полетов» все-таки начался, хрен вы загоните второй раз людей на это упражнение.
  6. После этого команда должна разработать решения для всех выявленных мешающих факторов, желательно — с применением способствующих факторов, написать их на стикерах и наклеить на доску. Дублирующие стикеры клеить поверх аналогичных.
  7. Дальше вы устраиваете голосование за лучшие решения. Можно использовать специальные метки для голосования, можно — просто маркером ставить точки (n точек на участника).
  8. После этого участники команды должны выбрать решения, которые они лично готовы внедрить. Это важный пункт. Скорее всего вы, как инициатор, будете самым ответственным, но очень рекомендую раздать ответственность и другим членам команды тоже, чтобы они не только предлагали классные идеи, но и руками поработали. Если по каким-то стикерам-решениям нет ответственных, то вы их к такой-то матери выкидываете. Тут, конечно, надо тонко чувствовать и культуру организации, и характер предлагаемых улучшений. Не всегда такая жесткость уместна: например, если от действий команды реально мало что зависит, надо все зарешивать вам с руководством.
  9. Дальше вы еще раз составляете «гистограмму счастья», но теперь to be: если вы внедрите то, о чем договорились, насколько вы будете счастливы процессом? Показатель должен улучшиться, иначе нахрена вы это все писали.

Вся сессия первое время будет занимать у вас часа три-четыре. Рассчитывайте на это время: с нормальными обсуждениями, выработкой решений и пр. На 10-й ретроспективе — 1,2-2 часа. Вы скажете «много» и «у меня никто не согласится выделить столько времени на это». Понимаю, слышал это тысячу раз. Но давайте посчитаем: команда из 5 человек потратит на четырехчасовую ретроспективу 20 человекочасов раз в две недели. Как вы думаете, как быстро это время окупится, если «отныне и вовеки» команда будет делать какие-то вещи быстрее, экономя на этом 3 часа в неделю? А если вы предотвратите факап, из-за которого вся команда просидела бы выходные?

Короче: это инвестиции времени, которые окупаются.

Как сделать так, чтобы это заработало

Во-первых, если вы не очень уверены в своих навыках фасилитатора, можете пригласить профессионала, который таких ретроспектив проводил десятки и сотни. Гуглите «фасилитация ретроспектива», или пишите мне в Телегу ;)

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

Поделиться
Отправить
Популярное