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

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

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

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

Даже только основные альфы адаптированной и отмоделированной в универсальном моделере системной схемы проекта (без перехода к подальфам) полезны не только для того, чтобы делать регулярный отчёт о ходе проекта (progress report, нужен для того, чтобы вся команда и в порядке надзора/governance её создатели коллективно представляли, в каком состоянии каждая альфа и что нужно делать дальше, какие риски есть в проекте), но и для того, чтобы давать полезный содержательный отклик по таким отчётам, просто замечая не то, что сказано, а то, о чём не сказано. Так, если в отчёте не сказано ни слова про организацию/коллектив/команду, то в качестве содержательного полезного отклика на progress report обязательно нужно задать вопросы --- в каком состоянии команда. Может выясниться много важного неожиданного (ключевые члены команды надумали уходить, сотрудничества уже три дня как нет по разным причинам и т.д.). Эти вопросы по пропущенным в мышлении о проекте альфам не будут случайными вопросами, альфы ведь эти выбраны не случайно, а отражают опыт многочисленных разработок, обобщённый авторами стандарта описания метода работы с использованием областей интересов, альф и их состояний, отражаемых в самых разных рабочих продуктах.

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

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

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

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