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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• См. Карточные игры
• см. также Карточки OMG Essence