18.03.2020 | Добавил: OleshkoV | Просмотров: 142
Извлеченные уроки: обзор Денниса Пирса. Часть 3

Двигаемся дальше по циклу извлеченных уроков с Деннисом Пирсом. В предыдущей части мы обсудили первые два этапа цикла – инициацию и признание. В своей четвертой заметке автор переходит к этапу собственно извлечения (capture) знаний из полученного опыта. Деннис предлагает рассмотреть три вопроса в этом контексте: «Зачем?», «Кто?» и «Как?».

Зачем извлекать уроки? Здесь идет речь не о том, о чем вы сразу подумали («чтобы учиться на своем опыте и повышать эффективность процессов»), а о мотивации сотрудников это делать. Автор рассматривает две ситуации: 

  1. Извлечение уроков встроено в стандарты выполнения процессов и проектов – то, что называется «in the flow», «мы всегда так делаем». Например, разбор полетов (AAR) как привычная рутинная процедура в рамках управления проектами.
  2. Извлечение уроков проводится разово как мероприятие, выходящее за рамки привычных процедур – «above the flow». Тот же разбор полетов, на который «вдруг» собрали команду проекта.

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

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

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

Итак, советы фасилитаторам:

  • Если у команды дефицит времени и ее участники перегружены разными встречами, можно провести подготовку: заранее по электронной почте собрать у участников ответы на первый вопрос AAR («Что должно было произойти?»). Фасилитатор может обработать эти ответы: сгруппировать их, выявить какие-то общие закономерности и т.п. Это сэкономит время в ходе самой встречи.
  • Если разборы полетов проводятся регулярно, можно попробовать составить стандартный список ожиданий (ответов на первый вопрос). Этот список, кстати, может стать неплохим тестом: действительно ли организация учится на своих ошибках или повторяет их раз за разом.
  • Бывает удобно фиксировать результаты в таблице (можно сразу в Excel и вывести на большой экран, чтобы все участники видели, как она заполняется): названия колонок – вопросы AAR; в строках указаны ожидания – ответы на первый вопрос. Тогда можно идти не по колонкам, а по строкам: каждое ожидание прогонять по всем вопросам со второго по четвертый, а потом переходить к следующему ожиданию.
  • Если при обсуждении второго вопроса («Что произошло на самом деле?») участники начинают рассказывать отвлеченные истории, никак не связанные с ответами, которые они дали на первый вопрос, их можно попробовать вернуть к теме, переформулировав вопрос: попросить пройтись по каждому из ответов на первый вопрос и сказать, были ли реализованы эти ожидания (да/нет). Иногда при этом может возникнуть потребность переформулировать эти ответы. Например, ответ «Все детали должны были прийти до 15 мая» лучше, чем ответ «Все детали должны были прийти вовремя».
  • При ответе на третий вопрос («Почему это произошло?») нужно постараться подтолкнуть участников в глубину, к поиску коренных причин (да, те самые «5 почему?» в помощь). Это особенно важно, когда исследуются коренные причины положительных событий – здесь очень велик риск просто сказать: «Все получилось так, как мы ожидали, потому что мы так запланировали». Также при обсуждении того, что прошло хорошо, у команды возникает желание ускориться – «Все ок, давайте двигаться дальше». Здесь нужно тормозить процесс вопросами: «Вы действительно уверены, что все ок?», «Даже если все прошло хорошо, есть ли что-то, что можно улучшить?».

