Как пользоваться контрольными вопросами к состоянию проекта
Основы (OMG Essence) предполагают активное использование контрольных вопросов для определения текущего и желаемого состояний проекта. Для этого стандарт предлагает список самых основных, минимальных вопросов в виде их списков (чеклистов) -- я предложил перевод этих списков в http://ailev.livejournal.com/1059781.html.
Обоснование такого подхода хорошо изложено в книжке Checklist Manifesto (http://ailev.livejournal.com/1029295.html). То есть, как минимум:
-- читаются чеклисты вслух в присутствии всей команды (команда должна согласиться с зачитанным) в специальных проверочных паузах (checkpause). Фишка в том, что ежели кто-то из участников проекта понимает, что есть проблема, то зачитывание вслух и подтверждение ответа всеми -- именно тот момент, когда все члены команды могут о проблеме узнать (т.е. все считают, что какой-то контрольный вопрос пройден, но у кого-то может быть знание, что это не так -- и он спасёт ситуацию, не даст наступить на затаившиеся грабли).
-- срабатывает чеклист (там, где ожидалось единогласное "да", вдруг оказывается "нет") только один раз из десяти, но этот один раз обычно является критическим для успеха проектах. Ибо люди очень умны, но забывчивы, и регулярно полагаются на "авось" (или на то, что работу сделал кто-то другой). Основы предполагают, что достижение состояний со всеми отвеченными утвердительно контрольными вопросами обеспечивается тяжёлой работой, их достижение необходимо, и отрицательные ответы означают, что работы было недостаточно. Незаданный вопрос (или нечестный ответ на вопрос) -- это классические грабли, на которые наступают по самым разным причинам, хотя об их существовании прожужжали все уши, всем они известны, но... хотят как лучше, получается, как всегда. Чеклисты Основ -- именно об этом, о возвращении к основам, о проверке тривиального.
Для каждой альфы (возможности, стейкхолдеров, требований, программной системы, команды, работы, технологии) выбирается проверяемое состояние, и его достижение как раз и характеризуется успешным прохождением списка контрольных вопросов. Если чеклист не удаётся пройти, значит вы ещё на предыдущей стадии, и вам нужно поработать ещё. Важно, что контрольные вопросы задаются к состояниям всех альф -- это понятно, но с этим как раз наибольшие проблемы, ведь это вопросы и к организации, и к технологии работ, а работы по организации работ и технологии часто и работами не считаются, отчего плохая организация и технология заваливают весь проект.
Контрольные вопросы чеклиста к каждому состоянию банальны, понятны, они про то, "как хорошо быть здоровым и богатым, нежели бедным и больным". Никаких чудес в плане содержания. Чудеса происходят в ходе их использования, и то не каждый раз, а только иногда. Но это "иногда" обычно предотвращает проектную катастрофу.
Использовать чеклисты можно очень по-разному. Например, сыграть в командный покер (чеклисты к состояниям альф пишутся на карточках, затем каждый член команды выкладывает на стол рубашкой вверх карточки текущих достигнутых состояний всех альф. Затем карты переворачиваются -- и если у всех они одинаковые, то консенсус. Если неодинаковые -- то члены команды по-разному оценивают ситуацию, и нужны срочные обсуждения реального состояния дел). Можно использовать чеклисты для планирования (типичная ошибка, когда в план попадают работы только по одной или парочке альф, но не по всем альфам -- а ведь если какие-то контрольные вопросы не проходятся, то это означает, что какая-то работа не была сделана).
Разнообразие использования этих чеклистов огромно. Я лично применял их к своим проектам за последнюю неделю раза три, и каждый раз это оказывалось крайне полезным. Возможно, нужно применять их даже чаще, а к результатам применения относиться серьёзней.
Конечно, при адаптации Основ, расширении числа их сущностей, принятии каких-то практик будут расширяться и число альф, и списки их состояний, и формулироваться новые контрольные вопросы. Вот почему создатели Основ говорят, что этот стандарт ориентирован не на облегчение работы методологов (мне кажется, так ровно наоборот: он усложняет их задачу), а на облегчение работы участников разработок -- применение стандарта по большей части заключается в разбирательстве с этими "банальными" контрольными вопросами.
Обоснование такого подхода хорошо изложено в книжке Checklist Manifesto (http://ailev.livejournal.com/1029295.html). То есть, как минимум:
-- читаются чеклисты вслух в присутствии всей команды (команда должна согласиться с зачитанным) в специальных проверочных паузах (checkpause). Фишка в том, что ежели кто-то из участников проекта понимает, что есть проблема, то зачитывание вслух и подтверждение ответа всеми -- именно тот момент, когда все члены команды могут о проблеме узнать (т.е. все считают, что какой-то контрольный вопрос пройден, но у кого-то может быть знание, что это не так -- и он спасёт ситуацию, не даст наступить на затаившиеся грабли).
-- срабатывает чеклист (там, где ожидалось единогласное "да", вдруг оказывается "нет") только один раз из десяти, но этот один раз обычно является критическим для успеха проектах. Ибо люди очень умны, но забывчивы, и регулярно полагаются на "авось" (или на то, что работу сделал кто-то другой). Основы предполагают, что достижение состояний со всеми отвеченными утвердительно контрольными вопросами обеспечивается тяжёлой работой, их достижение необходимо, и отрицательные ответы означают, что работы было недостаточно. Незаданный вопрос (или нечестный ответ на вопрос) -- это классические грабли, на которые наступают по самым разным причинам, хотя об их существовании прожужжали все уши, всем они известны, но... хотят как лучше, получается, как всегда. Чеклисты Основ -- именно об этом, о возвращении к основам, о проверке тривиального.
Для каждой альфы (возможности, стейкхолдеров, требований, программной системы, команды, работы, технологии) выбирается проверяемое состояние, и его достижение как раз и характеризуется успешным прохождением списка контрольных вопросов. Если чеклист не удаётся пройти, значит вы ещё на предыдущей стадии, и вам нужно поработать ещё. Важно, что контрольные вопросы задаются к состояниям всех альф -- это понятно, но с этим как раз наибольшие проблемы, ведь это вопросы и к организации, и к технологии работ, а работы по организации работ и технологии часто и работами не считаются, отчего плохая организация и технология заваливают весь проект.
Контрольные вопросы чеклиста к каждому состоянию банальны, понятны, они про то, "как хорошо быть здоровым и богатым, нежели бедным и больным". Никаких чудес в плане содержания. Чудеса происходят в ходе их использования, и то не каждый раз, а только иногда. Но это "иногда" обычно предотвращает проектную катастрофу.
Использовать чеклисты можно очень по-разному. Например, сыграть в командный покер (чеклисты к состояниям альф пишутся на карточках, затем каждый член команды выкладывает на стол рубашкой вверх карточки текущих достигнутых состояний всех альф. Затем карты переворачиваются -- и если у всех они одинаковые, то консенсус. Если неодинаковые -- то члены команды по-разному оценивают ситуацию, и нужны срочные обсуждения реального состояния дел). Можно использовать чеклисты для планирования (типичная ошибка, когда в план попадают работы только по одной или парочке альф, но не по всем альфам -- а ведь если какие-то контрольные вопросы не проходятся, то это означает, что какая-то работа не была сделана).
Разнообразие использования этих чеклистов огромно. Я лично применял их к своим проектам за последнюю неделю раза три, и каждый раз это оказывалось крайне полезным. Возможно, нужно применять их даже чаще, а к результатам применения относиться серьёзней.
Конечно, при адаптации Основ, расширении числа их сущностей, принятии каких-то практик будут расширяться и число альф, и списки их состояний, и формулироваться новые контрольные вопросы. Вот почему создатели Основ говорят, что этот стандарт ориентирован не на облегчение работы методологов (мне кажется, так ровно наоборот: он усложняет их задачу), а на облегчение работы участников разработок -- применение стандарта по большей части заключается в разбирательстве с этими "банальными" контрольными вопросами.