Как работают с моделью графа создателей в форме чеклиста
Когда говорим о моделировании графа создателей, то имеем в виду прежде всего не диаграммное представление в разных «рисовалках» вроде MS Visio, Figma или даже yEd (мы готовили иллюстрации текущего раздела как раз с использованием «рисовалки для графов» yEd), не диаграммное представление в моделерах каких-то бизнес-процессов типа Business Studio или ArchiMate (они поддерживают строгую типизацию элементов диаграммы), а представление в разного сорта текстовых (аутлайны, но не представление аутлайна в виде MindMaps) и табличных моделерах. Современный операционный софт обычно ровно такой: он представляет богатые возможности редактирования длинных списков, представленных таблицами.
Конечно, можно использовать и более простые формы, например, список областей интереса или даже альф мелом на доске или даже назначить пальцы на руке отображающими три-четыре области интереса или альфы. Но обычно используются всё-таки более богатые среды моделирования, позволяющие представить множество чеклистов — и сделать это в привычной для работника среде.
Самое простое использование модели графа создателей — это структурирование отчёта о ходе проекта (progress report). Нужно просто дать краткую содержательную характеристику состояния избранных вами альф избранных вами областей интереса в графе создателей. Progress report нужен для того, чтобы вся команда (и в порядке надзора/governance — её создатели) коллективно представляли, в каком состоянии каждая альфа, какие есть инженерные проблемы и что с ними можно сделать, какие риски несоблюдения сроков и бюджета есть в проекте.
Модель графа создателей (повторим: необязательно в виде диаграммы! Это может быть, и даже не «может быть», а должен быть набор таблиц в универсальном/табличном моделере!) удерживает коллективную собранность в проекте, гарантирует основной посыл чеклистов: подумать о состоянии важных объектов внимания в проекте, с нужным разрешением в плане точности моделирования, не пропуская ни одной области интереса для системы в графе создателей, ни одной альфы в каждой области интереса, ни одной подальфы, ни одного их состояния, ни одного контрольного вопроса для составляющих этих состояний на много (сколько надо, столько и будет!) уровней. А потом переходим к планированию работ для достижения этих состояний и отслеживанию не только выполнения этих работ, но и фактического достижения этих состояний альф (ибо работы могут быть выполнены, а нужного состояния не будет).
Пропущенная в отчёте о ходе проекта альфа часто означает совсем не то, что её состояние плачевно и докладчик почему-то его хочет намеренно скрыть. Да, такое бывает, но редко. Обычно «миром правит не тайная ложа, а явная лажа», и причина пропуска в отчёте рассказа о состоянии какой-то альфы означает, что просто про эту альфу давно не думали, её состояние (включая её подальфы) давно не оценивалось, о необходимости осознанного и структурированного внимания к ней просто забыли за какими-то другими делами. И это означает, что самое время подумать, что с такой пропущенной альфой и её подальфами происходит. Progress**-report—** это прохождение чеклиста уровня зон интереса и альф**.**
При подготовке отчёта отследите пропуски описания состояния дел в проекте по каким-то альфам или подальфам и немедленно подумайте (чаще всего это означает не просто «подумать», а сначала получить дополнительную информацию, поговорить с самыми разными исполнителями ролей в команде, и внешними проектными ролями), что с ними происходит и какие дела нужно в связи с этим происходящим сделать. Как с любыми чеклистами**,** в 9 случаях из десяти всё оказывается в порядке, а в 1 случае это предотвращает неминуемую катастрофу всего проекта**.**
Иногда проблема оказывается даже в том, что непонятно, по каким рабочим продуктам можно узнать, что происходит с альфой, и какой исполнитель какой роли об этом может рассказать: вот это самое тревожное, что может быть, ибо е****сли не подумал, то не сделал. Е****сли не сделал, то система не будет успешна, разве только случайно.
Моделирование в универсальном моделере графа создателей даже только адаптированными основными альфами без перехода к подальфам полезно не только для того, чтобы потом делать регулярный отчёт о ходе проекта, но и для того, чтобы давать полезный содержательный отклик по таким отчётам**, замечая не то, что сказано, а то, о чём не сказано****.** Так, если в отчёте не сказано ни слова про организацию/коллектив/команду::альфа, то в качестве содержательного полезного отклика на progress report обязательно нужно задать вопросы про состояние команды (уточняя прямо по контрольным вопросам этих состояний). Может выясниться много важного неожиданного (ключевые члены команды надумали уходить, сотрудничества уже три дня как нет по разным причинам и т.д.). Эти вопросы по состояниям пропущенных в мышлении о проекте альф не будут случайными вопросами. Основные/kernel альфы ведь эти выбраны не случайно, а отражают опыт многочисленных разработок. Если вы используете чеклисты на основе альф, то вы уже многое знаете о проекте, даже если вы первый раз встречаетесь с проектом!
Задавать вопросы прежде всего по выпавшим из внимания коллектива альфам (то есть важным объектам внимания в проекте) — это и есть управление коллективным вниманием в проекте, гарантирование коллективной собранности. Для этого нужно:
- использовать компьютерную память для моделирования графа создателей в виде шаблонов чеклистов
- модель графа создателей (шаблоны чеклистов) должны быть адаптированы к предметной области
- кроме шаблонов чеклистов надо иметь описания методов (регламенты, инструкции, корпоративные стандарты) в виде, удобном для загрузки в головы сотрудникам и в операционный софт (а не в виде, который удобен для методологов)
- чеклисты и регламенты как «хелп» к чеклисту должны быть в операционном софте сотрудника (а не любимом моделере методолога)
- приоритет реального использования чеклистов перед «централизацией». Это вполне может быть распределённая модель, трудно централизуемая. Объединение всех чеклистов и взаимные сверки — это вопрос айтишников, а не вопрос приспособляемости работников, барьеры в использовании чеклистов на рабочих местах надо снижать.
- Работники должны быть обучены работе по регламентам с использованием чеклистов (и вы должны пройти первый раз чеклист с ними — заодно исправите ошибки и внесёте уточнения)
- Должен быть организован надзор (и при этом не стоит ожидать, что все сотрудники будут пользоваться чеклистами. Надо будет заняться лидерством, но вполне возможно, что надо будет показательно уволить тех людей, кто не в состоянии работать с чеклистами — они и другие важные дела тоже могут иногда делать, иногда не делать, надёжность их работы под вопросом.
Потом вы должны регулярно (раз в день, раз в неделю, но уж точно чаще раза в месяц!) проходиться по верхнеуровневым/основным альфам, удерживать внимание коллектива на всех этих альфах, а не только на тех подальфах и некоторых контрольных вопросах к их состояниям, которые у них прямо сейчас в срочной работе, о которых они и так помнят. Ибо пока срочно работаешь с одним — быстро забывается и сгорает совсем другое. В проектах нужно быть очень внимательными, причём коллективно внимательными.
Ещё один вариант использования системной схемы проекта**—** это понять, какиевиды мастерства****у команды есть, а какие отсутствуют. Распечатайте списки областей интереса графа создателей и списки альф с их состоянием и контрольными вопросами (адаптированные!) в этих зонах интереса и дайте участникам проекта отметить крестиком те альфы, за состояние которых каждый из них планирует в этом проекте отвечать, играя какие-то роли. Если какие-то альфы остались без своих крестиков**—** то проект ждут большие риски**, и это надо немедленно обсудить: кто в команде берётся отвечать за состояни****я** этих «бесхозных» альф?
Вместо «опроса» может быть сразу осознанное принятие ответственности за какие-то альфы (или подальфы) в проекте. Проект как целое разбивается на изменяющиеся по его ходу объекты, требующие особого внимания (альфы, и ориентир тут для начальной разбивки — основные/kernel альфы из основных/kernel областей интереса), и команда проекта принимает индивидуальные ответственности за эти объекты**—** и коллективную ответственность за согласование действий по их поводу.
Помощь методологии с её опорой на системный подход в том, что ни на один момент не теряется внимание к самым разным системам графа создателей, их описаниям, методам их работы (их функциям), их работам. Это моделируется чеклистами достижения состояний этих объектов коллективного внимания.При частном разбирательстве с одной «горящей» и «проблемной» альфой остальные альфы никуда не деваются, они отмоделированы, об их состоянияхв проекте помнится, к ним обязательно вернутся**, обязательно** проверят их состояние. Число неожиданностей в проектах при таком использовании чеклистов много, много меньше, чем в проектах без использования чеклистов на базе альф.