За чем следить в проекте

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

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

Предложенный OMG Essence способ моделирования альф как предметов инженерного процесса как раз предлагает формат чеклиста — сами альфы ведь введены как объекты неусыпного внимания в ходе проекта, а чеклисты будут отличной формой, которая упростит отслеживание состояний альф.

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

• Важные объекты внимания, которые меняются в ходе проекта — это альфы, не забываем их отслеживать. Отслеживанию подлежат изменения: смены состояний альф как предметов методов инженерного процесса.
• Надо убеждаться, что смены состояний действительно произошли. Для этого используем чеклисты в компьютере. «Ведём проект», даже если у нас в проекте проблемы, ровно как лётчики «летят самолёт» — используя чеклисты («летят самолёт» — это от чеклиста остановки двигателя в полёте, где первым пунктом указано «fly the airplane», ибо пилоты буквально забывали заниматься пилотированием, занимаясь расследованием ситуации с остановкой двигателя — и самолёт входил в штопор).
• Ключевым является даже не само записанное в чеклисте состояние альфы (но записывать надо, человеческой памяти не доверяем) — но подумали или не подумали вы о её состоянии. Ибо если подумали, то шанс что-то исправить есть, а если не подумали — «всё, что может пойти не так, обязательно пойдёт не так».

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

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

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

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

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

• «Совещание»::альфа
• «Помещение для совещания»::альфа — подальфа для «Совещания»::альфа (тип подальфы — тоже альфа!)
• «Тишина в комнате совещаний установлена»::«контрольный вопрос» альфы «Помещение для совещания»
• ««Тишина в комнате совещаний установлена» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей состояния альфы и ожидаемого времени достижения)
• «Внешний шум отсечён»::«контрольный вопрос» второго уровня для «тишина в комнате совещаний установлена»::«контрольный вопрос»
• ««Внешний шум отсечён» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей второго уровня контрольного вопроса к состоянию альфы и ожидаемого времени достижения)
• «Дверь закрыта»:: контрольный вопрос третьего уровня к состоянию альфы «помещение для совещания»
• «Окна закрыты»:: контрольный вопрос третьего уровня к состоянию альфы «помещение для совещания»
• «Мобильники участников переведены в режим «без звука»»::«контрольный вопрос к альфе «тишина в комнате установлена»
• «Закрытие двери»::работа проводится «секретарём совещания»::оргзвено методом «закрыть руками» (варианты: «ближайшим к двери участником совещания»::оргзвено, «проводится автодоводчиком», дополнительно работа установки автодоводчика на дверь проводится службой офис-менеджмента).
• Закрытие двери заносится в issue tracker и назначается на секретаря совещания (и дальше выполнение этой работы проверяется «как обычно» — эта работа и факт её выполнения не потеряется, она тоже оказывается записанной).

Конечно, это крошечная часть состояний очень сложного предмета метода с сигнатурой «проведение совещания», которое может быть оффлайн синхронным, онлайн синхронным, онлайн асинхронным^[2], смешанным, проходить на пару человек в режиме прогулок, как у перипатетиков^[3], включать или не включать в себя подготовку транскриптов, протоколов и т.д. Более того, это слишком детальный чеклист (хотя где-то это может быть большим подспорьем — вовремя проверить, включены ли кондиционеры, закрыты ли двери и окна, оповещены ли сотрудники, есть ли способ показать, что помещение занято и т.д.). Главное, что у вас есть какие-то более-менее общие объекты внимания разного уровня (основные альфы), у них есть подальфы, дальше есть несколько уровней контрольных вопросов. И самое главное — что теперь вы понимаете, что в какое состояние переводить, теперь можно выбрать вариант метода в разложении метода (закрыть дверь ногой самому, рукой самому, попросить кого-то проходящего мимо, закрыть дверь автодоводчиком, но распорядиться, чтобы он там был), и даже не забыть попросить выключить звук у телефонов (хотя сейчас это уже и редко нужно, звук и так обычно уже выключен — но лет пять назад это ещё было актуально).

Потом надо убедиться, что запланированные работы выполнены — и не забыть поставить отметку не о выполнении работы, а о достижении состояния предмета метода этой работы. Чеклисты**—** для контроля того, что работы привели к нужному состоянию предметов методов, а не просто для того, чтобы показать факт «работы выполнялись».

Агентность — это во многом внимательность, осознанность, это не «делал во сне, на автомате и забыл, делал ли — вроде закрыл дверь на ключ и выключил утюг». Сделал — посмотрел, что там получилось в результате. Или посмотрел — и сделал всё, что надо, а не всё что в суете вспомнил. Плюс сверка ожидаемых результатов работы и реального состояния предметов метода, это резко уменьшает число ошибок от работы над недоделанными результатами прошлой работы (скажем, грунтовал — но не загрунтовалось, поэтому красим без грунтовки, результат — «почему-то покрасилось ужасно»). Чеклист — хороший инструмент для агентности. Даже если заснул в ходе работы, чеклист даёт возможность проснуться — сверить сны с реальностью. Вот и рост агентности.

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

