Системное мышление

Альфы системной схемы проекта полезны не только для того, чтобы делать отчёт о ходе проекта, но и для того, чтобы давать полезный отклик по таким отчётам. Если в отчёте не сказано ни слова про команду, то обязательно нужно задать вопросы – в каком состоянии команда. Может выясниться много интересного. Это всё не будет случайными вопросами, альфы ведь эти выбраны не случайно, а отражают опыт многочисленных разработок, обобщённый авторами стандарта OMG Essence.

Ещё один вариант использования системной схемы проекта – это понять, какие компетенции в команде проекта есть, а какие отсутствуют. Распечатайте системную схему проекта и дайте участникам проекта отметить крестиком те альфы, за состояние которых он планирует в этом проекте отвечать. Если какие-то альфы остались без своих крестиков – то проект ждут большие риски.

Но это же можно перевести и в другой режим: вместо «опроса» может быть осознанное принятие ответственности за какие-то альфы (или подальфы) в проекте. Проект как целое разбивается на изменяющиеся по его ходу объекты, требующие особого внимания (альфы), и команда проекта принимает индивидуальные ответственности за эти объекты – и коллективную ответственность за согласование действий по их поводу. Системный подход заключается тут в том, что ни на один момент не теряется целое, но со сложностью проекта в каждый момент времени можно иметь дело по частям: все остальные части проекта никуда не деваются, они отмоделированы, о них помнится, к ним обязательно вернутся и проверят, насколько они согласованно вписываются в целое.

Подальфы

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

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

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

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

• Привлечён –

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

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

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

• Работы закрыты –

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

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

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

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