Позволю себе дополнить текст Денниса Пирса рекомендациями из книги Ника Милтона «Knowledge Management for Teams and Projects». Для углубления в причины успеха Ник советует использовать вопросы «Что вы сделали для того, чтобы успех случился?», "Что бы вы порекомендовали команде будущего проекта, чтобы повторить успех?", "Если бы вам пришлось снова сделать это завтра, как бы вы это сделали?". Последние два вопроса адресуют нас к четвертому пункту повестки разбора полетов.

  • Четвертый резюмирующий вопрос «Чему мы можем научиться?» Деннис предлагает в другом формате – «Что вы сделаете в следующий раз?». В длинных проектах «следующий раз» может быть следующим этапом этого же проекта или аналогичным этапом следующего проекта. Рекомендации в первом и во втором случае могут быть разными – автор советует разделить их на две колонки. Также он предлагает добавить еще две колонки: 1) напротив каждой рекомендации проставить «У»=«улучшить» (для предложений по усовершенствованию) или «С»=«сохранить» (для хороших практик, которых нужно придерживаться и дальше); 2) указать ответственных за реализацию каждой рекомендации.
  • Следите, чтобы участники встречи не скатывались к банальным «дайте нам больше денег/времени/рабочих рук и т.п.». Такие утверждения – это не извлеченные уроки, и они не помогают команде научиться чему-то новому.
  • Настаивайте на точности формулировок. Участники встречи могут вкладывать разный смысл в слова и фразы вроде «вовремя», «как можно лучше», «сделать работу лучше» и т.п. Если не прояснить сразу, что имеется в виду, может оказаться, что в головах участников разная картинка, и эти противоречия всплывут позднее.
  • Молчание во время дискуссии часто бывает некомфортным, но может быть полезным. Несколько секунд тишины после того, как вы задали вопрос, могут показаться вечностью, но не спешите что-то говорить, чтобы заполнить паузу, или переходить к другому вопросу. Иногда самые лучшие идеи приходят после того, как все в тишине стараются придумать, что бы сказать.
  • «Застрять» надолго на одной из тем вполне допустимо, если все придерживаются этой темы, не уходя в сторону. Некоторым людям необходимо проговаривать вслух свои мысли, пока они не доберутся до ключевой идеи. Хорошо, когда участники начинают объяснять друг другу какие-то вещи, даже если это занимает много времени – так они начинают лучше понимать рабочие обязанности, проблемы и ответственность друг друга.
  • Если у вас много пунктов для обсуждения, может возникнуть спешка, желание поскорее пробежаться по списку. Этого делать нельзя. Гораздо важнее и ценнее глубоко обсудить только несколько пунктов и создать подробный план действий или список рекомендаций, чем поверхностно пробежаться по всем пунктам. Если встреча приносит ценность, люди не будут против собраться еще раз, чтобы закончить эту работу.

В конце пятой части Деннис Пирс также дает вопросы для наведения фокуса (Before Action Review), которыми пользуется в своей практике. Я привожу те из них, которые дополняют список вопросов из описания BAR у нас в блоге:

  • «Какие у нас есть точные, измеримые ожидания, которые определят успех?»; «Можем ли мы расставить приоритеты («необходимо сделать», «хорошо было бы сделать» и т.д.)?». Ответы на эти вопросы потом можно использовать как входящую информацию на разборе полетов.
  • «Есть ли что-то, что мы не должны делать, чтобы достичь успеха?». Иногда понимание того, что нельзя делать, бывает не менее важным для успеха проекта, чем понимание того, что делать нужно.

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

Инструменты / 18.03.2020 | Просмотров: 142 | Добавил: OleshkoV | Всего комментариев: 0 / Теги: инструменты управления знаниями, lessons learned, фасилитация
ОБ АВТОРЕ
Виктория Олешко Олешко Виктория, бизнес-тренер, консультант, главный редактор сайта SixSigmaOnline.ru. Автор книги “Управление знаниями: коротко о главном” и блога “Управление знаниями”.
Хотите узнать больше об управлении знаниями? Присоединяйтесь к группе на facebook.
Есть вопросы по управлению знаниями? Интересует корпоративное обучение? Пишите или обращайтесь через мой профиль в сети LinkedIn.

ПОХОЖИЕ МАТЕРИАЛЫ


  Добавить комментарий
avatar
SixSigmaOnline.ru © 2009-2020            Хостинг от uWeb