Практика контрольных вопросов

Практика контрольных вопросов — одна из самых мощных практик, позволяющая снизить фатальные ошибки от досадных промахов в сложной деятельности. Она лучше всего описана в книге Atul Gawande "The Checklist Manifesto"[1] (есть перевод на русский). Её суть: "мало что более эффективно в сверхсложных коллективных проектах, чем дисциплинированно проходимые чеклисты, но это мало где признаётся, кроме авиации, космонавтики, медицины".

Контрольные вопросы

Контрольные вопросы (checklist, “список контрольных вопросов”, а “отдельный вопрос” будет “checkpoint”) существуют в самых разных формах: от “классического” до списка работ в строительном проекте в составе структуры разбиения работ, от списка проверок due diligence в инвестиционных фондах до таблички на дверях “выключил ли ты свет?”.

Чеклист обычно — это короткий список (пять-семь, и лишь иногда семьдесят или семьсот) действий, каждое из которых должно быть сделано во время зачитывания списка (чеклист типа READ-DO), или результатов/условий/действий, которые должны быть подтверждены по мере зачитывания списка (DO-CONFIRM).

Наиболее эффективно использование чеклиста при смене состояний каких-то альф, в которых принимается решение Go-NoGo в ходе жизненного цикла альфы, т.е. в точках возможного “невозврата”. Чеклист "прочти-подтверди" (DO-CONFIRM) представляет собой проверку того, что сделано на предыдущей стадии, чтобы попасть в следующую стадию. Ну, или чтобы попасть в следующую стадию, нужно прогнать чеклист "прочти-сделай" (READ-DO, этот тип чеклиста обычно выполняется при попадании во внештатную ситуацию). Главных чеклистов обычно несколько штук, а вот "аварийных" могут быть сотни.

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

Контрольные вопросы к состояниям альф

Контрольные вопросы к состояниям альф сформулированы по типу “READ-CONFIRM”, т.е. нужно ответить на утверждения “да”, чтобы подтвердить достижение какого-то состояния альфы. Эти утверждения кажутся банальными, но есть подвохи:

  • При всей примитивности и очевидности, утверждения должны быть проверены и ответы должны быть обоснованы. Если кто-то из членов команды знает, что ответ “нет”, то он обязан предупредить всех членов команды, и можно будет предпринять какие-то меры. Если о проблеме умолчать, то меры не будут приняты, и риск провала проекта увеличится.
  • На некоторые вопросы вы не сможете ответить, если не будете знать соответствующей практики, а иногда даже и просто дисциплины.
  • Контрольные вопросы — это не всё, что нужно для успешного выполнения проекта. Это просто “банальности, про которые иногда забывают”. Только отвечая на контрольные вопросы, проект не выполнишь.

Контрольные вопросы записывают на карточки.

Когда заводить подальфы

Очень часто невозможно ясно ответить на контрольный вопрос основной альфы (а иногда и подальфы):

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

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

  1. Убедиться, что это такой объект в проекте, за изменениями которого нужно следить.
  2. Назвать её и указать подчинённость (другим подальфам или основным альфам).
  3. Прописать список состояний альфы.
  4. Прописать контрольные вопросы (checkpoints) для каждого состояния.

Определение подальфы состоит из следующих шагов:

  1. Определить, что она из себя представляет (из какой она дисциплины — это было бы лучше всего, но инженеры могут создавать альфы и “по наитию”, не на основе теории, а на основе эвристик. Главное, это не путать альфу и рабочий продукт, свидетельствующий её состояние).
  2. Определить, подальфой каких альф (или подальф) она будет — в том числе сразу нескольких (так, “член команды” это подальфа альф “команды” и “стейкхолдеры” одновременно).
  3. Определить, какие основные состояния будут у этой подальфы, определяющие её жизненный цикл.
  4. Сформулировать контрольные вопросы к каждому состоянию и оформить их в виде набора карточек.
  5. Определить, какие рабочие продукты должны будут свидетельствовать прохождение состояний этой новой альфы, если это описания, то какие практики описаний будут использованы для этих продуктов и какие инструменты будут поддерживать эти практики описаний.
  6. Если какие-то рабочие продукты окажутся отсутствующими, то разработать их на основе библиотечных (т.е. уже известных) практик описания. Если не нашлось подходящей практики описания, то создать её!

Карточные игры

Примечания

  1. ↑ [https://www.ozon.ru/context/detail/id/26845885/ А. Гаванде - Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям"
Источник — «http://sewiki.ru/index.php?title=Практика_контрольных_вопросов&oldid=3534»