Беда в том, что вот этих многочисленных действий/работ для достижения нужных состояний, непрерывно сползающих к предыдущим состояниям «неготовности» (жизнь меняется, состояния объектов тоже меняются — по самым разным причинам), накапливается много. Это одна из причин, почему прикладные инженеры не любят такой issue tracker как Trello (имитируется работа с 200-300 стикерами с задачами, разложенными по столу в несколько групп, несколько тысяч стикеров уже неподъёмны для Trello), а также не любят и другие «канбан-доски на стикерах». «Менеджеры», наоборот, их обожают: «всё наглядно», каждая работа выглядит как «карточка работы на бумаге», и продвижение проекта хорошо показывается как «продвижение карточек», метафора рабочего стола с бумагами.

При этом менеджер справедливо считает, что 200-300 работ на контроле — это очень много. Но у инженеров даже в небольшой команде за несколько месяцев разработки легко набегает 2-3 тысячи issues (проблемных вопросов), которые нужно отслеживать и как-то коллективно закрывать. Программисты и инженеры с этим справляются, а вот менеджеры теряются. Как решить эту проблему «чеклистов для огромного количества работ»? Нужно понимать, кто такие «менеджеры» по их ролям и зачем им нужно знать все работы.

Обычно современные issue trackers позволяют делать иерархию issues, а операционным менеджерам показывать только верхнеуровневые кейсы, их не так много, и большинство issue trackers позволяют их красиво изобразить карточками на экране. Это, конечно, похоже на первые автомобили — их делали в форме кареты, и даже называли «самобеглые повозки».

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

Мир можно делить на части очень разными способами/методами описаний, а ещё с этими частями работать потом очень разными способами/методами, и некоторые из этих способов/методов работы подразумевают начальные условия, которых сейчас нет, но которые мы тоже как-то можем получить — тоже работами по каким-то методам, но это будут другие работы по другим методам. То, что вы работаете с альфами и кейсами по продвижению состояний этих альф и думаете о них одинаково в терминах мета-мета-модели**, никак не закрывает огромной сложности и многообразия мира. Думать можно одинаково о самых разных вещах, это немного экономит время. Но творчество никуда не девается!** И дальше всё равно думать вам надо не только в терминах мета-мета-модели, но и отслеживать, что означает это мышление в терминах мета-модели, в терминах модели и даже насколько оно адекватно**—** то есть насколько в итоге адекватна модель реалиям жизни, актуальной ситуации.

Все эти даты в контрольных точках — это только плановые даты, ожидания. Очень полезно оценивать время достижения этих состояний, а если время трудно оценивается — бить дальше альфу на подальфы, на контрольные вопросы, чтобы время прохождения контрольных точек можно было оценить. Понятно, что прохождение состояний вышестоящих альф плохо прогнозируется во времени, а вот с подальфами и контрольными вопросами это проще. Нельзя сказать, в каком состоянии наши подрядчики, можно сказать — в каком состоянии каждый подрядчик. При дроблении появляется больше объектов внимания, по которым можно точнее что-то сказать: но внимание может быть рассеяно по такому большому количеству объектов. Поэтому:

• Всё записываем. Работаем с большими моделями, на мозг и устные договорённости не рассчитываем.
• Распределяем объекты внимания по многим людям (но не слишком многим, ибо чем больше людей, тем больше будет времени уходить на согласования и на потенциальные нестыковки результатов работ, конфигурационные коллизии. Помним закон Амдаля!).

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

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

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

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

1. Область интересов системы-создателя целевой (а есть ещё в графе создателей и создатели других систем, например, клиентуры),

1.1. Альфа «команда» (ещё есть альфы описания команды, метода работы команды, работы команды, но вполне могут быть и другие альфы)

1.1.3. Состояние альфы «Сотрудничает» (это третье состояние в ряду «намечена, сформирована, сотрудничает, производит, распущена», поэтому сразу 1.1.3),

1.1.3.2. Контрольный вопрос про «общение в команде открытое и честное» (он второй в списке).

