Анатолий Левенчук - Системное мышление

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

«Стейкхолдеры признаны»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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