Подальфы

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что уровня контроля не хватает, и нужно внимание к частям ситуации, определяемой альфой. Подальфа – это просто альфа, только она не «верхнего уровня», не основная (essence), не из системной схемы проекта. Более того, у каждой альфы (в том числе у подальф) могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе (прежде всего тут нужно указать на разработки Ivar Jacobson International по разработке альф для самых разных практик, особенно для гибких методологий203).

Вот пример альфы «подрядчик» как подальфы «стейкхолдеры» и «команда». Это альфа была подготовлена для крупной компании, занимающейся сооружением сложных инженерных объектов, отсюда и специфика её состояний. Для других проектов и других компаний это были бы совсем другие состояния:

• Признан – обоснование аутсорсинга есть; требования и ограничения для подсистемы есть; требования к гарантийному обслуживанию и ремонтным работам есть; требования к технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.

• Выбран – технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.

• Привлечён – валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.

• Работы идут – надзор за работами установлен; запросы обоих сторон учитываются; запросы обоих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.

• Работы приняты – уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписан; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.

• Работы закрыты – акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

Регулярная проверка того, что сделано и что не сделано по такому чеклисту существенно снижает риски.

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

Как пользоваться постоянно раздувающимся списком подальф с их контрольными вопросами для прохождения контрольных точек может помочь практик работы с чеклистами, описанная в книге Атула Гаванде «Чеклист. Как избежать глупых ошибок, ведущих к фатальным последствиям».204

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

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