Достижение этой контрольной точки 1.1.3 требует задействования лидерства::метод. Достижение этого состояния из контрольного вопроса 1.1.3.2. требует подумать о способах получить честное и открытое общение — и это приводит к мысли о какой-то составляющей лидерства, надо будет выбрать конкретный вариант достижения этого состояния через какие-то работы по какому-то методу (желательно из учебника прикладной дисциплины, а не сочинённой самостоятельно — если только вы не мировой эксперт по лидерству). Думать нужно так: «знания/объяснения из какого учебника лидерства будем применять для достижения этой контрольной точки?». Контрольная точка тут важна, ибо дорога ложка к обеду, вам же нужно не «когда-нибудь», а вовремя, чтобы проект был успешен. «Инструменты какого поставщика будем применять для поддержки лидерства?», ибо в 21 веке даже лидерство::метод поддерживается инструментально!

Затем нужно будет провести работы (понять, кто и когда будет проводить эти работы по выбранному варианту метода лидерства — запланировать работы, а потом выделить время и другие ресурсы, и провести эти работы — выполнение работ) для выбранной практики лидерства. И так с каждой контрольной точкой, по каждому вопросу чеклиста. И это мы ещё проигнорировали то, что там могут быть и подальфы, и сами контрольные вопросы могут быть многоуровневы.

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

• Помним, что так и должно быть. Человеческая деятельность сложна. Просто нужно думать о каждом деле по отдельности, а не обо всём сразу. Обо всём сразу невозможно. Но вопросов и впрямь много, даже в маленьких проектах. Хороший пример тут в авиации: не все чеклисты применяются часто, некоторые чеклисты — редко, в аварийных ситуациях. Но лучше бы их в этот момент иметь, чтобы поддерживать общую безаварийность.
• Записываем. Особенно записываем самое главное (принцип чеклиста: не пишем всех мелочей и нюансов учебника, но пишем самое главное, что неплохо бы проверить — ибо без этого проект провалится). И не забываем проверять записанное, возвращаться к нему снова и снова. Мозгу не верим (хотя спецы могут хорошо помнить все эти нюансы из учебников разных практик, их необязательно писать — но вот что требует хоть какого-то коллективного действия или существенно может повлиять на успех, то непременно пишем. Помним книжку Atul Gawande).
• В команде довольно много агентов (чаще всего — людей), все они имеют какие-то чеклисты для используемых ими методов. Совсем необязательно одному человеку и разрабатывать эти чеклисты, и работать с ними. Нет, огромное количество этих вопросов делится по людям. Другое дело, что записанные (чаще всего в issue trackers или даже в универсальных моделерах, которые потом связываются с issue trackers для управления получившимися работами) чеклисты довольно легко потом обсуждать при делёжке работ проекта между его исполнителями. Поэтому не забываем писать и практики, и роли, и исполнителей этих ролей.

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

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

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

Нет слов предметной области**—** не адаптировано! А без адаптации к конкретн****ым предметн****ым област****ям проекта и уровню опыта конкретной команды чеклисты (области интересов, альфы и подальфы, их состояния, контрольные вопросы многих уровней) «прямо из руководстве по методологии» и уж тем более «прямо из стандарта OMGEssence» использовать нельзя!Тексты из руководства тут дают только типы мета-мета-модели, они нужны как средства методолога для наведения внимания прикладной команды на важные объекты в их предметной области**!**

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

В разговоре про альфы необязательно каждый раз произносить слово «альфа». Как не говорят «система самолёт», «система чайник» (но добавляют слово «система», когда хотят подчеркнуть рассмотрение как системы), так в проекте не говорят «альфа работа» и «альфа команда», но говорят «работа» и «команда». Слово «альфа» добавляют, только когда хотят подчеркнуть именно работу с альфой как типом мета-мета-модели, если ваш собеседник понимает этот «птичий язык», проходил руководство по методологии. Этим собеседником можете быть и вы сами, скажем, при мышлении моделированием — полезно явно указывать типы. Номашинка типов у вас должна в мозгу работать «беззвучно» и при разговорах с другими людьми в терминах мета-модели**: вы должны отслеживать** в своей и чужой речи упоминание альф и подальф**. П****омним, что при адаптации они будут звучать вслух** для собеседников как всем понятные объекты метаС-модели или метаУ-модели. Мета-мета-модель будет вами «приговариваться в уме» как типы к понятиям мета-модели при проектировании чеклистов.

