Цитаты из книг автора «Анатолий Левенчук»

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

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

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

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

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

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

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

Всего семи основных альф как объектов внимания в проекте не будет хватать – тем более в больших проектах. Поэтому команде необходимо уделять внимание не только альфам, но и подальфам. Часто команда будет брать эти подальфы из дисциплин/теорий/принципов принятых ими практик. Например, в практике управления проектами методом критической цепи вводят альфу «буфер проекта» (project buffer) и отслеживают затем её состояние

Например, контрольная точка для альфы команда – «сотрудничает» формулируется как пункт чеклиста «команда работает как одно сплочённое оргзвено; общение в команде открытое и честное; команда сфокусирована на достижение миссии/задания команды; члены команды знают друг друга». Достижение этой контрольной точки требует выбора практики лидерства (дисциплину из какого учебника лидерства будете применять для достижения этой контрольной точки? Инструменты какого поставщика – в 21 веке ведь даже лидерство поддерживается инструментально!). Затем нужно будет провести работы (понять, кто и когда будет проводить эти работы – запланировать работы, а потом выделить время и другие ресурсы, и провести эти работы – выполнение работы) для выбранной практики. Если команда не обсуждает достижение всех этих контрольных точек и не выполняет работы по их достижению, то у проекта могут быть большие (в том числе фатальные для проекта) неприятности. Формулировки контрольных точек в OMG Essence (и, соответственно, в нашем учебнике) намеренно «мутные», неопределённые и расплывчатые. Авторы стандарта говорят, что это поощряет команду провести обсуждение этих контрольных точек, чтобы адаптировать формулировки к индивидуальным особенностям проекта, и получить явное соглашение команды о том, что все члены команды одинаково понимают эти контрольные точки.

Системная схема проекта представляет собой ровно такой чеклист: на верхнем уровне это альфы, которые необходимо удерживать во внимании всё время проекта. Если члены команды не задумывались о состоянии какой-то из альф, то возникают большие риски, что там что-то может пойти не так – просто потому, что не хватило внимания. Проект создания системы обычно не менее сложен и хлопотен, чем взлёт самолёта, поэтому можно ожидать отсутствия самых понятных и простых работ – например, можно в суете проекта забыть наладить коммуникацию с внешними ролями проекта/стейкхолдерами, или даже забыть провести испытания по проверке и приёмке (особенно часто забывают испытания по приёмке!) системы. Контрольные точки/milestones каждой альфы (формулируются как вопросы чеклиста, положительный ответ на которые означает достижение этой контрольной точки) требуют выбора практик для их достижения, а затем выполнения работ по их достижению.