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

• Распущена (adjourned): обязанности были выполнены; члены команды доступны для участия в других командах; миссия завершена.

В оригинальном стандарте речь идёт об альфе way of working (способ проведения работ), и авторы стандарта не случайно ушли от того, чтобы назвать альфу «практики». В практиках дисциплина грузится в головы исполнителей работ, её нужно искать в компетенциях команды, в человеческом капитале. И сама практика называется по имени своей дисциплины – и нужно постоянно про это помнить. Ещё есть большой соблазн различать начальное состояние «практики где-то там» (то, что обычно делают люди) и конечное состояние «доступной для использования в работах практики тут у нас». Для этого случая есть термин оргвозможности (capability, поставленная практика – то есть имеющиеся в команде обученные дисциплине люди и развёрнутые инструменты, на которых эти люди умеют работать).

Поэтому мы приняли решение для way of working говорить о том, что осталось от практики и разворачивается на самом предприятии – о технологии, но рекомендуем при этом не забывать о практике в целом, и это отражено в формулировках состояний альфы/контрольных точек. Конечно, говорить сразу о всех практиках и всех их технологиях не получится – поэтому лучше всего будет отслеживать в проекте связанные с технологиями подальфы отдельных практик/способов работы/технологий, а то и дробить их дальше на подальфы инструментов и отдельных рабочих продуктов.

Вот состояния/контрольные точки основной альфы «технологии»:

• Дисциплина установлена (principles established): команда активно поддерживает дисциплину/теорию/принципы; стейкхолдеры согласны с принципами; потребные для их поддержки инструменты согласованы; рекомендации по выбранному подходу доступны; рабочий контекст понимается; ограничения практики и выбранных в её составе инструментов известны.

• Основа положена (foundation established): ключевые практики и их инструменты выбраны; практики, необходимые для того, чтобы начать работу, согласованы; практики, по которым не будет обсуждений и их инструменты выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; способ работы, в котором все практики удобно использовать, определён.

• Используется (in use): практики и их инструменты используются; использование практик и их инструментов регулярно проверяется; практики и их инструменты адаптированы к контексту; практики и их инструменты поддерживаются командой; механизмы получения откликов/feedback на практики и их инструменты работают; практики и их инструменты поддерживают общение команды и сотрудничество.

• Наличествует (in place): практики и их инструменты используются всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well): делается предсказуемый прогресс; практики применяются естественным образом; инструменты естественным образом поддерживают принятую дисциплину работы; идёт постоянное совершенствование/подстройки.

• Вышла из употребления (retired): больше не используется; уроки использования практики опубликованы для использования в будущем.

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

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

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

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

Формулировки контрольных точек в Essence намеренно «мутные», неопределённые и расплывчатые. Авторы стандарта говорят, что это поощряет команду провести обсуждение этих контрольных точек, чтобы адаптировать формулировки к индивидуальным особенностям проекта, и получить явное соглашение команды о том, что все члены команды одинаково понимают эти контрольные точки.

Всего семи объектов внимания в проекте не будет хватать – тем более в больших проектах. Поэтому команде необходимо уделять внимание не только альфам, но и подальфам, на что мы обратили внимание, когда описывали основные альфы.

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

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

Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на состояние связанных с ними рабочих продуктов. С альфами происходит мышление, с рабочими продуктами происходит работа. Конечно, для описания (view, набор моделей) состояния альфы в рабочем продукте должен быть использован какой-то метод описания (viewpoint, метамодель и принципы создания модели, методические указания по моделированию предметной области интереса/concern). Поэтому в реальной обстановке обсуждение ведётся не только альф, но и рабочих продуктов.