Ещё раз повторим то же самое, только чуть более многословно. Мы предлагаем считать, что вообще все рабочие проекты — это проекты по изменению мира (инженерные), поэтому думать о всех этих проектах надо по-инженерному (те же типы мета-мета-модели, что и в наших руководствах инженерной серии), но использовать приемлемую для целевых предметных областей терминологию в именовании многочисленных альф и подальф (типы мета-модели: или «как в учебнике», или даже «как на предприятии, в ситуации»). Мышление в терминах мета-мета-модели нужно вам самому для того, чтобы в слабо знакомых вам ситуациях иметь хоть какое-то знание о важных объектах этой ситуации. Это абстрактное знание, его немного, но это уже хороший чеклист: про каждую систему вы сходу должны подумать про её воплощение, про системное описание, про метод работы и работу (не про описание метода работы и описание работы, а про них самих — про поведение системы в мире! Это само поведение системы, а не описание этого поведения!). И думать о графе создателей и тем самым о зонах интереса — к вашей системе, к создателю вашей системы, к целевой системе, к клиентуре, инвестуре и так далее. Думайте одинаково (отмечайте типы мета-мета-модели задействованных в самых разных проектах объектов, находите объекты пропущенных в мышлении и действии типов объектов — но только «в голове» и ваших собственных моделерах, не произносите терминов мета-мета-модели и не пишите их в операционном софте сотрудников). В общении с сотрудниками и в операционном софте сотрудников не говорите и не пишите типов мета-мета-модели, заменяйте их типами метаС-модели или метаУ-модели. Если у вас в голове «целевая система» как альфа, которую вы отслеживаете, в речи не говорите ни слова «альфа», ни слова «целевая система», а говорите тип системы, взятый в предметной области: самолёт, мастерство, игровой сеанс. Но вы обязаны делать это осознанно: если произнесли «самолёт», то должны понимать, что это целевая система, имеется в виду воплощение системы, оно проходит самые разные состояния по ходу проекта, но главное из них — это во время использования, то есть состояние, когда самолёт летит, а ещё этот самолёт — физический объект, он описан в его разделении функциональные, конструктивные, пространственные, стоимостные части, и ещё он является предметом какого-то инженерного метода разработки. Сотрудникам необязательно знать, как вы думаете, но им обязательно надо знать результаты вашего мышления. Вот эти результаты и говорите на языке мета-модели, не произносите слов мета-мета-модели.

Конечно, если сотрудники владеют мышлением и работой по нашим руководствам, разговор с ними пойдёт много быстрее и легче (мышление в терминах мета-мета-модели универсальней и компактней), но если они не освоили работу по нашим руководствам, разговор с задействованием терминов мета-мета-модели пойдёт в разы медленней, вас будут не понимать и считать странным: слишком большое понятийное расстояние^[4]. Умным, а не странным, вас будут считать за высказывание результатов мышления на языке мета-модели, то есть принятом в предметных областях вашего проекта языке (метаУ-модель) или даже принятом на вашем предприятии языке (метаС-модель). А типизацию этой модели типами из руководств по рациональной работе, системному мышлению, методологии, системной инженерии, инженерии личности, системному менеджменту — оставьте при себе.

Заметим, что для инженерии есть множество предметных областей, и язык разговора о каждой из них будет разным — причём даже слово «инженер» может не применяться. Например, инженеров личности мало кто называет инженерами, инженеров сообществ мало кто называет инженерами. Инженеров предприятия мало кто называют инженерами предприятия, чаще их называют менеджерами.

Менеджмент как инженерия предприятия всё-таки более-менее одинаков в этом плане, хотя и там огромная разница в понятиях и терминологии той или иной школы менеджмента. Хотя многим сотрудникам будут знакомы типы объектов из нашего руководства по системному менеджменту, будьте внимательны: они могут эти типы определять совсем не так, как определяете их вы на основе материалов наших руководств. «Операционный менеджмент» примерно один и тот же в инженерии, медицине, торговле, образовании. Но ваши сотрудники могут даже не знать, что они занимаются управлением кейсами, хотя полдня будут проводить с issue tracker. Поэтому каждый раз уточняйте язык, на котором идёт разговор с сотрудниками: правильно будет говорить на языке метаС-модели, а если вы хотите поменять эту модель — обсуждайте это на языке метаУ-модели. Мета-мета-модель из наших руководств держите только у себя в голове (усиленной вашим личным экзокортексом) и говорите на этом «птичьем языке» только с сотрудниками и коллегами, которые этот язык мета-мета-модели уже хорошо понимают. Помним о метанойе: то, что для вас кажется естественным, вы когда выучили и у вас даже когда-то были трудности в обучении. У других людей так же, плюс недоверие ко всему новому. Вот и не говорите им новых для них слов типов объектов, чтобы не вызывать недоверие. Но произносите эти слова у себя в уме и в своих собственных моделях: у вас будет меньше ошибок. Внимание будет на важном, рассуждения будут о важном, а не о чём-нибудь. И ещё вы поможете чеклистами удержать внимание на важном вашим коллегам.

---

1. https://www.litres.ru/atul-gavande/chek-list-kak-izbezhat-glupyh-oshibok-veduschih-k-fatalnym-posledstviyam/ ↩︎

2. https://ailev.livejournal.com/1511183.html ↩︎

3. https://ru.wikipedia.org/wiki/Перипатетики ↩︎

4. https://lesswrong.ru/w/Ожидая_короткие_понятийные_расстояния ↩︎