Как работают с системной схемой проекта

 

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

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

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

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

 

Подальфы

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Основной жизненный цикл

 

Горбатая диаграмма, использовавшаяся в RUP, получила своё развитие: в более современных версиях (например, из enterprise unified process, EUP, 2013) приводится другой набор практик и другой (полный, а не только стадии разработки и перехода к эксплуатации) набор стадий[205]:

 

 

Интересно, что и тут есть трудности – попытка изобразить то, что происходит до момента запуска проекта как последовательности стадий работ, но в жизненный цикл попадает.

Стандарт OMG Essence предложил ещё один вид жизненного цикла, удобный для отслеживания смены состояний основных альф. Это представление похоже на «горбатую диаграмму», использовавшуюся в EUP, только вместо практик там указаны задающие тематику работ альфы (а практики подразумеваются те, которые будут работать с этими альфами и их рабочими продуктами):

 

 

 

 

Как и любые диаграммы видов жизненного цикла, диаграммы OMG Essence – огромное упрощение. Так, в этих диаграммах не отражены подальфы, которые тоже меняют свои состояния асинхронно. На диаграммах также не отражено то, что в жизни мы наблюдаем не альфы непосредственно, но судим об их состоянии по рабочим продуктам. Более того, от этих диаграмм остаётся впечатление того, что проект может быть устроен «водопадным» образом, а это не так. Во-первых, альфы совершенно необязательно меняют своё состояние строго поступательно: нет, в них в ходе проекта возможны (и обычно происходят) откаты назад, включая и состояния их подальф. Во-вторых, мы показали тут только намеренно упрощённую последовательность прохождения состояний, а ведь состояния альфы могут представлять собой произвольный граф, включая циклы в этом графе.

Дополнительное усложнение – это то, что у заказчика (владельца и часто разработчика использующей системы) и контракторов (разработчиков и производителей подсистем) свои жизненные циклы своих проектов, и их тоже нужно согласовывать.