Анатолий Левенчук

Руководство по методологии для инженеров-менеджеров

Введение

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

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

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

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

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

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

В ходе прохождения даётся литература. Не забывайте смотреть материалы по ссылкам на литературу, там много интересного. Особенно рекомендуется чтение книг, обложки которых приведены в руководстве.

Задания по моделированию и мышлению письмом обязательны, без выполнения этих заданий освоение методологической работы по нашему руководству будет похоже на чтение учебника езды на велосипеде без попыток проехать хотя бы 100 метров. Только чтением текста мастерство методолога не получишь. Больше замечаний о том, как устроено руководство в части методики обучения (облегчение освоения мастерства методолога с использованием наставлений нашего руководства) и как учиться, можно найти в руководствах по рациональной работе и в первом разделе руководства по системному мышлению, а ещё больше объяснений будет в руководстве по инженерии личности.

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

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

Наставления нашего руководства впервые появились как часть учебника «Системноинженерное мышление» в 2013 году, текущий текст — это итог девятой переписки летом 2024 года. Но в ноябре 2024 уже начата десятая переписка, вы работаете с самым последним вариантом текста, а в мае 2025 года были заменены «курс» на «руководство», «студент» на «инженер-менеджер», Школа системного менеджмента (ШСМ) на мастерскую инженеров-менеджеров (МИМ).

Автор выражает благодарность студентам и преподавателям кафедры технологического предпринимательства МФТИ, где велось начальное преподавание методологии и был получен первый опыт обучения этой фундаментальной дисциплине, членам Русского отделения INCOSE, с которыми велись многочасовые обсуждения содержания руководства, сообществу мастерской инженеров-менеджеров (ранее Школы системного менеджмента), где велась доработка руководства в последние несколько лет. Десятки замечаний было представлено читателями блога автора (http://ailev.livejournal.com, трансляции блога есть в телеграме, мордокниге, вконтакте, фрифиде), учтены замечания десятков бета-тестеров. Особая благодарность Роману Варьянко, который оперативно выполнял корректуру текста, не ограничиваясь грамматикой и орфографией, но и делая содержательные замечания.

Ваши замечания и предложения по поводу следующих версий давайте или в форме сбора замечаний прямо на страницах руководства (https://aisystant.system-school.ru/lk/#/course/methodology/), или в чат поддержки, он организован в телеграме и общий для всех руководств программы рабочего развития инженеров-менеджеров: https://t.me/systemsthinking_course

Оглавление

[Введение 1](#введение)

[1. Методология как фундаментальный метод мышления 7](#методология-как-фундаментальный-метод-мышления)

[О чём будет, и о чём не будет рассказано в руководстве по методологии 7](#о-чём-будет-и-о-чём-не-будет-рассказано-в-руководстве-по-методологии)

[Моделирование: онтика методологии из руководства по системному мышлению 11](#моделирование-онтика-методологии-из-руководства-по-системному-мышлению)

[Фундаментальная и прикладная методология 11](#фундаментальная-и-прикладная-методология)

[Понятие метода 19](#понятие-метода)

[Зачем изучать методологию 23](#зачем-изучать-методологию)

[Методология в интеллект-стеке 26](#методология-в-интеллект-стеке)

[Моделирование: выбор метода 37](#моделирование-выбор-метода)

[Метафора разложения метода в стек. Спектр мастерства по стеку методов как спектральной шкале. 38](#метафора-разложения-метода-в-стек.-спектр-мастерства-по-стеку-методов-как-спектральной-шкале.)

[Моделирование: разложение культурного движения в стек 48](#моделирование-разложение-культурного-движения-в-стек)

[Представление разложения метода деревом 49](#представление-разложения-метода-деревом)

[«Схемотехника»: представление метода работы графом потоков. 55](#схемотехника-представление-метода-работы-графом-потоков.)

[Виды физического системного моделирования: функциональные диаграммы есть, но вместо них может быть компьютерный код 59](#виды-физического-системного-моделирования-функциональные-диаграммы-есть-но-вместо-них-может-быть-компьютерный-код)

[Задания: принципиальные схемы 66](#задания-принципиальные-схемы)

[Пример: методы создания систем AI 66](#пример-методы-создания-систем-ai)

[Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах 74](#представление-метода-работы-как-алгоритма-методология-как-алгоритмика-на-стероидах)

[Задание: разложение метода вашей работы 84](#задание-разложение-метода-вашей-работы)

[2. Создание и развитие: не жизненный, не цикл 84](#создание-и-развитие-не-жизненный-не-цикл)

[Биологический жизненный цикл, нулевая версия 84](#биологический-жизненный-цикл-нулевая-версия)

[Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы 86](#жизненный-цикл-системы-1.0-работы-меняющие-состояния-целевой-системы)

[Операционный менеджмент и методология. 91](#операционный-менеджмент-и-методология.)

[Жизненный цикл 1.0 — это работы создателей над создаваемой системой 97](#жизненный-цикл-1.0-это-работы-создателей-над-создаваемой-системой)

[Моделирование: предметы кейса, их состояния, практики достижения состояний 103](#моделирование-предметы-кейса-их-состояния-практики-достижения-состояний)

[Управление последовательностью работ 104](#управление-последовательностью-работ)

[Жизненный цикл проекта 116](#жизненный-цикл-проекта)

[TEST Жизненный цикл 1.0 121](#test-жизненный-цикл-1.0)

[Проблемы с жизненным циклом 1.0 125](#проблемы-с-жизненным-циклом-1.0)

[Провал водопадной модели жизненного цикла 138](#провал-водопадной-модели-жизненного-цикла)

[Жизненный цикл 2.0: от стадий работ к методам разработки 145](#жизненный-цикл-2.0-от-стадий-работ-к-методам-разработки)

[Время эксплуатации: пример человека 151](#время-эксплуатации-пример-человека)

[Граф создателей 158](#граф-создателей)

[«Времена» рассмотрения системы 164](#времена-рассмотрения-системы)

[Моделирование: время операционное, создания, методологическое 167](#моделирование-время-операционное-создания-методологическое)

[Задания: процесс инженерии и методологическое время 168](#задания-процесс-инженерии-и-методологическое-время)

[3. Инженерные процессы (методы разработки) 168](#инженерные-процессы-методы-разработки)

[V-диаграмма 168](#v-диаграмма)

[Элегантность/lean за счёт повышения точности моделирования и изготовления 174](#элегантностьlean-за-счёт-повышения-точности-моделирования-и-изготовления)

[Выбор инженерного процесса и организация разработки 182](#выбор-инженерного-процесса-и-организация-разработки)

[Разнообразие методов управления работами 192](#разнообразие-методов-управления-работами)

[Гибкие процессы разработки и управление кейсами 195](#гибкие-процессы-разработки-и-управление-кейсами)

[JTBD: клиентоориентированность? Нет, метод-ориентированность! 207](#jtbd-клиентоориентированность-нет-метод-ориентированность)

[Пример методологии маркетинга: customer eXperience management. 212](#пример-методологии-маркетинга-customer-experience-management.)

[Клиентоориентированность и управление впечатлениями 224](#клиентоориентированность-и-управление-впечатлениями)

[Корпоративные экзокортексы для управления впечатлениями: CRM, CXP, DXP, LXP. 235](#корпоративные-экзокортексы-для-управления-впечатлениями-crm-cxp-dxp-lxp.)

[TEST Метод разработки 241](#test-метод-разработки)

[Метод разработки ничего не скажет об оргзвеньях 243](#метод-разработки-ничего-не-скажет-об-оргзвеньях)

[Проект: это всё, что угодно 246](#проект-это-всё-что-угодно)

[Моделирование: управление инженерным процессом против управления работами 248](#моделирование-управление-инженерным-процессом-против-управления-работами)

[4. Метод как объект первого класса 248](#метод-как-объект-первого-класса)

[Понятие метода: повторение 248](#понятие-метода-повторение)

[TEST Методы 260](#test-методы)

[Знания метода и как их описывать. 264](#знания-метода-и-как-их-описывать.)

[TEST Дисциплины в основании методов работы 276](#test-дисциплины-в-основании-методов-работы)

[Инструменты метода как поддержка его дисциплины 278](#инструменты-метода-как-поддержка-его-дисциплины)

[TEST Инструментарий 280](#test-инструментарий)

[Совершенствование и развитие 283](#совершенствование-и-развитие)

[Где искать описания современных методов менеджмента и инженерии 290](#где-искать-описания-современных-методов-менеджмента-и-инженерии)

[Стандарты классической системной инженерии 297](#стандарты-классической-системной-инженерии)

[Закат тяжеловесных методологий 302](#закат-тяжеловесных-методологий)

[Моделирование: методология разработки 306](#моделирование-методология-разработки)

[Онтологические нюансы в основе рациональности при стратегировании 307](#онтологические-нюансы-в-основе-рациональности-при-стратегировании)

[Безмасштабность методологии 313](#безмасштабность-методологии)

[Метод как объект первого класса 319](#метод-как-объект-первого-класса-1)

[Вариативность культур 323](#вариативность-культур)

[TEST Онтология метода 328](#test-онтология-метода)

[Моделирование: методы вашей работы 329](#моделирование-методы-вашей-работы)

[Задание 330](#задание)

[Эволюция методов 331](#эволюция-методов)

[Системные уровни целевой системы и стратегирование 340](#системные-уровни-целевой-системы-и-стратегирование)

[Моделирование: практики для различных системных уровней 344](#моделирование-практики-для-различных-системных-уровней)

[Задание 345](#задание-1)

[5. Коллективная собранность в отслеживании выполнения работ 345](#коллективная-собранность-в-отслеживании-выполнения-работ)

[Диаграмма системного описания графов создателей 345](#диаграмма-системного-описания-графов-создателей)

[Всегда используйте текст (аутлайн) и таблицу вместо диаграмм 353](#всегда-используйте-текст-аутлайн-и-таблицу-вместо-диаграмм)

[Задания: чеклисты 359](#задания-чеклисты)

[Области интересов надсистем, целевой системы, создателя 360](#области-интересов-надсистем-целевой-системы-создателя)

[TEST Область интересов, основные альфы 368](#test-область-интересов-основные-альфы)

[Альфы — общий объект отслеживания для организации 375](#альфы-общий-объект-отслеживания-для-организации)

[TEST Роли и их ведущие альфы 381](#test-роли-и-их-ведущие-альфы)

[Альфа коммерческой возможности ведения проекта 382](#альфа-коммерческой-возможности-ведения-проекта)

[Альфа внешних проектных ролей 389](#альфа-внешних-проектных-ролей)

[Альфа системы 391](#альфа-системы)

[Альфа описания системы 395](#альфа-описания-системы)

[Альфа метода/способа/культуры работы 399](#альфа-методаспособакультуры-работы)

[Альфа работы (works/operations/эксплуатации/использования) целевой системы 401](#альфа-работы-worksoperationsэксплуатациииспользования-целевой-системы)

[Пример: альфа «культура» для сообществ 404](#пример-альфа-культура-для-сообществ)

[За чем следить в проекте 414](#за-чем-следить-в-проекте)

[Моделирование: распределение времени на целевую систему, надсистемы, создателя 423](#моделирование-распределение-времени-на-целевую-систему-надсистемы-создателя)

[Состояния альфы и артефакты/рабочие продукты 424](#состояния-альфы-и-артефактырабочие-продукты)

[Как работают с моделью графа создателей в форме чеклиста 427](#как-работают-с-моделью-графа-создателей-в-форме-чеклиста)

[Подальфы 430](#подальфы)

[Моделирование: адаптация модели графа создателей 434](#моделирование-адаптация-модели-графа-создателей)

[TEST Адаптация модели графа создателей 435](#test-адаптация-модели-графа-создателей)

[6. Теория стратегирования 438](#теория-стратегирования)

[Понятие стратегирования 438](#понятие-стратегирования)

[Будущее уже здесь 443](#будущее-уже-здесь)

[Подрыв подо всей цивилизацией сразу: экспоненциальные технологии и конвергенция 447](#подрыв-подо-всей-цивилизацией-сразу-экспоненциальные-технологии-и-конвергенция)

[Пример подрыва: электромобили уже сейчас дешевле бензиновых автомобилей и их продаётся больше 456](#пример-подрыва-электромобили-уже-сейчас-дешевле-бензиновых-автомобилей-и-их-продаётся-больше)

[Задания 461](#задания)

[Роботы заберут работу? Нет! Но работу/job/занятость надо будет менять часто. 462](#роботы-заберут-работу-нет-но-работуjobзанятость-надо-будет-менять-часто.)

[Инновации: всегда сбоку 472](#инновации-всегда-сбоку)

[TEST Скорость обучения нейросети 483](#test-скорость-обучения-нейросети)

[Моделирование: всё новое приходит сбоку 483](#моделирование-всё-новое-приходит-сбоку)

[Архистратегии ежа и лисы 485](#архистратегии-ежа-и-лисы)

[Моделирование: икигай по методу Коллинза 488](#моделирование-икигай-по-методу-коллинза)

[Задания 489](#задания-1)

[Мечту вполне можно иметь. На мечте просто нельзя застревать. 489](#мечту-вполне-можно-иметь.-на-мечте-просто-нельзя-застревать.)

[Не шагай в туман, не надейся на «авось»! 497](#не-шагай-в-туман-не-надейся-на-авось)

[В конкуренции побеждает самый быстроменяющийся 502](#в-конкуренции-побеждает-самый-быстроменяющийся)

[Моделирование: варианты мечты 508](#моделирование-варианты-мечты)

[Бесконечное развитие (open-endedness) 509](#бесконечное-развитие-open-endedness)

[TEST бесконечного развития 519](#test-бесконечного-развития)

[Моделирование: версионирование стратегии 519](#моделирование-версионирование-стратегии)

[Моделирование: использование личной или корпоративной стратегии как фильтра 520](#моделирование-использование-личной-или-корпоративной-стратегии-как-фильтра)

[Задания 520](#задания-2)

[Теории счастья и богатства 521](#теории-счастья-и-богатства)

[Моделирование: личные стратегии 528](#моделирование-личные-стратегии)

[Задания 529](#задания-3)

[Что дальше 530](#что-дальше)

1. Методология как фундаментальный метод мышления

О чём будет, и о чём не будет рассказано в руководстве по методологии

В системном мышлении мы встретили немало синонимов к понятию метода работы в его отличии от работы по методу:

• Метод, способ, паттерн, шаблон работы (way of working) — тут обычно обязательно добавляют «работу», говоря о паттернированности/шаблонности работы.

• Практика, рабочий процесс, культура, стиль, технология, стратегия. Тут не всегда добавляют слово «работа» (хотя в «рабочем процессе» эта работа уже помянута), поэтому возможна путаница работы по методу и метода работы — для исключения этой путаницы можно добавлять «работу», например, «практика работы».

• Иногда с добавлением слова «вид» — вид инженерии, вид труда, вид деятельности, чтобы указать существование множества специализаций метода. Впрочем, имя типа для специализации необязательно, поэтому термины инженерия, труд, деятельность — это тоже метод.

• Иногда с указанием на свойство предмета метода, например, не собственный предмет метода — сервис,

• Функция — если создатель не слишком интеллектуальный и не слишком живой, хотя иногда говорят про функции и людей, и даже оргзвеньев со множеством людей и систем AI.

Метод работы и работа по методу — это виды/специализации поведения/изменения, заключающееся в том, что создатели в момент своей работы/эксплуатации меняют какие-то предметы в своём системном окружении.

Метод — аспект поведения, указывающий на способ/паттерн/шаблон работы создателя по переводу предмета метода через какие-то его состояния, указанные в знаниях/алгоритмах метода.

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

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

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

Сначала для перевода каких-то предметов метода из текущего состояния в ожидаемое конечное надо

• выбрать метод работы (метод выбора метода — стратегирование),

• затем планировать ресурсы (планирование::метод),

• затем задействовать ресурсы для работы.

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

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

Создатели — это агенты, всё что из методов умеет делать агент (совокупность мастерства агента) — это личность агента.

Методы/функции как изменения обычно моделируются n-арными/местными отношениями, эти отношения обычно представляются в знаках как отглагольные существительные. Агенты имеют роли в методе. Метод — это сам паттерн изменений в мире (паттерн в актуальной работе), а не описание этих изменений. Описание метода — это описание шаблона/паттерна/способа работ по методу, а не описание описания. Метод существует в мире, пока агент исполняет роль, выполняя работу по методу с экземплярами предметов метода.

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

Методы могут быть

• как очень частные (настройка::метод рояля::«предмет метода» «настройщиком рояля» — и пусть с толку не сбивает очень общее понятие «настройка», конкретный вид/специализация метода определяется обычно по его сигнатуре/signature как заданным предметам метода и ролям какой-то предметной области, в данном случае вид/специализация настройки определяется роялем как предметом метода и мастерством настройщика рояля, которое несёт личность агента в роли настройщика роялей, если сигнатура другая, то и вид метода/способа работы будет совсем другой: настройка синхрофазотрона физиком-экспериментатором абсолютно другая),

• так и очень общими, уровня мета-мета-модели например, настройка::метод чего-то::«предмет метода» настройщиком::роль, где сигнатура метода/функции крайне абстрактна и не очень понятно, о какой конкретно предметной области идёт речь.

Пример сигнатуры метода для трёхместного отношения с двумя ролями: передача::метод чего-то::«предмет метода» дающим::роль принимающим::роль. Можно специализировать метод передачи до покупка::передача::метод чего-то::«предмет метода» покупателем::принимающим::роль у продавца::дающего::роль.

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

Представление графа состояний для целей контроля этих состояний в виде списка контрольных вопросов о достижении этих состояний в ходе проекта называют чеклистом альфы. Так для альфы подарка::«предмет дарения::метод» можно определить следующие состояния:

• Необходимость подарка признана (подарок::«предмет метода» перешёл в состояние «необходим» после применения к нему признания::метод).

• Подарок выбран (подарок::«предмет метода» перешёл в состояние «известен» после применения к нему выбора::метод).

• Подарок приобретён (подарок::«предмет метода» перешёл в состояние «в собственности» дарителя::роль после применения к нему приобретение::метод).

• Подарок подарен (подарок::предмет метода перешёл в состояние «в собственности» «одариваемого лица»/«получателя подарка»::роль после применения метода «передача в дар»::передача — это специализация передачи::метод).

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

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

Наше руководство посвящено этому «учению о методе», в дополнение к тому, что вы уже знаете из руководства по системному мышлению, мы дополнительно:

• Узнаем, как развивалось знание о методах разработки (которые тоже известны под самыми разными названиями: инженерный процесс, процессы жизненного цикла системы, методы создания и развития системы, методология разработки). Это иногда называют «системноинженерный менеджмент» (SEM, systems engineering management), поскольку непосредственно связывают с организацией инженерной работы коллектива инженеров. Больше материала будет в руководстве по системной инженерии, но надо разобраться, как вообще думать о том, что работы инженеров в самых разных проектах по созданию и развитию самых разных систем проходят не абы как, а в соответствии с каким-то шаблоном/способом/паттерном, то есть по какому-то методу. С одной стороны, в каждом проекте метод работы уникален, с другой стороны, все эти методы разработки имеют общие черты и надо как-то уметь об этом разговаривать, а также проектировать методы инженерной работы.

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

• В самых общих чертах рассмотрим, как проводить стратегирование — выбирать новый метод работы в условиях, когда вообще непонятно, что делать. А если непонятно, что именно делать, то и планировать ещё ничего нельзя (потребные ресурсы неизвестны, ведь непонятно, каким методом работаем) и работать нельзя, ибо нельзя что-то делать, не понимая, что (ну, разве что делать случайные действия со случайными предметами, «конвульсии»).

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

Моделирование: онтика методологии из руководства по системному мышлению

Выпишите по памяти в первой колонке таблицы понятия типов объектов из онтики методологии (метод, предмет метода и т.д.), которую вы узнали из руководства по системному мышлению и которая изложена в первом подразделе руководства по методологии. Затем уже не по памяти, а сверяясь с текстом первого подраздела, во второй колонке таблицы выпишите понятия типов объектов онтики методологии, но уже не все, а которые вы забыли указать в первой колонке. В третьей колонке укажите процент того, что у вас удержалось в памяти (игнорируйте при подсчёте лишние понятия не из методологии, которые попали в первую колонку таблицы, поделите число понятий в первой колонке на сумму числа понятий в первой и второй колонок и умножьте на сто).

Фундаментальная и прикладная методология

Методология — это фундаментальный «метод мышления о всяких методах», акцент на «всякие методы» в их огромном разнообразии, на высоком уровне абстракции тут не случаен.

В самых различных словарях и справочниках приводятся довольно путанные сведения о том, что такое методология, и это неудивительно — ибо исторически значение термина менялось, и продолжает меняться до сих пор.

Термин довольно древний, первым его использовал Платон², и речь шла о методе, которым производится «познание»/cognition. Но потом получилось так, что «методология» по своему предмету (учение о методе/способе познания) стала неотличима от самых разных других фундаментальных методов мышления. Попытки определить, чем занимаются

• методология,

• научный метод,

• философия науки,

• эпистемология,

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

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

После более чем столетней давности прагматического поворота в философии⁴ значения слова «методология» и «метод» продолжали меняться и познание/исследование/изучение/learning/cognition перестало быть только моделированием мира, сейчас основное — это изучение методов многоуровневого (действие на многих системных уровнях одновременно) изменения моделей мира и агента (при этом есть и такое мнение, что это общая неразделимая модель мира-с-агентом, главное, что ошибка предсказания становится мала⁵), а также физического мира и агента. При этом чёткое разделение на мир и агента в этих формулировках оказывается не очень удобным. Как любит говорить Karl Friston, агент не всегда уверен, где его тело, а где уже внешний мир — и поэтому постоянно тестирует границы своего влияния, так что «все взаимосвязанные модели и взаимосвязанные части мира изменяются одновременно, в одном процессе». Как всегда, «о границах системы надо коллективно договариваться, выдвигая и критикуя гипотезы».

Агент/IPU (information-processing unit⁶) при этом мыслится безмасштабно и его разумность тоже может быть совсем разной: у молекулы нет порождающих/generative моделей мира и себя, у кошки их побольше, а команда людей может иметь множество подробных таких моделей (которые необязательно в мозгу, иммунная система тоже содержит такую модель, отличающую «своё» от «чужого»⁷, а ещё такие модели могут быть в компьютерах). При этом границы моделей мира и себя, а также границы себя и мира, а также границы модели как программы-для-моделера и себя и мира как моделеров — они тоже размыты, прагматизм позволяет думать о том самом «одном процессе, одномоментном изменении всего». Методология как общее учение о методе даёт набор понятий, которые позволяют думать о таких изменениях. Тут поработали и физики: David Deutsch предложил понятие создателя/constructor⁸, которое позволяет рассуждать о методах работы создателя, причём создатель при выполнении экземпляров работ по методу остаётся неизменным — но появляется при этом ход на безмасштабное неантропоцентричное описание методов работы как поведения создателей.

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

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

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

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

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

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

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

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

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

• Прикладной методологией занимаются организаторы (подроль менеджера), когда они в подроли методолога: моделируют рабочие процессы. Рабочие процессы — это просто один из синонимов «метода», и когда кто-то занимается стратегированием (выбирает вид рабочего процесса изо всех возможных), моделированием (описанием рабочего процесса), созданием регламента, то мы имеем дело с ролью прикладного методолога. Конечно, регламент/инструкцию/стандарт можно рассматривать как учебный материал для сотрудников, тем самым занятие по подготовке регламентов можно отнести и к прикладной методологии роли «методолог» в «Инженерии личности».

• … этот список можно продолжать и продолжать, ибо везде приходится иметь дело с системами, которые что-то делают по какому-то методу в какой-то предметной области, и хорошо бы иметь хорошо разбирающегося в этих методах человека, это и будет прикладной методолог. А если речь идёт о том, чтобы разобраться в методах разных предметных областей, с которыми приходится сталкиваться, работа идёт по фундаментальному методу — методу фундаментальной методологии.

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

• Вначале был «опытный разработчик», который разбирался с методами/функциями работы системы, смотрел на доступные конструктивные части и назначал эти части на функции, чаще всего 1:1, но иногда и более хитрым образом.

• Затем выделился «архитектор», который главным образом занимался «верхнеуровневой разработкой», то есть он выписывал верхнеуровневые функции системы, затем бил системы на какие-то более-менее независимые части-модули, которые потом раздавались разным командам разработки. А уже внизу «просто опытные разработчики» как-то пытались реализовать эти модули.

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

• Сейчас в общей роли разработчика системы можно выделить частную роль методолога, который занимается не конструктивным/модульным синтезом (этим занимается архитектор), а функциональным синтезом/композицией. А разработчику осталось брать конструктивные модули, подходящие под ограничения на нарезку системы на модули и организацию их связей архитектором и реализовывать идеи, которые приходят от методологов. Очень и очень условно можно сказать, что агенты в ролях методолога и архитектора выступают для разработчика в роли «внутренних консультантов и инспекторов надзора» по своим предметам. Это в литературе для архитекторов описывается как функции mentoring (объяснение принятых архитектором решений по модульному синтезу), и governance (отслеживание того, что принятые решения соблюдаются, а если не соблюдаются — то принятие болезненных мер, вплоть до увольнения сотрудников, которые или не хотят, или не могут соблюсти эти решения). Для методолога можно ожидать примерно такого же описания его функций: принимать решения по поводу функционального синтеза, а затем отслеживать выполнение этих решений.

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

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

В части синонимии термина «методология» мы различаем обозначаемые этим термином значения:

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

• дисциплины («научного предмета») «методологии» как набора тесно связанных друг с другом понятий и способов рассуждения о них, это знание/дисциплина/«научный предмет»/теория/алгоритм/объяснения методологии::метод.

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

Слово-термин «методология» может иметь два словарных значения:

• как «учение о методе», то есть «метод мышления о методе» или дисциплина этого метода.

• как эквивалент слова «метод» для прикладного метода работы (например, методология возведения зданий в условиях вечной мерзлоты, методология выращивания породистых кошек, методология расчёта прочности клеевых соединений), это подчёркивается даже в инженерных стандартах¹¹.

Так что «методология разработки XYZ» или «метод разработки KLM», а также «инженерия методов»¹² и даже её вариант «ситуационная инженерия методов»¹³ как один из методов для самой методологии как учения о методе — так вполне можно говорить, а значения слова нужно выделять по контексту.

Это точно такое же использование слова «методология», как и в случае «логики» — она тоже может быть учением о разных логиках, а «Аристотелевская логика» — это одна из логик, изучаемых учением о логиках. Или «геометрия» — это учение о разных пространственных объектах в пространствах разных размерностей, а «Евклидова геометрия» — это один из вариантов геометрии, изучаемых учением о геометриях.

Понятия методологии вы встретили ещё в руководстве по системному мышлению», ибо они неразрывно связаны с понятиями системного подхода (прежде всего современная методология изучает методы работы систем-создателей в графах создателей каких-то целевых систем). Более того, в 2018-2022 годах методология входила в состав (тогда ещё курса, а не руководства) «Системное мышление» и была вынесена как отдельное руководство только в 2023 году. Так что смело можно рассматривать руководство по методологии как продолжение руководства по системному мышлению.

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

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

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

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

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

Понятие метода

Метод/way of working (не будем тут перечислять самые разные синонимы) — это в инженерии способ/паттерн/шаблон работ. Это функциональное определение, единица повторной используемости в работе, паттерн/похожесть в выполнении множества работ, относимых к одному методу работы. В мире мы видим работы как изменения при взаимодействии каких-то физических объектов (называемых в случае работ ресурсами). Похожести в действиях работников, связываемые с целями работ, и будут методом/способом этих работ. Метод/функция — это функциональный аспект поведения какой-то системы (если неживой, то чаще говорят функция, если живой — метод или один из его многочисленных синонимов для системы-создателя) как роли/функционального объекта. Работа/функционирование/«задействование/выполнение метода» — конструктивный взгляд на поведение системы как конструктивного объекта.

Если рабочий Петя выполняет рытьё канавы лопатой с 10 утра до 18 часов, а рабочий Вася роет канаву в другом городе, тоже лопатой, причём ночью — то это будет две работы::поведение, но выполняются они по одному методу::поведение «рытьё лопатой» ролями «землекопов», имеющими мастерство «рытьё лопатой», имеющими лопаты и работающими с предметами метода — канавой, проходящей состояния (это пример! В каждом проекте тут будет разное, на разном уровне детальности!) «определено, какая по глубине канава нужна и где она будет», «работник с лопатой для рытья выбран», «рытьё происходит», «канава вырыта».

Так что метод::поведение роли/«функционального объекта» с (функциональными) предметами метода реализуется в физическом мире работой конструктивного объекта с предметами работы. Но так не говорят, а говорят о применении метода в работе или выполнении метода.

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

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

Так что тут всё то же самое, что с воплощением ролевых объектов конструктивными объектами: как «принц Гамлет»::оргроль появляется в физическом мире, когда его играет/реализует/воплощает «Вася Пупкин»::оргзвено (а до этого есть только её описание, но принца Гамлета в физическом мире нет), так и «моделирование табличками»::метод появляется в мире только в момент его реализации работой Зинаиды Фёдоровны «моделирование по методам из руководства по методологии 23 мартобря 2024». Метод работы «моделирование табличками» при этом выполняются оргролью «модельер», а вот работа — конкретным оргзвеном, играющим роль модельера, Зинаидой Фёдоровной (а то, что инженер-менеджер, модельер и Зинаида Фёдоровна — это один и тот же объект, это нам даст 4D экстенсионализм: если обсуждаем одно и то же место в пространстве-времени, то это один и тот же предмет, даже если называем его по-разному).

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

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

Помним из руководства по системному мышлению о том, что нам удобно использовать понятие создателя, как его определял David Deutsch в constructor theory: это такая система, которая многократно может изменить/transform какие-то другие системы, сохранив при этом себя неизменной. Например, молекула-катализатор. Или станок. Или робот (станок с компьютером). Или человек (который может изготовить пять роботов, оставшись при этом неизменным, или даже изготовить человека, оставшись при этом неизменным!). Или транснациональная корпорация. Важно, что это обобщение вычисления с преобразования информации на все возможные изменения физического мира. И ещё помним, что методы могут описываться как последовательности операций (императивно), как набор логических высказываний о мире, как применение набора функций — знания создателя могут быть в самой разной форме (принцип соответствия Curry-Howard, унивалентные основания математики — это всё довольно тщательно обсуждается в computer science и конструктивной математике). Универсальный создатель тем самым похож на универсальную машину Тьюринга: он потенциально может выполнить любое преобразование физического мира, следуя алгоритму. Если создатель не совсем интеллектуальный (и мы говорим не о методе, а о функции), это не меняет общий ход рассуждения (подробности такого неантропоцентричного подхода к интеллекту даются в руководстве по интеллект-стеку).

Методы обычно дробны, они раскладываются на составляющие, тоже методы. Иногда говорят подметоды, но тут может быть путаница между разными видами отношений, скрывающимися за приставкой «под», чаще всего это отношения:

• Композиции/декомпозиции (часть-целое). Это отношение плохо определено для процессов (хотя есть способы об этом думать через части-целые создателя и предметов метода в 4D — но тогда проще сразу говорить про части-целые создателя и предметов метода, а не части-целые поведения).

• Разложение/составление (не сводимое к «частям целым»). Для «приготовления борща»::сигнатура (приготовление::метод, борщ::«предмет метода») мы будем «пассировать овощи»::сигнатура (пассировать::метод овощи::«предмет метода») и «варить овощи»::сигнатура (варить::метод, овощи::«предмет метода»). Борщ::«предмет метода» будет проходить состояния задуман, продукты закуплены, готовится, готов, съеден.

• Специализации (род-вид). Подметоды производства — это аддитивное (например, 3D-печать) и субтрактивное (например, фрезерование) производство.

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

• Метод/методология разработки — это самое крупное деление, «все методы, необходимые для выполнения проекта».

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

• Стиль — это самое мелкое деление, часто относящееся к особенностям реализации практики каким-то отдельным исполнителем или сообществом исполнителей. Когда говорят «стиль руководства», «стиль вождения автомобиля» — это ровно оно: будут выполняться какие-то практики (более крупные методы), но будут некоторые особенности их выполнения (эти особенности — способы/методы выполнения каких-то маленьких кусочков работы). Стиль общения — это ровно оно: вам скажут сообщение, но при этом в разложении метода будет или «добавлять матерные слова» или «убирать матерные слова». Иногда стиль важен, тогда его обсуждают отдельно. Иногда — нет, тогда его не обсуждают.

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

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

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

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

Для начала надо в явном виде обсуждать, что именно делает начальник: какие роли он играет, по каким методам он работает в этих ролях, ибо по сигнатуре метода мало что можно сказать, надо обсуждать разложение метода хотя бы на один уровень вниз — отдельно, что он сам думает по этому поводу, а что происходит при независимой оценке (самооценка и оценка со стороны могут разительно отличаться). Так, начальник может считать, что он главным образом инженер — но потом оказывается, что инженерная работа занимает не более 20% его времени, и он даже не инженер-архитектор, как он себя оценивал, а, например, инженер внутренней платформы разработки, а до архитектуры у него никогда руки не доходят, нет времени — годами.

Скажем, инженерия в целом — это инженерия чего угодно, но есть виды инженерии как отдельные «инженерные практики». Эти «инженерные практики» — «масло масляное»: можно сказать инженерные практики, практические практики, трудовые практики, деятельностные практики, практические деятельности, инженерные деятельности, инженерная инженерия и т.д. Бытовой язык богат, имеется в виду одно и то же, причём один термин дублирует другой «на всякий случай», показывает разные оттенки смысла. Но нам в нашем руководстве эти оттенки смысла не слишком важны. Наша задача — раскрыть значение используемого в методологии понятия и дать ему какое-то имя, чтобы мы могли его обсудить. А уж как оно называется в бытовой речи на самых разных естественных языках — дело десятое. Как удобно, так и называйте, но не путайте в голове оргроли и оргзвенья, методы/функции/сервисы и реализующие их работы конструкции. Функциональный и конструктивный миры различны, про функциональный мир думаем в момент эксплуатации/функционирования целевой системы, про конструктивный мир думаем во время создания целевой системы, то есть во время эксплуатации/функционирования создателя, а не эксплуатации/функционирования создаваемой системы.

Понятие метода/способа работы контринтуитивно, люди очень плохо осознают, что любая их работа (включая любую работу коллектива людей, впрочем, и любую работу станка) выполняется каким-то способом, по какому-то шаблону, паттерну.

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

Зачем изучать методологию

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

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

Аргументы против изучения методологии тоже есть, но есть также и их критика:

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

• Методология нужна только прикладным методологам (тем, кто занимается функциональностью каких-то целевых систем или систем-создателей). Размышлять о методах, моделировать/описывать методы нужно редко. Например, при создании учебных курсов методологию нужно знать только тем, кто занимается ролью методолога, а в менеджменте — только тем, кто занят описанием рабочих процессов (если оно вообще делается). Производственникам и менеджерам в целом она не нужна, а если уж кому приспичит (в какой-нибудь «службе качества», где проверяющие потребуют очередной «список методов» или «список процессов», как обычно, не имеющий отношения к тому, как реально проходит работа) — то и без обучения разберутся, все эти «службы качества» аналитические по принципу, никакого качества они на-гора не выдают, а просто готовят какие-то описания для разных проверяющих да инвентаризующих. Учить этих людей можно, но необязательно: свои пухленькие стандарты они и без «методологии» прочтут. Если верить этому аргументу, то «методолог» — это не роль человека, который рассуждает о методе, а должность. Нет, «пловец» — это не только спортсмен, который плавает где-то на соревнованиях как член команды пловцов, это любой человек, которому нужно проплыть из точки А по воде в точку Б, и нет ни лодки, ни спасательного круга. И в этот момент надо понимать: дана только сигнатура метода, но не его разложение. Так что дальше выбор — плыть топориком, по-собачьи, кролем или брассом. Неплохо бы знать при этом различия этих стилей. И ещё в этом «плыть» целый стек методов, например, надо ещё знать, как дышать. И ещё как управлять усилиями в теле — это делается одинаково для всех выбранных стилей плавания. С методологией так же: если обсуждать «как будем работать» (обсуждать метод/способ работы, way of working), то неплохо бы знать, на какие объекты в мире обращать внимание — например, такой объект, как «сигнатура метода». Нужно знать типы мета-мета-модели «из учебника» (типы объектов, обсуждаемых в наших руководствах для инженеров-менеджеров, в том числе руководстве по методологии), чтобы обсуждать затем организацию работы в проекте.

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

Аргументы за изучение методологии:

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

• Большинство людей, которые явно занялись методологией в инженерных и менеджерских проектах, были поставлены перед проблемой научить какую-то новую команду работать каким-то методом, которым они владели неосознанно. Они не знали, чему именно нужно учить людей: «что такое метод», как о нём рассказывать. Такая проблема (научить новому способу работы/way of working какую-то команду, адаптировав этот способ работы к новым условиям) появляется перед людьми чаще, чем можно подумать. Проблема переноса и адаптации метода работы появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии как таковой, а не только по конкретной технологии/методу/практике. Освоить один раз (наше руководство!), а потом использовать методологию во всех рабочих проектах, занимающихся созданием и развитием успешных систем самой разной природы.

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

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

Приложения методологии уже начинают изучать и на производстве, и в вузах, и не только неявно (то есть знакомством с разными Body of Knowledge как формой представления знаний о методах работы и неявным пониманием, что они по большому счёту устроены все примерно одинаково), но и явно — через изучение методологических стандартов (обычно посвящённых какой-то записи способа работы, это OMG Essence:2024, популярный у инженеров ISO 24774:2014 и многие другие, обычно применяющиеся для описания «рабочих процессов», «процессов разработки», «видов жизненного цикла» и тех самых BoK по разным методологиями разработки). Эти стандарты стремительно отстают от жизни, и нужно иметь более общее знание о том, как устроены такие стандарты, чтобы замечать отставание и не следовать таким стандартам слепо.

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

Методология в интеллект-стеке

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

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

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

• В современном интеллект-стеке признаётся, что кроме представления о методах работы в форме локальных (символьных) представлений с типами и отношениями, а в более современных вариантах — с типами и операциями конструирования типизированных объектов (конструктивный подход в математике и логике, переход к алгоритмам от логических «доказательств»), существует вариант с распределёнными представлениями. И тогда можно применить representations learning, «обучение представлениям» — и какая-нибудь нейросеть (включая, заметим, и «мокрая» нейросеть человека, и «сухая» нейросеть какого-нибудь робота) может выполнить выявление паттернов как предметов метода, так и паттернов эффективных действий с ними. Скажем, можно пробовать сформулировать метод вождения автомобиля в виде набора правил, но можно просто обучить нейросеть на примере огромного числа дорожных ситуаций, и есть множество методов подобного обучения. Скажем, так ставит проблему команда Виталия Ванчурина, которая использует закономерности физики для выработки стратегии (в мире искусственного интеллекта стратегию часто называют policy). Подход этой команды сводится к тому, что важную информацию не нужно извлекать «грубой силой», но можно использовать понимание симметрии системы, чтобы извлечь очень небольшое число важных типов, описывающих важные объекты (команда называет эти типы «инвариантами»), чтобы получить работоспособные стратегии ²⁰. Вся литература по «обучению с подкреплением» (reinforcement learning) по большому счёту — это литература по стратегированию, обучению выбору действий в незнакомой ситуации методом проб и ошибок, при этом известно, что будет ошибкой (известная «функция награды»). Современная методология наиболее бурно развивается как методология в распределённых представлениях. Мы её не будем подробно касаться в нашем руководстве, но вся проблематика современных систем с искусственным интеллектом — она связана со стратегированием и планированием в распределённых представлениях.

Тем самым понимание того, как же мы работаем с методами, как мы выбираем метод, существенно связано с тем, как мы представляем/represent этот метод:

• В локальных представлениях — на каком уровне абстракции (мета-мета-модель, мета-модель, модель)

• В распределённых представлениях так вопрос даже поставить нельзя, это исследовательский фронтир, и в общем случае для агентов проблема стратегирования и планирования не решена²¹.

Так что для разбирательства с современной методологией надо разобраться с современной семантикой (учение о представлениях, раньше — только локальных, а теперь локальных и распределённых), которая в свою очередь отсылает к физике и математике, а также семиотике и обучению представлениям (representations learning) в случае нейросетевых технологий с их распределёнными представлениями:

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

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

Тут ещё надо заметить, что понятия policy и plan в AI относятся к выбору метода и планированию одновременно, а в менеджменте стратегия и план — различаются предметом (стратегирование — про выбор метода, а планирование — про построение графика работ и оптимизацию использования ресурсов для выполнения работ по методу). Более того, policy — это понятие для современного AI, работающего с распределёнными представлениями и задействующего обучение с подкреплением, а в старом «логическом» (с экспертными системами) искусственном интеллекте прошлого века понятие «план» ещё и как в классическом проектном управлении — это up front plan (то есть полное планирование перед производством всех работ, что в реальной жизни уже признано практически недостижимым, кроме довольно редких ситуаций). План будет представлять собой строго определенную последовательность действий, ведущую от начального состояния предметов метода к конечному (ну, он может быть и сложнее, если у вас есть параллелизм, но это все равно основная идея). Политика будет определяться набором пар «состояние предмета метода -> действие», которые должны позволять из любого достижимого состояния в конечном итоге достичь заданного сигнатурой метода состояния²³.

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

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

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

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

• Затем примите рациональное (то есть на базе лучших теорий принятия решений) решение: выберите между альтернативами. Это будет неоптимальный выбор, «наименее худшего из всех имеющихся» (ибо лучший метод или вы не знаете, или его ещё не изобрели).

• Обоснуйте выбор, приведите его инженерное обоснование.

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

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

Так что для работы с методами нужно ещё и уметь рационально принимать решения, опираясь на лучшие известные нам контрфактуальные объяснения. И это мы даже ещё не весь интеллект-стек методов мышления прошли.

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

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

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

Вот, например, праксиология в варианте Murray Rothbard²⁴ от 1951 года (и нельзя сказать, чтобы человечество сильно продвинулось в построении этой праксиологии):

1. Теория изолированного агента (экономика Робинзона Крузо)

2. Теория добровольного межличностного обмена (каталлактика, или рыночная экономика)

   1. Бартер

   2. Со средствами для обмена

      1. Свободный рынок

      2. Эффекты насильственного вмешательства в рынок

      3. Эффекты насильственного запрета рынка (социализм)

3. Теория войны — враждебная деятельность

4. Теория игр (например, работы von Neumann and Morgenstern)

5. Неизвестное

А вот пример аксиом и постулатов праксиологии мизесовского варианта (не будем тут вдаваться в подробности о разнице постулатов и аксиом) в изложении одного из австрийских экономистов²⁵, и обратите внимание, что там только про «людей», это всё создавалось во времена, когда об «агентах» не особо задумывались:

1. Человеческое поведение целенаправленно. Цель может меняться (условия изменились и человек передумал, или человек передумал «просто так», не важно).

2. Целеполагание человека всецело субъективно (не существует никакого «объективного», «беспристрастного» и тем более «научного» способа решить, что ему или ей носить или где проводить отпуск).

3. Праксеологическое действие отличается от «физического». Бессознательные реакции организма существуют, но ими праксеология не занимается.

4. Более того, наблюдаемое бездействие часто оказывается действием, т.е. результатом выбора человека. Физически неподвижный человек, который не подходит к телефону, хотя слышит звонок и имеет физическую возможность взять трубку, совершил выбор, а значит в этот момент он действует в праксеологическом смысле.

5. Человек действует, чтобы изменить ситуацию для себя к лучшему. Так, как он понимает это лучшее в данный момент.

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

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

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

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

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

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

12. Праскеология может помочь при невротических состояниях (но не обязательно). Пракселогия прочищает мозги и стимулирует посмотреть иначе на многие привычные вещи. Праксеология не обеспечивает успеха в делах и в личной жизни. В этом смысле она относится не к «плодоносным», а к «светоносным» наукам²⁶.

Праксеология в изложении этого экономиста — аксиоматическая логическая наука, то есть такая специальная «математика» (наука о поведении идеальных/ментальных/абстрактных объектов), которая даёт для других «естественных» (о физическом мире, подразумевающих измерение) наук интересные объекты с хорошо изученным поведением для размышлений и некоторые соотношения между объектами. Как они связаны с физическими объектами из реальной жизни? Никак! Вот как геометрия никак не связана с фигурами из жизни. Нужны отдельные люди (для геометрии — физики), чтобы связать «треугольники из жизни» (измеряемые!) с геометриями, и иногда ньютоновские физики связывают с объектами геометрии Евклида, а иногда — Римана. Праксеологий тоже несколько, и они тоже «именные». По-английски такие наборы постулатов и аксиом, задающие «абстрактные объекты, с хорошо понятным поведением, использующиеся для задания типов в размышлениях о предметной области» — это, конечно, frameworks, а у нас в руководствах это мета-мета-модели или метаУ-модели. Праксеология — это такой фреймворк/мета-мета-модель для размышлений о людях (но в принципе тексты там для рациональных агентов, они не антропоцентричны). Подходящ ли этот фреймворк, не надо ли вместо мизесовской праксеологии брать какую другую? Фреймворки сами по себе обычно не используют, их обычно берут готовыми из «математики» или «логики» как догадки/гипотезы для естественных/экспериментальных наук, а потом другие люди (не праксеологи!), а экономисты, правоведы (не путать с юристами), социологи будут делать эксперименты/«измерения в контролируемых условиях для выбора из нескольких догадок», где показывать, что «поведение абстрактных объектов такой-то праксеологии похоже в каком-то смысле на поведение реальных объектов больше, чем поведение абстрактных объектов из другой праксеологии».

Для геометрии эти эксперименты делают физики. В предложенном экономисте варианте постулатов и аксиом праксиологии поминается и деление наук (термин в первоисточнике Фрэнсиса Бэкона experiments, но традиционно это переводится как «науки») на светоносные и плодоносные. Вот светоносные — это как раз и есть абстрактные наборы идей, фреймворки/метаУ-модели/«математики» (которые не чисто формульны, но всё-таки «логические», вплоть до «математически логических» или вероятностно-логических), а плодоносные — это аналоги «физики», которые подбирают догадки из объектов светоносных наук под какие-то замеры поведения объектов плодоносных наук. Дальше вместо разговора о физических объектах используют разговор о математических объектах.

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

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

Впрочем, физики тоже так поступают, при этом хорошая формализация (хорошее предложение framework, математических объектов для выражения физических явлений, согласованное с предложениями по другим мат.объектам, чтобы можно было строить и математические доказательства поведения абстрактных объектов) может быть найдена позже — а пока физики пользуются собственной догадкой об абстрактных объектах в математике, профессиональные математики оказываются очень недовольны плохой формализацией и отсутствием хорошей изученности предложенных объектов²⁷. Аналогичные истории можно было бы находить и в экономике, правоведении, социологии — но праксеологию там как-то не принято обсуждать явно, кроме как у последователей австрийской школы. Поэтому стратегический выбор версии экономики в наших руководствах — австрийская школа экономики, в ней праксеология обсуждается явно. Больше подробностей в наших руководствах по рациональной работе (устройство рациональных объяснений), системному менеджменту (экономика), интеллект-стеку (связь математики и физики).

Как при этом должны быть устроены сообщества, общества и человечество в целом политически и как там должно быть устроено право, основанное на праксиологии как общей теории деятельности — это большой вопрос. Наше руководство по методологии не будет касаться в текущей версии практик/деятельности/труда сообществ, обществ и человечества, равно как будет мало говорить о «методе работы станка» или «методе работы робота», хотя в этом случае всё будет проще и понятней, разве что станок и робот не могут принимать решений о методе своей работы, это за них делают люди и организации людей, в состав которых входят и станки, и роботы. Но сейчас с развитием машинного интеллекта возможен и другой вариант рассмотрения: какой-нибудь отдел может быть представлен как компьютер, в состав которого входят люди — и по мере развития постепенно люди замещаются компьютерами, это и есть тренд «автоматизация всего», концепция киборга (cybernetic organism) как образа агента будущего заменяется концепцией гиброта (hybrot — hybrid robot²⁸).

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

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

Современная идея в том, что исполнитель каждой прикладной роли задействует два мастерства методолога на двух онтологических уровнях:

• Фундаментальное методологическое мастерство, мастерство выполнения методологической работы. Методология как метод мышления фундаментальна, входит в состав фундаментальных методов интеллект-стека (подробней об этом можно узнать в руководстве по интеллект-стеку). Это умение рассуждать о методах, сравнивать методы, описывать методы, убеждаться в реальном выполнении методов в ходе работ (например, умение создавать чеклисты). Это уровень мета-мета-модели, предмет нашего руководства.

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

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

Моделирование: выбор метода

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

Метафора разложения метода в стек. Спектр мастерства по стеку методов как спектральной шкале.

Есть множество трудностей с пониманием самого понятия метода работы — очень трудно представить себе, что же это такое. Так, легко представить себе бегуна, но если попробовать представить бег этого бегуна, то представится опять-таки бегун, хотя и «развёрнутым видео бегуна в движении», без бегуна представить бег сложно, это ведь поведение без того, кто как-то себя ведёт. Похоже на попытки обсуждения Чеширского кота: улыбка кота есть, а самого кота нет. В 4D экстенсионализме это нормально, это подробно разбиралось в руководстве по системному мышлению.

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

Одна из трудностей тут — путаница между:

• самим методом как тем, что происходит в жизни в ходе работы,

• описанием метода,

• методом обучения мастерству выполнения метода (в том числе описание метода путают с описанием метода обучения мастерству выполнения метода).

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

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

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

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

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

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

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

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

Вот именно спектры от разных источников света:

Дальше надо бы рассмотреть много терминологических нюансов. Например, разложение в спектр света на английском — dispersion/дисперсия, ибо так это назвал Ньютон. Бывают и разложения в спектр не света или электромагнитных колебаний по длинам. Можно брать масс-спектры, где линии спектра соответствуют отношению массы к заряду иона (характеризуют природу иона, разные ионы имеют разные отношения массы к заряду), а высота линии — соответствует концентрации иона. Там тоже смесь ионов существует как одно целое и происходит разложение для понимания, из каких ионов составлен раствор. Но в растворе нельзя как-то выявить один вид ионов как его истинную часть, они же там все перемешаны, нет границы между ионами разной природы в их растворе! Иногда разложение даётся как spectral decomposition, таки «разложение», а вот разложение в ряд в математике — это расширение (expansion series).

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

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

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

Вернёмся к этому примеру и представим его в виде спектра степени мастерства танцоров по шкале из разложения методов в некоторый стек составляющих методов, разве что заменим «метод» словом «культура» — это синоним «метода», означающий, что метод получил распространение:

Онтологически различаем разные типы, которые тут отображены:

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

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

• Культуры характеризуются их теориями/объяснениями/алгоритмами, но это знания, которые только описывают поведение точно так же, как алгоритм описывает вычисление по нему, он сам — не вычисление. Один алгоритм описывает множество вычислений, которые можно выполнить над самыми разными входными данными этого алгоритма. Метод — это «обобщённое вычисление как преобразование/transformation входов в выходы, в том числе обобщённое на объекты реального мира», производимое какой-то программой как «алгоритмом, по которому идёт обобщённый вычислитель как создатель/constructor».

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

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

Хотя мы легко могли бы предложить и другие варианты спектрального представления (кроме спектра мастерства в выполнении метода, тут «культурного мастерства») для метода, разложенного в этот же стек:

• спектр общепринятости (распространённости этой культуры среди населения),

• спектр универсальности (тут мы касаемся «стековости» представления — ожидаем, что нижние уровни стека более распространены, чем верхние, то есть телесные практики будут задействованы и в спектре культуры социальных танцев, и в спектре культуры лёгкой атлетики, и в спектре культуры восточных единоборств),

• спектр документированности (где есть отчуждаемые от носителей культуры описания знаний, а где до сих пор «традиция устной передачи», на предприятиях это уровень документирования рабочих процессов. Помним, что один из синонимов для «метода» — это «рабочий процесс»).

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

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

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

Но проиллюстрируем идею «стека» как шкалы для разложения мастерства плавания. Вот вам табличка для разложения в стек культуры плавания (авторство Юлии Чайковской). Посмотрите, насколько сложней реальный пример того учебного примера, который мы рассмотрели в начале подраздела.

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

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

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

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

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

Вот практики (возьмём ещё один синоним) картинга на базе того же разложения телесной культуры, которое мы использовали для танцев и плавания³⁰:

Вот капоэйра в таком же представлении, уберём оттуда линию спектра мастерства³¹:

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

Эти таблички демонстрируют два вполне совместимых взгляда на разложение метода/культуры/инженерии/практики работы:

• объяснение того, что в одной и той же работе какой-то системы (в том числе системы-создателя, работе агента) можно увидеть много разных шаблонов/методов, как много разных «частных» цветов можно увидеть в белом «полном» свете (много частей спектра³² можно разглядеть в полном спектре, «разглядеть» тут — буквально, spectrum — это «видение» от латинского spectare, «смотреть»). Говорим о шкале.

• объяснение того, что мы можем переиспользовать какую-то часть разложения метода как «методы платформы», «основание стека методов», а другую — заменять. Говорим не столько о шкале, сколько о «стеке».

Моделирование: разложение культурного движения в стек

Представьте табличку разложения какого-то знакомого вам метода культурного движения (спорт, единоборства, танцы, паркур и т.д.) по образу и подобию таблиц из предыдущего подраздела. Укажите свою степень мастерства в каждой из субкультур (по десятибалльной шкале, 0 — «вообще не умею», 10 — «я олимпийский чемпион»).

Представление разложения метода деревом

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

Так, semantic web technology stack легко гуглится, он также называется semantic web layer cake, но слои в нём весьма и весьма условны (более того, ещё и на разных картинках разных авторов их число и состав разнится). Вот только один из вариантов изображения этого «слоёного пирога», обратите внимание, что там отнюдь не только плоские «блины» в этом пироге, не получается чистой «стопки», это и есть беда всех «стеков» в платформах и разложениях методов:

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

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

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

В старом понятии архитектуры (примерно до 2017 года, когда именно архитекторы создавали концепцию системы в целом как «самые опытные разработчики») это означает, что функциональные описания в рамках разработки архитектуры делают разработчики-проектировщики. Вот доклад 2021 года одного из главных архитекторов крупной (единорог) компании, который так и изображает эту проблему в заголовке: «как из одного архитектора вырастить 100+ архитекторов»³³. В самом докладе говорится главным образом о том, как сделать, чтобы разработкой функциональных описаний (методов, которыми работает система) занимались 100+ сотрудников, которых мы сейчас назвали бы прикладными методологами своих частей проекта общего проекта создания системы. А современное понятие архитектора подразумевает как раз разбиение системы на модули такое, чтобы прикладные методологи были по возможности автономны в своих решениях. В разработке каждого «микросервиса» в инженерии корпоративных программных систем надо определить его функцию и сделать так, чтобы все предложенные функции микросервисов укладывались в предложенный архитектором способ разбиения на части конструкции из микросервисов и способы организации коммуникации между этими частями конструкции. Это нужно для того, чтобы достичь удовлетворительных значений каких-то архитектурных характеристик «-остей», например, малое время отклика (малая латентность), высокие показатели доступности, высокие показатели в наработке на отказ (надёжность).

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

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

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

Есть множество методов (в том числе методов описания системы, удобных для применения этих методов) ведения методической, методологической и архитектурной работы в их взаимоувязке. Для примера мы можем использовать классический фреймворк Wim Gielingh из работы «A Theory for The Modelling of Complex and Dynamic Systems»³⁴, он был использован как один из источников идей для семейства стандартов описания систем STEP, ISO 15926 и далее BIM.

Gielingh вводит понятия functional unit (функциональный объект, «роль» — то, что будет задействовать метод) и technical solution (конструктивный объект, который выбран как аффорданс для реализации роли, то есть выполнения работы функции/метода) и показывает концепцию системы в ходе её эволюции, то есть создания и развития: каким образом происходит совместный функциональный синтез/декомпозиция и модульный/конструктивный синтез/декомпозиция. Если смотреть на диаграммы снизу вверх — синтез, «разработка снизу вверх», bottom-up. Если смотреть на диаграммы сверху вниз — декомпозиция, «разработка сверху вниз», top-down. В реальности же рекомендуемый метод разработки — «изнутри среднего уровня наружу вверх и вниз, inside out»). Вот предложенная нотация концепции системы для определения системных уровней с учётом отношений род-вид и выбора вида:

Такая нотация называется гамбургер-диаграмма, где указывается множество кандидатур методов в разложении для какой-то сигнатуры (обсуждение ведётся не в терминах самих методов, а в терминах ролей, работающих по этим методам, Functional Units, FU) и дальше метод назначается какому-то типу конструктивов (Technical Solution), чтобы разобраться с модульностью в порядке формирования концепции системы. «Гамбургер» тут — половинки булки, между которыми «начинка» — это выбор назначений технических решений (конструктивы) на функциональные единицы (роли). В нотации предложено принимать решения по модульности на каждом уровне функциональной декомпозиции, чтобы поощрить выделение модулей в целях унификации. Но современные архитекторы сказали бы, что такой принудительный ход на унификацию модулей — способ ввести межмодульные зависимости, поэтому подход Gielingh не получил особого распространения, умер вместе с очень популярной в 90х годах идеей разработки модулей с повторной используемостью, reuse. Это подход второго поколения системного мышления, где система разрабатывалась как экземпляр, но не как развивающийся вид, не было «непрерывного всего», разработка мыслилась итеративной, но однократной.

Фреймворк от Gielingh важен тем, что различает generalization hierarchy (иерархия сигнатур), specification hierarchy (выбор вида из рода) и installation hierarchy — уже выбранное по типу и инсталлированное как экземпляры в целевой системе, работающее — и делает это на уровне проектирования («воображаемый проект») и конфигурации конечной воплощённой системы (as built). Вот шесть иерархий, служащих предметами рассмотрения во фреймворке Gielingh — верхний ряд это «воображаемый проект» в его общем/генерализованном виде, а нижний ряд — это с конкретными расчётными функциями и указанными уже моделями конструктивов, самого Gielingh тут интересовала знаниевая работа над проектом, уточнение ролей с какими-то их методами работы и их поддержки со стороны конструктивов:

Эта диаграмма характеризует важное для методолога, разработчика и архитектора:

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

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

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

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

«Схемотехника»: представление метода работы графом потоков.

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

• Так что очевидный следующий шаг в выражении методов — сразу пройти весь путь: от последовательностей/chains (последовательности методов, например, «стек» тут тоже последовательность вложений или последовательность использования, да и «шкала» — последовательность, упорядоченность в ряду объектов)

• к деревьям/trees (хорошо представимы разными MindMaps, которые легко сводимы к аутлайнам/outlines, по факту это «хорошо структурированное оглавление», где в листьях этого оглавления могут лежать какие-то более подробные описания, фреймворк Gielingh с диаграммами гамбургера как раз такой граф «почти дерева»),

• и далее к графам/graph как общей форме представления потоков чего бы то ни было — в том числе предметов метода между ролями, задействующими метод.

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

Потоковые (движение предметов метода по каким-то путям) представления, удобно представимые графом, распространены и в менеджменте. Фон Берталанфи выделял исследование потоковых представлений систем как «исследование операций» (operations research), речь шла о времени эксплуатации (operations) — и эта дисциплина легла затем в основу операционного менеджмента, логистики, теории массового обслуживания. Конечно, в исследованиях операций в основе лежали «работы», речь шла прежде всего о потоках ресурсов между рабочими станциями. Но это можно было представить и как специфически функциональное представление: «рабочая станция» — это ведь роль, её могут выполнять разные конструктивы, она может действовать разными методами (прикладными методами операционного управления!). Опять мы попадаем в то, что методология — фундаментальная дисциплина, и даже если речь идёт об управлении работами по методу, то это рассмотрение может быть функциональным, и тут методология будет задействована для разбирательства с работами и работниками как прикладная методология операционного менеджмента — несмотря на все предупреждения «не путать метод работы и работы по методу». Методы исследования операций, методы проектного управления работами, методы операционного управления — это всё методы, только ими занимается прикладная методология этих предметных областей.

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

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

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

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

Увы, в материалах (учебных курсах, корпусах знаний, регламентах и стандартах) для архитекторов метод работы системы (в том числе системы-создателя) описывается в целом, без выделения специфической методологической/функциональной части. Да и в материалах для проектировщиков/designers не так много говорится про работу с функциями/методами, разве что упоминается, что проектирование надо начинать с работы с функциональными диаграммами. При этом функциональные диаграммы трудны для понимания, в них всё происходит как бы «одновременно», там законы типа закона Кирхгофа для электрических цепей. Помним, что разложения метода/функции тоже надо понимать, как работающие «одновременно». Но могут быть и всякие задержки и лаги (реактивные сопротивления в электроцепях, задержки на производство и логистику с момента выдачи заказа в цепях поставки, время продажи партии в розничных/retail сетях/chains).

В непрерывном производстве (нефтехимия, энергетика) функциональные диаграммы часто гибридны, в них приводится результат методологической работы (выбор метода) и одновременно указываются и результат проектирования: элементы конструкции. Это оформляется как P&ID диаграммы, piping and instrumentation diagram и PFD, process flow diagram диаграммами³⁶.

Каждый отдельный тип конструктива из крупной «нарезки на модули» архитекторами проектировщики будут потом в концепции системы упоминать не просто сам по себе, а как реализующий какую-то подсистему в её роли в системе.

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

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

Такое функциональное (это потоки в ходе функционирования моделируемой системы, функциональное представление — это ответ на вопрос «как работают в момент эксплуатации») моделирование чаще всего делают при помощи систем дифференциальных уравнений, учитывающих «одномоментность». Иногда такое физическое 1D моделирование называют системным моделированием, ибо речь идёт о моделировании работы системы как функционального объекта в целом на основе понимания того, как именно работают отдельные подсистемы.

В менеджменте такое моделирование чаще всего делают средствами системной динамики³⁷ — и это хорошо, только не надо считать, что это будет единственное моделирование в ходе проекта по созданию системы. Нет, это только 1D-моделирование, но будут ещё и другие. Более того, сегодня системным моделированием чаще называют 1D-моделирование не только упрощёнными дифференциальными уравнениями системной динамики (там очень ограниченный набор элементов модели и допустимых видов уравнений в системе дифференциальных уравнений), но и полноценным физическим описанием системы. В физическом системном моделировании (physical systems modeling), узко понимаемом как численное 1D моделирование, конкурируют каузальное моделирование с системой уравнений из обычных дифференциальных уравнений (ODE) и акаузальное моделирование с системой из алгебраических дифференциальных уравнений (ADE). Каузальное моделирование требует указывать порядок решения системы уравнений, а акаузальное моделирование — нет, систему уравнений решает сам компьютер, тренд при этом — переход от каузального моделирования к акаузальному.

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

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

1D-моделирование довольно долго делалось на акаузальных языках моделирования, например, Modelica³⁸, одновременно с графическим и текстовым представлением систем алгебраических дифференциальных уравнений. В физическом системном моделировании учитывается уже более-менее разная физика системы (механика, гидравлика, энерготеплопереносы и т.д.) или какие-то её другие свойства (например, умение производить работы, пропускать через себя поток предметов работ — иногда это называют даже factory physics). Но это всё моделирование функционирования, по факту — это моделирование метода работы системы. Вот пример представления модели на Modelica³⁹:

Мы видим на картинке 3D-модель системы «как в САПР», а также её функциональную графическую модель (диаграмму), а также программный код, соответствующий этой диаграмме. Диаграммное представление «наглядно», но с ним очень трудно работать — при росте размера диаграммы и увеличении числа «аннотаций» каждого элемента диаграммы (по факту «аннотации» — это текст, описывающий элементы диаграммы и связи — никогда не забываем, что любую картинку надо объяснять, и к картинкам для полной понятности мы «приговариваем» большое количество текста) модель, то есть систему дифференциальных уравнений, становится удобней представлять в виде текста на языке программирования. «Резистор» становится не схемным изображением на диаграмме, а текстом программы.

По итогам эксплуатации многочисленных систем с Modelica оказалось, что диаграммное представление функциональных схем менее удобно в работе: модельеры-проектировщики проводят много времени в текстовых представлениях, а диаграммы используют главным образом в «презентациях», для красоты, которую называют «наглядностью». Любые изменения-исправления, вставки и удаления, предложение альтернатив и комментарии делаются в текстовой форме, она банально удобнее. Поэтому современные средства 1D-моделирования по факту представляют собой пакеты численного моделирования для обычных языков программирования, например, один из самых мощных таких пакетов — JuliaSim⁴⁰. Отсутствие «визуальности» функционального моделирования с лихвой компенсируется удобством использования: тексты менять в ходе разработки много быстрее, чем диаграммы. И тексты можно пересылать друг другу, легко комментировать, чего не сделаешь с диаграммами — учитывая ещё и то, что откомментировать фрагмент текста программы функциональной модели можно и в чате, а вот с диаграммами всё не так просто, нужны специальные дорогие программы для работы с диаграммами, и они должны быть установлены у всех участников проекта, что обычно невозможно.

Тем самым мы от ограниченного диаграммного языка описания методов в их разложении перешли к описанию разложения метода алгоритмом, что ярко проявляется в функциональном физическом моделировании.

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

В традиционной «железной» инженерии принято было использование MatLab (более удобен для вычислительных задач, чем Фортран) и SimuLink для создания имитационных моделей, программные среды для вычислений с ODE (odinary differential equations in state space form — дифференциальные уравнения для пространства состояний входов и выходов). Это стало мейнстримом, но оказалось, что сопровождать модели в такой форме невозможно: для типовых случаев нельзя сделать библиотеки отдельных функциональных элементов, которые присутствуют в системе, и приходится каждый раз понимать, куда и как вписать очередное уточнение модели, или куда и как вписать очередное изменение модели.

Потому моделированию в ODE было противопоставлено акаузальное моделирование/acausal modeling с использованием DAE (differential algebraic equations) с алгебраическими переменными, которым a priori не могло быть придано никакого входного или выходного статуса — порядок вычислений не мог быть предсказан, ибо непонятно заранее, где у какого-то резистора вход, а где выход в составе модели.

Но как же проходит такой трюк с переходом от ODE к DAE? А вот так: разные уравнения собираются в большую систему из сотен, или даже тысяч (а в последнее время речь идёт и о миллионах) дифференциальных уравнений, и дальше решением этой огромной системы уравнений занимается компьютер (или даже суперкомпьютер, если система реально большая). Вот сравните удобство для инженеров моделирования электрического мотора с учётом инерции его вращения при представлении модели в DAE и ODE формах в их диаграммном виде⁴¹:

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

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

И в итоге были предложены специальные акаузальные (не требующие учёта порядка влияния друг на друга элементов через входы и выходы) языки программирования и вычислительные среды для них. Компания MathWorks к SimuLink с его ODE добавила SimScape с DAE, компания Siemens предлагает Amesim, но де-факто стандартом и экспериментальной средой для отработки новых идей стал язык акаузального имитационного моделирования мультифизики Modelica (https://modelica.org/), для которого было разработано полдюжины компиляторов самыми разными фирмами и университетами. На смену Modelica сейчас приходит проект JuliaSim с акаузальным инструментарием ModelingToolkit.jl⁴².

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

А поскольку разнородных средств физического/имитационного моделирования оказалось очень много, для объединения самых разных моделей на уровне обмена данных между их входами и выходами был предложен стандарт FMI⁴³ (functional mock-up interface — он поддерживается более чем 150 программными инструментами для моделирования).

Но и DAE/acausal моделирование оказалось с проблемами. Главная проблема тут — невозможность использования Multi-Mode DAE Models (mDAE). Multi-mode models — это моделирование режимов, связанных с разными структурами одной и той же системы. Если у вас летит ракета с тремя ступенями, потом с двумя, потом с одной ступенью — моделировать это нужно по-разному, это же будут лететь совсем разные ракеты, у которых только название общее, а физика совсем разная! Если у вас моделируется атомный реактор в ходе его нормальной работы, то там одна физическая модель. А если он уже начал плавиться — то моделировать его плавление нужно по-другому, прошлая модель реактора не будет работать. Это явление носит разные имена, Multi-mode DAE models только одно из них, в математике и физике используют и другие, например, VSS (variable structure system, — и они тоже имеют много разных подвариантов, «частных случаев»)⁴⁴. Есть и другие имена, разные группы исследователей приходят к этой проблеме учёта изменения структуры модели вслед за структурой моделируемой физической системы в разных исследовательских ситуациях и подчёркивают в имени разные аспекты проблемы.

Математика mDAE хитра, и языки акаузального физического моделирования и их компиляторы должны учитывать эту хитрость математики, иначе результаты моделирования будут кривые. Вот одна из работ 2020 года, проясняющая трудности: «The Mathematical Foundations of Physical Systems Modeling Languages»⁴⁵. Трудности там демонстрируются на вот таком простом примере, с которым не справляются нынешние компиляторы Modelica, и дело там не только в computer science (плохом языке моделирования и плохом его компиляторе), но и в математической-физической стороне вопроса:

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

После того, как разобрались с физикой и описывающей её математикой, подключается computer science, ибо нужно теперь создать язык с нужной для этой математики операционной семантикой и (оптимизирующий!) компилятор для него. Это оказывается в случае mDAE не так легко, ибо уже не хватает уровня продвинутости человечества в computer science. Исследования (computer science) и разработки (software engineering) для акаузального мультифизического моделирования идут по вот этим основным линиям, а основное развитие сейчас происходит в ModelingToolkit.jl⁴⁶ в проекте JuliaSim⁴⁷.

В какой-то мере этот тренд с использованием «языка» mDAE вместо ODE для физического моделирования похож на создание разных языков программирования для решения expression problem в самой computer science⁴⁸. Суть этой expression problem ровно в том же: разработка библиотек универсальных вычислительных элементов требует от языков программирования и реализующих их компиляторов возможности добавлять новые объекты для старых операций и новые операции для старых объектов, чтобы не нужно было переписывать весь код программы. Обратите внимание, что в предыдущем предложении мы по факту говорим, что языки программирования и языки моделирования — это одно и то же, функциональное моделирование делается на языке программирования. Это отдельная долгая история, ибо на самой заре программирования «языки высокого уровня» как раз и считались языками моделирования (например, Simula⁴⁹, первая версия которой появилась в 1962 году, это был первый объект-ориентированный язык). Это лишний раз подтверждает, что моделирование может и должно делаться не только на специализированных упрощённых языках моделирования, но и на самых обычных языках программирования общего назначения — но оно предъявляет специальные требования к этим языкам.

В mDAE против ODE мы расширяем expression problem с обсуждения только программных объектов и операций до обсуждения описания/моделирования физических сущностей: или ты делаешь язык, на котором разные функциональные объекты описываются разными наборами уравнений (декларативно), и просто добавляешь эти модели друг ко другу, или в языке у тебя такой возможности нет, и ты вынужден каждый раз переделывать программу при малейших изменениях моделируемой системы или малейших изменениях в идеях самого моделирования.

Если ты не решил эту «model expression problem», то тебе нельзя сделать стандартные библиотеки, оформляющие стандартные поведения функциональных объектов. Знания моделей становятся плохо переносимыми между моделями, модели плохо модифицируемыми — каждый раз при внесении изменений нужно переписывать и перекомпилировать всю модель.

Есть ещё и многомасштабность моделирования: объединение моделей разных системных уровней, разных масштабов времени, тут тоже свои математические и выразительные трудности в языках программирования⁵⁰, — и там тоже проблемы с ODE против DAE, плюс много чего собственного, и для этого тоже может потребоваться учёт в языках программирования/моделирования. Увы, языки программирования/моделирования не системны/многомасштабны «из коробки».

Для моделирования в реальном времени (цифровой двойник/digital twin, скорость моделирования имеет значение, проблемы алгоритмики как алгоритмов, дающих при заданной точности вычислений максимальную скорость счёта, тут всплывают в полной мере) тоже есть множество проблем, например, высокая скорость получается за счёт различных суррогатов⁵¹ моделей (быстрых аппроксиматоров сложных функций, например, нейросуррогаты получаются на базе нейронных сетей). No free lunch theorem гласит, что нет универсально быстрых алгоритмов: алгоритм, хороший для одной задачи будет плох для другой, и наоборот. И в каждом «общем решении» всё равно будут возникать (сотнями, тысячами!) многочисленные «частные случаи», требующие отдельных способов решения. Обсуждение качественного имитационного/simulations моделирования обычно связывают с суперкомпьютерами, это не случайно. Для удешевления и ускорения моделирования нужно делать прорывы в алгоритмике, менять физику компьютера (например, переходить к оптическим или квантовым вычислениям).

Когда директор стадиона обсуждает цифрового двойника для своего стадиона, хорошо бы, чтобы он понимал SoTA в области моделирования. А то ему теоретики-математики без понимания сути computer science намоделируют так, что мало никому не покажется — моделирование тут похоже на безопасность, про него ведь можно легко сказать «моделирования много не бывает», и тогда оно может съесть все деньги и ничего не дать взамен, как и излишняя безопасность. Лекарство легко может стать болезнью.

Задания: принципиальные схемы

Поставьте отметку о выполнении:

1. Написан пост о принципиальной схеме вашей системы. Особо проверьте, что в принципиальной схеме показаны функциональные, а не конструктивные объекты. Отметьте, вы где-то нашли эту принципиальную схему, или вам пришлось её составить для этого задания самостоятельно?

2. Написан пост о принципиальной схеме организации-создателя вашей системы. Особо проверьте, что в принципиальной схеме показаны оргроли, а не оргзвенья. Отметьте, вы где-то нашли эту принципиальную схему, или вам пришлось её составить для этого задания самостоятельно?

Пример: методы создания систем AI

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

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

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

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

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

В текущем подразделе мы приводим пример разговора про методы работы систем AI: что там делают подсистемы и подсистемы подсистем, обмениваясь данными, это dataflow представление. Центральное место в функциональном разбиении системы AI занимает искусственная нейронная сеть (ANN, artificial neural network), подсистема системы экспертов (несколько нейронных систем объединяются как «эксперты» в смеси экспертов, MoE, mixture of experts)⁵²:

В суперупрощённом виде мы видим функциональную диаграмму: какая-то входная информация даётся на вход маршрутизатора, который выбирает пару экспертов из четырёх возможных, а затем ответы этих экспертов как-то замешиваются в выходную информацию. Вот эти «эксперты» обычно — искусственные нейронные, ANN, artificial neural network сети с классической декомпозицией на «слои» из вычислительных «нейронов»⁵³. Вот типичная функциональная диаграмма для ANN (традиция называет такие диаграммы «архитектурами», но в этой «архитектуре» ни слова не говорится о конструктивах, это в других предметных областях было бы «принципиальная схема»), на ней представлен трансформер/transformer⁵⁴ как вид ANN, отвечающий подобного сорта функциональной диаграмме, эта «принципиальная схема» была предложена в 2017 году:

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

Обзором техноэволюции ANN занимается прикладной методолог систем AI Григорий Сапунов в канале «Gonzo-обзоры ML статей»⁵⁵. Основное содержание его обзоров много лет было как раз посвящено модификациям принципиальных схем ANN. В Gonzo-обзорах первый раз слово «метод» встречается 25 февраля 2019 в обзоре работы «AET vs. AED: Unsupervised Representation Learning by Auto-Encoding Transformations rather than Data»⁵⁶, там фраза «Дальше в работе рассматривают только параметрические преобразования. Это типа проще реализовывать, а также проще сравнивать с другими unsupervised методами». Онтологически из фразы следует, что «unsupervised learning»::метод — это род методов, в котором есть множество видов методов. Обратите внимание, что методы — это поведение, а до этого в подразделе мы обсуждали вроде как функциональные разбиения ролей на подроли (систем на подсистемы, в функциональном рассмотрении — разбиение функциональных объектов, а не поведения). Вот эта связанность роли и метода должна как-то удерживаться, нельзя думать про одно без другого: не может «никто» делать что-то, и «кто-то» не может ничего не делать! Опять же, роль может работать по какой-то сигнатуре метода, а там внутри можно даже менять методы в их разложении для этой сигнатуры, а роль поможет удерживать внимание на результирующем методе, абстрагируясь от его разложения.

Если продолжить читать текст статьи, пытаясь найти там «методы», то придётся признать, что в статье они обсуждаются, но называются крайне разнообразно — и меньше всего словами, которые у нас в руководстве даны как синонимы слова «метод». В статье «метод» обозначен то как «подход», то как «архитектура», и даже «efforts» как метонимия усилий команды, разработавшей метод, в фразах типа «Among the efforts on unsupervised learning methods, the most representative ones are Auto-Encoders and Generative Adversarial Nets (GANs)». Всё наше руководство посвящено тому, что мы под всеми этими именами выявляем/распознаем метод::тип — и с этого момента всё содержание нашего руководства по методологии приложимо к этим «подходам», «архитектурам» и даже «efforts». Заодно заметьте, что слово representative в текущей фразе не имеет отношения к representation learning, хотя, казалось бы, могло бы и иметь. Со всем этим можно разобраться из контекста, как это и наставлялось в руководстве по рациональной работе.

Помянутые методы «Auto-Encoders and Generative Adversarial Nets» (ещё раз внимание: методы называют как функциональные объекты, «автоэнкодеры» и «сети», а не поведения!) в их совокупности называют вместе родом Auto-Encoding Data (AED) как выучивание распределения по данным (выучивание — глагол, «выучивание распределения по данным» — это таки метод), и вводят ещё один род на этом же уровне: Auto-Encoding Transformations (AET, и transformations — это опять-таки отглагольное существительное, метод), где могут быть ещё и виды таких трансформаций: large variety of transformations can be easily incorporated into the AET formulation. Так, виды будут — параметрические преобразования::метод (Parameterized Transformations, как подвиды там пример — афинные и проективные), а ещё GAN (generative adversarial network — сеть, неожиданно существительное, то есть роль, а не способ работы, имеется в виду метонимия — «преобразования, которые производят GAN») и непараметрические преобразования.

Преобразования — это transformations, в русском тексте gonzo-обзора синонимизируются трансформации и преобразования. Вопрос, преобразования чего — какой предмет метода? Ведь «данные» — это явно совсем высокий уровень мета-моделирования, надо всегда стараться слова «информация» и «данные» как слишком общие типы мета-мета-модели в предметной области заменять на типы мета-модели (в руководстве по системному мышлению специально подчёркивалось, что сверхобобщения — вредны). В статье речь идёт о данных изображений, ибо текст 2019 года обсуждает главным образом распознавание изображений на тестах типа CIFAR-10⁵⁷.

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

Как же выглядит разложение методов работы нейросетей? Когда вы смотрите на диаграммы «архитектуры нейросетей», то вы должны понимать, что это функциональные диаграммы, которые по принципу мало отличаются от принципиальной схемы холодильной установки. Эта «принципиальная схема»/«функциональная диаграмма»/«dataflow diagram», показывающая потоки данных примерно так же, как электрическая принципиальная схема показывает потоки электрического тока, а гидравлическая схема показывает потоки жидкости — это и есть один из способов показать работу ролей по их методам работы, разложение метода, ответ на вопрос «как оно работает».

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

Пробегаем Gonzo-обзоры до 30 апреля 2024, когда там⁵⁸ появилась ссылка на обзор PEFT (Parameter-Efficient Fine-Tuning) алгоритмов для LLM. Смотрим на то, как употреблено слово «алгоритм» — ах, это те же методы! Как проверить? Берём картинку из статьи⁵⁹ и видим типичную ламаркианскую классификацию родов-видов именно методов, причём картинка названа именно классификаторски, «таксономией», аж на пять уровней:

Но если мы поглядим на то, что же такое PEFT даже не в самой статье, а просто аннотации, то увидим, что слово «метод» употребляется не как объект первого класса, а как что-то литературно-художественное, что тоже требует синонимизации, для пущей выразительности, термином авторы «метод» не считают: один раз это род разных видов «процессов» (но из нашего руководства мы знаем, что «процесс» — это тоже часто синоним «метода», а уж «рабочий процесс» — это точно «метод», только в менеджменте), а вот в другой раз — это род алгоритмов. Как это читать? А так и читать: алгоритм/теория/объяснение описывает метод (а чтобы не было сомнений, что теория и алгоритм — это одно и то же, то можно вспомнить про соответствие Curry-Howard — императивные и логические программы суть одно и то же, математические доказательства — это программы). Метод — это то, что делают в жизни нейросетки, проявляя «мастерство выполнения метода», а алгоритм — это то, что было взято для реализации этого мастерства для программирования вычислителя, проявляющего затем метод.

Если попытаться формализовать методологическую работу для систем AI, то от простых dataflow диаграмм можно перейти к псевдокоду, используя парадигму функционального программирования, а потом и просто к программному коду (возможно, уже мультипарадигмальному) — и там кодировать алгоритм метода с точностью, достаточной для машинного исполнения этого кода. Но если пытаться строже формализовать описание методов работы систем AI, не погружаясь в детальные описания на языках программирования, на помощь приходит теория категорий, дающая удобный формализм для математического описания методов/функций, в том числе и дающая диаграммную нотацию. Примером тут может служить работа «On the Anatomy of Attention»⁶⁰, где приводится диаграммная теоркатегорная нотация для методов работы систем AI, при этом особое внимание уделяется методам внимания. Вот пример диаграммы таксономии методов из этой работы:

Отдельно заметим, что в тексте текущего подраздела ничего не говорилось про конструктивы систем AI: мы понимаем, что алгоритмы, описывающие методы работы нейросетей реализуются на каких-то вычислителях, и эти вычислители — физические устройства со своими ограничениями. Например, где-то может быть ограничение по размеру памяти, и нужно будет выбрать вид метода, который даёт нужные результаты, но задействует немного памяти. А где-то будет достаточно памяти, но важна будет латентность: сколько времени будет занимать обработка входной информации, сколько ждать результата. И надо будет выбирать метод, дающий меньшую латентность. Ну, или оставлять тот же метод, только поручая выполнение алгоритма этого метода какому-нибудь более быстрому ускорителю вычислений методов в его разложении — то есть используя специальный инструментарий. Об этом иногда говорят как hardware aware architectures. Тут архитектура уже не совсем «принципиальная/функциональная схема», «алгоритм работы», ибо хоть как-то упомянуто и конструктивное/материальное описание системы, зацеплена работа современного архитектора, предписывающего ограничения на конструктивы и способы их взаимодействия.

Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах

Материал этого раздела весьма сложен, может оказаться, что вам нужно освежить азы алгоритмики. Как минимум, вы проходили алгоритмику в школе, возможно, сдавали по ней ЕГЭ, но методология требует, конечно, не школьного понимания алгоритмики. Увы, даже азам алгоритмики мало где учат. Мы можем указать на руководство по интеллект-стеку и там на дополнительные материалы⁶¹. Посмотрите там, чем же занимается алгоритмика. Конечно, программистам материал этого раздела будет понимать легче, но наш опыт показывает, что и это не всегда так: материал отсылает не к «программистскому опыту», а к теоретическому знанию — объяснениям азов алгоритмики в её связи с математикой и физикой. Увы, этому даже в вузах учат отнюдь не всех «программистов с высшим образованием».

Мастерство выполнения метода — программа, которая описана алгоритмом. Мы пока опустим тот нюанс, что алгоритма совершенно недостаточно для описания программы, ибо программа — это алгоритм плюс структуры данных⁶², да ещё и реализованные каким-то вычислителем (подробней это обсуждалось в руководстве по системному мышлению). В случае методов мы говорим, что создатели — это обобщение «вычислителя» до «создателя» (то есть не только работаем с данными на входе и получаем данные на выходе, но берём какие-то предметы метода на входе и получаем предметы метода на выходе — делаем физические преобразования). Так что «программа метода» понимается не просто как «вычислительная программа», а как «преобразовывающая мир», «программа для станка с ЧПУ» в простейшем случае. А если создатель умный и эта программа — алгоритм в мокрой нейросети, или даже гибридной нейросети предприятия, то мы назовём её «мастерство». Это неважно, что гибридная нейросеть предприятия состоит из мокрых нейросетей множества людей и компьютерных сухих нейросетей плюс множества баз данных и классических компьютерных программ, а ещё станков в поддержку как вычислений, так и преобразований физического мира. Всё равно можно говорить о мастерстве предприятия, например, о мастерстве разработки ракет компанией SpaceX («мастерстве в выполнении работ по методу разработки ракет»).

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

С подробным описанием метода плохо справится даже граф (визуально это будет «диаграмма», «принципиальная схема» и небольшое количество типов узлов графа и типов рёбер графа), но хорошо справится алгоритмическое представление в виде:

• алгоритма и предметов метода на естественном языке, это самая маленькая формальность представления метода на шкале формальности

• алгоритма и предметов метода на псевдокоде (похоже на какой-то формальный язык — но на самом деле формализация недостаточна для полностью машинного выполнения на классическом компьютере с языком программирования)

• алгоритма и предметов метода в виде кода на каком-то языке программирования, полностью формальное (подразумевающее «машинное» однозначное) выполнение.

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

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

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

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

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

Так что для возвращения тематики «обучения составлению алгоритмов выполнения работ» в обучение программированию нужно сделать довольно много:

• Сразу вводить понятие метода как работ не только с описаниями (абстрактными объектами, информацией, работы с данными — «компьютерное программирование»), но и с предметами метода. Алгоритмика не компьютерная, а созидательная (программирование создателей/constructors из теории создателей).

• Добавить обсуждение работы с типами предметов метода (а не только типами данных и структурами данных), ибо программа = алгоритм плюс данные.

• Алгоритмы надо будет выражать на декларативном (скорее всего, функциональном) языке. Хотя, по большому счёту, нужно владеть мультипарадигмальным программированием — ибо для разных вариантов алгоритмов удобней разные варианты парадигм программирования⁶⁵, отражённые в разных языках программирования, всё большее число современных языков программирования сегодня — мультипарадигмальные языки, поддерживают и процедурную, и функциональную парадигмы.

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

Алгоритмика сама по себе связана как с выражением способа вычислений на языке какой-то парадигмы (выражение способа — это методология), так и скоростью вычисления (это операционный менеджмент, исследование операций), что зависит от физики компьютера. Так что алгоритмика — экспериментальная наука, физика компьютера вносит реализм, а формальность вычисления — математику. Поскольку каждая программа — это доказательство (соответствие Curry-Howard⁶⁶), то соответствие физического процесса в компьютере (классическом, квантовом, оптическом и т.д.) и абстрактного процесса вычислений «в математике» может быть проверено только экспериментально, через экспериментальную науку. Deutsch прямо называет алгоритмику «наукой о доказательствах», ведь программы — это доказательства, конструктивная математика — это программирование, и дальше через алгоритмику можно делать ходы на выполнение доказательств (алгоритмов) на компьютерах, проекты унивалентных оснований математики и языков Agda и Coq как раз нацелены на помощь математикам со стороны компьютерной техники (подробней об этом — в руководстве по интеллект-стеку, и там много ссылок на литературу).

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

Алгоритмика должна экспериментально подтверждать, что алгоритм эффективно выполним на каком-то железе. В силу no free lunch theorem нет универсально быстрого алгоритма для всех задач, для разных ситуаций будут эффективны разные алгоритмы, а разница в эффективности алгоритмов на разном «железе» с разной физикой может быть драматической, в пересчёте на методы — это как копать котлован лопатой по сравнению с экскаватором, по сравнению с гидромеханическим размытием, по сравнению со взрывным способом. Методология с задействованием исследования операций в паре с операционным менеджментом должна экспериментально подтверждать, что создатель с его мастерством (реализованным тоже аппаратно!) и инструментарием (tooling), реализуя метод, будут получать результаты заданного качества/точности (предметы метода в заданном состоянии) в приемлемое время и при приемлемом расходе ресурсов. В алгоритмике говорят, что синтез алгоритмов должен быть hardware aware для того, чтобы алгоритм был эффективен. Вот и метод должен быть оптимизированным по инструментам (hardware aware), то есть учитывать наличные особенности инструментария, включая аппаратуру для мастерства как «управляющей программы».

Алгоритм — это вроде как последовательность вычислений, а тут — последовательность каких-то трансформаций для создателя, обобщение алгоритма для вычислителя (машины Тьюринга) на материальный/физический мир. И тут надо разбираться с теоретическими обобщениями, например, constructor theory⁶⁷ как обобщения машины Тьюринга как универсального вычислителя в сторону универсального преобразователя. С помощью подобной теории мы можем пробовать выдать какие-то достижения современной алгоритмики за начальные идеи в методологии, мы вполне можем понимать алгоритмы как «алгоритмы в том числе для станка с ЧПУ» и теории не математические, а вполне себе теории про реальный мир.

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

В существенной мере алгоритмы методов работы зависят от представления/representation знаний о предметной области: алгоритм сложения чисел с мастерством, реализующимся мокрой нейронной сеткой в человеческой голове, даже при условии её усиления ручкой-бумажкой для безошибочно работающей памяти и облегчения удержания внимания существенно зависит от нотации. В римской нотации всё плохо, а в арабской⁶⁸ нотации (позиционная запись и явно представленный ноль) — даже дети справляются не только с умножением десятизначных чисел, но и с делением, что казалось бы чудом ещё тысячу лет назад. Есть разница с нотациями, которые пригодны для непосредственно мышления об объектах (операции со знаками соответствуют операциям в реальном мире — вот как с арабскими цифрами, «рассуждение легко алгоритмизируется»), и «описаниями» каких-то операций в естественном языке или даже псевдокоде, которые не так-то легко алгоритмизируются⁶⁹. Хорошие нотации позволяют описать простые одинаковые последовательности операций с предметами метода для получения конечного состояния предметов метода. Плохие нотации заставляют каждый раз изобретать последовательность операций — это возможно, конечно, но только самым одарённым. А вот не для самых одарённых (тем более для компьютеров!) надо бы делать операции простыми и одинаковыми. Можно не «творить» каждый раз, а просто «посчитать по предлагаемой инструкции счёта». Не делать догадки и опровергать их, а просто «взять входные значения и без содержательного разбирательства с ними механически посчитать выходные значения».

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

Дальше по этой линии идёт DDD (domain driven design, где объекты реального мира сопоставляются объектам программы, как минимум — моделируются структурами данных), и дальше вычислитель с этими данными сам по себе становится объектом реального мира, а не просто работает с описанием объекта — это линия как «станка с ЧПУ», так и линия реестров и регистров. Если что-то поменялось в регистре, то это означает изменение в реальном мире, например, будет или не будет работать турникет допуска в помещение. Это всё важно для обсуждения тех методов, которые описываются в том числе и теорией речевых актов⁷⁰, то есть методы, включающие высказывание каких-то утверждений, которые по сути являются действиями (перформативы⁷¹ — поручения, обещания, акцепты и прочие коммуникационные акты, которые меняют ситуацию, то есть являются поступками, а не «просто словами»). Например, работы по инженерии предприятия⁷² Jan Dietz с коллегами как раз основаны на теории речевых актов.

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

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

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

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

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

А пока подчеркнём, что при попытках записи каких-то методов надо бы обращать внимание на алгоритмику и её опыт.

Автор этих строк в качестве первого рабочего задания после университета (1980 год) получил задание создать язык для описания строительства здания — и не знал, что он попал в отдел, который как раз занимается проблемами AI на базе класса систем, известных как «фреймовые»⁷⁴ (кодирование методов в структурах данных для «стереотипных ситуаций»). Постановка проблемы была примерно такой: «давай опишем алгоритм строительства дома на каком-то языке. Но мы знаем продолжительность каждой операции и требуемые ресурсы — для этого у нас есть СНиПы, строительные нормы и правила. Затем мы просто посчитаем длительность стройки в компьютере. Так что дай нам соответствующий язык описания». Конечно, в головах у всех в 1980 году был именно императивный подход к таким описаниям — который доблестно провалился, поэтому и обратились к фреймовому подходу в AI. Но как описывать эти «фреймы» и как находить их в жизни? Попытки сначала сделать язык для чего-то маленького (конечно, автор через пару недель попытки описания стройки понял, что проблема пока никому не по зубам, хотя за неё брались многие — но был молод и не отчаивался, поэтому просто решил пойти через решение более простых проблем), например, сделать язык формального описания для книг кулинарных рецептов, тоже ни к чему не привели. И только после многих лет автору стало понятным, почему всё было так плохо и почему идеи методологии трудно показать в их формализме на уровне, достаточном для автоматической/машинной реализации метода (а ведь вся цифровая трансформация — она про это!):

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

• Метод описывается алгоритмом, а алгоритм — это одновременно и теория, для объяснения надо разбираться в конструктивной математике, соответствии Curry-Howard и прочих основаниях математики и computer science.

• Более того, это не просто алгоритм действий с данными, а алгоритм действий в реальном мире, и это тоже трудно понимается. Речь идёт об идее 4E (extended, embedded, embodied, enactive) cognition⁷⁵, и это алгоритмы роботов с датчиками и актуаторами (станка с ЧПУ в простейшем случае), а не алгоритмы классического компьютера. Иногда это алгоритмы, реализуемые вычислителями на мокрой нейронной сетке (у людей) и задействующие сложные инструменты (станки), и ещё и многоуровневые (скажем, ваш заказ пиццы по каким-то методам в пиццерии обрабатывает довольно много людей и компьютеров, а также довольно много разного кухонного оборудования). Об этом трудно думать как-то в общем виде. Но именно такие размышления «в общем виде» позволяют переносить найденные в одних предметных областях методологические решения в другие предметные области. В частности, в ходе цифровой трансформации надо как-то сдвигать выполнение работ с физических двойников на цифровые двойники (например, подстройку режимов работы), а с людей на роботов. Это требует единообразного описания методов работы софта, людей, станков и даже AI-агентов.

• Трудность ещё и в том, что разложение алгоритма представляется как код — и понимание разных парадигм этого разложения алгоритма трудно, с мультипарадигмальным программированием с трудом справляются и профессиональные программисты. Автор этих строк знает огромное число программистов, которые в начале своей работы буквально страдали, пытаясь писать объект-ориентированно, но выдавая императивный код, а когда речь шла о переходе на функциональное программирование, например программирование на Haskell, имели вообще непреодолимые трудности. Даже если прорваться через типизацию объектов (что тоже проблема для многих людей — поэтому-то и нужно использовать трюки типа «онтологического дребезга» и всякие другие альтернативные интерфейсы к мокрой нейросетке новоявленного методолога), то прорваться через функциональную парадигму будет очень трудно. Та же печальная судьба трудностей в изучении постигла средства логического программирования (прежде всего Prolog, но дальше и Agda⁷⁶, и Coq⁷⁷ — они считаются ещё более трудными в изучении, чем средства функционального программирования, ибо могут рассматриваться и как функциональные языки, и как логические языки с зависимыми типами⁷⁸). Радикальное решение тут — сразу учить конструктивизму, конструктивной математике, теории категорий, гомотопической теории типов. Но это оказывается ещё труднее, чем учить распространённым функциональным и логическим языкам программирования. В любом случае, пошаговые представления метода хорошо применимы в мизерном количестве случаев, сама методологическая/функциональная действительность требует функциональных/декларативных представлений, а не императивных/процедурных. Рабочий процесс какого-то завода нельзя разложить на более мелкие рабочие процессы — и так довести это разложение до рабочих процессов, выполняемых отдельными людьми, если использовать идею «пошагового выполнения процесса», ничего не получится.

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

Например, по данным Американской ассоциации психологии с 1993 года было опубликовано около 39000 новых конструктов и 43000 новых методов⁷⁹. Более половины этих методов никогда не использовались за пределами своей первоначальной статьи, в которой они были представлены. Можно поглядеть, как выглядит картинка «методов в психологии» — интерактивная карта со ссылками на оригинальные описания предложенных методов психологической работы⁸⁰.

Это дополнительная сложность для прикладных методологов: если вы хотите как-то связно рассуждать про «методы в психологии», то вам надо понять, как вообще этому многообразию методов учить, как понять, что там важно, а что не очень. Распространённость методов тут не очень поможет. Так, теория флогистона и теория эфира когда-то были в физике тоже чрезвычайно распространены вместе с базирующимися на них методами описаний мира, а термодинамика едва-едва появилась, и была крайне контринтуитивна в понимании. Впрочем, и сейчас можно утверждать, что термодинамика контринтуитивна, идеи флогистона и эфира много легче в понимании, но термодинамические расчёты работают, а расчёты по теориям флогистона и эфира — нет. В случае теорий менеджмента или теорий психологии так однозначно сказать о работающих или не работающих методах — нельзя.

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

В этом месте любой человек, разбирающийся с методологией вообще и методологией прикладной предметной области говорит "Ааааа!" и хватается за голову. Много легче жить, когда просто не знаешь о всех этих трудностях. Как обычному человеку совладать с таким объёмом знаний в каждой предметной области, как стать методологом какой-то прикладной предметной области? Этот вопрос остаётся открытым.

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

Задание: разложение метода вашей работы

Поставьте отметку о выполнении:

1. Написан пост о представлениях метода работы по материалу первого раздела. Что так и осталось непонятным? Что оказалось контринтуитивным? Что вам удалось уже применить в рабочих проектах?

2. Написан пост о методе вашей собственной работы. Для этого определите, какая работа занимала у вас основное время на прошлой неделе. Опишите метод/способ, которым вы делали эту работу — и используйте для этого какие-то представления из текущего раздела нашего руководства.

2. Создание и развитие: не жизненный, не цикл

Биологический жизненный цикл, нулевая версия

Поскольку системный подход поначалу развивался на примерах относительно простых физических, а затем (фон Берталанфи был биологом) сложных биологических систем, то часть его терминологии осталась с времён зарождения общей теории систем. Вот сборник работ фон Берталанфи, 1940-1968, это как раз про первое поколение системного подхода:

Так, биологи хотели найти подходы к обсуждению таких сложных объектов, как заливной луг со всеми его взаимосвязанными сотнями видов растений, животных и сменой времён года — а слов для этого обсуждения не было. Они эти слова придумали, например «жизненный цикл». Вот жизненный цикл печёночного сосальщика⁸¹:

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

В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так (если игнорировать время эволюции/развития систем как вида):

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

• Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Даже роботы не живородят, не формируют личинок и куколок, не проходят метаморфозов! Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.

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

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

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

Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы

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

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

Назовём это понимание «жизненным циклом v1.0»⁸², оно разрабатывалось где-то в 70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте, который в те времена считался более-менее «психологической» особой дисциплиной, а не просто изводом системной инженерии для организационных систем. В системном подходе уже тогда признавали непосредственно выходящими из него не только системную инженерию, но и operations research/исследование операций⁸³ — исследование работ/operations с целью принятия лучших решений по ускорению их прохождения. Исследование операций скоро перестало быть «аналитикой», то есть только исследованиями, и в его синтетической/управленческой ипостаси стало operations management (операционное управление, акцент не только на понимании и отчётах, но и на действиях на основе этих исследований — собственно управлении, изменении ситуации в части ускорения прохождения потока работ через производящие эти работы ресурсы).

Дальше это направление управления работами/операционное управление/операционный менеджмент на базе каких-то представлений тогдашнего системного подхода развилось в классическое проектное управление/project management, как его понимают сегодня в менеджменте (хотя к нему кроме собственно управления операциями добавилась сегодня ещё и организация команды проекта, это подробней объясняется в руководстве по системному менеджменту⁸⁴). Мы же считаем операционный менеджмент эксплуатационной (то есть происходящей с уже созданной системой) инженерией организационной системы.

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner «Project Management: A Systems Approach to Planning, Scheduling, and Controlling». То есть управление проектами в момент его появления было применением системного подхода к планированию, построению графика работ и контролю выполнения работ. Это похоже на то, как понималась в те времена и классическая «железная» системная инженерия: применение системного подхода к инженерной работе.

Конечно, использование системного подхода в менеджменте не ограничивается сегодня только операционным управлением. По сути, весь менеджмент как специализация системной инженерии для создания и развития организаций строится на базе системного подхода. И это уже был системный подход второго поколения, которое ассоциируется главным образом не с работами фон Берталанфи, а с более поздними работами по «мягким системам» (soft systems), под которыми понимались прежде всего системы-создатели из людей с их инструментами. К таким системам из людей (организациям) оказались неприменимы жёсткие требования «как к железным системам», которые были характерны для системного подхода первого поколения, рассматривавшего главным образом какие-то не слишком живые целевые системы, но не граф создателей из людей и их коллективов. Графы создателей (хотя и в чуть другой терминологии) с их коллективами и менеджментом как «инженерией организаций» — это уже предмет второго поколения, наиболее характерны там работы Питера Чекланда. Вот его сборник работ в соавторстве с Jim Scholes, 1972-1981:

Понятие жизненного цикла 1.0 как времени производства работ создателя с создаваемой целевой системой (о цепочках создания речь не заходила) активно разрабатывалось и в системной инженерии, и в менеджменте, а именно — в классическом проектном управлении (project management) для принятия решений о планировании и составлении графика работ в инженерных проектах.

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

Так что работа — это Анастасия забивает гвозди молотком в доски 16 мартобря 2028. Забивание гвоздей 16 мартобря — это и есть работа, которую она выполняет, а Анастасия, молоток, гвозди, доски — это всё ресурсы, которые должны провзаимодействовать в момент работы и поэтому должны наличествовать. Нет ресурсов — нет работы. Так что управление работами (work/operations management, операционное управление) сводится к тому, чтобы оптимально распорядиться ресурсами: выполнить максимальное количество работ с минимальными ресурсами. Как? Например, вы можете пригласить Анастасию забивать гвозди на один день — 16 мартобря 2028, заплатить за один день. А можете пригласить на месяц и договориться платить зарплату месяц, а задействовать только один день — 16 мартобря 2028. Можете закупить гвозди и доски за два года до планируемой работы, а можете закупить так, что они прибудут сразу 16 мартобря 2028 и даже не успеют попасть на склад, а будут выданы сразу «в монтаж» Анастасии. Операционное управление, цепочки поставок (supply chains), логистика, исследование операций — всё это методы максимизирования прохода/throughput работ и предметов метода по какому-то графу создателей за счёт снятия логистических (ресурсных, в том числе транспортных, то есть наличия ресурсов для работ вовремя) ограничений.

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

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

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

В мире принято платить не столько за работы, сколько за результаты работ. Если платят за работы, то как-то само собой получается, что результатов нет и нет, а работы становится больше и больше — скажем, у врачей есть проблема лишних назначений, ибо им платят не за то, что они вылечивают, а за то, что лечат. Мы не будем рассматривать такие ситуации. Так что операционное управление в типовом случае занято максимизацией прохода/throughput: выпуск предметов общего метода работы организации за пределы организации — и за каждый выпущенный предмет метода поступает оплата. Больше продукта в выпуске (то есть растёт скорость выпуска, «проход» — выпуск единиц продукции в единицу времени, первая производная по времени) — больше оплата (то есть растёт скорость «впуска» оплаты). Максимизируем проход как «скорость выпуска» (то есть максимизируем проход работ и предметов работ по графу создателей), тем самым максимизируем скорость прихода оплаты**. Работы характеризуются не тем, чтобы выполнить побольше работ, а тем, чтобы выполнить работ поменьше, но выпустить продукта (включая чужого, ситуация сервиса) побольше. Целью операционного менеджмента является максимизация прохода/throughput при минимизации задействования ресурсов.**

Если у вас сдельщина по результату работ — будет мало работы, много результатов. Если сдельщина по самой работе, то будет много работы, а результатов работы — мало, значительная часть работ будет бесполезной.

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

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

Операционный менеджмент и методология.

В общей теории систем фон Берталанфи предложил operations research как науку, изучающую работы/operations в части их производительности/скорости. Проход как раз замеряется в единицах скорости, первой производной чего-то по времени. Проход — это первая производная объёма выходной продукции по времени — штуки для дискретной продукции или объёмы для непрерывного производства (химическая промышленность) в малую единицу времени, dx/dt. Единица времени должна быть малой, чтобы это было настоящей производной. Если единица времени большая, то менеджмент, по большому счёту, невозможен. Если вы хотите выпустить 500 штук продукции в год — то сколько надо производить в день? Весь год ничего и брать кредиты, а потом в последний день 500 штук? Или каждый день по паре штук — и иметь даже запас на случай сбоев (хотя что там про выходные дни, сколько их будет)? Если равномерный выпуск и оплата, тогда и кредиты брать не надо. Замеры должны быть точными, это означает, что дискретизация замера прохода должна быть поменьше, вы должны знать «ускоряемся» или «тормозим» не раз в год.

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

• Нужно рассматривать операционный менеджмент как методы работы в предметной области работ с задействованием ресурсов, изучаемый прикладной методологией.

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

Вот это второе положение требует некоторого пояснения. Скажем, вы занимаетесь спасением тонущего корабля, при этом у вас есть методологическая проблема: каким методом надо действовать, чтобы спасти корабль? Классический пример тут — вам не надо заниматься методами мойки палубы корабля, нужно заняться чем-то важным. Важное тут — увеличить скорость спасательных работ, а все остальные работы можно делать по остаточному принципу, ибо они ситуацию не улучшат. Можно даже палубу драить, если есть свободное время. Но только если есть свободное от спасения корабля время!

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

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

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

Поясним это чуть подробней — но по-настоящему подробные наставления будут в руководстве по системному менеджменту. У операционного менеджера главный интерес — сделать рывок, то есть увеличить ускорение прохода (а проход — это скорость выпуска). Он должен постоянно (так и говорят: процесс непрерывных улучшений, POOGI, process of On-Going Improvement) поднимать throughput/«проход» как скорость выпуска целевой системы, замеряемую на выходе предприятия (включая склады, ибо непроданные системы нам не нужны, за них не будет заплачено). В одну сторону (от поставщиков сырья или исходной информации) текут потоки вещества, информации, работ и вытекают из фирмы к клиентам, а в другую встречным потоком текут деньги, из которых происходит оплата за каждый ресурс, проводящий обработку потока.

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

Можно, конечно, вечно «тушить пожары». Но правильно было бы отследить причинно-следственные отношения и убрать сам источник пожаров, сделать «распожаризацию»: пожаров нет, потому что нет поджогов, все всё успевают.

Как выполнять «распожаризацию»? Тут есть следующие логически последовательные шаги, в которых тесно переплетены работы с методом (предмет методологии) и работы с работами (предмет операционного менеджмента):

1. Нужно выполнить инженерную работу по принципам Lean/элегантности, так в бизнесе называют физический принцип наименьшего действия. То есть первым делом надо найти то, что можно не делать — и при этом риски что-то ухудшить в характеристиках целевой системы или величине прохода останутся более-менее приемлемыми. Учтите, что вы сейчас собираетесь резко ускорить работу (даже если у вас главная задача выпустить новый продукт хоть в каком-то единичном объёме — то это будет ускорением работы: проход был нулём, стал ненулевым. Но каким ненулевым? Одна система в сутки? Одна система в месяц? Одна система в год? Одна система в десять лет? Надо это оценивать количественно). Ненужную работу не нужно ускорять, она вредит делу! Поэтому просто перестаньте эту работу делать. Более точное выражение тут — не выполняйте работы по какому-то ненужному методу. Элон Маск как-то сделал замечание, что если вам не приходится возвращать одну из десяти убранных работ, то вы слишком мало убираете ненужных работ: ищите их тщательней! Это инженерная, содержательная работа, и важны тут не сами работы, которых может быть множество, а важны методы работы. Надо перестать делать работы по какому-то ненужному методу, для этого понять, какой метод ненужный. Это методологическая работа, работа с методами. Дальше с тем же количеством ресурсов вы просто будете делать меньше работы, и дело пойдёт быстрее.

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

3. Дальше устраняем wait time, время пауз в работе. Устранение пауз в работе делается методами операционного менеджмента. Паузы в работе могут быть больше или меньше просто от того, что вы начинаете или пять работ в параллель и делаете их «вперемешку», или делаете все эти работы последовательно (мультитаскинг), запускаете работу «в последний момент» (поздний старт) или «как только будут наличествовать ресурсы» (ранний старт). Операционный менеджер минимизирует время пауз в работе путём рационального планирования. Терминология (например, «время ожидания», wait time) тут отличается от терминологии разговора об элегантности и разговора об управлении конфигурацией, ибо отличается набор понятий. Мы дальше берём терминологию метода операционного менеджмента TameFlow⁸⁵, которая по большому счёту и отражает SoTA в операционном менеджменте, ибо кроме управления промышленным производством (manufacturing) имеет дело с управлением разработкой — это недавнее введение в операционном менеджменте. В этом третьем шаге речь идёт о собственно работе операционного менеджмента, а не о методологической работе, не инженерной работе. Без предыдущих двух пунктов методологической работы в «распожаризации» использование TameFlow или любых других видов метода операционного менеджмента будет вредным! Вы резко ускорите беспорядок! Будет не просто хаос и пожары на работе, а крайне быстрый, ускоренный хорошим операционным менеджментом хаос и пожары! Операционные менеджеры вредны, если они хорошо делают свою работу без предварительной работы инженеров целевой системы и инженеров предприятия, занимающихся методологией разработки. «Устранение времени пауз», предотвращение «пробок» в работе, поддержание стабильного скоростного потока — это и есть операционный менеджмент, работа с работами, а не методами работ. Логически это только третий шаг! Если вы занялись организационными реформами, то начинать надо с методологической работы, это уже даст резкое ускорение. И только потом можно говорить об ускорении работ за счёт собственно практик операционного менеджмента.

4. После того, как вы добились успеха в устранении времени пауз (там очень, очень много нюансов, для их понимания нужно читать специализированные учебники операционного менеджмента, в руководстве по системному менеджменту будет рассказано, какие учебники надо читать, и там не только литература по TameFlow), вам нужно опять обратиться к методологии: заняться уменьшением времени обработки рабочих продуктов на определённых операциях (touch time), которые будут вам даны по итогам предыдущего шага. Для этого вы должны выбрать новые методы работы, которые дадут вам сокращение времени обработки. Например, автоматизировать какие-то операции. Важно, что не нужно сокращать время любых производственных операций, а только находящихся на критических местах в потоке работ — вся арифметика для нахождения этих мест вами будет выполнена на предыдущих шагах. И это опять будет инженерная задача, которая потребует методологических (по изменению метода работы) решений по существу инженерного вопроса, а не чисто менеджерская задача по распределению работ по ресурсам и учёту выполнения этих работ. Именно тут требуется продемонстрировать, почему вы вдруг занялись новыми методами работы вот прямо сейчас: как это отразится на проходе/throughput? Если никак, то вы занимаетесь не той методологической работой!

5. Не давайте инерции себя остановить! Вернитесь к пункту 1 и повторите всё с самого начала: выкиньте работы по ненужным методам — то есть прямо уменьшите число работ, наладьте управление конфигурацией (операционный учёт) — это высвободит ресурсы от многочисленных переделок/re-works, далее займитесь действиями по уменьшению времени пауз в работе, а затем вернитесь в расчётах к работам, где надо вернуться пересмотру их методов, чтобы сократить время работы за счёт изменения способа работы. Но это в самом конце, когда уже известно из расчётов (буквально: из арифметики), время каких работ надо уменьшать, а затем надо выполнить организационное изменение: перейти на работу по новому методу, и дальше вернуться к пункту 1 — не давать инерции остановить себя однократным прохождением цикла.

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

За забивку гвоздей у нас ответственна Анастасия в должности «плотник» (не путать с оргролью «плотник»), и обычно она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3 мартобря 2029 года, и планируемая её продолжительность — десять минут. За это время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места на досках.

Работы легко наблюдать: это просто взаимодействующие между собой ресурсы (включаемые в работу по отношению участия/participation, это такая специализация отношения composition/состава/is_part_of/часть-целое), но взятые не только как объёмы в пространстве, но и протяжённые во времени. Так, работа по методу «забивка гвоздя» представляет собой поведение взятых на интервале 30 секунд молотка, гвоздя, доски и забивающего их работника как конструктивных объектов. Их нужно собрать вместе на эти 30 секунд, чтобы они провзаимодействовали, то есть поучаствовали как ресурсы в этой 30-секундной работе. Если будет забито 180 гвоздей за час, то это 180 работ по методу с сигнатурой «забивка гвоздя».

Обсуждение работ обычно является предметом операционного менеджмента и затрагивает логистический предмет интереса: времени прохождения потока работ. Интересует тут не столько содержание работы (это обсуждается как метод/практика/способ работы/way of working), а как задействовать для этой работы имеющиеся ресурсы, чтобы получить оптимальное время прохождения потока работ (не всегда минимальное, ибо иногда важней равномерность задействования ресурсов, чем именно минимальное время выполнения, требующее обычно очень неравномерной загрузки ресурсов).

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

Жизненный цикл 1.0 — это работы создателей над создаваемой системой

Понятие жизненного цикла системы в его исторически первой инженерной версии (инженерный жизненный цикл 1.0, биологический жизненный цикл тут будет как нулевая версия) как последовательность крупных работ-стадий тем самым отражает аспект операционного менеджмента, представления классического проектного управления.

Проект — это в классическом проектном управлении работы оргзвена как группы организованных (то есть с понятными полномочиями по распоряжению трудом, материалами и прочими ресурсами) агентов биологических и не очень, с каким-то оборудованием и материалами, полномочиями по проведению работ (то есть проект — это даже не работы оргзвена, а работы оргвозможности/capability — оргзвена, которое назначено на роли и имеет полномочия по выполнению работ по методам этих ролей и имеет все необходимые ресурсы для этого).

Проект имеет целью его работ (хотя тут более корректно говорить о цели оргзвена или даже оргвозможности, «цель работ» тут — метонимия⁸⁶) обычно создание и развитие какой-то системы (иногда по длинной цепочке/пути в графе создателей). Дальше мы будем считать, что если речь идёт об оргзвене, то оно уже достигло состояния оргвозможности — все умения, ресурсы и полномочия по распоряжению ими оргзвеном уже получены.

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

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

Чтобы собрать какую-то нужную нам (целевую, думаем о времени эксплуатации/использования) конструкцию из досок, нам нужно создать проект/project — организовать создателя::оргзвено на выполнение работ по сборке конструкции. Оргзвено (создатель, думаем о времени создания конструкции из досок как целевой системы) состоит из модулей Анастасии-с-ответственностью, молотка, 20 гвоздей, четырёх досок. Нам нужно ещё запланировать эти все ресурсы на 20 минут, иначе работы не случится. Это всё менеджерские работы: проекты создают и затем ими управляют (то есть управляют последовательностью выделения ресурсов на работы — возможно, привлекая временно свободные ресурсы из других проектов) менеджеры (создатели и операторы эксплуатации организаций).

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

Операционного менеджера не интересует «каким способом происходит работа, почему она даст результат», как вообще нужно забивать гвозди, и почему нужно скреплять доски гвоздями, а не склеивать их, или вообще приматывать их друг ко другу верёвками, и не интересует, как сделать гвоздевое соединение прочным. Метод ему «по роли» не важен. А раз так, то по работам бесполезно обсуждать, как же именно эти работы в их взаимодействии будут двигать целевую систему, да и все остальные системы по их состояниям в ходе создания и развития системы. Обсуждение работ не связано с функциональностью/методами и ролями исполнителей этих работ, оно связано с планированием ресурсов и контролем выполнения плана: минимизацией времени прохождения потока работ при минимально задействованных ресурсах, это типовое предпочтение операционного менеджера. Для обсуждения «как работать» нужно обсуждать не работы, а методы работы!

Обратите внимание, что по факту «жизненный цикл системы X» ничего не говорит о самой целевой системе X и её состояниях. Он говорит про то, что делают системы создания X: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «болезни», case file — это папка «Дело №__» или в медицине папка «истории болезни», то есть описание работ дела/случая/ситуации/болезни). Запоминаем: кейс — это работы, только для этих работ не всегда известен план, а в самом начале этих работ часто известна сигнатура («вылечить больного», «раскрыть дело, наказать преступника»), но неизвестно ещё разложение метода, поэтому и планирование этих работ up front (перед проведением работ) невозможно, оно проводится после каждого шага работ. Судебные дела, лечения, исследования, отладка/troubleshooting/debug, проектирование — всё, что требует высказывания и проверки гипотез — ведётся «непрерывно открывающимися обстоятельствами», для планирования каждого шага работ используется свежеполученная от предыдущих шагов работы информация.

В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) — это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс::работа будет назван по его предмету — «гвоздь» (предмет этих работ, который нужно привести в конечное состояние «забит». Если предмет работ не гвозди, работы — «забивание гвоздей», а доски с работами по скреплению досок заранее непонятным методом, то кейс будет «доски», приводимые в состояние «скреплены»). Описывает вариант с заранее непонятным планом работ вид «операционного менеджмента»::метод, известный как case management. «Case management»::метод, в свою очередь, род для разных его видов, например adaptive/dynamic/advanced case management⁸⁷, который в последнее время перестал быть в силу общей распространённости отдельным компактно излагаемым вариантом метода case management со специальным софтом его поддержки. Само операционное управление теперь связывается с case management — вплоть до того, что классическое проектное управление с up front планированием считается частным случаем кейс менеджмента (ибо редко бывает, что состав работ заранее известен и возможно составить качественный план), а управление работами по этому методу называется «проектное управление». Поддержка со стороны программного обеспечения перешла от специализированных систем проектного управления в системы с облегчённым программированием, универсальные моделеры, LowCode⁸⁸. Так что сегодня «проектом» называют то, что ещё вчера было более-менее крупным кейсом (работы, названные по имени предмета кейса, предмета работ — то, что надо привести в какое-то конечное состояние). Значение слова «проект» окончательно оторвалось от классического «проектного управления».

В биологическом жизненном цикле в дикой природе любое яйцо или гусеница создают сами себя, «сами себя создатели». В инженерии, если я сам подстригаю себе ногти, меня будут моделировать во множестве ролей — создатель, выполняющий работы (выполняющий кейс «красы ногтей»⁸⁹), а также владелец ногтей, плюс тело как ближнее окружение ногтей. В «Инженерии личности» дан пример агента, который пришёл учиться — у него множество самых разных ролей, ученик только одна из них.

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

Методология использует системное мышление и смотрит на оргзвенья/предприятия/команды/коллективы/организации::создатели точно так же, как смотрит на любые другие системы:

• Как на функциональные объекты, и видит их как набор оргролей, которые «задействуют методы работы»/«предоставляют сервисы».

• Как на конструктивные объекты, и видит их как оргзвенья, в ходе их использования «выполняющие работы»/обслуживающие (а уж по какому методу там работает этот конструктивный объект — дело десятое. Конструктивное представление стремится абстрагироваться от метода получения результата работы. Один из изводов исследования операций — теория массового обслуживания, она же теория очередей⁹⁰).

• Они занимают место в пространстве-времени.

• У них тоже есть полная стоимость владения.

• … и на них можно ещё смотреть очень по-разному, в зависимости от проекта.

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

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

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

Итак, Анастасия, предоставляющая сервис забивки гвоздей, берёт свой молоток и забивает выданный ей гвоздь №143 в доску #26, то есть выполняет работу. Жизненный цикл гвоздя в представлениях прошлого века (первое поколение, 1.0) состоит уже не из состояний гвоздя («лежит в коробке», «взят в руки», «нацелен», «забивается», «забит»), а происходящих с ним работ, которые, конечно, можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем создания, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном не цикле принят аналог «аристотелевской физики», где палец давит на стол, а стол не давит на палец. Работают создатели, а гвоздь в ответ не работает, он пассивный объект для систем создания, он просто меняет состояния по мере выполнения с ним работ, «претерпевает изменения».

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

• Обнаружение потребности в гвоздевом соединении. «Гвоздь запланирован» — но Так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE2⁹¹, это хорошая практика именования. Помним, что «большой кейс называют проектом», а уж связь кейс-менеджмента и проектного менеджмента будет рассказана подробней в руководстве по системному менеджменту. И обратите внимание: тут объект — не гвоздь, а соединение (гвоздевое соединение — надсистема, в состав которой входит и гвоздь, и те объекты, которые он соединяет).

• Закупка. «Гвоздь закуплен» — помним, что в жизненном цикле 1.0 волнуют работы, а не состояния гвоздя! Состояния гвоздя волнуют тогда, когда обсуждаем целевую систему и прохождение ей различных состояний в ходе жизненного цикла — то есть прохождение различных состояний в ходе работ с целевой системой. Состояние «гвоздь закуплен» тут указывает на результат выполнения работы закупки гвоздя, сама работа тут — «закупка». В названии работы её и указывали, и даже слово «гвоздь» забывали указать, сокращали даже «закупка гвоздя» до просто «закупка». Операционные менеджеры любят обобщать, когда пишут о работах, их не волнует содержание работы и специфика этой работы: только ресурсы и время.

• Выдача в монтаж. «Гвоздь доступен в месте забивки» — указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).

• Нацеливание гвоздя. «Гвоздь нацелен».

• Вколачивание гвоздя. «Гвоздь вбит».

• Проверка крепости соединения. «Гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем. Но можно и «проверка удержания гвоздём».

• Эксплуатация соединения. «Соединение держит и стабильно при нагрузках», можно отдельно обсуждать смену предмета. Но можно и «Гвоздь держит, удержание стабильно при нагрузках», это будет «эксплуатация гвоздя» (до этого было только изготовление гвоздя, доведение его до состояния «гвоздь что-то скрепляет».

• Вытаскивание гвоздя. «Гвоздь вытащен».

• Ликвидация гвоздя. «Гвоздь выкинут» — прослеживаем судьбу предмета работ вплоть до его исчезновения, идея жизненного цикла «от рождения до смерти».

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

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

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

Моделирование: предметы кейса, их состояния, практики достижения состояний

Опираясь на пример с гвоздём, выпишите пять каких-то предметов кейсов (предметов работ) для вашего рабочего проекта, наборы состояний этих предметов и методы, которые приводят предметы кейса в эти состояния. Не забудьте проверить, забыли ли вы какие-то состояния до и после тех, что вы записали сходу.

Управление последовательностью работ

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

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

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

Конечно, чтобы работы были выполнены, надо ещё создать организационную возможность (capability):

• У оргзвена есть мастерство выполнения метода и все необходимые инструменты и материалы.

• У оргзвена есть полномочия выполнять работы по методу (то есть выполнять оргроль).

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

Конечно, в организационном контексте не так часто говорят слово «метод», но используют самые разные другие синонимы. Часто, например, говорят «практики» (practice), не менее часто используют и понятие «рабочие процессы» и даже кривой термин «бизнес-процессы» (в западных стандартах по IT рекомендуют business process менять на organizational или organization process в зависимости от того, что принято, на русском это «оргпроцессы» или «административные процессы»). Давайте предыдущий абзац про создание оргвозможностей повторим, заменив «метод» на синоним — «рабочий процесс».

«Конечно, чтобы работы были выполнены, надо ещё создать организационную возможность (capability):

• У оргзвена есть мастерство выполнения рабочего процесса и все необходимые инструменты и материалы.

• У оргзвена есть полномочия выполнять работы рабочего процесса (то есть выполнять оргроль).

• Известно, кто может давать входы рабочего процесса и известно, кому отдавать выходы (если это конвейер, то принимать работу нужно от одних оргзвеньев, а отдавать её — другим)».

Это не два одинаковых абзаца! Как видите, кажется, что ничего не изменилось, но «предметы метода на входе» были согласно традиции обсуждения рабочих процессов названы входами/input, а предметы метода на выходе метода названы выходы/output: замена терминологии. При этом мы свободно говорим про мастерство выполнения метода/«рабочего процесса» оргзвеном, ибо минимальное оргзвено — это один человек, но это может быть и какое-то подразделение или даже коллективный орган (скажем, собрание акционеров какого-то предприятия, научно-технический совет, комиссия, рабочая группа проекта) или даже какое-то предприятие (скажем, предприятие, входящее в холдинг — «дочернее или зависимое общество»).

Обсуждение оргзвеньев идёт как конструктивов:

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

• Как из оргзвеньев на каких оргинтерфейсах собирается вся организация как целое (из каких конструктивов на каких интерфейсах собирается целая система, как её собрать без лишних зависимостей, задача архитектора), как там работает логистика.

• Как сделать так, чтобы сотрудничали: чтобы оргзвенья выполняли работы, а не артачились, задача лидера.

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

• Как сделать так, чтобы умели работать по методу (было мастерство сотрудников)

• Как сделать так, чтобы наладить управление работами, чтобы всё было вовремя (ресурсы были, старт работ был оптимальный).

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

В подходе к описанию предприятий DEMO⁹² (подробней будет в руководстве по системному менеджменту) каждая работа проходит следующий цикл взаимодействия оргзвеньев:

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

• Работа принята к исполнению оргзвеном-исполнителем, это тоже координационный акт.

• Работа выполняется оргзвеном-исполнителем. Это производственный акт (production act), реальное выполнение работы. Именно это учитывается в жизненном цикле целевой системы, над которой выполняется работа. В жизненном цикле обсуждаются только производственные акты, а не координационные акты! Учёт координационных актов и требуемых на них трат ресурсов и задержек времени на «согласование» и «выдачу поручения» (иногда нужно год интенсивно работать, чтобы получить разрешение на пятиминутную реальную работу) ещё ждёт адекватного отражения в методологии. Пока же это рассматривается в дисциплине рациональности как «рациональное принятие решений» на базе теории принятия решений⁹³.

• Результаты работы предъявлены к приёмке оргзвеном-исполнителем, это координационный акт.

• Результаты работы приняты оргзвеном-инициатором работы, координационный акт.

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

Деление на координационные и производственные акты в обсуждении работ важно, чтобы делать правильные оценки времени на выполнение работы: от момента затребования работы до момента принятия результатов работы на координационные акты легко может уходить до 60% времени, и только 40% времени на проведение самой работы, а в случае знаниевых (проектных, а не изготовления физического воплощения) работ это может быть и 80% на 20% в среднем, ибо работы по «обоснованиям решений о том, что надо сделать» очень трудоёмки сами по себе: надо не просто запросить работу, но и обосновать то, что её надо выполнить (это может быть более трудоёмко, чем сама работа!), и надо не только предъявить результаты работы, но и обосновать то, что эти результаты приемлемы.

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

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

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

Как планировать работы — по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами (проектного управления, управления процессами, управления программами, управления кейсами — тут тоже изобилие синонимов) отвечают на этот вопрос по-разному. Управление работами как раз занимается планированием работ и контролем выполнения работ, где работы — это поведение оргзвеньев/оргединиц. Управление работами не обсуждает то, как правильно выполнять работы создателей так, чтобы они меняли создаваемую и развиваемую систему в нужном направлении (т.е. без обсуждения оргролей и их методов работы).

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

Оргзвенья играют оргроли, оргроли реализуются/воплощаются оргзвеньями (функциональные объекты реализуются конструктивными, это отношение реализации/воплощения, помним 4D экстенсионализм). Оргроли выполняют методы работы (функциональное/ролевое/ «прикладное инженерное»/содержательное рассмотрение), а оргзвенья выполняют работы по методам (конструктивное/логистическое/«операционного менеджмента» рассмотрение).

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

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

Помним: геном и мемом — это наследуемый материал (гены в ДНК и мемы на каких-то носителях информации, например в PLM-системе⁹⁵ в машиностроении или репозитории кода в программной инженерии), а феном — это проявленный в организме наследуемый материал. Техноэволюция идёт быстро, и в жизненный цикл (то есть не жизненный и не цикл) заодно попали стадии/работы, в которых идёт работа по получению и развитию мемома (иногда в промышленности это идёт как «проектная документация») целевой системы, проекта/design целевой системы. Слово «проект» в русском языке имеет не только значение проекта/project::работы по созданию системы, но и значение проекта/design как мемома создаваемой системы, то есть описания ещё не реализованной системы. Мы будем отличать проект-работы и проект-описание-системы как проект/project и проект/design. В жизни нужно различать эти значения, как обычно — по контексту, смотреть на «что хотели сказать», а не на употреблённый термин. В трудных случаях — переспрашивать. На вопрос «ты сделаешь мне проект сепульки?» надо уточнять — сделать только описания системы (design), или вообще сделать саму сепульку (project) — как описания системы, так и изготовление самой системы?

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

Целевая система осталась только как «объект проекта», объект для группы работ, объединённых понятием «жизненный цикл объекта проекта»: указание того, над чем идут эти работы жизненного цикла. Иногда вместо проекта появлялись и более мелкие деления работы — кейс/case (из управления кейсами: аналог проектного управления, не требующий up front планирования, позволяющий планировать «на лету») или управления задачами/task (как правило, это то же самое, что управление кейсами, разница в нюансах).

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

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

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

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

Итак, жизненный цикл создаваемой системы в версии 1.0 означает просто последовательность работ, которые производят создатели этой системы.

Изображались такие жизненные циклы 1.0 с периодизацией работ очень просто: такими «колбасками», в которых поминались производимые последовательно крупные работы каких-то периодов времени внутри периода времени всей работы. Эти крупные отрезки времени внутри всего времени работ по изменению состояний системы были названы стадиями/фазами жизненного цикла. Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288, и обратите внимание на то, что каждое название стадии там говорит о работах создателей, а не о состоянии создаваемой системы (хотя иногда и случаются наименования состояния, но они используются как альтернативное название проводимых работ для достижения этого состояния, в духе положений PRINCE2 о том, что работы лучше бы называть по их результату как выполнению метода — конечному состоянию предмета метода):

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

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

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

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

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

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

Сам термин «жизненный цикл», данный без уточнений, всегда означает «полный», то есть от работ создателей по замыслу до работ по «прекращению существования»/ликвидации/уничтожению/списанию/«выводу из эксплуатации» проэксплуатированной целевой системы. Это всё работы создателей, а не создаваемой системы: целевая система себя не замысливает, это создатели её замысливают! И то же с другими стадиями, системы обычно сами себя не создают, не эксплуатируют, не ликвидируют.

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

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

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

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

• посетитель/зритель, любитель/отслеживающий, зашедший на вебсайт,

• читатель содержания вебсайта, а дальше совсем уж специфическая терминология

• lead — возможный клиент, можно передавать от службы маркетинга как сервис-провайдеру «ловли и уговоров» потенциального клиента службе продаж как сервис-провайдеру продажи. Служба продажи работает с

• prospect, потенциальный клиент — и доводит его до состояния платежа,

• customer — «платящий клиент». Далее воронка расширяется, ибо мы от одной продажи переходим для одного клиента ко множеству продаж: это будет

• «возвращающийся клиент» (repeating customer) и в конечном итоге

• «пропагандист торговой марки» (brand advocate).

Как можно было бы именовать стадии наших «колбасок»? По-разному:

• По названию предмета обработки в конце такта/фазы/стади обработки или по состоянию на начало такта/фазы/стадии. В примере воронки цифрового маркетинга мы видим картинку ровно такую.

• По названию характеристики предмета работ, которую мы хотим получить на выходе обработки. В примере воронки цифрового маркетинга мы это видим «на полях» — это awareness, consideration, conversion, loyalty, advocacy.

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

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

Главное тут — это понимать, что речь идёт ровно о той же самой «колбаске» жизненного цикла в её самом примитивном понимании. Дело не меняется, если поменять «позицию восприятия»/reference index. Скажем, возьмём клиента — который будет проходить через свои обработки продвиженцами примерно так же, как автомобиль проходит через разные стадии мойки и рассказывает про свой опыт (меня почистили от грязи, намочили, намылили, смысли, промыли от разводов, высушили) из первой позиции восприятия. Или дом: «меня замыслили, спроектировали, изготовили, теперь во мне живут, скоро меня сломают». Для автомобиля и дома такое, конечно, не очень характерно. Но в службах продвижения продуктов и услуг такое появилось, но мы видим, что изменилось тут не много — это та же «колбаска» стадий⁹⁸:

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

Но тут же мы забываем новый язык с термином «путешествия» и возвращаемся к привычному «циклу» покупки⁹⁹:

Тут просто примерно сопоставили «что делает будущий клиент», «каких состояний должен достигнуть клиент», а как сопоставить обработки для этих состояний — это мы уже знаем, будет классический «жизненный цикл».

Да, всё то же самое — это жизненный цикл 1.0, хотя и с некоторыми нюансами по именованию стадий и (поскольку чуть дальше от инженерии) большей красочностью в изображении и меньшей строгостью к типам объектов в названиях стадий¹⁰⁰:

Жизненный цикл проекта

Но поскольку уже было понятно, что речь идёт о работах, а естественной максимальной (соразмерной стадиям ЖЦ) единицей работ в проектном управлении стал «проект» (project, а не design), то появился ещё один термин: жизненный цикл проекта (project life cycle) — он означал те работы полного (от замысла до ликвидирования системы) жизненного цикла, которые попадали в рамки конкретного проекта с конкретными организаторами. Проекты эти обычно совпадали с работами, проводимыми для каких-то полных стадий жизненного цикла, одной или нескольких — скажем, только разработка, только изготовление, только эксплуатация. Это называлось «естественным делением жизненного цикла», потому что разные проекты часто выполнялись разными организациями — и нужно было как-то выделять части жизненного цикла, за которые несла ответственность проводящая проект организация/оргзвено.

По факту системное мышление и «проектное управление»/«управление проектами»/«project management» (и все они вместе как части процессного управления — отсылка к процессам, понимаемым как «пошаговое выполнение работ») на первых порах так и были связаны: жизненным циклом системы (термин из системного мышления) называли происходящие по поводу создания системы работы (предмет проектного управления), а работы уже делились на проводимые в разных проектах, там делились на проходящие в разных стадиях/фазах/этапах проектов.

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

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

Особо нужно отметить о времени жизненного цикла в его 1.0 понимании:

• Понятие жизненного цикла — всегда полные работы на всём протяжении от замысла до ликвидирования системы (это влияние системного мышления)

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

• Возврат к идее цикла, ибо «жизненный цикл» будет выполняться с разными версиями системы, понятие «жизненный цикл» при этом уходит, понятие «проект» остаётся, но это будет «проект по созданию и развитию системы», ключевое слово тут «развитие», подразумевающее «эволюцию системы как вида».

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

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

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

Поскольку проект в классическом project management имеет конкретные даты начала и конца, конкретные ресурсы, то «жизненный цикл проекта» понимается просто как проект из проектного управления, а большие куски жизненного цикла, или даже полный жизненный цикл понимаются уже не как проект, а как программа (иногда даже пишут полностью программа проектов¹⁰², иногда программа работ). В проектном управлении программа — это набор проектов, посвящённых какой-то цели, но проекты из этого набора планируются по мере осознания в них потребности, а не сразу в момент старта программы.

Так, в военной системной инженерии киберфизических систем про жизненный цикл какого-то военного самолёта могут говорить как о программе этого самолёта — это ровно вот эта подмена нейтрального для самых разных практик/деятельностей/инженерий (киберфизики, менеджмента, основания предприятий/предпринимательства) понятия жизненного цикла понятием из проектного управления, которое сегодня развилось из просто project management в program and project management (иногда этот переход от «просто к проектов» к «проектам и программам проектов» называют «третье поколение проектного менеджмента», совместное мышление о программах работ и проектах как частях программы работ). При этом при переходе от проекта (от даты-1 до даты-2) к программе переходят к «открытой дате окончания» (её просто не указывают, «работы над системой можно только начать, их нельзя закончить», это неявно отражает переход к концепции «непрерывного всего», но всё-таки с удержанием идей классического проектного и программного управления).

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

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

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

«Программа партии/движения» — это ведь тоже программа работ, где создатель — коллективный агент, такой как партия/«общественное движение»::сообщество! И «Программа» уже обычно не содержит терминологии «жизненного цикла», она как-то ближе в её понимании к идеям создания и параллельного с использованием непрерывного развития системы, а не просто «задумали, спроектировали, затем родился — жил — умер».

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

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

Садовник создаёт (в данном случае замышляет, проектирует, выращивает, эксплуатирует, ликвидирует) цветок: ведёт работы по методам замысливания появления цветка в конкретном месте, посадки семечка, полива семечка, а потом и растения, удаления сорняков из окружения растения, удобрения почвы для благоприятного окружения цветка, а после цветения выведения из эксплуатации (ликвидации/выкидывания) уже отцвётшего цветка. Цветок ничего не делает сам, все работы его жизненного цикла делает его система создания в лице садовника.

Система создания цветка не часть его окружения (садовник не часть каких-то систем окружения цветка, времени эксплуатации. Если агент, играющий роль садовника и любуется цветком, то это будет другая роль, не садовника). Системы окружения (время эксплуатации!) не части создателей (время создания!), создатели не части систем окружения, они рассматриваются в разных временах. Я жарю шницель: шницель не часть меня, я не часть шницеля! Это другое отношение, отношение создания. Я рисую/описываю дерево: дерево не часть меня, я не часть дерева, я и дерево не части описания, описание не часть меня или дерева. Есть и другие отношения, кроме отношений «часть-целое»/композиции. Отслеживайте типы объектов, но отслеживайте и типы отношений, минимально это классификация, специализация, композиция, реализация/воплощение, создание. Без знания теории понятий (работа с типами и отношениями объектов) и онтологии (учение о многоуровневой нарезке мира на объекты, находящиеся друг с другом в каких-то отношениях) системное мышление невозможно!

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

TEST Жизненный цикл 1.0

Какой список содержит стадии типичного жизненного цикла (без учёта развития)?

--- Итерация 1, итерация 2, итерация 3, ... итерация N, релиз ### Нет, это просто перечисление каких-то итераций (периодов времени, когда выполняются работы по различным методам).

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

+++ Замысел, проектирование, изготовление, эксплуатация, вывод из эксплуатации ### Да, именно через эти стадии обычно проходит система в ходе её жизненного цикла (без учёта развития). Иногда эти стадии сокращали, объединяя проектирование и изготовление как «разработку».

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

--- Изготовление, эксплуатация, модернизация, эксплуатация, продление срока службы, эксплуатация, вывод из эксплуатации ### Нет, это уже не типичный и простейший, а существенно усложнённый специальный жизненный цикл, да ещё и начинающийся не с замысла и проектирования.

Петя собирается поехать на тренинг из СПб в Москву на поезде. Он решает, что надёжнее будет положить билеты и паспорт в портмоне, а портмоне убрать в сумку. Однако в метро у него вытаскивают портмоне с документами, о чем Петя пока не знает. В какой стадии ЖЦ находится система хранения документов?

--- Диспозиции ### Нет такой стадии

--- Дислокации ### Нет такой стадии

+++ Использования ### Да, система хранения «портмоне в сумке» находится на стадии эксплуатации, хотя что-то уже пошло не так.

--- Находится между стадиями ### Нет, между стадиями обычно ничего не находится.

--- Испытаний ### Испытаний (часть инженерного обоснования) не было, сразу эксплуатация/использование.

--- Модернизации ### Нет, ничего не меняется по сравнению с оригинальным проектом.

--- Ожидания документов для хранения ### Нет, такая стадия даже не планировалась.

Ольга делает ящик для кошки из органических материалов. Для этого она закупила дощечки из настоящего дерева, гвозди, молоток и мешок наполнителя. Домашние просят её показать ящик. Что она покажет?

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

--- Нарисует ящик в готовом виде, и покажет его ### Нет, просили показать ящик, а это будет не ящик, а документация ящика.

--- Покажет ящик в состоянии «сырьё закуплено» ### Нет, если не уточняется, на какой стадии ЖЦ спрашивают про систему - то обычно принято иметь в виду «эксплуатацию». Так что показывать сырьё ещё рано.

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

+++ Покажет ящик после передачи его в эксплуатацию ### Да, именно целевую систему на стадии эксплуатации и нужно показывать, если специально не просят чего-то иного.

Сенатора очень интересует самолёт МиГ-48, ибо он может получить государственный заказ на его выпуск для своего авиазавода (у него контрольный пакет акций). Когда он убеждает генералов в важности этого самолёта, приводимые им аргументы относятся к (и обратите внимание, что в тексте вроде бы формулировки «однократного создания и использования», но в жизни это будет «непрерывное развитие», «программа создания и развития», а не «проект создания»):

+++ Самолёту МиГ-48 на стадии эксплуатации ### Да, проектные роли генералов имеют предметом интереса боевые характеристики самолёта.

--- Самолёту МиГ-48 в ходе его разработки ### Нет, проектные роли генералов не озабочены особенностями проектирования и производства самолёта, предмет их интереса — боевые качества самолёта на стадии эксплуатации.

--- Самолёту МиГ-48 на протяжении всего его жизненного цикла ### Нет, генералов не волнуют особенности производства, для принятия решения о заказе их волнуют характеристики самолёта на стадии эксплуатации.

--- Системам создания самолёта МиГ-48 на стадии эксплуатации ### Нет, генералов интересует самолёт в бою, а не службы его техобслуживания и ремонта.

--- Системы создания самолёта МиГ-48 на всём его жизненном цикле ### Нет, стейкхолдеров-генералов интересует самолёт в бою, а не службы его проектирования, изготовления, техобслуживания и ремонта.

Сенатора очень интересует самолёт МиГ-48, ибо он может получить государственный заказ на его выпуск для своего авиазавода (у него контрольный пакет акций). Когда он говорит своей семье про свой интерес к этому самолёту, он рассказывает о (и обратите внимание, что в тексте вроде бы формулировки «однократного создания и использования», но в жизни это будет «непрерывное развитие», «программа создания и развития», а не «проект создания»):

--- Самолёте МиГ-48 на стадии эксплуатации ### Нет, семью сам самолёт не волнует.

--- Самолёт МиГ-48 на стадии выпуска ### Нет, семью сам самолёт не волнует.

--- Самолёт МиГ-48 на протяжении всего его жизненного цикла ### Нет, семью сам самолёт не волнует.

--- Системе создания самолёта МиГ-48 на стадии его эксплуатации. ### Нет, семью это не слишком волнует: эксплуатация самолёта ведётся не на принадлежащем семье авиазаводе.

+++ Системе создания самолёта МиГ-48 на всём его жизненном цикле. ### Да, семью волнует авиазавод и что он будет делать в ходе жизненного цикла самолёта — проектировать, производить, модернизировать и т.д.

Георгий хочет рассказать подруге о звездолёте, который он строит в свободное от учёбы время. О чём он должен рассказать?

--- О системах создания на стадии эксплуатации звездолёта ### Нет, ремонтные мастерские и службы техобслуживания звездолёта — это не звездолёт на стадии эксплуатации, не об этом должен быть рассказ.

--- О надсистеме звездолёта на стадии эксплуатации ### Нет, это не звездолёт, это, скорее всего, звездолётный флот (много звездолётов), или звездолётная компания, эксплуатирующая звездолёты (типа авиакомпании, эксплуатирующей самолёты), а то и вообще космический вакуум, окружающий звездолёт. Рассказ о надсистеме — это не рассказ о самой системе, это рассказ об операционном окружении системы.

+++ О целевой системе «звездолёт» на стадии её эксплуатации ### Да, именно это и нужно рассказывать — если система называется без указания на стадию жизненного цикла, то обычно интересуются стадией эксплуатации её как целевой системы.

--- О жизненном цикле звездолёта ### Нет, когда говорят о целевой системе, если явно не требуют иного, то говорят не о поведении создателей, а об уже созданной целевой системе на момент её эксплуатации.

--- Об описании звездолёта ### Нет, карта не территория, описание (и даже документация) звездолёта — не сам звездолёт.

Упоминание сепулькария как системы в каком-то проекте должно по умолчанию пониматься как относящееся к какой из стадий его жизненного цикла?

--- замысел ### Нет, это не так. Сепулькария на этой стадии ещё нет, и не факт, что это будет сепулькарий.

--- проектирование ### Нет, это не так. Сепулькария ещё нет в материальном мире, а системы представляются в момент их использования.

--- изготовление ### Нет, это не так. Сепулькария ещё нет, он только изготавливается, есть только его части.

--- передача в эксплуатацию ### Нет, это не так. Он в этот момент не выполняет своей функции, не взаимодействует с окружением.

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

--- обслуживание и ремонт ### Нет, это не так. В этот момент сепулькарий не рассматривается как функционирующий в окружении.

--- модернизация ### Нет, это не так. В этот момент сепулькарий не рассматривается, как функционирующий.

--- вывод из эксплуатации ### Нет, это не так. В этот момент сепулькарий уже «бывший сепулькарий».

Петя собирается в гипермаркет «Лента» за продуктами на неделю. Петя пользуется типовым алгоритмом при своих закупках: «Анализ содержимого холодильника» - «Анализ потребностей на неделю» - «Определение бюджета покупки» - «Составление списка продуктов» - «Закупка» - «Оптимизация списка закупок». Обычно Петя закупает продукты, хранит продукты в холодильнике, выкидывает просроченные покупки, и старается есть только качественные продукты. Алгоритм Пети является:

+++ Жизненным циклом проекта закупки продуктов питания ### Да, это он, перечисляются работы Пети с продуктами его питания, ограниченные временем закупки (ЖЦ проекта на неделю против ЖЦ системы, то есть создания и поддержания/развития набора продуктов на неопределённое время, «в цикле», «программа питания»).

--- Жизненным циклом продуктов здорового питания ### Нет, такой жизненный цикл должен как минимум включать поедание продуктов (конец жизненного цикла).

--- Циклом повышения качества Шухарта-Деминга ### Нет, это не цикл Шухарта-Деминга (планируй-делай-изучай-корректируй).

--- Ничем из вышеперечисленного ### Нет, правильный ответ есть: это жизненный цикл проекта.

Проблемы с жизненным циклом 1.0

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

Сначала в agile¹⁰³ (гибких) подходах к разработке софта появились не тематические по видам работ «стадии», а безымянные «итерации» какой-то фиксированной длины — и на этих итерациях было очень трудно отследить, какая же там преимущественная тематика работ, чтобы по ним назвать стадию/фазу/этап. По факту там в каждой итерации и замышляли кусочек системы, и разрабатывали её, и делали, и испытывали, и эксплуатировали, и вроде как понятно было, что всё это нужно обсуждать, но вот идея «стадия как время ведения каких-то одних видов работ, а потом другая стадия как время ведения других видов работ» не выжила. Тем самым и провалилась попытка назвать работы в их крупном делении по имени метода — скажем, «изготовление» отсылало к содержанию работ в стадии, а при переходе к итерациям — все признаки «этапа» были, а вот отсылки к преимущественным методам работ исчезли. Это похоже на то, как был «лакокрасочный цех», а потом там стали делать и сборку, и тестирование, и даже сварку — и пришлось назвать «цех №4», специфика метода работы исчезли. Так и тут — этапы/фазы/стадии стали номерными, их специфика исчезла, красивые картинки «типового жизненного цикла» перестали описывать жизнь.

Эпоха «водопада/каскада/cascade» как «последовательного прохождения стадий жизненного цикла, как вода течёт в водопадах всегда сверху вниз» закончилась даже до появления полноценной идеи «непрерывного развития», в которой множество линейных жизненных циклов и системы в целом, и её фич замыкались в изначальное «квазибиологическое» кольцо/цикл. Квазибиологическое кольцо, когда никакая версия системы не является последней — это всё-таки техно-эволюция, когда создатели делают всё новые и новые версии системы, но не система делает себя сама снова и снова как в дарвиновской биологической эволюции (в техноэволюции мутации не случайны, это smart mutations, а наследственный материал не реплицируется вместе с системой — он хранится где-нибудь в конструкторском бюро). Но это уже была эволюция, не «от рождения до смерти» даже с учётом проектирования, и даже не «круговерть рождений и смертей», как в биологической эволюции, а круговерть доработок системы — и доработок в замысливании, и доработок в разработке, и доработок в изготовлении — типичная инженерия из идеализированной greenfield («с нуля») инженерии превратилась в повсеместную brownfield (не с нуля, доработка уже имеющегося) инженерию.

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

Тем самым в начале нулевых годов 21 века возникли вопросы к идее о том, что работы на стадиях жизненного цикла ведутся с каким-то определённым состоянием целевой системы и поэтому группируются по каким-то методам. Система разными своими частями находилась в разных состояниях, а все методы работ применялись одновременно к разным частям системы: если корабль красили, то не как раньше — сначала зачищали всю поверхность, потом всю её грунтовали, потом всю красили, всю сушили. Нет, чаще всего сначала зачищали кусочек, потом его грунтовали, и одновременно начинали зачищать следующий кусочек, потом первый кусочек красили, второй грунтовали, а третий начинали зачищать — и «сначала» и «потом» оказывалось сугубо локальным для кусочка, а не глобальным для всей целевой системы. Стадии «зачистки», «грунтовки», «покраски», «просушки» оказывались перекрывающимися во времени/параллельными/concurrent, то есть они перестали быть последовательными стадиями, группировкой последовательности работ! В этом месте программисты могут вспомнить, как соотносятся декларативные функциональные описания и выполняемые на компьютере с хорошим распараллеливанием в процессорных ядрах императивные команды машинного языка. Описание жизненного цикла в его первой версии выглядело как процедурное, «последовательность крупных шагов», но оказалось функциональным!

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

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

Вот типичная картинка объяснения перехода к параллельной/concurrent инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются)¹⁰⁴:

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

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

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

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

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

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

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

Это принятие решений по методам/способам верхнеуровневой росписи методов по работам (например, проектирование как метод работы будет только одной работой где-то ближе к началу проекта, или же оно будет длиться всё время проекта понемножку, даже и ближе к концу проекта тоже) стали называть управлением жизненным циклом (life cycle management, ср. work management/управление работами, а типовые решения на эту тему — моделями жизненного цикла (слово «модель» тут надо понимать в значении «образец для повторения»).

В управлении работами (операционном менеджменте) нет решений по методам работ создания и развития системы: не идёт речь о содержании работ, их технологии, то есть о методах/практиках/«видах инженерии», но только о длительности работ и потребных ресурсах безотносительно к «способу выполнения работ»/«way of working»/методу.

Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)¹⁰⁵, она представляет собой спектр разложения интенсивности работ по шкале методов создания системы, при этом каждое значение объёма работ ещё раскрыто в отдельный спектр по времени ведения проекта:

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

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

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

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

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

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

• Привязана ко времени. Так, дисциплина Requirements (полностью — requirements engineering, причём engineering тут тоже синоним «метода»: указывается «вид инженерии») в диаграмме 1996 года была очень и очень современной, культурно-обусловленной, SoTA. А сейчас это воспринимается как анахронизм, привет из прошлого.

Как проверить культурную обусловленность? Обычно по культурно-обусловленным методам работы есть учебники, курсы, монографии, статьи, посты в блоге, регламенты, руководства, инструкции, корпуса знаний (body of knowledge). А если это кулибинство/«я сам придумал!»¹⁰⁶, то учебника/руководства обычно нет — и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как работать по этому методу мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем. Ну, или даже там устная традиция, как в восточных единоборствах, «секреты мастерства» передаются из поколения в поколение только устно. В литературе это было во времена до книгопечатания: былины и эпосы, с методами всё то же самое). Методология не учит, что делать в этом случае — понятно, что вы должны стратегировать (выбрать какой-то метод работы в ситуации, когда он вам вначале неизвестен), но методология заставляет удерживать во внимании методы работы и интересоваться их культурной обусловленностью, вы не можете уйти от осознанного выбора метода работы, осознанного стратегирования.

Работы по методам, описанным разными дисциплинами на «горбатой диаграмме» как-то распределены по времени жизненного цикла в его начальном (1.0) представлении («жизненный цикл — это последовательность работ»). В RUP это работы по практикам организационного моделирования (business modeling, помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельный метод работы не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому, ведь диаграмме около 30 лет!), испытаний (сегодня это инженерные обоснования, quality assurance), разворачивания (но вот delivering как «введение в эксплуатацию» в RUP нет, это не считалось трудозатратным — «акт подписать»), управления конфигурацией и изменениями, управления проектом, работы с окружением/environment. И это никак не закольцовано, хотя и выделены «порции работ по всем методам создания и развития вместе» как «итерации» — но это просто отражение «постепенного достижения конечного результата», а не получение сначала MVP (создание), а затем развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились с проектированием и изготовлением, убедились, что удовлетворили начальные требования — всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса — за рамками жизненного цикла».

Деление работ на стадии/фазы/этапы, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) относят к методам проектного управления, в то же время методология обсуждает разложение методов работы создателей (названные на «горбатой диаграмме» по их дисциплинам) как разделение труда (division of labor). Виды труда — это один из синонимов «метода».

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

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

• выше мастерство — меньше новичковых ошибок,

• меньше ошибок — меньше надо их исправлять, что-то переделывать,

• меньше время переделок — меньше время выполнения проекта.

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

Работы — это про количество работы для имеющихся ресурсов и её скорость, а методы/практики/стили работы (виды труда, инженерии, деятельности) — это про назначение и разнообразие способов работы задействованных в проекте ролей и их уместность/полезность/назначение в проекте. Что нужно? Нужно и одно, и другое!

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

Конечно, работы — это взаимодействующие продукты/агенты/конструктивы::ресурсы, участвующие в выполнении действий какого-то метода работы из жизненного цикла. Но все эти работы мы представляем ещё и как набор паттернов/шаблонов такого взаимодействия — и это будет рассмотрение уже не собственно работ, а метода работ. Метод работ и работы по методу неразделимы, ибо 4D экстенсионализм не разделяет конструктивы, проводящие работы и роли, задействующие методы — это одни и те же места в пространстве-времени, значит это одни и те же объекты, просто они рассматриваются в их разных аспектах.

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

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

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

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

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

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

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

Cоздатель АЭС — это набор связанных разными видами соглашений организаций, так называемое расширенное предприятие, extended enterprise, поэтому говорим не просто про архитектуру, а организационную архитектуру.

Создатели имеют свои первичные названия, как и любые системы — по основной их роли, а роли — по выполняемым функциям/методам работы, а функции/методы работы называются по их дисциплинам/теории/объяснениям. Вопрос именования систем подробно разбирался в руководстве по системному мышлению. Парикмахерская выполняет работы своего сервиса (это синоним метода! Только над чужими системами) как оргзвено::ресурс (например, как частный парикмахер Ольга, как предприятие ООО «Причешем», или подразделение холдинга Всёрежьчешиукладка), но метод своей работы «стрижка и укладка» выполняет как «парикмахер»::оргроль. Сам термин «парикмахерская» (или барбершоп) тут — просто обозначение места работы парикмахеров¹⁰⁷. Какие методы работы будут у парикмахера? Что можно сказать про разложение метода, которое они используют? Разложение метода зависит от предмета метода, например, речь идёт о методах работы с мужскими волосами (например, стрижка бороды и усов) или методах работы с женскими волосами. В зависимости от этого выбираем агентов-парикмахеров с необходимой степенью мастерства в разных методах парикмахерских работ.

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

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

А оргзвено? Для каждой более мелкой роли будет обычно более мелкое оргзвено — концепция системы (в данном случае концепция создателя и даже более точно — концепция организации организации) расскажет, какие оргзвенья воплощают какие роли, то есть назначены на какие виды/методы работ:

• для клиники — предприятие (клиника::роль, предприятие::оргзвено);

• для врача — не слишком понятно, что, в силу общности роли в плане разнообразия методов работы (и это должно напрягать: модульный синтез для «врача» будет трудным);

• для гинеколога — человек, «обладающий мастерством в»/«знающий дисциплину и управляющийся с инструментарием»/практикующий гинекологию::метод, занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами. Это описано оргзвено размером с одного человека.

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

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

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

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

Провал водопадной модели жизненного цикла

Недостаточность и ограниченность описания жизненного цикла как поведения создателей (view) через метод описания (viewpoint) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Назревала необходимость смены метода описания поведения создателей.

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

Наборы различных типовых последовательностей работ получили название модели жизненного цикла (life cycle model¹⁰⁹, вид/форма жизненного цикла, модель тут как образец/шаблон/паттерн).

Модели жизненного цикла грубо можно разместить между двух крайностей:

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

2. Методы работы и работы-стадии/фазы/этапы не совпадают и для их выражения нужны какие-то сложные представления для разложения методов. Это разложение методов даже внешне похоже на принципиальные схемы с их «логическим, а не физическим временем» и «потоками альф, меняющими по мере прохождения обработок состояния». Квази-модульные диаграммы пошаговых «колбасок» с их квази-интерфейсами тут никак не помогают.

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

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

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

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

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

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

Требования постоянно оказывались не «долженствованием», а «мы чуток ошиблись, гипотеза не подтвердилась», «мы тут не уточнили, давайте сформулируем по-другому». Пробы и ошибки всё равно были, новые и новые переделки/reworks не позволяли хоть как-то соотносить запланированные стадии жизненного цикла и реально ведущиеся работы.

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

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

Эта ситуация известна как проблема «а чо такова?»¹¹⁰, то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия — плод фантазии, но всё-таки следовать им. «Водопад» оказывается утопичен, фантазиен, но всё-таки люди считают, что он хорошо описывает проект и дальше пытаются ему следовать. Почему? Ответ обычно — «он же прост! Не надо усложнять». Ну, 2*2=3 тоже просто, но не работает. Но в этом случае почему-то ошибку исправляют, а в случае водопада — нет, менеджерам он выгоден, можно всегда обвинить инженеров в том, что они не справились.

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

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

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

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

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

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

Каждый раз, когда люди говорят «у нас принята водопадная модель» — это означает, что они думают про свой проект стадиями «колбаски», а в жизни у них не-пойми-что, но только не эта «колбаска» с последовательным продвижением по стадиям. Тем самым описание проекта сильно отличается от жизни, а это недопустимо, это само по себе вносит риск в проект!

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

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

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

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

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

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

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

Границы проекта при этом не сводятся к изготовлению одного экземпляра или даже «малой серии» системы. «Не жизненный, но цикл» — при этом не гарантируется одинаковость каждого прохождения цикла, этот возврат к развитию/эволюции оказывается не так легко описать: надо описывать заранее неизвестное! Нельзя просто сказать, что «повторяем водопад много-много раз, после первого прохождения будет второе и так много раз»! Нет, нужна была не модель «множества водопадов по пути к цели».

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

Жизненный цикл 2.0: от стадий работ к методам разработки

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

Этот спиральный жизненный цикл¹¹¹ был предложен Barry Boehm в 1978 году на примере айтишных проектов, успешно реализован им 1981 и опубликован 1988 году — задолго до появления «горбатой диаграммы» в RUP (напомним, она появилась в 1996 году, и тоже у айтишников — пелетон в инженерии растягивается на десяток-другой лет). Вот один из поздних вариантов изображения этой «спирали»:

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

К методам работы, изменяющим состояние продукта (целевой системы), которые указаны на белом поле, добавились методы работы с проектными ролями, на диаграмме они показаны на сером фоне. Process definitions — это как раз описание/проектирование/definitions модели жизненного цикла, который стал называться process/метод разработки. Это добавляло путаницы: process понимался как просто «поведение» и дальше рандомно разные люди относили его то к методам разработки, то к работам.

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

Мы в руководстве чаще говорим о «процессе разработки» как об общем методе инженерной работы в проекте (все методы выполняемой в проекте работы), а о «рабочем процессе» — как одном из частных методов в разложении «процесса разработки».

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

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

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

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

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

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

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

Последний вариант спиральной модели жизненного цикла носит название «модель пошагового спирального выделения ресурсов» (Incremental Commitment Spiral Model). Эта модель жизненного цикла разрабатывалась Barry Boehm, Jo Ann Lane,‎ Supannika Koolmanojwong, Richard Turner в 2006-2014 годах как продолжение работ по развитию идей спирального вида жизненного цикла. Эта модель жизненного цикла используется в военных инженерных проектах США¹¹².

Вот один из типичных вариантов «спирали», в которой укрупнённые старинные инженерные практики/процессы/методы работы (в современном варианте не было бы, например, «анализа требований») раскладываются по линии времени:

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

Тем самым произошёл переход от

• «проектного» (версии 1.0) понимания жизненного цикла как цикла работ создателей. Это менеджерски-логистический взгляд на системы создания, ведущие работы с производством и потреблением ресурсов проекта в строго запланированное время. Акцент тут делается на своевременное выделение ресурсов и учёт рабочих продуктов, контроль выдаваемых обещаний и приёмок-сдач (координационные акты DEMO) к

• методологическому пониманию (версии 2.0), где на первый план выходит полноценная концепция жизненного цикла как представление метода разработки в его разложении на частные инженерные методы работы, но ещё и отражение работ, которые ведутся по этим методам.

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

«Инженерный процесс»/«процесс инженерии»/«engineering process» — предпочтительный термин. Термин «процесс разработки»/«development process» используется в двух значениях:

• Именно метод/процесс разработки как противопоставление другим методам из разложения полного инженерного метода (визионерство, архитектура, создание производственной платформы, подробнее будет в руководстве по системной инженерии).

• Полный метод/процесс инженерии, где разработка только один из методов в разложении. Это появилось как историческое название: когда-то инженеров интересовала главным образом только «разработка», даже без изготовления (хотя его важность признавалась — но всё-таки речь шла о разработке как проведении НИОКР — до получения работающего прототипа, который потом «шёл в серию»), и уж точно без эксплуатации и ликвидации. Но потом времена поменялись, и термин «разработка» остался — но в границы «разработки» попала практически вся инженерия, включая и эксплуатацию.

Инженеры целевой системы (прикладные инженеры) и инженеры организации создателя (то есть менеджеры, создающие команду прикладных инженеров) договариваются о методе/процессе инженерии:

• прикладные инженеры предлагают «по каким методам будем работать, чтобы целевая система была успешной»,

• менеджеры предлагают способы организации работы (создают и развивают оргвозможности для работы по предложенным методам, причём так, чтобы была успешна и система-создатель, то есть была успешна организация).

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

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

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

• Начинать с целевой системы в её окружении во время эксплуатации как чёрного ящика (концепция использования, сценарии использования)

• Затем рассматривать «как работает», прозрачный ящик (функциональное моделирование прежде всего, 1D-моделирование)

• Затем рассматривать «из чего может быть сделано», надо найти конструктивы как аффордансы для функциональных объектов

• Затем надо рассматривать способ, которым это всё можно сделать, то есть метод инженерии, «инженерный процесс». В хорошем инженерном процессе предусмотрены и первые шаги по этой системной мантре.

• И только тут надо рассмотреть, какие роли должны выполнять этот инженерный процесс в его разложении на отдельные методы инженерии, кто мог бы исполнить эти роли и каков должен там быть граф создателей.

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

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

Управление работами производят путём связи альфы с рабочими продуктами и кейсами, предметами которых будут рабочие продукты для этих альф. Кейсы отслеживаются в софте управления работами: управления кейсами/issue trackers, управления проектами, управления процессами, управления программами или просто в универсальных моделерах типа coda.io или notion.so, которые позволяют отмоделировать в том числе и метод инженерии. Подробней об управлении работами (операционный менеджмент) будет рассказано в руководстве по системному менеджменту. А вот как моделировать движение альф по их состояниям — предмет методологической работы, рассматривается в нашем руководстве. Прикладная методология заставит выбрать правильный метод, правильные предметы метода, состояния этих предметов метода. Но наше руководство по фундаментальной методологии расскажет, как это всё описать, а также какие ошибки не надо делать в ходе рационального выбора метода.

Часто на диаграммах инженерного процесса (жизненного цикла, метода разработки) приводят только методы работ. Эти диаграммы практически полностью будут функциональным описанием создателя системы как «прозрачного ящика», причём чаще всего без показа ролей, а только с показом функций/методов, выполняемых ролями и потоками предметов метода, проходящими обработки по этим методам. Гибридизация с представлением работ происходит сегодня много реже, ибо планирование работ в современных методах инженерии происходит «на лету», непонятно как показывать работы (разве что иногда показывают тип «работа/task» или «пакет работ»/ «work package»). Диаграммы работ не называют диаграммами инженерного процесса, процесса разработки, жизненного цикла, но называют диаграммами проектного управления (например, диаграммы Ганта¹¹³), верный признак диаграмм работ — там физическое время, а не «логическое».

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

Время эксплуатации: пример человека

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

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

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

Так что создатели могут быть операторами, ремонтниками, модернизаторами, но их работу относим по большей части ко времени создания, а вот если есть пользователь (получатель сервиса от системы), то взаимодействие с ним — время использования, описывается это взаимодействие сценариями использования (use cases).

Все работы по методам «инженерного процесса»/«жизненного цикла»/«создания и развития» какой-то системы делаются создателями для того, чтобы система могла выполнить свою функцию в надсистеме во время использования: нанесения системой непоправимой пользы окружению. Иногда эта польза демонстрируется путём предъявления довольно длинной причинно-следственной цепочки рассуждений, рассматривающей разветвлённый граф создателей, но это не меняет рассуждения.

Вот схематически это показано на примере сверхсложной системы — человека, и мы обращаемся при этом для простоты к нулевой биологической версии понимания жизненного цикла — «от рождения до смерти».

Сам человек тут показан как система, которую делают (а не которая сама растёт-развивается). Напомним онтологию человека (она даётся в руководствах по системному мышлению и инженерии личности): в человеке выделяют организм (физическое его тело) и личность как сумму мастерства во всех возможных методах работы, которые есть у человека.

В отличие от классических биологических жизненных циклов тут показан не жизненный, и не цикл — ибо не рассматривается цикл биологической жизни человека, биологическая жизнь и смерть входят в предлагаемый метод описания (viewpoint) методов работы создателей только как часть важных состояний целевой системы, а акцент делается на методы работы и роли создателей человека, как бы странно это ни звучало.

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

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

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

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

Затем доктора нашего человека его главным образом лечат (эксплуатация закончена, человек больше не работает — выведен из эксплуатации), а потом микробы прекращают существование организма (метод ликвидации). Альтернативная реализация методов ликвидации организма в данном случае — кремация, там без микробов.

А как же развитие человека как системы, ведь говорим о создании и развитии? Тут несколько вариантов:

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

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

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

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

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

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

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

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

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

Пример инженерии человека (включая тело, причём не только лечение как ремонт, но и изменение тела для развития его возможностей) и инженерии личности (альтернативное название для обучения в целом и образования в частности) подробней разбирается в руководстве по инженерии личности.

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

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

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

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

Если вам нужно привести какой-то объект в какое-то состояние:

• Надо понять, каким методом вы это можете сделать: объект при этом будет предметом метода

• Надо понять, если ли у вас оргвозможность сделать (и создать эту оргвозможность, если её нет)

• Надо запланировать и выполнить работу с этим объектом как предметом работы.

• Даже если в проекте принята другая терминология, надо как-то выдержать само вот это размышление, оно тут часть системной мантры.

Граф создателей

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

• вы делаете топор (топор — целевая система)?

• вы используете топор для колки дров (целевая система — дрова, топор — «один из создателей»/«одна из систем создания», необходимая для подготовки целевой системы-дров к эксплуатации — сгоранию в печке)?

• топор для вас одна из систем в окружении целевой для вас колоды, совместно с которой топор должен колоть дрова и свойства которого вы выясняете для того, чтобы спроектировать и изготовить правильную колоду¹¹⁵?

С самого начала обсуждения жизненных циклов и далее инженерных процессов было понимание, что отдельные инженерные проекты по созданию систем связаны между собой через время эксплуатации/использования в разветвлённые графы создателей, ибо время эксплуатации создателя — это когда создатель участвует в работах по созданию и/или развитию какой-то очередной системы в графе создателей. Чтобы дойти в этом графе создателей до создания и развития целевой системы, может понадобиться несколько шагов (я заточил топор, нарубил дров и сделал из них костёр, добыл охотой дичь, запёк дичь в костре, накормил готовым обедом семью — и это очень простой граф создателей, целевая система в нём — семья, я выступаю как провайдер обеда, но чтобы произвести обработку семьи обедом мне требуется перед этим создать инструментарий: топор, костёр, а ещё создать дичь как сырьё для обеда, и дальше уже можно говорить, что сам обед — это результат «развития» дичи, а не развития топора или костра). Создатели — это необязательно предприятия, это могут быть и простые инструменты. В конце концов, это constructors из constructor theory David Deutsch и Chiara Marletto, а также это enabling systems (системы времени создания и развития, которые преобразуют сырьё, проводя его через разные состояния в итоговую целевую систему), это агенты в широком смысле, у которых есть важное отличие от многих других систем: они «нерасходуемы», то есть после выполнения какого-то сервиса (обработки какого-то предмета сервиса для перевода его в другое состояние) создатели не разрушаются, они опять готовы к работе. Это могут быть и молекулы катализатора, и станки, и люди, и роботы, включая роботов, умеющих самореплицироваться.

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

На таких диаграммах (её рисовать несколько секунд!) рассказывали истории прохода по графу создателей типа «мы организуем стартап, который создаст САПР, при помощи которого мы затем спроектируем топор, при помощи которого мы потом будем колоть дрова, при помощи которых потом мы приготовим обед» — и для каждой системы в цепочке создания обеда в такой диаграмме понятно, что она проходит довольно долгий период собственного изготовления перед тем, как быть использованной/проэксплуатированной. Обратили ли вы внимание, что «мы» тут тоже создатель в графе создателей, и даже у этого «мы» тоже можно задаться вопросом о графе создателей этого «мы»?

Недостатки упрощённой картинки являются продолжением её достоинств:

• Если обсуждаем три системы, то картинка проста. Если систем не три, а тридцать три, то с картинками работать невозможно — поэтому придётся уходить от графического представления к табличным или текстовым.

• На картинке показаны стрелки по факту физического времени, хотя и предельно абстрактно представленного (одно из ранних пониманий жизненного цикла как «водопада» стадий/фаз/этапов работ, а не методов),

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

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

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

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

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

Давайте представим виды/типы/классы систем, которыми занимается предприятие/фирма («которыми занимается» — это ведь «работает по каким-то методам», то есть эти виды систем будут предметами методов работы предприятия/фирмы):

• Целевая система: система, которую производит фирма (возможно, из чужого сырья, если фирма — провайдер сервиса)

• Надсистема для целевой системы (у клиентов есть потребности как раз в надсистеме, в которой они хотят употребить целевую систему как часть)

• Создатель целевой системы (команда инженеров, занимающаяся прикладной инженерией, например, программной инженерией, если целевая система — это софт)

• Создатель команд фирмы (который будет создавать команду инженеров и команду создателя агентуры, то есть команда менеджеров фирмы, занимающихся её развитием)

• Создатель создателя команд фирмы, который не только создаёт инвестуру — группу инвесторов, которые дают фирме необходимый для развития капитал, но и создаёт команду менеджеров по организационному развитию фирмы (то есть команда основателей фирмы, которая проводит соответствующие переговоры с инвесторами, оформляет инвестиционные сделки и организует/создаёт и развивает команду менеджеров)

• Создатель агентуры, который создаст группу агентов по продажам (команда продвиженцев: маркетинг, реклама, продажи продуктов и/или сервисов фирмы)

• Создатель клиентуры (агентура, то есть группа агентов, которая будет вербовать клиентов)

• Клиентура (группа клиентов, у которых есть потребности в системе, они создают свои надсистемы и интересуются целевой системой).

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

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

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

Когда мы рассматриваем системы попарно: создатель::система «создаёт и развивает»::метод «свою систему»::система, то если «своя система»::создатель, эту цепочку можно продолжить. А ещё один создатель может создавать несколько систем, одна система может создаваться несколькими создателями, и тогда цепочки оказываются полноценным графом.

Исключительно для иллюстративных целей приведём диаграмму графа создателей (в жизни вы будете создавать и заполнять списки и/или таблички, а не диаграммы, ибо замучаетесь вносить постоянные изменения в диаграмму, но про таблички расскажем чуть позже)¹¹⁶:

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

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

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

Любителям абсолютной онтологической строгости с альфами приходится туго, но мы не будем тут что-то сочинять своё, а будем задействовать язык/language/дисциплину OMG Essence, ибо этот стандарт как раз предназначен для описания инженерных процессов и какого-то их упрощённого разложения (рабочие процессы — это методы работы, поэтому используем тут метафору разложения в спектр).

Мы не советуем использовать предлагаемую этим стандартом нотацию (как текстовую, так и диаграммную) и предложенный в нём набор областей интереса и альф (в языке стандарта это kernel, «основные альфы»):

• Они не будут без адаптации работать с типами объектов вашей метаС-модели инженерного процесса, в том числе набор kernel объектов (прежде всего — альф) там ещё взят из устаревших версий инженерного процесса

• Сами нотации крайне трудны для сопровождения в ходе неминуемых изменений.

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

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

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

«Времена» рассмотрения системы

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

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

В обсуждениях самых разных проектов по созданию и развитию систем есть множество явно выделенных времён, которые должны быть во внимании в проектах:

1. Время эксплуатации/использования/run-time/operations, оно в момент «разработки с нуля»/greenfield, а также разработки фич (модернизации, brownfield). Это время работы уже существующей готовой и работающей целевой системы. Оно в ходе проекта часто находится в будущем, и поэтому приходится думать о будущей системе как уже существующей и успешной (т.е. удовлетворяющей потребностям проектных ролей, а то и превосходящей их ожидания). Это время эксплуатации может быть очень небольшим, например, 20 миллисекунд для исполнения какого-нибудь софта или реализации взрыва. Это также может быть тремя минутами для танцевального перформанса, или восьмьюдесятью годами бесперебойной работы энергоблока атомной электростанции. В этот момент система уже создана и её экземпляр прошёл какое-то развитие. Экземпляр системы находится в физическом мире, настроен и работает, взаимодействует со своим окружением в составе надсистемы, нанося этому окружению непоправимую пользу. Взрыв крушит всё вокруг, софт перемалывает данные, танцевальный перформанс происходит и три минуты радует людей, энергоблок АЭС производит электричество. Ведущий аспект рассмотрения целевой системы тут — функциональный, система создания обычно не рассматривается (но может рассматриваться из неё оператор, который работает как раз в это время).

2. «Время создания и развития»/«design and construction time»/«development time» как время работы создателя целевой системы, состояние целевой системы при этом необязательно готовое для работы, она может быть вообще ещё в виде сырья или даже существовать только в форме идеи/замысла, то есть создаваемая система в это время может ещё и не существовать в физическом мире. Это design-time или development у айтишников (начиная с замысливания и включая «непрерывное всё»), но мы включаем сюда и время изготовления, наладки, испытаний, ввода в эксплуатацию, модернизации и техобслуживания для «железных систем», что часто в программной инженерии не рассматривается как отдельные работы. Софт контроллера в подушке безопасности автомобиля работает 20 миллисекунд, но время его создания и развития — три года разработки начальной версии и три года эксплуатации (где актуальное срабатывание — только 20 миллисекунд, остальное — время ожидания включения, но это ожидание включения — тоже время эксплуатации). Но длительность создания и развития контроллера в подушке безопасности будет всего не шесть лет, а много больше — ибо каждый год выходит новая улучшенная версия, и так продолжается уже двадцать пять лет, и непонятно, сколько ещё будет продолжаться («непрерывное всё» в технической эволюции может быть ограничено по времени, но в целом развитие жизни, включая техносферу, бесконечно по времени, и мы рассматриваем уже «систему как вид», эволюцию системы). Можно подразделять это время на создание MVP, развития/эволюции, можно выделять из времени развития ещё и время создания каждой очередной версии системы (время создания инкремента, время создания фичи), считая, что время развития состоит из времён создания множества инкрементов, но это уже детали. Главное, что речь идёт о рассмотрении работы систем создания и состояний целевой системы, которая ещё не работает. Ведущий аспект рассмотрения тут — рассмотрение не столько целевой системы, сколько методов работы и работ создателей из их графа.

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

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

Моделирование: время операционное, создания, методологическое

Составьте три описания ситуаций в вашем проекте (используйте в них все три времени рассмотрения системы!), а затем рассортируйте части этих описаний по разным временам, ориентируясь на пример.

Задания: процесс инженерии и методологическое время

Поставьте отметки о выполнении:

1. Написан пост, в котором вы даёте оценку процессу инженерии в вашей организации: насколько он далеко от «водопада».

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

3. Инженерные процессы (методы разработки)

V-диаграмма

Самым упрощённым, популярным и распространённым визуальным представлением «однократного» процесса инженерии (создания-без-развития) с показом основных практик в их развёртке по «логическому времени» является V-диаграмма (V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg¹¹⁷:

Это «культурное наследие» прошлых времён, и его нужно знать хотя бы для того, чтобы мочь поддержать разговор с инженерами старших поколений.

Название этой диаграммы происходит от формы латинской буквы V, а форма выражает «логическую»/функциональную линию времени, перегнутую пополам в точке, где укрупнённая стадия описания будущей системы (работа с битами, system definition) переходит в укрупнённую стадию воплощения системы (работа с атомами, system realization). Это такой упрощённый водопад ещё первого понимания жизненного цикла как работ, поделённых на стадии. На этом первые V-диаграммы обычно и заканчивались, но потом иногда начали изображать и стадию эксплуатации/использования (работы/функционирования системы, system operation) как длинный горизонтальный отрезок. На нашем рисунке это «иногда» показано квадратными скобочками вокруг [работы системы]. Внешний вид диаграммы больше стал напоминать квадратный корень, но название «V-диаграмма» осталось. Традиционную для системной инженерии с её «от рождения до смерти» стадию вывода из эксплуатации («смерти») на V-диаграммах изображать так и не начали.

Эти дополнения начальной V отражали постепенное принятие инженерами идей системного мышления:

• сначала идея жизненного цикла проекта/project разработки системы (то, чем занимаются системные инженеры в своём проекте),

• потом охват мышлением стадии эксплуатации (ещё шаг к удержанию внимания на полном жизненном цикле, добавили стадию),

• и только в самое последнее время (уже в 21 веке, начиная со стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием является обязательное рассмотрение полного жизненного цикла — в том числе и (инвестиционный, коммерческий) замысел, начиная с проверки соответствия идеи проекта стратегии предприятия, берущегося за проект, и заканчивая выводом из эксплуатации/уничтожением после использования.

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

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

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

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

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

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

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

• Описание как информация о системе (акцент на то, что это описание как содержание «проектной документации», «системной документации», хотя уже и отсылка к «документам» устарела, это всё какие-то информационные модели в базах данных).

• Описание как описывание::работа, обобщённая/укрупнённая стадия жизненного цикла, то есть работы по описыванию системы/созданию описания системы в первом смысле этого слова (информация о системе, а не стадия). И тут даже английская не -ing форма (definition) не помогает: регулярно стадии работы называют не по их процессам, а по их результирующим предметам метода. «Забитый гвоздь» вполне может быть «работой по какому-то из методов забивания гвоздя, дающей на выходе состояние гвоздя «забитый»». Будьте внимательны к типам!

После того, как система спроектирована, линия «логического»/функционального/методологического времени делает перегиб, и начинается следующая стадия воплощения системы (system realization, реализация тут как «вынос в реальность», получение физического воплощения — изготовление, сборка, наладка). Словосочетание «воплощение системы» тем самым тоже используется в двух словарных значениях:

• Название системы как вещи (система как физическое тело в пространстве-времени, воплощение-существительное в отглагольном существительном: результат работ по воплощению)

• Название работы создателя по её ведущему методу, то есть обобщённой/укрупнённой стадии жизненного цикла (воплощение-глагол в отглагольном существительном: сами работы, приводящие к результирующей готовой системе-вещи).

Сам излом V нужен для того, чтобы удобно показать инженерные обоснования/assurance. Эти обоснования делили на два рода:

• проверки/верификации/verification — обоснование того, что сделали то, что запроектировали: «мы этого хотели, вот оно». Это было особо актуально в момент, когда вместо сценариев использования говорили о требованиях. Требования описывали систему в её границах, и вот это соответствие требованиям обосновывали.

• приёмки/валидации/validation — обоснование того, что сделано то, что надо, то есть учтены потребности, описание надсистемы (а не требования, описания самой системы). «Они этого хотели, вот им» — совершенно другая формулировка.

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

V-диаграмма говорит, что изготовление деталей (неделимых далее, то есть не собираемых из частей конструктивов) системы делается и обосновывается (для деталей — проверяется/верифицируется) в соответствии с проектом/design, стрелки проверки/верификации на диаграмме показывают именно этот факт. Ради показа этих стрелок проверки соответствия воплощения описанию и сделана сама V-диаграмма: она показывает «инженерный процесс»/«модель жизненного цикла» как упорядоченный «логически» (в целях объяснения) набор методов работы, в котором воплощение/создание/realization (то есть изготовление, сборка, наладка) системы происходит не путём проб и ошибок в физическом мире, а сначала путём размышлений и моделирования системы в ходе замысливания и проектирования, включая архитектурную работу — это всё работы по описанию будущей системы (system definition). Уже созданная/воплощённая (изготовленная в виде деталей, а затем собранная из этих деталей) система проверяется/верифицируется на соответствие её предварительно разработанному описанию — эти проверки изображаются стрелочками проверки на диаграмме.

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

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

• разбирательство с «методологией разработки»/«инженерным процессом» (тогда это было «управление жизненным циклом», а также системноинженерный менеджмент как получение в инженерной организации оргвозможности вести инженерный процесс в соответствии с выбранным его видом),

• инженерию требований, ибо требования вроде как собирались для системы в целом (что оказалось плохой практикой!),

• системную архитектуру в её старом понимании (создание верхнеуровневой концепции системы), причём это считалось ведущей практикой системной инженерии,

• ввод в эксплуатацию готовой системы (наладку),

• инженерные обоснования (ведение испытаний, проверки и приёмки) успешности системы в целом.

Все остальные методы работы (включая, например, проектирование/design::метод с получением в результате проекта/design, проведение инженерных расчётов по каким-то инженерным отдельным методам работы — теплотехнике, аэродинамике) считались прикладными методами инженерии.

Из V-диаграммы видно, что так «по-старинке» понимаемые методы (их чаще называли «процессы», например в устаревшем уже идеологически стандарте «железной» системной инженерии ISO 15288¹¹⁸ это system life cycle processes) системной инженерии встречаются главным образом на начальных и конечных стадиях проекта/project (сейчас при однократном проходе по «жизненному циклу» это была бы концепция использования и концепция системы, включающая современное понимание архитектуры в начале проекта, и испытания на соответствие им в конце проекта), а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями. Современное понимание системной инженерии уже иное: это не какие-то отдельные «системноинженерные» методы работы, а наиболее общее описание сигнатур самых разных методов инженерной работы в их разбиении по культурно-обусловленным ролям, подробней об этих методах («как надо вести инженерную работу») и выполняющих их проектных ролях будет в руководстве по системной инженерии.

V-диаграмма — это одна из первых (это 1991 год, спиральная диаграмма — 1986 год, они практически неразличимы в историческом масштабе) «логических»/функциональных диаграмм, «принципиальных схем жизненного цикла», где появляются методы работы, именуемые по их инженерным дисциплинам/объяснениям/теориям. Её главная новация — разделение работ по описанию и воплощению системы с проверками и приёмками на основе сопоставлений проектной документации и того, что получилось в физическом мире, и ещё явное выписывание методов работ, как и в горбатой диаграмме. V-диаграмма характеризует водопадный/каскадный/cascade инженерный процесс (водопадную модель однократно проходимого жизненного цикла), но переход к двумерному отображению жизненного цикла от «колбаски» уже даёт многое — есть огромное число вариантов V-диаграммы, обсуждающих разные аспекты архитектурных решений по поводу жизненного цикла: каким образом практики задействуются в работах¹¹⁹.

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

Элегантность/lean за счёт повышения точности моделирования и изготовления

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

Для V-диаграммы был сформулирован классический слоган системной инженерии: все возможные работы по методам правой части диаграммы нужно переносить в левую часть. Это означало, что всё, что можно сделать на стадии описания/моделирования будущей системы, нужно делать именно на этой стадии: битами много дешевле оперировать, нежели атомами, особенно если речь идёт о сложных дорогих системах типа самолёта или энергоблока атомной электростанции. Вот данные INCOSE по стоимости исправления ошибок в зависимости от стадии типового жизненного цикла водопадного проекта (2013)¹²⁰:

Это иллюстрация хорошо известного вам уже тезиса уменьшения стоимости переделок/re-work: работать надо так, чтобы уменьшать число переделок, ошибки на одних стадиях не пускать на другие стадии. В Tesla на каждой заводской операции есть и входной контроль (чтобы в обработку не попал ошибочный предмет метода, и мы не потратили бы ресурсы на его переделку), и выходной контроль (чтобы брак не попал в работу — и кто-то дальше по конвейеру не потратил ресурсы на ненужную работу, ибо потом всё одно пришлось бы переделывать). Ошибки надо обнаруживать и устранять рано, проверять ошибки надо постоянно, они ведут к чудовищным тратам ресурсов, если обнаружены позже: переделка для поздно обнаруженной ошибки будет стоить очень дорого!

В современных условиях не-водопада этот тезис можно переформулировать так, что:

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

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

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

Современность, конечно, к этому добавила:

• Моделировать нужно будет много раз, ибо «непрерывное всё». Не получится отмоделировать всё один раз под чётко определённые требования: концепция системы постоянно изменяется в ходе проекта, жизнь ведь не остановишь. «Зафиксировать требования» (даже не просто задокументировать, а именно что «зафиксировать», сделать неизменяемыми), а дальше «выполнить требования во что бы то ни стало» (если уже понятно, что гипотеза о том, какова должна бы быть система, не подтвердилась) сегодня считается плохой практикой. Хорошая практика — проверить гипотезы по концепции использования, потом откорректировать по итогам проверки, проверить опять — и так длительно развивать систему после выпуска MVP. А ещё нужно разбить систему на конструктивы/модули, используя знания по архитектуре. Архитектура стала отдельной от разработки с её моделированием дисциплиной, в том числе озабоченной тем, чтобы разработку разбить на максимально независимые части, которые ведутся асинхронно разными командами — и сама идея стадий/этапов/фаз оказывается не работающей, ибо команды асинхронно выпускают новые версии своих частей. Никто никого не держит.

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

Моделирования в современной разработке по сравнению с древним «водопадом» тем самым стало не меньше, а больше — просто «много моделируй, а один раз сделай» стало само выполняться много раз в ходе развития системы.

«Моделирование в широком смысле — это эффективное по затратам использование чего-то одного вместо чего-то другого для мыслительных целей. Это позволяет нам использовать вместо реальности что-то такое, что проще, безопаснее или дешевле чем реальность для заданной цели; модель является абстракцией реальности в том смысле, что она не может представить все аспекты реальности. Это позволяет нам иметь дело с миром упрощённым способом, обходя сложность, опасность и необратимость реальности»¹²¹.

Мы не тратим силы на обсуждение и обработку ненужных деталей моделируемого объекта. Модели — это «правильные упрощения». Обсуждаем только то, что отмоделировано, то, что важно, что нужно.

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

Но зато формальную (на основе математики) модель можно относительно легко проверить на формальную правильность — вручную или даже компьютером. В случае возможности сведения к чисто логическим (не численным) моделям это называется проверкой моделей (model checking)¹²². Так, в радиосхеме можно формально удостовериться, что все её компоненты соединены и нет неприсоединённых компонент, все соединения не имеют разрывов (то есть не идут откуда-то в никуда). А теперь представим, что речь идёт о радиосхеме из полусотни миллиардов транзисторов (компьютерном чипе). Конечно, проще сделать проверку модели (то есть проверку проектного описания, по которому потом будет сделан компьютерный чип), затем убедиться, что процесс изготовления воплощения системы по модели точный (иначе бессмысленно делать безошибочные модели — ошибки будут внесены при изготовлении), чем пытаться как-то исправить на всех экземплярах чипа ошибку в отсутствии какого-то соединения, которую «прозевали» в модели, в «радиотехнической» схеме чипа. Это, конечно, упрощённое представление происходящего в разработке компьютерных чипов, но отражает основные идеи. И для всей инженерии эти идеи те же самые — ранняя формализация, раннее обнаружение ошибок, затем высокая точность изготовления по безошибочным моделям. И дальше всё работает с первого раза.

Формальную модель системы можно подвергнуть оптимизации (в том числе компьютерной) по самым разным критериям, в том числе многим ранжированным критериям. С формальной моделью может работать поиск/search — искать вычислительными методами оптимальное решение в пространстве решений (при этом модель может быть даже деформализована для поиска оптимума, речь тут идёт о так называемых дифференцируемых архитектурах¹²³).

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

Формальную модель можно не делать руками, а породить/generate компьютером — это решение проблемы сложности. Так, 4 триллиона транзисторов на современном микрочипе¹²⁴ невозможно нарисовать руками на кремниевой пластине, и даже невозможно руками нарисовать принципиальную схему такого микрочипа. Но можно породить и принципиальную схему, и литографическую маску из моделей более высокого уровня абстракции на языке описания микросхем. Получается так, что методы работы потихоньку сдвигаются:

• С изготовления на моделирование: методом проб и ошибок на «проектирование проб — и они оказываются безошибочными». Для уменьшения числа ошибок воплощения моделей в физическом мире поднимается точность моделирования.

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

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

С использованием компьютерного моделирования резко поднялась точность и безошибочность основанного на проверяемых моделях проектирования и одновременно резко поднялась точность изготовления деталей. Компьютерное управление конфигурацией и изменениями позволили в разы снизить количество конфигурационных коллизий, уменьшить тем самым число переделок. Этот переход к элегантной разработке (lean, «ничего лишнего», никаких rework, никаких застреваний на work in progress) резко ускорило разработки, в разы. Если вам говорят, что самолёт или автомобиль, а также компьютерный чип сегодня разрабатывать дольше, чем раньше — не верьте: сложность и характеристики этих самолётов, автомобилей и компьютерных чипов просто несопоставимы с теми, что были раньше. Раньше их было бы разработать не просто дольше — их разработать было бы запредельно долго, попросту невозможно. Не было таких методов работы, не было инструментов, и стоимость разработки должна была бы включить и стоимость разработки методов работы со всеми их теориями и инструментарием. И не берите тут примером государственные проекты, там высокое искусство траты дармовых денег налогоплательщиков с их максимизацией по величине и длительности в оплату за ненужные работы и ненужные функции, поэтому разработки ведутся дольше, дороже, а результаты хуже, чем в частном секторе. Космические программы тут не пример успеха, а пример провала — пока речь не зашла о коммерческом космосе в исполнении SpaceX. В этот момент многим государствам пришлось переформатировать свои инженерные космические программы — и они стали ближе к описываемым тут принципам инженерии.

Точность моделирования и точность изготовления (а точность — это следствие формальности моделей и облегчения проверок) привела к потере актуальности традиционной шутки про необходимость для каждой детали «подгонки по месту напильником». Все изготовленные (не вручную!) по тщательно продуманному и отмоделированному проекту/design и методу изготовления (например, на станке с ЧПУ или 3D-принтере) детали просто собираются в целую систему, и она работает как описано проектировщиками. То же относится к мастерству, которое изготавливается в людях и AI-системах при изучении ими какого-то метода работы, хотя тут всё в разы менее формально. То же относится к программной инженерии, к генетической инженерии, к организационному развитию в менеджменте.

Это соответствует одному из слоганов системной инженерии: «с первого раза правильно», т.е. первое же воплощение системы должно быть работоспособно, его не нужно дорабатывать, а дорабатывать нужно описания-модели. Не всегда ещё так получается, не у всех команд и не во всех областях деятельности, но всё чаще, чаще и чаще. Так, из сорока полётов на Марс до настоящего времени только половина закончилась успешно. Но команда системных инженеров Индии сумела отправить на орбиту Марса в 2013 году ракету с первого раза¹²⁵. Современность к этому только добавляет: никакая ракета на Марс, никакая запущенная в эксплуатацию система не будет у вас последней. «С первого раза правильно» надо делать всё время, моделировать и точно изготавливать нужно всё время — все многочисленные версии развиваемой (как вид) системы.

Практика интеграции (сборки из плохо подогнанных друг ко другу частей и связанного с этим решения системных проблем) была раньше одной из основных практик системной инженерии, вы можете её увидеть в V-диаграмме как «привет из прошлого». Сейчас из набора основных практик системной инженерии практика интеграции исчезла, а сборка стала рутинной нетворческой операцией. Это произошло главным образом за счёт тщательного системного моделирования (а потом изготовления отмоделированных деталей с большой точностью по размерам и другим физическим свойствам). А управление конфигурацией позволило начинать работу по новой конфигурации даже тогда, когда предыдущая конфигурация ещё не изготовлена, не испытана, и не эксплуатируется — но инженеры-разработчики уже знают, как следующую версию системы сделать лучше. Новая версия космического двигателя начинает разрабатываться сейчас раньше, чем текущая успела слетать в космос — ибо уже по итогам инженерных обоснований становится понятно, что там можно улучшить, развить. Хорошо налаженное управление конфигурацией в рамках принятого метода разработки позволяет не запутаться с различными версиями проекта/design системы и самого воплощения системы, не допустить конфигурационных коллизий, тем самым не допустить переделок/rework — и сэкономить время и ресурсы.

Моделирование по мере развития методов инженерии стало частью разложения методов описания системы (раньше — левая часть V-диаграммы), но модели начали использоваться и при изготовлении системы (раньше — это правая часть V), а в последнее время и при эксплуатации (третья часть дополненной V, перекладина в V‾‾). Для готовой эксплуатирующейся системы эта часть методов инженерии получила название использование «цифрового двойника»/«digital twin», а сама система (воплощение системы) тем самым стала «физическим двойником»/«physical twin». Все разные вычислители/computers с моделями, датчики и актуаторы/эффекторы самой готовой системы при этом связаны «цифровой нитью»/digital thread.

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

Методы «мышления моделированием»¹²⁶ в инженерии поддерживаются инструментарием моделеров/modelers, а создание внутренней производственной платформы (internal development platform) не только для изготовления («завод»), но и для моделирования в ходе инженерии (различные компьютерные моделеры с функциями автоматизации проектирования, моделирования) — цифровой инженерией. Про это будет подробно в учебнике «Системная инженерия», а тут покажем относительно новый, но всё-таки идеологически старый вариант V-диаграммы, который появился в 2018 в связи с вниманием к моделированию в инженерии¹²⁷:

Этот новый вариант V-диаграммы от Boeing упоминает ещё один синоним для цифровой инженерии: моделеориентированная инженерия/model-based engineering/MBE. Кроме того, это не V, а MBE-ромб/diamond из двух сложенных своими перегибами V‾‾, где нижняя часть — это классическая V, а верхняя указывает на цифровую инженерию как создание моделеров и исполняемых моделей, которые и порождают модели-описания (например, порождают/generate аэродинамически выгодную форму системы, порождают/generate программу для станка с ЧПУ или программу для 3D-принтера для изготовления какой-то детали из материала). Этот вариант V-диаграммы стал ещё более «метафоричным», ещё более оторванным от реально проходящего в жизни процесса инженерии — ибо в жизни тесно сплетены процессы инженерии систем в графе создателей (скажем, изготовление и разворачивание, настройка моделеров, разворачивание команд инженеров-модельеров), а также тут очень плохо обсуждается независимость разработки разных конструктивов/модулей (а это важно в крупных проектах), плохо обсуждается «непрерывное всё» (когда эксплуатация уже идёт текущей версии, изготавливаются части следующей версии для модернизации текущей версии и проектируются части версии, следующей за изготавливаемой — с жёстким управлением конфигурацией, чтобы чего-то не перепутать).

Тем не менее, эта ромб/diamond диаграмма уже признаёт, что моделирование (проектирование/modeling и имитационное моделирование/simulation) происходит в течение всего «жизненного цикла», а не только в «левой части V». Все остальные недостатки V-модели жизненного цикла в ромб-модели жизненного цикла конечно, остаются, начиная с самого «жизненного цикла». Конечно, системные инженеры «железных» систем уже давно понимают, что развитие систем проходит долго, но продолжают держаться за V-диаграмму и разные другие варианты, напоминающие им однократное прохождение водопада. А вот в программной инженерии от таких диаграмм уже отказались, и на их диаграммах показывают обязательно какие-то «циклы», означающие развитие: выдвижение гипотез, их проверку, переделки, адаптации к изменившимся состояниям и т.д.

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

Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами/gates/воротами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии/фазы/этапа работ и принималось решение о продолжении проекта на следующей стадии (go/no-go).

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

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

В авиации гейтов сначала стало порядка семи, а к 2010 году их стало всего три, при этом даже не все из них связаны с инженерией: например, решение о сворачивании проекта принимается, когда проектирование зашло уже довольно далеко, но не собран достаточный для уверенности в финансовом успехе проекта пакет предзаказов на новую модель самолёта¹²⁸.

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

Выбор инженерного процесса и организация разработки

Наши руководства каждый вопрос рассматривают два-три раза с некоторым интервалом и в немного разных контекстах, чтобы натренировать нейронную сетку человека с учётом кривых забывания (приём spaced repetition¹²⁹). Увы, человек не компьютер, чтобы сходу загружать в мозг сжатое и компактное описание какого-то мастерства. Людям (да и AI-агентам тоже) нужно каждое новое понятие и описание его связи с другими понятиями предъявить несколько раз, чтобы произошло запоминание и появились ассоциативные связи с уже имеющимся знанием.

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

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

Вы должны как-то отмоделировать этот метод разработки, представить его в самом общем виде — используя знание из первого раздела нашего руководства по методологии о том, что это довольно сложно, поэтому надо выделить достаточно рабочего времени, а дальше используя знания второго и третьего разделов нашего руководства с примерами методов описания/моделирования методов разработки и указанием на «новичковые ошибки человечества» с предложением таких методов.

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

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

• Выбрать вид инженерного процесса (концепцию процесса разработки, модель жизненного цикла — выберите себе синоним), и затем

• Выполнить методы организации разработки (управления разработкой, управления жизненным циклом — выберите себе синоним) для того, чтобы получить оргвозможность выполнения выбранного инженерного процесса.

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

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

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

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

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

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

• По современному понятию принятия архитектурных решений, оформленных чаще всего как ADR (architecture decision records). На выходе — несколько десятков ADR, которые ограничивают свободу проектировщиков в выборе конструктивов/модулей, а часто ещё и предписывают использование какой-то платформы для обеспечения связи между модулями. Его задача — добиться оптимальной связности между модулями, чтобы были достигнуты требуемые значения важнейших архитектурных характеристик (которые раньше были «требованиями качества»). Минимизация связности помогает независимой разработке модулей разными командами, максимизация связности — повышению каких-то функциональных характеристик. Архитектор ищет тут баланс.

Сейчас вам уже должно быть понятней, что такое инженерный процесс, метод разработки (раньше — модель жизненного цикла) и вы не путаете

• системноинженерный менеджмент, технический менеджмент, организацию инженерных работ, организационное управление (да, это тоже оно — наладить инженерный процесс!), управление инженерным процессом, управление жизненным циклом (тут тоже огромное число синонимов!) и даже организация разработки продукта (product development) с

• управлением работами, управлением процессами, управлением проектами, управлением кейсами, управлением программами работ, операционным менеджментом.

На всякий случай ещё раз напомним основные отличия этих двух скрывающихся за двумя длинными синонимическими рядами разных методов работы в их самых разных вариантах разложения на составляющие и в самой разной связи между собой.

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

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

Как бы этот метод работы ни назывался, он отвечает на вопрос «как организованы создатели, какое у них должно быть мастерство в выполнении методов работы по их ролям и инструментарий, чтобы по итогам разработки была успешная целевая система, и её успешность удерживалась длительное время в ходе развития?». И дело не ограничивается «аналитикой», то есть просто «ответом на вопрос». Этот метод работ ещё и в качестве результата работ по нему создаёт и развивает оргвозможность выполнения «процесса инженерии»/«метода разработки» для конкретного рабочего проекта.

Методы в разложении полного метода разработки на его составляющие выбирают инженеры, хорошо в них разбирающиеся — по факту это прикладные методологи, владеющие SoTA методов в той или иной предметной области, связанной прежде всего с видом разрабатываемых систем. Понятно, что общий тренд сегодня — уход от «водопада», но всё-таки методы разработки продуктов (product development) в области генной инженерии, железнодорожного транспорта и систем AI имеют свои особенности, их надо знать. Там ещё надо создавать и создателей в графах создателей, как минимум, настроить их инструментарий на конкретную ситуацию проекта. В отличие от бабочки или кошечки, дом сам себя не построит, ракета сама себя не построит, мастерство не самозародится. Кто-то (прежде всего — роль методолога) должен указать, какими методами, какими способами это делать, в какой последовательности, а затем и научить всю организацию работать этими методами (это «научить» будет уже у других ролей, прежде всего лидера, но там ещё нужны будут оргпроектирование и оргархитектура, чтобы лидер смог сработать по оргпроекту, и ещё нужно будет дать полномочия и снабдить ресурсами) — получить оргвозможность. Вот это и делают организаторы разработки/управляющие жизненным циклом.

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

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

В том числе организатор разработки традиционно гарантирует целостность конфигурации инженерного процесса:

• ни один рабочий процесс (то есть ни один составляющий инженерный процесс метод работы) не будет пропущен (то есть не будут пропущены, но будут запланированы и выполнены в какой-то инженерно правильный момент работы, реализующие этот рабочий процесс),

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

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

Организатор разработки может быть реализованным агентами на должностях директора по развитию (в английском это может быть, например, chief transformation officer¹³⁰), главным инженера предприятия (главного инженера предприятия не нужно путать с главным инженером проекта, ГИП, который принимает инженерные решения не по поводу создателя, а по поводу разрабатываемой создателями системы. По-английски это будет — CTO, chief technology officer¹³¹). Агенты (отдельные люди или даже целые подразделения под руководством агентов на этой должности) лучше всех разбираются в процессах разработки, ведущих к созданию успешной системы выбранного вида, но должность даёт ещё и полномочия для того, чтобы не просто аналитически «разбираться», но воплотить в физической реальности оргвозможность вести создание и развитие систем по выбранному инженерному процессу.

Организатор разработки занимается создателями, а не создаваемой системой. Эта роль — не методолог, не проектировщик и не архитектор создаваемой системы. Его внимание обращено на огрвозможность создания, то есть оргвозможность инженерного процесса.

Организатор разработки — это сложная роль, ибо чтобы обеспечить оргвозможность, ему надо выполнить множество организационных методов/практик в разложении его метода работы (подробней будет в руководстве по системному менеджменту):

• орг-методологическую (роль методолога), в которой он разбирается с SoTA инженерных процессов в предметной области его предприятия,

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

• орг-проектировочную, где делается оргпроект — указывается, какие оргроли играются какими огрзвеньями, какие они должны иметь полномочия и ресурсы,

• лидерскую, где автономные агенты уговариваются быть не такими уж автономными, а сотрудничать согласно оргпроекту (а не вести себя независимо, или сотрудничать не так, как предусмотрено оргпроектом).

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

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

Не ждите, что везде это будет называться как-то одинаково. Практика организации разработки как отдельная практика новая, понятие жизненного цикла по факту только ушло (вместе с «управлением жизненным циклом»), «метод работы» трудно понимаем, инженерный процесс каждый инженер и каждый менеджер понимают по-своему. Так что имена будут везде разные. Скажем, в методе организации разработки SAFe¹³² (они себя называют подходом/framework, scaling agile framework, SAFe, «масштабируемый гибкий подход») определяют переход к непрерывному потоку (continuous flow) в мастерстве (competency) Enterprise Solution Delivery¹³³.

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

Вот картинка диаграммы из пятой версии SAFe¹³⁴, январь 2020:

А вот вариант этой же диаграммы из версии SAFe 6.0, выпущенной в марте 2023¹³⁵:

Видим, что «традиционные методы разработки» отступают. От сотни начальных утверждений о будущей системе и множества неотвеченных вопросов в ходе непрерывного хода разработки (flow по-русски всё-таки «ход» в случае как работ, так и разработки, хотя часто переводят и «поток») появляются уже тысячи утверждений о будущей системе, а также накапливается множество принятых решений по поставленным вопросам. Но требований как предмета метода инженерии требований уже нет (хотя какие-то отсылки к ним в других частях документации остаются, но незначительные), остаётся только Evolve the Solution Intent, постепенное формирование намерения/intent иметь конечную форму решения/конструктива системы, при этом видно, что это намерение никогда не оказывается окончательным (часть variable, то есть часть вопросов, не нулевая, а тысячи утверждений о том, какое будет решение всё-таки не формируют собой полностью намерение решения, вопросы остаются).

Мы не будем тут обсуждать сами инженерные методы, их названия, их предметы методов. Скажем, мы не будем сейчас обсуждать возможность названия концепции использования какими-то другими словами, например, «намерение разработать инженерное/программное решение» (да, тут тоже будет полно синонимов с небольшими нюансами в их использовании). И не будем обсуждать, надо ли после создания такого «намерения разработать инженерное решение» обязательно заняться документированием требований к системе (нет, не надо). За подробностями надо идти в руководство по системной инженерии.

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

Очень часты случаи, когда кто-то в проекте будет использовать старинную V-диаграмму и всё — и даже не обсуждать это, «без названий», просто работать, как будто в проекте «водопад с неожиданностями» (и у него тогда каждый день будут «неожиданности», ибо «водопад» — утопия). Кто-то будет разворачивать у себя SAFe шестой версии, ибо это промежуточный вариант между «водопадом» и полностью гибкими методами, очень удобно для крупных организаций, менеджерам которых невозможно объяснить невозможность «водопада» и объявить «всеобщую гибкость» (для них разные варианты гибкости — полная невозможность up-front планирования, это для них крушение основ их мировоззрения. Невозможно людям старой инженерной школы признать, что up-front планирование в разработке — это призрак). Кто-то будет говорить, что у него SCRUM — и использовать при этом терминологию и идеи совсем не из SCRUM. Кто-то сам сочинит для себя уникальный метод разработки, и будет прав не меньше, а может и больше, чем его соседи по проекту (но если у него нет методологического мастерства — вряд ли это будет удачной затеей).

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

Нет экземпляров предметов методов в момент эксплуатации функциональных объектов (эксплуатации/работы ролей) — нет работ с предметами работ. Работами (экземплярами работ, а не работами по их типам/паттернам/шаблонам/методам) занимается управление работами (operation management, управление операциями, операционный менеджмент в форме самых разных вариантов — проектного управления, процессного управления, управления кейсами и т.д.). Операционный менеджмент на входе принимает оргвозможности как предмет своих методов, а дальше занимается выделением этих оргвозможностей как ресурсов для прохождения всех контрольных точек в срок и в соответствии с бюджетом. Управление «инженерным процессом»/«ходом разработки» (не ходом работ!) рассматривается как инженерно-менеджерская (systems engineering management, engineering management), но преимущественно инженерная дисциплина (нужно хорошо знать практики инженерной работы). Управление работами (ходом работ!) — это чисто менеджерская дисциплина (её мастеру нужно хорошо знать практики операционного менеджмента, например, теорию ограничений и TameFlow).

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

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

Разнообразие методов управления работами

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

Какие вообще методы/практики/стили работы применять? Например, какими методами лечить пациента, когда непонятно ещё, чем он болеет? Какими методами изготавливать систему, когда ещё непонятно, какие части войдут в её состав, да и вообще ещё плохо понятно, что сама система будет делать? Это всё вопросы методологические. Но когда они отвечены и метод работ известен, в «операционном менеджменте»/«управлении работами» проводится шаг (операционного) планирования: принимается решение — кому (оргзвено, назначаемое на роль) и когда (физический отрезок времени) выполнять работы по уже известному методу работы, чтобы общая продолжительность и стоимость работ по проекту создания и развития системы были минимальны. Обратите внимание, что минимизируются общая продолжительность и стоимость работ, а не продолжительность и стоимость той работы, которая планируется. Тем самым оптимизация идёт по общему плану работ, а не конкретной одной работы.

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

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

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

Отнюдь не все работы с системой удаётся запланировать до начала выполнения этих работ, когда уже определяются бюджеты и сроки, но мало что известно про описание системы (нет ещё концепции системы, нет архитектуры, нет подробного проекта/design с точностью, достаточной для изготовления — рабочей документации, «рабочки»), мало что известно про трудности производства/изготовления воплощения системы, иногда даже неизвестно, кто будет (даже так: кто сможет) систему изготовить, причём во множестве её самых разных ожидающихся версий. То есть непонятно, что будем делать — это означает, что непонятно, кто это будет делать, непонятны создатели (в проектном управлении создатели — это «ресурсы», как сами оргзвенья, так и входящий в их состав инструментарий и необходимые для работы материалы). Предварительное планирование легко делать для проектов изготовления и сборки, когда описание системы готово. Это, например, крупное машиностроение «под заказ» при уже готовом проекте системы, строительство. Но вот детально планировать работы по описанию/проектированию сложной системы обычно не удаётся — часто даже непонятно, какие при проектировании могут потребоваться ресурсы, сколько и каких частей системы придётся разрабатывать, сколько гипотез надо будет отвергнуть, прежде чем найдётся приемлемый вариант проектного решения. И тогда используют другие методы управления работами, не требующие обязательного up-front планирования и обязательного знания норм выработки для выполняющих работы ресурсов.

Если непонятно, какие могут быть большие куски работы в задуманном проекте, то проект переименовывается в программу (которая сама будет состоять из проектов как отдельных «пакетов работ»), а метод управления работами тут — управлении программами (program management, управление программами проектов). По мере понимания содержания работ и требуемых ресурсов для проектов в рамках программы (это инженерная, содержательная работа!), в рамках программы запускаются отдельные составляющие её проекты. Каждый проект будет проходить предварительное/up-front планирование достижения своих контрольных точек (milestones), как в классическом проектном управлении. Но у программы не будет плана запуска отдельных проектов программы (только невнятные неформальные намётки, часто называемые roadmap), ибо деятельность программы как раз и состоит в выявлении этих проектов и планировании их, а дальше работы проектов управляются стандартными методами проектного управления. Скажем, roadmap может быть объявлен для создания и развития системы: создания как выпуска MVP, а развития системы — заранее будет намечено, как во времени будут располагаться какие-то версии системы с увеличивающимися со временем возможностями/фичами. Управление программами отличается от остальных методов управления работами тем, что более мелкие работы (проекты) управляются в них другим методом, нежели сама программа: в программах работ обычно нет «подпрограмм», зато есть «проекты» из проектного управления. В проектах же обычно можно найти подпроекты, в процессах процессного управления — подпроцессы, в кейсах управления кейсами — подкейсы и т.д. Все методы управления работами предусматривают разбиение работ, но методы на каждом уровне разбиения остаются теми же — за редкими исключениями, вроде управления программами проектов, которое предусматривает для своих проектов переход к проектному управлению.

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

Все эти перечисленные варианты методов управления работами потихоньку сдают свои позиции управлению кейсами (case management), которое приходит под самыми разными именами. Собственное имя «управление кейсами» она имеет разве что в медицине, а её варианты в других сферах называются очень по-разному (какой-нибудь «Kanban for development», поддерживаемый софтом issue tracker, или TameFlow с критикой Kanban как устаревшего метода операционного менеджмента).

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

Операционному менеджменту посвящён большой раздел в руководстве по системному менеджменту.

Гибкие процессы разработки и управление кейсами

Если полный список работ неизвестен, поэтому контрольные точки (milestones, моменты времени получения определённых результатов в ходе проекта) неизвестны, и ресурсы для выполнения работ тоже неизвестны, а планирование ведётся как в судебных расследованиях (case, «судебное дело») от открывающихся в ходе ведения проекта новых обстоятельств (все разработки/development именно таковы: вы не знаете, очередная инженерная гипотеза/идея приведёт к успеху, или её после неудач в инженерном обосновании придётся отбросить и придумывать что-то новое), то от самой идеи проектирования как предварительного/up-front детального планирования приходится отказаться.

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

Это «послеспиральное» поколение видов/моделей/концепций жизненного цикла получило название гибких (agile, аджайл, эджайл, более правильный перевод был бы «ловкий» или «изворотливый», но в литературе закрепилось «гибкий») методов разработки (agile development process/agile product development). И вот эта терминология «методов разработки» (которые включали в себя и методы введения в эксплуатацию, и даже методы эксплуатации/использования, практики операторов системы) по факту сейчас вытеснила понятия «жизненный цикл» и «управление жизненным циклом». Упоминания «жизненного цикла» остались по факту только в «железной инженерии» больших военных и государственных проектов, где все недостатки связанных с этими понятиями инженерных методов просто замазываются большими деньгами и большими сроками разработки.

Самые разные инженерные процессы, которые относят себя к вариантам гибких/agile подразумевают «операционную гибкость», то есть отсутствие заранее назначенного астрономического момента выполнения работы, отсутствие up-front planning/предварительного планирования. Назначение работы (то есть выделение ресурсов) на какой-то метод может произойти в любой момент проекта — скажем в любой момент, а не только в самом начале проекта можно задействовать методы разработки концепции использования. При этом Ivar Jacobson ехидно замечает, что нет таких организаторов инженерии, которые бы признались, что их инженерные процессы негибкие — даже если речь идёт о «водопадах». Ведь «всегда можно передоговориться», это же везде оговаривается. Но в гибких (инженерных) процессах это уже были не отдельные исключения с возможностью передоговориться, внезапность/незапланированность в появлении каких-то работ признаётся как основное в этих «гибких» методах. Признавалось, что учесть новые обстоятельства и передоговориться — это основное в разработке.

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

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

Общее для всех этих гибких вариантов «методов разработки»/«инженерных процессов» в том, что они используют в части управления работами управление кейсами (case management)¹³⁶. Вот классическое определение кейса — это ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведётся постепенно появляющимися обстоятельствами дела.

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

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

С проблемой кейса проводится исследование:

• Понимается причина возникновения проблемы (это может потребовать проведения дополнительных работ, они будут запланированы как подкейсы этого кейса). Скажем, трюковый самокат осматривается — находится, что разболтался подшипник (проверяются наиболее вероятные причины того, что самокат гремит¹³⁷).

• Проводится стратегирование: находится метод, который с наибольшей вероятностью решит вопрос — то есть переведёт предмет кейса в ожидаемое состояние. Метод может уже существовать, тогда говорят о «шаблоне кейса» и метод будут выполнять как «рабочий процесс» по регламенту/шаблону. Если подходящего метода нет, то стратегирование будет вестись «на лету» (а его результат, если вопрос будет повторяться, станет шаблоном кейса — но только после выполнения работ, когда «задним числом» будет описан метод, которым выполнялись работы). Это методологическая часть, она обычно намертво прикручена к диагностике, если известен шаблон кейса (template как известный метод, которым выполняются работы для проблемы кейса). Скажем, «Если гремит где-то в районе колёс, дело либо в износившемся подшипнике (под замену), либо в том, что плохо закручена ось (подтянуть)». Шаблон метода (заменить подшипник или подтянуть ось) прямо указывается для каждого диагноза. Если шаблона нет — подключаем рациональность: генерируем и проверяем гипотезы, рационально выбирая лучший метод (подключаем общий интеллект и переводим проблемы в задачи), а затем переходим к планированию для получившихся задач.

• Проводится планирование: оцениваются потребные ресурсы и время, потребное на получение ресурсов и выполнение работы (в том числе и когда метод работ неизвестен в целом, но хотя бы известны возможные первые шаги — планируются они). В результате планирования формулируется пункт плана: задача/задание на работу какого-то ресурса (task). Эти задачи назначаются на ресурсы, которые владеют соответствующими оргвозможностями/capabilities выполнять работы для определённых на предыдущем пункте методов работы. Скажем, для самоката планируется подтягивание оси, оценка времени — пара минут, работа назначена Григорию, у которого есть мастерство механика.

В результате управления кейсами в любой момент времени в проекте есть набор кейсов в разных их состояниях, кейсы из которого надо бы закрыть — и этот набор иногда называют backlog (чаще всего не переводится, так и пишут «бэклог», хотя иногда пишут «портфель невыполненных работ», но там кроме работ/задач ещё могут быть и проблемы/issues, которые часто путают с задачами). Дальше для того, чтобы определить оптимальное распределение ресурсов по этим работам, могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development¹³⁸ для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing¹³⁹) или TameFlow.

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

Инструментарий, используемый для гибких методов разработки в части управления кейсами как варианта метода управлении работами — это инструментарий трекинга проблем/«нерешённых вопросов» (issue tracking, сегодня часто их называют «системы управления задачами», ибо после issue предмет кейса становится работой/задачей, иногда это «системы отслеживания ошибок», ибо ошибка/bug — это как раз «нерешённый вопрос», «системы отслеживания поручений» — ибо каждое поручение это как раз «поручение решить проблему» или «поручение выполнить запланированную задачу»). Название отражает тот факт, что кейсы появляются не в плановом порядке сразу как «работы», они изначально представляют собой проблему/«нерешённый вопрос» (issue), требующую своего решения. Трекеры (issue trackers, софт для трекинга кейсов¹⁴⁰) учитывают эти кейсы по мере их появления. Вопросы (если они признаны важными), превращаются потом в назначаемые на выполняемые конкретными ресурсами задачи/tasks (после определения методов, которые помогут решить вопрос — и дальше планируются и проводятся работы по этим методам), а после выполнения задачи они превращаются ещё в уведомления/notices о завершении. Состояние мира изменилось после решения исходной проблемы/вопроса/issue, и нужно уведомить все заинтересованные в этом проектные роли.

Если появляется возможность что-то спланировать up-front, в управлении кейсами это обязательно делается. Но часто тут план — это просто опыт прохождения какого-то кейса в прошлом, который берётся как шаблон для будущих прохождений. Вот эти записи о прошлом опыте (взятые из папки «Дело», куда записывают всё происходящее в кейсе, case file) и будут называться шаблоном (template), если их используют для планирования повторения какой-нибудь удачной последовательности подкейсов — это и будет шаблоном/паттерном работ, то есть методом/способом работ. Если эти шаблоны (описания методов работы, а часто и оценки требуемых на работы ресурсов) готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны — шаблонами сообщества (community template).

Мы различаем:

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

• Управление работами в его самых разных вариантах (например, управление программами и проектами, процессное управление, управление кейсами — когда работы уже назначены и нужно просто их запланировать и отследить выполнение), а в рамках этих разных вариантов методы планирования работ (например, метод критического пути или критической цепи для планирования в управлении проектами, канбан для разработки или TameFlow в управлении кейсами). Управление работами (оно же — операционный менеджмент) тоже входит в инженерию организации, но это деятельность не времени создания организации, а времени использования организации. Операционный менеджер — это оператор уже готовой организации.

При этом управление разработкой (дать оргвозможность выполнения инженерного процесса, оно же оргдизайн, оно же оргразвитие, оно же цифровая трансформация и ещё сотни разных имён) и управления работами (операционный менеджмент) тесно связаны в части выбранных методов для инженерного процесса и выбранных методов для самого операционного менеджмента этого инженерного процесса. Причём оргвозможность для операционного менеджмента часто делает организатор, а не сам операционный менеджер (а функции операционного менеджера вообще сейчас переходят к операционному софту, например, тому же софту issue tracker). Важно запомнить: методы управления разработкой должны соответствовать методам операционного менеджмента. Например, если выбран agile инженерный процесс, а операционный менеджмент — классическое проектное управление, то добра не жди.

Вот схематическое изображение инженерного процесса одной из самых распространённых методологий (методология/method — ещё один синоним метода, обычно термин применяется, когда речь идёт о предписанном разложении какого-то метода получения результата «под ключ» на составляющие методы) гибкой (agile) разработки, SCRUM¹⁴¹:

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

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

Ключевые события (моменты этих событий как milestones/«контрольных точек», когда альфы будут менять своё состояние) — «выбор требований» (это довольно старая диаграмма, в 2008 году, когда эта классическая и широко распространённая диаграмма была сделана, требования ещё были одной из основных альф рабочего проекта), «демонстрация заказчикам» и т.д. Содержание работ (то есть методы/практики/способы работ) оговаривается разложением общего процесса разработки SCRUM, например, метод проведения планирующих сессий для текущего спринта, метод ежедневных совещаний. Эти методы из разложения SCRUM нужно будет задействовать, чтобы его альфы (например, альфа product backlog, альфа sprint backlog) меняли свои состояния. А дальше работы конкретных оргзвеньев::ресурсов будут менять артефакты/продукты, реализующие эти альфы.

Гибкие методы разработки — это не методы управления работами, а методы создания и развития систем. Скажем, kanban — это один из методов управления работой, TameFlow — это ругающий kanban за его многочисленные недостатки метод управления работой. И TameFlow, и kanban — они вполне могут быть использованы в сочетании с самыми разными вариантами гибких методов разработки. Об этом подробно будет рассказано в руководстве по системному менеджменту — управление работами (оно же — операционный менеджмент) тут один из составляющих методов системного менеджмента. О самих гибких методах разработки и как устроена инженерная работа — это будет рассказано в руководстве системной инженерии. Организация разработки, управление разработкой — это промежуточная дисциплина между инженерией и менеджментом. Содержание её определяется вроде как инженерами, они там обычно методологи, знают SoTA методов инженерной работы, а вот воплощение в жизнь этого содержания, то есть оргархитектура и оргпроектирование, лидерство и администрирование — это делается менеджерами.

Надо разговаривать с инженерами-технарями, чтобы достичь содержательной (как её формулирует прикладной инженер: описывая характеристики работы системы) успешности проекта, а не просто решать вопросы планирования и контроля исполнения работ для минимизации сроков и стоимости их выполнения (это вопросы операционных менеджеров: главное, чтобы «в срок и в бюджет»). Менеджеры и инженеры при этом должны договориться: если у инженеров agile, а у менеджеров up-front planning, то жди беды в проекте и постоянных скандалов. Повторим: методы разработки и методы управления работами могут быть несовместимы, и поэтому менеджеры и инженеры обязательно должны договориться. Для достижения договорённости у них должно быть какое-то знание методологии: они должны понимать природу методов разработки и методов управления работами, чтобы суметь обсудить их совместимость, а также не застревать на своих любимых методах, которые они узнали в предыдущих проектах и дальше могут или повторить — или покинуть проект, поскольку не в состоянии понять, как адаптировать метод к текущей ситуации.

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

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

При указании варианта метода разработки или метода управления работами команде не нужно говорить SCRUM, или DSDM¹⁴², или Open Kanban¹⁴³, или приводить ещё какие-то названия больших методологий со многими составляющими их методами/практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какой вид инженерного процесса использует команда и какой вид операционного менеджмента. А ещё надо убедиться, что есть оргвозможность вести работы: все члены команды имеют мастерство выполнения этих методов в целом, мастерство в выполнении их составляющих методов, имеют надлежащие ресурсы и полномочия, а также проверять, что команда идёт именно по этим методам — это и есть «организовать работу». По большому счёту, директор по развитию, главный инженер — они должны создать и развивать именно такую оргвозможность для предприятия.

Какой выбрать вариант процесса разработки? Мы крайне рекомендуем воздерживаться от даже упоминаний традиционного «водопада», всех этих «стадий» и неизбежных «требований», если у вас проект не похож на простую сборку уже спроектированной системы из стандартных деталей, например, стройка типовых многоквартирных домов. Если это стройка типового здания — вперёд, до стадии «отделка» всё будет работать, на стадии «отделка» придётся призадуматься, одни бригады будут красить, другие по свежепокрашенному делать мелкий ремонт — и никакого «водопада» и up-front плана не будет.

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

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

Начали делать концепцию использования, используя user story, потом выяснили, что проект слишком большой — и перешли на более мощную практику use cases. И заодно поменяли софт с поддержки user story на поддержку use cases. А ещё в середине проекта вдруг решили менять архитектуру системы — и по обратному манёвру Конвея (подробнее — в руководстве по системной инженерии) вдруг поплыл и оргпроект предприятия, по-другому организовали оргзвенья для ролей разработчиков.

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

Просто нужно помнить, что управляющие работами методами проектного управления всегда и во всём видят несуществующий в природе, но удобный для их рассуждений и действий «водопад», изо всех видов программирования он соответствует «пошаговому исполнению процедур», императивному программированию. Инженерные процессы (это же методы работы!) плохо отображаются императивными программами, «пошаговыми планами работ» — они лучше отображаются функциональными программами, декларативными описаниями. Поэтому классические проектные управляющие будут всегда испытывать непреодолимые трудности при попытках up-front планирования работ. Поэтому нужно работать с исполнителями ролей операционных менеджеров, сильными в управлении кейсами (например, практика/метод TameFlow или даже критикуемая в TameFlow практика/метод Kanban for development), а не в классике проектного управления. Инженерам и менеджерам будет существенно легче договориться!

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

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

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

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

В последней версии стандарта ISO 15288:2023 даже есть «6.4.1. Business or mission analysis process». Суть этого рабочего процесса — понять, какую целевую систему берётся делать команда, и определить, стоит ли её вообще делать, соответствует ли это стратегии компании, чья команда будет выполнять проект. Хотя ISO 15288 и содержит в себе отражение «водопада» в части стадий и V-диаграммы в части вида инженерного процесса, но даже однократное прохождение жизненного цикла (без развития системы) как-то надо начинать! На старте проекта готовится концепция использования (OpCon или ConOps, concept of operations, мы их не различаем, но в разных школах инженерии иногда вводят отличия), но чтобы разобраться, не утопично ли создание системы, проводится и разработка первых версий концепции системы (ибо можно написать отличную концепцию использования скатерти-самобранки, но потом обнаружить, что её не из чего сделать, система утопична).

Окончание жизненного цикла системы на сегодня обычно не планируется, хотя вполне могут обсуждаться ожидания по выпуску первой версии продукта (обычно это MVP — minimal viable product¹⁴⁴, минимальный жизнеспособный продукт, который и будет потом развиваться).

Дальше система может модернизироваться так, что в её воплощении не останется уже ничего от предыдущей. Берём швабру, через некоторое время ломается ручка, меняем ручку, потом меняем перекладину — это та же швабра? Да, это та же швабра-система (функциональный объект тот же!), только поменялись какие-то модули, конструктивные части. Швабра определяется по её функциональному описанию, если заменить наполнение конкретными модулями или даже поменять размещение, ничего страшного с системой не произойдёт — она останется существовать. Телефон остался телефоном, хотя там уже давно нет проводов, трубки, кнопок номеронабирателя, ни одного элемента классического телефона, просуществовавшего больше сотни лет. Но осталась функция передачи звука на расстояние: теле (далёкий) фон (звук). Хотя и это уже не главная функция, телефоны перестали звонить и используются как терминалы доступа к интернету — а звонки массово заменяются чатами.

Microsoft объявила, что Windows 10 будет её последней операционной системой, при этом непрерывно производит в ней изменения (выпуск Windows 11 широко обсуждался как имеющий чисто маркетинговое значение, смена названия не привела к тому, что сам продукт существенно изменился, более того, изменения в Windows 11 проходят примерно так же, как в Windows 10 — программы и функциональность потихоньку меняется, но не меняется имя продукта. Просто одни программы в составе Windows потихоньку меняются на другие, это происходит уже много лет). Срок службы атомных электростанций сначала делали 60 лет, но сейчас продляют его до 80 лет, проводя частичные модернизации — при этом часть стран хотят избавиться от атомных станций, а часть стран как раз хочет развивать атомную энергетику. Тесла придумала софтверные изменения для автомобиля, поддерживающие его ценность путём модернизации по ходу эксплуатации, электромобили Tesla не нужно вовремя продавать, они перестают морально устаревать: это изменение бизнес-модели автомобильной промышленности¹⁴⁵.

Жизненный цикл системы оказывается не содержащим чёткое заранее определённое число проектов перед выводом из эксплуатации/уничтожением после использования, и может не иметь чёткого срока окончания. И тем самым понятие «жизненного цикла» перестаёт быть важным. Можно говорить о жизненном цикле организма динозавра, но труднее говорить о «жизненном цикле» вида динозавра, который потихоньку за десяток миллионов лет, или чуточку подольше превратился в птичку. Это уже «ход эволюции» (развития системы, изменения в геноме, ведущие к изменению фенома), а не «жизненный цикл» создания одной системы (геном воплощается в свой феном, феном «прокачивается» и используется — и конец истории). Третье поколение системного мышления привело к тому, что мы говорим о создании и развитии системы, а систему понимаем уже как множество экземпляров системы, которые представляют собой разные версии системы. Это похоже на то, как мы воспринимаем биологические виды в ходе эволюции: тех же динозавров, превращающихся в птичек — и, конечно, это рассмотрение идёт на более длинных промежутках времени, чем время жизни одной версии системы. Операционные системы Android и iOS имеют уже огромное количество версий, каждая версия разрабатывается по полгода-году, но сама разработка этих операционных систем как видов систем занимает уже полтора десятка лет (первая версия Android вышла в сентябре 2008 года, первая версия iOS вышла в июне 2007 года, развитие этих систем продолжается).

В атомной промышленности даже случилась терминологическая коллизия: управлением жизненным циклом (lifecycle management) там называют не методы управления жизненным циклом из системной инженерии, а методы продления срока эксплуатации атомных станций¹⁴⁶! К счастью, по мере распространения знаний системного мышления среди работников атомной промышленности, значение термина меняется на общепринятое.

С вот этой бесконечной/неоканчивающейся/открытой/open-ended¹⁴⁷ разработкой связан ещё один вариант показа стадийности инженерного процесса — как развёртки во времени выпуска версий какой-то системы, roadmap/дорожная карта. Этот термин пришёл из проектного управления¹⁴⁸, но всё чаще используется для показа ориентировочных сроков выпуска версий системы. Вот пример инженерного процесса, показанного как жизненный цикл спиральной модели с заданным прохождением водопада несколько раз, с упором на методы не столько инженерии или менеджмента, сколько предпринимательства¹⁴⁹ — и эта диаграмма приведена в совмещении с диаграммой типовой дорожной карты (roadmap, показаны три версии продукта разной степени готовности):

JTBD: клиентоориентированность? Нет, метод-ориентированность!

Мы стратегируем — и получаем по итогам стратегирования стратегию::метод создания и развития системы, планируем и проводим работы по этому методу, отслеживаем в ходе разработки в конечном итоге альфу (воплощения) целевой системы, которая должна будет удовлетворить потребности (needs) внешних проектных ролей. Некоторые из этих внешних проектных ролей обычно скрываются за словами client, customer, user, consumer. То, что в системном подходе было «от границы целевой системы смотрим сначала всегда наружу, в поведение в окружении во время эксплуатации», в бизнес-литературе выражается тем, что в название методологии разработки вставляют какой-то синоним (как обычно, тысячи их) ориентированности на клиента/заказчика/пользователя и добавляют focused, centered, driven, first, oriented или даже obsessed в название метода (в том числе бизнес-стратегии, метода разработки, предоставления сервиса, организационной культуры — слово "метод/процесс" тут тоже имеет множество синонимов):

• Customer-focused

• Consumer-focused

• User-centered

• User-centric

• Customer-driven

• Client-focused

• Market-oriented

• Customer-first

• Customer-obsessed

• Customer-led

• Human-centered

• Client-driven

• User-driven

• Customer-oriented

• Service-oriented

• Audience-focused

Напомним, что первое поколение системного подхода делало акцент на технические процессы и минимальное внимание на клиентах (1950-1980-е), ещё до водопада была модель code-and-fix, структурное программирование, затем «водопад» (предложен Winston W.Royce в 1970, хотя он сам и не использовал слово «waterfall»).

Второе поколение системного подхода заметило людей-создателей и внешние проектные роли. После чего заговорили о прототипировании (1980-е) и спиральной модели (1986), в программировании возникла идея reuse и объектно-ориентированного программирования для переиспользования (потом эта идея была похоронена архитекторами: «повторное использование» оказалось лазейкой, в которую проникали лишние зависимости между модулями). Но там уже была замечена внешняя проектная роль User — и в HCI (human-computer interaction как одной из ветвей software engineering) появился UCD (user-centered design, 1980-1990e). И уже опираясь на это, появился agile с его манифестом в 2001 году и идеями активного сотрудничества с клиентом в ходе разработки. Примерно в это же время (2000е) — идеи lean development в agile, где пытались применить принципы Toyota manufacturing system, lean construction в строительстве с тщетными попытками планировать непланируемое.

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

Третье поколение системного подхода с учётом времени эволюции и самой возможности эволюционирования систем (evolvability), инженерной идеей "непрерывного всего" в разработке (прежде всего «непрерывная сборка» и «непрерывный ввод в эксплуатацию») начинается в 10е годы 21 века, с идей lean startup и дальше с переходом от стартапов к управлению инновациями (innovation management) как выражению той же самой идеи, но уже не только для стартапов, а для всех.

Идея lean была взята у производственников (Toyota production system). Она означала, что не должно быть лишних работ. «Ничего лишнего», lean/элегантно — но не только при производстве, но даже и при задумывании продукта, в стартапе. Но как узнать, что там лишнее, а что нет?

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

В случае людей, наконец, признали, что людей нельзя заставить пройти через стадии обработки, которые дают гарантированные результаты. И надо смотреть на ситуацию не только с точки зрения желающего что-то сделать с клиентом, но и наоборот — с «точки зрения»/«позиции восприятия»/«индекса отсылки»/«referential index» клиента.

Появляется множество разных прикладных методологий клиентоориентированности, слово customer становится центральным. Во всех, конечно, voice of customer с неизбежной критикой, ибо customers при их опросах не могут высказать невысказываемое («изречённое дао — не настоящее дао»), говорят одно, а делают другое, вообще не ощущают свои «боли» и даже не догадываются, что у них болит (ибо надо было находить даже не «потребности», а «боль», чтобы уж точно было желание купить лекарство от этой боли), долгосрочное стратегирование у клиентов вообще на нуле и влиять на него оказалось нельзя — и так далее, список критики этих методологий учёта «голоса клиента» длинный. Поэтому первое же развитие в этой предметной области сдвинуло «голос клиента» (понимающийся как голос персонажа из какой-то «целевой аудитории» — аудитория задавалась образом жизни, возрастом, полом и прочими демографическими характеристиками) на метод работы, который хочет выполнять клиент в своих работах, и дальше смотреть на проблемы этого метода. При этом то, что было важно раньше (возраст, пол, семейное положение и т.д.) абстрагировалось. Внимание начало уделяться методам/функциям, поэтому для новой теории клиенториентированности в разработке термин был предложен jobs to be done, а не works to be done. Важным оказалось то, что делает клиент, метод его работы, и это уже было выделение действительно важного — не надо было гадать, что там выделять из всего «потока сознания», который выдавал клиент и который предлагалось хоть как-то учитывать в ранних методологиях клиентоориентированности.

Outcome-driven innovation¹⁵⁰ от Anthony Ulwick, "What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services", 2005. Первый документированный успех «инноваций, ориентированных на общий результат» (outcome), а не на частный результат одной операции (output) был в 1992, патенты по методологии Ulwik получал ещё с 1999 года, затем публикация в HBR в 2002 году, затем — книжка в 2005¹⁵¹. Формально JTBD theory была создана в 1990. В 1990 Ulwik предложил, чтобы компании прекратили фокусироваться на продукте и на клиенте (при этом термин был, помним, «клиентоориентированность»!). Вместо этого компании должны были разобраться с “underlying process” (or job), который клиент пытается выполнить, когда он использует продукт или сервис компании. Грубо говоря, «думай про метод/job, который задействует конечный потребитель, используя продукт или задействуя сервис». Это явная отсылка к методу (job ведь это не «работа» в смысле work, это работа в смысле «занятость каким-то видом труда»). По факту Ulwik в 1990 году предложил искать сигнатуру метода (что с чем клиент хочет делать, и зачем), а дальше компании могли бы предлагать другое разложение метода с использованием своего инструмента. Клиент тогда «наймёт на работу» твой продукт, если метод с твоим продуктом будет получше (дешевле, быстрей, приятней). Всё то же самое, но другая терминология — и оттуда объяснение через какой-то определённый набор метафор.

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

С идеями Ulwick по outcome-driven development довольно рано ознакомился Christensen (тот самый, который предложил в 1997 году термин «disruptive innovation» и написал «Дилемму инноватора»), он и популяризовал подход с некоторыми добавками своих примеров — он и дал название Jobs-to-be-done (с альтернативным термином-синонимом «outcomes that customers are seeking»), в книге 2003 года «The Innovator Solution», когда идеи Ulwik были известны только по публикации в HBR, то есть ещё раньше, чем вышла книга самого Ulwik.

Подход outcome-driven innovation тем самым начал пониматься как происходящий на основе Jobs-to-be-done theory, которую затем тащили в разные предметные области за пределами b2c. В 2016 году Ulwik выпускает книжку уже с термином в заглавии «Jobs to be Done: From Theory to Practice», где показывает, как теорию превратить в рабочий метод. В том же 2016 году выходит аналогичная книжка Christensen с вариантом этого фреймворка, «Competing Against Luck».

Если сделать этот трюк со сдвигом внимания на метод работы клиента с использованием продукта (job to be done), то Ulwik отмечает многие изменения в онтологизации маркетинговых рассмотрений¹⁵²:

• The unit of analysis is no longer the customer or the product, it’s the core functional “job” [не просто job, а functional job — это чтобы вы не перепутали с work, job тут не синоним для work!] the customer is trying to get done.

• Markets aren’t defined around products, they are defined as groups of people [сообщества!] trying to get a job done [сообщества объединяются по общим методам/культурам/занятостям своих участников, «занятости» тут отсылают к job]

• Customers aren’t buyers, they are job executors [это у нас исправление ошибки «моментом использования системы будет момент её покупки» выпячивание клиента не как пользователя, а как покупателя. Это самая частая начальная ошибка студентов кафедры технологического предпринимательства, а также тех инженеров-менеджеров, которые себя считают «чистыми менеджерами» — им же надо прежде всего продать, а там хоть трава не расти! Нет, моментом использования будет момент эксплуатации/работы/функционирования системы или результата сервиса].

• Needs aren’t vague, latent and unknowable, they are the metrics customers use to measure success when getting a job done. [эта тема выходит на actionable metrics, что требует вообще отдельного разговора — но об этом мы расскажем позже]

• Competitors aren’t companies that make products like yours, they are any solution being used to get the job done [аффордансы могут быть очень разными, а всё новое приходит сбоку — под конкретную сигнатуру может прийти аффорданс совершенно другой природы, это мы подробно разбираем в теории стратегирования в последнем разделе нашего руководства].

• Customer segments aren’t based on demographics or psychographics, they are based on how customers struggle differently to get a job done. [это мы обсуждаем как переход от «метода персон» к рассмотрению методов и внешних проектных ролей не просто «клиента», а уточняющих эту роль — скажем, «игрок» (и даже разные подклассы игроков, если речь идёт о профессиональном геймдизайне), а не просто «клиент». Интересно, что JTBD постулирует акцент на методе, роль и её именование по сути опускается — чтобы сразу перейти к «сообществу как группе с какими-то культурами работы», но рассуждения с точно названной ролью обычно проще]

В jobs-to-be-done и тем самым outcome-driven innovation стараниями главным образом Clayton Christensen¹⁵³ (самый активный популяризатор теории) появились самые разные варианты понимания метода работы, например:

• Методы-действия (помним, что тут jobs как методы, которыми работает клиент, а не система) как действия (activity), где прямо пишутся «функциональные шаги» (простейшее императивное разложение метода), которые клиент должен предпринять в работе, чтобы получить результат. Инкрементальные улучшения, акцент на «что клиент делает». Это основная линия рассуждений Ulwik, «рабочие процессы клиента с вашим продуктом».

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

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

Популярность тут пришла и из-за того, что огромное число крупных компаний начали использовать ровно вот эти рассуждения, чтобы выяснить эти самые customer jobs — и дальше предложить продукты с улучшенным восприятием/eXperience того, как прошло задействование метода (грубо говоря, ищется вариант впечатления «мне понравилось, как я сработал вами предложенным методом»). Поэтому появилось огромное число success stories и case studies, в вузах пошло массовое обучение теории JTBD.

JTBD отлично интегрируется со многими клиентоориентированными методологиями разработки, они же — маркетинговые методологии (в классическом понимании маркетинга: определить, чем будет выгодно торговать — и найти аргументы для объяснения клиенту его выгод). Конечно, есть огромное число публикаций по поводу этой теории и результирующего современного фреймворка. Вот, например, картинка из исследования 2020 года с альтернативной версией истории JTBD, преодоление противоречий между job с идеей process и идеей progress, но через job steps, и вы сами с использованием материала нашего руководства отойдите от императивного представления процессов в этой картинке¹⁵⁴:

Для «людей с улицы» возникает вопрос «зачем так сложно о простом»? Затем, что «так сложно» можно рассуждать потом не только о простом. Более того, популярность JTBD сегодня велика, но простой эту методологию не назовёшь, в ней множество нюансов. Но если разобраться с методологией как фундаментальным методом мышления, то рассказы о разных прикладных методологиях (вроде той же JTBD) становятся примерами методологической работы. И будет сразу очевидно, что там просто, а где простота только кажется.

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

Пример методологии маркетинга: customer eXperience management.

В нулевых годах сделали несколько замеров: оказалось, что впечатления по поводу товаров и сервисов самих клиентов и работников фирм, которые продают эти товары и сервисы, разительно различаются. Конечно, у всех фирм в этот момент уже победили идеи TQM (total quality management)¹⁵⁵, и идея о шикарном качестве товара была реализована. Но это качество не связывалось с впечатлениями клиентов — качество шло как отсутствие дефектов! Идеи шести сигм¹⁵⁶ — это 3.4 дефекта на миллион изделий, не больше, меньше сигм — больше дефектов, так что стремимся к бездефектности на уровне шести сигмам! И вдруг — у нас качественнейшая продукция, но покупают товары конкурентов, ибо плохие впечатления у клиентов оказываются не от бездефектного товара, а от эстетики упаковки, навязчивости рекламы, репутации фирмы (у которой могут быть проблемы не с товарами, а чем-то другим), что угодно. Жизненный цикл (тогда ещё мыслили этими терминами) клиента оказывался не весь проходящим по рабочим процессам, которые проектировались создателями «лояльного клиента» из «просто людей» как сырья. Ключевым там оказались впечатления/experience людей, которые они получали в ходе проводящегося над ними инженерного процесса. У неживых систем впечатлений не было, у животных впечатления мало волновали, а вот у людей, если речь идёт о торговле как добровольных обменах, впечатления оказывались главным объектом внимания в проекте! Так, в маркетинге появился термин «клиентские впечатления»/«customer experience».

Впечатления/eXperience клиент получал в ходе взаимодействия с товаром (в том числе обнаруживая, что товар некачественный), фирмой, брендом, сервисом и чем угодно. «Чем угодно» — это важно, это особенно подчёркивалось. Ход тут был на преодоление сложившегося разделения труда продвиженцев, то есть преодоление границ отдельных функциональных единиц вроде «маркетинга», «рекламы», «продаж», «производства», «обслуживания», «клиентской поддержки». Этот же ход отслеживания впечатлений будущего клиента во время всего его превращения «из человека в клиента, и даже пропагандиста продуктов и сервисов фирмы» шёл и на преодоление границ отдельных каналов коммуникации фирмы и потенциального клиента: разделение труда было по организации онлайн и оффлайн каналов коммуникаций по продвижению и получению обратной связи, а также доставке товаров, сервисов, впечатлений, поддержке сообществ и т.д. И этот же ход на «проектирование и затем отслеживание всех возможных впечатлений по поводу нашей фирмы, товаров, сервисов» был ещё и на преодоление ограничений идей жизненного цикла как однократного его прохождения, преодоление идеи о том, что речь идёт о «транзакции», одной сделке, однократном прохождении по какой-то «воронке продаж». Всё то же самое, что происходило с пониманием «жизненного цикла 1.0» в инженерном процессе, параллельно происходило и в маркетинге как «инженерном процессе» создания и развития клиента — менялись поколения, происходил переход к agile методологиям.

Продвиженцы (маркетологи, рекламщики, «продажники») поняли, что:

• никому не нужны дрели или сверлильные сервисы,

• но никому не нужны и дырки в стене (outcome-based innovations, смотрим, на что надо нанять наш товар-дрель, идеи JTBD),

• нужны впечатления о том, как хорошо дрель или сверлильный сервис делает дырки в стене и какие чудесные после этого дырки, дополненные впечатлениями о том, как легко было купить дрель, какая она красивая, как приятно лежит в руке, как бесшумно делает дырку, как вежливо общается служба поддержки, если с дрелью что-то не так, как легко эту дрель продать на вторичном рынке дрелей, если она мне не будет долго нужна. Эти впечатления должны быть лучше ожидаемых среднерыночных впечатлений!

• Никакое впечатление не является последним, двигать надо в получение лояльности — и там cross-selling¹⁵⁷, upselling¹⁵⁸, организация сообществ и так далее. Всё в маркетинге не заканчивается первой покупкой клиента, но превращается в непрерывную череду покупок. Ещё оказался возможен сдвиг части работы фирмы на клиента, причём не только перевод на «самообслуживание», но и на помощь другим клиентам в использовании продуктов и сервисов, а также помощь в самом в продвижении, можно уговорить клиентов делиться впечатлениями о продукте и сервисе, советовать бренд друзьям. Для фирмы оказалось важным делать постоянный приток положительных впечатлений потенциальным клиентам до, во время и уже реальным клиентам после сделок — и сделок этих должно было стать побольше. В том числе продукты и сервисы, а также ожидаемые впечатления даже без изменения продуктов и сервисов надо постоянно менять в ходе «непрерывного всего» — и тут идея рыночных гипотез и их обязательной проверки, а также невечности «рыночного окна».

Итого: важно не просто, чтобы job to be done, но важны положительные впечатления, которые будут получены по ходу выполнения работы внешними проектными ролями.

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

Тренд перехода от торговли товарами и сервисами и только иногда (индустрия развлечений) впечатлениями к торговле исключительно впечатлениями получил название «экономика впечатлений».

Речь идёт о границе тысячелетия, надувался инвестиционный пузырь доткомов¹⁵⁹. Компании тогда временно продавались не на основе уже оценки того, сколько они могли бы заработать, а на оценке того, сколько они привлекли клиентов, вбрасывая практически все полученные от инвесторов деньги в рекламу, а не в разработку продукта. А прибыли? Была надежда, что «много клиентов — много прибыли!». Тогда и появилась странная экономическая идея, что клиентам ничего не надо, кроме вау-эффекта, впечатлений/experience, чтобы купить продукт или сервис.

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

По экономике впечатлений (experience economy¹⁶⁰) в 1998 году вышла статья, в которой говорилось, что после аграрной, индустриальной и даже самой последней, сервис-ориентированной экономики, появился новая экономика — впечатлений. От «хлеба и зрелищ» вроде как перешли к экономике главным образом «зрелищ», ибо товары и сервисы в жизни оказались не главными, в последнее время торговля идёт впечатлениями. В следующем году (1999) вышла уже книжка Pine II и Gilmour, «The experience economy», первое издание. Всё (помним: это был бум доткомов) указывало на то, что и вправду: кто тебя удивил, тот и выиграл, а продукт, сервис и все эти jobs-to-be-done — не так уж важны. Кто даст более сильные впечатления (даже если это впечатления от фильма ужасов — поэтому воспринимаемые положительно, даже если это впечатления радости и счастья от полуобморочного состояния после марафонского пробега или побитости после выхода на боксёрский ринг), тот и победил — поэтому жизнь пойдёт по пути виртуальной реальности и погружения клиентов во впечатления, которые должны приходить к клиентам по всем каналам. А товары и сервисы? Ну, они будут, как остались продукты питания от аграрной экономики, товары длительного спроса от промышленной экономики, какие-то сервисы от сервис-ориентированной экономики. Но всё остальное — это торговля впечатлениями, причём «по проводам» (включая марафонский бег в виртуальной реальности, боксёрский бой в виртуальной реальности, и т.д.). То, что где-то там далеко в Африке люди умирают от недостатка таких товаров как вода и еда, а также таких сервисов, как медицинское обслуживания — ну, это временная трудность, экономика развлечений должна была дойти и до Африки.

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

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

В 2011 году Pine II и Gilmore переиздали апдейт своей книжки по экономике впечатлений 1999 года¹⁶¹. Редакция её анонсировала так: «В 1999 году Джозеф Пайн и Джеймс Гилмор предложили эту идею читателям как новый способ думать о связи с клиентами и обеспечении их лояльности. В результате их книга «Экономика впечатлений» теперь стала классикой, принятой читателями и компаниями по всему миру и прочитанной более чем на дюжине языков. И хотя с тех пор мир во многом изменился, путь к сердцу клиента остался прежним. На самом деле, идея постановки впечатлений, чтобы оставить памятное — и прибыльное — впечатление, сейчас актуальна как никогда. С постоянным потоком брендов, атакующих потребителей со всех сторон, как вы можете выделить свой? Добро пожаловать в новую Экономику впечатлений. В этом полностью обновленном издании книги Пайн и Гилмор ещё убедительней доказывают, что впечатления — это недостающее звено между компанией и её потенциальной аудиторией».

Как всегда, надо быть внимательным к типам. Онтология experience (или даже eXperience, для пущего впечатления) в текстах customer eXperience-- то ли сам процесс вовлечения/engagement во взаимодействие (метод вовлечения), то ли само взаимодействие (результат вовлечения, которое тоже взаимодействие для получения целевого уже взаимодействия — например, «уговорить посмотреть рекламу», там «уговорить» — вовлечение, а само взаимодействие — «просмотр рекламы»), то ли впечатление от этого взаимодействия («понравилось, как меня уговорили посмотреть рекламу, понравилось, что я её посмотрел, впечатлён рекламой, имею настрой купить!»).

Одна из проблем в том, что разные люди по-разному понимают тип experience в customer experience — ровно так, как по-разному понимали тип job в job-to-be-done. Мы это разбирали чуть раньше, но напомним:

• Job to be done как цель работы и меру прогресса («нужна дырка в стене», это outcome в outcome-driven innovations — и в том числе тут всякие эмоции и впечатления, социальные последствия и прочее, как варианты outcome, которые появились не так сразу в обсуждениях, но всё-таки появились. Как раз customer experience тут, и по этой линии в обоснование обычно идут разные «теории мотивации» из психологии, нейропсихологии, социопсихологии).

• Job to be done как собственно процесс («сверление дырки в стене дрелью»), метод, который в какой-то момент будет работой. Никакой «психологии», но методология (метод надо описать и оптимизировать), а также операционный менеджмент (ресурсы и время на выполнение работы по методу надо оптимизировать).

Всё то же самое надо повторить для experience — это то ли outcome от процесса, ведущего к прогрессу в достижении цели («позитивные впечатления»), то ли сам процесс получения этих впечатлений. Если почитать тексты про customer experience management — то там онтологический винегрет, проявляющийся в самых разных определениях customer experience::

• Totality of Customer (mental, subjective) Responses¹⁶². Customer experience is the internal and subjective response customers have to any direct or indirect contact with a company. При этом квалификаторы в тексте, где встречается это определение — good, positive, enjoyable, и вдруг driving в смысле «опыт вождения» (там упоминается BMW) — другое словарное значение! Или «драйвовое» в смысле «бодрое, побуждающее»? А ещё internal, ineffable. «Response to contact with a company» — это по-русски «опыт» или «впечатление»? Противопоставляется тут experience ожиданиям/expectations: Customers instinctively compare each new experience, positive or otherwise, with their previous ones and judge it accordingly — опыт (даже «опыты») оцениваются тут по сравнению с ожиданиями, или "впечатления"? У вас совокупный ответ на то, как вы куда-то спутешествовали (чуть позже мы введём термин «путешествие» и даже термин «контакт», хотя он будет touch, а не как в этом определении contact): опыт этого путешествия, или впечатления от него? А поскольку это «ответы на контакт», то неожиданно там будут когнитивные, поведенческие, сенсорные, социальные ответы — какое тут понятие и поэтому выбранное для перевода слово? «Когнитивные, поведенческие, сенсорные, социальные опыты», или «когнитивный, поведенческий, сенсорный, социальный опыт» (потеряли множественность в накоплении опыта по ходу путешествия), или таки «когнитивные, поведенческие, сенсорные, социальные впечатления» от взаимодействия в «точках контакта» (touchpoints)? В любом случае, это про «ментальное субъективное состояние». Сюда же — experience как impression, тут однозначно «впечатление». Поэтому дальше по этой линии — те самые теории мотивации (грубо говоря, психологические и иногда психосоциальные теории, которые очень плохо работают — если кто-то начинает задействовать такую теорию, а начинают это сейчас делать более-менее все маркетинговые службы, то через несколько соприкосновений с паттернами из этих теорий у вас будет «маркетинговый иммунитет», и результат будет обратным, впечатления негативны, мотивации не будет¹⁶³).

• Sum of interactions, то есть сами взаимодействия «в жизни», из нейтральной внешней позиции восприятия (и уже им потом будет даваться внутренняя субъективная оценка успешности с позиции восприятия клиента). Experience тут — это как «опыт по физике», поведение взаимодействия, а не ментальное состояние. Ментальное состояние будет результатом, «ответом на взаимодействие», как в Totality of Customer responces. То есть experience — это те взаимодействия, которые были у клиента с чем-то, связанным с фирмой в точках контакта. Тут методологическое рассмотрение, «сумма процессов взаимодействия» или рассмотрение операционного менеджмента — «сумма работ взаимодействия». Но и тут можно легко запутаться, потому как часто встречается различение взаимодействий (самый узкий класс), вовлечений (класс пошире) и «опыта»/«впечатлений»¹⁶⁴. Например, «сustomer experience (CX) is all the interactions customers have with your company at all stages of the customer journey. Whether it’s a call to customer service, observing an ad, or something as simple as paying a bill, every exchange impacts how a customer perceives a business»¹⁶⁵.

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

И даже сокращение experience в customer experience делают двоякое — или СE, или CX (customer eXprerience), а поскольку впечатлениями хотят управлять, то методология получила название customer experience management — и там тоже или CEM, или CXM, никакого однообразия не наблюдается. В английских текстах с использованием experience онтологический винегрет, не ждите пощады, это buzzword — модно, модно уже пару десятков лет, поэтому будет задействовано в самых разных значениях, которые ему хотят приписать. Как разбираться? Как всегда в таких случаях: отслеживать типы, значения типов брать из контекста.

«Управление клиентскими впечатлениями»/«сustomer experience management» как методологию можно считать устоявшимся с 2003 года, когда появилась книжка профессора маркетинга Bernd H. Schmitt «Customer Experience Management: A Revolutionary Approach to Connecting with Your Customers»¹⁶⁶. Там главное слово вообще не experience, а experiential (по ссылке доступен список наиболее часто встречающихся терминов) — экспериментальный, основанный на эксперименте как опыте, а эксперимент основан на измерениях. Вопросы тут про то, чей опыт (роль) и чего именно опыт (метод). Обычно в customer experience management обсуждался опыт продвиженца (маркетолога, рекламиста, продавца), который или умел что-то продавать, или не умел. Много меньше это был опыт разработчика, который создавал новый продукт (разработчики в этой «серой зоне» между инженерией и маркетингом выбирали более узкие и простые методологии, типа JTBD, и их не интересовал «весь опыт»).

Разворот от классического продвижения 20 века в это новое продвижение 21 века был в клиентоориентированности: эти эксперименты/опыты с компанией вёл клиент, и опыт взаимодействия, вовлечения, получения впечатления был его — а не опыт продвиженца! Смена позиции восприятия: «деталь, обрабатываемая маркетингом, рекламой, продажей» оказалась не пассивной «деталью», а она что-то там тоже делает, что-то чувствует, и в конечном итоге решение принимает не «создатель клиента», а сам «создаваемый клиент»!

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

В русском языке с этим CEM/CXM тоже всё плохо, так что я дам какие-то англоязычные термины для самых разных понятий этой методологии и к ним дам комментарии по переводу на русский. Суть подробного разбора терминологии CEM/CXM в том, чтобы вы получили пример разбирательства с методом, как он встречается в жизни:

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

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

• Цели научить вас чему-то в области CEM/CXM нет, для этого вам придётся почитать литературу. Хотя сразу скажем, что тамошний подход серьёзно сейчас критикуется за то, что метрики «впечатлений» оказываются non-actionable (то есть ты получаешь метрику, по метрике видишь, что «клиент недоволен», но абсолютно не понимаешь, чем недоволен, что с этим делать, с кем на эту тему в компании разговаривать), а также замеры всех этих метрик приводят к тому, что клиент взвывает (когда ему на каждый чих от компании предлагают заполнить пятиминутный обзорчик, «что вам понравилось, что не понравилось, и почему, порекомендуете ли вы наш сервис ещё кому-то» и пресловутое «ваше мнение очень важно для нас» при полном понимании, что там идёт какой-то дикий поток этих откликов, и ваше индивидуальное участие точно потеряется).

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

Вот эти термины и комментарии к их возможному переводу на русский (повторим, что вы должны соотнести понятия этой мета-модели с понятиями мета-мета-модели из наших руководств для инженеров-менеджеров):

• customer — (поэтому это всё из customer-centric методологий), получатель товаров, сервисов и впечатлений (эти впечатления — из experience economy), которые поставляются/provided by компанией.

• customer experience традиционно или «опыт», или «впечатления»¹⁶⁷. Мы уже обсудили, что под customer experience понимается много чего разного: то ли то, что делает клиент (происходит с клиентом), то ли то, что ощущает при этом клиент. Да, сюда включают и что-то знаниевое/познавательное/cognitive, и даже «социальное» (помним критику Фридриха фон Хайека термина «социальный» — когда сказать нечего, то добавляют слово «социальный», как будто это что-то объясняет, например тут — «социальные впечатления» или «социальные взаимодействия»: непонятно, как именно они отличаются от «не социальных»). Примерно в эти же годы, когда появлялась customer experience methodology, появилось много и других методологий с терминами experience и experiential, там и experiential retail¹⁶⁸, и experiential learning¹⁶⁹ (и все из них содержат похожие слова и отсылки, поэтому в литературе нещадно перемешиваются). Даже event marketing¹⁷⁰ определяется как experiential marketing.

• touches — контакты, то есть взаимодействия, вовлечения, а иногда и "локальные приращения опыта" (и не пытайтесь разобраться, все авторы тут вкладывают свой смысл), которые происходят в точках контакта.

• touchpoint — точка/пункт контакта, где контакт — это те самые touches, «процессы» то ли вовлечения, то ли взаимодействия, то ли «соприкосновения» (авторы тут намеренно говорят мутно, часто добавляют что-нибудь типа «и всё что угодно»). Подразумевается, что компания тщательно создаёт эти точки контакта, это инфраструктура выдачи/получения (тут как «приёмка-сдача», это же взаимодействие) впечатлений. Конечно, в литературе вы увидите дикую путаницу — touchpoints будут типа «процесс», путаться с самими touches, которые там происходят. И да, «контакт» как синоним «точки/места контакта» и «контакт» как «происходящее в месте контакта» — они тоже регулярно путаются между собой. Можно вообще переводить это как «ловушка», ибо компания в ходе customer journey ловит клиента и пытается впечатать ему нужные впечатления, "гипнотизировать" (подробней в «Иммунный ответ мокрой нейросетки на "маркетинг»¹⁷¹). Сначала «анализировали», современные версии говорят о «тщательном проектировании», но признают, что большинство взаимодействий случайно.

• channel — иногда специфицируют «канал», по которому происходит touch клиента с touchpoint, например, пришло письмо по почте, или через чат, или через почтовый ящик, или вы поглядели сообщение в «личном кабинете», или кто-то позвонил и сказал. Поэтому «просто» experience (который путают, как мы помним, с совокупностью всех touches или же «всеми взаимодействиями» и «вовлечениями») часто называют omni-channel experience, то есть явно добавляют ещё «общности». Добавить общности — это в customer experience любимый приём, хотя и приводится множество примеров, чтобы было хоть какое-то заземление. В итоге в голове остаётся приятный онтологический туман, сопровождаемый множеством примеров, по которым каждый строит своё собственное представление о понятии.

• customer journey — чаще всего «путь»::«траектория по точкам контакта», но тогда отсекается «путешествие»::процесс::поведение, в котором были получены впечатления! Если это «путь», то легко его увидеть на карте. Путь как последовательность прохождения точек контакта, часто весьма запутан и уникален для каждого отдельного клиента. Сначала это был пошаговый путь по специально спроектированным ловушкам/touchpoints с «промывкой мозгов»/touch клиента с целью дать клиенту позитивные впечатления и добиться каких-то последовательных состояний клиента на каждом маршруте (по факту этот journey мыслился как жёсткая последовательность обработок в «воронке продаж», говорили о «причудливом маршруте», но рисовали жёсткие «шаги процесса»). Затем маркетинговые методологи признали, что не могут повлиять на то, как и в какой последовательности клиент попадает в ловушки, причём часть этих ловушек не они сами ставили (скажем, клиент попадает к недовольному брендом другу и тот рассказывает пару анекдотов о плохих собственных впечатлениях), перестали рисовать жёсткие этапы «жизненного пути/цикла клиента» (перестали говорить о «воронке продаж»). Путь клиента становится не линейным, а графом общего вида, а после того, как наступает понимание, что никакая сделка не является последней, ещё и с кольцами. И это не конец истории, ибо пришлось признать, что путь клиента пролегает и через незапланированные контакты (типа того же «друга, который отговаривает от покупки» или «маркетплейс, где можно найти с отзывы других клиентов», причём клиенты уже отлично распознают фейковые отзывы, проплаченные маркетологами). И ещё всё это происходит в незапланированные моменты времени, так что графовое представление оказывается неадекватным, надо говорить об управлении кейсами. Experience design — это когда пытаются спроектировать впечатление по всем точкам контакта в клиентском путешествии, по какому бы пути оно ни пошло. В какой-то мере это похоже на проектирование игр: игрокам должно казаться, что они делают какие-то собственные выборы, но в реальности их неумолимо ведут по серии каких-то действий, в конце будет какой-то босс, затем запланированный переход на следующий уровень — и для игродела там нет никаких случайностей, а для игрока — вроде как полностью его собственные уникальные выборы. Клиент же попадает в «маркетинговую игру», где его удержать в рамках игры невозможно, он и впрямь может придумать что-то необычное, что не учли маркетологи. «Путешествие» отражает вот этот «процесс» прохождения по «пути». У реки течение как процесс и русло как путь, и ещё есть сама река с течением и руслом — вот тут то же самое с клиентом и его journey. С точки зрения служб маркетинга можно говорить о клиентском потоке в смысле типа «поток» из ISO 15926: поток — это представление системы, удерживающее единство пути.

• customer journey map — это карта, на которой отражают места/пункты/точки контакта и путь путешествия клиента через эти точки контакта поначалу (когда считалось, что клиент шагает по воронке продаж) и хотя бы точки контакта с вероятностными маршрутами потом — когда признавалось, что клиент сам тоже выбирает, что ему дальше делать и кого и когда слушать. Иногда это «данные в компьютере», иногда именно «визуализация», часто не только для «одного клиента», но для потока клиентов (клиентов, находящихся в путешествиях по определённым точкам контакта).

• emotions, feelings — это вполне себе синонимы для одного из пониманий experience (впечатления), которые получаются по ходу путешествия по точкам контакта. Для них есть оценки (позитивность, негативность), получаемые при сравнении с ожиданиями (тот experience, который можно ожидать a priori). И ровно тот пункт, за который ругают метрики: ничего нельзя сказать про то, почему эмоции позитивны или негативны. Разве что если негативны, то «разбираться дальше», метрики non-actionable.

• satisfaction, удовлетворение как степень соответствия experience ожиданиям. Лояльность/loyalty тут же: правдоподобность того, что клиент будет и дальше путешествовать по touchpoints. И тут же множество их метрик, которые, конечно, должны потом стать actionable metrics, но пока с этим плохо, а ещё плохо с тем, что добыча данных для этих метрик приводит к «усталости» клиентов, сама по себе раздражает. Вас никогда не спрашивали по десять раз за день в самые неподходящие моменты: «ты меня любишь? Крепко-крепко? Будешь рекомендовать меня своему другу? А за что ты меня любишь? Твоё мнение крайне важно для меня!».

Основным тут термином будет клиентское путешествие, customer journey как прохождение клиентом каких-то обработок по каким-то методам в каких-то точках контакта, и эти обработки будут менять состояние клиента. Да, это метод, «методология создания и развития клиента из какого-то не слишком клиентского человеческого сырья». Термин journey/путешествие появился как описание инженерного процесса со стороны не создателя системы, а со стороны создаваемой системы. При этом основная область применения этого термина там, где пытаются привести в конечное состояние людей, изготовить в них какое-то мастерство, заняться инженерией их личности. Это требует как минимум учесть такие факторы, которые не надо было учитывать в классической инженерной разработке:

• Личности может понравиться или не понравиться любая из обработок, которые вы для неё приготовили.

• Личность может сама пройти такие обработки, которые вы не предусмотрели.

• Конкуренты тоже ведут свои обработки (или даже успели эти обработки провести перед вашими попытками повлиять на личность).

• … и такого довольно много. Личность принадлежит себе — и это как-то сразу не даёт вам возможность что-то с ней делать без предварительного согласия. А, например, продвиженцам ровно это и нужно: заманить без предварительного согласия, научить покупать их продукт! Учителям нужно согласие родителей, а не детей, чтобы их учить — а вот чему учить, они даже у родителей спрашивать не будут.

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

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

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

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

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

• Цифровая трансформация тут будет — переход от CRM (customer relationship management), информация о части путешествий клиента, часть контактов) к CXP (customer eXperience platform, информация обо всех контактах, сквозная для всех служб — маркетинга, продаж, обслуживания и даже проектирования и производства). Но об этом будет подробней в руководстве по системному менеджменту.

• -- ...добавьте сюда что-нибудь сами.

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

Дальше идея eXperience пошла работать и с другими ролями: стали обсуждать и employee experience, и community member experience, и самые разные прочие experience.

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

Клиентоориентированность и управление впечатлениями

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

Мы можем излагать это самыми разными словами. Основная терминология нашего руководства взята из инженерного процесса в его современных версиях непрерывной/agile разработки. Но речь идёт об общих паттернах деятельности и общих паттернах описания этой деятельности. Experience management (тут намеренно опущено слово customer, ибо мы собираемся сейчас обобщить эту онтологию) говорит, что рассказ таки нужно вести с точки зрения изменения состояний создаваемой и обсуждаемой системы, причём в случае интеллектуальных агентов принимая во внимание:

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

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

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

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

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

• в машиностроении в терминах «процесса разработки» или «инженерного процесса» с последующим разложением его на несколько уровней «практик»/practice. Например, мы создаём и развиваем гравицапу, для которой мы применяем процесс «scaled грави-agile с поправками для цап». Наши самые разные инженеры (архитекторы, проектировщики, технологи и т.д.) двигают альфу гравицапы как воплощение целевой системы по её состояниям от «задумано», через «спроектировано» и «изготовлено» до «используется» и даже «выведена из эксплуатации» (взяты состояния из классического типового «водопадного» рассмотрения), пытаясь как-то скоординироваться. Гравицапа находится в состояниях «как замысел», «как проект/design», «в виде сырья», «готовая» и когда-нибудь «мусор». Чтобы не запутаться, версии проекта храним в PDM (информационная система product data management, хранение данных о продукте, и только о продукте), работы и прохождение состояний — в issue tracker (а поскольку мы современны, то это вместе называем PLM, информационная система product lifecycle management, определяемая как система хранения данных о продукте и ещё чём-то, в данном случае кейсах работы с продуктами, поддержка версионирования и управления кейсами, в софте это обычно в разных системах, а в машиностроении и строительстве — в одной), версии того, что происходит с воплощениями в ходе изготовления храним в ERP (ибо это «ресурсы», речь идёт об enterprise resource planning, и не путайте с «бухгалтерской системой» — в ERP есть алгоритм планирования ресурсов, в бухгалтерских системах его нет), версии в ходе эксплуатации в EAM (информационные системы enterprise asset management, и там ведётся учёт данных о поломках и ремонтах воплощений).

• в менеджменте в терминах «рабочих процессов», где «функциональные единицы», они же оргроли, назначенные на оргзвенья и получившие все полномочия и ресурсы (ставшие оргвозможностями/capabilities) выполняют какие-то методы работы со «входами» и «выходами» как их предметами.

• В терминах путешествий, контактов, точек контактов и обязательно впечатлений или опыта (experience) там, где есть автономные интеллектуальные агенты, которые могут запросто сами что-то задумать и сделать. Обычно это люди, но могут быть сегодня и какими-нибудь AI-системами, а также коллективами из них всех (при этом коллективы вроде организации, «лица» мы ещё признаём как-то с натяжкой агентами, иногда даже государства признаём такими «лицами», но вот сообщества и общества, даже клиентуры и даже инвестуры — тут с агентностью проблема¹⁷²). Если создатели с ними работают, то возникает проблема: агенты ещё и сами себе создатели, поэтому нельзя планово переводить их из одних требуемых состояний к другим –«лошадь можно подвести к воде, а заставить попить — нельзя». Ещё они могут быть сразу в двух или больше состояниях (выделяются подальфы) и появляться у провайдеров разных обработок в заранее неизвестном порядке (ибо ещё и сами ходят, а не их за ручку водят). И ещё у них есть свои впечатления от происходящего. Если эти впечатления (или в другой терминологии — полученный опыт) становятся отрицательными, то всё, можно списывать все предыдущие потраченные на них силы, результата (скажем, покупки) не будет. Впрочем, даже гравицапу можно испортить на любом шаге обработки, это не является чем-то особенным, гравицапа может прилететь на твёрдый пол где-нибудь в ходе строго предписанной последовательности обработок и погнуться, так что идея «путешествия» с незапланированными обработками в незапланированных точках контакта вполне может работать и тут. Понятно, что надо отслеживать experience (впечатления) агентов-людей в ходе контактов/touches (и тут много чего может быть разного в ходе контакта-как-процесса: вовлечение, обучение, формирование впечатлений, взаимодействие и т.д.) с нашими создателями/местами-обработки/местами-контакта/touchpoints. Но ещё можно подумать и о впечатлениях внешних проектных ролей при инженерном процессе с чем-то «не очень живым и агентным», с теми же гравицапами. У гравицапы впечатлений нет, а вот у проектных ролей (и внешних, и внутренних) в ходе проекта создания и развития гравицапы впечатления будут. Кто-нибудь их планирует?

• … есть и множество других вариантов в самых разных предметных областях. Вы должны понимать, что все эти варианты — попытки разными словами и немного разными понятиями рассказать про одно и то же, про метод/культуру/стиль/способ работы: какой-то создатель в какой-то роли берёт какой-то объект и проводит его через ряд состояний каким-то методом, причём можно разложить этот метод на составляющие, в том числе и разложить роль на подроли — примерно так, как мы обсуждали в первом разделе руководства. И для всех этих вариантов мы понимаем, что легко выразить что-то одно, но чуть труднее — что-то другое, поэтому приходится дорабатывать описания методов, если чего-то не хватает. И использовать при этом терминологию, привычную в той или иной предметной области.

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

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

В маркетинге этот подход уже более-менее мейнстримный, customer journey уже в развитых странах вытеснил sales funnel, но по факту понимается он не как «причудливое путешествие» вместо «строгой последовательности шагов», а как «смена позиции восприятия». «Водопад» в мышлении оказывается бессмертен.

На диаграммах сейчас какой-то гибрид. Посмотрите на картинки: о нелинейном customer journey в тексте говорят «как надо», а иллюстрации приводят такие, что воронка продаж и путешествие клиента оказываются неразличимыми. Это та же «колбаска» прохода разных обработок клиента для перевода клиента в разные состояния, только там вроде как чуть побольше стадий и они более красочно нарисованы (вероятно, чтобы отразить «впечатления»). Вот типичная customer journey map¹⁷³, пример на русском:

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

Маркетологи уже договорились, что вообще неплохо бы иметь «бесконечное путешествие» — и продавать, продавать, продавать по up-sales и cross-sales что-нибудь до самой смерти или компании, или клиента, а также вербовать в сотрудники (делать из клиентов собственный touchpoint — загонять в сообщество клиентов, предлагать рекомендовать продукт знакомым, вовлекать в помощь другим клиентам в пользовании продуктом, разгружая свои колл-центры, и т.д.). Это всё было «управление жизненным циклом» клиента, теперь это стало «управлением путешествиями» клиента (customer journey management), хотя картинки и остались почти прежними (на них стадии обработки остались, но результат обработки теперь ещё и включает опыт/впечатления — чтобы не забывали о смене позиции восприятия с «как задумал маркетолог» на «как отреагировал на эту задумку клиент»).

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

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

• Управление впечатлениями. Оценка реальных впечатлений по сравнению с ожиданием этих впечатлений должна оставаться положительной. Нужно моделировать по реальным замерам впечатления по ходу путешествия агента (замерять что-то, а затем косвенно определять впечатления — ибо на постоянные расспросы «потратьте пять минут на то, чтобы оценить наш продукт» люди реагируют уже крайне нервно), а не только иметь проект впечатлений, которые хотят дать сотрудники. Это называют не «клиентоориентированность», а experience management: управление впечатлениями по мере путешествия по точкам контакта. Управлять впечатлениями — это проектировать такие точки контакта, чтобы контакты в них оставляли положительные впечатления, «превосходили ожидания».

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

Или другой вариант: клиента встречает тренер, через час клиент на полусогнутых выползает из этой качалки, думая, что «хорошо, что не надо было скорую вызывать» и «никогда не думал, что я столько подниму». Что там с впечатлениями от этой тренировки::touch в качалке::touchpoint? Голосовать своим кошельком клиент будет за тренировку-развлечение или тренировку-обучение? А если речь идёт о «качалке по высшей математике»? А если речь идёт об освоении системного мышления и методологии по их руководствам для инженеров-менеджеров? Всё в мире впечатлений и их оценок не так однозначно, существенно зависит от культуры той или иной предметной области.

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

Собранность как удержание (в компаниях — коллективного) внимания на каком-то объекте сегодня обеспечивается не «ментальными практиками», а информационными системами: базами данных, которые помнят о состояниях самых разных объектов, получаемых в ходе их путешествия (и вы к слову «путешествие» сами должны добавить «по точкам контактов» и подумать о разветвлённом графе состояний объекта как предмета метода. Эти состояния меняются в ходе собственно контактов как обработок этих объектов как предметов метода по каким-то методам. Вот это и есть онтологическое мышление: видите одно слово для понятия какой-то онтики, восстанавливаете в этом месте полную онтику). Эти информационные системы служат для усиления возможностей головного мозга, они как бы «внешняя кора головного мозга», экзокортекс (по аналогии с неокортексом — это «новая кора» как часть головного мозга человека, которая отвечает за высшие психические функции). Термин «экзокортекс» был предложен довольно давно, напрямую связывается с нейроинтерфейсами и относится к фантастике и трансгуманистическим технологиям¹⁷⁴. В 21 веке стало понятно, что усиливать способности к мышлению (прежде всего за счёт возможности управлять вниманием и обеспечивать надёжную память) могут даже карандаш и бумага, а уж компьютер — тем более. А поскольку собранность (управление вниманием и памятью) нужна не только индивидуальная, но и коллективная, то термин прижился. Мы будем называть корпоративные информационные системы коллективным экзокортексом, чтобы подчеркнуть, что речь идёт прежде всего об удержании коллективной собранности: удержание в корпоративном внимании и обеспечении надёжной памяти для сведений о состояниях самых разных предметов методов, которыми занимается компания. Для обсуждения программного обеспечения, используемого как личные и корпоративные экзокортексы, есть даже чат «Экзокортекс (МИМ)»¹⁷⁵. При этом идея экзокортекса продолжает развиваться для других классов программного обеспечения, например, предполагается использование AI-агентов как экзокортекса¹⁷⁶.

Экзокортексы для «клиентоориентированности» и «управления впечатлениями» будут предлагаться самые разные, часть из них будет прямо поддерживать «водопад» (по-старинке они будут хвастаться тем, что «реализуют классическое проектное управление», как будто это хорошо), часть — кейс-менеджмент (по-современному это и будет «проект» с планированием чаще всего «на лету» и ведением case files, «папок дел»). Ещё часть будет поддерживать старинное «процессное управление», где 95% экземпляров процессов проходят по стандартному маршруту, а 5% становятся дикой головной болью ввиду нестандартности своего путешествия и неминуемых отрицательных впечатлений при нерешении проблем, они занимают 95% времени на внимание к себе. Вот примерно так выглядел вариант процессного управления нулевых годов 21 века, до появления кейс-менеджмента для agile инженерных процессов, где эти 5% кейсов — просто кейсы, штатная, а не «проблемная» ситуация.

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

Скажем, только в области маркетинга вам в 2024 будет предложено 14106 софтверных продуктов самых разных типов (MarTech — маркетинговые технологии), и по факту вы можете сказать, что все они поддерживают собранность работников служб продвижения, помогают планировать и реализовывать клиентские путешествия¹⁷⁷:

Что из них вам надо? Что не надо? Что из них поддерживает допотопные способы мышления? Что заведомо не сработает?

Понятно, что таксоны в классификации MartechMap взяты «исторически» и ничему осмысленному не соответствуют. Легко найти множество других классификаций (ни один термин в этих классификациях не повторяется, они построены на разных принципах, отражают принципиально разные описания маркетинга! хотя повсеместно повторяются уже знакомые нам слова: marketing, experience, customer, channel, journey). Конечно, все поставщики софта называют свои продукты «платформами», уже давно не «приложениями» и не «комплексами/suite». Эти «платформы» обычно пытаются сделать необъятными в числе поддерживаемых прикладных модулей (тех же «приложений»). Если вы поняли, что путешествие потока заготовок по машиностроительному заводу (отслеживается классом софта ERP, enterprise resource planning) эквивалентно путешествию клиента по точкам контакта, то легко представить, что оно будет отслеживаться каким-то вариантом ECRP как эквивалентом ERP в машиностроении (enterprise client resource planning, планирование клиентских ресурсов предприятия, пошутим так), но тут же эта первая приходящая на ум аналогия не выдерживает критики: на склад «клиентские заготовки» и «клиентские полуфабрикаты» не положишь, «клиентское сырьё» на условиях just-in-time не закупишь.

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

Пример тут — как рассуждать о том, как какого-то «проходящего мимо агента» готовят к выполнению какой-то роли, организуя его путешествие:

• Customer journey — мы только что довольно подробно рассмотрели вопрос про клиентское впечатление. Отдельно можно говорить о пользовательском (как становятся пользователем продукта, но необязательно платящим, например, на тарифных планах free в бизнес-моделях freemium¹⁷⁸) и именно клиентском путешествии как путешествии пользователя, который таки заплатил и находится в финансовых отношениях с компанией, получает «премиальное обслуживание». В любом случае, «клиенториентированность» идёт от клиента, customer. И eXperience management с идеей journey начинался именно на примере customer. Путешествия других проектных ролей с отслеживанием их впечатлений были предложены позднее.

• Employee journey тут идёт по примерно такой же линии рассуждений, только тут не клиентоориентированность, а сотруднико-ориентированность. И тут тоже отход от «водопада» к разным траекториям/путям/маршрутам путешествия по организации, и это тоже надо отслеживать. И там тоже eXperience/впечатление/опыт, вовлечение/engagement, мотивирование, попытки проектирования маршрута и неожиданные места контакта (touchpoints) с неожиданными результатами этих контактов, в конечном итоге — превращения «проходящего мимо человека из целевой аудитории» в кандидата на занятие вакантной должности, а затем сотрудника на этой должности, с возможным ещё карьерным путешествием career journey и тоже обязательным отслеживанием впечатлений и индивидуализацией этих путешествий.

• Learner journey — тут всё то же самое, и тоже индивидуальные учебные программы при понимании, что без автоматизации ничего хорошего из индивидуализации обучения не получится, а автоматизация труда ученика невозможна.

• Community member journey, и тут тоже полно всяких «платформ» по поддержке сообществ, и тоже «путешествие, которое мы планируем» существенно отличается от «путешествия, какое было у члена сообщества», а ещё у сообществ не всегда чётко определённое членство и главное — сообщества не имеют чётко определённой одинаковой культуры, которую можно было бы легко поддержать софтом. AI это вроде должен менять, но пока это всё только в далёких планах.

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

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

Экзокортекс для коллективного отслеживания всех этих «путешествий» имеет самые разные названия:

• Для «путешествия» софта или классических инженерных систем будет использоваться internal engineering platform, занимаются этим platform engineers¹⁷⁹.

• Для «путешествий» клиентов будут использованы системы CRM (customer relationship management¹⁸⁰), заниматься этим будут в службе продаж, или CXP (customer experience platform¹⁸¹), заниматься этим будут в самых разных службах (и чаще службах маркетинга, как основных, а не только службах продаж),

• Для «путешествия» сотрудников этим будут заниматься административные системы (employee experience platform¹⁸²), заниматься этим будет администрация предприятия

• … и так далее.

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

Надо выявлять незапланированные части путешествий предметов метода даже для не очень живых продуктов. Например, вы отдаёте на завод информационную модель, завод раздаёт её фрагменты для «изготовления по кооперации» (то есть отдаёт субподрядчикам), там «улучшают» части 3D-информационной модели изделия/продукта, полученные от КБ, причём делают (иногда из самых лучших побуждений!) круглое квадратным и наоборот. Потом все эти изменённые непонятно кем непонятно где (и не проверенные поэтому конструкторским бюро) информационные модели изделия превращаются на заводе в металлические части, которые не могут быть собраны вместе. Почему? Неучтённый в internal engineering platform внешний touchpoint (а теория говорит, что обработки предметов метода могут происходить и в незапланированных точках, это всегда надо ожидать), где информационная модель изменяется подрядчиками завода по каким-то своим соображениям. Как решать эти проблемы? Отследить маршрут информационных моделей и резко снизить затраты времени и нервов (eXperience всех участников инженерного процесса) на согласование изменений информационных моделей с КБ.

Другой пример будет в методе «пропитки» как подготовке к организационным изменениям из руководства по системному менеджменту: решения принимаются не теми, с кем вы разговаривали и кого уговаривали, а какими-то их влиятельными друзьями, с которыми советуются вроде бы «принимающие решения лица». Вы уговорите начальника что-то сделать, но в последний момент он посоветуется со своим другом, который будет против этого просто потому, что не хочет рисковать сам и начальнику будет советовать «не рисковать!». Этот друг ничего не знает про ваши аргументы, вы же не с ним разговаривали! В результате посоветовавшийся со своим другом начальник легко откажется от договорённостей с вами: своему менее разбирающемуся в ваших аргументах другу начальник верит больше, чем вам. А этих друзей будет несколько. Поэтому «убалтывать» надо этих друзей, а поскольку вы не знаете, кто они, то хорошо бы уболтать вообще всех потенциальных «советчиков лица, принимающего решения» — и тогда нужное решение не встретит скрытого сопротивления. Это всё экземпляры общего рассуждения, customer experience management и customer journey тут только примеры (скажем, вам надо убедить купить какой-то продукт не только клиента, но и друзей клиента, поэтому знать о продукте и его свойствах хорошо бы не только покупателю, но и всем вообще людям — вы не знаете, кто будет давать по поводу покупки вашего продукта последний самый важный совет потенциальному покупателю).

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

Корпоративные экзокортексы для управления впечатлениями: CRM, CXP, DXP, LXP.

Трудно поверить, но ещё до информационных систем CRM (customer relationship management), то есть ещё в далёких 80х годах гуляли слова

• Database marketing¹⁸³. Им занимались «официальные спамеры» (spamming¹⁸⁴), которые вели списки рассылки direct marketing¹⁸⁵. Для того, чтобы поднять эффективность (это было ещё в эпоху бумажной рекламы через почту), надо было рассылать рекламу не всем подряд, но делая «выборку из базы данных».

• Relationship marketing¹⁸⁶. Для него важней было удержать отношения, «никакая продажа не является последней». Relationships/отношения — это когда у продавца не одномоментная сделка, а длящиеся во времени отношения, и хорошо бы накапливать об этом информацию, иметь память о том, с кем компания в каких отношениях, как эти отношения развивались, какие есть планы по дальнейшему «развитию отношений» (это эвфемизм для «что мы можем туда ещё продать»). Для поддержки отношений нужна была база данных, экзокортекс — разгрузить ненадёжный мозг sales managers, дать им компьютерную систему вместо ручки и бумажки. База данных (свежий ещё термин в 80х) как раз и должна была быть такой памятью о клиенте и проходимых им состояниях в его путешествии (хотя слова «путешествие» ещё не было, но «воронка продаж» — это уже было).

Дальше для целей маркетинга и взаимодействия с клиентами развивались document management systems (DMS¹⁸⁷), монстрообразные системы сначала просто документооборота, которые главным образом хранили документы — в том числе договорную документацию по каким-то клиентам, но могли хранить и протоколы совещаний и всё остальное, что касалось продаж и маркетинга. Потом это стало enterprise content management (ECM¹⁸⁸, с 2017 года предпочтительное название — intelligent information management), ибо маркетинг часто и с картинками работал, и с видео, и даже потом вебсайты там уже были с середины 90х, и там были уже просто content management systems (CMS¹⁸⁹). Конечно, все эти понятия применялись весьма широко и чёткого отнесения конкретного софта к этим классам не было. Тем не менее, в CMS не было ориентации на клиента, скорее это была ориентация на «неопределённо широкий круг лиц». Деньги были большие, но, как любил подчёркивать Jensen Huang, самые большие деньги — в специализации. Никому не нужны «чипы для искусственного интеллекта», но вот «чипы для серверов в датацентрах», «чипы для видеоигр», «чипы для обработки медицинских изображений» — это совсем другое дело, хотя это всё один и тот же чип, только в немного другой обёртке, но эту обёртку уже много проще соотнести с источником денег. Ибо «нужно всем» чаще всего означает «не нужно никому».

Content management system была роленезависимой, она не была настроена на какое-то «путешествие», на то, чтобы быть internal development platform для удерживания состояния агентов в их путешествии на занятие какой-то внешней или внутренней роли (stakeholder), например, путешествия «людей с улицы» в «клиенты». Агента для этой роли клиента (customer) надо было поймать где-то «на улице» (то есть неизвестно, где именно, скажем, перехватить красочной рекламой взгляд при просмотре какого-то вебсайта, например, вебсайта газеты), затем обучить роли (мастерство — знать продукт, любить продукт, купить продукт), затем удержать от ухода к конкурентам, затем доить вечно. Это, конечно, очень неформальный способ разговора о маркетинге, но он тут намеренно. Обычно у продвиженцев нейтральный язык, там даже спам называют не спамом, а direct marketing. Поэтому для продвиженцев в компании тут было бы приятно и привычно прочесть «обеспечивать лояльность и повторные покупки по линиям cross-sales и upsales», но это слова продвиженцев. «С другой стороны баррикады» это «меня хотят поймать, заставить купить, затем будут удерживать и надеются доить вечно».

База данных для database marketing и relationship marketing ничем принципиально не отличалась от типичной ECM системы, но имела в схеме данных и своих отчётах главную сущность customer. Чтобы как-то выделить этот менее универсальный класс систем «управления контентом», такого сорта базам данных дали с середины 90х прошлого столетия название customer relationship management, CRM¹⁹⁰ — новый класс информационных систем (который, конечно, ни разу не был новым) для служб продаж. Это была не столько менеджерская или айтишная идея, сколько айтишный «голимый маркетинг» своих «универсальных баз данных» с какой-то моделью данных событий, происходящих в ходе account-based marketing и account management. Смотрите на тон предыдущего предложения: сами продвиженцы-менеджеры или айтишники никогда про свои системы так не скажут, но язык вполне может выражать оценку других ролей, смену референтного интекса, позиции восприятия: «доблестные разведчики» становятся «презренными шпионами».

Account — это как раз реестр данных о контактах с клиентом. Там и контакты клиента для связи с ним (ещё одно значение русского слова «контакт»: кроме места контакта и процесса контакта тут «адрес канала клиента» — канал тут «способ связи», то есть почта, или чат в мессенджере, или телефон, или даже бумажная почта). Этот account-based marketing¹⁹¹ cам по себе отдельная методология маркетинга. И вот в 1993 году Tomas Siebel покинул Oracle Corporation, чтобы основать Siebel Systems, которая стала одним из ведущих поставщиков программного обеспечения CRM. Компания Siebel сыграла значительную роль в популяризации этого термина. Примерно в это же время другие компании-разработчики корпоративного программного обеспечения, такие как SAP и Oracle, также начали разрабатывать и продвигать решения CRM, главным образом для служб продаж (а не для использования всеми остальными службами с их touchpoints, например, службами маркетинга, службами рекламы, службами клиентской поддержки).

Тут и пришёл в нулевые годы 21 века experience management, который сказал, что клиент взаимодействует не только со службой продаж, но и с результатами работы чуть ли не всех служб компании, и речь идёт не только о ключевых клиентах, но и вообще всех клиентах, и всю информацию по самым разным местам контакта и взаимодействиям надо собрать и накопить. Компания тем самым должна иметь базу данных прежде всего по впечатлениям (eXperience), которая будет использоваться всеми (platform, а не просто какая-то там system). Родился термин customer eXperience platform (CXP). Ссылок не даём намеренно, погуглите, у всех провайдеров есть своя страничка рассказа, что это за класс программных продуктов.

Главный объект в CXP — карта путешествия (journey map), которая в существенной мере состоит из списка запланированных (и иногда паразитных) контактов/touchpoints. CXP предполагает проектирование маршрута клиента по этой map, какие-то возможности по кастомизации маршрута для управления впечатлениями. Почему не просто «система управления», а именно «платформа»? Потому что CRM и прочие системы поддержки «управления» предполагалось использовать в рамках какого-то одного подразделения, а вот платформа была изначально предназначена для использования всеми службами предприятия. Предполагался полный продвиженческий (маркетинг, реклама, продажа, постпродажное обслуживание) конвейер «от и до», это был экзокортекс для всех служб компании. Такой конвейер в инженерии — internal development plaftform, только по конвейеру тут идёт какой-то агент, обрабатываясь до состояния customer.

CXP имеет особенность: там важен сбор откликов по тому, что происходит с клиентом. Главным там оказывается не journey, не само путешествие, но тот самый experience, впечатление. Эти системы продвигались не столько как «базы данных для учёта клиентов», сколько как «базы данных для накопления сведений о впечатлениях клиента, о состояниях клиента», упор на съём показателей, «получение обратной связи». Конечно, внутри таких информационных систем есть и вполне универсальный моделер для предметной области customer journey management, но акцент всё-таки на outcome, «что на выходе путешествия в целом»: всем службам надо знать, какие там у клиентов впечатления, какова их лояльность — и где там на маршруте возникают проблемы, чтобы их устранять, не терять клиентов.

Есть и класс специализированных информационных систем для customer journey management (CJM, а не CXP). Это специализированные системы управления процессами, они пытаются не столько собирать информацию про «полученный в ходе путешествия опыт», сколько отслеживать само «путешествие», проход по точкам контакта, по сути дела это разновидности issue trackers.

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

Поскольку мы тут говорим о более-менее общем механизме рассуждения «прохождения людей по конвейеру», то довольно скоро был сделан последний шаг — CXP как customer eXperience platform переименовывается в DXP — digital eXperience platform, и там уже речь идёт не просто о впечатлениях, а о «цифровых впечатлениях», то есть предполагается, что «обработка клиента» ведётся главным образом через цифровые каналы. Задача DXP — create, manage, optimize, and deliver seamless and consistent digital customer experiences across multiple channels and touchpoints. Впрямую путешествие тут не упоминается, зато подчёркивается множественность каналов и множественность точек контакта. На сегодня на рынке представлено довольно много подобного софта¹⁹².

У разработчиков DXP eXperience становится больше «взаимодействием» (interaction), которое хорошо протоколируется — ибо «впечатление» маркетологов не запротоколируешь. Но, понятно, это «великолепные взаимодействия/experiences», которые маркетологи трактуют как «великолепные впечатления/epxerience» — несмотря на онтологическую путаницу, разработчики софта и маркетологи отлично находят общий язык.

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

Customer или digital в CXP или DXP при этом заменяется на что угодно, остаётся *XP, которая читается или «платформа впечатлений/опыта», или (в трактовке программистов) — платформа взаимодействий. Например, Dassault Systèmes¹⁹³ выпускала:

• PDM (product data management) систему, это была ENOVIA PDM, 1998 год. Это была торговля по сути чужим продуктом фирмы ENOVIA, купленным Dassault Systèmes, никакой особой интеграции с CAD от Dassault Systèmes даже не было, никакой «платформенности» и «взаимодействий». Это было просто отражение идеи первого поколения системного мышления: собрать все данные об изделиях машиностроения (и иногда — строительства), тогда это были главным образом чертежи с выходом на сводно-заказную спецификацию (BoM, bill of materials) продукта/изделия.

• PLM систему (product lifecycle management). Это было буквально через год-другой после старта продаж PDM ENOVIA. В 1999-2000 годах, ENOVIA уже продавалась как PLM Solution. PLM формально определяется как «база данных, в которой кроме данных о продукте лежат ещё какие-то данные», и там лежали данные о создателях — кто что с этими описаниями продукта делал, там внутри был issue tracker, то есть «данные о работах создателей», это было главное отличие. До полного жизненного цикла в сборе данных в этом продукте так и не добрались, но хотя бы стадию проектирования закрыли — в машиностроении тогда ещё обслуживался «водопад», каждая стадия предполагала свой вид систем.

• DXP систему (digital experience platform) Dassault Systèmes запустила в 2012, это была 3DEXPERIENCE. Слоган там был — integrating all aspects of a business into a single platform. Но слоган для PLM системы был для большинства инженеров неотличим: данные о продукте и всём остальном, что с ним происходит, на всех стадиях. Что же было нового по сравнению с ENOVIA? То, что окончательно перешли от 2D проектирования к 3D проектированию? Нет. Вот как описывается 3DEXPERIENCE: «It provides a holistic, real-time view of business activity and ecosystem, fostering innovation and collaboration not just within engineering teams but across the entire organization, including marketing, sales, and external partners. The platform enables companies to create unique customer experiences by leveraging virtual universes to simulate and optimize products and processes before actual production» — это мы видим описание в продукте для инженеров основных идей customer experience management.

Идеи «из маркетинга» съели идеи инженеров с их сухими описаниями PLM, а также идеи эккаунт-менеджеров с их CRM, а также все остальные «частные идеи» отдельных информационных систем, предназначенных для отдельных инженерных стадий или отдельных служб компаний. Если вспомнить, чем там хвасталась Dassault Systèmes при запуске своей DXP, так это всякими интеграциями вовне фирм, которые закупали 3DEXPERIENCE: во всех рекламных роликах рассказывалось, как выложить 3D-информационную модель для какого-то каталога комплектующих, как потом показать виртуальную модель изделия клиентам машиностроительных предприятий, как подключить каких-то внешних инженеров для участия в разработке. Все это объяснялось через важность обустройства точек контакта и акцент делался на цифровые каналы, по которым шли и документировались взаимодействия в этих точках контакта, которых много, очень много, и софт поможет их организовать.

Это типовой язык для DXP, так что 3DEXPERIENCE platform позиционировалась на рынке как DXP. Инженеры PLM систем традиционно называли обмен данными с другими типами софтов «интеграциями», рассматривая только «программистскую» часть проблемы, поэтому для них рекламное предложение Dassault Systèmes по поводу 3DEXPERIENCE казалось бессмысленным «бла-бла-бла», «маркетингом». Но для менеджеров машиностроительных предприятий это был связный рассказ о том, как DXP от Dassault Systèmes поможет им в customer experience design (то есть каким образом сделает клиентоориентированным их машиностроительное производство — и в части проектирования, и в части производства, и даже в части маркетинга и продаж, а затем ещё и постпродажного обслуживания). Поэтому деньги на покупку DXP выделялись менеджерами много проще. Инженерам надо было только произвести, они не были клиентоориентированными. Менеджерам надо было не только произвести, поэтому для инженеров это всё выглядело как «ребрендинг PLM ENOVIA», а для менеджеров это был совсем другой вид продукта — не PLM, а DXP.

Когда люди из служб маркетинга Dassault Systèmes писали «These developments reflect Dassault Systèmes' commitment to evolving their software solutions to meet the changing needs of engineering and enterprise environments, from managing product data to encompassing the entire product lifecycle and delivering comprehensive digital experiences» — инженеры дочитывали до слова delivering и дальше ничего уже не понимали. Правильно не понимали, слово experience пришло по линии маркетинга и отлично прочитывалось менеджерами машиностроительных предприятий. Им предъявляли онтику «современных трендов клиенториентированности».

DXP можно рассматривать и как «связку PLM для продукта с CRM» в минимальном варианте, но главное там — это поддержка всех взаимодействий/experience для всех служб предприятия. Так, ожидается, что будет поддержан и каталог продуктов или сервисов, и выход на биллинг, и выход на колл-центр поддержки, и даже выход на рекламу. Были бы продукты и сервисы (их у крупных фирм обычно много) и были бы клиенты (их тоже обычно много), а далее надо «учесть все их возможные взаимодействия/experiences», причём так, чтобы эти впечатления/experiences были «превосходными», то есть превосходили ожидания, были позитивными.

Дальше идея цифровых платформ поддержки взаимодействия (DXP) нашла поддержку для самых разных сфер.

Например, LMS (learning management system¹⁹⁴, аналог PLM для обучения) по большей части тоже пытались перейти к LXP (learning eXperience platform). Но в вузах и даже корпоративных университетах, где использовались LMS, идеи маркетинга и экономики впечатлений были не очень распространены, поэтому не все поставщики LMS стали менять свои продукты, название класса продукта и способ разговора о продукте (то есть использовать слово eXperience, слова про learner journey). Некоторым поставщикам LMS не надо было интегрироваться по захвату данных всего учебного заведения и не надо было напирать на то, что у каждого ученика проходит learning journey (иногда пишут learning journey для позиции восприятия учителями, иногда — learner journey, чтобы подчеркнуть «ориентацию на восприятие учеником») уникально, а не представляет собой универсальный для всех предписанный учебным планом «водопад».

Маркетинг LXP шёл поэтому не по линии CRM (привлечь ученика/learner, хотя для онлайн-провайдеров обучения это оказалось ключевым — объединение LMS и CRM), не по линии интеграции данных по всем experience в понимании айтишников, то есть experience как процесс, а не как впечатления от процесса. С LMS процесс добавления новых видов данных от разных точек контакта в хранимые данные о всех взаимодействиях шёл медленно, а затем время от времени разные поставщики таких систем и сервисов делали ребрендинг их как LXP. В любом случае, этот новый тип системы поддержки «путешествия ученика» заявляли не все поставщики LMS. Но если была заявка на поддержку «всех видов взаимодействия по всему маршруту путешествия ученика», да ещё и «искусственный интеллект» и «большие данные» для «индивидуализации опыта каждого ученика» (обратите внимание, это всё прямые отсылки к experience management), то тут чаще всего и отказывались от термина LMS и переходили к platform, то есть LXP, и этих LXP сейчас очень много¹⁹⁵.

Для самых разных ролей все эти «путешествия» и «впечатления/опыт» (или в варианте айтишников — взаимодействия, которые дают впечатления) устроены примерно одинаково. Скажем, сотрудники (employee, взятые как сообщество) имеют свои платформы для отслеживания их «путешествий», career journey. То же самое — члены сообществ, там тоже DXP, которые работают по проектированию и отслеживанию впечатлений членов сообщества, организации взаимодействий, вовлечению в какие-то дела предприятия. Конечно, такого сорта системы поддерживают и роль пользователя (роль user сегодня понимается и как связанная с ролью customer на стадии эксплуатации, и как community member).

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

TEST Метод разработки

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

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

+++ спиральная модель ### Да, спиральная модель жизненного цикла — после опробования прототипа система, оказывающая сервис, была доработана, на этом проект был закончен и началась эксплуатация.

--- agile ### Нет, в случае гибких методов разработки проект не был бы закрыт, доработки бы продолжались.

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

--- Agile ### Нет, гибкие методы предполагают возможность пересмотра характеристик продукта на всех стадиях, диаграмму Ганта по видам работ для такого проекта построить не удастся (все работы будут параллельны/одновременны на такой диаграмме, диаграмма будет бессмысленна). И ещё тут вопрос с использованием в разработке метода инженерии требований (agile практики давно избегают подготовки требований) и архитектуры (архитектура сейчас определяется так, что трудно её представить отдельной стадией, подробней об этом будет в руководстве по системной инженерии).

--- Спиральный ### Нет, спиральная модель жизненного цикла предполагает постепенное достижение требуемых характеристик продукта, по итогам предыдущих не вполне окончательных удачных или неудачных, но в любом случае частичных попыток. Тут же — всего один виток, никаких «попыток». Речь явно не об этом.

+++ Каскадный ### Да, это описание «водопада». У проекта будут огромные сложности, ибо это утопичная модель инженерного процесса, «всё пойдёт не так», работы в жизни не будут соответствовать плану работ из диаграммы Ганта.

--- Ни один из вышеперечисленных ### Нет, правильный ответ в списке присутствует: был выбран «водопад».

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

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

+++ Спиральный ### Да, это спиральная модель жизненного цикла, которая предполагает постепенное достижение требуемых характеристик продукта, в том числе и по итогам предыдущих не вполне удачных попыток (многократное прототипирование).

--- Каскадный ### Нет, «водопадная» модель жизненного цикла не предполагает, что разработка будет доведена до неудачного конца, а потом начата заново. Основное в ней — передача всех материалов предыдущих стадий/физ/этапов на следующую и попытка представить дело так, что эти материалы потом не меняются в ходе проекта, нет возвращения к работам по методам предыдущих стадий. В «водопаде»/cascade все стадии работы прописаны заранее, поэтому должно быть известно, сколько именно там будет прототипов перед успешным окончанием проекта! Можно, конечно, предложить в «водопаде» и три прототипа, и все пять, но уж точно не неопределённое их число, ибо классическое проектное управление предполагает предварительного планирование всех работ. Создание каждого прототипа в «водопаде» должно быть оговорено заранее!

--- Ни один из вышеперечисленных ### Нет, правильный ответ в списке присутствует: спиральный вид инженерного процесса.

В сказке Пушкина «Золотая рыбка» жизненный цикл жилища старика и старухи имел вид:

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

--- Шухарта ### Нет, цикл Шухарта-Деминга — это не вид инженерного процесса.

--- Деминга ### Нет, цикл Шухарта-Деминга — это не вид инженерного процесса.

+++ Agile ### Да, на основе опыта эксплуатации каждого варианта жилища выдвигались новые требования к разработке, и разработчики гибко отвечали на эти новые требования.

Метод разработки ничего не скажет об оргзвеньях

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

Орг-проектировщики обычно кладут в основу концепции организации метод разработки, по которому будет работать организация. Часто это даже не полный метод разработки, а только те методы, которыми будет заниматься организация. Скажем, если это завод — то только методы изготовления системы и методы инженерных обоснований в части испытаний, но не методы замысливания и проектирования системы. Или наоборот — если это КБ, то только методы архитектурной работы, проектирования, но не изготовления (хотя инженерам надо учитывать методы изготовления! Но оргпроектировщик этим не будет озабочен).

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

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

Метод разработки — это поведение создателей, то есть изменения состояний предметов метода во времени, поэтому он представляется развёртками во времени:

• пару десятков лет назад это была диаграмма работ-стадий в физическом времени,

• потом двумерная диаграмма методов и стадий,

• современный вариант — это функциональная диаграмма связи методов по потоку их предметов в логическом времени, а

• самый современный вариант представляет собой исполняемые варианты в каких-то табличных моделерах, часто связанных с issue tracker, что позволяет связать в жизни управление процессом/методом разработки с управлением работами.

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

• имеет людей и AI-агентов с нужным мастерством,

• моделеры с нужными шаблонами, или на которых можно эти шаблоны получить и подстраивать, если метод включает в себя рекомендации по адаптации шаблонов моделирования,

• имеет полномочия по трате времени и других ресурсов на выполнение этого метода создания концепции системы, да ещё и

• это время, и все другие ресурсы наличествуют.

Это два разных вопроса: 1. Как будем работать, по какому методу (функциональный) и 2. Кто будет работать (конструктивный). Сама работа получается только после ответа на оба вопроса!

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

Для продуктовых линий (product lines¹⁹⁶, иногда product families, когда из стандартных модулей собираются разные конфигурации системы для разных потребностей, и это происходит на нескольких системных платформенных уровнях), инженерные процессы разных таких платформ как частей системы или систем в окружении могут быть переплетены причудливым образом. Нужно всегда помнить, что системы выделяются из окружающего мира субъективно (хотя это и хорошо организованная субъективность! Все договариваются, системное мышление для этого!), в зависимости от интереса роли, выполняющей какой-то частный метод работы в рамках инженерного процесса со множеством участников в весьма сложном графе создателей.

И даже выявление (прежде всего — моделирование, модель делает невидимое видимым, даёт возможность обсуждения и основу для договорённостей) метода разработки как поведения создателей в их графе — субъективно. Разные агенты (люди и AI-системы) с разным опытом и предложат разные варианты «инженерного процесса»/«метода разработки» для одной и той же системы, и опишут по-разному составляющие методы уже полным ходом идущей разработки и последующего развития системы, и признают в ней разные «виды методов разработки» и даже «модели жизненного цикла».

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

Нужно всегда помнить, что должна быть оргвозможность управления методом разработки, управления инженерным процессом, оргвозможность оргразвития: кто-то::роль с его инструментами моделирования методов инженерии и мастерством это делать должен проектировать метод разработки и превращать его в оргвозможность (чаще всего это ответственность CTO или CIO с их службами, и там особо выделим роль методолога, оргпроектировщика, оргархитектра и лидера, чтобы договариваться со всеми причастными).

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

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

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

Конечно, это мы ещё раз очень кратко помянули системную мантру.

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

Проект: это всё, что угодно

Проектом (project) сегодня называют любое организованное (то есть с понятным распределением полномочий по распоряжению трудом и капиталом) усилие/начинание/endeavor/«трата ресурсов» какой-то команды (оргзвена с агентами, которые выполняют некоторый набор методов работы, действуя в известных ролях — разделение труда) по достижению какой-то цели, в том числе цели создания и развития системы (включая использование системы, включая изменение свойств системы).

Слово «проект» сегодня не ассоциируется исключительно как «проект в классической практике проектного управления (project management)», то есть с тем, как определяют понятие «проект/project» в ассоциациях проектного управления Project Management Institute (PMI)¹⁹⁷, PRINCE2¹⁹⁸ или аналогичных. Проектом тем самым будет назван и кейс/case починки протекающего унитаза в офисе, и программистский трёхмесячник по методу SCRUM¹⁹⁹, в котором вообще не строилось диаграммы Ганта (зато с выдачей через месяц после начала минимального жизнеспособного продукта/MVP, ещё через пару недель второй версии этого MVP и затем ещё через неделю крутым виражом/pivot с полной сменой целей проекта и перепиской продукта «с нуля» под новые цели), и даже какая-нибудь певица у какого-нибудь продюсера (при этом сама певица-исполнитель в «проекте» может быть легко заменена одна на другую без переименования проекта), ибо продюсер::создатель создаёт и развивает певицу::«целевая система» (а как «проект создания и развития певицы» стал «певицей::проект» — это уже особенности языка, метонимия). И даже программы из классического проектного управления (то есть множество классических проектов, которые порождаются по мере осознания в них необходимости в рамках «программы проектов»/«проектной программы») тоже сегодня часто называют «проектами». Могут сказать «программа полётов человека на Луну», имея в виду всю совокупность проектов, связанных с полётами людей на Луну, в том числе и заранее неизвестных ещё проектов, которые ещё даже не осознаны как необходимые, а могут сказать «проект полётов человека на Луну».

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

Ещё в русском языке есть разница между проект/design и проект/project, это тоже нужно учитывать. Обычно продукт — это воплощение целевой системы в её окружении, а проект/project — работы создателя этого продукта. Но есть вариант, когда продукт — это воплощение целевой системы в её окружении, а проект/design — описание/«system definition» этого продукта. Иногда эти значения можно как-то разделить, если обращать внимание на глаголы: «проект дома» в русском языке часто будет design, а «проект создания дома» — это будет project. Очень редко встречается и проект как «проектная команда» («мне сказали из проекта Васи, что Маша из нашего проекта обещала закончить проект на неделю раньше плана»). Напомним: «косил косой с косой косой косой на косе» — мозг вполне справляется с омонимией, один и тот же термин может означать абсолютно разные понятия. Будьте внимательны к типам понятий (развивайте свою «машинку типов»), и вы не запутаетесь! «Проектом» может оказаться что угодно, обращайте внимание на тип!

Моделирование: управление инженерным процессом против управления работами

Напишите рядом два кратких эссе, в которых вы описываете основные идеи принятого в вашем рабочем проекте варианта инженерного процесса и варианта управления работами.

4. Метод как объект первого класса

Понятие метода: повторение

Как и для любых других систем, ключевым аспектом описания создателей является функциональный/ролевой. Прежде всего интересуют ответы на вопросы «для чего нужно использование?» и «что делает, чтобы получить результат?». Функции как поведение создателей в их ролях называют методами работы (и там длинный ряд синонимов — способы, практики, культуры, стили работы, виды деятельности, инженерии, труда, решающие проблемы методы будут называть стратегиями, и т.д.).

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

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

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

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

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

Например, «метод инженерного обоснования chaos engineering»²⁰⁰ — это составляющая «инженерного процесса» в целом, представляет собой набор практик планирования выключений основного (не тестового!) самого разного оборудования на какое-то время, чтобы посмотреть, как с этим справляется система, от которой ожидается большая надёжность. Или метод строительства железобетонных зданий и сооружений при помощи скользящей опалубки/climbing formwork²⁰¹ это часть «инженерного процесса» строительства зданий, сам состоит из практик обустройства опалубки, заливки бетона, перемещения опалубки и т.д. Мы понимаем, что «практики», которые по такому определению входят в метод — это тоже методы, только составляющие исходного метода, полученные разложением метода.

Это специфическое для классической инженерии и менеджмента понимание «метода»: если уж употреблён именно этот термин, то ожидается какая-то полнота/законченность приведения альфы в конечное/целевое/ожидаемое состояние какими-то практиками разложения этого метода на составляющие. И практики двигают подальфы этой альфы, пока не будет достигнуто это конечное/целевое/ожидаемое состояние альфы.

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

В инженерной профессиональной литературе все практики считаются примерно равны друг другу по уровню, но метод — он будет крупнее, ожидается его разложение на практики. При этом в инженерии ещё и синоним «метода» — «методология» с другим словарным значением, чем «учение о методе». Это даже будет не «учение об одном специальном методе», при этом не факт что это будет вообще «учение» как теория/объяснения/алгоритмы. Это часто именно выполняемая методология/метод/практика, например, «методология SCRUM» — способ работы бригады разработчиков.

Так что метод в инженерии будет — способ работы для достижения какого-то конечного результата, конечных состояний какой-то альфы, а не просто какая-нибудь «практика» как способ работы для получения какого-то необязательно конечного результата, то есть прохождения пути по какой-то цепочке в графе состояний альфы, от какого-то одного состояния в какое-то другое, необязательно даже конечного.

Сегодня часто кроме слов «метод/методология», «практика» говорят и «процесс» (process) — за последние пять лет слово «процесс» перестало всегда означать развёртку в физическом времени работ, «физический процесс» (функционирование, работу физической системы). В менеджменте оно приобрело оттенок указания на функциональный аспект работ, развёртку в логическом/причинном времени — то есть стало синонимом «метода». Например, «процесс инженерного обоснования» сегодня означает метод в инженерном смысле, «много разных методов/практик, как составляющих метода в целом» инженерного обоснования: использование «формальных методов»²⁰² прямо с термином «метод» в названии, а также методов экспертной оценки, проведения стендовых испытаний, методов «ведения дела безопасности»/«safety case»²⁰³ и всеобъемлющего «обосновывающего дела»/«assurance case», и так далее — см. раздел по методам/практикам инженерных обоснований в руководстве по системной инженерии.

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

Очень часто про множество всех возможных методов говорят «деятельность» (activity или action, например, книжка von Mises по праксиологии/методологии и основам экономики называется «Человеческая деятельность»/«Human Action»²⁰⁴), и ещё про это же говорят «труд» (например, «разделение труда»/«division of labor»  — разделение работ по разным агентам, опирающееся на разницу в видах труда, то есть разницу в методах этих работ). Эта терминология развивается дальше в сторону разговора о больших группах методов — видах труда, видах деятельности. Речь про труд и деятельность ведётся обычно при обсуждении профессионального разделения труда, выделении каких-то групп агентов, которые обладают мастерством работ по каким-то широким группам методов в каких-то предметных областях: инженерия, менеджмент, инвестиции и технологическое предпринимательство, здравоохранение, правоохрана, культурное строительство, политическое переустройство общества, и т.д.

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

Неправильно говорить, что это «профессии», ибо слово «профессия» закреплено за «пожизненным ролевым определением, полученным долгим начальным специальным обучением». Но можно говорить о «профессионализации» или «профессиональности» как синониме мастерства какого-то агента.

Нужно признать, что «методы работы» и «профессии» (пожизненная или хотя бы очень долгая работа агента по какому-то методу) — близкие слова, только «профессии» сейчас отмирают, ибо занятости людей по освоенным им методам работы отмирают²⁰⁵, агент (человек в том числе) просто овладевает мастерством во множестве разных методов/способов/практик/культур/стилей работы.

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

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

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

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

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

Альфа метода имеет три важных подальфы:

• дисциплина/теория/объяснения/алгоритм. Это описание метода, которое будет проходить разные состояния по мере инсталлирования в головы работников и в память компьютеров, потихоньку становясь мастерством. Отношения тут сложные, как между кодом программы (абстрактный объект) и работающим софтом (физический объект), часто мы можем видеть поэтому целевым состоянием мастерство (оргзвена в выполнении оргроли, то есть проведении работ по методу). При разработке метода (например, при стратегировании) важнее иметь на выходе его описание, по возможности отчуждённое от разработчиков. При обучении часто описание метода есть, но нужно на выходе получить мастерство. Поэтому подальфой метода могут считать и мастерство, и даже оргвозможность, как ситуацию, в которой возможно применение мастерства. Метод называют обычно по его дисциплине. Дисциплину можно найти в таких рабочих продуктах, как учебники (документы!), регламенты предприятия, Body of Knowledge (публичные документы), стандарты. Поскольку это подальфа описания, то в жизни состояние этой подальфы надо определять как презентованное в таких рабочих продуктах, как документы (в том числе электронные документы).

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

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

Сам метод обычно (хотя и бывают нюансы) задаётся как сигнатура: функция/операция/процесс::поведение и предмет метода, который будет изменяться этим поведением. При этом и поведение, и предмет задаются типами. Сигнатура «покрасить насос» будет «покрасить»::операция/процесс::поведение (тип, а не конкретная работа-индивид покраски в марте 2034 года) «насос»::«физический объект» (тип предмета метода, а не индивид/экземпляр «насос муромского завода 2029 года выпуска с серийным номером 45793»).

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

Дисциплина имеется в виду именно объяснительная — «научная дисциплина», или «учебная дисциплина», то есть некоторая теория (фундаментальная/трансдисциплина или прикладная, это неважно, но она как-то объясняет происходящее в предметной области, говорит, что там причины и как они связаны со следствиями), модель или подход/approach/framework. Дисциплина определяет основные объекты внимания/альфы/функциональные объекты, необходимые для деятельностного мышления о предметной области (domain). Дисциплине обучается агент-актёр, исполнитель-роли, который потом будет играть оргроль (если мы говорим об интеллектуальных агентах и организациях), требующую мастерства в этой дисциплине для выполнения метода.

Инструментарий — это поддерживающие дисциплину инструменты/«средства производства». Современные методы работы не подразумевают работу только «голого мозга» и «голых рук», они обычно используют инструменты как поддержки работы мозга или группы мозгов в организации (экзокортекс/«база данных»: от бумажки и карандаша до сложного софта), так и поддержки работы по изменению окружающего физического мира руками и/или какими-то инструментами (tools, instruments). Cлесарные методы подразумевают не только задействование мастерства на основе описаний, как обрабатывать металлические детали, то есть мастерства как «прошитой» в мозге слесарной дисциплины/объяснений, но и слесарный инструментарий. Это были токарные станки раньше и обрабатывающих центры/станки с ЧПУ/CNC²⁰⁶ сейчас. Датчики и измерительная аппаратура (штангенциркуль в слесарном деле) тоже попадают в инструментарий.

Скажем, в управлении проектами (один из видов метода операционного управления) обычно используется софт управления проектами, например, MS Project или Primavera. Поэтому кроме принятия решения об использовании того или иного варианта дисциплины управления проектами (да, в управлении проектами тоже много видов этого метода, и надо выбрать из этого разнообразия — скажем, «метод критического пути», «метод критической цепи») нужно принять решение, какой конкретно софт будет использован в поддержку выбранного варианта дисциплины управления проектами.

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

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

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

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

Для методологического рассуждения (рассуждения о методах работы) надо найти в жизни эти типы.

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

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

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

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

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

• О поведении мыслим как части разложения более крупного поведения на составляющие (как в системном мышлении: первый ход всегда «наверх» к целым по любой системной иерархии или любому разложению метода), и его тоже раскладываем на более мелкие составляющие (вторым ходом). Модель такого разложения описывается теорией/объяснениями/алгоритмами — и дальше мы рассуждаем об алгоритмике, причём обобщении алгоритмики до универсальных преобразований в физическом мире, а формализация упирается в функциональное и иное декларативное программирование, знание основ computer science (информатики) и теории категорий как языка моделирования для computer science. Это делает трудным понимание формализации метода, трудно точно моделировать метод.

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

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

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

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

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

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

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

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

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

• Метод реально выполняется в жизни, это поведение (не описание, не система, не свойство)

• Метод описывается его дисциплиной/объяснениями/теорией/алгоритмом

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

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

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

А если гвозди начинает забивать автомат, а не люди? Тут возможны два варианта:

• Метод назовём функцией, автомат просто будет «выполнять функцию», а не «работать по методу». Рассуждение не меняется, но немного меняется терминология.

• Рассуждение и терминология не меняется: автомат просто считается частью оргзвена. И претензии к плохому выполнению метода идут не к автомату, а к людям в оргзвене.

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

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

С появлением систем AI всё существенно усложняется: до сих пор непонятно, как регулировать автомобили без водителя, если был наезд. С одной стороны, там во всём виновата программа системы AI, то есть неожиданно производитель автомобилей становится виноватым. С другой стороны, если бы автомобиль никуда не ехал — никого бы не задавил, пассажир виноват! Или устроитель дорожного движения, «строитель дороги», раз создал такие условия. Или владелец автомобиля — раз уж купил опасный предмет, пусть знает, что он может нанести непоправимый вред. В любом случае, с системами AI, которые принимают решения сами «без людей» мы оказываемся в совершенно новой ситуации, поэтому нельзя сказать, что тут сегодня доступны типовые способы рассуждений. Будьте внимательны, если у вас не автоматы, а системы AI — и терминологию надо выбирать аккуратно, и определять границы оргзвеньев тут тоже надо аккуратно, и обсуждать оргвозможности аккуратно, и прописывать сценарии использования для ситуаций, когда что-то пошло не так, надо тоже аккуратно.

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

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

TEST Методы

Семён пошёл на тренинг по продажам, потому что:

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

+++ Хочет освоить метод работы ### Да, продажи — это метод работы, поведение роли «продавец», именно методы работы изучают на курсах/тренингах (корпоративных или внешних), а потом задействуют мастерство работы по методу в реальных проектах.

Идя на ежедневную тренировку, Петя сегодня увидел разбитую тротуарную плитку, и перепрыгнул через дырку. Для Пети это:

+++ Действие ### Да, это разовое действие.

--- Метод ### Нет, это не метод. Ничего деятельностного/типового/культурно-обусловленного в проекте ходьбы на тренировку в этом нет, дисциплины/теории/алгоритма одноразового перепрыга никакой нет, паттерна (а метод — это паттерн/шаблон) нет.

--- Работа ### Нет, это не работа (задействование ресурсов, сроки выполнения не обсуждаются).

--- Стадия пути на тренировку ### Нет, это не стадия (укрупнённая работа в ходе пути на тренировку), никакой типичной периодизации/деления на стадии обычного ежедневного пути на тренировку тут нет.

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

--- Действие ### Нет, это не разовое действие — тут есть повторение, а обязательность намекает на какие-то культурные нормы/правила.

+++ Практика ### Да, это метод/практика/стиль, в действиях Пети есть дисциплина/алгоритм, какая-то теория — почему нельзя наступать на границы плиток. Можно спорить, является ли эта практика культурно-обусловленной, или это личная практика Пети, но для самого Пети это практика, выполнение (возможно, его собственных) норм/правил, следование «инсталлированной в его голове» теории/алгоритму, проявление мастерства.

--- Работа ### Нет, это не работа (не обсуждается ресурсная сторона вопроса, время выполнения) — речь идёт об обязательности перешагивания каждый раз как видишь границу, это небольшая теоретическая дисциплина, чёткое указание на метод.

--- Стадия пути на тренировку ### Нет, никакой периодизации обычного ежедневного пути на тренировку и выделенного для перешагивания периода времени тут нет, это не укрупнённая работа/стадия. Управления работами (планирование ресурсов, контроль выполнения, отслеживание загрузки ресурсов, определение сроков начала и окончания стадии и т.д.) тут нет.

Саша поцеловал Дашу от избытка чувств. Для Саши это:

+++ Действие ### Да, это разовое действие. И не спрашивайте о теории/алгоритме/дисциплине.

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

--- Работа ### Нет, это не работа, не обсуждается наличие ресурсов, точное время начала и окончания работы и прочие вопросы операционного управления.

--- Стадия встречи ### Нет, это не укрупнённая работа, и обычно во встрече не выделяются работы для этого поцелуя.

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

--- Действие ### Нет, это не просто разовое действие: есть слово «обычно», подразумевающее какую-то закономерность, правила/теорию/дисциплину.

+++ Стиль ### Да, это повторяющиеся действия (паттерн поведения, метод/стиль/культура), в которых наблюдается использование какой-то дисциплины/теории/алгоритма для того, чтобы поведение считать вежливым. Есть субкультуры, где при встрече целуются даже троекратно, независимо от пола — это культурно-обусловленное поведение, метод работы.

+++ Стадия встречи ### Да, работа выполнения поцелуев при встрече может быть основной для первой стадии встречи со знакомыми людьми, стадия (укрупнённая работа, требующая ресурса и занимающая время участников) может быть названа по этому методу. Указание времени показывает, что имеется в виду работа (затрата ресурса, «уходит по 20 секунд») речь вполне могла идти о стадии, одноимённой с практикой. Если бы это было «чисто логическое время», не давалась бы отсылка к физическому времени «20 секунд».

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

+++ Быстро найдёт подходящие курсы ### Да, такой метод найдётся, а раз есть метод/культура/практика, то и курсы по нему найдутся. Например, безопасному падению обучают в боевых искусствах (самбо, айкидо).

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

Геодезист 1-й категории Игорь установил теодолит по уровню. Он:

+++ Выполнял практику установки теодолита ### Да, он выполнял практику/метод, которой его учили как геодезиста — следовал знаниям учебной дисциплины (применял своё мастерство, использовал инструменты).

--- Просто установил теодолит, никаких методов ### Нет, геодезист выполняет установку теодолита по каким-то правилам/знаниям/алгоритмам/объяснениям, в его действиях есть паттерн — это метод/культура/практика его работы.

--- Ответ «выполнял метод» или «просто установил, никаких методов» зависит от того, как его учили ### Нет, геодезиста (агента, который выполняет роль геодезиста) учат геодезии, в том числе знаниям/объяснениям/дисциплине метода установки теодолита. Различаться могут варианты метода (например, могут быть разные версии метода, принятые в той или иной школе геодезической мысли), но не то, что его установка должна делаться по какому-то методу, определяемому знаниями геодезии.

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

Метод прыжков в высоту «ножницами» по отношению к методу прыжков в высоту является:

+++ Одним из вариантов метода ### Да, это вариант практики прыжков в высоту, отношение тип-подтип для поведения (специализация).

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

--- Независимым объектом, не связанным никакими отношениями ### Нет, эти методы связаны: «прыжки «ножницами»»::метод/практика являются специализацией::отношение «прыжков в высоту»::метод/практика.

Культура системного мышления:

+++ Является одним из видов мышления как метода работы ### Да, это специализация общей культуры мышления, отношение тип-подтип/род-вид/множество-подмножество/специализация.

--- Является функциональной частью практики мышления ### Нет, это не функциональная часть мышления, тут нет отношения часть-целое, важного для «частей».

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

Знания метода и как их описывать.

Главное в методе — «невидимое», дисциплина/теория/«модель предметной области»/объяснения/знания/алгоритм. Мышление «по дисциплине» (дисциплину ума, дисциплину использования понятий теории при мышлении) у какого-то человека нельзя проверить каким-то простым образом, использование дисциплинированного (а не дикого, «самодеятельного», «народного») мышления в деятельности/труде/культуре/инженерии трудно обсуждать, описание дисциплины мышления (по факту — описание метода мышления) в общем случае непонятно как делать.

Скажем, сама методология — это тоже метод, базирующийся на одноимённой научно-практической дисциплине. Казалось бы, люди из сообщества инженеров могли бы почитать об этой дисциплине в учебниках, которые писали праксиологи, которые писали философы-методологи, которые писали методологи оригинальных школ мысли (например, системомыследеятельностные методологи²⁰⁹). Но с инженерной методологической культурой исторически получилось всё совсем не так. Более того, когда потребовалось описать сам метод методологии, способа записи методов не нашлось, кроме пространных текстовых рассуждений и примитивных диаграмм — методологии-то как метода в этот момент у инженеров не было! Похоже, что обучение методологии систем AI тоже столкнётся с проблемами записи дисциплин, записи знаний/объяснений/теорий — доступно множество описаний «просто текстом»: в научных статьях (описание метода исследования), книгах (передача опыта какой-то деятельности), учебниках (описание дисциплин в форме, удобной для изучения людьми, в форме, удобной для изготовления человеческого мастерства).

Donald Firesmith рассказывал, что они с друзьями занимались в начале 80-х объект-ориентированным программированием, что тогда было остромодно и ново. Как-то его вызвал начальник и сказал: «у тебя производительность программирования стала в последнее время в несколько раз выше, чем у остальных в нашей компании. Научи их своему методу работы». Дональд пошёл на своё рабочее место думать над новым заданием, и понял, что не понимает — что такое «метод работы», чему же он должен научить других сотрудников? Что происходит в ходе выполнения программистского проекта методом объектно-ориентированного программирования? Ему было понятно, что он работает уже не так, как до знакомства с объектно-ориентированным программированием, но как описать эту разницу в работе? Внешне ведь это выглядело просто как «на работе днём сижу и думаю, а о чём думаю на работе — вечерами обсуждаю с друзьями». Описывать нужно было не столько внешнее поведение (что и как записывать из мыслей в код объект-ориентированной программы), сколько происходящее «в мозгах» объект-ориентированное размышление. Более того, описывать надо было ещё и не само поведение «что происходит в мозгах», а «метод работы», задаваемый дисциплиной/знаниями/объяснениями/правилами/алгоритмами этого метода. Надо было описывать знания для мастерства самых разных людей, которое бы могло повторить происходящее в мозгах Donald Firesmith во многих и многих разных программистских проектах, которые не видел и сам Donald Firesmith.

После этого Donald Firesmith с друзьями начал разрабатывать новый метод «инженерия методов»/«method engineering»²¹⁰. Конечно, методология и традиция методологии, а также соображения по общей теории деятельности ему не были знакомы — он же был не философ, а программист! Поэтому у него с друзьями были собственные догадки/гипотезы о том, какие должны быть основные объекты методологии. Скоро выяснилось, что никакой метод/способ работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект. Ситуация (технология и особенности целевой системы в конкретном проекте) меняла всё заранее пошагово/процедурно/императивно (например, на языке блок-схем, они эквивалентны процедурному языку программирования) записанный образец/шаблон/паттерн поведения. И тогда инженерию методов переименовали в «ситуационную инженерию методов»/«situational method engineering», чтобы подчеркнуть тот факт, что каждый метод работы зависит от ситуации, а между ситуациями выживает не сам метод как предзаданная последовательность операций, а только какие-то его части. В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices, фрагментами/fragments и т.д. — главным образом компонентами/кусочками/фрагментами выступали «артефакты» (рабочие продукты, даже не предметы методов), «процессы», «инструменты», вариантов было много. Языки ситуационной инженерии методов (то есть языки переизобретённой инженерами методологии, формализованной до уровня псевдокодного полуформального языка записи шаблонов поведения), каждый из которых определял свой набор «компонент метода», оформлялись в виде стандартов, по которым далее разрабатывались описания самых разных методов. При этом только дисциплин/теорий/алгоритмов (описаний методов), то есть методов в разложении инженерного процесса программной разработки и «железной» разработки существует несколько десятков тысяч. Десятки тысяч идей о том, как нужно начинать инженерную работу, продолжать инженерную работу, заканчивать (или наоборот — никогда не заканчивать, «непрерывное всё», вечная эволюция) инженерную работу.

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

Трансдисциплинарной (общей, «для всего», а не прикладной для какой-то прикладной предметной области) методологии и посвящено наше руководство.

Конечно, было множество попыток моделирования методов. Но все они были весьма и весьма неформальны. Например, в 1977 году строительными архитекторами был предложен подход «языков паттернов/шаблонов»/«pattern languages»²¹¹. Из строительной архитектуры этот подход перекочевал в архитектуру программных систем, подробно мы разбираем его в руководстве по системной инженерии в подразделе «Прохождение архитектурных развилок»²¹². Паттерн тут — это и есть метод работы (или хотя бы принципы, которым надо следовать при выполнении работ). Если посмотреть, что же там моделируется, то мы увидим — основное внимание уделяется сигнатуре метода. Оговаривается, что в какой-то форме надо описать имя паттерна, тип из классификации паттернов, решаемую паттерном проблему, но вот само решение описывается произвольным образом, «текстом на естественном языке», хотя вот для обоснования этого решения (обоснования того, что предлагаемый метод сработает как надо) и говорится, что можно использовать какой-то формализм (особенно, если речь идёт об обосновании решений по безопасности и защите). Формализация дорогая, но в части безопасности на цену обращают внимания мало.

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

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

• первое, ориентированное на методологов, которым нужно было описывать методы работы и систематизировать эти методы работы. Это прежде всего стандарты OPF, ISO 24744 и OMG SPEM 2.0. В этих стандартах было стремление к строгости, модели были трудночитаемы²¹³.

• второе, ориентированное прежде всего на удобство пользователей описаний метода (инженеров), а не на методологов. Пока это поколение стандартов состоит из стандарта OMG Essence²¹⁴, версия 1.0 которого была выпущена в ноябре 2014 (последняя версия — 2024 года). Там давался свой набор объектов, который должен был описывать метод разработки и развития системы (language), одним из основных понятий которого стала альфа как объект внимания к изменениям в проекте, а также дополнительно некоторый «пример» из основных (kernel) семи альф (возможности, стейкхолдеры, программная система, требования, команда, работы, способ работы), к которому нужно было привязывать все остальные альфы как подальфы этих основых/kernel.

В нашем руководстве мы используем часть языка/language современной версии стандарта OMG Essence, гармонизировав этот язык с достижениями многих других исследователей-методологов. Но эти семь основных/kernel альф из даваемого в стандарте примера использования языка, устарели. Эти альфы отражали не саму методологию и её объекты внимания, а были уже моделью популярного на тот момент «инженерного процесса»/«метода создания и развития программных систем», включающего, например, требования (от этой альфы в современной программной инженерии уже отказались, рабочие продукты, отражающие требования, в последние пять лет в большинстве проектов перестали разрабатывать). Вопрос об отказе от требований вызывает повышенный интерес, ибо требования оказались прописаны во многих и многих стандартах, которые с отказом от требований оказались устаревшими. Подробно этот отказ будет описан в руководстве по системной инженерии, тут только заметим, что:

• Отказались от того, чтобы иметь отдельных «аналитиков», пересказывающих ситуацию у клиента разработчикам. Это «испорченный телефон», появились более простые и точные методы выяснения того, что именно хотят клиенты.

• Требования — это именно «требования», модальность долженствования/деонтическая. Сейчас же принято считать, что высказываем гипотезы, а потом пытаемся подтвердить их: это вообще другой способ мышления, когда у тебя «догадки», а не «требования».

• Догадки можно документировать, но вот «зафиксировать» их нельзя, ибо отказ от них в ходе проекта — это важнейшее их свойство. Изменение же требований — это всегда более тяжёлая административно процедура, чем отказ от одной догадки в пользу другой. Более того, на догадку можно ответить несколькими разными способами, чтобы попробовать найти лучший. А требования — они предполагают однозначный ответ. И требования — это пережиток однократного «жизненного цикла», а сегодняшний инженерный процесс отражает «непрерывное всё».

• Догадки можно высказывать и пытаться их поддержать свойствами системы асинхронно, работа с «требованиями» требует обычно собрать все требования и проверить из согласованность. В реальных условиях это существенно тормозит проект.

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

Методология представляет собой тоже метод:

• Метод методологии работает над предметом метода «метод».

• Роль исполнителя метода методологии — методолог.

• Дисциплина/теория/знания/объяснения/алгоритмы метода методологии — учение методологии (это обычно, метод называется по дисциплине).

• Инструментарий — самые разные моделеры для описания метода.

Повторим:

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

• Мастерство в прикладной методологии (разбирательство с тем, какие методы сегодня SoTA в какой-то прикладной системной области) нужно прикладным методологам. Если вы архитектор, то вам потребуется знать SoTA архитектурных методов, например, знать методы документирования архитектурных решений (ADR, architecture decision record — только один из таких методов, профи в архитектуре должны знать больше).

• И ещё мастерство в прикладной методологии нужно профессиональным методологам, которые в инженерном проекте занимаются именно методами работы. Скажем, в инженерии личности работают с мастерством в каком-то методе. Поэтому там визионерами по части методов/практик являются культуртрегеры, которые определяют необходимость в работе по какому-то методу. Регламенты, стандарты, справочники, инструкции по разным методам/практикам пишут методологи совместно с предметными экспертами (SME, subject matter expert) в соответствующей предметной области, а при подготовке материалов курсов (учебники, руководства, задания) к ним добавляются методисты (специалисты по instructional design, их мастерство — находить эффективные способы объяснения материала, подбирать задачи и упражнения и советовать способы удержания мотивации к обучению). Конечно, если рассматривать обучение кого-то методу как «изготовление мастерства работ по методу», то потребуется задействовать множество разных ролей (мы даже не помянули ещё роль ученика/студента, роль педагога/наставника, но и это не весь список), это подробней изучается в руководстве по инженерии личности. Если вы методолог программной инженерии, то знаете SoTA методы создания и развития программных систем и помогаете проектировщикам и кодировщикам в нахождении и разъяснении этих методов. Если методолог систем AI, то знаете методы создания таких систем (развёрнутый пример был в первом разделе нашего руководства).

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

Это проблема танцев против плясок: с одной стороны «танец» — это следование какому-то канону стиля, культурно-обусловленным шаблонам, с другой стороны — «пляска» как полное игнорирование канонов, «движения по велению души». Если только шаблон — вроде как творчества нет, но как только вы пускаетесь в пляс, ваши паттерны становятся очень и очень простыми, в них нет накопленного эволюцией опыта! А «предписанные шаблоны» вдруг оказываются весьма разнообразными и никакая «пляска» близко не подходит к сложности этих шаблонов «танца», ибо сложность там создавалась длительной эволюцией, накоплением опыта. Подробней в работе «Чем танец отличается от пляски»²¹⁵.

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

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

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

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

Скажем, дисциплина «квантовые вычисления» развивается на базе фундаментальных физических исследований, исследований по квантовой физике (ибо «квантовые») и исследований по информатике (computer science). К этой дисциплине потом добавляются инструменты: прежде всего сами квантовые компьютеры — и получается метод квантовых вычислений/компьютинга (называемый по дисциплине). В дисциплине квантового компьютинга²¹⁶ вводится понятие квантовой информации и единицы её измерения кубита — это новые понятия, которые сначала были высказаны как гипотезы, и которые оказалось трудно опровергнуть. Квантовый компьютер как инструмент (физический объект) эквивалентен функционально классическому компьютеру (то есть универсален по критерию Тьюринга: может выполнять все те же вычисления, что и машина Тьюринга, что и мозг человека — разница только в эффективности вычислений по тем или иным алгоритмам).

Гипотезы (например, существование квантовой информации и операций с ней) проверяются логикой, а потом ставятся проверочные эксперименты — точны ли в выражении реальности модели/теории больше, чем модели/теории с другими догадками. И если эти догадки более точны, то их принимают всерьёз. В том числе поддерживают инструментами. Так, догадки в части энергии атомного ядра поддержали инструментом «атомная бомба» («открытие на кончике пера» дисциплины, а затем создание инструмента для метода проведения атомных взрывов). Догадки по части квантовых вычислений в части дисциплины (идея David Deutsch, высказанная в 1985 году²¹⁷) были тоже прокритикованы, выдержали критику, далее эти идеи приняты всерьёз — и поддержаны созданием инструментария квантовых компьютеров²¹⁸.

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

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

Так что зачастую достаточно отобрать какой-то набор альф из уже известной литературы, гармонизировать их между собой, изложить в виде учебного курса, руководства, регламента, стандарта или справочника/handbook — это такое «мета-исследование»/«мета-наука»²¹⁹, исследование по материалам других исследований. Учебник по дисциплине — это уже переход к разработке мастерства (instructional design как дисциплина разработки учебных продуктов, роль — методист), и это хорошая форма выходного результата для работы методолога: дисциплина ведь «оживает» только после «загрузки» в чью-то голову (хотя есть вариант «оживления» её в виде компьютерной программы, использующей её понятия и выполняющей фрагменты её предметного мышления в экзокортексе, а ещё есть вариант «оживления» в системе AI). А затем эта дисциплина должна быть поддержана инструментарием. И ещё должны быть предметы метода надлежащего качества (самый искусный повар, знаток кулинарии, владелец шикарного кухонного инструментария не сможет приготовить вкусную еду из гнилых продуктов, или не сможет приготовить борщ из рыбы без овощей — увы, в рабочих проектах часто в таких ситуациях мастерам предлагают «сотворить чудо»).

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

Инструментарий для нашего варианта методологии как метода мышления предполагается обычный для методов мышления: какой-нибудь моделер, начиная от «ручки-бумажки» для текстовых моделей невысокого уровня формальности, заканчивая универсальным моделером для табличного моделирования типа notion.so, coda.io (и может быть ещё много самых разных вариантов моделеров, один другого сложнее — помним, что методы трудно формализовывать, но всё-таки можно).

Этот набор методологических понятий и понятий системного мышления был первоначально изложен для руководства по методологии в виде не слишком удобного для изучения «текста справочника» (без повторений, примернов, вопросов/quiz и заданий по моделированию и написанию постов) — это была проведена методологическая работа, получено сухое формальное описание метода, которое описывалось как «собрать под одной обложкой все знания о методологии». Затем содержание материала в ходе неоднократных переписок стало уже не «энциклопедией/справочником», а руководством/guide, причём не с нейтральным «информационным» изложением, а наставлением (предназначенным для исполнения, регламентом работы, указанием метода работы), более удобным для освоения, более удобным для понимания. В руководство были добавлены более подробные и понятные объяснения, указаны наиболее часто встречающиеся «новичковые ошибки» в применении его наставлений, появились вопросы/quiz на основе идей concept inventory²²⁰, задания на табличное моделирование/«мышление моделированием», задания на чтение литературы и текстовое моделирование/«мышление письмом» для удержания мозга на некоторое время в мышлении с использованием понятий дисциплины методологии в приложении к реальной жизни), это была методическая работа (instructional design). Причём в ходе методической работы были использованы материалы множества других прикладных (инженерия личности) и фундаментальных (интеллект-стека, например, семантика и онтология) методов мышления, прописаны связи предметов метода методологии с предметами многих других методов мышления: помним, что в одном руководстве могут излагаться знания/объяснения несколько разных дисциплин. Так, в руководстве по методологии много отсылок «назад» к руководствам по рациональной работе и системному мышлению, а также «вперёд», к руководствам по системной инженерии, инженерии личности, системного менеджмента.

Все тексты руководств для инженеров-менеджеров изложены так, что вместе они дают целостную, гармонизированную картину мира, изложенную на уровне абстракции: общей для инженеров-менеджеров современной мета-мета-модели мира.

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

• изменение текущей версии дисциплины методологии (отражение эволюции методологического учения, отслеживание SoTA) и

• изменения в части согласованности наставлений руководства с другими руководствами мастерской инженеров-менеджеров (управление конфигурацией знаний).

Это всё описывает соответствует третьему поколению системного подхода и современной эволюционной системной инженерии. Руководства — это «документация как код», так что руководства разрабатываются (создаются MVP, затем они развиваются) по эволюционным/agile методологиям, а затем они используются для такого же эволюционного создания и развития мастерства инженеров-менеджеров.

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

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

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

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

Технология моделеров для методологии позволяет делать модели методов в самой разной форме. Многие варианты представления методов обсуждались в первом разделе (например, принципиальные схемы), далее мы подробней рассмотрим представление методов работы в организации в виде регламента/стандарта/инструкции с шаблоном чеклиста.

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

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

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

Инструментарий меняется много чаще, чем SoTA дисциплин в поддерживаемых инструментарием методах. Моделеры для того же системного подхода меняют свои поколения каждые 4 года (средняя скорость смены поколений в информационных технологиях. Например, в 2019 году появился стандарт описания функциональной структуры системы для моделирования физических систем SSP, system structure and parametrization, а в 2020 году появились первые моделеры, его поддерживающие²²¹ — технологии моделирования тоже меняются быстро). Но все эти моделеры по факту поддерживают одну и ту же много медленней меняющуюся дисциплину, даже не всю дисциплину, а какие-то её части.

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

Нельзя успокаиваться после получения мастерства в какой-то дисциплине, надо продолжать отслеживать развитие методов, которые основываются на этой дисциплине, развитие инструментария этих методов, появление новых предметов метода. Надо учитывать, что состояние state-of-the-art (SoTA, «лучшее известное на сегодняшний момент») методов мышления и работы описывается в учебниках и курсах обычно не меньше чем через пять лет после его появления в ходе исследований (в том числе R&D, «исследований и разработок» — речь тут не идёт только об академической науке, исследованиями и разработками занимаются практически все предприятия). Ещё пять лет проходит до начала массового изучения дисциплины в вузах (дисциплина попадает в учебные планы не сразу! Учебники и курсы уже есть, но в учебных планах вузов их нет). Всего через десять лет после окончания вуза можно обнаружить, что владеешь каким-то уже совсем антикварным пониманием метода работы — двадцатилетней «свежести». При этом время летит быстро, и «двадцатилетний опыт» задействования какого-то метода оказывается «однолетним опытом двадцатилетней давности, повторённым двадцать раз».

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

Lean manufacturing (элегантное/минимализированное/бережливое производство) впервые был упомянут в статье 1988 года²²², прошло более тридцати лет с момента появления этого метода! Kanban уже прокритикован, ему тоже уже десятки лет (см. критику канбана в подходе TameFlow и руководстве по рациональной работе. Этот момент будет затронут и в руководстве по системному менеджменту). Нужно регулярно отслеживать не только относительно частые смены инструментария методов, но и относительно редкие изменения в дисциплине метода!

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

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

TEST Дисциплины в основании методов работы

В детском саду дети освоили метод устного счёта. Какая дисциплина лежит в основе этого метода счёта?

--- Педагогика ### Нет, эта дисциплина лежит в основе методов, использованных воспитателями, а не освоенных детьми.

+++ Теория целых чисел ### Да, в основе устного счёта лежит теория целых чисел.

--- Опыт счёта, имеющийся у воспитателей ### Нет, «опыт» — это не дисциплина.

+++ Арифметика ### Да, это основная дисциплина в основе устного счёта.

--- В этом нет никакой дисциплины ### Нет, правильно считать без правил/теории/дисциплины/объяснений/алгоритмов/норм не получится. «Правильно» — это «по правилам»!

Какая дисциплина используется при разработке программных средств проектного управления?

+++ Проектное управление ### Да, проектное управление (project management) уже десятки лет составляет самостоятельную дисциплину (знания, теории, правила, нормы).

+++ Исследование операций ### Да, проектное управление в том числе использует теоретические результаты этой научной области, operations research.

--- Опыт проектных управляющих ### Нет, «опыт» — это не дисциплина.

+++ Математическая статистика ### Да, проектное управление в том числе использует теоретические результаты этой научной области.

--- Физика ### Нет, проектное управление практически не использует теоретические результаты этой научной области, хотя был краткий момент известности варианта операционного управления под названием factory physics (погуглите).

+++ Финансы ### Да, программные средства для проектного управления часто содержат блоки, реализующие учёт финансов, то есть используют правила этой дисциплины.

--- Не использует никакой дисциплины, только опыт разработчиков ### Нет, в разработке будут использованы понятия и правила многих разных дисциплин, а хоть и преломлённых опытом (неформальное, неявное знание, tacit knowledge) разработчиков.

Какая дисциплина лежит в основе метода ведения переговоров?

+++ Конфликтология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях конфликтологии.

+++ Социология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях социологии — науки о групповом поведении людей.

+++ Психология ### Да, многие варианты практик ведения переговоров основываются на теоретических положениях психологии (но тут надо особо заметить, что теоретические положения многих и многих школ психологии давно прокритикованы, тут надо быть очень осторожным).

+++ Логика ### Да, многие технологии ведения переговоров основываются на теоретических положениях логики и рационального мышления.

--- В практике переговоров нет никакой дисциплины, важен опыт ### Нет, в переговорах надо использовать объяснения/знания/правила/теорию/нормы многих разных дисциплин.

Дисциплинарный комитет ООО «Профтехснабстроймонтажавтоматика» рассмотрел жалобу слесаря В. Пупкина на оскорбления со стороны начальника участка К. Щеглова и объявил ему порицание. На какой дисциплине основан метод работы дисциплинарного комитета?

--- Положение о дисциплинарном комитете ### Нет, это назван документ, описывающий организацию работы комитета, но не дисциплина/теория/правила/нормы.

+++ Этика ### Да, работа дисциплинарного комитета основывается, в том числе, на этических нормах и правилах.

--- Здравый смысл ### Нет, «здравый смысл» — это не дисциплина.

+++ Конфликтология ### Да, работа комитета основывается, в том числе, на рекомендациях дисциплины конфликтологии (и плохо, если не основывается).

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

Инструменты метода как поддержка его дисциплины

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

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

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

Например, управление проектами может быть классическим с предметом метода критический путь (critical path), но теория ограничений Голдратта критикует использование предмета метода «критический путь» и предлагает другой предмет: критическая цепь (critical chain)²²³ и управление проектом основывается на отслеживании подальфы буфера проекта²²⁴ альфы «работа». Если вы не понимаете связи между инструментами (в данном случае софт управления проектами) и разными вариантами дисциплин/теории проектного управления с их «специфическими понятиями для отслеживания»/«альфами и подальфами», а купите просто какую-нибудь «популярную программу управления проектами», то вас может ожидать сюрприз: программы будут развёрнуты, кнопки на них будут как-то нажиматься, формы заполняться, но практика управления проектами выполняться не будет, проектам лучше не станет! Подальфы буфера проекта в некоторых методах управления проектами попросту нет, она не существует в дисциплине с критическим путём — и поэтому софт для этой дисциплины её не отражает!

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

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

Если не владеть каким-то менеджерским кругозором в части вариантов дисциплин проектного управления, то можно вообще не понять, почему так различается инструментарий для вроде бы одной и той же практики, а «светофоры буферов» будут казаться особенностями интерфейса программы, а не варианта дисциплины проектного управления.

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

TEST Инструментарий

Выберите части, которые могут входить в инструментарий тренировок прыжков в высоту:

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

--- Учебник физики для физкультурных вузов ### Нет, это документация дисциплины (знания, объяснения, дисциплина), а не часть поддерживающего дисциплину инструментария.

+++ Планка и стойки для её крепления ### Да, это часть инструментария/оборудования тренировок.

+++ Мягкий мат ### Да, это часть инструментария/оборудования тренировок

+++ Секундомер ### Да, это часть инструментария тренировок

+++ Рулетка ### Да, это часть инструментария тренировок

+++ Покрытие дорожки для разбега ### Да, это часть инструментария тренировок

--- Зрители соревнований по лёгкой атлетике ### Нет, зрители не входят в инструментарий тренировок как часть, они не используются в ходе тренировки

+++ Видеокамера для замедленной съёмки ### Да, это часть оборудования тренировок

--- Соревнования по прыжкам в высоту ### Нет, соревнования не входят в инструментарий тренировок, они не задействованы в тренировке

В инструментарий инженерных расчётов могут входить:

--- Учебник математического анализа ### Нет, это документация дисциплины (теория, алгоритмы, объяснения, правила), а не часть поддерживающего выполнение алгоритмов/объяснений инструментария.

--- Задачник по математическому анализу ### Нет, это документация дисциплины (знания, объяснения, дисциплина, правила), а не часть поддерживающего выполнение дисциплины инструментария.

+++ Логарифмическая линейка ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Калькулятор ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Научный калькулятор (с корнями, тригонометрией, логарифмами и т.п.) ### Да, это часть одного из вариантов инструментария инженерных расчётов

+++ Математические программы (Mathematica, Maple, Sagemath, Oscar или аналогичные) ### Да, это часть одного из вариантов инструментария (софт — это современное оборудование, «мягкое оборудование», software) инженерных расчётов.

+++ Специализированные программы инженерных расчётов ### Да, это вариант инструментария (софт — это современное оборудование, «мягкое оборудование», software) инженерных расчётов.

--- Проектное бюро, в котором используются все прочие предметы из перечисленных тут ### Нет, само бюро не входит в инструментарий. Инструментарий расчётов в бюро может принципиально измениться, а бюро останется. Скорее уж инструментарий является частью оргзвена бюро.

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

Инструментарий машинописи может включать в себя:

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

--- Повязку на глаза ### Нет, это часть инструментария тренировки машинописи по одному из методов обучения машинописи, но не часть самого инструментария машинописи.

+++ Десять пальцев ### Да, это часть одного из вариантов инструментария машинописи — где инструментами являются все десять пальцев, а не меньшее их число.

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

+++ Механическую пишущую машинку ### Да, это часть одного из вариантов инструментария машинописи, где текст переносится от клавиш к бумаге механическим устройством.

Культура приёма экзаменов может задействовать следующий инструментарий:

+++ Наборы вопросов на листочках (билеты) ### Да, это часть определённого инструментария приёма экзаменов, билеты тут инструменты полного отображения тем в заданиях и одновременно внесения случайности в выбор тем для экзамена.

--- Учебник по предмету экзамена ### Нет, это документация с описанием знаний/дисциплины, по которой сдаётся экзамен, а не часть инструментария приёма экзаменов.

--- Учебник «Как вести себя на экзамене» ### Нет, это документация с описанием дисциплины сдачи экзаменов, хотя в нём могут быть описаны разные части инструментария приёма экзаменов, но документация по дисциплине — это не инструментарий.

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

+++ Помещение для приёма экзамена (отвечающее требованиям к уровню шума, освещению, входу-выходу, глушению сигнала мобильных телефонов) ### Да, это часть одного из вариантов инструментария приёма экзаменов, дающего безопасность и удобство.

+++ Экзаменационная ведомость ### Да, это документ/артефакт/«рабочий продукт» — часть варианта инструментария приёма экзаменов, учётная система для регистрации результатов (меняет состояние в ходе экзамена).

+++ Шпаргалки ### Да, это артефакт/«рабочий продукт» в одном из вариантов инструментария сдачи экзамена (приём экзаменов — то же самое, только другой референтный индекс, описание от другого лица), его учитывают в дисциплине/правилах/знаниях/объяснениях приёма экзаменов и экзаменатору нужно знать правила/нормы, как на этот артефакт (не на его содержание! На сам артефакт!) реагировать в случае появления в физическом мире в ситуации приёма экзамена. Это функциональный физический объект (носитель информации подсказок), конструктив тут может быть записью формулы шариковой ручкой на бедре под юбкой, бумажной маленькой книжечкой с подсказками, смартфоном с беспроводным аудиоинтерфейсом и беспроводным микрофоном и наушником прямо в ухе, замаскированными волосами.

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

--- Вскрытие конвертов с вопросами непосредственно перед экзаменом ### Нет, это метод («вскрытие» — отглагольное существительное) из разложения метода приёма экзаменов. А вот частями инструментария тут являются конверты с вопросами.

+++ Бланки для подачи апелляции на результаты экзамена ### Да, это артефакты/рабочие продукты, части варианта инструментария приёма экзаменов.

Совершенствование и развитие

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

Методы работы (методы в составе инженерного процесса) при совершенствовании меняются главным образом в части замены инструментария на более производительный и изменения моментов начала и конца выполнения работ в целях их ускорения. К совершенствованию будут относиться и меры по надзору за выполнением рабочих процессов «как надо» (в соответствии с описанной в регламентах, инструкциях, стандартах дисциплиной), а не «как придётся», что поднимет качество выполнения работ и уменьшит переделки/re-work. Это и дообучение сотрудников, и работа с чеклистами и даже автоматизация (сдвиг части работ людей на не очень живых агентов). Главное, что лежащие в основе метода его знания/теории/дисциплины/объяснения/алгоритмы — они не меняются.

Например, при совершенствовании люди переучиваются (training) на работу с новым инструментом, скажем, осваивают новый софт для той же дисциплины: пересаживаются с одного САПР на другой, или с одного issue tracker на другой — ничего не меняя в своём мышлении. При совершенствовании не нужно дополнительно образовываться в части прикладных дисциплин выполняемых методов, читать учебник с новыми понятиями — мышление остаётся тем же. Резал салаты обычным кухонным ножом, поменял нож на профессиональный поварской из лучших сортов стали — всё, затачивать нож надо реже, огрехов в нарезке меньше, но ничего в умениях резки менять не надо. Если в фирме годовой цикл бюджетирования был без поддержки софта, а стал с поддержкой софта — это совершенствование, но не развитие. Развитие — это когда надо будет поменять метод бюджетирования с ежегодного на постояннотекущее, beyond budgeting (будет проходиться в «Системном менеджменте»), для этого развития придётся переучить всех сотрудников, соприкасающихся с тратами средств предприятия. Для совершенствования переучивать не надо, дисциплина не меняется, из неё просто выжимают с каждым шагом совершенствования всё, на что эта дисциплина способна в плане роста производительности.

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

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

Развитие (development) предприятия/оргзвена (помним, оргзвено — это от одного человека, даже и участвующего part time, а не полный рабочий день) происходит тогда, когда меняются знания, используемые мастерством выполнения метода. Это означает чаще всего, что меняется и поддерживающий это мастерство инструментарий. Поменяли синхронную коммуникацию (совещания) на асинхронную (форумы и чаты)²²⁵ — и тут же изменились инструменты: исчезли большие столы в комнатах начальников, исчезло изобилие переговорок, зато появились многочисленные треды комментов в самых разных информационных системах, начало работать множество чатов в мессенджерах.

Для возможности развития люди образовываются (education, «как в школе и вузе») для получения возможности быстро учиться, осваивать новое, не теряться в новых ситуациях. Затем для освоения новой прикладной дисциплины мышления по новому методу, они изучают новые понятия и их отношения, а дальше обучаются/тренируются (training, часто на рабочем месте) в работе с новым инструментарием поддержки новой дисциплины.

По факту при развитии происходит коррекция мемома, знаний по созданию систем — те самые smart mutations/«умные мутации», которые потенциально (не факт! Это всё «гипотезы», хотя и тщательно продуманные) приведут к получению новых качеств. Скажем, когда подхакивают гены утёнка и он становится больше похожим на лебедя, и если теперь повторять создание системы по этим генам, то сразу и шея бывшего утёнка будет длиннее, и тело крупнее. Это, конечно, не отменяет того факта, что новую систему тоже можно совершенствовать, но шея у даже плохонького «нового развитого утёнка» будет подлинней, и тело покрупней, чем у хорошо тренированного и откормленного «старого долго совершенствованного», а уже если его совершенствовать — то и шея несказанно длинней, и тело существенно крупней. Гены решают всё. Без развития, то есть смены знаний, а не только совершенствования как «надлежащей настройки» при тех же знаниях, будет «лысенковщина»²²⁶: попытки получить путём «надлежащего ухода за организмом» такой феном (набор отличительных признаков организма), который можно получить только модификацией генома. Ничего хорошего из такого подхода «много совершенствования даст развитие» обычно не получается: сколько ни совершенствуйте прыжок в высоту методом «ножниц» (знания/алгоритм там — прыгать к планке лицом, перекидывая одну ногу за другой над планкой), двух метров планки вам не преодолеть. Придётся полностью перестроить объяснения/теорию/знания того, как надо прыгать: учить мастерству разворачиваться в полёте к планке спиной и перелетать её лицом вверх — переучивать в прыжке придётся всю технику прыжка, прошивать в виде мастерства новую дисциплину. А заодно менять инструментарий: накачивать другие мышцы в их другой координации, нежели дающие максимальный результат для прыжков «ножницами».

Текущий тренд (впрочем, этот тренд был всегда — просто это было трудно заметить, в развитии работают экспоненциальные законы, и ещё совсем недавно тренд был не так очевиден, об этом будет рассказываться чуть дальше) в том, что периоды совершенствования становятся всё короче и короче, и всё чаще и чаще приходится осуществлять шаги развития: предприятие/оргзвено начинает использовать незнакомые членам команды методы работы. Чаще меняться в работах по каким-то методам начинает не только инструментарий, но и весь метод в целом (часто вместе с агентами, которые меняются с имеющих великолепное мастерство в старом методе на имеющих хотя бы едва приемлемый уровень мастерства в новом методе). В конкурентной борьбе оказывается недостаточно использовать «лучшие инструменты», необходимо использовать и «лучшее мышление», которое происходит в силу обучения лучшим на сегодня (SoTA) знаниям. И уж это «лучшее мышление» поддерживать «лучшими инструментами». Скажем, признать, что в текущей деятельности невозможно какое-то планирование up front и перейти от классического управления проектами с софтом управления проектами к управлению кейсами и освоить софт трекеров/issue tracker — тут описан массовый переход от одного поколения методов операционного менеджмента к другому, который описан в предыдущих двух разделах.

Интересно, что некоторые наши инженеры-менеджеры воспринимают материал предыдущих разделов как справочно-исторический, «художественную вставку в текст учебника, передышку в изучении». Но нет:

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

• Самое страшное тут — это взглянуть в зеркало: что у вас в голове? Поднимите вашу переписку, пересмотрите ваши видео. Каким языком вы говорите о вашем инженерном процессе? Например, «итеративность» — вы имеете в виду «спринты» в «непрерывном всём», но почему говорите «итерации»? Или более древние «итерации» из RUP — докрутку в несколько спринтов до заранее запланированного результата? А что понимают под этим ваши коллеги? Какой у них в голове инженерный процесс, как отражаются в этих головах ваши слова? Попробуйте выявить использование терминов в вашей речи, провести контроль типов, буквально понимать то, что вы же говорите. Совпадает ли то, что вы реально сообщаете с тем, что вы думали сказать? Опыт наших учебных потоков показывает — нет, не совпадает. Материал разделов не был использован как учебный, как инструкция для мышления и проверки качества коммуникации.

Всё то же самое надо смотреть и в самых разных других материалах, в которых рассматривается смена инженерной культуры, смена методов работы. Это, например, новостные ленты профессиональных медиа, занимающихся прикладной методологией той или иной предметной области. Скажем, вы пошли учиться самому модному языку программирования для разработки вебсайтов (веб-разработка, «инженерный процесс разработки приложений, доступных в виде интернет/веб-сайта через веб-браузер») — PHP, и вдруг (по историческим меркам — действительно вдруг!) этот язык стал абсолютно немодным. И то же самое произошло с другим самым модным языком — Perl. При этом вы изучили ещё один язык JavaScript, и угадали, он вроде бы немного задержался. Но нет, каждые несколько лет вам приходится выучивать «язык на языке», который вроде бы является инструментом (программный фреймворк), но на деле требует мастерства в некоторых весьма специфических методах веб-разработки. И вам приходится переучиваться каждые несколько лет, хотя вроде бы вы и знаете язык! Ужас же ещё и в том, что «вышел из острой моды» — это ничего обычно не значит, ибо перспектив у метода вроде уже нет, но в мире полно людей, которые пользуются этим методом после долгих периодов совершенствования, и новые перспективные методы на самых первых шагах, не имея шанса показать себя полностью, в глазах многих и многих людей имеют равные примерно возможности со старыми методами и их инструментарием. Вот она, неустроенность (не путаем с конфликтами, не путаем с неудовлетворённостью) — наличие огромного числа вариантов методов с похожей эффективностью для каждой сигнатуры метода. Но если приглядеться, то окажется, что в тех же языках программирования популярность их разительно меняется, скажем, до 2002 года мы ничего не слышали о языке PHP, затем через восемь лет в марте 2010 он оказался третьим по популярности среди всех языков в индексе TIOBE²²⁷ (ибо на нём программировали Мордокнигу, поэтому довольно много людей сочло, что в их проекте этот язык тоже будет хорош), в апреле 2024 он уже семнадцатый, взлёт и падение прошли за какой-то десяток лет²²⁸:

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

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

Отследить развитие трудно:

• Надо иметь мастерство методолога (владеть фундаментальной методологией, часть хорошего образования, один из методов мышления интеллект-стека), чтобы работать с методами, как объектами первого класса: моделировать их, обсуждать, сравнивать.

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

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

Умение увидеть объекты мышления в объектах из жизни (понятийное наведение внимание) и удерживать их во внимании в течение всего хода проекта (собранность, в том числе личная и коллективная) тренируется. Это умение — основное, что отличает людей с хорошим базовым образованием от дилетантов, просто запомнивших наиболее часто встречающиеся последовательности нажатия кнопок на вверенном им инструментарии какого-то оргзвена. Люди с хорошим базовым образованием обычно способны провести элементарное рассуждение в терминах знаний/дисциплины/объяснений/онтологии/правил/алгоритмов метода и грамотно (без новичковых ошибок!) применить инструментарий с учётом области применимости знаний метода — и у них будут smart мутации метода, а дилетанты-кулибины обычно будут предлагать варианты с новичковыми ошибками, и у них будут не smart, а обычные мутации (ошибки репликации! Огромное число мутаций в природе смертельны, удачны мутации крайне редко!) будут приводить к неэффективности и неудачам. Если речь идёт о хорошем владении инструментами, то автоматизмы ими владения не освобождают от мыслительных ошибок из-за невладения знаниями метода. В музыке вы можете играть на саксофоне интуитивно, в танце вы можете танцевать интуитивно, в кулинарии можете готовить борщ интуитивно, но вот если будете интуитивно проектировать ракету, то она вряд ли улетит далеко — нужны знания. В том числе нужны знания о том, как проводить оргразвитие (развитие организации, то есть получение оргвозможности какого-то метода работы). Про оргразвитие подробно рассказывается в руководстве по системному менеджменту. Но идеи развития одного человека или системы AI и оргзвена (команды проекта, стартапа, предприятия) одни и те же, и даже в какой-то мере могут быть распространены на сообщества и общества. Поэтому наше руководство по методологии включает в себя и раздел по теории стратегирования — теории метода выбора метода в ситуации, когда непонятно что делать. Для стратегии вы будете затем получать оргвозможность, чтобы реализовать эту стратегию (метод, выбранный в ходе работ стратегирования). Описание этого выбранного метода — стратегия, затем надо спланировать ресурсы, это планирование, затем получить ресурсы и принять решение о деятельности, затем приступить к выполнению работ по стратегии. Так что наше руководство по методологии в том числе нужно использовать и для стратегирования организационного развития, и для стратегирования личного развития, и для стратегирования развития сообществ.

Где искать описания современных методов менеджмента и инженерии

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

• слова важны (у нас кроме слов обычно ничего нет), и

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

Наиболее типичны для документирования прикладных методов классического инженерного процесса и основных методов менеджмента такие публичные документы и стандарты, как своды знаний (body of knowledge²²⁹, корпус знаний), описывающие различные подпрактики какой-то более-менее крупной практики/деятельности и возможные варианты выбора этих подпрактик в какой-то связный метод. Но описания методов могут быть найдены и в справочниках, и в учебниках, в монографиях, небольшие методы могут быть описаны в статьях и блог-постах, набирает форму и видео рассказ-показ в соцсетях. Скажем, культура социальных танцев редко документируется текстами, чаще это видеоролики — по понятным причинам, но если речь идёт о предъявлении культуры/стиля на соревновании/конкурсе для оценки соответствия предъявляемого стиля танцевания судьями, то ассоциации танцоров какого-то стиля готовят стандарты, которым надо соответствовать, чтобы считаться победителями. Если есть несогласие с тем, что сделала одна какая-то ассоциация в плане документирования метода, в спор включается другая ассоциация с другим стандартом.

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

Например, в медицине лечат сегодня по протоколам диагностики и лечения²³⁰ — эти протоколы и есть методы лечения, лечение/работа идёт по описаниям способов лечения/работы в этих протоколах. В сводах знаний могут запросто метод обозвать мастерством, могут обозвать способностью/ability.

В организационном менеджменте чаще всего встречаться будут процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000). Не реже будут и методы (помним, что в инженерии термин «метод» часто используется как набор составляющих его более мелких практик, достаточный для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), а иногда и «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity).

У СМД-методологов используется термин «деятельность» и даже «труд» (когда говорится о разделении труда, division of labour/labor). А с учётом того, что методы что-то меняют в окружающем мире для того, чтобы изменить этот мир к лучшему путём создания успешных систем, их называют ещё и инженерией (и не только классической «железной» или программной инженерией, но и генной инженерией, социальной инженерией и т.д.). Деятельность, труд, инженерия всё-таки сами по себе общи, часто ими называют и все возможные методы, которыми работают интеллектуальные агенты, например, «человеческая деятельность» — это отсылка ко всем методам, которыми работает человек, всё, что делают люди. Так что тут могут сужать значение, говоря о виде деятельности, виде труда, виде инженерии — это будет достаточно широко понимаемый метод работы, с вариантами разложения для очень широко понимаемой сигнатуры. Скажем, инженерия путей сообщения как вид инженерии — все методы работы путевых инженеров. Формально пути сообщения — это и автомобильные дороги, и водные пути, и железные дороги. Часто инженерия путей сообщения понимается вообще узко, только как инженерия железных дорог²³¹. Программная инженерия (software engineering) тоже весьма и весьма широко понимаемый набор методов создания программных систем. Посмотрите на то, как «программная инженерия» таки сводится к «методу разработки» в статье Википедии²³², вы там увидите в определении множество знакомых слов из синонимов метода работы, все эти слова как-то ссылаются на одно и то же: Software engineering is an engineering approach to software development. A practitioner, called a software engineer, applies the engineering design process to develop software. Неявно из синонимов метода тут помянута даже «практика», через роль practitioner, но ещё и процесс, и разработка, и инженерия. И тут прямо в определении сужение понимания границ инженерного процесса, ограничиваемое только проектированием и кодированием как аналогом проектирования/design в машиностроении. Помним, что сначала процесс разработки касался только разработки как проектирования, затем разработки до момента получения работоспособного образца целевой системы, затем в инженерный процесс (который продолжали называть «разработкой») начал включать в себя и производство, затем включили эксплуатацию и вывод из эксплуатации, затем только перешли к тому, что всё это, только повторяемое для множества и множества версий системы — поэтому вывод из эксплуатации перестал быть особо актуальным, но ведение всего остального подразумевалось непрерывным. Конечно, в «народной памяти» (памяти инженеров самых разных поколений) живут одновременно все эти воспоминания, которые прорываются в тексты — и мы видим ровно вот такие попытки объять необъятное и плохо совместимое, как в обсуждаемой статье Википедии. Поэтому обращайте внимание на смысл, а не на употребляемые слова — и не ждите, что про методы вам будут писать тексты со строгим контролем типов. Даже если формализацией методов занимаются математики или онтологи, будьте внимательны: оторванная от жизни, незаземлённая логика может не сработать. Что верно в математике и физике, может быть неверно в системном мышлении: в математике у стада может быть хвост, а системное мышление говорит, что так думать нельзя. Этот пример был в «Системном мышлении».

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

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

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

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

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

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

Вот примеры документирования некоторых методов работы (видов инженерии, методов разработки) в сводах знаний:

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)²³³. Тут в главе 10 третьей версии кратко охарактеризован набор из 50 методов (так и называемых «метод»), начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK)²³⁴. То, что называется «метод работы» в нашем руководстве, в PMBoK называют «процесс». Например, группа процессов планирования определяет и уточняет цели, а также планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов и т.д. (всего 47 процессов в 6 версии PMI PMBoK 2017 года). В 2021 году вышла 7 версия PMI PMBoK, которая была существенно переработана.

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)²³⁵. Сами методы тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по разложению какого-то инженерного или менеджерского метода на составляющие.

Можно спорить, описывают ли подобные документы методы, включая возможный инструментарий («гвозди должны быть забиты быстро и ровно, для этого используйте молотки, а не любые попавшиеся под руку камни»), или только «чистые объяснения», «чистую теорию», оставляя какое-то описание возможных инструментов за своими пределами («гвозди должны быть забиты быстро и ровно»). Авторы подобных документов обычно уделяют не столь большое внимание таким вопросам, не различают «научную дисциплину» и «инженерную дисциплину, включающую указания на методы работы с инструментарием». Но нужно помнить, что знания о методе меняются медленно, а инструменты — крайне быстро. Пример нового инструмента — ChatGPT в 2023 году получил 100 миллионов пользователей за первые два месяца. Это пример скорости распространения нового инструментария. Новые инструменты часто приводят к тому, что появляются и новые методы работы, опирающиеся на новые объяснения, новые знания: так, появилось несколько инструментов поиска для интернета, а метод «погуглить» появился только с появлением достаточно продвинутого инструмента интернет-поиска от Google, теперь поиску в интернете учат в некоторых вузах как отдельному методу в составе исследовательского процесса (исследовательский процесс — метод получения знаний, о котором думать надо ровно так же, как об инженерном процессе — методе получения успешных систем).

Алгоритмы поисковой системы Google меняются часто, но дисциплина «гугления» меняется много медленней. Хотя и тут уже происходят драматические изменения, ибо вопросы можно теперь задавать не только Гуглу, но ещё и AI-агентам на базе больших языковых моделей, так что знание/теория правильного вопрошания кардинально изменились и получили название prompt engineering²³⁶. Но и с prompt engineering как новым методом работы с системами AI на основе новой дисциплины уже происходят драматические изменения: оказалось, что AI-системы отлично пишут промпты сами себе, и специальных знаний для задания вопросов большим языковым моделям иметь не нужно, надо просто быть достаточно умным, чтобы сформулировать вопрос и уточнить его — примерно так же, как это было бы в любой беседе с людьми. И этот вопрос может быть и поисковым запросом на получение знаний, с каким раньше обращались к Гуглу.

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

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

За современностью в методах и поддерживающих их инструментах, современностью материалов в предметах метода нужно внимательно следить. Например, понятие критической цепи/critical chain некоторое время назад было контркультурным, свежим словом в дисциплине проектного управления, сам термин мало кто знал. Сегодня это общее место, все уже понимают разницу критического пути/critical path и критической ресурсной цепи в объяснениях/теории метода проектного управления, и обращают внимание на возможности софта поддержки проектного управления по поддержке соответствующих расчётов — чтобы не промахнуться с инструментарием (мы приводили уже этот пример).

Не уделяют авторы сводов знаний внимания и вопросам выбора варианта метода по его сигнатуре, оставляя этот выбор за агентом, готовящимся к выполнению метода в какой-то проектной роли. Например, есть вариант метода проектного управления, описанный в PMI PMBoK, но есть и альтернативный вариант метода проектного управления, описанный в APM BoK²³⁷ — и нужно выбирать, каким из этих двух вариантов метода надо будет работать, поэтому каким из этих сводов знаний воспользоваться для изучения метода проектного управления. Содержание этих сводов знаний абсолютно разное. Это химия или физика в двух учебниках окажется одной и той же, хотя и это не всегда факт для более современных учебников, а проектное управление обычно будет очень разным!

Абсолютно не исключено, что разные группы компетентных в том или ином методе работы экспертов будут рекомендовать использование своего любимого варианта метода, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

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

И даже на этом уровне разбиения могут быть самые разные варианты. Например, если брать такой метод проектирования как ТРИЗ, то за последние двадцать лет ТРИЗ-методы создания концепции системы были дополнены ТРИЗ-методами создания концепции использования. Так что для создания концепции использования можно или использовать методы ТРИЗ²³⁸ (включая инструменты их поддержки: моделеры специфических для этого диаграмм ТРИЗ), или альтернативные методы, например сценарии использования (use cases, включая инструменты: моделеры, поддерживающие специфические языки для моделирования use cases).

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

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

Стандарты классической системной инженерии

Стандарт процессов жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2023²³⁹ Systems and software engineering — System life cycle processes является примером документирования метода не в формате свода знаний, но если приглядеться, то это оказывается очень близким форматом. Он устанавливает наиболее общие описания методов создания (но не развития) систем, созданных людьми в ходе системноинженерных проектов. Название «процессы жизненного цикла» как раз отражает, что он стандарт уже прошлого (второго) поколения системного мышления, соответственно, там инженерия ещё времён опоры на «прохождение полного жизненного цикла, от замысла через рождение до смерти», это было остромодно на момент выхода первой версии стандарта в 2002 году и преодолевало понятие «разработки» как только «подготовки к серийному выпуску, но не само производство, не запуск в эксплуатацию, не эксплуатация, не вывод из эксплуатации».

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

Эти методы/процессы определены для всего времени создания/«жизненного цикла» (развитие может быть, но явно не предусмотрено) и существования созданной системы. В выполнение этих практик вовлекаются все проектные роли (stakeholders: и внутренние, и внешние), с главной целью — удовлетворить клиента.

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

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

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

Жизненный цикл в стандарте понимается в его одном из самых ранних пониманий — это стадии работ проекта (замысел, разработка, производство, использование, поддержка, выбрасывание), привязанные к нахождению системы в каком-то состоянии. Признаётся, что стадии жизненного цикла могут следовать в самом разном порядке, в том числе перекрываться, формируя самые разные варианты соответствий предложенных методов системной инженерии стадиям работ. То, что стадии работ привязаны к нахождению системы в определённом состоянии и параллельность стадий тем самым означает, что система одновременно находится в разных состояниях — это авторов стандарта не очень заботит. Они просто хотят выразить мысль, что методы и работы должны рассматриваться отдельно. И отсылают за концепциями собственно жизненного цикла к другим стандартам по управлению жизненным циклом (ISO/IEC/IEEE 24748-1 и ISO/IEC/IEEE 24748-2), где этот вопрос соотношения управления работами и организации инженерного процесса рассматривается подробней.

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

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

Аналогичный свод знаний в статусе стандарта для заведомо дорогой и заведомо долгой коммерчески невыгодной (то есть требующей госфинансирования) системной инженерии, который существенно объёмней (у него подзаголовок «Энциклопедия», хотя в заголовке «Учебник»), чем ISO 15288, но основан на тех же идеях второго поколения системного подхода и «водопада» — это SEH 4.0 NASA (Systems Engineering Handbook)²⁴⁰. Если вы хотите за государственные деньги с отставанием от всех возможных сроков создать космическую систему прошлого поколения, то вы вполне можете следовать рекомендациям этого свода знаний.

Сегодня в инженерии существует тренд перехода на методологические принципы agile, lean, lightweight methodologies, идеи типа minimal viable product — погуглите все эти понятия, если они плохо вам знакомы. Все эти принципы входят в современный кругозор менеджеров, основателей компаний, инвесторов: нужно выполнять минимум работы (lean переводим как «элегантный», «ничего лишнего»), и главное тут — не тратить ненужных ресурсов на выполнение ненужных работ по ненужным методам. В программной инженерии это уже культура. Аналогичный ISO 15288 стандарт программной инженерии ISO 12207 выглядит уже полным анахронизмом, ибо в программной инженерии новые методологические принципы, соответствующие третьему поколению системного мышления, уже победили. Но во многих других видах инженерии идёт борьба старых инженерных процессов на основе второго поколения системного мышления и понятия «жизненного цикла», а также объёмнейших сводов знаний и новых инженерных процессов, в которых вы не должны выполнять никому не нужную работу и доделывать её обязательно до конца, потому как «так надо», и «так принято», «так прописано в стандарте». Это всё приложение принципа минимального действия в физике к инженерии в целом и к менеджменту (инженерии организации) в частности.

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

Как и для любой другой классификации, для технических методов системной инженерии из стандарта можно предложить и альтернативные варианты. Например, наше руководство по системной инженерии использует более короткий список методов (и соответствующих им ролей), которые имеют отличающиеся названия от технических процессов ISO 15288. Это методы визионерства, разработки (и мы уже говорили, что разработку мы тоже раскладываем на множество составляющих методов), архитектурной деятельности, инженерии производственной платформы. Эти же методы в менеджменте и исполняющие эти методы роли называются по-другому: методы бизнеса, организовывания, орг-архитектуры, администрирования. Так что международный стандарт методов системной инженерии вроде как есть, но он устарел. И немудрено: разработки международных стандартов и голосования стран в ISO тянутся годами, методы инженерной работы и менеджмента успевают измениться раньше, чем международная бюрократия успевает менять стандарты и BoK, которые вроде как документируют лучшие практики. Но нет — это становится документированием лучших практик прошлого поколения, причём явно избыточного количества лучших практик (зато удобно отчитываться перед государственными надзорными органами, а также отчитываться об огромных затратах бюджетных денег). Лучшие на сегодня (а не на вчера) практики, то есть лучшие методы работы, надо искать уже не в стандартах и сводах знаний, и даже не в академических журналах — там опоздание в свежести знания будет на год, что сегодня ведёт к отставанию в конкуренции. Знание сегодня распространяется в препринтах, а самое современное вообще сегодня публикуется в блогах, подкастах, докладах на промышленных и научно-практических конференциях.

Но знать о существовании стандартов и публичных документов (типа BoK) с описаниями методов надо. Ими руководствуется довольно много людей, с которыми вам придётся разговаривать — и незнание их может быть сочтено профессиональной неграмотностью. Поэтому можно показывать их знание, но совсем необязательно им следовать, вам необязательно воплощать в жизнь старые методы работы из этих стандартов, когда можно сразу воплощать в жизнь современные (state-of-the-art, SoTA) методы. Другое дело, что всегда есть риск по незнанию взять за основу своей работы какой-нибудь неработающий метод. Но брать стандарт или публичный документ с заведомо устаревшим и уже известно по каким причинам не работающим методом — это будет ещё хуже. Подробней эти «муки выбора метода в условиях неопределённости» будут разбираться в разделе о теории стратегирования.

Закат тяжеловесных методологий

Мы уже упоминали, что один из стандартов ситуационной инженерии методов (ISO 24744) подчёркивал синонимичность метода/method и методологии/methodology. У термина «методология/methodology» есть в инженерии значения как минимум:

• отдельного метода/практики/«вида инженерии»,

• метода как совокупности частных методов в его разложении (процессов, практик) для достижения каких-то значимых результатов «под ключ», например, «инженерный процесс»/«метод разработки»/«методология разработки» или одного достаточно объёмного метода, например «методология управления проектами»,

• общего метода мышления о методах (предмет нашего руководства)

• учения/теории/дисциплины о методах (описание метода мышления о методах).

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

Популярные полные/исчерпывающие/comprehensive методы/методологии/процессы разработки (development process), т.е. разные варианты agile методов/методологий/процессов (например, DSDM, SCRUM, SAFe и т.д.)²⁴¹, они же «гибкая методология разработки» (но она не одна, их много вариантов!), обеспечения качества (например, six sigma²⁴²), архитектурной работы для предприятия (TOGAF²⁴³, но осторожней: там те же проблемы с архаичностью, что и у ISO 15288, и у NASA SEM) и даже многочисленные варианты старинных по их идеям (но по датам выпуска стандарта — вроде свежих!) методологий системной инженерии, оказываются все согласованными между собой наборами множества детально прописанных разложений методов создания и развития систем или каких-то отдельных свойств систем.

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

Такие «прикладные методологии для сдачи экзаменов» часто содержат в себе три части:

• Общее описание дисциплины/объяснений для многих составляющих методологию методов. Эта дисциплина вводит предметы общего метода, поэтому можно сформулировать сигнатуры составляющих методов и ввести альфы общих предметов для этих составляющих методов. Составляющие методы прикладной методологии потом могут работать с подальфами этих альф. Например, agile-методологии вводят альфу backlog²⁴⁴ как некоторый «список хотелок к реализации». Практики ТРИЗ-методологии используют понятие «идеального конечного результата»²⁴⁵, методологии социальных танцев работают с понятием «коннекшн»²⁴⁶.

• Множество отдельных методов как инструкции «что и как нужно делать» в каждой конкретной ситуации: «если встретил ситуацию X, то делай в ней Y с объектами Z». Их обычно много разных (десятки, если не сотни в одной методологии), они могут вводить свои подальфы, но в целом посвящены переводу альф из одного состояния в другое.

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

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

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

Для методологий разработки Ivar Jacobson (один из ведущих соавторов стандарта описания методов/процессов создания и развития систем OMG Essence) призывает «освободить практики от методологий» (помним, что «метод» и «методология» часто используются как указание на то, что они содержат в себе довольно много мелких методов, называемых в этом случае практиками). По Ivar Jacobson небольшие объяснения/знания отдельных методов являются отличными единицами накопления опыта — его доклад на SECR’17 так и называется: «Kill All Methods — Free the Practices»²⁴⁷. Никакого метода как полного набора практик для достижения результата «под ключ», работаем с отдельными культурно-обусловленными практиками, которые выбираем не из тяжеловесных методов/методологий, а сразу изо всех возможных источников знаний. А если эта практика оказалась слишком большой (её в инженерии часто называют «методом»), то разбираем на составляющие практики и её — но используем в работе всегда только небольшую часть известных нам практик, а не работаем по детально прописанным сотням практик из какой-нибудь тяжеловесной всеохватной методологии.

Переход от тяжеловесных/heavyweight методологий (описываемых документами на сотни страниц и требующих неукоснительного соблюдения сразу всех требований этих сотен страниц) к легковесным/lightweight методологиям (описываемых короткими документами, и упирающих на очень компактный набор принципов, без длинных указаний о том, что и когда делать и без обязательного учёта всех этих принципов в их неразрывной совокупности) отражает современную культуру элегантности, стремление избавиться от ненужной работы в пользу только минимально необходимой.

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

Заявления о том, что «у вас метод SCRUM не работает, потому как вы не выполнили все до одного требования 600-страничного документа, её описывающего» хороши были в 2000 году, сегодня они вызывают улыбку. А что следование немногим принципам отслеживается много жёстче, чем следование заведомо невыполнимым уложениям сотен страниц тяжеловесных методологий, сегодня уже понятно: порядка в следовании легковесным методологиям оказывается в итоге больше, чем порядка в следовании заведомо невыполнимым тяжеловесным методологиям.

Разборка крупных методологий на отдельные небольшие методы происходит даже в танцевальных методологиях/методах/стилях. Повсеместно происходит переход от жёсткого соблюдения в танце одного какого-то стиля (хотя на конкурсах жёстко отслеживается чистота стиля!) к fusion dance²⁴⁸ как сплаву разных танцевальных стилей. Например, в социальных танцах это может быть смесь/mix или сплав/fusion танцевальных стилей танго, кизомбы, форро, сальсы (см. как пример проект системного мультиданса²⁴⁹).

Объединение разных танцевальных стилей требует дополнительного развития тела как инструмента для составного fusion-стиля. чтобы оно могло выполнить движения нескольких стилей. Часто нужно и подстраивать музыку, чтобы в ней были проявлены музыкальные акценты многих ритмов, использующихся в «сплаве» стилей. Если хотите смешать практики из стиля/культуры/методов хип-хопа и стиля/культуры/методов кизомбы, а вами был освоен только один стиль, то придётся доразвить тело и подобрать подходящие музыкальные треки. Но это возможно! Помним, что «стиль», который мы тут обсуждаем — это просто один из синонимов метода. Подход с «тяжеловесными методологиями» (требование строгого соблюдения одного стиля, зато в его полноте) практически исключал такие смешения, мультидисциплинарные (задействующие множество знаний/дисциплин/объяснений многих методов) работы были крайне трудны — и в танцах, и в инженерии, и в менеджменте. Это презрительно называлось «эклектика». Но нет, оказалось, что тщательный подбор методов из разных их разложений в новый составной метод — это секрет к получению новых стилей/культур/методов, это и есть проявление эволюции, путь к развитию.

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

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

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

Сами методологии необязательно ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) классических инженерных (главным образом software engineering) и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик создания целевой системы, но только инженерии и эксплуатации команды разработчиков, то есть менеджерские²⁵⁰.

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

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

Моделирование: методология разработки

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

Онтологические нюансы в основе рациональности при стратегировании

Ключевое понятие методологии — это метод работы. Синонимический ряд на русском языке для метода можно продолжать и продолжать. На английском тоже много аналогичных понятий: activity/action/practice/labor/engineering/method/methodology/culture/style/strategy/way of working, и тоже этот ряд можно продолжать и продолжать. Определения тут мало помогают, они выхватывают обычно только какой-то один аспект метода как объекта внимания и мало пригодны к заземлению/grounding²⁵¹, обнаружению метода в рабочем проекте, в жизни, в физическом мире.

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

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

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

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

• Привязка к физическому миру должна быть на уровне индивидов, но обсуждение обычно ведётся в типах/классах индивидов.

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

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

Методы нужны, чтобы уметь их выбирать, то есть проводить стратегирование — постоянный выбор (continuous everything!) изо всего множества возможных методов того, который оптимально ведёт к успешному изменению предметов какой-то работы (стратегия), затем планирование работ по нему, работа, затем коррекция стратегии.

Работа — это всегда действие в реальном мире, использование конкретных ресурсов, это уже не говорильня и размышления, это переход к действиям, к изменениям индивидов. Чтобы получить ожидаемый полезный (а не неожиданный бесполезный) результат работ, надо проводить эту работу по тщательно выбранному методу, который обычно называется стратегией, а саму работу вести по плану**.**

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

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

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

• Затем принимаете решение о том, какая же у вас стратегия: выбираете изо всех вариантов стратегии наименее плохой (потому что «лучший» вряд ли присутствует в тех вариантах методов, приемлемые объяснения которых удалось собрать на первом шаге). Тут вам нужно задействовать методы, которые описываются теориями принятия решений.

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

• Дальше надо выполнять работу по плану! Это очень, очень трудно. Вы приняли решение, составили план — но это вовсе не значит, что вы начали что-то делать! Надо ещё «проявить политическую волю», как сегодня принято говорить. Преодолеть лень, перейти от «умственной работы» к реальной работе (она вполне может быть умственной, но это таки работа — её делают, а не только думают о ней!). Это ключевое, что отличает «аналитиков» от инженеров, которые меняют жизнь. От разговоров и размышлений надо перейти к делу!

• И ещё надо обеспечить надзор: 1. отслеживание результатов выполнения метода (проверка того, что делаются все важные операции и достигаются все предписанные методом состояния предметов метода) и 2. отслеживание выполнения плана работ (наличие всех ресурсов, старты и окончания работ совпадают с запланированными, об окончании работ извещается исполнитель следующих работ по supply chain, и так далее).

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

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

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

Методолог учится смотреть на мир прежде всего как на изменения состояний каких-то объектов мира, вызываемые агентами/IPU — видеть во всём методы этих изменений объектов мира как предметов методов. Для этого он задействует все остальные методы фундаментального мышления интеллект-стека. Возможно, будет полезно не изучать подробно, но хотя бы «по диагонали» просмотреть руководство по интеллект-стеку фундаментальных методов мышления, в котором много говорится о том, как формализовать мышление, в том числе формализовать мышление о методах работы.

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

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

• «работник», «работа», «предмет работы»,

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

Работник и мастер — это две роли какого-то создателя, причём с учётом всех его инструментов (можно говорить по аналогии с «расширенным предприятием»/«extended enterprise», куда включаем множество предприятий, занимавшихся созданием и развитием какой-то системы на основе каких-то контрактов, о «расширенном создателе», extended constructor, куда будем включать и инструменты, и даже множество каких-то автономных создателей, организацию (команду или коллектив как команду команд) создателей, или даже ровно то самое «расширенное предприятие» из множества самых разных предприятий/создателей. Работник, ведущий работы по методу и мастер, задействующий метод работы — это один и тот же создатель, описываемый в двух его ипостасях/ролях, работающих по методу «работа» и «метод» соответственно. Тут опять онтологические нюансы, но не будем особо в них углубляться, разве что заметим, что на работу вполне можно смотреть как на метод, которым кто-то::работник работает::метод — работа как метод задействования ресурсов для получения необходимых состояний предметов работы, и у этого метода есть свои предметы метода, свои объяснения/правила/знания и даже свой инструментарий, прежде всего инструментарий планирования и отслеживания выполнения планов (в руководстве по рациональной работе вы уже касались «работы» как метода). Но не рекомендуем настаивать на том, что «работа и метод это одно и то же, потому что я могу посмотреть на работу как на метод, это у вас же в руководстве говорится». Потому мы и говорим, что тут много онтологических и семантических нюансов (онтология, семантика — это всё отсылки к интеллект-стеку), с которыми вы постепенно разберётесь.

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

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

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

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

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

Как узнать, что работа двигается? Конечно, отслеживать состояние рабочих продуктов (например, чеклистов с отметками о выполнении каких-то операций работы), по рабочим продуктам мы можем свидетельствовать/evidence состояние предметов метода.

Так что вы:

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

• Находите/выявляете (предпринимаете усилия, чтобы найти! Сами они не бросятся вам в глаза!) для этих типов рабочие продукты (материальные объекты: документы для моделей::описаний как предметов метода, конструктивные объекты для систем, в том числе создателей), чтобы по этим рабочим продуктам оценить состояние альфы.

• Оцениваете состояние альфы.

• Стратегируете, каким методом можно продвинуть состояние альфы в текущей ситуации, понимая, что двигать придётся чаще всего множество подальф.

• Планируете ресурсы для выполнения работ по методу.

• Задействуете ресурсы: проводите работы по выбранному методу (реализуете стратегию).

• Убеждаетесь, что результаты работ используются (если не используются, то всё это можно было бы не затевать).

Это обманчиво короткий список:

• Типов мета-мета-модели в наших руководствах множество, они связаны друг с другом, имеют множество нюансов в их использовании, они крайне абстрактны, гипотеза о том, что именно для вас сейчас будет самое важное — это ведь только гипотеза. Формальных алгоритмов тут нет, поможет знание руководств, кругозор и интуиция.

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

• Оценивать состояние альфы у вас сразу тоже не получится, ибо обычно приходится оценивать состояние множества альф. Скажем, стартовали ли работы, если речь идёт о сотне работников? Вот эти пятеро уже работают, эти шестеро ещё и не знают, что им надо будет работать, но мы уже решили, что надо, а вот эти восьмеро — мы ещё сами не знаем, будем ли мы их задействовать, обо всех остальных мы ещё просто не знаем. Так стартовали ли работы? Пятеро-то уже работают, а 95 — ещё нет, и многие даже не знают, что им надо «впахать»! Это типичная ситуация при оценке альф.

• Стратегирование — тут только одно слово, но посмотрите на разложение метода стратегирования в текущем подразделе! У стратегирования довольно много шагов.

Безмасштабность методологии

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

Конечно, в простейших случаях вам будет достаточно «опыта», ибо вы много раз встречались с какой-то ситуацией, у вас есть в мозгу определённое интуитивное представление о том, что надо делать. Но нейросети могут галлюцинировать — поэтому это интуитивное представление надо бы считать лишь гипотезой, и эту гипотезу считать лишь одной из гипотез, полученных в ходе непрерывного стратегирования. И это уже логическое рассмотрение, требует больших затрат «мыслетоплива», высокой собранности, в инженерных проектах эта собранность будет ключевым условием успеха. Если ни вы, ни ваши коллеги не дают себе отчёта, какие методы работы они выбрали для работы, какие предметы метода к каким состояниям с какой вероятностью этот метод в какие сроки может привести (то есть не дают себе отчёта, какова их стратегия), то проект, конечно, может закончиться большим успехом — но это будет более-менее случайно, после множества переделок/re-works, абсолютно неэлегантно, не lean, совершенно не на основе принципа минимальных усилий.

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

И вы ещё и гуглите в ходе стратегирования (ну, или спрашиваете AI-помощника, или опытного коллегу-методолога), чтобы увеличить количество гипотез о методах, которые вы оцениваете при выборе метода в ходе стратегирования.

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

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

Даже просто «наблюдение» за происходящим, то есть отслеживание изменений в предметах метода в ходе работ с предметами работ оказывается абсолютно проактивным «измерением», в котором тесно переплетены чисто вычислительные/мыслительные (обработка информации) шаги с моделями мира и себя-агента, и вполне телесные (да ещё и с экзотелом/инструментом, если речь идёт о людях, но это может быть и робот, у которого сплошное экзотело/инструмент) шаги по изменению/трансформации физического мира. IPU (information processing units) оказываются вполне деятельными, агенты оказываются вполне вычислительными, это одно и то же, алгоритмика оказывается обобщённой для вычислителей из computer science и для создателей/constructors из теории создателей (constructor theory). И это рассуждение безмасштабно!

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

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

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

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

Так что мышление будет признаваться рациональным, возможно по длинной цепочке рассуждений и с запоминанием промежуточных результатов на несколько лет, если понятно причинно-следственно, что оно ведёт к росту успешности имеющихся на сегодня систем физического мира. Да ещё эти проекты создания успешных систем на базе сильного/универсального и SoTA прикладного мышления по стратегированию с последующими работами по реализации стратегий тесно и многоуровнево переплетены. Исследовательские (добыча новых объяснений) вопросы к миру и результаты работы по изменениям систем реального мира появляются в ходе проекта не так, чтобы «сначала исследовали, затем разработали, то есть R&D, потом сделали, потом пользуемся» (водопад), а вперемешку, параллельно и рекурсивно на разных системных уровнях.

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

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

Кроме метода с его описанием нам важно подчеркнуть материальность создателя, который задействует метод, а также наличие у создателя мастерства (вычислитель/контроллер, ведущий вычисление по алгоритму/объяснениям/знаниям/дисциплине метода) и инструментария метода.

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

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

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

Методология по мере перехода от систем с индивидуальными агентами к мультиагентным системам организаций (понятные полномочия по распоряжению работниками, инструментарием, предметами работ) как дисциплина/объяснения становится менее внятной — ибо методы с участием многих создателей моделировать крайне трудно, в частности, моделировать инженерные процессы. Когда говорят о гибких методах разработки, то чаще всего имеют в виду масштабы одной команды из 5-12 человек. Если речь идёт о scaled agile, то есть «масштабированной гибкости» — работе множества команд разработчиков над одной системой, тем более команд в разных предприятиях (extended enterprise), методология даёт только основные методы рассуждений, но готовых «рецептов», готовых методов, готовых теорий для таких сложных объектов — нет.

Метанойя, которую должен получить методолог::роль — это смотреть на действующих в мире агентов (IPU/constructor: существ, людей, организации и т.д.) и как-то выделять тот метод, работу по которому выполняет агент, его степень мастерства в этом методе, насколько SoTA этот метод (насколько SoTA дисциплина/теория/объяснения, насколько SoTA инструментарий, насколько SoTA предметы метода), насколько силён интеллект агента (то есть что будет происходить, когда при выполнении практики «что-то пойдёт не так», а не так всегда будет что-то идти). Методы — это не физические объекты, о них трудно мыслить. В последнее время появляются новые способы это делать, тут можно указать на конструктивистское понимание построение целого из частей как операций конструирования (а не как структур по отношениям «часть-целое»), предложенное Kit Fine²⁵⁴.

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

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

Методологическое мышление тем самым безмасштабно по отношению к системным уровням как предметов метода, так и создателей, выполняющих метод.

Метод как объект первого класса

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

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

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

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

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

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

Без знаний/теорий/объяснений/алгоритмов метода (полученных или самостоятельно исследованиями, или полученных из текстов, или полученных из устного обучения и демонстраций, или полученных неявно из «насмотренности») мастерства выполнения работ по методу не будет. При этом знания могут быть явными или неявными, причём неявные нельзя будет обсудить, откорректировать ошибки в выполнении метода, сравнить эти знания со знаниями других вариантов метода. Методология требует явного моделирования знаний/теорий/алгоритмов/объяснений/дисциплин.

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

Личность — это «софт» агента, алгоритмы методов, реализованные его «хардвером» (организмом у человека, аппаратурой механики, датчиков и вычислителей у робота). Обучение методу (явное, или неявное, или познание метода в ходе исследований, или подсматривание за другими агентами, как они работают и распознавание паттернов их работы) важно, без обучения метод не может быть задействован. Мы рассматривали рациональность как шаги выбора метода — но при этом явно не говорили об обучении, предполагалось, что на стадии добычи ресурсов (в том числе добычи создателя как ресурса) для выполнения работы это мастерство будет получено. Но если мастерства не найдено, его можно получить — надо просто научить агента! Чтобы получить из сотрудников работников (из нанятых людей или даже роботов тех, кто реально работает), их сначала надо научить. Легко представить себе ситуацию, когда сотрудники наняты, а работать не могут — потому как не умеют работать по методам инженерного процесса, принятого на предприятии.

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

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

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

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

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

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

• Осознать метод, понимать, что любая работа делается не «просто так», а следует какому-то содержательному паттерну, происходит каким-то способом, и у этого способа наверняка есть варианты — это и есть метод. Это ключевой момент! Этот метод/способ работы должен как-то попасть во внимание, стать предметом рассуждения, иметь собственное имя!

• Назвать метод, назвать роль работника по этому методу. Тут важно иметь кругозор, «начитанность», «насмотренность». Название лучше бы не сочинить, а взять из культуры.

• Задаться вопросом о знаниях/теории/дисциплине метода (и её SoTA) и инструментарии (и его SoTA), а также о «начальных предметах метода»/сырье (и их SoTA). Гуглить, спрашивать коллег, спрашивать AI-помощников, лезть в учебники, смотреть на разнообразие вариантов метода! Сделать рациональную оценку вариантов метода и принять решение, что с текущим методом делать (менять на другой, оставить «как есть», поменять не метод, а исполнителя работы по методу на другого агента или поменять инструментарий, и так далее). Это шаг рабочего мышления: разговаривайте, гуглите, читайте книги, размышляйте, ходите на экскурсии, и ещё проводите эксперименты!

Как выявить метод, когда он неочевиден? Вот ряд вариантов:

• Вы можете «зацепиться» за самые разные моменты: обратить внимание на незнакомые слова и термины — и поинтересоваться, из какой они предметной области, области знаний, дисциплины, теории. По дисциплине затем восстановить весь метод.

• «Зацепиться» в ситуации за то, что используется специфический рабочий продукт или инструмент — и поинтересоваться, какую дисциплину он поддерживает, какие для его использования приводятся объяснения, где учат таким пользоваться. И опять же, восстановить метод по его знаниям/теории.

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

Главным приёмом появления метода как объекта вашего внимания будет задаться вопросом: откуда исполнитель проектной роли (человек, команда, коллектив, предприятие, AI-агент) знает, как ему выполнять свою работу. Вот какой-то работник занят какой-то работой:

• Он сам придумал, как именно эту работу нужно делать? Или подглядел у других работников? Он читал учебник, проходил курсы, следовал какому-то регламенту, инструкции или стандарту, и когда это было?

• А что сейчас говорят на эту тему в университетах, что пишут в блогах ведущие мастера этого метода? Что тут SoTA?

• Можем ли мы представить, что мы должны получить такие же результаты его работы, но быстрее и дешевле, поменяв способ работы? Как бы мы начали искать этот новый способ работы?

• Можем ли мы использовать тот же метод работы, но задействовать инструментарий получше, а также получить повыше степень мастерства для выполнения этого метода, взять покачественней предметы метода?

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

Главным тут будет переход от обсуждения собственно работы (быстро, медленно, какие ресурсы) к способу/методу/культуре/стилю выполнения работы и далее к альтернативным вариантам в способах выполнения работы.

Вариативность культур

Давайте рассмотрим «приготовление кофе»::культура/«рабочий процесс»/метод. «Кофе готовит»::метод бариста::роль. Мастерство бариста приобретают в школах бариста, где студентов учат знаниям/объяснениям/теории приготовления кофе и тренируют в использовании инструментария.

Есть множество учебных материалов, раскрывающих знания/дисциплину/теорию/алгоритмы приготовления кофе в разных вариантах метода приготовления кофе, например, приготовления кофе с молоком²⁵⁶::«вариант метода». В объяснениях/теории приготовления кофе с молоком уделяется внимание вопросу отделения действий, относящихся к особенностям подачи (например, лить кофе в молоко или молоко в кофе) от основы дисциплины: задание вкуса кофе. По факту большинство действий относятся к особенностям подачи в разных странах, разных барах, но сам вкус кофе с молоком зависит только от соотношения кофе и молока.

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

1. Отмер и трамбовка кофе

2. Пролив

3. Опциональное приготовление молока и пены

   1. Отмер молока и пены

   2. Капучинирование

      1. Обеспечение пара

      2. Контроль температуры

      3. Контроль объёма пены

      4. Очистка насадки панарелло после капучинирования

      5. ???Простукивание

   3. ???Простукивание

4. Латте-арт

   1. ???Простукивание

   2. …

5. Подача

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

• Поверхность молока (состояние по итогам простукивания: без «холмов» пены)

• Крупные пузыри (состояние по итогам простукивания: отсутствуют)

Простукивание у нас условно (с вопросительными знаками и курсивом) показано трижды:

• Предположительно, как последняя операция капучинирования

• Предположительно, как последняя операция приготовления молока и пены

• Предположительно, как первая операция латте-арта

Как правильно? Предписанного ответа на этот вопрос нет. Ответ существенно зависит от вашего проекта, от особенностей «вашего варианта метода»/«принятой у вас культуры» приготовления кофе.

Итак, вы познакомились с культурой/методом приготовления кофе с молоком. Какие вы можете предложить варианты метода? Например, вы можете менять варианты отдельных составляющих методов/практик в разложении этой культуры, например, для приготовления кофе дома:

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

• Капучинирование можно делать дома индуктивным капучинатором, то есть не нужно пара. Это чуть дольше, но существенно проще, не нужно очищать насадку панарелло (её попросту нет).

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

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

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

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

Каждая прикладная культура работы имеет носителей этой культуры — агентов-мастеров, которых в совокупности называют «профессиональным сообществом», community of practice. Эти сообщества имеют свои своды знаний (в том числе в форме учебников и курсов, руководств и даже в случае религиозных сообществ «святых книг») по рациональным или не очень рациональным объяснениям методов, свои вузы (магистерские программы в вузе, если точнее, ибо бакалавриаты посвящены больше не прикладным объяснительным теориям, а фундаментальным), свои конференции, свои выставки, свои СМИ, форумы и чаты, у них есть свои знаменитости/celebrities как образцы для подражания.

Несмотря на одно и то же название для сигнатуры, варианты методов могут существенно различаться по их объяснительным теориям, инструментам и даже предметам метода. Разные организации часто присваивают себе право говорить от имени какого-то профессионального сообщества, но нужно быть крайне осторожными, чтобы им верить. Так, «системная инженерия» главным образом киберфизических систем как практика развивается самыми разными сообществами системных инженеров:

• IEEE Systems Council²⁵⁷, который выпускает стандарты и публичные документы по системной инженерии, а также проводит в том числе IEEE International Systems Conference и издаёт IEEE Systems Journal по вопросам системной инженерии

• INCOSE²⁵⁸, International Council of systems Engineering, который тоже выпускает своды знаний и стандарты, а также проводит международные конференции по системной инженерии и издаёт журнал Systems Engineering.

• Сообществами системных инженеров в крупных организациях, например, мы уже приводили пример свода знаний по инженерному процессу системной инженерии, разработанного сообществом системных инженеров NASA²⁵⁹, можно привести аналогичный учебник, разработанный сообществом системных инженеров MITRE²⁶⁰.

В области классического проектного управления, как варианта управления работами, конкуренция организаций, которые представляют себя как сообщества «профессиональных управляющих проектами», ещё жёстче. В классическом проектном управлении есть множество абсолютно разных вариантов методов, мастерство в работе по этим методам сертифицируется, содержание знаний метода для сертификации во всех таких организациях — разное. Вот сравнение нескольких таких организаций, поддерживающих разные версии практики проектного управления²⁶¹:

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

TEST Онтология метода

С какими утверждениями можно согласиться?

+++ Вид труда — это метод работы исполнителей какой-то профессиональной роли. ### Да, «вид труда»/«метод работы» — это поведение проектной/деятельностной/орг роли. Инженерный труд (инженерия как метод работы) — это то, что делают инженеры, менеджмент — это то, что делают менеджеры.

--- Метод — это использование инструментов в оргзвеньях ### Дважды нет: 1. Метод — это функция не оргзвеньев (конструктив организации), а оргролей (функциональный объект организации). 2. Использование инструментов не главное, главное — следование знаниям/объяснениям/дисциплине/алгоритмам метода.

+++ Технологии — это практики работы. Скажем, технология получения сверхчистых полупроводников — это просто синоним для практики получения сверхчистых полупроводников. ### Да, и технологии, и практики — это синонимы метода работы.

--- Практика — это какая-то инженерная или менеджерская дисциплина. Практика операционного менеджмента, например — это дисциплина операционного менеджмента. ### Нет, практика/метод как поведение описываются дисциплиной/объяснениями, описание поведения/изменений и само поведение/изменения — это разные объекты.

+++ Метод можно выполнять ### Да, оргроли выполняют методы/функции в ходе работы.

Выберите примеры разложения метода:

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

+++ приготовление борща делится на подготовку овощей, подготовку мяса, варку. Подготовка овощей состоит из их очистки, нарезки, пассировки. ### Да, это разложение метода в одном из простейших случаев, на шаги императивно/процедурно описанного алгоритма.

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

+++ плавание включает в себя дыхание, движения руками, движение ногами ### Да, это пример разложения метода плавания: одновременно происходит работа по методам дыхания, движения руками, движения ногами в общем методе плавания.

Моделирование: методы вашей работы

Рассмотрите три и более работы, которые вы выполняли на своей работе последний месяц и тратили на них больше двух часов в день. Какие методы работы вы использовали, где эти методы описаны, как вы о них узнали? Как называется роль, в которой вы выполняли работу по этим методам? Укажите также один из многих отброшенных вами в ходе стратегирования альтернативных вариантов метода работы.

Вспомните три последних ваших разговора с коллегами по работе и заполните табличку (степень мастерства оценивайте по десятибалльной шкале, 0 — «абсолютно не владеет методом работы, ничего не умеет, допускает абсолютно все новичковые ошибки», 10 — «владеет методом работы лучше всех в мире, умеет делать этим методом работы с неизменно превосходным результатом»):

Приведите основные профессиональные сообщества, в которых вы формально участвовали:

Задание

Поставьте отметки о выполнении:

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

Эволюция методов

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

• время создания оргвозможности (время создания мастерства практики в создателе, «вызревание мастера»), это обычно довольно быстро.

• время одного исполнения работы по методу,

• время существования оргвозможности, где метод задействуется многократно,

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

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

Всё, что мы знаем про эволюцию, в эволюции практик тоже будет соблюдаться:

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

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

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

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

• Учитываем, что разложение метода часто работает рекурсивно на многих системных уровнях, так что важна многоуровневая оптимизация (выбираются решения по методам, которые помогают снять конфликты между разными системными уровнями. Так, если брать практику управления/control как быстрого и точного достижения какого-то заданного состояния системы, то «централизованные одномасштабные системы управления» позволят достигать состояния быстро и неточно, децентрализованные — очень точно, но не очень быстро. Нужно иметь многоуровневую систему управления со множеством обратных связей, задействовать разные методы на разных масштабах, именно это диктует нам современная дисциплина синтеза систем управления²⁶⁴. Если нет учёта многоуровневости — нельзя говорить о том, что вы как-то системно стратегируете, выбирая метод. Ваша оптимизация будет одноуровневой, она не будет снимать межуровневые конфликты).

• Вся эта оптимизация метода временная, речь идёт о динамическом ландшафте приспособленности: эволюция не останавливается и не заключается в бесконечном приближении к какому-то неподвижному оптимуму. Нет, оптимум сам непрерывно движется, что было оптимально вчера — уже неоптимально сегодня, а что оптимально сегодня утром — будет неоптимально уже сегодня вечером!

Иногда говорят о модах и поветриях в методах работы. Мода — это когда новый метод работы (и его теория) уже появился, и мастерство выполнения этого метода становится популярным, знание/теория быстро распространяется по агентам, метод становится «культурой», и так и остаётся популярным.

Это прямая ассоциация с индустрией моды. Скажем, некоторое время назад (первая половина 1960-х) появилась практика носить мини-юбки, и так и осталась до настоящего времени. В 60х это и была «мода». А вот в 1920 годах женщины рисовали брови, ниспадающие наружу-вниз — это быстро прошло и уже забылось²⁶⁵, это можно считать «поветрием», неудачной мутацией.

Все эти культуры/стили (синонимы метода!), более и менее удачные, тоже подчиняются законам эволюции, только не дарвиновской, а техно-эволюции. Они тесно связанной с меметикой и особенностями памяти мемов (как и биологическая эволюция связана с генетикой и особенностями памяти генов).

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

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

Термин Web 2.0 пришёл и ушёл из обращения, но его технологии/методы остались, это было не поветрие, это была острая мода — и термин для этой группы методов появился как раз для того, чтобы отслеживать эту «острую моду». Социальные сети (user generated content) и рекомендательные системы, в которых собирают оценки, которые дали читатели-слушатели-зрители, до сих пор с нами, они никуда не ушли, их и называли технологиями Web 2.0. Web 1.0 был про «порталы» как «точки входа в сеть», порталы вполне остались (скажем, поисковая страница Гугла), но в Web 2.0 упор делался на разные варианты социальных сетей.

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

А вот с Web 3.0 другая история. Этот термин появился для обозначения технологий семантических сетей (semantic networks)²⁶⁷ в конце нулевых годов 21 века. Термин отражал прогноз для «большого нового тренда интернет-технологий», потом термин подзабылся, ибо семантические сети «не взлетели», они остались довольно маргинальной технологией с не очень большим распространением.

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

Искусственный интеллект вышел из острой моды конца 80х годов прошлого века (так называемая «зима искусственного интеллекта»), но после появления ускорителей вычислений интерес к нему возобновился после появления успешных искусственных нейронных сетей в 2012 году, и продолжает расти, особенно с выходом ChatGPT в марте 2023 года.

Конечно, все эти новации были не такими сильными потрясениями, как приход социальных сетей после порталов, то есть появление технологий Web 2.0. Web 2.0 оказался очень сильным потрясением для всего человечества: каждый человек получил методы работы, дающие возможность стать писателем, журналистом, телестанцией, радиостанцией без организаций-посредников. Это был цивилизационный сдвиг, это широко обсуждалось. После появления ChatGPT ситуация меняется, искусственный интеллект очень активно обсуждается, просто терминология ушла от «поколений», моды и поветрия перестали быть хорошо наблюдаемыми.

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

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

Видно, что метод total cost management появилась раньше, чем total quality management, смысл тотальности тут в том, что управлением ценой должны были заниматься все сотрудники предприятия прямо на своих рабочих местах, речь шла о «трансдисциплинарности» знаний метода. Эта идея/мем росла в популярности десяток лет, а потом немного упала в популярности, но в целом осталась. Это была мода. А ещё эта идея/мем мутировала и стала идеей, что так же тотально нужно управлять качеством: каждый должен заняться качеством на своём рабочем месте. И вот эта «вторичная мода» оказалась мощней тотального управления стоимостью, если сравнить графики в одном масштабе (на картинке это первый график), то на фоне графика роста популярности и последующего падения острой модности (но из жизни эта идея никуда не делась!) тотального управления качеством рост популярности раньше появившейся идеи тотального управления стоимостью практически оказывается не виден, нужно приводить график другого масштаба, чтобы разглядеть его форму.

Интернет привёл к тому, что идеи/мемы знаний/объяснений/теорий/дисциплин/алгоритмов новых методов и их мутаций для уже популярных методов распространяются исключительно быстро. Развитие промышленности и компьютерного инструментария дают возможность быстрого размножения реализаций этих мемов в физическом мире (как геном реализуется в клетках и организмах, так и мемом реализуется в мастерстве агентов: людей, систем AI, организаций, новые эффективные методы быстро становятся культурой в сообществах, обществах и даже человечестве, формируют фенотип. И если лет двадцать назад в доинтернетную эпоху мы видели «эволюционный срок» появления нового метода и угасания либо моды на этот метод (но сам метод остаётся! Мода приходит и уходит, но её объект остаётся), либо поветрия (метод вымирает, оказывается эволюционно неудачным) лет так в двадцать, сегодня это явно не больше пяти-шести лет, завтра это будет пару лет года (или уже сегодня такое можно видеть?), а в ближайшем будущем можно ожидать технологической сингулярности²⁶⁹, одно из определений которой гласит, что это такие времена, когда технологии (синоним метода!), становящиеся культурой (то есть методы, мастерство в которых получает широкое распространение) обновляются так быстро, что ни один человек не может сориентироваться в происходящем, настолько быстро меняется мир — и поэтому смотреть надо на системы искусственного интеллекта, которые будут приобретать агентность (автономность в работе), успевать отслеживать ситуацию и тем самым получат преимущество перед людьми.

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

Вот, например, результаты²⁷⁰ постановки новых практик менеджмента в компании BHP Billiton за полтора года, и это было ещё десяток лет назад:

BHP Billiton сумела уменьшить за счёт освоения методов элегантного управления (lean management — вариант операционного управления, в котором минимизируется количество лишней работы) стоимость бурения и заканчивания скважин²⁷¹ за 18 месяцев на 50% в бассейне Permian и на 49% в бассейне Eagle Ford. Аналогичные результаты показали и другие нефтегазовые компании, которые применяли lean management. Сам метод минимизирования лишней работы lean появился под этим названием в 1988 году²⁷², и он «пришёл, чтобы остаться», мутируя в lean manufacturing, lean construction, lean project management и далее приобретая форму, пригодную уже не просто для промышленного производства, но и для разработки (это будет подробно изложено в руководстве по системному менеджменту).

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

Например, вот организационные моды и поветрия, которые были собраны Томасом Давенпортом и Ларри Прусаком в 2003 году²⁷³, сколько из этих методов вам знакомы? Много этих методов стали культурой (то есть мастерство в них широко распространилось), а затем уже вымерло с тех пор, оказалось поветрием — но до сих пор имена этих методов встречаются в литературе. Динозавры-то вымерли, но название «динозавр» встречается много чаще, чем слово для каких-то вполне живущих сегодня видов! Более того, дети сегодня могут различать разные виды динозавров, но могут не различать ныне живущие виды зверей: это особенности бытования культур. С методами работы происходит всё то же самое, что со знаниями про динозавров и людей, будьте внимательны. Вот этот список того, что было модно более двадцати лет назад:

• Activity-based costing

• Activity value analysis

• Adaptive enterprises

• Artificial intelligence

• Attention management

• Balanced scorecard

• Benchmarking

• Brainstorming

• Brand management

• Business modeling

• Cannibalization

• Centralization/decentralization

• Change management

• Chaos/complexity

• Competitive intelligence

• Complex adaptive systems

• Concurrent engineering

• Conglomeration

• Continuous improvement

• Co-opetition

• Core capabilities

• Core competence

• Corporate culture

• Cost-benefit analysis

• Creative destruction

• Crisis management

• Critical-path analysis

• Cross-selling

• Customer relationship management

• Customer satisfaction

• De-layering

• Decision trees

• Diversification

• Double-loop learning

• Downsizing

• e-Commerce

• e-Marketplaces

• Economic value analysis (EVA)

• Economies of scale/scope

• Electronic data interchange (EDI)

• Empowerment

• Enterprise systems

• Entrepreneurship

• Evolutionary modelling

• Excellence

• Experience curves

• Experience economy

• Five forces analysis

• Flat organizations

• Franchising

• Game theory

• Globalization

• Growth/share matrix

• Hawthorne effect

• Hierarchy of needs

• Horizontal organization

• Information ecology

• Information management

• Intellectual capitalism

• Intellectual property management

• Interorganizational systems

• Intrapreneurship

• Just-in-time delivery

• Keiretsu

• Knowledge management

• Lead user analysis

• Leadership

• Lean production

• Learning organizations

• Lifetime customer value

• Loyalty management

• Management by objectives

• Management by walking around

• Managerial grid

• Marketing myopia

• Mass customization

• Mass production

• Matrix management

• Mentoring

• Mission statements

• One-minute managing

• Open-book management

• Operations research

• Organizational ecology

• Outsourcing

• Paradigms

• Pay-for-performance

• Permission marketing

• Portfolio analysis

• Portfolio management

• Process improvement

• Product life cycles

• Profit pools

• Prototyping

• Quality circles

• Quality of work life

• Real options

• Reengineering

• Resource-based strategy

• Restructuring

• S-curves

• Satisficing

• Scenario planning

• Scientific management

• Scientific retailing

• Segmentation

• Services

• Seven S model

• Simulation

• Six Sigma

• Social capital

• Sociotechnical systems

• Spans of control

• Strategic alignment

• Strategic business units

• Strategic planning

• Strenghts, weaknesses, opportunities, threats (SWOT) analysis

• Succession planning

• Supply chain management

• Synergy

• Systems dynamics

• T groups

• Teams

• Technology transfer

• Theories X and Y

• Theory Z

• Time-based competition

• Total quality management (TQM)

• Unbundling

• Value chain

• Value disciplines

• Value migration

• Value proposition

• Vertical/horizontal integration

• Virtual organizations

• Vision

• War for talent

• Wellness

• Yield management

• Zero-based budgeting

Это только то, что показалось авторам списка достаточно известным и популярным в 2003 году.

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

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

Системные уровни целевой системы и стратегирование

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

• Того, на котором ведётся работа с системой. Например, работы менеджмента ведутся с системным уровнем организации как системы из множества организованных индивидуальных агентов (людей, систем AI).

• Уровня ниже. Если целевой уровень — это организация и методы менеджмента, то уровнем ниже будет уровень индивидуального агента и там методы различных вариантов инженерии личности, в том числе разные варианты методов коучинга, психотерапии, обучения на рабочем месте.

• Уровня выше. Если целевой уровень — организация, то уровнем выше будут какие-то бизнес-эко-системы, в которые входит организация. Там будут, например, методы организации торговли (организации рынка).

Грубо говоря, если ты строишь стену, то тебе хорошо бы разбираться в:

• стенах и их свойствах, методах работы со стенами (твой уровень),

• кирпичах и что с ними можно делать, растворе (уровень ниже твоего, но тут можно подумать и о других методах строительства стен, например, методе скользящей опалубки — и кирпичей там уже не будет, равно как не будет кирпичей при крупнопанельном строительстве, и в этом надо тоже разбираться),

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

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

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

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

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

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

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

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

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

• многоуровневую программу совершенствования агента как повышения эффективности выполнения каких-то методов из текущего их набора (например, стека — но помним материал первого раздела нашего руководства: вариантов представления разложения методов множество!)

• многоуровневую программу развития агента как замену методов работы на более эффективные.

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

1. Работа с телом (уровни общего движения, усилий в масштабах тела, усилий и амплитуды в частях тела). Обеспечить себе прямую постуру (позу и мышечные усилия) и мягкую спину за счёт работы по обмяканию в области груди и поясницы. Цель ближайших трёх месяцев: приводить себя в рабочую постуру в течение не полуминуты, как сейчас, а полусекунды (танцевальное время, а не йога!), удерживать прямую постуру в вертикальной скрутке, а также делать это в ходе перформансов (не терять собранности), а не в спокойных упражнениях перед зеркалом. [это всё общетанцевальное] Увеличить угол выноса руки назад. [потребуется для поворотов партнёрши за спиной, растяжки мышц груди и рук при этом не хватает]

2. Общетанцевальный уровень. Добиться управления атаками (скорость нарастания силы в импульсе) в ведении, разобраться с инерционным ведением. [обратите внимание, что появился метод этого уровня — «ведение» — но вот дальше разговор идёт явно в терминах методов более низкого системного уровня. Чтобы поправить исполнение вышестоящего метода, нужно чаще всего работать с методами уровня ниже: «чтобы починить стену, нужно работать на уровне кирпичей и раствора». При этом даже не поминаются понятия вышестоящего уровня, то есть названия танцевальных стилей.] И поднять, наконец, голову от пола! [это, конечно, отсылка к собранности, но в данном случае речь идёт об общетанцевальном: нехорошо танцевать с опущенной головой, «смотреть в пол», это общее для всех стилей социального танца. Собранность нужна для того, чтобы это исправить — не смотреть в пол легко, особого мастерства для этого не надо, но надо просто не забывать, поставить привычку!]

3. Уровень стильного танцевания. В танго: приходить на ось ритмически точно на сильную долю, чтобы не было «недохода», выжим с места вперёд и вниз (а не вверх). Освоить «заднюю саккаду». В modern swing: чётко удерживать rolling count. В форро: отработать поворот партнёрши за спиной.

4. Уровень композиции/перформанса. Упражнение по музыкальности Рони Салеха в ритме slow-beat-beat-quick*4 (замедление в начале восьмерки, ускорение в конце, а не ускорение в начале и замедление в конце, как обычно). [вроде как обращение идёт к уровню ниже, ритмике как «движению вовремя», но тут это используется для того, чтобы разнообразить ритмические паттерны в ходе танцевальной импровизации, работа хореографа, это не совсем ритмика, это использование мастерства ритмики в хореографии]

5. Уровень вечеринки. Приглашать как минимум одну незнакомую партнёршу за вечеринку.

6. Уровень сообщества/субкультуры конкретного танца. Бывать на вечеринках как минимум двух разных стилей танцев в неделю. Познакомиться с идеями танго нуэво и стрит танго, смотреть видео, читать литературу. Осмыслить тренд разнообразия видов стайлинга и размытия стиля урбан киза. Посмотреть в Сети развитие культуры альтернативной музыки для разных стилей социальных танцев. Писать в Сети посты, популяризирующие культуру мультиданс/микс/нуэво/фьюжн танцевания.

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

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

Начали класть стены (фирма-каменщик::роль, «кладка»::метод, стена::«предмет метода»), фирма на этом подросла. Потом стали из стен делать здания «под ключ», фирма ещё подросла. Затем начали делать кирпичи и раствор для кладки кирпичей в стену, затем добавили проектирование зданий и отделку зданий, и так далее. Через некоторое время это девелопер коттежных посёлков из кирпичных домов, в том числе владеющий карьерами для добычи глины для своих кирпичных заводов. Иногда такую стратегию развития (стратегия — выбранный метод, в данном случае речь идёт о методе развития фирмы) называют вертикальной интеграцией²⁷⁴.

Моделирование: практики для различных системных уровней

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

Задание

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

1. Внимание в течение полного круга удерживается без отвлечений на мышечных ощущениях от ходьбы: что напрягается, что расслаблено, что в теле двигается, а что нет.

2. Внимание в течение полного круга удерживается на равномерности движения по кругу (что в ходьбе инерционно, что требует «тяги» для поддержания скорости, можно ли сделать движение более равномерным, без рывков и толчков. Проверка: ходить со стаканом воды — насколько там будет плескаться вода?)

3. Внимание в течение полного круга удерживается на форме круга и прохождении его за ровно восемь шагов (счёт шагов при их заданной длине, диаметр круга и насколько это круг, а не эллипс).

4. Внимание в течение полного круга удерживается на окружающей обстановке в целом (помещение, включающее в себя вас, ходящего по кругу)

5. Внимание в течение полного круга удерживается на контексте ситуации (управление вниманием в ходе выполнения задания из руководства по методологии).

5. Коллективная собранность в отслеживании выполнения работ

Диаграмма системного описания графов создателей

Выполнение работ означает два факта:

• Собственно затрату ресурсов на преобразование рабочих продуктов. Вася проработал два часа, забил сто гвоздей.

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

Дальше мнение о том, что такое «выполненная работа» может разделяться, как мы знаем из весёлых школьных диалогов: «-- ты выучил уроки? — Я учил! — я понимаю, что учил, но выучил ли?» или из физики «-- я двигал шкаф, аж вспотел! — но сдвинул ли? — нет, но я двигал! — тогда работа равна нулю». Всё-таки об успехе выполнения работы мы судим не по факту затрат ресурса, прежде всего времени создателя с его инструментарием и каких-то расходных материалов, но по достижению ожидаемого состояния предметов метода. Урок должен быть «выучен», шкаф «передвинут».

Состояние предмета метода даётся причастием, которое означает временный признак предмета (в данном случае — предмета метода) в отличие от прилагательного, которое означает обычно постоянный признак. Причастие — это особая форма глагола, которая отвечает на вопрос прилагательного (какой? Какая? Какое?). Иногда это даётся как «особая форма глагола», иногда как «отглагольное прилагательное»²⁷⁵. Глагол тут — какая-то операция, применение метода к его предмету: «гвоздь забит» означает, что для гвоздя была выполнена работа по методу забивания. Причастия имеют разную форму, нас больше всего интересует краткая форма страдательного залога прошедшего времени («проверен», полная форма была бы «проверенный»), краткая форма изменяется по родам и числам²⁷⁶. К такому причастию (в отличие от прилагательного) можно задать и вопрос «каков?» и «что с ним сделано?» (с учётом числа и рода). Солнце жёлтое (с ним ничего не сделано), но Солнце закрыто (его закрыли). Вот нас интересуют результаты работ: состояние на конец какой-то работы, каких-то взаимодействий. Что-то сделать можно даже с Солнцем (например, закрыть его зонтиком или тентом).

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

Тем самым получается, что для отслеживания выполнения работ надо отслеживать не просто состояния предмета работ (рабочих продуктов, например, в проектировании — проектной документации, в которой отражены какие-то проектные решения), но состояние предмета метода — например принятых проектных решений, предмет метода проектирования.

В руководстве по системному мышлению было введено понятие альфы как специального объекта, предназначенного для отслеживания состояний предмета метода. Особенностью альфы является то, что она игнорирует онтологический статус предмета метода. Скажем, альфа (воплощения) системы отслеживает состояния системы начиная с сырья, когда никакой системы ещё нет, но есть сырьё. Альфы служат для маршрутизации внимания в ходе отслеживания выполнения работ по их методу, они не отражают статическое онтологическое моделирование, когда каждый объект называется одинаково, независимо от его состояния по мере возможной сборки-разборки и даже прохождения проектирования как описаний «возможного будущего» (сама фраза «система существует в виде описания» формально-онтологически некорректна). Рассуждения об альфах поэтому полуформальны, моделирование альф тоже полуформально. Язык описания методов работ (по-другому — метод описания, задающий способ означкования для заданных типов понятий предметной области, viewpoint), основанный на альфах имеет уровень формальности псевдокода/pseudocode²⁷⁷. Псевдокод выражает какие-то алгоритмы (в том числе выражает алгоритмы через описание машины с конечным числом состояний, finite-state machine²⁷⁸) средствами, принятыми для описания алгоритмов, но итоговый записанный на псевдокоде алгоритм предназначен прежде всего для чтения человеком, но не для исполнения на классическом компьютере. Сейчас ситуация «чтения человеком» меняется довольно быстро, ибо чтение может быть и AI-агентом, задействующим большие языковые модели. Но в целом уровень формальности псевдокода меньше, чем уровень формальности классической алгоритмики или (помним об эквивалентности Curry-Howard) классической логики.

Итак, для того, чтобы отслеживать выполнение работ в проекте:

• Надо иметь метод описания состояний прежде всего предметов метода, например, использующий понятие альфы для моделирования этих изменяющихся состояний.

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

Стандарт OMG Essence²⁷⁹ предложил в качестве метода описания/viewpoint инженерных процессов (составляющих рабочих процессов) язык/language как набор понятий (онтологию, задающую типы моделируемых объектов) и средства графического и текстового «означкования» для записи моделей. Кроме языка моделирования в качестве примера для начала описания первые версии стандарта OMG Essence предложили также набор из семи основных/kernel (essence, существенный, основной, в самом стандарте эти семь альф названы kernel, но сам стандарт называется essence: «The kernel is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable engineering in a practice independent way») альф проекта программной инженерии. Есть в стандарте и другие типы основных объектов — основные области интересов, основные работы, основные компетентности. Но мы пока будем использовать только основные альфы. Последующие версии стандарта объявили этот стандарт более общим, приложимым к системной инженерии в целом. Этими семью альфами как основными объектами внимания к предметам методов разработки были: коммерческая возможность, проектные роли, требования, воплощение системы, работа создателя, команда создателя, метод (way of working) работы создателя.

Эти семь основных альф стандарт разложил в основные/kernel области интереса, в которых размещались тесно связанные основные альфы — это были области интересов заказчика (customer), предлагаемого проектного решения (solution, акцент на индивидуализированный результат «под ключ»), а также проекта/project (endeavor). Все остальные альфы (объекты пристального коллективного внимания) проекта предлагалось считать подальфами этих основных.

Этот набор семи основных альф был получен путём экспериментального ответа на вопрос: какие объекты внимания команды присутствуют в каждом проекте разработки? Было рассмотрено более 250 программистских проектов, и в основные альфы попали только те, которые встречались буквально в каждом проекте — это были работы примерно 2009-2014 годов в рамках инициативы SEMAT²⁸⁰.

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

Стандарт предлагал брать его язык/language (который вводил сам тип «альфа» как меняющий свои состояния объект внимания в проекте), но проводить его адаптацию в части набора основных/kernel альф. Стандарт по факту продолжает линию языков описания «инженерных процессов»/«методов разработки» (а ранее — «моделей жизненного цикла»), которые развивались в рамках ситуационной инженерии методов. Более ранние стандарты ситуационной инженерии методов предлагали какие-то свои варианты языков/language для описания объектов внимания в проекте, но они были ориентированы на методологов (SPEM, ISO 24744). OMG Essense был более продвинутым стандартом, ибо его главное отличие было заявлено как ориентация не на «удобную запись моделей методов», но «простое чтение метода» людьми-разработчиками как его пользователями, а не «далёких от народа» методологов. Поэтому стандарт сделал шаг работы «за методологов» и команда стандарта выполнила первый шаг моделирования разработки — предложила пример моделирования типами языка/language стандарта каких-то основных/kernel объектов внимания, прежде всего это набор из семи основных/kernel альф. Это отличало стандарты первого поколения ситуационной инженерии методов (они предлагали только language) от OMG Essence как стандарта второго поколения (language и пример kernel, который можно в простых случаях брать как первое приближение к важнейшим объектам внимания в проекте, сразу можно было отслеживать их состояния — в первом поколении стандартов инженерии методов этого не было).

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

С OMG Essence как стандартом моделирования инженерного процесса было проще работать: он «из коробки» уже что-то говорил не только про язык описания «метода разработки»/«инженерного процесса», но и про сам метод разработки: за какими именно альфами надо следить в проекте, какие состояния каких альф ожидать.

Но представления о лучшем на сегодняшний день (SoTA) типовом методе разработки поменялись, поэтому мы не можем оставить основные альфы из стандарта. Мы немного доработали²⁸¹ этот набор основных/kernel альф и областей интереса, сохранив язык/language стандарта ещё в 2015 году, для целей охвата проектов не только программной, но и «железной» системной инженерии. Это вполне предусмотрено и самим стандартом: в нём говорится, что можно оставить язык/language, но заменить основные понятия, предлагаемые на этом языке (kernel: конкретный набор альф из нескольких конкретных областей интереса, к которым предлагалось потом привязывать все остальные альфы как подальфы) на какие-то другие, более подходящие. Эта доработка оказалась удачной, но не окончательной. Дальше мы провели ещё несколько доработок основных альф и областей интереса — и представляем в нашем руководстве самый свежий вариант 2025 года, где повторяется для каждой из систем (целевой и её создателей, систем в окружении и их создателей) паттерн из четырёх основных альф: воплощения системы, описания системы, метода работы системы и работы системы.

Вы тоже должны дорабатывать набор основных/kernel альф для вашего рабочего проекта (наставления нашего руководства тут только ориентир!), но использовать язык/language этого стандарта, то есть типы «альфа», «область интереса», «рабочий продукт» и другие типы тамошней мета-мета-модели.

Основные альфы в стандарте было предложено считать связанными, это отражалось в диаграмме альф проекта разработки проекта, которую мы бы считали диаграммой графа создателей. Мы приведём её не для основных/kernel альф из стандарта, а для доработанного нами основного набора альф.

На этой упрощённой диаграмме мы видим три области интереса:

• Область интереса надсистем, главным образом там рассматривается время продвижения, «чтобы узнали и использовали — причём заплатили за это». «Время» тут рассматривается в контексте «непрерывного всего», означая время работ по созданию клиентуры как множества клиентов. Продвижение — это работы по маркетингу, рекламе, продажам: чтобы проект состоялся, надо найти клиентов, которые готовы оплатить создание и развитие системы, и дальше убедиться, что клиент доволен: созданная и развиваемая система успешна. В OMG Essence это примерно соответствует customer area of concern, обычно на диаграммах это закрашивается мятным (оттенок зелёного) цветом²⁸². Один из предметов интереса в этой области интереса — «внешние проектные роли»::альфа (то, что это альфа — означает, что в проекте будет отслеживаться смена состояний внешних проектных ролей, причём там указано, что этих ролей будет от 15 разных, то есть отслеживаться будет не просто эта альфа, а ещё и от 15 подальф этой альфы). Ещё один предмет интереса — «коммерческая возможность»::альфа, это сама возможность выполнить проект безубыточно. Альфа коммерческой возможности будет включать в себя подальфы надсистемы и потребностей (потребности — это ожидания внешних проектных ролей в поведении надсистемы, поэтому потребность может быть подальфой и внешней проектной роли: продвижение потребностей к удовлетворению продвигает и коммерческую возможность к моменту получения прибыли от проекта, но также и внешнюю проектную роль к состоянию удовлетворённости в использовании целевой системы) Для возможности выполнения проекта важна ожидаемая от него прибыль (превышение дохода от проекта над затратами на него), это тоже подальфа возможности. Если не отслеживать в ходе всего проекта альфы зоны/области интересов надсистемы, то результаты проекта могут оказаться никому не нужными, проект не будет оплачен — возможность выполнения проекта может исчезнуть в любой момент времени проекта, внешние проектные роли в любой момент могут перестать поддерживать организацию проекта материально, «продукт у нас есть, но его никто не покупает». Благотворительные проекты, которые оплачивают сами агенты-члены команды инженеров? Пожалуйста, тут разговор идёт о ролях, а не об агентах. Но если они не довольны тем, что сами же делают — проект прекратится за отсутствием возможности, хотя эту возможность и трудно будет назвать «коммерческой». Но ресурсов для разработки не будет, или ресурсы будут, они будут потрачены, но кто-то понесёт убытки — и это вопрос этичности: можно ли считать проект успешным, если внешние проектные роли несут убытки, а команда проекта получает оплату за не нужную никому работу, «нерациональную работу» в проекте.

• Область интереса целевой системы, в OMG Essence это solution area of concern, на диаграмме обычно жёлтого цвета. Эта область интересов относится главным образом ко времени использования. Мы видим там основные альфы kernel какой-либо системы — самой системы (в данном случае — целевой, физический двойник), её описания (в данном случае — цифровой двойник, нас ведь особо интересует время использования/эксплуатации, поэтому важно, чтобы описание включало в себя описание времени использования — акцент понятия цифрового двойника как раз на этом, «описание не только проекта/design, но и времени использования»), затем работа системы и функция/метод работы системы. Это то, чем в организации проекта будут заниматься самые разные инженеры целевой системы: их задача получить 1. воплощение системы, которое соответствует 2. описанию и 3. работает по выбранному 4. методу. Вот это всё и будет важными объектами внимания в проекте, и вот эти четыре основные альфы потом будут повторяться в самых разных областях интереса (тут их на диаграмме всего три, но в более сложных графах создателей их будет много больше).

• Область интересов создателя относится к выполняющей проект организации, главным образом во время создания системы, в оригинальном OMG Essence это была область интересов Endeavor (предприятие, проект, начинание), на диаграммах обычно голубого цвета. Там те же наши четыре основные/kernel альфы, только система — это уже инженерная команда (система-создатель целевой), её описание — это оргмодель, метод работы системы — это «метод разработки»/«инженерный процесс», а работа — это работы создания и развития целевой системы (работы инженерного процесса). Внутри каждой альфы вы видите некоторые предложения по составу подальф.

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

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

• Описание системы (проект/design — все необходимые для создания и развития системы модели), которое постепенно появляется в ходе создания и развития системы, а затем и в ходе использования/эксплуатации (в случае создаваемой системы это «и в ходе использования тоже» акцентируется термином «цифровой двойник»)

• Метод/функция работы системы в ходе её использования, уточняющий что там меняется из предметов метода, на базе какой теории/объяснений, какими инструментами. Метод, конечно, подчёркивает время использования (или использования созданной команды инженеров, или использования целевой системы).

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

Основных/kernel альф на диаграмме не четыре, а больше, ибо добавляются:

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

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

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

Диаграмма графа создателей — просто чеклист для альф как объектов, для которых проводится отслеживание состояния в ходе всего проекта. Надо не забыть отслеживать состояние всех этих альф и подальф. «Не забыть» — это главное. Графическое/диаграммное представление альф — не главное. Главное — это всегда помнить об этих альфах как важнейших объектах внимания и оценивать изменение их состояний.

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

Всегда используйте текст (аутлайн) и таблицу вместо диаграмм

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

Вот пример записи альф из диаграммы в нашем примере в виде списка (первый уровень — это область интереса, второй уровень — альфы):

1. Надсистема целевой системы (время продвижения)

   1. Коммерческая возможность проекта создания целевой системы

   2. Внешние проектные роли

2. Целевая система (время использования)

   1. Воплощение целевой системы

   2. Цифровой двойник

   3. Методы/сервисы/функции работы целевой системы

   4. Работы (оperations) целевой системы

3. Создатель целевой системы (время создания и развития)

   1. Инженерная команда целевой системы

   2. Оргмодель инженерной команды

   3. Метод разработки целевой системы (инженерный процесс)

   4. Работы создания и развития целевой системы

Этот список в использовании для мониторинга состояния проекта имеет много преимуществ перед диаграммой:

• Занимает меньше места, на маленьком экране его легко окинуть взглядом.

• Связи между элементами списка не отображаются. В принципе, как это замечается и в стандарте OMG Essence, в проекте все альфы связаны друг с другом — на диаграмме были приведены не все связи/отношения, а только некоторые, просто для иллюстрации того, что эти альфы как-то относятся друг ко другу. Вот мы эти отношения будем подразумевать, просто не прописывать словами.

• Список этот можно сделать в текстовом редакторе, не нужно долго рисовать картинки.

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

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

• Текст легко послать по почте, легко открыть для чтения — для чтения и записи текста существует много разного софта, для диаграмм — выбор меньше. Легко показать изменения (revision). Легко искать нужное место в большом списке (поиск по тексту).

Эту же диаграмму (граф создателей) легко показать, проигнорировав показанные в диаграмме отношения между основными альфами, не вложенным списком (аутлайном), а таблицей. Покажем это, добавив ещё и уровень подальф.

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

Даже необязательно объединять пустые ячейки таблицы, их можно просто оставлять пустыми. И необязательно использовать нумерацию. Если вы понимаете (удерживаете в голове, не упускаете из внимания) принципы, по которым устроена эта таблица, вам и вашим коллегам будет всё понятно. Мы ещё и добавили пример состояний для одной из альф, чтобы было понятно, что такое табличное описание легко расширять, и оно очень компактно — ещё и в качестве буллета использовали «птичку», как в чеклисте (это же всё такой витиеватый и необычный, но чеклист! Объекты внимания, состояния которых надо отслеживать!) и даже вставили словесный комментарий, разорвав список состояний альфы. Если вы понимаете, что такое «область интересов», «альфы», «подальфы», «состояния альфы» (это всё было в руководстве по системному мышлению), то вы легко разберётесь. Это просто примеры моделирования с использованием этого языка/language/онтологии/мета-мета-модели в качестве метода описания происходящего в проекте создания и развития системы. Опять немного поменяли имена (помним, что синонимов много, важно понимать смысл, а не запоминать слова). И, конечно, можно использовать как таблицы в Ворде, так и таблицы в Экселе, но ещё и в coda.io, notion.so, Obsidian и других редакторах текста и табличных процессорах, а также productivity tools:

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

Ещё таблицы можно разбивать на части, совсем необязательно в проекте иметь одну огромную таблицу.

Не пользуйтесь диаграммами (картинками с квадратиками и стрелочками) для моделирования, пользуйтесь текстами (не только на естественном языке, но и в виде псевдокода, необязательно даже использовать полностью формальный язык! Вы можете всегда указать в тексте на естественном языке тип какого-то понятия, указать список синонимов для термина, уточнить значение, дать ссылку на литературу), многоуровневыми списками (outline), таблицами.

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

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

1. Опишите метод в форме, пригодной для его изучения (это означает разработку регламента/инструкции/«корпоративного стандарта» для рабочего процесса не столько в форме «справочника» или «чёткого алгоритма», сколько в форме учебного материала, удобного для укладывания в голову).

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

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

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

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

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

По чеклистам как основному средству обеспечения коллективной собранности (мы предпочитаем современное написание «чеклист», а не «чек-лист» как в старых словарях) читаем книгу Atul Gawande, «The Checklist Manifesto», 2009 — и смело считаем эту книгу одним из самых интересных современных материалов по методологии, она подробно описывает, как появляется и поддерживается разделение труда (division of labor), то есть разложение методов работы на отдельные составляющие, поручение работ по этим методам отдельным агентам, которые оказываются играющими разные роли в проектах.

Чтение этой книги — обязательная часть в освоении методологической работы по нашему руководству. Вы не вычитаете в этой книге ничего принципиально нового, но книга вас убедит, что чеклисты — это важно, нужно, и надо их использовать в работе. После чтения книги инженеры-менеджеры перестают рассуждать и думать о чеклистах, но доходят до изменения своего поведения: начинают активно разрабатывать и использовать чеклисты, и это спасает их и личные, и рабочие проекты. В книге Atul Gawande приводится один из примеров: использование чеклистов при проведении операций в больницах снизило смертность на 30%. Это типичный результат. Примерно такого же можно ожидать с вашими проектами: смертность вашего проекта может быть снижена использованием чеклистов на треть, а то и больше.

Задания: чеклисты

Поставьте отметку о выполнении.

1. Прочтена книга Atul Gawande, «The Checklist Manifesto», 2009 (есть и русскоязычные переводы). В ходе чтения вы понимали, что речь идёт об альфах (объектах особого внимания в проектах, состояния которых оказываются крайне важны) и списках их состояний. Чеклисты позволяют удостовериться в достижении этих состояний. Чаще всего это состояние после закрытия какого-то кейса::работа.

2. Написан в порядке мышления письмом пост о том, что вы нашли контринтуитивным в прочитанной книге о чеклистах, то есть что было удивительно и с чем трудно было согласиться.

Области интересов надсистем, целевой системы, создателя

Области важных характеристик/предметов интереса (area of concerns) предложены в стандарте языка/language OMG Essence для группировки объектов внимания в проекте по укрупнённым характеристикам связи с какими-то системами. Они настолько укрупнены, что их было предложено называть не интересами, а областями интересов. В основных/kernel объектах из примера стандарта это были области интереса к объектам внимания, связанным с заказчиком/customer, системой»/system и проектом/начинанием/endeavor. Мы оставляем язык стандарта, сохраняем понятие «области интересов», но отказываемся от предложенного примера основных/kernel объектов в пользу более подходящего к нашему случаю примера не работы одной команды, а работы множества команд в графе создателей.

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

• что уже сделано (достижение необходимых состояний предметов метода будет отмечено в чеклистах), а

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

«Важная характеристика»/«предмет интереса» — это тема «озабоченности»/concern множества ролей. Она выражается явно каким-то методом описания/viewpoint, это не «чего ролям хочется достичь». «Чего хочется достичь» — это будет не сама характеристика, а предпочтения проектных ролей для этой характеристики, сам интерес в предмете этого интереса как шкале для отметки предпочтений —роли могут двигать целевые характеристики в разные стороны, для этого они используют удобные для этого методы описания. И роли договариваются между собой по поводу реализации своих предпочтений в этих важных характеристиках.

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

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

Если это группа агентов/оргзвеньев, которые играют какие-то роли (например, клиентура или просто «внешние проектные роли»), то будем создавать чеклисты для подальф, чтобы отслеживать изменения состояний отдельных агентов в группе. Подальфы важны, ибо часто нельзя сказать, что достигнуто какое-то состояние для альфы в целом, но можно — для подальф. Подальфы добавляют «разрешение»/resolution в модель, примерно так же, как добавка разрешения матричного экрана позволяет рассмотреть больше деталей изображения. Если у вас экран 8x8 пикселей, то вряд ли вы поймёте, что же у вас на нём изображено. Если же разрешение 4K UHD (3840 × 2160), то вы не только увидите, что изображено, но и увидите состояние того, что изображено. Например, на вопрос о том, в каком состоянии клиентура, вы могли бы отвечать «Клиенты 3, 5, 8 в процессе перезаключения договора, клиент 64 вчера отказался от наших услуг и мы проводим дополнительную с ним работу, от клиентов 39, 40 и 35 ожидаем оплаты, остальные обслуживаются». При этом у вас есть и альфа «клиентура», ибо если её нет, то что вы развиваете? Развиваете вы как раз клиентуру, наращиваете число клиентов в целом, увеличиваете лояльность, считаете показатели юнит-экономики²⁸⁴.

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

А теперь покажем группу из четырёх альф в каждом звене графа создателей масштаба предприятия, добавим немного дополнительных подробностей, просто чтобы оценить топологию графа создателей, когда начинаем его разворачивать для отслеживания не только самих систем, но и их описаний и их работ. Эту диаграмму вы уже видели, она была в руководстве по системному мышлению в разделе «Системное описание предприятия», подразделе «Системное описание (предметов) деятельности предприятия» ²⁸⁵:

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

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

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

1. Опишите функцию в форме, пригодной для её изучения и выполнения системой (это означает разработку модели, а то и исполняемого алгоритма для функции). Узнали «подготовьте регламент/инструкцию в форме, удобной для загрузки в голову сотрудника»?

2. Составьте для функции набор тестов состояния (впрочем, с этого можно начинать — test-driven development, TDD, когда тесты на достижение правильных выходных состояний системы для самых разных входных состояний разрабатываются заранее. Помним, что все эти «шаги» и их порядок — условны, жизнь сложнее, методы на чёткие «шаги» обычно не делятся, поэтому там термин «разложение на составляющие», а вы тут читаете именно «описание метода описания метода и надзора над его соблюдением», как бы странно рекурсивно это ни звучало). Узнали «подготовьте шаблон чеклиста»?

3. Убедитесь, что и описание метода, и результаты тестирования (замеры состояний) хранятся по возможности в самой системе, хотя тут могут быть и варианты. Это и есть «цифровой двойник», digital twin. Узнали про «убедитесь, что регламенты и чеклисты не в вашем софте, а в операционном софте сотрудника, который их исполняет»?

4. Проведите наладку — для этого в ходе разработки обязательно проведите испытания в самых разных режимах и обнаружьте несовпадение ваших моделей с реальностью. Исправьте ошибки по возможности до выхода в эксплуатацию. Инженерные обоснования (quality assurance) обязательны (подробнее — в руководстве по системной инженерии). Узнали «пройдите по чеклисту вместе с сотрудником»?

5. Не забывайте проверять, что там происходит с цифровым двойником, и как используются его данные для подстройки системы под условия использования. Узнали «организуйте надзор за честным заполнением чеклиста»?

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

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

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

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

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

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

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

Не бойтесь модифицировать приведённые в нашем руководстве основные альфы, наборы их подальф, контрольные вопросы чеклистов для состояний этих альф. Наоборот, бойтесь их не модифицировать. Хотя наши инженеры-менеджеры и говорят, что 75% примеров альф из нашего руководства можно использовать в проекте без модификации, вам может повезти сильно меньше. Только вы внутри проекта сможете сообразить, какие именно альфы и их подальфы вам нужно отслеживать, и только вы сможете сообразить, что можно взять для моделирования их чеклистов из нашего руководства, а что надо будет создать самим. Сам стандарт OMG Essence настаивает, чтобы чеклисты альф были адаптированы командой проекта: это даёт некоторую надежду, что команда понимает, что говорится в контрольных вопросах этих чеклистов.

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

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

Планирование этих работ/operations/services целевой системы не всегда делает сама целевая система (если эта система не очень живая, то это может делать оператор из системы создателя или кто-то из окружения целевой), поэтому планирование на отношении связи между воплощением системы и её работами на диаграмме взяли в скобки. По большому счёту, в момент времени работы/эксплуатации целевой системы она может при достаточной степени агентности/автономности/сознательности планировать (заранее или «на лету»/on the fly) свои работы сама, при этом, конечно, для того, чтобы не запутаться, обязательно проходим на системный уровень вниз: что там планирует, а что исполняет планы из подсистем (помним про «моя правая рука почесала мою левую руку по методу, который выбрало моё мастерство чесания, и по плану, который составило моё мастерство планирования собственных движений»).

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

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

Длина вроде как типовых цепочек создания для графа создателей в разных организациях может существенно различаться, там не так уж и много «типового». Так, клиентура в маленькой компании может создаваться службой продвижения непосредственно. А в большой компании — сначала служба продвижения создаёт агентуру, а потом уже агентура создаёт клиентуру. Точно так же можно рассматривать и вставку в цепочку создания какого-то оборудования: разработчики создают игровые сеансы не непосредственно, они создают игровые программы на устройствах игроков и серверную часть этих программ, а уже эти программы создают игровые сеансы. В появляющееся в цепочках создания оборудование можно включать и людей (скажем, система колл-центра на базе AI обрабатывает 90% звонков, но 10% звонков переключаются на людей — и мы считаем их «такими специальными станками, цели для ближайшей автоматизации/цифровой трансформации/интеллектуализации» — и для «неживой» и «живой» части таких систем можно обсуждать различные цепочки создания, различные производственные технологические платформы). Смотрите внимательно, сколько звеньев включать в якобы «типовые, сразу понятные» цепочки создания. Очень часто число этих звеньев недооценивается и обсуждать проект становится сложно из-за явных пропусков таких звеньев: по факту это вы пропускаете важные объекты внимания, они остаются без своих чеклистов, в какой-то момент проекта вы просто о них не вспомните, и дальше обязательно реализуются какие-то связанные с ними риски.

Инженерия производственной платформы (современный подход к DevOps/SRE как к platform engineering, подробнее будет рассказано в руководстве по системной инженерии), в том числе создание административных служб предприятия (подробнее будет рассказано в руководстве по системному менеджменту), на примерах диаграмм в текущем подразделе не показана. Но там применимы все те же рассуждения, что в руководстве по системному мышлению приводятся для графа создателей: инженер платформы разработки создаёт «большой станок» (в случае ракеты это завод ракет, в случае софта — это inner development platform, в случае системы-предприятия — это административные службы) и обеспечивает его работу, обучает инженеров работать с его помощью (для чего пишет регламенты/руководства по инженерному процессу, который задействует эту производственную платформу как инструментарий), и уже на этом «большом станке» изготавливается описания целевой системы, а затем и сама целевая система.

Вам нужно предусмотреть это, когда будете адаптировать основные альфы для вашего проекта. Этим занимаются чаще всего исполнители ролей CTO/CIO (chief technology/information officer, в современном мире «станочный парк» стал во многом «парком» корпоративных информационных систем, «главный инженер» и «главный айтишник» — это одно и то же по их задачам), или выделенные ответственные за DevOps, и этих инженеров производственной платформы не надо путать с инженерами целевой системы: одни проектируют и эксплуатируют завод, а другие проектируют и эксплуатируют целевую систему, изготавливаемую и проверяемую на этом заводе.

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

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

Какая альфа главная в основных альфах графа создателей? С одной стороны, все альфы. Отслеживать изменения в проекте нужно всех альф, ни одной не забывать. Но «главная среди равных» — альфа воплощения системы, привязывающая все рассуждения к физической реальности. Системы материальны, они гарантируют адекватность проекта, предупреждают отрыв мышления от реальности. Привязка всех остальных альф к альфе воплощения системы помогает избегать оторванных от физической реальности рассуждений, которые могут оказаться фантазиями.

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

TEST Область интересов, основные альфы

На совещании в инженерном отделе оказалось, что все обсуждают описание целевой системы и её воплощение. Иногда обсуждали собственные (инженеров) работы по созданию системы и способы ведения этих работ. Какая область интересов наверняка упущена?

+++ Надсистем ### Да, ни возможность выполнения проекта, ни внешние проектные роли не упоминались. Тем самым в проекте в этой области интересов могут быть необсуждённые неожиданности.

--- Целевой системы ### Нет, описание целевой системы и воплощение целевой системы — это область интересов целевой системы, а эти вопросы как раз обсуждались.

--- Создателя ### Нет, работы и метод организации, выполняющей инженерный проект — это как раз область интересов создателя, они обсуждались.

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

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

+++ С целевой системой ### Да, ничего из области инженерии целевой системы в перечне имеющегося опыта не упомянуто.

--- С организацией ### Нет, у специалистов есть опыт в этой области (менеджмент в целом и лидерство в частности).

Менеджер проекта не спит, и думает о проекте. Какую систему проекта при этом он считает своей?

--- Надсистему ### Нет, о надсистеме обычно думает визионер или продвиженец, или учитывающий потребности разработчик, когда он разрабатывает концепцию использования.

--- Целевую ### Нет, о целевой системе обычно думают прикладные инженеры.

+++ Создателя ### Да, менеджер проекта обычно думает именно о той организации, которая проектирует и изготавливает целевую систему (команда или даже коллектив инженеров) — работах этого оргзвена, организации команды, задействованном инструментарии как ресурсах, оргвозможностях ведения инженерного процесса.

Инженерным отделом были рассмотрены несколько вариантов изготовления корпуса устройства, включая штамповку под высоким давлением и 3D печать высокого качества. О каких основных альфах идёт речь?

+++ Воплощение создаваемой системы ### Да, если речь про реально изготавливаемый корпус системы в физическом мире — это про воплощение.

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

--- Функции создаваемой системы ### Нет, о функциях изделия и создаваемого корпуса изделия речь не идёт.

--- Работы целевой системы ### Нет, рассматривалось время создания. Время использования целевой системы не обсуждалось.

--- Создатель ### Нет, явно создатель не обсуждался. Когда выберут метод, можно будет пообсуждать, кто там будет этот метод исполнять: это и будет создатель.

--- Описание создателя ### Нет, никакие описания не обсуждались, обсуждалось только то, что будет происходить — варианты методов работы создателя.

+++ Метод работы создателя ### Да, варианты изготовления — это про выбор варианта метода по его сигнатуре (изготовление::метод и корпус::«предмет метода»): штамповки или 3D печати высокого качества. Без выбора варианта метода нельзя даже будет сказать, что там за роли должны быть в команде инженеров: технологи штамповки или технологи 3D-печати!

--- Работы создателя ### Нет, про то, кто и когда что-то будет реально делать (штамповать, печатать) речь не идёт.

--- Производство ### Нет, это не одна из основных альф. Хотя в проекте могли выделить и отслеживать такую подальфу, но нам об этом неизвестно.

--- Возможность ### Нет, про то, ради чего и почему делается устройство, выгодно ли вообще им заниматься — речь не идёт

--- Внешние проектные роли ### Ни о внешних, ни о внутренних ролях не говорилось.

В ходе выполнения проекта по созданию многодиапазонного аппаратно-программного комплекса для моделирования сетей радиодоступа изменились сроки возможного проведения полигонных испытаний, в связи с чем были внесены соответствующие изменения в план-график. О каких основных альфах идёт речь?

--- Описание системы ### Нет, про описание целевой системы (информационные модели в 3D, расчёты и прочие описания, отражённые в инженерном софте) речь не идёт.

+++ Воплощение системы ### Да, речь про испытания реально изготовленного (то есть уже на полигоне) комплекса — это про воплощение.

--- Методы работы целевой системы ### Нет, методы работы аппаратно-программного комплекса не обсуждались.

+++ Работы целевой системы ### Да, в ходе испытаний целевая система будет работать, эти работы надо запланировать и выполнить с нужными ресурсами.

+++ Работы создателя ### Да, тут говорится, кем и когда что-то будет реально делаться (план-график испытаний именно об этом).

--- Методы работы создания ### Нет, методы работы не обсуждались, не менялись, обсуждался только план-график, а это — работы.

--- Описание создателя ### Нет, про моделирование команды создателей речь не заходила.

--- Возможность ### Нет, про возможность выполнения проекта речь не идёт: вопросы выгодности проекта для команды, удовлетворённости внешних проектных ролей не ставились.

--- Внешние проектные роли ### Нет, внешние проектные роли не были помянуты.

--- Календарный план ### Нет, это не одна из основных альф. Хотя в проекте могли выделить и отслеживать такую подальфу, но нам об этом неизвестно.

В ходе проекта обновления программного обеспечения компьютерного зрения в системе автоматической сортировки шкур животных в цеху кожевенной фабрики было определено, что сложные математические способы определения площади не подходят для решения задачи. Было принято решение использовать простой алгоритм умножения количества пикселей в изображении шкурки на коэффициент, определяемый при калибровке системы. Это изменение алгоритма было внесено программистом Виктором в коды системы сортировки шкур 12 мартобря 2018 года, 13 мартобря 2018 новая система была введена в эксплуатацию. О каких основных альфах идет речь?

+++ Воплощение системы ### Да, речь про обновление реально работающего ПО (программного обеспечения) в цеху — это про воплощение.

+++ Описание системы ### Да, код алгоритма — это изменение описания целевой системы. Это по факту проект обновления софта — софт компьютерного зрения тут целевая система, код алгоритма — это описание софта.

+++ Функции системы ### Да, речь шла о выборе варианта метода/функции по её сигнатуре: вместо сложных способов работы системы выбрали простой.

+++ Работы системы ### Да, упомянут ввод в эксплуатацию, начало выполнения работ системы.

+++ Создатель ### Да, упомянут программист Виктор.

--- Описание создателя ### Нет, никакие описания команды разработчиков нам неизвестны.

--- Методы создания ### Нет, нам неизвестны методы, которыми работал программист Виктор.

+++ Работы создателя ### Да, упомянута работа программиста Виктора.

--- Возможность ### Нет, тут не обсуждалось то, ради чего и зачем нужно делать проект улучшения системы компьютерного зрения или даже систему автоматической сортировки шкур животных.

--- Метрология ### Нет, это не одна из основных альф. Хотя в проекте могли выделить и отслеживать такую подальфу, но нам об этом неизвестно.

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

--- Воплощение системы ### Нет, до воплощения системы в физическом мире дело пока не дошло.

+++ Описание системы ### Да, речь идёт о проектировании (работа над концепцией системы) — это обычно про описание целевой системы перед тем, как начать её воплощать/изготавливать.

+++ Методы работы системы ### Да, технологии/методы рекуперации — это про время работы системы.

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

-- Создатель системы ### Нет, мы не знаем, кто создаёт систему энергообеспечения.

--- Описание создателя ### Нет, никакие модели самого создателя не обсуждались.

--- Методы работы создателя ### Нет, не сказано, каким методом принимались решения о выборе варианта метода работы системы, разрабатывалась концепция системы.

--- Работы создателя ### Нет, речь не шла о том, кто, что и когда будет делать в команде прикладных инженеров.

+++ Возможности ### Да, работа с технико-экономическим обоснованием, обсуждение общей стоимости владения — это работа с коммерческой возможностью выполнения проекта.

--- Жизненный цикл ### Нет, это не одна из основных альф. Хотя при рассмотрении описания организации проекта можно обсуждать и выбор модели жизненного цикла/метода разработки и развития (метод разработки, инженерный процесс), но в тексте методы работы создателя не обсуждались.

На просьбу инвестора рассказать о проекте бизнесмен подробно рассказал о существующих клиентах, бизнес-модели, денежных потоках и команде проекта. Какие основные альфы и их подальфы совсем не затронул бизнесмен в своём рассказе?

+++ Воплощение системы ### Да, про состояние дел с физическим воплощением системы в реальном мире ничего не сказано.

+++ Описание системы ### Да, про описание целевой системы (информационные модели, расчёты и прочие описания, отражённые в инженерном софте) речь не зашла.

+++ Метод работы системы ### Да, способ, которым система выполняет свою работу, не обсуждался.

+++ Работы системы ### Да, работы системы не обсуждалось. Не обсуждались никакие альфы области интересов системы.

--- Создатель ### Нет, про команду было рассказано.

+++ Метод разработки ### Да, про инженерный процесс ничего не сказано.

+++ Работы по созданию и развитию ### Да, про них ничего не сказано: ничего о том, что, когда и кем будет сделано при создании и развитии системы.

--- Возможность ### Нет, бизнес-модель и денежные потоки — это про коммерческую возможность ведения проекта, это было упомянуто в рассказе.

--- Внешние проектные роли ### Нет, про клиентов было рассказано, они как раз и есть внешние проектные роли (хотя, конечно, кроме клиентов есть и другие внешние проектные роли).

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

+++ области интересов надсистем ### Да, ради возможности («коммерческость» тут весьма условна!) понравиться жениху и была девушкой сделана причёска (осуществлён проект по стрижке и укладке волос). Теперь коммерческая возможность отсутствует, внешняя проектная роль «жених» не может быть переведён в состояние «удовлетворён в использовании», так что и внешняя проектная роль «заказчик причёски» тоже не может быть переведена в состояние «удовлетворена в использовании».

+++ области интересов целевой системы ### Да, реальная причёска — это воплощение целевой системы.

--- области интересов создателя ### Нет, на парикмахеров, их описания, их методы работы, их работы поток воздуха не повлиял — все эти альфы не поменяли свои состояния.

--- области интересов культуры ### Нет такой зоны интересов в проекте.

Лежащий на складе куксователь потенциальный заказчик готов купить, если у него цена одной куксы составит не более 3 рублей на протяжении всего срока эксплуатации. Этого можно достичь, если расположить куксователь вертикально. Для этого нужно пригласить мастера-вертикальщика и вложиться в специальный прибор для калибровки вертикальных куксователей, плюс предусмотреть дополнительную неделю на работы по калибровке. Какие из основных альф упомянуты в этом рассказе?

+++ Возможность ### Да, цена — это про коммерческую возможность выполнения проекта. Если куксователь не готовы купить, то нет возможности выполнить проект.

+++ Внешние проектные роли ### Да, потенциальный заказчик — это внешняя проектная роль.

+++ Воплощение куксователя ### Да, речь идёт именно про реальный куксователь, с которым надо что-то делать — расположить вертикально и калибровать.

--- Описание куксователя ### Нет, про описание системы тут речь не идёт: не делается никаких описаний куксователя, моделирования не ведётся. Хотя можно считать, что было сделано стоимостное описание, да ещё и для вариантов вертикального и иного (не сказано, какое) расположения куксователя, но явно об этом описании ничего не говорится.

--- Функции куксователя ### Нет, работы целевой системы в ходе её использования не обсуждались.

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

--- Описание организации проекта ### Нет, ничего про моделирование организации не говорилось, про оргпроект/оргмодель мы ничего не знаем.

+++ инженерный процесс ### Да, рассказано про методы работы команды: устанавливать куксователь вертикально (требуется мастерство вертикальщика) и калибровать куксователь.

+++ Работы организации ### Да, работы непосредственно упомянуты, в частности, необходимость выделения на работы по калибровке дополнительной недели.

Альфы — общий объект отслеживания для организации

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

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

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

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

Конечно, каждая новая степень взаимодействия включает в себя и предыдущие (нет сотрудничества без кооперации)²⁸⁶:

• Игнорирование (ignorance) того, что делают другие агенты, можем даже нанести им вред. При этом иногда заявляют «ничего личного, это бизнес» — и что самое интересное, и заявитель такого верит, что это отличное оправдание, и даже те, кому вредят, вроде как «понимают мотивы». А поскольку игнорируем, то никакого общения, делами других не интересуемся, свои дела никому не показываем.

• Информирование и общение (networking): готовы общаться, но не готовы ничего менять в своих планах и действиях. Если кто-то готов подстроиться под нас, то и хорошо. Но сами работаем, как работаем. Скажем, вывешиваем часы своей работы — но не готовы их менять даже когда кому-то очень надо.

• Координация (coordinated networking): готовы поменять какие-то свои планы и действия. Например, поглядеть на часы работы соседа и прийти в его рабочие часы. Заполнить форму, какую от меня требуют в той системе, в которой требуют, а не написать заявку в произвольном формате и отослать личным письмом.

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

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

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

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

Проблема отсутствия сотрудничества может появляться даже, когда все роли исполняются одной личностью (одна личность выполняет работы разных методов, задействует несколько разных видов мастерства). Агент легко может не согласовать действия своих разных ролей между собой. Причины разные, например, желание получить оплату за две работы, которые совместно не улучшат систему, а ухудшат её, или банальная несобранность, или просто непонимание происходящего. Скажем, губернатор в своей речи заявляет, что сделает всё возможное, чтобы привлечь в регион иностранные инвестиции, создать максимально благоприятный инвестиционный климат, ибо без инвестиций будет всё очень плохо, но через три минуты в той же речи говорит, что в регионе появилось слишком много компаний с иностранным владением, и он будет с этим бороться! Это противоречие самому ему незаметно, ибо говорили от его имени разные роли с разными интересами. Такое встречается сплошь и рядом.

Польза от системного и методологического мышления — поднять скорость и точность согласования своих работ в условиях коллективного сложного труда, скооперироваться и сотрудничать в коллективном сложном труде! Для этого агенты договариваются:

• Об инженерном процессе и составляющих его методах (в том числе методах менеджмента, например, метод операционного менеджмента).

• О том, какие роли в инженерном процессе кто из агентов будет играть.

• Какие предметы составляющих методов инженерного процесса будут менять свои состояния (альфы).

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

• Все согласования делать в режиме «непрерывного всего», ибо каждый день будет новая ситуация в проекте — и надо будет передоговариваться (договориться раз и навсегда не получится!).

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

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

• Замышлена (conceived), внешние проектные роли согласны в необходимости новой системы для удовлетворения потребностей.

• Ограничена (bounded), функции новой системы в её окружении понятны.

• Непротиворечива (coherent), концепция использования непротиворечиво описывает существенные характеристики новой системы.

• Приемлема (acceptable), концепция использования описывает систему, которая приемлема для проектных ролей.

• Учтена (addressed), функции достаточно реализованы воплощением системы так, чтобы это было принято внешними проектными ролями как удовлетворение их потребностей.

• Удовлетворена (fulfilled), на текущий момент потребности внешних проектных ролей удовлетворены.

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

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

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

• в голове удерживаете типы мета-мета-модели из фундаментальных дисциплин (например, наших руководств по системному мышлению и методологии),

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

• в ячейках строк табличек будут значения характеристик объектов операционной модели (модели экземпляров из реального мира), явно классифицированные типами мета-модели (или метаУ-модели, или метаС-модели) в колонках, которые неявно («в голове») классифицированы типами мета-мета-модели.

Отслеживать нужно все три уровня моделей! Без типов мета-мета-модели (типов из наших руководств, удерживаем внимание на них «в голове») вы плохо будете выделять важные объекты внимания в предметных областях (из учебника, или на предприятии), наверняка забудете продумать культурно-обусловленные/«цивилизационно известные» важные характеристики системы и проекта, сделаете новичковые ошибки (или просто ошибки из-за несобранности личной или коллективной), не сможете корректно записать модели, что обязательно приведёт к утере коллективной собранности.

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

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

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

«Станочный парк» многих проектов сегодня часто соответствует «парку корпоративных информационных систем». За них отвечает инженер производственной платформы. Чаще всего эта роль выполняется оргзвеньями под руководством CTO и/или CIO. В их ведении обычно и инженерный процесс (метод разработки), в том числе поддержка составляющих этого метода необходимым инструментарием. Для метода разработки концепции использования целевой системы инженер платформы должен предусмотреть моделер, её поддерживающий (например, для практики use case выбрать какой-то моделер, позволяющий записывать результаты моделирования), а также предусмотреть управление конфигурацией для версий концепции использования (версий документов с моделями, входящими в концепцию использования целевой системы). Так что инженер производственной платформы тоже занимается подальфой концепции использования.

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

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

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

Команда договаривается о том, что такое в жизни эти альфы, каковы их состояния (адаптирует к ситуации своего проекта типовые наборы альф, подальф, их состояний, контрольных вопросов к состояниям), договаривается о том, какие рабочие продукты будут отражать эти состояния альф. Затем команда сотрудничает в изменении состояний альф. Для этого команда моделирует состояние альф («коллективное мышление моделированием»), удерживает внимание на этих важных объектах («коллективная собранность»).

Для какого-то записанного и обсуждённого состояния альф команда выбирает методы работы, планирует работы, выделяет ресурсы — и проводит работы.

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

TEST Роли и их ведущие альфы

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

+++ Операционный менеджер ### Да, решение о перемещении ресурсов — это и есть типичное решение операционного менеджера. Прораб (человек на должности) выступил как операционный менеджер (проектная роль).

--- Архитектор ### Нет, архитектор принял бы для снижения цены техническое решение, как-то изменяющее принципы деления на конструктивные части и их взаимодействие для целевой системы — квартиры.

--- Разработчик ### Нет, инженер-разработчик может ответить изменением проекта/design, который должны будут реализовать ремонтники, учёт работы именно землян в проекте вряд ли есть (но если выяснится, что тау-китяне не могут выполнить какие-то операции, требуемые проектом, прораб может потребовать, чтобы разработчики изменили проект, или сам прораб станет на некоторое время разработчиком и поменяет проект).

--- Владелец продукта ### Нет, такая роль вообще тут не участвует. И это очень похоже на должность, а не роль, хотя из ролей к этой должности ближе всего визионер.

--- Визионер ### Нет, визионер бы просто сказал «такой проект нам невыгоден».

В ответ на требование заказчика снизить стоимость ремонта трёхкомнатной квартиры на 100 тысяч рублей и сократить срок производства работ на 1 неделю, прораб принимает решение проложить внешнюю электропроводку вместо скрытой. Прораб при принятии этого решения действовал как:

--- Операционный менеджер ### Нет, операционный менеджер принимает решения работах, но не технические решения.

+++ Разработчик ### Да, разработчик принимает именно технические решения, меняющие целевую систему — квартиру. Прораб (должность) выступил как разработчик.

--- Владелец продукта ### Нет, такая роль вообще тут не участвует. И это очень похоже на должность, а не роль.

--- Визионер ### Нет, визионер бы просто сказал «такой проект нам невыгоден».

Альфа коммерческой возможности ведения проекта

Описываемый концепцией использования ход «от потребностей (что мы хотим от надсистемы, если в её состав включить неизвестную пока целевую систему) к описанию целевой системы с её обычно неизвестными на момент начала проекта свойствами» сам по себе нетривиальный. Этот ход включает по факту в себя изобретение: предложение целевой системы как аффорданса в конструкции надсистемы, удовлетворящей потребности в функции этой надсистемы.

Скажем, наша целевая система должна быть «забивало» для гвоздей в какой-то надсистеме (столярная мастерская). Мы «идём на рынок» и ищем для «забивала» аффорданс изо всех представленных на рынке конструктивов: микроскоп дороговат, камень непрочный и неудобный, плоскогубцы слишком лёгкие для передачи энергии гвоздю. Ок, давай сделаем сами что-то железное тяжёлое, которое удобно держать, но не плоскогубцы — они вроде хороши, но их бы утяжелить. Назовём этот аффорданс «молоток» (маленький молот, а молот от «молотить» — стучать, бить). Рука взаимодействует с тяжёлым (но полегче, чем молот) молотком, разгоняя его, а энергия затем передаётся гвоздю, загоняя его в доску.

Добавим ещё один сценарий использования: бьём молотком не по гвоздю, а по чему-то хрупкому, чтобы расколоть. Для гвоздя нужно иметь плоскую поверхность бойка, чтобы легче попасть, а для колки всё то же самое, но хорошо бы малую поверхность клина при ударе, чтобы больше энергии уходило через меньшую площадь. Итак, нам нужен тяжёлый объект (предположительно металл), в котором есть большая и маленькая площадки, который приводится в движение рукой. И вот он будет не только в мастерской «забивалом», но и при нужде «разбивалом».

Эта идея приходит в головы разработчикам двух фирм. Они придумывают более-менее одинакову концепцию системы (тяжёлая металлическая часть для передачи энергии, снабжённая удобной для держания рукой деревянной рукояткой). Но одна фирма специализируется на функции «забивала» (не исключая побочно выполняемой функции «разбивала») и называет свой продукт «молоток» с плоским бойком и клином с острым носком в головке молотка:

Другая фирма специализируется на функции «разбивала» и выходит на рынок с «топором», где клин делается тонким (полотно) и ещё затачивается для получения лезвия с минимальной площадью, а для «забивала» используется обух:

Проблема предложения целевой системы в том, что для понятного набора функций системы нужно предложить её конструкцию из подсистем. Если концепция системы непонятна (непонятно, из чего делать систему), то никакое описание нужных функций не поможет. Если Бэббиджу было непонятно, что вычислитель надо было делать из вакуумных ламп (которых в его времена просто не было), а изобретателям самолётов до братьев Райт было непонятно, что двигателем там должен быть лёгкий и мощный двигатель внутреннего сгорания (а не распространённая раньше паровая машина) — проекты не могли быть удачными. Скажем, скатерть-самобранка хорошо понятна в части сценариев её использования дома и в ресторане, но как и из чего её сделать?! Надо синтезировать концепцию системы, а также каждой подсистемы, и так на много уровней вниз — если это сразу не удалось, то не факт, что удастся в ходе проекта. А если удалось, то не факт, что на предлагаемое инженерное решение будет спрос, вложения в разработку (включая производство) и маркетинг (это могут быть тоже немалые затраты) окупятся.

В случае потребностей конструктивные решения и для надсистемы (что там может быть целевой системой) и для самой целевой системы (из чего её сделать) обычно не так очевидны, о них должно быть сделано рациональное предположение (предпринимательская гипотеза), затем (логически, в реальном времени там сложные отношения) предложена концепция использования, затем такая концепция целевой системы (хотя бы на уровне идеи), которая могла бы удовлетворить концепции использования, затем можно попробовать такую систему сделать (что не факт, что просто), затем продать — и если это удалось, то гипотеза подтверждается, а если нет — не подтверждается (хотя даже тут не всё остаётся понятным: может быть, проблема в ценообразовании, а может — просто плохо продавали, умели сделать, но не умели продать).

Коммерческая возможность проекта увязывает два неизвестных вероятностных (предпринимательские гипотезы вероятностны!) описания двух разных систем (надсистема с концепцией использования и целевая с концепцией системы) и исключает разные неприемлемые варианты типа запроса на скатерть-самобранку (легко предложить концепцию использования, нелегко предложить конструкцию системы) или дешёвый («чтобы был не дороже билета на самолёт, иначе наш маркетинговый отдел возражает!») пассажирский транспорт на Марс. Это исключает и вариант «вот наши инженеры сделали Глюклу, она очень хитро устроена и хорошо издаёт забавные звуки (глюкает), когда крутится в воде, теперь мы не знаем, куда бы её приткнуть — где бы мог пригодиться такой сервис? Никто не знает, где нужна такая функция?».

Конечно, при этом нужно учитывать минимальное число видов описаний как в концепции использования для надсистемы как прозрачного ящика (функциональное, конструктивное, размещения/компоновка, стоимостное).

А ещё не надо считать, что в концепциях использования и системы можно писать банальности, которые всем известны — типа «интерес в том, чтобы система была дешёвой». Это проверяется путём подстановки слова «обувь» вместо названия системы. Скажем, написано «глюкла должна быть дешёвой» — «обувь должна быть дешёвой». Хорошо звучит, никакого онтологического дребезга. Значит, мы сказали какую-то общеизвестную истину, которую можно и не говорить, «спасибо, Кэп»²⁸⁷.

В любом случае, повторим ещё раз (ибо все инженеры-менеджеры по десять раз задают этот вопрос): алгоритма выдвижения предпринимательской гипотезы как идеи проекта нет, это сугубо творческий акт, никаких чётких последовательностей шагов, гарантированно ведущих к успеху! Это «поиск аффордансов в нише», как говорят вслед за биологами специалисты по дизайну. Affordance тут один из синонимов к opportunity, по-русски это всё будет «возможности»²⁸⁸.

Альфа коммерческой возможности (opportunity/«возможно делать», не путать с possibility/«вероятно/возможно существование») ведения проекта нужна для отслеживания в ходе проекта по созданию и развитию (или даже просто какому-то изменению уже имеющейся, brownfield) целевой системы как формулирования этой возможности (и затем визионер как шумпетеровский предприниматель говорит: «да, моя оценка — будет выгодно, работаем»), так и последующего отслеживания, что возможность не исчезла по ходу проекта (при этом система может развиваться, возможность ведения проекта необязательно исчезает с выпуском первой версии). Проект возможен, только когда:

• его целевая система будет кому-то нужна, и за неё смогут платить — есть потребность, неудовлетворимая без целевой системы, и за неё готовы платить (сегодня это обычно означает не только «заплатить» однократно, но и «платить» за развитие),

• её какое-то оргзвено (один человек, коллектив, предприятие, производственная кооперация) может сделать и дальше развивать не себе в убыток.

Можно возразить, что не все проекты связаны с какими-то коммерческими возможностями (скажем, часто в пример приводят политические проекты). Нет, это не так. Если денег на пропитание команды нет, то команда не будет работать, займётся чем-то другим, чтобы её члены могли банально выжить. Если же люди работают, не требуя оплаты, да ещё и оплачивают работу своего оборудования (включая компьютеры и связь), то это просто означает, что они сами в двух ролях: члены организации/команды/коллектива проекта, а ещё и во внешних проектных ролях — пользователей, заказчиков, плательщиков. Разговор ведь функциональный, про роли, а не про конкретных агентов (неважно, эти агенты люди или даже целые предприятия).

В «некоммерческих проектах» придётся всё равно оценивать их выполнимость: понимать, какая там будет конструкция, определять методы разработки, планировать, для чего определять потребность в ресурсах, так или иначе определять ту самую «коммерческую/ресурсную/бизнес возможность». И тут нужно не ошибаться: например, если вы помогаете голодным в Африке, то заказчики::«внешние проектные роли» тут спонсоры/благотворители, а выпускать будете сытых/бенефициаров::«целевая система»! Заказчики не сами голодные, а те, кто платит за их сытость! Голодные тут бенефициары, а не заказчики благотворительности! И если благотворителей нет, а голодных много, то «нет коммерческой возможности вести проект», накормить никого не удастся, проект невозможен.

Нужно быть очень внимательным при обсуждении альфы коммерческой возможности в «некоммерческих проектах»! Там часто очень контринтуитивные рассуждения. Если вы, например, хотите затеять небольшую войну как проект, то какие-то люди могут посчитать, что у них от вашего проекта будет не прибыль, а убыток, и будут готовы заплатить деньгами, другими ресурсами, собственным трудом за то, чтобы помешать вашему проекту: и «маленькая победоносная война» закончится крахом по ресурсным соображениям. Это неважно, речь идёт о горячей войне, холодной войне или торговой войне. Альфа «коммерческая возможность» говорит о том, быть проекту или не быть, о ней нельзя забывать в ходе всего проекта (как и обо всех остальных). И помним, что её нужно отслеживать всё время проекта: системы не только создаются в их первой версии как MVP, но и постоянно развиваются, участвуют в техноэволюции.

Альфой коммерческой возможности занимаются главным образом (это подробней обсуждается в руководстве по системному менеджменту в в разделе про орг-стратегирование):

• Визионер в команде инженеров целевой системы — он отслеживает, что коммерческая возможность не ускользает, оценивает будущее: даёт оценку, что развитие системы даёт возможность получать деньги от продажи продукта или работ какого-то сервиса.

• Бизнесмен в команде менеджеров — он отслеживает, что реализация этой коммерческой возможности не приведёт к уменьшению стоимости фирмы (например, проект может не соответствовать стратегии фирмы, инвесторы могут посчитать, что фирма уменьшит свою стоимость в силу репутационных рисков и т.д.).

Альфа коммерческой возможности — важная альфа (если заведомо нет ресурсов на проект — команда не должна его делать, даже если очень хочется), как и все альфы, она меняет свои состояния (в том числе и откатывается по состояниям назад!) в ходе всего проекта. Инженеры целевой системы и даже менеджеры часто забывают об этой альфе сразу после заключения контракта: «приходите через полтора года, когда система будет готова». Часто это ещё и контракт на изготовление одной версии системы, да ещё и на базе устаревшей идеи «требований». Такая забывчивость — часто фатальная для проекта ошибка. Возможность выполнения проекта успевает исчезнуть прямо во время выполнения проекта. Нет ведь «требований», есть «гипотезы» по поводу как надсистемы, отражённые в концепции использования, так и системы, отражённые в концепции системы и архитектуре системы, а ещё есть непрерывно и быстро изменяющийся мир с его многочисленными привходящими обстоятельствами. Если возможность проекта исчезла, а организация проекта продолжает тратить ресурсы на создание целевой системы, создание этой системы не окупится, некому будет за эту систему заплатить.

Это одна из самых сложных альф, она отражает взаимоувязанность решений самых разных проектных ролей, и внутренних, и внешних. И она существенно привязана ко времени: каждый день меняется ситуация на рынке, и каждый день меняется ситуация в разработке. Поэтому оценивать состояние альфы нужно часто, а мониторить её состояние нужно в ходе всего проекта, а не только при заключении контракта.

Альфа коммерческой возможности в ходе проекта проходит следующие состояния (достижение которых можно считать milestones, «контрольными точками» для управления проектами), но их нужно понимать не только как контрольные точки в выпуске только первой версии системы (чаще всего это MPV, minimal viable product, минимальный жизнеспособный продукт), но и инкрементов в улучшениях — каких-то новых фич системы, каких-то модернизаций самой системы, улучшающих её способность удовлетворить потребности, быть аффордансом в нише, которой занимаются внешние проектные роли²⁸⁹:

• Выявлена (identified): найдена идея; найден как минимум один исполнитель проектной роли, желающий сделать инвестицию в понимание коммерческой возможности; определены другие проектные роли.

• Нужно решение (solution needed): установлены потребности; определены проблемы и их причины, имеется концепция использования, целевая система/solution одобряется внешними проектными ролями как нужная, был предложен как минимум один вариант концепции системы, одобряемый внутренними проектными ролями.

• Польза установлена (value established): польза²⁹⁰ от реализации проекта была определена количественно; влияние решения/solution/целевой системы на внешние проектные роли понятно; польза системы внешними проектными ролями понимается; критерии успешности ясны; результаты ясны и выражены количественно.

• Жизнеспособна (viable): целевая система возможна с учётом всех известных ограничений; риски приемлемы и управляемы; проект выгоден; причины для создания целевой системы (или её инкремента/фичи/модернизации) понимаются; ясно, что проект как реализация коммерческой возможности жизнеспособен.

• Реализована (addressed): коммерческая возможность реализована; целевая система введена в эксплуатацию; внешние проектные роли удовлетворены;

• Извлекается выгода (benefit accrued): проект создания целевой системы принёс выгоду; возврат на инвестиции приемлем.

Нужно работать какими-то методами, чтобы альфа возможности двигалась по своим состояниям. Достижение каждого состояния альфы «возможности» проверяется прохождением вышеупомянутого чеклиста, и свидетельствуется какими-то артефактами/рабочими продуктами. Например, состояние описаний свидетельствуется документами тех или иных моделей надсистемы, целевой системы и систем в цепочках создания. Состояний альф может свидетельствоваться в простых случаях и просто отметками в чеклисте, если мы верим, что поставивший эти отметки лично убедился в достижении требуемого чеклистом состояния. В нашем руководстве мы не будем подробно рассматривать методы этой работы, это предмет системной инженерии и системного менеджмента, по этим методам работы у нас отдельные руководства.

Сама себя альфа коммерческой возможности не двигает, возможность бизнеса сама себя не выявляет, «инициативы» по проекту сами по себе не ведут к коммерческому успеху. «Безумные изобретатели» предпринимают безумные проекты, но эти проекты часто не ведут к выгоде — там нет планомерной работы с альфой коммерческой возможности, нет разговора о методах этой работы!

Альфа коммерческой возможности весьма медленно переходит в состояние «извлекается выгода», часто это занимает несколько лет. Для этого нужна упорная работа команды проекта, в том числе с альфой возможности работают и фундаментальные методы мышления интеллект-стека (физика, онтология, рациональность, исследования, этика, риторика, методология, системная инженерия в числе них), а также понимание того, что надо будет проект как-то организационно оформлять (системный менеджмент).

Состояние альфы коммерческой возможности может характеризоваться самыми разными документами: «бизнес-планом», «концепцией», «обоснованием инвестиций/инвестиционным меморандумом», «бюджетом проекта», «рыночным исследованием», «проектным предложением» и т.п. Эти документы в свою очередь отражают состояние «концепции использования», «концепции системы», различных моделей, которые разрабатываются в ходе орг-стратегирования (в руководстве по системному менеджменту подробно разбираются три такие модели — бизнес-модель, модель оргразвития и модель целеполагания). Так что альфа коммерческой возможности может иметь в качестве своих подальф самые разные подальфы самых разных других альф.

Коммерческая возможность выполнить проект — это альфа, имеющая дело с наименее алгоритмизируемыми методами: «предпринимательством по Шумпетеру» как предсказанием будущего, изобретательством и прочим творчеством. Повторим, что методы перевода этой альфы по её состояниям обычно опираются не на прикладное, а на фундаментальное мышление «из первых принципов», ибо требуют решения проблем, которые раньше не встречались, и очень часто — в предметных областях, которых ещё нет (если компания первой выходит на рынок в надежде его захватить раньше, чем придут конкуренты). Прежде всего методы работы для продвижения состояний этой альфой связаны со способностью предугадать будущее, а это делается на основе хороших представлений об устройстве мира. В частности, наши руководства для инженеров-менеджеров дают ровно такую модель, мета-мета-модель мира.

Альфа внешних проектных ролей

Альфа внешних проектных ролей (stakeholders) говорит о ролях, для которых целевые системы их проекта — надсистемы нашей целевой системы, так что эта альфа в области интересов надсистем. И ещё мы относим её главным образом ко времени продвижения (работы маркетинга, рекламы, продажи), ибо важнейшие внешние проектные роли — это относящиеся к пользователям/бенефициарам, будущим владельцам, плательщикам и прочим ролям (иногда собирательно называемых «клиентом»), которые должны согласиться профинансировать создание и развитие целевой системы, а затем её использовать. Это очень условное отнесение, ибо внешние проектные роли могут быть самые разные (например, всевозможные надзоры — роли, проверяющие соответствие работ всех систем графа создателей, включая целевую систему, какому-то разделу законодательства).

Команда (внутренние проектные роли) представлена отдельной альфой. Термин «stakeholder» имеет два значения:

• собственно роль (функциональный объект, называется по методу работы)

• агент, играющий роль (конструктивный объект, оргзвено, называется по его имени).

Будьте осторожными, чтобы не перепутать роль и исполнителя роли: не надо путать потребности принца Гамлета с потребностями Васи Пупкина, который сегодня играет роль принца Гамлета (в речи они оба могут быть «стейкхолдер», поэтому лучше используйте «внешнюю проектную роль» для обсуждения потребностей).

Внешние проектные роли дают возможность (следим за типами: это была только что упомянута альфа::тип коммерческой возможности!) выполнения проекта, они его оплачивают или запрещают (скажем, внешняя проектная роль «регулятор», «надзор», «инспектор»). Успешность целевой системы (следим за типами: это была упомянута альфа воплощения целевой системы!) определяется именно внешними проектными ролями, ибо целевая система — это та, в которой соблюдены их ролевые интересы/предпочтения.

Проектные роли (и внешние, и внутренние) могут играться группами исполнителей (например, 30 тыс. пользователей программного приложения, которые появились от 30 тыс. розничных продаж, или 1 тыс. зрителей спортивного поединка на каком-то стадионе), некоторые группы исполнителей ролей могут быть вообще недоступны (скажем, хакеры), поэтому каждая из групп может быть представлена/represented каким-то «образцом проектной роли», или даже членом команды (например, отвечающим за продвижение/маркетинг), ответственным за представление разнообразных интересов внешних ролей и отстаивание их удовлетворения как перед командой, так и перед другими внешними проектными ролями (ибо внешние проектные роли легко могут конфликтовать между собой в своих потребностях — клиент самоката, скажем, хочет «ездить побыстрее», а надзор для тех же самокатов хочет — «скорость должна быть ограничена»).

Хорошей практикой является сразу разделение альфы «внешние проектные роли» на отдельные подальфы индивидуальных проектных ролей и раздельный учёт состояния каждой из этих подальф. И обычно этих подальф сразу от пятнадцати, а не от трёх или пяти! Помним: в любой момент проекта число внешних проектных ролей на единицу больше числа выявленных проектных ролей — и вот эта единица будет неиссякаемым источником сюрпризов.

Вот состояния с контрольными вопросами для определения их достижения для внешних проектных ролей (и помним, что речь может идти или о свежесозданном MVP, или какой-то версии/инкременте системы, или даже об отдельной фиче в составе системы):

• Признаны (recognized): внешние проектные роли выявлены; ключевые из них представлены; ответственности представителей/исполнителей проектных ролей определены.

• Представлены (represented): исполнители внешних проектных ролей согласились с ответственностью; представители каких-то оргзвеньев получили полномочия; подход к сотрудничеству согласован; инженерный процесс поддерживается и уважается.

• Вовлечены (involved): представители/исполнители внешних проектных ролей помогают команде; реагирование представителей на запросы своевременно, и они предлагают решения; изменения сообщаются вовремя.

• В согласии (in agreement): минимальные ожидания/предпочтения согласованы; представители/исполнители внешних проектных ролей довольны своим вовлечением; вклад внешних проектных ролей приносит пользу проекту; приоритеты ясны; перспективы команды и внешних проектных ролей сбалансированы.

• Удовлетворены для разворачивания (satisfied for deployment): имеется отклик/feedback от внешних проектных ролей; система готова для разворачивания в месте её эксплуатации.

• Удовлетворены в использовании (satisfied in use): отклик/feedback по использованию/эксплуатации системы доступен; система отвечает ожиданиям/предпочтениям.

Проектные роли в силу 4D экстенсионализма совпадают с актёрами (конкретными оргзвеньями, которые исполняют эти роли) в тот момент, когда они играются. Проектные роли не существуют, когда их никто не отыгрывает. Если какая-то проектная роль (в том числе внешняя) в проекте нужна, но отсутствует, то надо найти исполнителя этой роли. Продвижение именно этим и занято для клиентуры: находит исполнителей составной роли клиента (помним, что «клиент» или «заказчик» — это обычно большое обобщение, ибо платят одни, владеют другие, используют третьи, принимают решение о покупке четвёртые, и это ещё не весь список).

Люди-актёры могут играть в проекте несколько ролей, и несколько человек могут играть одну роль. Ведущая практика, которая катализирует сотрудничество актёров в ходе качественного отыгрывания ими своих ролей — лидерство. Люди в команде должны выполнять лидерство не только для налаживания сотрудничества внутри команды (и команды из одного человека — себя, «организовывать себя», «быть лидером самого себя», «сотрудничать/дружить с собой», а ещё команды из многих людей, и даже команды из многих больших оргзвеньев-предприятий) но и с необходимыми представителями/исполнителями внешних проектных ролей, чтобы играющие эти роли внешние по отношению к команде люди были вовлечены в проект и оказывали содействие в продвижении всех альф проекта по их состояниям.

При документировании внешних проектных ролей хорошая идея — использовать табличку из руководства по системному мышлению, эта табличка приводилась в тот момент, когда мы рассказывали о ролях. Напомним её:

А ещё внешние проектные роли берут не только по отношению к надсистемам целевой системы, но и по отношению к системам создателей в их графе, причём иногда они будут довольно далеки по этому графу от целевой системы. Команде в каком-то месте графа создателей всё равно, речь идёт о надсистеме целевой системы или любой другой команде любой другой системы в графе создателей: «не члены нашей команды, а взаимодействовать надо» — всё, эти роли попали во «внешние проектные роли», проектирование ведь обычно ведётся не абстрактное, а в рамках работы какой-то команды. И если CEO считает все 8 тысяч человек какого-то холдинга «нашей командой», то команда какого-то небольшого проекта на пять человек в этом холдинге посчитает роли этого CEO совсем внешними (если вообще учтёт).

Альфа системы

Альфа системы (иногда для акцентирования физичности, «вещности», материальности — альфа воплощения системы) весьма разнообразна: состояния воплощения системы будут абсолютно разные для атомной электростанции, мобильного приложения, стартапа, магазинной доставки, игрового сеанса, лесопосадок, гражданского общества, танцевального перформанса, гончарной мастерской, сталелитейного завода.

Вот пример очень общего списка состояний (определяемых событиями достижения их контрольных точек, отражённых в контрольных вопросах чеклиста) для «железной» системы в заказной разработке. Его нужно тщательно адаптировать для каждого отдельного вида систем, и даже для разных видов «железных систем» в разных вариантах инженерного процесса заказной разработки. «Железная» система (или её версии, или инкременты, фичи, опции — «непрерывное всё») при заказной разработке может проходить следующие состояния:

• В виде модели (as a model): «рабочка» (описание с точностью, достаточной для изготовления) готово для изготовления; BoM (bill of materials, сводно-заказная спецификация) готова для закупок, технология изготовления с инженерами внутренней платформы разработки согласована.

• В виде сырья (as a raw material): материалы для воплощения системы наличествуют и позволяют создать части системы с нужными характеристиками; оборудование для переработки материалов в детали наличествует; график производства и логистики частей системы согласован; возможны работы по изготовлению частей системы.

• В виде частей (as parts): части воплощения системы созданы и/или закуплены и проверены; график интеграции/сборки/монтажа/строительства из частей согласован; возможны работы по интеграции/сборке/монтажу/строительству.

• Демонстрируемо (demonstrable): воплощение системы может быть опробовано в отдельных функциях и ключевые характеристики могут быть измерены; ключевые характеристики могут быть продемонстрированы внешним проектным ролям; критические интерфейсы системы к окружению были продемонстрированы; система готова к испытаниям в порядке инженерного обоснования успешности; необходимые внешние проектные роли согласны, что систему нужно испытывать.

• Готово (ready): функциональность испытана; уровни дефектов для внешних проектных ролей приемлемы; установочная и другая пользовательская и операторская документация доступна; представители/исполнители внешних проектных ролей удовлетворены системой; состав/конфигурация передаваемой системы известен; представители/исполнители внешних проектных ролей готовы эксплуатировать систему; эксплуатационная поддержка создателей наличествует; операторы и пользователи наличествуют; системное/рабочее окружение для критических интерфейсов готово.

• Эксплуатируется (operational): доступна внешним проектным ролям для эксплуатации/использования в рабочем окружении; есть как минимум один пример работающей системы (при серийном выпуске); поддерживается на согласованном уровне сервиса обслуживания.

• Выведено из эксплуатации (retired): Воплощение целевой системы было заменено или прекращено в использовании; система больше не поддерживается; нет «официальных» внешних проектных ролей, которые до сих пор используют систему; доработки/доделки системы больше не будут производиться; все материальные компоненты системы либо повторно используются, либо надлежащим образом уничтожены.

Удивительно, но у многих людей при обсуждении воплощения системы так мысль и не доходит до физической реальности, всё остаётся в виде описаний (типичная ошибка: «целевой системой нашего проекта является аналитический отчёт», а ведь отчёт — это описание!). Напомним, что это проявление симпатической магии: убеждение в том, что для изменений в физическом мире достаточно изменить описание (скажем, колоть булавкой или целовать модель человека — куклу Вуду, надеясь, что с описанным этой куклой человеком произойдёт что-то плохое или хорошее. Изменить строчку программного кода ERP-системы, игнорируя, как это повлияет на планирование потоков ресурсов в предприятии — это проявление того же мышления, «симпатическая магия»)²⁹¹.

Если ваше воплощение системы не находится в материальном мире, вы не можете для вашей системы указать место в пространстве в какие-то моменты во времени, то велика вероятность, что у вас фантазийный проект. Если его сделать, то ничего в физическом мире не изменится. Ну вот и не делайте, бросьте его, ничего ведь в мире не изменится!

Убедитесь, что в вашем проекте воплощение системы в конечном итоге физично! «В конечном итоге» — это, возможно, уже не в рамках вашего проекта, а позже, в ходе выполнения какого-то другого проекта другой командой, но вы должны понимать, что ваша работа направлена на изменения в физическом мире, в поддержку этих изменений, а проводится не сама по себе. И после этого понимания — действовать, не считать, что ваша работа заканчивается там, где вы выдали какое-то описание. Нет, вам надо проследить, что это описание реально повлияло на то, чтобы появилась успешная система. Думать «потом пусть пришлют замечания, если что-то не понравится» — это неправильно, контрпродуктивно. Если завод выпустил неработающий станок, ресторан кормит вас несъедобным борщом, то вряд ли им за такое надо платить. За выпуск описаний надо платить только тогда, когда эти описания тоже привели к чему-то успешно работающему в физическом мире, тут та же логика.

Ваша работа должна быть рациональна, то есть вы должны привести причинно-следственное (контрфактическое) рассуждение о том, каким образом ваша работа поддерживает изменение физического мира (создание и/или развитие какой-то системы::«физический объект»). Нерациональные работы лучше не делать, нерационально (без понимания причинно-следственных связей с выпуском успешной системы) устроенные проекты лучше закрывать сразу, платить деньги за выполнение таких проектов неэтично, получать деньги за выполнение работ в таких проектах — неэтично.

Когда вы обсуждаете альфу воплощения целевой системы, обращайте внимание и на создателей. Описания самой системы могут быть хороши, но изготовить вы её не сможете: инженерная команда приготовила описания, не заботясь о том, как система будет изготавливаться, не продумали, как система будет появляться в физическом мире. Обычно неудача с производством возникает тогда, когда в команде отсутствует технолог или аналогичная роль для «нежелезных» систем. Потом оказывается, что нет таких станочков для «железа», непонятно как учить для образовательных проектов, нет нужной вычислительной мощности в компьютерах для проектов программной инженерии и т.д.

Если ваш предмет интереса только в описании системы, не забывайте, что это описание нужно только постольку, поскольку система будет воплощена в физическом мире, займёт там место в пространстве-времени. Отслеживайте альфу воплощения системы в ходе всего проекта, с самого его начала, а не только в момент, когда нужно начинать воплощение! И ещё не забудьте: воплощение системы эксплуатируется/используется, всё делается для этого состояния (а не для состояния в момент окончания изготовления или в момент продажи. Воплощение самолёта в рабочем состоянии летит высоко в небе, перевозит грузы и пассажиров, зарабатывает деньги для авиакомпании, а не «готово» или даже «отгружено для использования»!).

Альфой системы в графе создателей может быть альфа организации проекта, для краткости мы назовём эту организацию «командой», хотя это может быть один человек, небольшая команда, «которую можно накормить двумя большими пиццами»²⁹², коллектив из нескольких команд, большое предприятие, кооперация/«расширенное предприятие»/«extended enterprise» из нескольких предприятий. Вот состояния, по которым можно отслеживать изменения альфы «команда» (тут состояния для небольшой команды, для большой организации из многих команд придётся неминуемо всё адаптировать, всё переписать по-другому — и памятуем, что оргизменения в ходе постоянного развития тут по факту опущены, каждое из них требует создания отдельной подальфы или использования текущей альфы для каждой новой создаваемой оргвозможности):

• Намечена (seeded): стратегия (функция) команды в ближайшей надсистеме (организации, бизнес эко-системе) определена и роль команды тем самым известна; ограничения и их причины известны и явны; механизмы роста и развития команды наличествуют; инженерный процесс в общих чертах известен и тем самым состав внутренних ролей в команде определён; обязанности команды по отношению к надсистемам обрисованы в общих чертах; уровень принятых командой обязательств ясен; требуемый уровень мастерства определён; размер команды определён; методы надзора за деятельностью определены; вид/форма оргзвена (подразделение, рабочая группа проекта, иное) выбрана.

• Сформирована (formed): Было набрано достаточное число членов команды; роли в команде понимаются её членами; все понимают инженерный процесс; члены команды узнают друг друга при встрече; члены команды понимают индивидуальные обязанности и как они увязаны с их мастерством; члены команды принимают результаты работ друг друга и смежников; внешние смежники (организации, команды и отдельные люди) определены; механизмы общения и удержания коллективной собранности в команде определены; каждый член команды принял обязательство работать так, как это принято в команде; технологии развёрнуты; ресурсы для работы выделены, полномочия получены.

• Сотрудничает (collaborating): команда работает как одно сплочённое оргзвено (распределённое лидерство); общение в команде открытое и честное; команда сфокусирована на реализацию стратегии (миссии/задания) команды; члены команды знают друг друга и сотрудничают.

• Производит (performing): команда постоянно выполняет обязательства; команда непрерывно адаптируется к изменяющемуся контексту; команда определяет и решает проблемы без внешней помощи; минимум возвращений к сделанному и переделок; работа команды рациональна и элегантна: работа впустую (waste) и причины для работы впустую постоянно устраняются.

• Распущена (adjourned): стратегия была реализована; обязанности были выполнены; члены команды доступны для участия в других командах.

Обращайте внимание на смысл, а не терминологию. Так, для первого состояния «железной» системы была выбрана формулировка «в виде модели», но это же состояние для команды названо «намечена» (термин взят из примера альфы team в OMG Essence). Можно было бы назвать это состояние «в виде оргмодели», по образу и подобию «железной системы», можно взять более подходящее для вашей ситуации имя состояния. Всегда адаптируйте материал наших руководств для использования в вашем проекте!

Подальфы для команды, конечно, это описания ролей членов команды, поэтому хорошая тут идея — использовать табличку для описания ролей из руководства по системному мышлению и наборы типовых проектных ролей из руководств по системной инженерии, инженерии личности, системному менеджменту или какой-то аналогичный набор культурно-обусловленных ролей для инженерного процесса в вашей предметной области.

Не забудьте проверить, есть ли у членов команды (оргзвеньев, исполнителей ролей — конструктивов для ролей) мастерство в методах работы, которые будут указаны в альфе «метод». Если инженерный процесс требует такого метода работы, как «программирование на Julia», а у вас в команде на исполнение таких работ назначен мастер в операционном менеджменте, который говорит, «ОК, я займусь, заодно научусь программировать», то в этом проекте не ждите успеха.

Проверьте, где в вашей оргмодели можно найти ответы на вопросы, нужные для определения состояния альфы «команда». Например, «общение в команде открытое и честное» — это же нельзя вывести из оргмодели, данной как список фамилий, расписанный по их должностям? Если открытость и честность в команде как-то не документированы, они останутся невидимы, и тогда не будут запланированы работы по каким-то методам лидерства, а не будет лидерства, то и ситуация с общением в проекте может оказаться плохой и нервной, и об этом мало кто будет думать как о чём-то, что надо поправить лидерской работой, а не просто сетованиями на «плохую атмосферу». Чеклист как раз для того, чтобы про такую работу не забывали!

Работать в банке с пауками мало кто хочет, мало кому так работать приятно. На проекте это скажется не лучшим образом: в подобных ситуациях часто людей «подставляют» (делают так, чтобы какой-то кусок проекта провалился, и было известно, по чьей вине). Вам надо, чтобы какой-то кусок проекта провалился, даже если будет известно, по чьей вине?! Альфа «команда проекта» заставит обратить внимание на эту ситуацию, заставит запланировать работы для решения этой проблемы.

Системное мышление, методология — это фундаментальные методы мышления, обращающие внимание на важное. Альфы — это и есть самое важное в проекте, что вы должны интенсивно менять в ходе всего проекта, их изменения надо согласовывать в масштабах команды проекта и непрерывно отслеживать в течение всего проекта. Их нельзя упускать из виду, о них нельзя забывать, поэтому не надейтесь на ненадёжный и забывчивый человеческий мозг, используйте чеклисты для альф в каком-то операционном софте.

Альфа описания системы

Описание системы, наряду с воплощением системы, относится к области интересов какой-то системы в графе создателей. Описанием системы (продвижением этой альфы по её состояниям) занимаются инженеры создателя этой системы. Если целевая система, то это какие-то прикладные инженеры — «железные» инженеры, врачи, учителя, всех их мы рассматриваем как инженеров. Но, если речь идёт о какой-то системе в цепочке создания, то там будут инженеры предприятия, то есть менеджеры, но это может оказаться и «станок» или «софт», и тогда мы опять возвращаемся к прикладным инженерам во всём их предметном разнообразии.

Как самостоятельная, альфа описания системы осмыслена только в самых общих разговорах по проекту. Для реального отслеживания дел с описанием системы нужно сразу разбивать её на подальфы (концепция использования, концепция системы, архитектура, «рабочка» как проект/design с детальностью, достаточной для изготовления и ещё много самых разных моделей).

Для разных типов систем подальфы описания системы называются по-разному. Например, что для информационных и «железных» систем «архитектурные решения», для предприятия они же могут называться «орг-архитектурные решения», а для спортивного события они будут называться «правилами». Это общее для всех альф и подальф: названия альф и подальф, а также названия их состояний и формулировки контрольных вопросов надо не брать прямо из нашего руководства, а обязательно адаптировать, называть понятно для использующих итоговые чеклисты сотрудников.

Состояние альфы описания системы свидетельствуется проектной документацией (которая может быть в базах данных инженерного и менеджерского софта, о бумаге давно забыли), описание ставится под управление конфигурацией: описано обычно несколько вариантов системы, в реализацию идёт или один из них, или даже несколько (скажем, в продуктовых семействах или при A|B тестировании).

Вот очень обобщённый пример набора состояний альфы описания для «железной» системы. И для «железной» системы из вашего проекта, и для других видов систем (скажем, вы занимаетесь менеджментом, или политикой, или разведением редких видов жуков, или обучением людей) рекомендуется адаптировать эти состояния, контрольные вопросы. И ещё не забудьте выбрать те синонимы, которые понятны вашим сотрудникам. Как обычно, мы нейтральный к размеру термин «организация проекта» заменяем привычным «команда проекта» или просто «команда», но это легко может быть и «проектная кооперация по поводу строительства атомной электростанции» с тысячами «команд» в огромном графе создателей.

Речь может идти не только о создании всего описания для впервые создаваемого MVP системы, но и об описании инкремента/модернизации или какой-то отдельной фичи системы. Вы можете использовать подобный чеклист и не для полного описания, а для какого-то частного, лучше бы сразу работать с подальфами, но альфа описания системы нужна, чтобы был пункт чеклиста, где вы задумаетесь, какие там вообще описания есть, какие нужны подальфы для отслеживания состояния отдельных частных описаний/views.

Описание системы (или её инкремента, фичи, опции) может иметь состояния:

• Замыслено (conceived): внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования частных описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.

• Непротиворечиво (coherent): частные описания системы документированы; документация доступна команде и внешним проектным ролям; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система ожидается как успешная (в ней учтены интересы внешних проектных ролей).

• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний системы хватает для начала изготовления/производства; методы/технологии изготовления по этим описаниям системы сами описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.

• Используется для инженерных обоснований воплощения (in use for assurance): есть все описания, нужные для инженерного обоснования успешности системы (assurance case); испытания/тесты, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний/тестов.

• Используется для эксплуатации (in use for operations): описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации/развитии системы.

• Используется для вывода из эксплуатации (in use for retirement): используется для определения момента вывода из эксплуатации или принятия решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

Повторим: приведённые выше состояния альфы описания целевой системы являются настолько общими, что для реального проекта должны быть обязательно конкретизированы — и в части терминологии и самих состояний, принятых для описания системы, но также и в части подальф.

Вот как могла бы выглядеть альфа описания организации в графе создателей. Неважно, инженерная ли это организация, которая занимается целевой системой или её частью, или организация, которая занимается чем-то другим (скажем, продвижением — создаёт клиентуру). Заодно заменим слово «описание» на «модель». Получение описаний организации часто называют организационным моделированием, а само описание — оргмоделью. Соответственно будут называться и альфа, и её состояния. Предполагается, что оргмоделированием занимается организация-создатель моделируемой организации, «служба оргразвития», которая занимается «оргразвитием»::метод какой-то команды проекта. Помним, что когда мы пишем «создание», то это полностью в условиях победы идеи «непрерывное всё» будет «создание и развитие».

Оргмодель (или её инкремент для оргизменения) может иметь состояния:

• Замыслена (conceived): служба оргразвития согласна, что организация проекта будет создана; методы моделирования организации проекта согласованы; способ согласования оргмодели с внешними проектными ролями службы оргразвития согласован; механизмы управления конфигурацией оргмодели согласованы.

• Непротиворечива (coherent): оргмодель документирована, документация доступна службе оргразвития и команде проекта; происхождение оргмодели ясно; оргмодель проверяется; противоречия в оргмодели выявлены и ими занимаются; служба оргразвития понимает оргмодель и соглашается её воплотить; соответствующая оргмодели организация проекта принимается службой оргразвития как заслуживающая воплощения.

• Используется для лидерства (in use for leadership): служба оргразвития считает, что оргмодели хватает для начала создания организации проекта; методы оргразвития по этой оргмодели сами отмоделированы и документированы; возникающие при организации команды проекта проблемы приводят к доработке и актуализации оргмодели.

• Используется для работы (in use for operations): оргмодель используется для сбора операционной информации о состоянии проекта (цифровой двойник, digital twin); оргмодель наряду с операционной информацией цифрового двойника используется для принятия решений о совершенствовании (непрерывных улучшениях) и развитии.

• Используется для роспуска команды проекта (in use for adjourn): оргмодель используется для определения момента роспуска команды проекта или принятии решения о продолжении работы; демонстрирует отсутствие вредных эффектов (например, выполнение каких-то сервисов, до сих пор нужных для внешних по отношению к команде проекта оргзвеньев предприятия) при роспуске команды проекта; используется для планирования и проведения работ по роспуску или перепрофилированию.

Мы привели тут в подразделе лишь пример альфы для целевой «железной» системы и для организации проекта, но систем много и в графе создателей, и в окружении каждого из создателей в их графе. Методология говорит о прохождении альфой описания системы и её подальфами всех запланированных состояний в ходе проекта, и это описание/моделирование нужно создавать по каким-то методам описания/viewpoints с их дисциплинами/теориями и инструментарием (прежде всего — самыми разными моделерами). Всё, что в руководствах по рациональной работе и системному мышлению было сказано про описания и моделирование, в том числе системное моделирование — всё это надо использовать как методы работы с альфой описания системы.

Если в вашей концепции системы (подальфа описания системы) нет функциональных описаний системы как «прозрачного ящика», а только перечисляется набор конструктивных частей системы и говорится, где они размещены, то проекту счастья не будет, а будут одни несчастья. К оргсистемам (организациям, командам, коллективам, предприятиям) это тоже относится, если в концепции организации ничего нет про оргроли, но всё только про оргзвенья и полномочия их руководителей (органиграмма), хотя даже и будет ещё указано, где они расположены (размещение) — тоже счастья такому проекту развития организации не будет. Оргсистема — это ведь просто частный случай системы.

Инженеры-менеджеры, у которых альфа описания системы не учитывает того, что писалось в руководстве по системному мышлению о минимально необходимых разбиениях, которые должны быть описаны (функциональное, конструктивное, размещения, стоимостное — и это минимум!), у которых перемешаны описания разных систем (например, приведено конструктивное описание целевой системы, и функциональное нашей системы, которая находится где-нибудь среди графа создателей — да так, что невозможно разобраться, какое описание какую систему описывает), у которых явные конфигурационные коллизии (например, даны два списка функциональных частей какой-то системы, даже не целевой, и в этих списках разное число частей без указания причин расхождения) — все такие инженеры-менеджеры получат два балла при сдаче экзамена, неважно в вузе этот экзамен или в жизни на работе. В жизни просто увольняют с работы или переводят на менее квалифицированную работу, а иногда ещё и сильно штрафуют за такие ошибки.

Системное мышление — это управление вниманием, и чтобы не терять внимание своё и коллектива, нужно использовать современную практику собранности: наводить внимание понятийно (использовать типы моделей высоких мета-уровней для выделения объектов из фона) и затем удерживать это внимание долго, используя не мозг, а внешние носители информации — прежде всего компьютерные моделеры.

В инженерных проектах это ещё и коллективное системное мышление, поддерживаемое коллективной собранностью. Если не знаешь, как описывать самое важное в системах (целевых, создателях, подсистемах, системах в окружении и т.д.) и их поведении, эти описания надёжно документировать — всё плохо, внимание и личное, и коллективное рассеяно, ждите проблемы.

Если несобранные сотрудники с рассеянным бессистемным вниманием, которое не отслеживает важное, а отслеживает только знакомое по предыдущему «опыту работы», оказываются в успешном рабочем проекте, они начинают приносить этому проекту несчастья: за ними тянется тяжёлый след конфигурационных коллизий, они являются причиной множества переделок/re-work, причиной нерациональной работы.

Можно будет посочувствовать инвесторам: у проекта с такими внимательными к неважному и невнимательностью к важному сотрудниками большие риски, и мало кто будет понимать, почему всё так плохо, все ведь упорно работают! А плохо в проектах бывает главным образом из-за невнимания к важному, путанного внимания, то есть бессистемности, несобранности, непрактичности и огромного количества работы, которая нерациональна. Надо не просто много и упорно работать, но много и упорно работать именно над важными объектами, а не над теми, о которых случайно вспомнили, которые «больше всех кричат».

Основные альфы и их подальфы — это и есть такие важные объекты, с них нельзя спускать глаз в ходе всего проекта, они будут постоянно менять состояния, в том числе откатываясь по состояниям назад, менять эти состояния позже ожидаемого, и всё это нужно отслеживать.

Альфа метода/способа/культуры работы

По большому счёту, содержание следующего после руководства по методологии руководства по системной инженерии — это весьма обобщённое/абстрактное изложение методов создания и развития (инженерных процессов, процессов разработки) самых разных систем и указание типовых ролей для этих методов. Руководство по системному менеджменту — это тоже довольно абстрактное изложение метода создания и развития организационных систем. Руководство по инженерии личности — это описание метода инженерии личности в целом и отдельного мастерства, то есть описание «инженерного процесса» для учебных проектов. Наставления всех этих руководств инженерной серии, по большому счёту, должны лечь в основу чеклиста для альфы метода/способа/культуры работы. Эту альфу можно назвать и альфой инженерного процесса, и альфой метода разработки — помним, что это всё общее название для общего метода, которым идёт создание и развитие целевой системы.

Руководство по методологии посвящено в том числе и методам описания методов. Так что моделирование метода работы путём определения альф, их состояний, контрольных вопросов, которые удостоверяют достижение состояний как прохождение контрольных событий/вех/milestones — это и есть один из методов описания метода. Конечно, это самый простой способ моделирования такого сложного объекта, как «метод» — и помним про то, что регламент/инструкция/«корпоративный стандарт» тоже может считаться моделью, а в первом разделе нашего руководства мы говорили о том, что простейшие пошаговые «процедуры», «стеки» и прочие простейшие модели в сложных случаях неприменимы, но таки лучше, чем вообще отсутствие явных описаний.

Так что дадим пример состояний альфы «метод создания и развития системы»/«метод разработки»/«инженерный процесс» и контрольных вопросов для этих состояний. Прототипом для этого набора состояний возьмём альфу way of working из примера основных альф OMG Essence. Итак, альфа инженерного процесса могла бы иметь следующие состояния (акцент тут делается не просто на постановку метода, но на реализацию оргвозможности — чеклист проверит, что в конечном итоге люди действительно задействуют метод, а не работают «уж как получается»):

• Правила установлены (principles established): команда активно поддерживает дисциплину/теорию/правила/принципы инженерного процесса; внешние проектные роли согласны с принципами; потребные для их поддержки инструменты/оборудование согласованы; рекомендации по выбранному варианту инженерного процесса доступны; рабочий контекст понимается; ограничения методов и выбранных для их выполнения инструментов известны.

• Основа положена (foundation established): ключевые методы работы инженерного процесса и их инструменты выбраны; методы, необходимые для того, чтобы начать работу, согласованы; методы, по которым не будет обсуждений и их инструментарий выявлены; разрыв между доступными и необходимыми оргвозможностями/capability определён; инженерный процесс, в котором все его методы удобно использовать, определён.

• Используется (in use): методы работы и их инструментарий используются; использование методов работы регулярно проверяется; методы адаптированы к обстоятельствам проекта; методы поддерживаются командой; механизмы получения откликов/feedback на методы работы работают; методы работы поддерживаются общением команды, команда сотрудничает в выполнении практик.

• Наличествует (in place): инженерный процесс используется всей командой; оргвозможности доступны всей команде; проверяются и адаптируются всей командой.

• Работает хорошо (working well): альфы проекта предсказуемо продвигаются по состояниям; методы применяются естественным образом без дополнительного обучения; инструменты естественным образом без дополнительной настройки поддерживают инженерный процесс работы; идёт постоянное совершенствование.

• Вышел из употребления (retired): инженерный процесс и его методы работы больше не используются; уроки использования практик метода опубликованы для использования в будущих проектах.

Руководство по методологии как раз разъясняет, как работать с описаниями методов и инженерным процессом в целом, а руководства инженерной серии дают развёрнутые описания вариантов методов для разных систем и указывают литературу, где можно найти ещё больше вариантов. Поэтому мы намеренно не будем тут подробно рассказывать про альфу инженерного процесса или даже её подальфу для какого-то прикладного метода. Сами попробуйте адаптировать чеклист альфы к своему проекту — выберите синонимы для метода и составляющих его методов, подберите подальфы. И помним: минимальный комплект действий по постановке метода (для оргвозможности надо ещё, чтобы метод можно было задействовать при работе) — это описание-регламент, шаблон чеклиста (примеры альф и их состояний как раз удобны для этого), чеклист для отметок при каждом прохождении метода в операционном софте, первый проход по методу с работником «за ручку» (обучение и заодно отладка возможных ошибок), установка надзора за выполнением метода и заполнением чеклиста.

Мы не приводим тут вариантов альфы функции системы как метода работы «не очень живой» системы, ибо в каждой предметной области приняты очень разные способы моделирования функциональности системы, подробней мы это обсуждали в первом разделе. Если вы считаете полезным, то вы можете попробовать сделать такой чеклист самостоятельно — но предупреждаем, что это может оказаться более трудным, чем вы это себе представляете. У вас должна быть как минимум квалификация методолога для той прикладной предметной области, к которой относится система, методы/функции работы которой вы будете описывать.

Альфа работы (works/operations/эксплуатации/использования) целевой системы

В ходе разработки целевой системы довольно трудно удержать внимание на времени её эксплуатации, когда система уже готова и как-то ведёт себя в эксплуатационном/операционном окружении (operational environment, время run-time/operations). Вот пример состояний альфы работы/эксплуатации/использования целевой системы и контрольные вопросы этих состояний. Помним, что вы должны адаптировать всё это для ситуации вашего проекта, и речь может идти не только о работе всей системы в целом, но и работе какой-то версии системы или даже инкремента/фичи/опции:

• Инициирована (initiated): требуемый результат работы (состояние предметов работы в окружении системы) системы ясен; ограничения (времени, ресурсов, безопасности и т.д.) ясны; известно, какая проектная роль платит за работу системы; инициатор работы выявлен; принимающие работу проектные роли известны; источник рабочих продуктов и финансирования работы ясен; приоритеты в работе ясны.

• Подготовлена (prepared): обязательства на выполнение работы владельцем системы (или самой системой достаточного уровня агентности/автономности) приняты; метод работы известен; цена работы и расход ресурсов оценены; доступность материалов для работы, пространства для работы и энергии понимается; правила и процедуры контроля ясны; критерии приёмки определены и согласованы; работы разбиты на части в достаточной для начала работ мере; задачи (tasks) определены, приоритеты для них расставляются; наличествует правдоподобный план (если это не планирование «на лету», планирование может вестись и внешнее); финансирование работы целевой системы наличествует; откуда брать исходные рабочие продукты и куда помещать конечные результаты работы, кому и как сообщать о выполненной работе определено.

• Начата (started): работа системы начата; прогресс работы отслеживается, исторические данные записываются; ресурсы начали расходоваться.

• Под контролем (under control): количество результатов работы растёт; незапланированная работа и расход ресурсов под контролем; риски под контролем; оценки производительности пересматриваются, чтобы отражать реальную производительность и расход ресурсов на работу системы; прогресс измеряется; необходимость повторного выполнения работы под контролем; обещания выполнения работ выполняются.

• Закончена (concluded): остались только координационные акты (извещения о завершении работы); результат работ был достигнут; внешние проектные роли приняли результаты работы.

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было задокументировано (digital twins); бюджет был сверен и закрыт; система была освобождена; нет незавершённых недоделанных работ.

Если вы хотите описать состояние работы в ходе использования/эксплуатации, то постарайтесь ответить на вопросы по состоянию этой альфы. Вы не отделаетесь только описаниями, например, только списком операций, которые нужно выполнить вашей системе (план работ), или которые она потенциально может делать (описание функциональности). Нет, надо будет описывать сами работы в жизни.

Конечно, вы можете (и лучше бы вы это делали) вводить и ещё один уровень отслеживания состояния. Например, для «задачи (tasks) определены» можно поставить дополнительный чеклист (это означает поставить дополнительную альфу) для проверки того, насколько деление работы на задачи сделано рационально. Например, соответствуют ли критериям MOVE из TameFlow (подробней — в руководствах по рациональной работе и системному менеджменту).

Вы должны знать (то есть выявить и документировать в каком-то моделере) те состояния работы/функционирования/operations/service/эксплуатации/использования целевой системы, которые у вас будут после её изготовления и введения в эксплуатацию. И, конечно, вы должны отслеживать эту альфу и во время эксплуатации. Состояния этой альфы выявляются положительными ответами на вопросы, важные для многих внешних проектных ролей: сколько стоит эксплуатация системы тут только один из них. Помним, что системное описание включает обязательный аспект стоимости системы как полной стоимости владения (разработка+эксплуатация), поэтому уклоняться от ответов на эти вопросы не получится, они важны для получения системного описания с ответами на важные вопросы, а не любого какого-то описания с ответами на какие-то вопросы.

Ещё один пример, набор состояний альфы «работа команды проекта». Работа организации/команды/коллектива проекта по созданию и развитию какой-то системы (создателя) может проходить следующие состояния (и не забывайте, что всё это надо адаптировать к ситуации вашего проекта и конкретной ситуации создателя где-то в цепочке создания!):

• Инициирована (initiated): требуемый результат работ ясен (состояние предметов работы в окружении создателя); ограничения ясны; известна проектная роль, которая платит за работы; инициатор выявлен; принимающие работу проектные роли известны; источник денег ясен; приоритеты ясны.

• Подготовлена (prepared): обязательства приняты; цена и потребные усилия оценены; доступность ресурсов понимается; правила и процедуры контроля ясны; критерии приёмки определены и согласованы; работы разбиты на части в достаточной для начала работ мере; задачи (tasks) определены, приоритеты для них расставляются; наличествует правдоподобный план; финансирование работ наличествует; как минимум, один человек из команды готов начать работу; моменты интеграции результатов работы определены.

• Начата (started): работа по разработке начата; прогресс работы отслеживается; работа разбита на единицы действий с ясными определениями того, что нужно сделать; члены команды принимают и выполняют задания.

• Под контролем (under control): количество завершённых задач растёт; незапланированная работа под контролем; риски под контролем; оценки пересматриваются, чтобы отражать реальную производительность команды; прогресс измеряется; переделки под контролем; обещания выполнения работ выполняются.

• Закончена (concluded): остались только административные задачи; результат работ был достигнут; внешние проектные роли приняли систему (или её инкремент/фичу).

• Закрыта (closed): метрики были сделаны доступными для других проектов; всё было заархивировано; бюджет был сверен и закрыт; команда была освобождена; нет незавершённых недоделанных задач.

Это всё вариации состояний альфы «работа» из примера основных альф OMG Essence — и тут очень чётко просматривается «водопад» в его простейшем начальном понимании из проектного управления (скажем, ничего не говорится об инженерном процессе и методах работы, но зато «наличествует правдоподобный план» — это ведь явная отсылка к up-front планированию). Чтобы работать по этому чеклисту в современных условиях, надо существенным образом его адаптировать.

Если вы хотите описать состояние работ, а не описать состояние описания работ, то вы не можете просто дать список работ в виде какого-то плана или даже бэклога²⁹³, даже если вы напишете какой-то обобщённый жизненный цикл в его первой версии: «работы включают замысел, проектирование, изготовление, испытания, а дальше не наше дело». Этот список не ответит на вопрос о том, в каком состоянии альфа «работа» — подготовлена ли она, под контролем? Как этот список работ ответит на вопрос о наличии финансирования? На вопрос о наличии правдоподобного плана «список стадий» тоже не ответ, это же не план (кто что когда делает), это список стадий из учебника! А вот правдоподобный план (состояние альфы характеризуется не вообще любым планом, а правдоподобным планом — ожидается рациональное планирование и такой план, для которого высока вероятность его реализации) текущего шага, что прямо сейчас нужно делать — он есть? Есть ли текущий список кейсов/issues в трекере, что там уже выполняется, а что ещё в бэклоге? Проставлены ли в нём приоритеты, что делать прямо сейчас, а что оставить на потом — важен ведь порядок работ, а не просто список работ (помним, например, про мультитаскинг и поздние старты)?

Вот этим нужно интересоваться, общие слова, что «мы замыслим, спроектируем, изготовим систему, а затем испытаем её» — они тут не пройдут. Вы должны знать (то есть выявить и документировать) то состояние, в котором у вас находятся работы по проекту. Следим за типами: слово «работы» в предыдущем предложении как раз и есть альфа «работы организации проекта».

Пример: альфа «культура» для сообществ

Социологические и социопсихологические теории в инженерии сообществ нам пока не слишком помогут²⁹⁴, а инженерный подход сразу приводит к рассмотрению графа создателей сообщества. Создатели сообщества сегодня называются чаще всего менеджерами сообщества, ибо менеджмент сообществ оказывается во многих аспектах близок к менеджменту организации в целом:

• Организация рассматривается с одной стороны как сообщество её сотрудников, разделяющее какую-то организационную культуру (методы общения и отношения друг ко другу, разделяемые членами этой организации).

• Собственно «организация» как группа людей с понятными полномочиями по распоряжению трудом и капиталом, ведущая скоординированную работу по созданию каких-то систем-продуктов и/или предоставлению сервисов.

Если мы берём какое-то сообщество, которое не представляет собой «рабочую силу организации», то можно рассматривать его с двух позиций восприятия:

• Члена сообщества, который получает какой-то опыт/впечатления, проходя своё путешествие в это сообщество, нахождения в сообществе, ухода из сообщества. Это мы обсуждали в нашем руководстве: community member journey и community member experience.

• Менеджеров сообщества, ибо они пытаются организовывать и развивать какие-то сообщества (жителей территории, любителей спорта, увлекающихся каким-то хобби и т.д., но так же и сообщества клиентов, пользователей, инвесторов организации) примерно так же, как они занимаются развитием сообщества самих сотрудников. В этом плане работа менеджеров сообществ и HR служб компаний отличаются не сильно.

Рассмотрение тут функциональное, ролевое, методологическое: одни и те же агенты могут быть одновременно и участниками сообщества, и его менеджерами. «Инженеры сообществ» говорить не принято, это можно услышать ещё реже, чем «инженеры предприятий». Чаще всего говорят «менеджеры сообщества», но эту роль могут назвать и «организатор», «орг» — тут примерно та же терминология, что и с «мероприятиями», которые, по большому счёту сводятся часто к «мероприятиям в рамках управлению сообществами», то есть мероприятиям по созданию, развитию, обучению сообществ, вовлечению членов сообщества в какую-то профильную культуру.

Если мы будем говорить о «создателях сообщества», то речь идёт необязательно о «создателях с нуля», речь может идти и о развитии, и о поддержании или наоборот, сознательном развале сообщества, если кто-то из агентов посчитает его неприемлемым. Тут термин создатель/constructor формально указывает просто на системы из графа создателей. Как всегда, надо восстанавливать значения терминов не из «определений» и «словарей» (их множество!), а из контекста. Смысл слов ищется главным образом в их употреблении, а не в словарях! Словари могут помочь, но могут и запутать, и вовлечь в пустопорожний «спор о терминах».

В руководству по системному мышлению отмечалось, что групповые объекты вполне можно считать системой, если рассматривать их без отрыва от рассмотрения их среды/environment как надсистем. В зависимости от проекта сообщество можно или считать целевой системой с каким-то обществом как надсистемой (и там ещё надо показать часть-целое, что может быть непросто), или даже считать подсистемой создателя, нужной для его функционирования в его собственной надсистеме (скажем, для выживания в конкурентной среде, удержания границ) или даже вообще не считать системой — считать множеством членов (как не считаем системой партию деталей, а системой считаем каждую деталь, выпущенную на заводе-создателе по общему для всех этих деталей проекту/design), но это будет только в том случае, когда нас не интересуют эмерджентные характеристики сообщества.

Сообщество при этом мы посчитали состоящим из каких-то членов, у которых есть мастерство культуры, практикуемой этим сообществом. И тут мы опять попадаем в предмет рассмотрения методологии: культура — это просто метод, которым пользуется какое-то сообщество. Сообщество инвесторов состоит из агентов с мастерством инвестирования, сообщество клиентов состоит из агентов с мастерством покупки продуктов или сервисов, сообщество свободных художников состоит из агентов с мастерством свободы (если они договорились, по каким методам ведут себя «свободные» агенты) и рисования.

Какие культуры надо рассматривать, когда мы говорим о сообществах? Чтобы системно описать изменения в ходе создания и развития сообществ, нам потребуется отслеживать альфы минимально в трёх областях интереса:

• Создателя (менеджер/builder/developer/орг) сообщества, причём их может быть множество — в том числе они могут и конкурировать, в том числе там могут быть сложные графы создателей.

• Самого создаваемого и развиваемого сообщества как целевой системы.

• Отдельных членов сообщества как подсистем целевого сообщества-системы.

Ничего необычного. Если вам встречается какой-то «странный объект в странной предметной области», вы просто используете системное мышление — и появляются реально важные объекты, которые будет понятно, как описывать. Сообщества тут не исключение.

В каждой из областей интереса мы обычно выделяем четыре основные/kernel альфы как предметы метода, отслеживаемые в ходе проекта: воплощение системы, описание системы, метод работы системы, работы системы. Это означает, что для трёх упомянутых областей интереса мы сходу получаем 12 альф, которые надо бы отслеживать в ходе проекта, причём там сразу намечаются усложнения:

• Создатель дальше будет раскрываться как целый набор создателей в каком-то графе создателей сообщества. Какое там было путешествие менеджера сообщества? Откуда он пришёл, кто его привёл, кто научил? Кто влияет на его решения или вообще может его заменить? Кто там его конкуренты (влиять на сообщества много кто хочет, и часто это влияние конкурирующее!), кто союзники?

• Сообщество можно раскрывать и как набор подальф «член сообщества», но по факту будет сложнее: члены сообщества будут выступать как полноценные системы в этом сообществе и могут моделироваться каждое полноценными четырьмя основными альфами (как и в случае «инженерной команды»).

Конечно, в корпоративном контексте сразу речь пойдёт о ролевых сообществах сотрудников, пользователей, клиентов, инвесторов, жителей тех районов, где размещены предприятия, сообществах поставщиков. Но все эти рассмотрения могут быть использованы и не для корпоративных контекстов — для какого-нибудь кружка вышивания крестиком или саморегулируемой организации (не все саморегулируемые организации уполномочены государством, политические партии и их объединения вполне могут таковыми быть, иногда такой подход называют «партией нового типа», начиная от партии большевиков). Впрочем, у нас руководство не по управлению сообществами, а по методологии, поэтому дальше эту тему раскрывать не будем, а отошлём сразу к руководству по системному менеджменту, где рассматривается менеджмент и организаций, и не слишком организованных сообществ.

Для методологии важны культуры, состояния которых отслеживаются альфами «метод» и их подальфами в соответствующих областях интереса. Конечно, такая альфа для сообщества будет называться не «метод», а «культура»:

1. Культура члена сообщества. Её можно разложить на составляющие, которые можно отслеживать подальфами альфы «культура» в области/зоне/area интересов члена сообщества:

• Культура мышления (превращения проблем в задачи), определяемая общим интеллектом, получаемым образованием (подробней — в руководствах по инженерии личности и интеллект-стеку). Грубо говоря, члену сообщества надо быть образованным человеком или AI-агентом (интернет тем и хорош, что на другом конце мира с тобой может разговаривать не только человек — и это оказывается не так важно). Конечно, стая диких собак в городе — тоже сообщество, но всё-таки мы тут про другие сообщества, и вот сообщество (иногда само сообщество в таких случаях называют «культурой», поэтому повторим, что тип понятия лучше определять не по словам-терминам, а по контексту) дикого племени в амазонском лесу (tribal community) или сообщество физиков, интересующихся квантовой гравитацией (community of practice) всё-таки разные виды сообществ. Про то, как строятся детские сообщества, как они связаны с общим интеллектом и культурой развитой цивилизации, можно почитать в книге «The Lord of The Flies»²⁹⁵. Интеллект для участника сообщества лишним не бывает, для участия в людских сообществах нужно иметь минимальную культуру мышления. Впрочем, как показывают сообщества астрологической практики, сообщества арома/арт/танц/театр/чегоугоднотерапии от всех болезней, сообщества заговора причёсок на любовь и деньги, сообщества снятия порчи, сообщества конспирологов и т.д. — интеллект и в современном городе необязателен, сообщество можно найти себе для любой силы интеллекта. Детям сейчас нравится быть квадроберами²⁹⁶ и хоббихорсерами²⁹⁷, родители оплачивают их увлечения, эти увлечения могут оставаться и во взрослом обществе. Но в любом случае — культура мышления какого-то уровня у члена сообщества должна быть, её надо обсуждать явно.

• Культура обучения (включая прикладное обучение, но и непрерывное образование — общее умение учиться). Будущему члену сообщества очень часто надо дополнительно учиться профильной культуре сообщества, нельзя ожидать, что без обучения можно стать полноценным членом сообщества. Скажем, не научился бухгалтерскому делу — не будешь нормальным членом сообщества бухгалтеров, не научился танцевать парные танцы или хотя бы диджеить — не будешь в сообществе социальных танцев, не научился бояться пауков — не будешь в сообществе боящихся пауков. Пример с арахнофобией как «выученному мастерству» взят из литературы по нейролингвистическому программированию (оригинальному НЛП): там прямо говорят, что «мозг научился бояться пауков, это означает, что его можно научить не бояться», психотерапия тем самым заменяется разными вариантами моделирования «человеческого совершенства»/«human excellence» и затем научению отмоделированного мастерства методами «нейролингвистического программирования», то есть «программирования мокрой нейронной сети словами». причём необязательно методами именно старинного (из 70х годов прошлого века) оригинального НЛП. Подробней это будет разбираться в руководстве по инженерии личности, но тут мы культуру обучения берём не с позиции внешнего учителя, а как культуру обучения себя («внутреннего учителя» с его мастерством мотивировать себя на обучение и выбрать методы этого обучения и «внутреннего ученика» с его мастерством быть собранным в ходе тренировок). В руководстве по инженерии личности указаны роли ученика, и их немало. Для выполнения всех этих ролей нужна некоторая степень мастерства исполнения этих ролей, иначе обучения не будет. Скажем, нужно иметь некоторую степень собранности, чтобы ученик вообще чему-то научился. И даже при наличии «мастерства учиться» профильной культуре сообщества до какого-то приемлемого этим сообществом уровня нужно учиться много лет.

• Профильная культура сообщества. Конечно, тут возможны самые разные градации мастерства, но это ровно тот метод, работа по которому отличает членов одного сообщества от другого: кто-то инвестирует, кто-то покупает продукты, кто-то занимается конкретным видом спорта, кто-то «болеет» за спортивную команду. Дело тут не столько в «знании», во владении мастерством. Можно знать, но ничего не делать. Скажем, степени квалификации МИМ²⁹⁸ предполагают переход от «специалиста», который может поговорить о предмете интереса сообщества организаторов работы к «практику», который что-то там умеет сам сделать, а дальше «мастеру», который будет носителем SoTA мастерства и будет практиковать профильную культуру (в том числе будет её проводником, будет обучать этой культуре), а дальше степень квалификации «реформатор» предполагает уже не просто практикование какой-то культуры, но и развитие культуры, smart mutations для этой культуры, и там можно стать ещё и «революционером», если удастся предложить какой-то крупный эволюционный сдвиг, выйти на новый уровень оптимизации. Грубо говоря, в сообществе композиторов я могу рассуждать о композиторстве (специалист), но сочинять могу не уметь. Могу иногда что-то такое сочинить на совсем любительском уровне (практик). Но могу практиковать образ жизни композитора, иметь композиторское мастерство, показывать образец того, что означает быть композитором — активно сочинять! Реформатор — это тот, кто развивает предмет, продвигает нестандартные методы композиции, содержательно продвигает культуру, устанавливает планку для мастерства композиции. Но «революционер» — это когда устанавливается новый уровень планки для мастерства композиции, скажем, Арнольд Шёнберг был революционером, он предложил новый метод музыкальной композиции, додекафонию²⁹⁹. В сообществах, где надо просто жить вместе и не драться, профильная культура — это «культура общежития». В сообществах финансовой взаимопомощи — культура давать и брать деньги. В сообществе плоской Земли надо обычно просто хорошо разбираться в вопросе и популяризовать имеющиеся идеи, но неплохо бы и развивать теорию (скажем, вносить и развивать идеи вогнутой Земли, даже жизни внутри Земли³⁰⁰), выходить на уровень квалификации реформатора. Во всех сообществах В мастерской инженеров-менеджеров слово «мастер» используется и как «агент с какой-то степенью мастерства в каком-то методе работы», и как «агент, у которого вполне определённая по заранее установленной шкале³⁰¹ степень мастерства в методах оргразвития», то есть «мастер оргразвития». Часто не обсуждают культуру/метод, а обсуждают «мастерство выполнения метода» у членов сообщества. Так что внимательно смотрим за контекстом, а омонимия для «мастера» («мастер своего дела» и «мастер оргразвития» как минимум) в наших руководствах указана. В сообществах обращают особое внимание на уровень владения мастерством какой-то культуры, социальный статус членов сообщества в сообществе во многом определяется именно мастерством выполнения работ по профильной культуре сообщества: член кружка вышивания крестиком оценивается по тому, как качественно и быстро он вышивает, танцор — по качеству его танцевания.

• Культура сотрудничества/collaboration и собственно «духа сообщества». В сообществах регулярно затеваются какие-то проекты. Для этого появляются наложенные/overlay (состоящие из членов сообщества) организации, в которых будет задействовано разделение ролей в достижении общих целей — участникам сообщества надо будет вписываться в какие-то проектные команды. Быть членом команды, имея достаточно собранности для удерживания роли — вот это оно и есть «культура сотрудничества». Давать обещания, выполнять обещания вовремя, удерживать ответственность не только за результат своего кусочка работы, но и за результат проекта в целом. Когда говорим о том, что каждый отдельный член сообщества занимается профильной культурой (например, покупает мотоциклы Харлей Дэвидсон и разъезжает на них, или печатает на 3D-принтере в maker community, или просто «является членом общежития» в какой-то коммуне), ему надо собственные дела как-то увязывать с делами остальных членов сообщества. Так, в сообществах практики надо помогать друг другу в обсуждении трудных проблем, в социальных танцах надо формировать пары и соблюдать правила поведения на вечеринках. В онлайн-сообществах надо совместно бороться со спамом, либо поощрять разговор матом («контркультура» — это тоже культура!), либо наоборот — не поощрять, соблюдать какие-то этические стандарты в своём поведении. В добровольческих (филантропия и меценатство, но не деньгами, а работой) проектах понимать, что «бесплатного обеда не бывает» и вся «бесплатность» мнимая, отслеживать поэтому траты своего времени на добровольную работу и ценить трату времени других членов — понимая, что там может и должно быть сделано бесплатно, а что кто-то должен оплатить. В организациях тут сразу идёт речь о «корпоративной культуре», которая главным образом и понимается как «культура сотрудничества» (хотя в широком смысле слова она включает не только методы, которыми достигается сотрудничество членов организации, но и все остальные методы работы — в том числе стили/методы/культуры инженерии, менеджмента, маркетинга и т.д.). В корпоративной (корпорация — сообщество сотрудников, на котором существует наложенная организация с понятными полномочиями по распоряжению ресурсами) культуре тоже довольно много обсуждается метод достижения приемлемой степени сотрудничества (например, core protocols³⁰²). Когда обсуждают тематику сообществ в её «социальности», именно эта культура сотрудничества становится центральной: «своих не выдаём», «один за всех и все за одного» и прочие коммунистические слоганы, идеи колхоза и всяческих коммун именно тут, причём эти идеи борются с идеями рациональной организации какого-то труда. Собиратели марок, спортивные клубы, «кровавый энтерпрайз» разработки софта в крупных организациях, мафиозные организации — все они различаются способом, каким налаживают культуру сотрудничества, хотя не все эти сообщества можно назвать полноценными «организациями».

• Ситуационная культура сообщества. Тут практикование уникальных ритуалов и обычаев сообщества, участие в конкретных мероприятиях, «общая идентичность» (чаще эта «идентичность» означает общую историю как участие в каких-то событиях, признание каких-то принципов важными — «общие ценности», знание символов — что они означают и почему важны, иногда вообще что-то абстрактное трудновообразимое, типа признания «исторической родины», или желание быть меховым зверем). Тут же всякие важные принципы в принятии решений о действиях («ценности сообщества», причём под этим словом все понимают крайне разное, лучше бы его не использовать). Можно думать о профильной культуре и культуре сотрудничества/collaboration как о метаУ-моделях, «как в учебниках», а о ситуационной культуре — как о метаС-модели для этих культур, «как это принято у нас». И сюда же входит культура осознания (наличие у члена сообществам мастерства/умения осознать), что член сообщества — не только член местного сообщества или участник конкретного мероприятия, но и часть более крупной социальной группы — несмотря на то, что этот участник сообщества может не знать всех членов этой социальной группы лично.

2. Культура создателя/менеджера/организатора/орга/builder/developer сообщества. Она может быть разложена на несколько составляющих её культур, которые можно отслеживать подальфами альфы «культура» в области интересов менеджера сообщества:

• Культура менеджмента сообществ. Тут, конечно, есть особенности, включая коллективное управление собственностью (если она есть), отсутствие иерархии в управлении (в том числе и отсутствие власти благосклонного диктатора³⁰³). Тут и организация сообщества «на пустом месте», и коллективное стратегирование в сообществе, и «управление мероприятиями»/«event management»³⁰⁴, вузовская специальность. Впрочем, и community management тоже сегодня специальность, которой учат в вузах. В эту культуру, как и в любую другую культуру менеджмента входит ещё и обучение членов сообщества всем их культурам (тут мы подразумеваем, что культуры членов сообщества отличаются от культуры сообщества там, где сообщество само агент и следует методам, которые распространены у других сообществ — поэтому говорим о культурах членов сообщества. Впрочем, это уже нюансы — «культура сообщества» довольно многими будет понята как «культура, которую разделяют члены этого сообщества»), создание альянсов (внутри сообщества прежде всего, но и с другими сообществами), взаимная поддержка в сотрудничестве — лидерство (ибо членов сообщества надо культуре сотрудничества научить), укрепление доверия, разрешение споров, нетворкинг и всякое другое. По большому счёту, это классический менеджмент, только с той особенностью, что сообщество есть, а вот его организации и проекта по созданию какой-то системы у этой организации — нет. Профильное руководство тут — по системному менеджменту.

• Культура продвижения. Тут довольно много всего, ибо это «маркетинг, реклама», но немного особенная и без «продаж» — нет товара, нет сервиса (хотя вы, конечно, можете заманивать в какую-нибудь церковь как победившую секту или секту как проигравшую церковь через предложение сервиса «спасение в загробной жизни»). Речь тут идёт о разных способах «вербовки» в члены сообщества, хотя язык при этом используют более мягкий и безоценочный — вовлечение/engagement. В этой роли орг сообщества может быть назван advocate, ambassador, evangelists (техноевангелисты каких-то технологий — это как раз про «затаскивание в сообщество применяющих новые технологии/методы»), группы таких оргов будут называться activist groups.

Конечно, и член сообщества, и создатель сообщества (инженер сообщества, хотя повторимся: сегодня более уместно тут говорить «менеджер», иногда «организатор») — это, конечно, роли. Поэтому возможны разные варианты раскладки ролей по агентам, исполняющим эти роли:

• Какой-то агент может просто совершать своё «путешествие» из «чужих людей» в «члены сообщества», а затем начать предпринимать осознанные или даже неосознанные усилия для того, чтобы как-то «поддержать сообщество».

• Может быть и так, что ростом и благополучием сообщества будет заниматься какая-то внешняя организация, скажем, сообщество клиентов создаёт и развивает служба продвижения какой-то компании. Тут можно говорить в разных терминах, всё зависит от референтного индекса и разделяемых идей коммунальности. Например, есть вариант рассмотрения как «разведение домашних животных», клиентура или даже инвестура «как стадо коров» — стадо тут часть фермерского хозяйства, клиентура как сообщество может считаться частью «хозяйства компании». В подобного сорта рассмотрении можно найти множество аналогий: «создание и развитие стада» (время создания), и «эксплуатация — дойка и переработка молока» (про мясо умолчим, но в военных сообществах молоком не интересуются, а пушечным мясом — вполне). Примеры тут могут быть и менее «обидные», из мира животных (это одно из проявлений паразитизма, которое иногда оказывается ведущим к симбиозу). Например, отдельные виды муравьёв разводят тлей, речь идёт о самых разных видах и вариантах такого симбиоза³⁰⁵. Ключевым рассмотрением тут будет культура: какие сервисы оказывают орги и сообщество как целое друг другу (организация с входящими в её состав подсистемами оргов и ролевыми сообществами). Как отличить от рабовладения, от крепостничества, феодального закрепления (тут ведь тоже много разных степеней «ужасности»)? Это решается контекстом. Для кого-то и работа по найму в фирму — рабовладение у капиталистов, для кого-то и жизнь под государственной диктатурой — полностью свободный выбор гражданина (хотя там и есть хитрый перескок на уровень общества, избирательное право, выборы или их отсутствие). Ещё один пример—сообщества (их много!) менеджеров сообществ (есть и англоязычные³⁰⁶, и русскоязычные³⁰⁷). Конечно, для сообществ тоже можно построить граф создателей. Так, каких-нибудь клиентов сети парикмахерских будет развивать как «сообщество любителей шикарных стрижек» менеджер сообщества, нанятый парикмахерской. Этот менеджер сам будет членом сообщества менеджеров сообщества (например, русскоязычного сообщества менеджеров сообщества), но и у этого «сообщества менеджеров сообщества» есть свой организатор³⁰⁸.

• вариант, сотрудников как сообщества: тогда говорят о корпоративной культуре, и там всё то же самое, только методы работы будут иметь другие названия, например, не «вербовка» или даже «вовлечение», а «найм»/recruitment.

Все эти субкультуры менеджмента сообществ отличаются от общей культуры менеджмента ровно отсутствием «организации» как иерархической структуры управления с понятным подчинением, чётким управлением ресурсами, которые инвестированы в организацию, отсутствием явной общей цели, отсутствием коллективного создания и развития какой-то системы в форме проекта с глубоким разделением труда. «Перегибы» тут в том, что из менеджмента сообществ в организационный менеджмент проникают социалистические идеи (обычно это идеи каких-то «плоских» или «бирюзовых» организаций), и они сопровождаются идеями утопических проектов, отсутствием достижимых целей («для самурая нет цели, только путь» — для компаний это возможно, пока она проедает деньги инвесторов, а после этого надо всё-таки иметь какую-то эффективность производства, нужна не семья, не сообщество — нужна ещё и эффективная организация).

Конечно, любая организация (наложенная/overlayed на сообщество сотрудников!) — это система систем (SoS), подразумевающая автономность отдельных подсистем. Люди ведь самопринадлежны. Так что люди (про AI-системы пока не говорим) там одновременно и самопринадлежные личности, и входят в состав оргзвеньев организации (поэтому выполняют роли, назначенные оргзвеньям), и одновременно они участники/члены сообщества сотрудников — и выполняют роли членов этого сообщества, практикуют корпоративную/организационную культуру.

И тут же идёт поворот к сервисной ориентации и поворот к построению brand community — маркетинг работает на создание и поддержание пользовательского (сервисный же поворот!) сообщества. Так что менеджмент организационный и менеджмент сообществ оказываются тесно связанными.

В любом случае, мы избегаем слов «самоорганизация сообществ», ибо это запутывает. Если я почесался («самоорганизовался на почесание»), то лучше сразу идти на уровень вниз и выделять роли — «моя левая рука, организованная моим мозгом, почесала мою правую руку» и всё, никакого «само». Конечно, можно выделять какие-то каталлактические³⁰⁹ эффекты (это подробно обсуждалось Хайеком и прочими исследователями «спонтанного порядка»), но пока давайте разбираться с ситуациями выделения ролей организаторов, в том числе выделения ролей конкурирующих организаторов — в том числе рассматривать стратегирование с конкурирующими идеями.

В качестве иллюстрации разных тем обсуждения в менеджменте сообществ приведём пример³¹⁰ канвы, используемой как чеклист создателями сообщества:

А теперь посмотрим на составляющие культуры члена сообщества и менеджера сообщества ещё раз, но без подробных разъяснений и с указанием ролей и подролей, просто чтобы «увидеть лес за деревьями»:

1. Культура члена сообщества — роль в зависимости от роли для профильной культуры сообщества (сотрудник, пользователь, клиент, игрок, хоббист, земляк...):

• культура мышления (проявления общего интеллекта, получаемого образованием) — личность (кошек в сообщества не берут, интеллектом не вышли)

• культура обучения — ученик (чаще всего указывается даже не просто «ученик», а ещё и «где учился», чтобы оценить косвенно умение учиться)

• профильная культура сообщества — по факту вот эта культура и будет транслироваться до уровня роли члена сообщества и выходить в название (сотрудник, пользователь, клиент...)

• культура сотрудничества и «духа сообщества» (в организациях — «корпоративная/организационная культура») — тут «участник команды»/сотрудник

• ситуационная культура сообщества — обычно тут всё то же, что в профильной культуре, только ещё и знание сленга и недоступного извне знания, роль — «свой» (противопоставляется роли «не наш, чужой»), но по сути дела это опять-таки относится к конкретному варианту разложения культуры для заявляемой сигнатуры культуры члена сообщества.

2. Культуры менеджера (организации или сообщества, тут не так важно) — роли орга/менеджера:

• менеджмент (и мы не разделяем тут менеджмент организаций и сообществ — всё это менеджмент, организационный или сообществ).

• продвижение (если роль сотрудника, то заполнение вакансий по наинизшей цене, если роль клиента — то пополнение рядов клиентов с наилучшей юнит-экономикой, если роль любителя культуры — то пополнение рядов любителей культуры какими-то попытками просвещения в порядке меценатства и филантропии).

За чем следить в проекте

Основной способ отслеживания состояния альф — это чеклисты (checklist, список контрольных вопросов), заставляющие подумать о том, о чём можно забыть подумать в суете проекта.

Когда самолёты стали слишком большими для управления одним человеком, они часто взрывались на взлёте из-за банальных ошибок: то с ручного тормоза не снимут, то забудут проверить работу всех многочисленных двигателей перед взлётом. Помогло введение чеклиста: чеклист заставлял подумать и проверить то, что в спокойной обстановке все знают, что нужно делать, но в суматохе взлёта иногда забывают действительно сделать, и это ведёт к фатальным неприятностям, вы должны были читать об этом рекомендованную книгу Атула Гаванде, заодно там рассказывается, что чеклисты могут существовать в самой разной форме³¹¹.

Предложенный OMG Essence способ моделирования альф как предметов инженерного процесса как раз предлагает формат чеклиста — сами альфы ведь введены как объекты неусыпного внимания в ходе проекта, а чеклисты будут отличной формой, которая упростит отслеживание состояний альф.

Если члены команды не задумывались о состоянии какой-то из альф, то возникают большие риски, что там что-то может пойти не так — просто потому, что не хватило внимания. Проект создания системы обычно не менее сложен и хлопотен, чем взлёт самолёта, поэтому можно ожидать отсутствия самых понятных и простых работ — например, можно в суете проекта забыть наладить коммуникацию с исполнителями внешних проектных ролей и просто фантазировать/галлюцинировать вместо выяснения ситуации по поводу потребностей и надсистем, или забыть провести испытания в рамках инженерных обоснований, или забыть учесть какие-то архитектурные решения. Коллективная собранность в проекте должна быть как-то организована:

• Важные объекты внимания, которые меняются в ходе проекта — это альфы, не забываем их отслеживать. Отслеживанию подлежат изменения: смены состояний альф как предметов методов инженерного процесса.

• Надо убеждаться, что смены состояний действительно произошли. Для этого используем чеклисты в компьютере. «Ведём проект», даже если у нас в проекте проблемы, ровно как лётчики «летят самолёт» — используя чеклисты («летят самолёт» — это от чеклиста остановки двигателя в полёте, где первым пунктом указано «fly the airplane», ибо пилоты буквально забывали заниматься пилотированием, занимаясь расследованием ситуации с остановкой двигателя — и самолёт входил в штопор).

• Ключевым является даже не само записанное в чеклисте состояние альфы (но записывать надо, человеческой памяти не доверяем) — но подумали или не подумали вы о её состоянии. Ибо если подумали, то шанс что-то исправить есть, а если не подумали — «всё, что может пойти не так, обязательно пойдёт не так».

Контрольные точки (milestones, моменты каких-то событий, используемые для планирования работ и отслеживания выполнения планов) достижения состояний каждой альфы на графе изменения её состояний формулируются как события смены ответа на вопросы чеклиста: смена отрицательного на положительный ответ означает событие достижения нужного состояния, то есть прохождение этой контрольной точки в какой-то момент времени. В текущем разделе графы состояний каждой альфы (не путать с графом создателей, графы — это просто универсальная математическая структура, удобная для моделирования) даны как некоторые последовательности состояний, но в общем случае состояния альфы могут проходить какие-то маршруты по довольно разветвлённому графу.

Вы можете увеличивать разрешение планирования, выделяя альфы, подальфы, состояния альф и подальф, у этих состояний формулируя критерии достижения через некоторые контрольные вопросы, задающие контрольные точки достижения составляющей состояния, а дальше и для этих контрольных вопросов вводить ещё какие-то дополнительные вопросы. А как надо? Надо, чтобы вы не пропустили какие-то важные объекты внимания в своих чеклистах, это означает, что вам надо бы отмоделировать граф создателей — чтобы не пропустить чего-то по-крупному. А потом взять важные подальфы для этого графа создателей (и их тоже может быть несколько уровней подальф), но какие именно — это уж вам решать в проекте. И то же самое про состояния альф и подальф, число контрольных вопросов для определения события достижения состояния, и разложение этих контрольных вопросов (всё это тесно связано: разложение методов достижения нужного состояния какой-то альфы и разложение достижения её состояний на составляющие — там точно так же плохо получается говорить о «частях состояний», как и о «частях метода»).

Скажем, в альфе «работа» области интересов организации проекта состояние «инициирована» имеет первым же подпунктом «требуемый результат работ ясен (состояние предметов работы в окружении системы или создателя)». Вы можете считать контрольной точкой событие «достижение состояния «работа инициирована» к какой-то дате» и все контрольные вопросы для этого состояния просто контрольными вопросами достижения этого состояния, а можете эти контрольные вопросы тоже привязать к контрольными точкам, достижение которых возможно в разные моменты времени для каждого, чтобы потом отслеживать это в операционном менеджменте, привязать к календарю. Это ваш выбор, какой дробности моделирование вы делаете. Моделирование альф и их состояний, контрольных вопросов, привязка их всех к календарному планированию через привязку к контрольным точкам (milestones) — гибкое, оно не жёстко предопределено.

При этом результат работ сам себя не прояснит, состояние «требуемый результат работ ясен» само собой не произойдёт. Для достижения этого (и любых других состояний и составляющих этих состояний) надо провести какие-то работы, и эти работы должны быть проведены по каким-то методам.

Достижение состояний альф неминуемо порождает обсуждение методов работы по их достижению, а планирование моментов этих достижений состояния как контрольных точек проекта неминуемо вызывает обсуждение ресурсов, эти ресурсы берутся из методов, а их доступность — из ресурсного планирования. Мысль должна бежать так (приведём простой пример, но это общее рассуждение, при этом все соседние рассуждения по похожим последовательностям откидываем для простоты):

• «Совещание»::альфа

• «Помещение для совещания»::альфа — подальфа для «Совещания»::альфа (тип подальфы — тоже альфа!)

• «Тишина в комнате совещаний установлена»::«контрольный вопрос» альфы «Помещение для совещания»

• ««Тишина в комнате совещаний установлена» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей состояния альфы и ожидаемого времени достижения)

• «Внешний шум отсечён»::«контрольный вопрос» второго уровня для «тишина в комнате совещаний установлена»::«контрольный вопрос»

• ««Внешний шум отсечён» «к началу совещания (ожидается в 16 часов)»»::контрольная точка (сделана из контрольного вопроса составляющей второго уровня контрольного вопроса к состоянию альфы и ожидаемого времени достижения)

• «Дверь закрыта»:: контрольный вопрос третьего уровня к состоянию альфы «помещение для совещания»

• «Окна закрыты»:: контрольный вопрос третьего уровня к состоянию альфы «помещение для совещания»

• «Мобильники участников переведены в режим «без звука»»::«контрольный вопрос к альфе «тишина в комнате установлена»

• «Закрытие двери»::работа проводится «секретарём совещания»::оргзвено методом «закрыть руками» (варианты: «ближайшим к двери участником совещания»::оргзвено, «проводится автодоводчиком», дополнительно работа установки автодоводчика на дверь проводится службой офис-менеджмента).

• Закрытие двери заносится в issue tracker и назначается на секретаря совещания (и дальше выполнение этой работы проверяется «как обычно» — эта работа и факт её выполнения не потеряется, она тоже оказывается записанной).

Конечно, это крошечная часть состояний очень сложного предмета метода с сигнатурой «проведение совещания», которое может быть оффлайн синхронным, онлайн синхронным, онлайн асинхронным³¹², смешанным, проходить на пару человек в режиме прогулок, как у перипатетиков³¹³, включать или не включать в себя подготовку транскриптов, протоколов и т.д. Более того, это слишком детальный чеклист (хотя где-то это может быть большим подспорьем — вовремя проверить, включены ли кондиционеры, закрыты ли двери и окна, оповещены ли сотрудники, есть ли способ показать, что помещение занято и т.д.). Главное, что у вас есть какие-то более-менее общие объекты внимания разного уровня (основные альфы), у них есть подальфы, дальше есть несколько уровней контрольных вопросов. И самое главное — что теперь вы понимаете, что в какое состояние переводить, теперь можно выбрать вариант метода в разложении метода (закрыть дверь ногой самому, рукой самому, попросить кого-то проходящего мимо, закрыть дверь автодоводчиком, но распорядиться, чтобы он там был), и даже не забыть попросить выключить звук у телефонов (хотя сейчас это уже и редко нужно, звук и так обычно уже выключен — но лет пять назад это ещё было актуально).

Потом надо убедиться, что запланированные работы выполнены — и не забыть поставить отметку не о выполнении работы, а о достижении состояния предмета метода этой работы. Чеклисты — для контроля того, что работы привели к нужному состоянию предметов методов, а не просто для того, чтобы показать факт «работы выполнялись».

Агентность — это во многом внимательность, осознанность, это не «делал во сне, на автомате и забыл, делал ли — вроде закрыл дверь на ключ и выключил утюг». Сделал — посмотрел, что там получилось в результате. Или посмотрел — и сделал всё, что надо, а не всё что в суете вспомнил. Плюс сверка ожидаемых результатов работы и реального состояния предметов метода, это резко уменьшает число ошибок от работы над недоделанными результатами прошлой работы (скажем, грунтовал — но не загрунтовалось, поэтому красим без грунтовки, результат — «почему-то покрасилось ужасно»). Чеклист — хороший инструмент для агентности. Даже если заснул в ходе работы, чеклист даёт возможность проснуться — сверить сны с реальностью. Вот и рост агентности.

Но вот само желание что-то сделать от чеклиста не появляется. Не слишком инициативного сотрудника чеклист может заставить что-то сделать, что без чеклиста просто не будет сделано, забыто, инициатива «сделать» без чеклиста по совокупности причин не будет проявлена. А вот уже достаточно агентному, автономному в выполнении каких-то сложных работ сотруднику чеклист поможет в разы увеличить масштаб изменений, которые агент проводит в окружающем мире (чеклист удержит описание сверхсложных методов работы даже не в голове, а в экзокортексе, даст сработать в сложных проектах коллективно, уменьшит количество ошибок участников проекта, которые они делают от усталости или отвлечений в обычных условиях полной внешней неразберихи и постоянных изменений в проектной ситуации).

Беда в том, что вот этих многочисленных действий/работ для достижения нужных состояний, непрерывно сползающих к предыдущим состояниям «неготовности» (жизнь меняется, состояния объектов тоже меняются — по самым разным причинам), накапливается много. Это одна из причин, почему прикладные инженеры не любят такой 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 (и, соответственно, в нашем руководстве) намеренно «мутные», неопределённые и расплывчатые. Авторы стандарта говорят, что эта «мутность» поощряет команду провести обсуждение этих формулировок, чтобы адаптировать к индивидуальным особенностям проекта и получить примерно одинаковое понимание этих формулировок всеми членами команды. Эта адаптация — необходимость, она не опциональна, она должна быть проведена.

Адаптация включает изменение всех приведённых в нашем руководстве примеров: меняются и число, и виды, и имена-термины для областей интереса, альф и подальф графа создателей, состояний в графе состояний каждой альфы, формулировок контрольных вопросов по достижению отдельных состояний, числу уровней составляющих состояний и тем самым число уровней контрольных вопросов. Тут мы приводим самые общие формулировки уровня мета-мета-модели. Адаптация проводится так, чтобы учесть мета-модели предметных областей проекта («как в учебнике» и «как на предприятии»), не нужно использовать прямые формулировки из нашего руководства! Если работаете с самолётом, то альфа будет не «воплощение системы», альфа будет «самолёт», если с мастерством — альфа не «воплощение системы», а «мастерство», если создатели — то это «самолётостроители» и «учителя» соответственно.

Нет слов предметной области — не адаптировано! А без адаптации к конкретным предметным областям проекта и уровню опыта конкретной команды чеклисты (области интересов, альфы и подальфы, их состояния, контрольные вопросы многих уровней) «прямо из руководстве по методологии» и уж тем более «прямо из стандарта OMG Essence» использовать нельзя! Тексты из руководства тут дают только типы мета-мета-модели, они нужны как средства методолога для наведения внимания прикладной команды на важные объекты в их предметной области!

Команда должна договориться, за чем следить в проекте, кто в проекте берёт на себя ответственность за продвижение состояний какой альфы — и иметь для этого понятные ей формулировки. Эти альфы (и их подальфы) становятся затем предметами кейсов::работы (подробней обсуждается в руководстве по системному менеджменту).

В разговоре про альфы необязательно каждый раз произносить слово «альфа». Как не говорят «система самолёт», «система чайник» (но добавляют слово «система», когда хотят подчеркнуть рассмотрение как системы), так в проекте не говорят «альфа работа» и «альфа команда», но говорят «работа» и «команда». Слово «альфа» добавляют, только когда хотят подчеркнуть именно работу с альфой как типом мета-мета-модели, если ваш собеседник понимает этот «птичий язык», проходил руководство по методологии. Этим собеседником можете быть и вы сами, скажем, при мышлении моделированием — полезно явно указывать типы. Но машинка типов у вас должна в мозгу работать «беззвучно» и при разговорах с другими людьми в терминах мета-модели: вы должны отслеживать в своей и чужой речи упоминание альф и подальф. Помним, что при адаптации они будут звучать вслух для собеседников как всем понятные объекты метаС-модели или метаУ-модели. Мета-мета-модель будет вами «приговариваться в уме» как типы к понятиям мета-модели при проектировании чеклистов.

Ещё раз повторим то же самое, только чуть более многословно. Мы предлагаем считать, что вообще все рабочие проекты — это проекты по изменению мира (инженерные), поэтому думать о всех этих проектах надо по-инженерному (те же типы мета-мета-модели, что и в наших руководствах инженерной серии), но использовать приемлемую для целевых предметных областей терминологию в именовании многочисленных альф и подальф (типы мета-модели: или «как в учебнике», или даже «как на предприятии, в ситуации»). Мышление в терминах мета-мета-модели нужно вам самому для того, чтобы в слабо знакомых вам ситуациях иметь хоть какое-то знание о важных объектах этой ситуации. Это абстрактное знание, его немного, но это уже хороший чеклист: про каждую систему вы сходу должны подумать про её воплощение, про системное описание, про метод работы и работу (не про описание метода работы и описание работы, а про них самих — про поведение системы в мире! Это само поведение системы, а не описание этого поведения!). И думать о графе создателей и тем самым о зонах интереса — к вашей системе, к создателю вашей системы, к целевой системе, к клиентуре, инвестуре и так далее. Думайте одинаково (отмечайте типы мета-мета-модели задействованных в самых разных проектах объектов, находите объекты пропущенных в мышлении и действии типов объектов — но только «в голове» и ваших собственных моделерах, не произносите терминов мета-мета-модели и не пишите их в операционном софте сотрудников). В общении с сотрудниками и в операционном софте сотрудников не говорите и не пишите типов мета-мета-модели, заменяйте их типами метаС-модели или метаУ-модели. Если у вас в голове «целевая система» как альфа, которую вы отслеживаете, в речи не говорите ни слова «альфа», ни слова «целевая система», а говорите тип системы, взятый в предметной области: самолёт, мастерство, игровой сеанс. Но вы обязаны делать это осознанно: если произнесли «самолёт», то должны понимать, что это целевая система, имеется в виду воплощение системы, оно проходит самые разные состояния по ходу проекта, но главное из них — это во время использования, то есть состояние, когда самолёт летит, а ещё этот самолёт — физический объект, он описан в его разделении функциональные, конструктивные, пространственные, стоимостные части, и ещё он является предметом какого-то инженерного метода разработки. Сотрудникам необязательно знать, как вы думаете, но им обязательно надо знать результаты вашего мышления. Вот эти результаты и говорите на языке мета-модели, не произносите слов мета-мета-модели.

Конечно, если сотрудники владеют мышлением и работой по нашим руководствам, разговор с ними пойдёт много быстрее и легче (мышление в терминах мета-мета-модели универсальней и компактней), но если они не освоили работу по нашим руководствам, разговор с задействованием терминов мета-мета-модели пойдёт в разы медленней, вас будут не понимать и считать странным: слишком большое понятийное расстояние³¹⁴. Умным, а не странным, вас будут считать за высказывание результатов мышления на языке мета-модели, то есть принятом в предметных областях вашего проекта языке (метаУ-модель) или даже принятом на вашем предприятии языке (метаС-модель). А типизацию этой модели типами из руководств по рациональной работе, системному мышлению, методологии, системной инженерии, инженерии личности, системному менеджменту — оставьте при себе.

Заметим, что для инженерии есть множество предметных областей, и язык разговора о каждой из них будет разным — причём даже слово «инженер» может не применяться. Например, инженеров личности мало кто называет инженерами, инженеров сообществ мало кто называет инженерами. Инженеров предприятия мало кто называют инженерами предприятия, чаще их называют менеджерами.

Менеджмент как инженерия предприятия всё-таки более-менее одинаков в этом плане, хотя и там огромная разница в понятиях и терминологии той или иной школы менеджмента. Хотя многим сотрудникам будут знакомы типы объектов из нашего руководства по системному менеджменту, будьте внимательны: они могут эти типы определять совсем не так, как определяете их вы на основе материалов наших руководств. «Операционный менеджмент» примерно один и тот же в инженерии, медицине, торговле, образовании. Но ваши сотрудники могут даже не знать, что они занимаются управлением кейсами, хотя полдня будут проводить с issue tracker. Поэтому каждый раз уточняйте язык, на котором идёт разговор с сотрудниками: правильно будет говорить на языке метаС-модели, а если вы хотите поменять эту модель — обсуждайте это на языке метаУ-модели. Мета-мета-модель из наших руководств держите только у себя в голове (усиленной вашим личным экзокортексом) и говорите на этом «птичьем языке» только с сотрудниками и коллегами, которые этот язык мета-мета-модели уже хорошо понимают. Помним о метанойе: то, что для вас кажется естественным, вы когда выучили и у вас даже когда-то были трудности в обучении. У других людей так же, плюс недоверие ко всему новому. Вот и не говорите им новых для них слов типов объектов, чтобы не вызывать недоверие. Но произносите эти слова у себя в уме и в своих собственных моделях: у вас будет меньше ошибок. Внимание будет на важном, рассуждения будут о важном, а не о чём-нибудь. И ещё вы поможете чеклистами удержать внимание на важном вашим коллегам.

Моделирование: распределение времени на целевую систему, надсистемы, создателя

Оцените, сколько времени (в процентах от общего времени, должно в сумме получиться 100 процентов) вы занимаетесь в рабочем проекте изменением состояний каких альф. Сделайте для себя вывод: кем вы себя считаете (по роли), кем вас считают окружающие (по роли), чем вы на самом деле занимаетесь (по роли).

Состояния альфы и артефакты/рабочие продукты

Состояния альф можно узнать не сами по себе, «умозрительно», а посмотрев на состояние связанных с ними артефактов/рабочих продуктов. С альфами происходит мышление, с рабочими продуктами/артефактами (в том числе с документацией, но и с воплощением системы непосредственно, а также с инструментами поддержки дисциплин самых разных методов) происходит работа по изменению рабочих продуктов. Конечно, для описания (view для согласования каких-то предметов интереса, то есть набор разных моделей) состояния альфы должен быть использован какой-то метод описания/viewpoint: мета-модель предметной области проекта (не наша мета-мета-модель из руководства, она только помогает вам найти эти альфы в проекте, а метаУ-модель «из учебника предметной области» или «метаС-модель», как она понимается в ситуации конкретного проекта) и принципы создания модели, методические указания по моделированию «предмета интереса»/concern.

Чтобы обсуждать состояние функционального физического объекта «забивало», надо обсуждать состояние играющих его роль конструктивов — молотка, микроскопа, камня (то, что было выбрано как аффорданс). И дальше надо понимать, что именно там интересует — степень ржавости бойка молотка с заведомо удобным хватом рукоятки против степени неудобности хвата для камня при неприменимости к камню ржавости.

Из руководства по системному мышлению помним, что предмет интереса моделируется задействованием какого-то метода описания, а само описание документируется, чтобы внимание коллектива на нём стабильно удерживалось независимо от уровня отвлечений людей в этом коллективе на разные другие проекты, а также чтобы особенности кривых забывания не влияли на точность описания — это и есть коллективная собранность. Поэтому в реальной обстановке обсуждение ведётся не только вполне материальных предметов как альф (например, альфы «система»), но и свидетельствующих о состоянии нематериальных/абстрактных альф вроде «описание системы» рабочих продуктов/артефактов, например, документов (в том числе и электронных, в том числе и баз данных какого-то софта, в том числе с использованием специализированных и универсальных моделеров).

Документирование по сравнению с чисто устной работой «с голоса» имеет:

• Достоинства, например, возможность коллективной и независимой проверки моделей, возможность помнить о деталях через долгое время после обсуждений, моделирование только важного и т.п.

• Недостатки, например, лишняя работа, требующая времени — в простых случаях и при малом числе участников проекта иногда ведь хватает и устных обсуждений с неформальными устными же замечаниями, особенно если речь идёт не о крупных вопросах (как для чеклистов), а о различных мелких нюансах, которые тут же учитываются — и о них можно забыть.

Порог сложности, когда от «разработки проговариванием» и «мышления проговариванием» надо переходить к полноценному документированию проекта и «мышлению моделированием», оказывается очень низким. Поэтому смело говорим: «не пишешь — не думаешь!».

Люди забывчивы и невнимательны больше, чем они осознают. А ещё у них часто ложное чувство понимания: при коллективной разработке замечание «поставь дверь вот сюда» будет понято, но вот в какую сторону будет открываться дверь — вот это не будет обсуждено, дверь мастер установит уж как ему подскажет его опыт, и это может быть весьма неожиданный опыт.

Каждая команда выбирает свой уровень документирования происходящего в проекте, это тоже вопрос договорённостей в команде. Этот выбор делается указанием методов описаний и рабочих продуктов с этими описаниями. Скажем, для альфы внешние проектные роли в состояниях «определены» и «есть соглашение по исполнителям» могут быть отражены в документе подходящего моделера. Вы должны уметь использовать для моделирования состояний альф и чеклистов разные моделеры, понимать принципы моделирования, а не привыкнуть к одному моделеру конкретного вендора софта. Софт тут как ручка писателя: некоторые пишут лучше, некоторые хуже, но будет ли написанное претендовать на Нобелевскую премию по литературе, зависит не от ручки. С моделированием альф то же самое: от использованного моделера качество моделирования зависит меньше всего.

Вот пример описания контрольных вопросов по достижению состояния «признаны» альфы «внешние проектные роли»:

Состояние «Внешние проектные роли признаны»

Конечно, для каждого проекта командой адаптируются как сами критерии достижения состояния, так и формы документирования их прохождения. А ещё указываются адреса всех этих документов (хотя сегодня поисковые системы, в том числе корпоративные поисковые системы работают настолько хорошо, что адреса можно не указывать, а находить нужные описания интеллектуальным поиском).

Используемые в проекте методы создания и развития системы (варианты инженерного процесса) часто сами оговаривают методы описания важных объектов. Эти методы и определяют альфы, за которыми нужно следить в ходе инженерного проекта, и рассказывают, каким методом эти альфы лучше описывать, чтобы по описанию было ясно их текущее состояние.

В обсуждениях состояния проекта используют главным образом альфы, мышление идёт с ними. Но работаем в проектах с альфами как физическими объектами, а для альф абстрактных объектов — с отражающими/свидетельствующими/evidence состояния альф документами (в том числе базами данных какого-то корпоративного или инженерного софта). Это всё артефакты/«рабочие продукты», а не описания, свойства или поведения материальных объектов. Легко обсуждать готовность документа: красоту шрифта, число страниц или экранов, была ли литературная редакция, или нет. Это можно делать, абстрагируясь от содержания. Обсуждение альфы требует вчитаться в документ — и готовым или нет будет сам документ, это неважно, обсуждается состояние того, что в документе описано: состояние альфы, а не состояние рабочего продукта. Если инженерное решение не принято, то оно не принято — это про альфу. Если инженерное решение принято, то оно может быть отражено в рабочем продукте с разной степенью детальности, разной степенью аккуратности и подробности. Но главное — решение будет уже принятым. Готовность (состояние) альф и готовность (состояние) рабочих продуктов поэтому обсуждаются раздельно. Если альфа «исследовательская гипотеза» в исследовательском проекте в состоянии «сформулирована», но свидетельствующего документа ещё нет, то состояние альфы достигнуто, а рабочий продукт не готов. Что делать с этой ситуацией — это определяется каким-то конкретным коллективом. Скажем, «у нас это нормально, верим на слово» скажет один коллектив, «приоритет минимума документов, будем работать дальше с голоса, уж кто что запомнил из рассказанной на совещании гипоОКтезы». Другой коллектив скажет: «не записано — значит не проверено, а то и вовсе нет — ибо никаких следов нет, работать дальше невозможно».

Уровень бюрократии (типовых решений, выполняемых с использованием стандартизованного набора рабочих продуктов) можно и нужно выбирать в зависимости от профиля рисков проекта. При этом профиль рисков проекта меняется со временем, так что эти решения должны постоянно пересматриваться, бюрократию тоже можно считать альфой!

Рабочие продукты, свидетельствующие состояния альф (включая подальфы) проекта, можно делать проще или сложнее: инженерный процесс может быть самым разным по сложности, но он должен быть достаточным для снижения риска утери внимания за важным в проекте, опять-таки читайте книжку «Checklist manifesto» Atul Gawande.

Системное мышление и методология подразумевают письменную работу, мышление не только в биологических головах, но протянутое «из головы» во внешний физический мир! Кроме того, в проектах важно мышление организации/команды/коллектива/предприятия, оно требует организации коллективной памяти, что делается сегодня компьютерными специализированными моделерами (например, машиностроительными САПР), и всё больше — универсальными табличными моделерами. Нет коллективного экзокортекса — значит, нет надёжного коллективного поддержанного инструментарием мышления, есть мышление, ограниченное «голым забывчивым и невнимательным мозгом» людей, которым ещё и трудно договориться «с голоса» (каждый поймёт потом договорённость по-своему).

Как работают с моделью графа создателей в форме чеклиста

Когда говорим о моделировании графа создателей, то имеем в виду прежде всего не диаграммное представление в разных «рисовалках» вроде MS Visio, Figma или даже yEd (мы готовили иллюстрации текущего раздела как раз с использованием «рисовалки для графов» yEd), не диаграммное представление в моделерах каких-то бизнес-процессов типа Business Studio или ArchiMate (они поддерживают строгую типизацию элементов диаграммы), а представление в разного сорта текстовых (аутлайны, но не представление аутлайна в виде MindMaps) и табличных моделерах. Современный операционный софт обычно ровно такой: он представляет богатые возможности редактирования длинных списков, представленных таблицами.

Конечно, можно использовать и более простые формы, например, список областей интереса или даже альф мелом на доске или даже назначить пальцы на руке отображающими три-четыре области интереса или альфы. Но обычно используются всё-таки более богатые среды моделирования, позволяющие представить множество чеклистов — и сделать это в привычной для работника среде.

Самое простое использование модели графа создателей — это структурирование отчёта о ходе проекта (progress report). Нужно просто дать краткую содержательную характеристику состояния избранных вами альф избранных вами областей интереса в графе создателей. Progress report нужен для того, чтобы вся команда (и в порядке надзора/governance — её создатели) коллективно представляли, в каком состоянии каждая альфа, какие есть инженерные проблемы и что с ними можно сделать, какие риски несоблюдения сроков и бюджета есть в проекте.

Модель графа создателей (повторим: необязательно в виде диаграммы! Это может быть, и даже не «может быть», а должен быть набор таблиц в универсальном/табличном моделере!) удерживает коллективную собранность в проекте, гарантирует основной посыл чеклистов: подумать о состоянии важных объектов внимания в проекте, с нужным разрешением в плане точности моделирования, не пропуская ни одной области интереса для системы в графе создателей, ни одной альфы в каждой области интереса, ни одной подальфы, ни одного их состояния, ни одного контрольного вопроса для составляющих этих состояний на много (сколько надо, столько и будет!) уровней. А потом переходим к планированию работ для достижения этих состояний и отслеживанию не только выполнения этих работ, но и фактического достижения этих состояний альф (ибо работы могут быть выполнены, а нужного состояния не будет).

Пропущенная в отчёте о ходе проекта альфа часто означает совсем не то, что её состояние плачевно и докладчик почему-то его хочет намеренно скрыть. Да, такое бывает, но редко. Обычно «миром правит не тайная ложа, а явная лажа», и причина пропуска в отчёте рассказа о состоянии какой-то альфы означает, что просто про эту альфу давно не думали, её состояние (включая её подальфы) давно не оценивалось, о необходимости осознанного и структурированного внимания к ней просто забыли за какими-то другими делами. И это означает, что самое время подумать, что с такой пропущенной альфой и её подальфами происходит. Progress-report — это прохождение чеклиста уровня зон интереса и альф.

При подготовке отчёта отследите пропуски описания состояния дел в проекте по каким-то альфам или подальфам и немедленно подумайте (чаще всего это означает не просто «подумать», а сначала получить дополнительную информацию, поговорить с самыми разными исполнителями ролей в команде, и внешними проектными ролями), что с ними происходит и какие дела нужно в связи с этим происходящим сделать. Как с любыми чеклистами, в 9 случаях из десяти всё оказывается в порядке, а в 1 случае это предотвращает неминуемую катастрофу всего проекта.

Иногда проблема оказывается даже в том, что непонятно, по каким рабочим продуктам можно узнать, что происходит с альфой, и какой исполнитель какой роли об этом может рассказать: вот это самое тревожное, что может быть, ибо если не подумал, то не сделал. Если не сделал, то система не будет успешна, разве только случайно.

Моделирование в универсальном моделере графа создателей даже только адаптированными основными альфами без перехода к подальфам полезно не только для того, чтобы потом делать регулярный отчёт о ходе проекта, но и для того, чтобы давать полезный содержательный отклик по таким отчётам, замечая не то, что сказано, а то, о чём не сказано. Так, если в отчёте не сказано ни слова про организацию/коллектив/команду::альфа, то в качестве содержательного полезного отклика на progress report обязательно нужно задать вопросы про состояние команды (уточняя прямо по контрольным вопросам этих состояний). Может выясниться много важного неожиданного (ключевые члены команды надумали уходить, сотрудничества уже три дня как нет по разным причинам и т.д.). Эти вопросы по состояниям пропущенных в мышлении о проекте альф не будут случайными вопросами. Основные/kernel альфы ведь эти выбраны не случайно, а отражают опыт многочисленных разработок. Если вы используете чеклисты на основе альф, то вы уже многое знаете о проекте, даже если вы первый раз встречаетесь с проектом!

Задавать вопросы прежде всего по выпавшим из внимания коллектива альфам (то есть важным объектам внимания в проекте) — это и есть управление коллективным вниманием в проекте, гарантирование коллективной собранности. Для этого нужно:

• использовать компьютерную память для моделирования графа создателей в виде шаблонов чеклистов

• модель графа создателей (шаблоны чеклистов) должны быть адаптированы к предметной области

• кроме шаблонов чеклистов надо иметь описания методов (регламенты, инструкции, корпоративные стандарты) в виде, удобном для загрузки в головы сотрудникам и в операционный софт (а не в виде, который удобен для методологов)

• чеклисты и регламенты как «хелп» к чеклисту должны быть в операционном софте сотрудника (а не любимом моделере методолога)

• приоритет реального использования чеклистов перед «централизацией». Это вполне может быть распределённая модель, трудно централизуемая. Объединение всех чеклистов и взаимные сверки — это вопрос айтишников, а не вопрос приспособляемости работников, барьеры в использовании чеклистов на рабочих местах надо снижать.

• Работники должны быть обучены работе по регламентам с использованием чеклистов (и вы должны пройти первый раз чеклист с ними — заодно исправите ошибки и внесёте уточнения)

• Должен быть организован надзор (и при этом не стоит ожидать, что все сотрудники будут пользоваться чеклистами. Надо будет заняться лидерством, но вполне возможно, что надо будет показательно уволить тех людей, кто не в состоянии работать с чеклистами — они и другие важные дела тоже могут иногда делать, иногда не делать, надёжность их работы под вопросом.

Потом вы должны регулярно (раз в день, раз в неделю, но уж точно чаще раза в месяц!) проходиться по верхнеуровневым/основным альфам, удерживать внимание коллектива на всех этих альфах, а не только на тех подальфах и некоторых контрольных вопросах к их состояниям, которые у них прямо сейчас в срочной работе, о которых они и так помнят. Ибо пока срочно работаешь с одним — быстро забывается и сгорает совсем другое. В проектах нужно быть очень внимательными, причём коллективно внимательными.

Ещё один вариант использования системной схемы проекта — это понять, какие виды мастерства у команды есть, а какие отсутствуют. Распечатайте списки областей интереса графа создателей и списки альф с их состоянием и контрольными вопросами (адаптированные!) в этих зонах интереса и дайте участникам проекта отметить крестиком те альфы, за состояние которых каждый из них планирует в этом проекте отвечать, играя какие-то роли. Если какие-то альфы остались без своих крестиков — то проект ждут большие риски, и это надо немедленно обсудить: кто в команде берётся отвечать за состояния этих «бесхозных» альф?

Вместо «опроса» может быть сразу осознанное принятие ответственности за какие-то альфы (или подальфы) в проекте. Проект как целое разбивается на изменяющиеся по его ходу объекты, требующие особого внимания (альфы, и ориентир тут для начальной разбивки — основные/kernel альфы из основных/kernel областей интереса), и команда проекта принимает индивидуальные ответственности за эти объекты — и коллективную ответственность за согласование действий по их поводу.

Помощь методологии с её опорой на системный подход в том, что ни на один момент не теряется внимание к самым разным системам графа создателей, их описаниям, методам их работы (их функциям), их работам. Это моделируется чеклистами достижения состояний этих объектов коллективного внимания. При частном разбирательстве с одной «горящей» и «проблемной» альфой остальные альфы никуда не деваются, они отмоделированы, об их состояниях в проекте помнится, к ним обязательно вернутся, обязательно проверят их состояние. Число неожиданностей в проектах при таком использовании чеклистов много, много меньше, чем в проектах без использования чеклистов на базе альф.

Подальфы

Подальфы и их состояния порождаются командой по потребности, когда команда понимает, что внимания к ситуации на уровне альф не хватает, и нужно внимание к дополнительным объектам, от которых зависит продвижение альф по их состояниям. Подальфа так и определяется — это альфа, связанная с другой альфой отношением «если состояние подальфы продвигается, то и состояние её надальфы продвигается». Более того, у каждой альфы (в том числе у подальф, у которых тот же тип «альфа») могут быть свои подальфы, а одна подальфа может быть подальфой нескольких альф и подальф. Примеры этих подальф можно брать в самом стандарте OMG Essence, можно брать в разнообразной литературе. Прежде всего тут нужно указать на разработки Ivar Jacobson International, они предложили наборы альф с их состояниями и контрольные вопросы этих состояний для самых разных практик, особенно для гибких методологий³¹⁵.

Основных альф различных областей интереса из модели графа создателей как объектов внимания в проекте не будет хватать, слишком маленькое разрешение, нужно видеть в проекте больше деталей. Поэтому увеличиваем разрешающую способность нашего внимания, для чего команда берёт эти подальфы из дисциплин/теорий/принципов принятого ей инженерного процесса. Дальше с подальфами всех уровней работа идёт ровно такая же, как с любыми другими альфами: если их брали из литературы, то они обязательно адаптируются к предметной области проекта, для них формулируются состояния (которые тоже организованы в какой-то граф состояний), контрольные вопросы для составляющих этих состояний — и этих вопросов для составляющих состояний может быть ещё несколько уровней. Это всё организуется в шаблоны чек-листов, затем в операционном софте реализуются сами чеклисты для каждой ситуации (скажем, для каждого подрядчика делается отдельный чеклист, например, в формате строки таблицы). Дальше для перевода состояний подальф в нужном направлении в графе состояний этой подальфы, как и в случае любой альфы, предлагаются методы работы, работы планируются в виде кейсов, а затем ведутся работы этих кейсов.

Например, в практике управления проектами методом критической цепи вводят для альфы «работа» подальфу «буфер проекта» (project buffer) и отслеживают затем её состояние — сначала этот буфер проекта создаётся, потом потихоньку расходуется в ходе проекта. Ответ на вопрос «в каком состоянии работы проекта?» (вопрос про альфу «работа») может включать в себя отдельный рассказ про состояние «буфера проекта» (подальфу альфы «работа»). Вот именно поэтому подальфа определяется не через отношение часть-целое, онтологически «буфер проекта» уж точно не часть «работы». Онтологически буфер проекта — это описание работы, хотя можно трактовать и так, что это описание «потенциальной работы». В любом случае, трудно представить «буфер» истинной частью «работ». А вот как подальфа — да, это удобно.

Подальфа — тоже альфа! Так же, как подсистема — тоже система, подкейс — тоже кейс. Разве что отношение не «часть-целое», а определённое более хитрым образом. Всегда проверяйте, какого типа отношение имеется в виду, когда применяют приставку «под-»!

Вот пример подальфы «подрядчик» для альфы «команда» (навскидку: обратили внимание на «под-»? Какого там типа отношение с «рядчиком»³¹⁶? А в субподрядчик какое отношение «суб-» с подрядчиком? Особого смысла эти рассуждения не имеют, это просто проверка — обратили ли вы внимание на предыдущий абзац).

Подальфа «подрядчик» альфы «команда» была отмоделирована автором руководства для крупной строительной компании, занимающейся сооружением сложных инженерных объектов, отсюда и специфика её состояний, это адаптированная для этой предметной области альфа (обратите особое внимание, что работы тут считаются выполняемыми однократно, «по-старинке», в строительстве по-другому пока просто «не понимают»):

• Признан — обоснование аутсорсинга есть; концепция использования для подсистемы есть; ожидания к гарантийному обслуживанию и ремонтным работам есть; понимание по технологиям работы есть; сроки поставки определены; критерии приёмки результата есть; оценка возможной цены есть.

• Выбран — технико-коммерческие предложения получены; переговоры с кандидатами проведены; технико-коммерческие предложения оценены; подрядчик нами выбран.

• Привлечён — валютные, сроков поставки, качества и прочие риски оценены; договор с учтёнными рисками подписан; аванс перечислен; необходимая документация для начала работ передана; уведомление о начале работ получено; процедура коммуникации команды с исполнителями установлена.

• Работы идут — надзор за работами установлен; запросы обеих сторон учитываются; запросы обеих сторон своевременно решаются; график работ соблюдается; технология работ соответствует ожидаемой; коммуникация команды с исполнителем не прерывается.

• Работы приняты — уведомление об окончании работ получено; испытания проведены; претензий к качеству работ нет (претензии сформулированы и устранены); акты проведения успешных испытаний подписаны; результаты работ доставлены на место; документация передана; монтажные работы произведены; пуско-наладочные работы проведены.

• Работы закрыты — акт приёмки-сдачи подписан; деньги перечислены; никаких дел к подрядчику нет; гарантийные и сервисные работы производятся; документация архивирована.

Поскольку это описание подальфы — мета-модель предметной области, а не мета-мета-модель из нашего руководства «для всех видов проектов», для других проектов (например, подрядчиков в проектах создания какого-то корпоративного софта) состояния «подрядчика» были бы совсем другие.

Регулярная проверка сделанного и не сделанного по такому чеклисту существенно снижает риски. Поскольку люди не компьютеры, один раз из десятка важная работа просто не делается, «по совокупности причин»: просто в силу отвлечения внимания или надежды, что какую-то важную работу сделает кто-то другой в команде. И обращение к чеклисту состояний альфы, подальфы (прохождение по списку контрольных вопросов) может спасти ситуацию.

По всем проблемам, обнаруженным в ходе рассмотрения состояния альф как чеклиста, планируются решающие эти проблемы работы. Этим работам выделяются ресурсы в соответствии с принятой практикой управления работами (например, для документирования заданий на эти работы используется трекер, а для запуска в работу практика TameFlow). Затем эти работы будут двигать состояния всех альф в их взаимосвязи в направлении к успешному завершению проекта, а новые проблемы будут своевременно выявляться опять же с применением отмоделированного в виде набора чеклистов графа состояний.

Например, если для альфы «подрядчик» работы приняты (предпоследнее состояние этой альфы, мы даже не пишем тут кавычки, чтобы подчеркнуть, что это понятие с типом «состояние альфы»), то работы закрыты (последнее состояние альфы) будут только после подписания акта приёмки-сдачи (первый вопрос чеклиста). Так что порождаем задание подписать акт, записываем его в трекер как task/задачу (работу, которая может быть назначена конкретному исполнителю и имеет конкретный проверяемый результат), назначаем кого-то выполнить эту задачу. Эта работа не будет забыта, это и есть управление коллективным вниманием в проекте. В этом и смысл использования чеклистов с проверкой и отслеживанием состояний альф и подальф.

А откуда берутся альфы верхнего уровня? Из системного мышления и методологии: что скрывается за этими альфами, подробно на сотнях страниц обсуждалось в наших руководствах. Системное мышление и методология (как и остальные фундаментальные методы мышления интеллект-стека) занимаются управлением вниманием в сложных проектах, меняющих физический мир.

А теперь подумайте, как бы вы отмоделировали работу с альфой «подрядчик» из текущего раздела, в ситуации, когда непрерывно открываются новые обстоятельства, а работу принципиально нельзя выполнить как однократное выполнение требований. Как бы вы перестроили организацию работ с подрядчиками в таких условиях? Какие чеклисты бы для этого создали?

Множество подальф появляется, когда вы начинаете заниматься моделированием воплощения системы: каждая отдельная модель и каждое их согласованное (без конфигурационных коллизий) объединение может быть выражено подальфой с каким-то своим набором состояний.

Цифровые двойники (digital twins) — информационные/цифровые модели систем (физические двойники, то есть воплощения системы), существующие на всём протяжении их жизненного цикла, особенно включая эксплуатацию. В наших примерах моделирования графа состояний мы вместо альфы «описание системы» для целевой системы прямо говорили «цифровой двойник».

В реализации это может быть сеть цифровых двойников/digital twins network, реализующую цифровые двойники для подсистем как физических двойников.

Это всё можно считать альфами, проходящими свои состояния. Но если пройдём на уровень ниже, уровень подальф, то получим как целый ряд моделей по самым разным методам описания/viewpoints времени эксплуатации (это особо подчёркивается по сравнению с машиностроительными или строительными PLM-моделями, часто не доходящими до эксплуатации), так и целый ряд моделей, использующихся во время создания: все эти 3D-модели, кинематические, электрические, тепловые и прочие инженерные модели.

Цифровая нить (digital thread) — это инструменты и метод федерирования-унификации-интеграции данных, обычно на основе так называемых семантических моделей данных (semantic data models), которых довольно много в инженерии, связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. «Железный» инженер (машиностроитель или строитель) старой закалки скажет «интеграция данных жизненного цикла» и помянет множество PLM (а если это не машиностроение, а корпоративный софт, то может помянуть и «корпоративную шину данных»), менеджер новой закалки скажет «цифровая нить» и помянет PLM, ERP, EAM и даже CRM (и ещё довольно много «трёхбуквенных сокращений»³¹⁷). И, поскольку «цифровой — это новый информационный», то заметят, что для какого-нибудь здания или моста кроме BIM (building information model) цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь «искусственный интеллект» обнаружения аномалий для ремонта по состоянию. Инженеры старой закалки продолжают говорить «управление информацией» или «управление данными», их язык «цифровой нити» не увлекает, хотя менеджерам эта метафора очень нравится.

Так, если нужно сшить между собой мультифизическую модель (модели нескольких физик — механическую модель, электрическую модель, тепловую модель, акустическую модель и т.д.), то инженеры будут говорить управление данными имитационного моделирования/SMD/simulation data management, а менеджеры старой закалки предпочтут говорить управление информацией (имитационного/мультифизичного) моделирования/simulation information management (но говорят так довольно редко, менеджеры до этих тонкостей уже не доходят, они больше про «нить»).

Цифровая инженерия/digital engineering — это создание цифрового двойника путём сплетения цифровой нитью различных его моделей, экземпляра его физического двойника и цифровых двойников окружения. Цифровой инженерией занимается цифровой инженер/digital engineer, причём знания цифрового инженера::роль должны быть настолько широки (вся просто инженерия и всё просто айти), что его оргроль часто выполняется обычно командами/оргзвеньями из нескольких человек, и часто коллективами из многих оргзвеньями. Ещё один синоним для цифровой инженерии: моделеориентированная инженерия/MBE (model-based engineering).

Современные инженерные проекты растут в сложности, число одновременно удерживаемых объектов внимания в них растёт, простые формализации становятся сложнее. Это означает, что число подальф растёт, и для удержания всех их во внимании нужно использовать экзокортекс: самые разные компьютерные модели, включая цифровых двойников, связанных в сети и привязанных к датчикам и актуаторам/эффекторам физических двойников цифровыми нитями.

Цифровые двойники и цифровые нити оказались очень удобным способом говорить о системном моделировании³¹⁸. Из инженерии этот подход перешёл в самые разные другие предметные области (в медицине речь идёт о цифровом двойнике пациента, в педагогике о цифровом двойнике ученика/студента, и так далее). Эта идея и терминология настолько прижились, что говорят о цифровых двойниках безмасштабно: для всех видов систем (вещество, киберфизические системы, существо, личность, организация, сообщество, общество, человечество).

Основная мысль подраздела в том, что надо отслеживать состояния не только воплощения системы, но и описаний системы — надо отслеживать ход моделирований, которых в современных инженерных проектах множество самых разных видов. Для этого используйте подальфы описания системы, и работайте с этими подальфами письменно — ведите изменение их состояний в каком-то универсальном моделере, а работы по изменению этих подальф (достижение какими-то моделями цифрового двойника тех или иных состояний) ведите в issue tracker. Вы наверняка и так это делаете, но главная мысль тут — обо всех этих подальфах думать можно (и даже нужно) абсолютно одинаково, действовать по их поводу можно абсолютно одинаково, моделирование их на уровне мета-мета-модели можно вести одинаково. Уже на уровне мета-модели там все слова-термины и набор типов будет разный, но вас не должно это смущать. Какой бы ни был набор типов, какие бы ни были слова — вы сможете узнать знакомый вам набор альф и даже какие-то подальфы.

Моделирование: адаптация модели графа создателей

Выполните адаптацию модели графа создателей в виде чеклистов для вашего проекта. Начните с тех, которые есть в таблице, но желательно и продолжить:

TEST Адаптация модели графа создателей

Менеджер проекта думает, как ему отслеживать прогресс разработки сложной инженерной системы. Ему нужно отслеживать для этого:

+++ Состояние альф «Описание целевой системы» и «Воплощение целевой системы» ### Да, именно состояния этих альф позволяют увидеть, далеко ли продвинулась разработка. И для этого нужно отслеживать документы, свидетельствующие состояние описания системы и самой системы в её физическом воплощении.

--- Отчёт о затраченных инженерами ресурсах и времени выполнения работ ### Нет, смысл происходящего в инженерии целевой системы из данных о работах понять трудно. Например, могло быть потрачено три месяца времени на тупиковый вариант концепции системы: разработка при этом не продвинется, но время таки будет потрачено (и это время обязательно надо потратить! Инженерия подразумевает, что будут проработаны и тупиковые варианты — иначе тупиковость этих вариантов не понять!).

+++ Протоколы обсуждений инженерами встреченных трудностей на научно-техническом совете ### Да, это полезный рабочий продукт, позволяющий отследить изменения альф «Описание целевой системы» и «Воплощение целевой системы»

--- Состояние альфы «Описание организации проекта» ### Нет, состояние этой альфы — очень плохой индикатор для оперативного контроля инженерных проблем с целевой системой, это альфа из области интересов создателя.

На вопрос «Как дела?» команда проекта рассказала, что они уже трижды достигали состояния «Готово» для альфы «Воплощение целевой системы», но потом откатывались к состоянию «Демонстрируема». Как это возможно?

--- Команда что-то путает, пешки назад не ходят ### Нет, это вполне возможно, состояния альф представляют собой произвольный граф, по которому возможно движение в любую сторону, в том числе и откаты назад.

+++ Команда несколько раз не проходила испытания в ходе инженерного обоснования, поэтому переделывала готовую систему ### Да, так всё и было, именно в случае неудовлетворённости заказчика в использовании системы не удаётся продвинуться дальше состояния «Готово».

--- Возвраты к «Демонстрируемо» состоялись за пределами проекта, во внеурочное время ### Нет, состояния альф меняются независимо от того, рабочее время, или нет.

Команда проекта договорилась, что, вместо отслеживания для альфы «Работа» состояний «Инициирована», «Подготовлена», «Начата», «Под контролем», «Закончена», она будет использовать другой набор, более привычный для менеджера проекта (он ссылается на стандарт проектного управления, в котором используются другие названия, и менеджер проекта собирается использовать этот стандарт, а не идеи из стандарта OMG Essence). Можно ли так делать?

+++ ОК, команда в своём праве ### Да, названия альф и их состояний не просто разрешается менять, а даже рекомендуется. Они точно не догма. Названия альф, набор их подальф, их состояния, контрольные вопросы должны учитывать предметную область, а также метод работы команды. Если команда использует какой-то конкретный метод управления проектами, который по-другому структурирует состояние работ, то нужно использовать набор состояний альфа «работа» из этого конкретного метода.

--- Нет, стандарты нужно соблюдать целиком: если используете язык OMG Essence, то и все названия должны быть из него, а если иной стандарт проектного управления — то из него, не путайте людей. ### Нет, OMG Essence разрешает и даже поощряет такую адаптацию, в том числе и для лучшей гармонизации с другими стандартами, и для лучшей гармонизации с производственными регламентами конкретного предприятия.

--- ОК, если это разрешит высшее руководство ### Нет, команда инженеров и менеджер проекта могут договориться о методе определения состояния работ без дополнительных разрешений руководства.

--- Нет, команда потеряет возможность обсуждать работы ### Нет, наоборот, если все команды и менеджер проекта договорятся об этих новых состояниях альфы «работа», которые они будут отслеживать, то они смогут обсуждать работы более точно и делать в этих обсуждениях меньше ошибок из-за несоответствия привычной им терминологии и непривычной терминологии какой-то очень общей модели (мета-мета-модели нашего руководства, или мета-мета-модели из самого стандарта OMG Essence).

На совещании команды развития и проекта оценили состояние команды проекта как уже «Сформирована», но ещё не «Сотрудничает». Что им нужно сделать, чтобы перейти в новое состояние?

--- Ничего, пройдёт время, все притрутся друг к другу, можно будет отрапортовать результат — ничего специального делать не нужно. ### Нет, состояния альф сами по себе в нужном направлении меняться не будут. Нужно проводить работу лидерства, «катализировать сотрудничество» (подробнее будет в руководстве по системному менеджменту).

+++ Наметить и выполнить какие-то работы с альфой «Команда проекта» ### Да, именно это: для изменения состояния альфы нужно планировать и выполнять работы (в данном случае работы практики лидерства, чтобы катализировать сотрудничество).

Если подальфа продвинулась по её состояниям, или даже откатилась назад, что, скорее всего, произошло с её (над)альфой?

--- Ничего, они никак не связаны, это просто удобный способ группировки отслеживаемых в проекте объектов ### Нет, подальфы выбираются так, что если подальфа продвинулась или откатилась, то и надальфа тоже продвинулась или откатилась, хотя бы немного.

--- Ничего, они ведь специально создаются для отражения разных состояний разных объектов в проекте ### Нет, подальфы выбираются так, что при изменении их состояния в ту же сторону меняется состояние надальфы.

+++ Состояние надальфы тоже изменилось, но, возможно, не так сильно, чтобы гарантированно перейти в следующее или предыдущее состояние ### Да, подальфы выбираются так, что если подальфа изменила состояние, то и надальфа тоже изменила состояние, хотя это может быть и не настолько, чтобы это было следующее или предыдущее состояние.

--- Надальфа гарантированно перешла в следующее состояние ### Нет, изменение состояния подальфы изменяет состояние её (над)альфы, но обычно не настолько, чтобы гарантировать переход её в следующее или предыдущее состояние.

6. Теория стратегирования

Понятие стратегирования

Стратегирование — это метод выбора метода работы, когда не очень понятно, что надо делать. «Что делать» — это какие предметы метода надо брать и в какое состояние их приводить каким методом. Поскольку речь идёт о выборе метода работы (на выходе стратегирования — метод, дальше будет планирование, дальше будет собственно работа), то можно считать, что стратегирование изучается в рамках руководства по методологии.

Прикладные варианты методов стратегирования будут изучаться в соответствующих прикладных руководствах инженерной серии. Например, в руководстве по системному менеджменту будет рассказано про прикладное организационное стратегирование, даны шаблоны нескольких важных организационных моделей, используемых при орг-стратегировании, а также рассказано о том, как организовывать коллективное стратегирование. В руководствах программы личного развития стратегирование рассказывается в приложении к личности. Поскольку всё это разговор о методах, то стратегирование и личное, и корпоративное, и даже для каких-то не очень живых систем («что будет делать наш робот»/«каким методом будет работать наш робот») оказывается в общих чертах довольно похожим, поэтому мы тут дадим какие-то соображения по стратегированию.

Стратегирование часто начинают вообще с чистого листа — когда нет сигнатуры метода, то есть непонятно вообще, каких результатов хотим достичь, какой проект делать, какие объекты привести в какие состояния, какой системой заняться. Есть ресурсы (скажем, есть вы — с руками, ногами, накормленный и обеспеченный жильём на некоторое время. Или есть фирма с каким-то начальным капиталом), но непонятно, какие системы надо создавать и развивать — и какой для этого инженерный процесс выбрать. Термин «стратегирование» чаще всего используют в этой ситуации.

Стратегия — это тот метод, который будет выбран в ходе стратегирования («я буду учиться на медицинского робототехника, потом буду учить роботов хирургии»; «наша фирма займётся выпуском самых скользких сепулек»). А вот актуальный выбранный вариант разложения метода для этой сигнатуры в таком случае могут назвать тактикой, ибо его можно будет поменять, оставляя сигнатуру-стратегию неизменной. Проблема, когда разложение метода для сигнатуры не обсуждают вообще (ни как «тактику», ни как часть «стратегии»), а сразу переходят к планированию работ. Это означает, что вариант метода, которым будут вестись работы оставлен на усмотрение исполнителей работ — такой вариант, конечно, возможен, но могут быть большие сюрпризы и в результатах работы, и в выбранном инструментарии, и в задействованных исполнителях (их мастерство непонятно: мы не знаем, мастерство в каком варианте разложения стратегии на составляющие методы), сюрпризы в инструментах (это же будут «ресурсы» — неожиданно для каких-то вариантов метода нужны будут редкие и дорогие инструменты), сюрпризы во времени работ по плану (разные варианты методов могут требовать разных времён работы).

Стратегией могут назвать и сигнатуру метода с разложением на примерно один уровень, а тактикой — более подробное разложение (помним материал первого раздела про разложение методов). Тогда тактикой будет разложение составляющих стратегии/метода.

Ещё один вариант — термин «тактика» вообще не используется, а стратегия просто детализируется до уровня, достаточного для планирования в ходе непрерывного стратегирования. Наше руководство придерживается такого подхода, это убирает произвол в делении на «стратегию» и «тактику». Разные люди проводят границу между стратегией и тактикой по-разному, договориться на эту тему обычно невозможно, само положение границы ни на что не влияет — поэтому этим и не надо быть озабоченным. Детализация стратегии — да, а вот «является ли закручивание наших особых гаек нашим особым ключом нашей стратегией, или это уже наша тактика» — нет, это спор о терминах, спор по поводу классификатора. «Роза пахнет розой, хоть розой назови её, хоть нет»: в любом случае речь идёт о выборе методов, просто выбор методов нужно делать на каждом уровне разложения.

Ключевой дисциплиной интеллект-стека для стратегирования является рациональность (подробней о рациональности — в руководствах по рациональной работе и интеллект-стеку фундаментальных методов мышления). Мы уже приводили «условные шаги» (это не шаги императивного процесса, это функциональное описание, они идут в логическом времени, а не строго последовательно) для стратегирования. Напомним их вкратце (подробней было в подразделе «Онтологические нюансы при стратегировании» раздела «4. Метод как объект первого класса»), но ещё и добавим немного, и вставим чуть больше шагов:

• Выявить (предложить гипотезу или принять как входное задание) сигнатуру метода: какие предметы метода в каких их состояниях вы должны будете получить в результате реализации стратегии. Иногда «стратегией» называют результат только этого условного шага. По-хорошему, у вас должно быть много таких гипотез. Если у вас только один вариант в этом шаге, то вы заигрались, застряли по жизни — вы меднолобый фанатик, религиозно преследующий единственную цель. Мы об этом будем говорить в текущем разделе.

• Затем предлагаете варианты (много! Больше одного!) разложения метода для сигнатуры из предыдущего шага на составляющие. Тут должна работать не чистая фантазия, нужны как-то причинно-следственно обоснованные объяснения для описания различных вариантов разложения метода-стратегии на составляющие — из литературы, или придумываете сами. Вы должны породить достаточное число вариантов методов, и не любых, а с максимальной вероятностью ведущих к успеху. Подойдут различные методы творчества.

• Затем в ход идёт теория принятия решений в условиях неопределённости (результаты будут в будущем и в реальном мире, решения принимаете сейчас и по каким-то моделям). Теория принятия решений и есть ключевая дисциплина в рациональности. Надо выбрать наименее плохой вариант разложения метода (потому что «лучший» вряд ли присутствует в ваших предложениях — он теоретически недостижим. Помним, что вы всегда работаете в условиях многоуровневых конфликтов и речь идёт о многоуровневой оптимизации). Задачу облегчает то, что в силу неустроенности (помним о неустроенностях/«geometrical frustrations» из-за неизбежных конфликтов между системами разных системных уровней, об этом было в «Системном мышлении») будет множество решений примерно с одинаковой оптимальностью.

• Дальше вам надо запланировать работы. Этот шаг плохо понимается, если вы не различаете работы и методы работы. Планирование и стратегирование — разные методы, работающие с разными предметами: планирование с работами, а стратегирование — с методами. Планирование работ связано с выявлением доступности ресурсов (доступных по цене и доступных в нужный момент времени). При этом помним, что когда в «Дюне» Фрэнка Герберта говорят «планы внутри планов» («Планы внутри планов, и вновь планы — уже внутри вторых планов, — подумала Джессика — Стали ли мы сейчас частью ещё одного плана?»), то имеют в виду не собственно планы, а стратегии (методы достижения каких-то целей). Но в собственно планировании работ оптимальность вашего плана работ плана определяется не оптимальностью обособленного плана ваших работ, а оптимальностью плана общих работ всего проекта — вы должны понимать, что оптимизация обычно идёт только всей производственной программы предприятия, оптимум «глобальный» по всем работам какого-то коллективного создателя (скажем, предприятия), а не «локальный» только ваших работ. И ещё надо учесть, что надёжного универсального алгоритма планирования нет, а в agile проектах планирование работ вообще делается «на лету», это добавляет трудности. А поскольку планирование работ ведётся для какого-то метода работ, то при непрерывном стратегировании планирование тоже становится непрерывным: «планы ничто, планирование — всё». В менеджменте часто не разделяют стратегирование (содержательная методологическая работа) и планирование («арифметика» операционного менеджмента, например, задействуя методологию TameFlow). Зря! И в «Рациональной работе», и в «Методологии» объясняется, почему их полезно разделять: они отвечают на разные вопросы об одном и том же поведении. Поэтому в менеджменте популярны поговорки не про стратегию, а про планы, например, «планы нужны только для того, чтобы их выкинуть, но не планировать — нельзя». Такие «планы» реферируют к понятию «стратегия». Это просто термин, надо понимать, о чём идёт речь, как обычно — из контекста. Иногда стратегию::метод называют «план», а чтобы подчеркнуть стратегичность — «хитрый план». Но мы будем считать, что стратегия — отдельно, игнорировать тактику (стратегия многоуровнева в части разложения её на составляющие, термин «тактика» не используем), а планы поминать только как планы из предметной области операционного управления.

• Дальше надо выполнять работу по плану, от описания переходить к делу! План сам себя не выполняет, это бы была симпатическая магия (вера в то, что достаточно поменять модель, и жизнь как-то магически изменится в соответствии с подправленным описанием: если куклу Вуду кольнуть булавкой, то хуже станет и описываемому этой моделью человеку — без каких-то дополнительных действий с самим этим человеком). Надо «проявить политическую волю», как сегодня принято говорить. Это ключевое, что отличает «аналитиков» (которые только описывают жизнь) от инженеров, которые меняют жизнь, доводя идеи до воплощения. От разговоров и размышлений надо перейти к делу, все размышления нужны только для того, чтобы что-то в итоге сделать с физическим миром. Даже если в стратегии речь идёт об описаниях как её предмете — надо всё равно будет проследить, что эти описания как-то повлияли на мир, как было задумано, учесть это в методе и работах.

• Надо убедиться в том, что стратегия разделяется/shared всеми задействованными в выполнении работ по ней агентами. Для этого она должна быть документирована. И по этой стратегии (метод работы!) должно быть проведено обучение, чтобы у агентов было мастерство её выполнения.

• И ещё надо обеспечить надзор: 1. отслеживание результатов выполнения метода (проверка того, что делаются все важные операции и достигаются все предписанные методом состояния предметов метода) и 2. отслеживание выполнения плана работ (наличие всех ресурсов, старты и окончания работ совпадают с запланированными, об окончании работ извещается исполнитель следующих работ по supply chain, и так далее). По итогам надзора надо иногда принимать административные меры (скажем, увольнять агентов, намеренно не придерживающихся стратегии и не выполняющих запланированные работы), иногда проявлять лидерство (уговаривать выполнять стратегию), иногда доучивать и дооснащать инструментарием, иногда же — менять стратегию и планы ввиду их нереалистичности.

• Не забывать, что стратегирование непрерывно! Непрерывно обновлять стратегию! Можно только начать стратегировать, закончить стратегировать нельзя!

Помним, что это всё не однократно проходимая логическая последовательность, тут тоже используется принцип «непрерывное всё» (иногда его для случая стратегирования формулируют как «стратегия — ничто, стратегирование — всё», понимая под этим то, что стратегия живёт короткий промежуток времени, после чего в ходе непрекращающегося стратегирования она будет непрерывно меняться). Помним про путаницу между «планированием» и «стратегированием» (в жизни это часто синонимы, в наших руководствах — нет!).

Интересно, что есть некоторая путаница между выбором основной функции создаваемой системы и выбором метода работы какого-то создателя (например, команды инженеров, создающих систему) — и то, и другое называют стратегированием. Действительно, стратегированием будут называть:

• и выбор метода/функции, которыми будет работать целевая система (скажем, «наша сепулька для скользкости будет использовать тефлоновое покрытие на нашем суперклею, что позволит нам выгодно отличаться от конкурентов, которые не смогут приклеивать тефлон», тут разговор про сепульку, тефлон, суперклей),

• и выбор метода, которым будет работать инженеры (скажем, предыдущая фраза будет как «наша стратегия — мы разработаем скользкую сепульку, для этого мы задействуем суперклей для приклеивания тефлона на сепульку, только мы сможем приклеивать тефлон!», тут разговор про нас и наши действия с сепулькой, главный герой в этой фразе — «мы»::создатель, а не сепулька).

Как и во всём остальном руководстве, мы в изложении не будем обращать внимание на то, о методах работы каких систем в графе создателей идёт речь — рассуждения, по большому счёту, одни и те же. Вы уже понимаете, что выбирать метод работы вам придётся для системы в каждой области интереса графа создателей. И речь может идти и о инженерном стратегировании, и о корпоративном стратегировании, и о личном стратегировании.

Основная трудность стратегирования в том, что все решения надо принимать в условиях неопределённости, заглядывать в «туман будущего». В стратегировании поэтому важна роль «шумпетерского предпринимателя» (не предпринимателя в бытовом смысле слова, в бытовом смысле слова мы «предпринимателя» табуируем, у этого термина слишком много значений!):

• визионера (если мы говорим об инженерном проекте: выгодно ли делать систему с какой-то функцией)

• бизнесмена (если мы говорим об организационном проекте: выгодно ли делать компанию, умеющую работать какими-то методами, например, выпускать системы с какими-то функциями)

• культуртрегера (если мы говорим о проектах создания мастерства: выгодно ли учить агентов тому или иному мастерству)

… — могут быть и другие названия.

Но надо помнить: шумпетеровский предприниматель (не агент! роль!) лишь говорит о том, что он в условиях недостатка информации готов рискнуть взять деньги инвестора на проект, который будет работать по предложенной стратегии. Но вот саму стратегию всё-таки вырабатывает прикладной методолог той предметной области, о которой идёт речь, ведь именно он разбирается в лучших (SoTA) методах.

Но и тут есть проблема: выигрышная стратегия всегда приходит сбоку, и никогда не приходит из той предметной области, в которой работаете вы, или работает ваша фирма, или работает ваша целевая система. Поэтому лучший методолог для вашей системы (какой-то из систем в графе создателей) может быть не методолог, который досконально знает именно вашу предметную область, а методолог какой-то другой предметной области. Сигнатура метода будет ваша, а разложение метода — придёт сбоку. Скажем, методы фотографирования останутся — но разложение метода перейдёт от химической фотографии к цифровой, а фотоаппараты станут частью смартфонов.

«Всё новое приходит сбоку», и дальше мы подробней будем рассматривать теорию стратегирования, которая раскрывает это положение более подробно.

Будущее уже здесь

Будущее уже здесь, только оно неравномерно распределено.

У.Гибсон

Сегодня к этому высказыванию добавляют «и ужасно дорого стоит». А когда цена на «товар/услугу из будущего» падает (часто в несколько раз за год — экспоненциальная зависимость), это будущее вдруг становится широко распространённым, то есть настоящим. А новое будущее опять уже здесь, и опять дорого стоит.

Тут хорошо бы спросить, а что мы считаем «будущим»? Что обсуждается? Обсуждаются прежде всего новые технологии, которые будут широко распространены. Технологии — это один из синонимов метода, так что будущее, рассматриваемое с точки зрения прихода новых технологий/методов оказывается предметом рассмотрения методологии. Будущее нам нужно, когда мы стратегируем: пытаемся выбрать тот метод, который нам поможет. Выбираем-то мы сейчас, а вот задействовать метод придётся в будущем. И поэтому стратегирование происходит в условиях неопределённости.

Будущее как туман: на расстоянии вытянутой руки всё прозрачно, а в трёх метрах может оказаться абсолютно невидимая стена. Метафора тумана для будущего была предложена одним из отцов современного искусственного интеллекта Geoffrey Hinton как вполне адекватная, туман ведь имеет экспоненциальную зависимость его прозрачности от расстояния³¹⁹, и это основная проблема для мышления людей о будущем: человек ожидает линейного развития ситуаций, но по отношению к будущему развитие идёт по экспоненциальным законам: совсем ничего, ничего, почти ничего, и вдруг ай-ай-ай сколько и сразу потом ой-ой-ой, уже всё!

Почему будущее так неопределённо? Почему нельзя выделить один какой-то ведущий технологический тренд, и всё подробно и точно предсказать? Почему футурологи ничего не могут толком сказать?

В мире всё со всем связано неочевидным способом, мир целостен, он системен — части его взаимодействуют, и эти взаимодействия очень трудно предсказать, кроме того, что системы всё усложняются и усложняются. То говорили, что на орбиту выводят спутник — и каждый спутник был победой, а сегодня счёт уже идёт на «констелляции» спутников, спутников в них сотни и планируются десятки тысяч, проекты типа Starlink³²⁰, OneWeb³²¹, СФЕРА³²². Возможности таких «констелляций» растут экспоненциально, если вырастают возможности ракет. Например, когда начнутся запуски спутников StarLink 2.0 при помощи StarShip, то их длина может достигать 7 метров с антеннами в 5-6 метров. Эти огромные аппараты непосредственно смогут работать с сотовыми телефонами без дополнительных антенн, и это уже обсуждается с телефонными провайдерами³²³.

Единственного ведущего изменения, определяющего будущее, нет. Ибо изменения происходят на самых разных системных уровнях в ходе эволюции: идут непрерывные мутации самых разных биологических и технических систем, эти мутации проявляются в их поведении (в методах работы этих систем).

Но у эволюции есть закономерности, которые важно учитывать. В том числе они оказываются важны в техно-эволюции. Как в биологии некоторые гены могут прийти от паразитов (например, митохондрии появились в клетках ровно таким образом), так и все радикальные новинки в технике приходят «сбоку» от той сферы деятельности, в которой они вносят максимальные изменения в привычный уклад. Микроволновку на кухню изобрели спецы по радарам!

Первый компьютер сделали на радиолампах в середине 20 века, хотя всё программирование уже было изобретено ещё Бэббиджем в середине 19 века³²⁴. Триоды пришли в компьютеры «сбоку», они совсем не для этого изобретались, изобретены были ещё в 1906 году³²⁵, но технология массового производства была отлажена много позже, результирующая дешевизна триодов появилась отнюдь не сразу.

Особо отметим дешевизну технологий как важнейший критерий: если задействование метода дёшево (малая стоимость инструментов, малое время работы создателей), то его будут задействовать повсеместно — для дешёвых технологий найдётся множество применений.

Дешёвые триоды придумали использовать как элементную базу для логических цепей в компьютерах только в августе 1942 года, когда Джон Мокли³²⁶ написал 7-страничный документ «The Use of High-Speed Vacuum Tube Devices for Calculation», в котором предлагал Электротехнической школе Мура (подразделение Пенсильванского университета) построить электронную вычислительную машину, основанную на электронных лампах. Руководство Электротехнической школы работу не оценило и сдало документ в архив, где он вообще был утерян.

В апреле 1943 года Мокли по памяти восстановил документ уже для Баллистической лаборатории, он был одобрен. В проекте машина называлась «электронный дифф. анализатор» (electronic diff. analyzer). Это была уловка, чтобы новизна проекта не вызвала отторжения у военных. Все они были уже знакомы с дифференциальным анализатором, и проект в их представлении просто предлагал сделать его не механическим, а электрическим. Проект обещал, что построенный компьютер будет вычислять одну траекторию за 5 минут. Военные сказали «ОК» и выделили деньги: $61700 на первые 6 месяцев исследовательских работ. В контракте под номером W-670-ORD-4926, заключённом 5 июня 1943 года, машина называлась «Electronic Numerical Integrator» («Электронный числовой интегратор»), позднее к названию было добавлено «and Computer» («и компьютер»), в результате чего получилась знаменитая аббревиатура первого в мире универсального (то есть программируемого на самые разные вычисления) электронного компьютера ENIAC³²⁷. Абсолютно засекреченный компьютер был полностью готов лишь осенью 1945 года, а первыми его программистами стали шесть девушек³²⁸.

Такая витиеватая последовательность событий в начале, середине, конце (в любом месте!) технологических революций (революций в методах работы, соответственно в предметах методов, в инструментах и мастерстве создателей) типична. Будущее непредсказуемо: ни содержание изобретения электронного компьютера как инструмента для вычислений::метод, ни время изобретения, ни место изобретения — предсказать это всё было невозможно, хотя все необходимые для изобретения компьютера идеи были хорошо известны. Зато можно было предсказать, что дальше события развивались не линейно в части скорости распространения, а экспоненциально: разработка ENIAC на вакуумных радиолампах дала старт компьютерной революции, далее компьютерная революция следовала уже экспоненциальным, «революционным» законам.

Электронные вычислительные машины оказались быстры и надёжны, в отличие от механических, пневматических и даже электрических (реле) вычислителей. Вычисления от электронных ламп перешли к транзисторам, потом к транзисторным микросхемам, а сейчас вы уже можете купить и квантовый компьютер (прямо через облако, не выходя из дома, у более чем дюжины провайдеров³²⁹), и оптические вычисления (оптический компьютер можно купить было ещё в 2021 году, хотя не все даже профессионалы знают об этом³³⁰). Обещание вычисления одной баллистической траектории за 5 минут кажется милым и наивным, сегодня такой счёт шёл бы микросекунды, но начиналось всё именно так: это было запредельно круто для 1943 года!

Приход будущей технологии не одномоментен, он растягивается на некоторое время:

• Технология сначала очень долго считается невозможной, мечтой. Функция/метод чего-то нового (создателя или какой-то системы) уже обсуждается, но конструкция ещё непонятна. Это «знаем что, но не знаем как» может длиться сотни лет, а то и тысячи. Летать людям хотелось давно! А сумели это осуществить не так давно: между первым полётом братьев Райт и полётом человека на Луну прошло всего 60 лет, тут можно говорить об экспоненциальном прогрессе. Машинный интеллект казался невозможно далёким будущим ещё десяток лет назад, а многим и сейчас таким кажется, хотя с его применениями люди сталкиваются уже ежедневно.

• Затем это «будущее-в-настоящем» очень дорого стоит и его немного, то есть принципиально новая технология существует, но недоступна для большинства. Скажем, искусственный интеллект ещё в начале 2012 в общественном мнении был невозможным за любые деньги. Но в конце 2012 года (после победы нейронных сетей в соревновании распознавания изображений ImageNet Challenge³³¹) уже было понятно, что с машинным интеллектом всё в порядке, и развитие будет быстрым. Но стоимость машинного интеллекта высокого качества (это «высокое качество» всегда будет недосягаемым для большинства, как бы ни был умён дешёвый доступный всем интеллект, всегда будет хотеться иметь для себя самого умного машинного агента) даже сегодня запредельно высока³³². Очень немногие компании могут себе позволить с ним работать «на фронтире», хотя эксперименты с уже имеющимся интеллектом всегда будут относительно дёшевы. Вырастить из младенца и хорошо обучить мудрого человека — очень дорого, а вот задать ему вопрос или подучить какой-то одной новой практике — это обычно дёшево. С искусственным интеллектом получается примерно так же.

• Наконец, будущее становится уже настоящим и повсеместным, «не будущим». Новые технологии (то самое «будущее») стоят дёшево, это уже не роскошь. Машинный интеллект, понимающий команды с микрофона уже обыден, все разговаривают со своими телефонами и даже не удивляются, что телефон отвечает не жестяным голосом робота, а нормальным голосом с человеческими интонациями, да ещё показывает картинку говорящего с вами никогда не существовавшего человека, робота-аватара. Будущим считают уже что-то другое, а не эту повседневность, которая ещё вчера была далёкой мечтой. Будущее — как стена тумана, отходящая с каждым шагом. Как горизонт, ускользающий при быстром к нему движении.

До сих пор принято мечтать о том, что будет в 21 веке — в будущем. Но мы давно уже в этом будущем, уже прошла четверть 21 века!

Подрыв подо всей цивилизацией сразу: экспоненциальные технологии и конвергенция

Disruption technologies принято переводить как подрывные технологии³³³ — это такие технологии (методы работы!), которые закрывают одни отрасли и открывают другие. Типичная такая цепочка — это технология проводного, а затем радио телеграфирования важной информации, которая была подорвана технологией проводной телефонии, которая был подорвана технологией сотовой телефонии, которая была подорвана технологией смартфона с упором не на звонки, а на передачу данных, а дальше через чаты происходит возврат к «телеграфу», звонки же всё больше — групповые видеозвонки. Восковые валики для записи звука заменились на виниловую аналоговую грамзапись, потом она стала записью на цифровые CD-диски, а потом и вовсе превратилась в сетевые музыкальные сервисы и соединилась с технологией сотовой уже не телефонии, а передачи данных на смартфонах. Гибкие магнитные диски появились, уступили место «флешкам» буквально на несколько лет, а затем и флешки исчезли из употребления, данные передаются через облачные сервисы.

Каждый такой «подрыв» — это исчезновение одних массовых видов работ, требующих мастерства в уходящей технологии и приход новых видов работ, требующих мастерства в приходящей технологии. Десятки и сотни тысяч людей, а то и миллионы занятых в подорванных технологиях вынуждены были переучиваться. Сейчас это происходит с нарастающим масштабом и увеличивающейся скоростью.

Кто помнит извозчиков? Буквально за 13 лет с 1900 по 1913 год гужевой транспорт в Нью-Йорке был заменён автоперевозками, с чего Tony Seba и начинает свою серию презентаций в 2014 году³³⁴, которую потом он повторял и уточнял вплоть до 2020 года, когда тренд с электромобилями стал уже всем очевиден³³⁵. Но это в мегаполисе, в Нью-Йорке. А в целом по США с 1910 по 1920 всего за десять лет доля пассажиро-километров на автомобилях была поднята с 11% до 81%. Для этого была построена автомобильная промышленность, развёрнуты производство бензина и сеть автозаправок — и это в то время, когда страна отвлекала ресурсы на участие в первой мировой войне.

Лучшая на сегодня бизнес-теория техно-эволюции (то есть объяснение «где деньги во всём этом бурном прогрессе») создана Tony Seba. Вам нужно просмотреть его короткие видео, которые вышли в конце 2022 года³³⁶, и дальше обратиться к его книгам (они упоминаются в этих видео, хотя не ожидайте там какого-то очень точного рассказа: как бы ни был прозорлив Tony Seba, предсказать будущее не может и он, тем более что затронуты оказываются все сферы жизни).

Истории подрыва/disruption можно рассказывать о секретарях-машинистках и машинописных бюро. Об операторах ЭВМ в эпоху мейнфреймов. Веб-мастера на старте интернета просуществовали буквально несколько лет. Из массовых профессий буквально сейчас стремительно уходит профессия кассира, магазины без кассы в мире уже появились и потихоньку распространяются, одновременно безналичные расчёты резко сократили затраты времени нынешних кассиров, стало больше «касс самообслуживания» — и кассиров на кассе теперь нужно меньше при сравнимой длине к ним очереди (очередь из трёх человек раньше в крупном магазине была к каждому из двадцати кассиров, а сейчас — к трём). Хотя и это меняется: если речь идёт о методах/технологиях/культуре торговли, то в крупных и даже мелких городах магазинная торговля постепенно перемещается в торговлю через маркетплейсы и службы доставки (в пункты доставки с примерочными, а то и сразу к двери — решена проблема «последней мили» в дистрибуции).

Так что мастерство телеграфистов, мастерство кассиров, как и мастерство работы по всем остальным методам оказывается применимым ограниченно по времени.

Можно ли назвать «профессией» занятость, приходящую и уходящую буквально за несколько лет? Скажем, в 2023 году начали говорить о профессии prompt engineering³³⁷ как профессии создания запросов к несовершенным ещё системам AI. В 2024 году вышла ChatGPT o1, где прямо говорится, что не нужно заботиться о промптах — оказалось, что prompt engineering легко автоматизировать. Профессия умерла, просуществовав буквально год-другой. Мастерство prompt engineering оказалось не нужным, как и мастерство телеграфиста. Не все извозчики стали таксистами, да и жизнь таксистов сейчас резко меняется. Навигаторы и «уберизация» (маркетплейсы такси-сервисов) резко обесценили специфическое мастерство таксования, быть таксистом — это может быть уже не профессией на много лет, а просто «подработкой». А на горизонте уже роботакси, таксисты-люди оказываются не нужными.

Занятость каким-то делом, даже если речь идёт о мастерстве в этом деле, назвать «профессией» нельзя. Это просто «занятость», практикование какого-то мастерства, выполнение в течении какого-то времени (но не всю жизнь) работ по какому-то методу. В долгой жизни можно стать мастером во многих деятельностях, но необязательно каждый вид своего мастерства называть «профессией».

То же самое относится и к фирмам: ни одна фирма не может гарантировать себе «профессию» на долгие годы. Время от времени фирмы делают вираж/pivot, полностью меняя технологии, в которых они мастера. Для стартапов («молодых» фирм) этот «вираж» вроде как норма, но это же норма и для крупных фирм. Конечно, эти «виражи» болезненны: не факт, что новое мастерство окажется востребованным, а ещё коллектив фирмы, который хорош в одном уходящем в прошлое мастерстве, может иметь недостаточно хорошее мастерство, чтобы конкурировать на новом рынке. Kodak с фотоаппаратами, IBM с персональными компьютерами, Nokia с телефонами: все эти фирмы как-то выжили, но не смогли удержать лидерство в ходе перехода на новое поколение технологий.

Технологические подрывы и связанные с ними сценарии вынужденного переучивания миллионов людей, вызваны одной и той же причиной: экономикой экспоненциальных технологий. В экспоненциальных технологиях цена реализации технологии какой-то системой (технология — функция, реализует функцию какая-то система. Помним, что нет бега без бегуна) нелинейно (в полтора-два раза за год, что ведёт к эспоненте) падает.

Поскольку цена реализации какой-то функции (то есть цена соответствующих систем, реализовывающих функцию, а в случае сервиса — цена работы этого сервиса) падает по экспоненте, то изделия и сервисы, реализующие необходимую функцию/«метод работы»/технологию начинают покупать в больших масштабах. Если поездка на такси будет стоить вам месячной зарплаты — вы не поедете, разве что это будет вопрос жизни и смерти, ехать в больницу. Если поездка на такси будет даже дешевле, чем поездка на автобусе (а роботакси вроде как обещают именно такое) — то вы поедете на такси, а не на автобусе. Для дешёвых технологий находится неожиданно много применений: те, кто не пользовался ими задорого, вдруг готовы пользоваться, если они подешевели.

Распространённость новой технологии следует закону S-образной кривой, в которой есть участок буквально взрывного, экспоненциального роста распространённости — а потом просто становится некому продавать, все уже имеют эту технологию. Но тут обязательно появляется новый «неожиданный» подрыв — и всё повторяется: сначала дорого и у немногих, потом очень дёшево, при этом — у всех. Кривая падения цены — экспонента (всегда есть, куда падать в цене ещё ниже), а кривая распространения технологии — логистическая, она же S-curve (выходит на плато, ибо становится уже некому продавать — у всех, кому потенциально надо, доступ к технологии уже есть).

Ничего линейного в будущем нет, это цепочка «неожиданных» (хотя вы должны это ожидать!) экспоненциальных подрывов — и в каждом таком подрыве есть период с «ничего вроде не происходит» с последующим периодом «неожиданно всё стремительно». Вкладываться в устаревшую технологию становится неправильно по чисто экономическим соображениям, и происходит шаг развития — переход к новой технологии, у которой совершенно другой потенциал развития.

Это и есть техно-эволюция видов систем, причём всё происходит быстро за счёт того, что мемом (информационные модели систем для работы по новым технологиям, по этим информационным моделям в автоматическом режиме изготавливается огромное число воплощений описанных систем с определяемым этим мемомом феномом) отделён от целевой системы, и в нём идут умные мутации, а не происходит медленная дарвиновская биологическая эволюция.

Главное тут то, что самые разные «экспоненциальные технологии», каждая с каким-то своим «законом» (то есть коэффициентом к экспоненте, чаще всего этот «закон» называют по имени инженера, определившего этот коэффициент) кратного падения цены за год складываются вместе в одной результирующей технологии, и в этот момент начинается подрыв: эта технология стремительно распространяется, её использование в силу дешевизны вырастает кратно в год.

На картинке показана скорость распространения новых технологий. Видно, что чем позже появляется технология, тем быстрей она распространяется. Скажем, технология смартфонов от телефонов отличается тем, что главной становится передача данных, а не голосовая связь. Косвенный признак тут — смена тастатуры на дополнительную площадь экрана, при этом ещё и рост размера телефона, чтобы увеличить площадь экрана. Последние телефоны были «чем меньше, тем лучше», а смартфоны хорошо продавались большие, «лопаты».

Первый успешный смартфон (iPhone) появился в 2007 году. Первый планшет (iPad) — в 2010 году.

Почему iPhone появился в 2007 году и имел сразу такой успех? Потому что в этом продукте сошлись множество других экспоненциальных технологий (для каждой технологии говорим о системе, которая даёт эту технологию):

• экспоненциально падала стоимость технологии вычислений (транзистора в чипе — закон Мура³³⁸),

• хранения информации (бита во внешней памяти — закон Кридера³³⁹),

• цифровой фотосъёмки (числа пикселей в матрице камеры — закон Хенди³⁴⁰),

• передачи данных (закон Баттера³⁴¹),

• а ещё дешёвый сенсорный экран высокого разрешения,

• дешёвые литий-ионные аккумуляторы (падение цены на 10-15% в год, это тоже экспонента),

• GPS (спутники в эксплуатации с 1978 года, но речь идёт о дешёвых чувствительных приёмниках),

• датчики акселерометра и гироскопа (акселерометр на лунном модуле Apollo весил 15кг, в смартфоне вес этих датчиков пренебрежимо мал).

И когда всё это стало достаточно дешёвым и слиплось в один продукт за $600, он «взлетел». Помним, что Apple пыталась запустить до iPhone абсолютно инновационный наладонный компьютер Newton, это был 1993 год³⁴². Ничего не получилось: технологии уже все были в наличии, но слишком дорого стоили. Особенность тут в том, что в сложных новых продуктах стремительно дешевеющих систем, реализующих разные технологии — много. При этом дешевеют системы, но задействование метода, реализуемого системой тем самым становится дешевле. Поэтому говорят также и об экспоненциальном подешевении технологии. В какой-то момент цена самых разных систем для составляющих какой-то технологии падает в разы, так что стоимость итогового продукта для технологии падает (неожиданно для всех) в разы — и дешёвый продукт мгновенно разлетается по планете, делая «вдруг» доступной ранее повсеместно недоступную технологию.

Через пару лет после появления смартфона в 2009 году появился Uber, он предложил бизнес-модель заказа такси с использованием смартфона и облачных вычислений, и через 7 лет (в 2016 году) число заказов через Uber стало больше, чем во всех таксомоторных парках США. Через 8 лет (в 2017 году) Uber и Lyft с начального нуля получили 20% от всего объёма перевозок (в милях) в таких городах, как Сан-Франциско и Нью-Йорк. А в декабре 2020 Uber продал своё подразделение автопилотируемых автомобилей³⁴³ — там уже несколько лет ожидалось экспоненциальное развитие, но его не случилось! Самоуправляемые/беспилотные/автономные автомобили находятся пока на начальной стадии S-образной кривой. А потом? А потом, через несколько лет будет традиционное — «ах, когда же это всё успело произойти?!». Разговоры вдруг станут реальностью, и ключевое тут будет слово «вдруг», ведь роботакси без водителя уже доступны широкой публике, но их распространение сдерживается именно тем, что они пока очень дорогие, их эксплуатировать невыгодно³⁴⁴. Но в какой-то момент они распространятся «вдруг», экспоненты работают «внезапно».

Эти нелинейности и неожиданности моментов использования одних технологий в составе других и последующего стремительного распространения появляются за счёт чисто экономических причин: экспоненциального падения стоимости новаций, и массовых закупок вдруг «внезапно» подешевевшей технологической роскоши. Тут нет никаких «планов развития инноваций» от правительств, или ещё каких-то других конспиративных теорий, реализации чьих-то долгосрочных планов. Кто мог предсказать появление смартфонов и дата-центров по приемлемой для широких масс цене? Кто мог без этих дешёвых смартфонов и дешёвых дата-центров сделать аналог Uber?

Никакие эксперты не в состоянии предсказать будущее: каждая из технологий неочевидным образом снижает цены и делает доступными огромному количеству людей те технологии, в состав которых они входят. А если и не снижается цена, то при той же цене можно получить характеристику в разы лучше. Пять лет назад за $2000 можно было купить ноутбук с 8Gb памяти, 4 ядрами процессора и FullHD дисплеем. Сегодня за ту же сумму можно купить ноутбук с 32Gb памяти, 8 ядрами процессора и 4К дисплеем. И ещё там будет 1Tb твёрдотельный «диск» (который уже давно не диск!) и отдельный ускоритель для графики и AI. Такие ноутбуки, какие были 5 лет назад, стоят $1000, вдвое дешевле, а то и меньше. «Вдвое за пару лет» гласит закон Мура по поводу числа транзисторов на микросхеме — это начальник службы исследований и разработки компании Fairchild Semiconductor Гордон Мур сформулировал ещё в 1975 году, он предположил тогда, что так будет ещё лет десять. Но это было полвека назад! Сейчас скорость падения цены по закону Мура немного уменьшилась, но закон до сих пор продолжает действовать. И даже «вдвое за четыре года» вместо «вдвое за два года» — это тоже экспонента, и это тоже очень быстро!

Tony Seba называет склейку разных экспонент в одном продукте конвергенцией.

«Подрыв подо всей цивилизацией» происходит из-за конвергенции самых разных технологий в одной. Так, в автомобилях происходит конвергенция

• технологии аккумуляторов с созданием гигафабрик для их выпуска (и поэтому становятся возможными электромобили),

• технологий автопилотирования, требующих развития как аппаратных средств искусственного интеллекта (специальные компьютеры с ускорителями для умножения матриц), так и развитых нейросетевых алгоритмов,

• технологий ориентации автомобиля в пространстве с задействованием лидаров,

• технологий замены алгоритмов автомобиля через интернет, не надо приезжать на станции техобслуживания.

Быстрое распространение подрывных технологий можно очень приблизительно разделить на следующие стадии³⁴⁵:

• стандартизация (standardization, возникновение промышленных стандартов, позволяющих организовать встраивание новой технологии во внешние системы). Если вы обнаружили перспективную технологию, в которой ещё нет стандартов, то вам повезло: вы близки к началу её распространения.

• удобство использования (usability, обеспечение удобного интерфейса к технологии, иногда речь идёт о «ключевом приложении», killer application)

• переход в массовое потребление (сonsumerization)

• переход в инфраструктуру (foundationalization, «изо всех утюгов», «потребление незаметно». Основная характеристика инфраструктуры — это повсеместность, доступность в любой точке, где возникла потребность).

В персональном компьютинге:

• сначала появились открытые архитектуры компьютеров (стандартизация),

• затем графические интерфейсы (удобство использования),

• потом они стали массовым потребительским товаром (доступны даже школьникам, новые форм-факторы — даже смартфон теперь компьютер),

• сейчас основной компьютинг идёт вообще в инфраструктурных организациях — дата-центрах.

Интернет в его современном понимании (как все его вебсайты, а не как сервера на протоколе TCP/IP):

• начался со стандарта HTML (стандартизация),

• затем появилось удобное его использование (разделение оформления и содержания страниц через стилевые описания CSS),

• затем появились социальные сети (Web 2.0),

• сейчас по факту интернет стал основой для большинства рабочих, промышленных и торговых коммуникаций, это инфраструктура, интернет повсеместен.

В AI:

• стандарты уже появились (первым был ONNX³⁴⁶, сейчас их множество), удобство использования — это чат-интерфейсы и голосовые чат-интерфейсы (assistants), а также встроенность в различные специализированные моделеры (copilots).

• Массовое использование пока только намечается (по аналогии с интернетом это может быть ситуация, в которой специализированные AI создаются самими пользователями, а не специалистами, пока же это ещё очень дорогое занятие. Тем не менее, уже стали не нужны знания по prompt engineering),

• некоторое время ещё нужно ждать до инфраструктурности.

Эти все этапы довольно быстро (экспонента!) пробегаются самыми разными технологиями.

Какие факторы тут влияют на экспоненциальность? Разнонаправленные:

• Глобализация (обмен новостями через интернет, глобальные поисковые системы, свобода перемещений лиц и товаров, глобальные системы денежных расчётов, глобальный рынок инвестиций, наличие электронных переводчиков и так далее) существенно ускоряет распространение новых технологий в момент их появления.

• Деглобализация (Разделение интернета на анклавы, раздробление платёжных систем, закрытие рынков, ограничение транспортной доступности, ограничение доступа к SaaS и продукции отдельных фирм, ограничение на использование иностранных языков и так далее) замедляет распространение новых технологий в момент их появления. Этот тренд нельзя не учитывать, ибо архитектурно мир не может быть «всесвязным/безмодульным/однородным», это закроет дорогу к развитию мира. Мысль эта контринтуитивна, к ней сразу можно найти множество возражений, и речь идёт о каком-то оптимуме связности, а не полной противоположности (полной «развязанности», повсеместным «железным занавесам», ибо тогда не будет взаимодействия подсистем мира, не будет возможен системный эффект и его оптимизация). Это чисто архитектурное рассмотрение в его современном понимании, к нему надо отнестись серьёзно: подробности можно найти в наставлениях по архитектуре из руководства по системной инженерии: там рассказывается об архитектуре в её современном понимании, в том числе о необходимости нарезки системы на модули и оптимизации взаимозависимостей, и что бывает, если взаимозависимости не ограничивать. Увы, текущие ограничения глобализации не временные, они будут длиться неопределённо долго. Это не зависит от текущих конкретных горячих и холодных войн. Участники этих войн будут меняться, но вот хода на возврат к свободе перемещения товаров, информации, людей (глобализация) не будет. Нет, будут жёсткие интерфейсы с тщательными проверками того, что пересекает границы. Сами границы, конечно, будут меняться, там же конфликты между системными уровнями, как же без этого. Более подробное обсуждение можно найти в подразделах «Этические/политические проблемы естественной эволюции, которые можно решать инженерно» руководства по системной инженерии и «Системная этика» руководства по системному мышлению. Дополнительно надо посмотреть материалы об архитектуре сложных систем от John Doyle³⁴⁷.

Пример подрыва: электромобили уже сейчас дешевле бензиновых автомобилей и их продаётся больше

В своих презентациях (например, по транспорту 22 апреля 2020 года³⁴⁸) Tony Seba рассказывает, что по итогам «чистого подрыва» с 2025 года все новые автомобили будут электрическими, и (с учётом задержек из-за пандемийных и деглобализационных ограничений) этот прогноз выглядит как до сих пор актуальный. Вот график роста числа электромобилей³⁴⁹, там хорошо видна экспонента, а в 2024 году ожидается, что 20% проданных автомобилей будут уже электромобилями:

Уже сегодня несколько китайских производителей имеют электромобили со стоимостью до $30тыс. при батарее с дальностью поездки от 300 километров. В 2021 году стоимость бензинового и электрического автомобилей из расчёта жизненного цикла на километр пробега сравнялись. Переход на электромобили стал чисто экономическим решением, например в расчёте на три года владения автомобилем и 12 тыс. миль пробега ежегодно в UK нужно платить за электромобиль 67 пенсов за милю, а за бензиновый автомобиль 74 пенса за милю, это уже сегодня³⁵⁰. Скоро разница будет настолько ощутима, что бензиновые автомобили просто перестанут покупать даже «по привычке» (при этом учитываем, что затраты на разные виды автомобилей никто не считает! Смотрят на совсем другие факторы, но эти факторы учитываются в конечном итоге в цене).

Ещё одна технология — это технология «беспилотности», которая обеспечивается компьютерным инструментарием: нужны дешёвые энергоэффективные суперкомпьютеры, которые могут быть размещены в автомобиле. Тут тоже экспонента: NVIDIA выпустила автомобильные компьютеры Orin в 2021 году, а в 2024 году новые автомобили (например, Volvo Cars EX90 SUV)³⁵¹ комплектуются компьютерами Thor, которые вчетверо более производительные, чем Orin, и всемеро более энергоэффективные.

А дальше будут нелинейные эффекты от сочетания быстро проходящих свои стадии развития технологий: обычный легковой автомобиль 96% времени простаивает, и только 4% времени находится в движении. Автономный электромобиль, предоставляемый как сервис по вызову такси, будет в работе весь день. Иметь собственный автомобиль станет невыгодным. Стоимость поездки резко упадёт, и можно будет покупать абонемент на поездки за цену существенно меньшую, чем стоимость обслуживания и страховки собственного автомобиля. Это уже происходит с сервисами car sharing (аренда автомобиля на одну поездку, при этом ты сам его ведёшь) в крупных городах. Дело тут не в правительственных субсидиях на электромобили, вопрос чисто экономический, субсидии могут только двигать момент выгодности покупки электромобиля или покупки сервиса электророботакси на год-другой, эти субсидии представляют только маленькую часть цены.

Меньше автомобилей обслужат больше жителей, и они не будут долго стоять. 80% парковочного места освободятся. Электромобили экономичны, и нефти для автотранспорта потребуется меньше, цена нефти резко упадёт, этому помогает ещё и солнечная энергетика плюс наличие дешёвых аккумуляторных батарей (а дешевизна аккумуляторов объясняется в том числе и тем, что они нужны прежде всего для электромобилей, но их с удовольствием используют и для солнечных и ветровых электростанций).

Там будет и много других чудесных следствий — но тут главное в скорости, с какой изменится мир уже в ближайшее время. Точка перегиба S-образной кривой автономного электротранспорта на быстрый взлёт уже была — это 2021 год, до этого момента изменения были практически незаметны, а после — неизбежно стремительны, и всяческие «энергокризисы» этому будут только способствовать.

Новость 2024 года: в Китае (самый конкурентный и большой рынок автомобилей в мире) продано в июле больше электромобилей (51.1%), чем автомобилей с двигателем внутреннего сгорания — при этом продажи электромобилей (NEV, new energy vehicles — чистые электромобили и гибриды, заряжаемые от сети) выросли на 28.6% за год³⁵².

Но это Китай, а вот что в Европе: в Норвегии NEV заняли 91.5% рынка, при этом только чисто аккумуляторные (а не гибриды) машины заняли почти 90% от всех NEV³⁵³. Подчеркнём, что гибриды вы тоже можете зарядить на электрозаправке — и поехать.

Похоже, что к 2030 году автомобили с бензиновым двигателем будут как гужевой транспорт в 1930 году. Для этого не хватает только инфраструктуры «электрозаправок», но она появляется очень быстро, у всех ведущих автопроизводителей есть планы на этот счёт³⁵⁴:

Переход на электромобили — это не единственный тренд, который изменит городской транспорт. Удалённая работа больше не считается чем-то неправильным (и дело тут даже не в экспериментах на живых людях, которые провели правительства всех стран в 2020 году, пандемия ковида просто немного ускорила ход событий в этой сфере). Сервисы доставки продемонстрировали, что они реально экономят время на походы в магазины, доставка до двери уже через пять лет вряд ли будет делаться людьми (уже сейчас роботы-доставщики Яндекса заметны в Москве, и даже голосом просят прохожих нажать кнопку на светофоре, чтобы перейти дорогу — сами пока они эту кнопку нажать не могут, но это же только самое начало тренда). Конечно, возврат людей в «оффлайн» на рабочие места и магазины после пандемии произошёл, но это не стало возвратом к старому «доковидному» состоянию.

Электросамокаты и электровелосипеды стали массовыми буквально за пять лет, они порождение того же тренда на экспоненциальное уменьшение цены аккумуляторов, а прокат их растёт в связи с доступностью безналичных расчётов через смартфоны.

Мир неузнаваемо изменится за ближайшие даже не десять, а пять лет, и продолжит меняться так же быстро и дальше. Бояться этого не нужно, нужно радоваться. Человечество за это время станет:

• более здорово

• более сыто

• более недовольно происходящим, ибо кто был никем, тот станет всем, и наоборот.

Вывод: менять работу и образ жизни придётся практически всем, а то и по нескольку раз за десяток лет. Это относится и к людям, и к организациям. Учитывать это надо и в личном стратегировании, и в организационном.

Задания

Поставьте отметки о выполнении следующих дел, не забывайте про «мышление письмом»: публикуйте свои мысли по поводу прочитанного и отсмотренного материала.

1. Прочитаны материалы о многоуровневых инженерно-предпринимательских программах (https://ailev.livejournal.com/1608515.html, 2022), отслежено, что с этими упомянутыми программами происходит сейчас, опубликованы собственные мысли на эту тему.

2. Изучены многоуровневые стратегии производителей электроавтомобилей по материалам Battery (Tesla) и Power (Volkswagen, https://www.forbes.com/sites/jamesmorris/2021/03/20/power-day-volkswagens-imitation-of-tesla-is-the-sincerest-form-of-flattery/) Days. Электромобильные компании устроили эти дни обсуждения roadmap одного из нижних системных уровней автомобиля — аккумуляторных батарей, причём с попыткой трассировать характеристики электромобиля не только к батарее в целом, но и к частям самой батареи (анод, катод, электролит, корпус — это всё есть в презентации Volkswagen, https://www.volkswagenag.com/presence/konzern/power-day/Powerday_Chart-183.pdf), а также с целью предъявить публике выход на уровень окружения (уровень выше автомобиля), например, предъявить планы по росту числа быстрых зарядок на дорожной сети. Многоуровневость: внимание к развитию частей целевой системы и развитию систем в окружении. NVIDIA уже в 2017 году говорила, что для тех же роботакси она не может продать им просто голые чипы, а нужно демонстрировать полный технологический стек, на много уровней выше чипов — https://ailev.livejournal.com/1384766.html. В статье Forbes по первой ссылке из текущего пункта задания говорится: «Toyota’s emphasis on Hydrogen Fuel Cells might have fared better if the company had invested in refueling stations rather than leaving that up to other companies. Volkswagen isn’t making this mistake and is putting serious money into solving the charging infrastructure problem». Многоуровневость, абсолютно разные задачи на каждом системном уровне. В Volkswagen для уровня той же батареи отмечали, что идти нужно и за пределы традиционно понимаемого жизненного цикла — и можно обнаружить, что ключевые интервенции развития нужно делать там, слайды 51 и 52 презентации Volkswagen — как раз кривоватые слайды про «жизненный цикл». Опубликованы ваши собственные мысли по поводу многоуровневых стратегий технологического предпринимательства.

3. Написан пост о том, какие новинки появились на разных системных уровнях продукта вашего текущего рабочего проекта (как самого продукта, так и его частей на несколько уровней вниз, так и уровня окружения). В эссе отражены ваши рыночные перспективы в связи с этими изменениями. Когда вы ожидаете прихода этих изменений? Какие действия вы предпринимаете, чтобы быть к этим изменениям готовыми?

4. Отсмотрены свежие видео на странице Tony Seba, https://www.youtube.com/user/tonyseba/videos, прочитаны свежие записи в блоге его фирмы RethinkX https://rethinkdisruption.com/. Опубликованы посты с собственными мыслями по поводу материалов Tony Seba и RethinkX.

Роботы заберут работу? Нет! Но работу/job/занятость надо будет менять часто.

Учитываем, что на первом месте отслеживаемых Tony Seba экспоненциальных подрывных технологий — машинный интеллект. Он занимает особое положение, потому как он может быть направлен на улучшение самого себя, «компьютерные программы, которые пишут компьютерные программы». После чего некоторые люди ожидают, что какие-то из этих улучшенных компьютерных программ могут получить самосознание «как у человека», но они будут умнее и одного человека, и даже всех вместе взятых людей, поэтому смогут «захватить мир». Многие даже разработчики систем AI включились в обсуждение возможных сценариев гибели цивилизации из-за слишком умного машинного интеллекта, правительства разных стран начали издавать законы, сдерживающие развитие технологий. Dell проектирует датацентры с ядерными реакторами для их запитывания, как раз под работу систем с искусственным интеллектом: ожидается нехватка электроэнергии для работы систем искусственного интеллекта, ибо чем больше времени и электроэнергии им дашь «на подумать», тем умнее они будут выдавать ответы — пока, как боятся некоторые разработчики (но не все!) не произойдёт гибели цивилизации. Элон Маск так вообще говорит, что люди не будут работать: любую их работу будут лучше делать роботы.

Мы даже не будем обсуждать тут вопросы безопасности систем AI, это всё равно как обсуждать вопросы безопасности людей: решения в этой сфере чаще всего иррациональны. Мы также не будем обсуждать типовое решение по «утрате работы людьми» — введение безусловного базового дохода (который понимается каждым произносящим этот термин по-разному, нет двух одинаковых пониманий, кроме того, что «откуда-то возьмутся деньги, их будут кому-то раздавать просто так»).

Tony Seba особо отмечает, что развитие машинного интеллекта не экспоненциально, а гиперэкспоненциально. Похоже, что он прав. Использован машинный интеллект может быть так же, как и любой человеческий интеллект: везде, где используется интеллект людей. Интеллект универсален, нет закрытых от него сфер. Как эта гиперэкспоненциальная подрывная технология повлияет на мир, предсказать нельзя — как нельзя предсказать, как именно повлияет на мир интеллект естественный. Это покрыто туманом будущего.

Изменения в мире произойдут стремительно. В древнем отчёте 2017 года от McKinsey в 2030 году ожидалось, что 400-800 млн. нынешних рабочих мест будут автоматизированы, труд на этих местах существенно изменится (читай: «исчезнет в его текущем виде»). Как раз о таких отчётах Tony Seba предупреждает в своих презентациях и книгах: они недооценивают масштабы перемен в разы из-за неучёта экспоненциального характера затрагиваемых ими технологий.

Автоматизация к 2030 году коснётся миллиардов рабочих мест, хотя в мире население всего 8 млрд. человек. Помним, что в телефоны у миллиардов людей в кармане никто тоже не верил, в интернет у миллиардов людей в кармане тоже никто не верил, в автоматизацию труда миллиардов людей пока тоже не верят, а зря. Но проблески этой тотальной автоматизации видны уже сейчас.

Важно, что автоматизация будет не только в области умственного труда (knowledge works), но и труда физического — грузчики, сборщики, водители, уборщики. Роботы готовятся сейчас двух видов: четвероногие (при этом вместо «головы» там может быть манипулятор) и антропоморфные, ибо вся сегодняшняя среда обитания приспособлена к физическим размерам человека. То, что роботов делают и четвероногих — это понятно, людям легче понимать, где и как могут быть задействованы такие роботы. Труднее сообразить, что дроны и «коптеры» — это тоже роботы. В этой области трудно приводить ссылки, ибо новости появляются практически ежедневно.

То, что сейчас говорят «цифровая трансформация», а иногда и «гиперавтоматизация», ничего не меняет: это всё маркетинговые замены термина, но суть дела остаётся: человеческий труд повсеместно заменяется машинным, как физический труд, так и умственный.

Скорость таких изменений надо учитывать и в личном стратегировании, и в корпоративном: если что-то связано с технологиями искусственного интеллекта, то развитие событий будет, скорее всего быстрее, чем ожидается.

Почему применяют роботов, а не людей? Часто не потому, что роботы не болеют, не уходят в отпуск, не спят, а работают быстрее. Нет, роботы работают лучше, чем люди — часто настолько лучше, что делают недостижимое людьми (быстрее, точнее, меньше ошибок), плюс меньше отвлечений при решении рутинных задач и отсутствует время для отдыха. Это как замена землекопов экскаваторами, только в качестве землекопов выступают люди самых разных профессий.

Вот уже довольно давняя история, января 2019. Тогда в Walmart вместо уборщиков вышли 360 роботов фирмы BrainOS, в апреле к ним добавили ещё 1500. Эти роботы убирают лучше и быстрее, управляя обычными уборочными машинами. Аргументы про то, что их не нужно часто нанимать и дополнительно учить (среди уборщиков в год меняется от 30% до 100% персонала. И всех этих новеньких нужно найти, нанять, обучить — с роботами этого не нужно, их покупка, ввод в эксплуатацию и настройка занимают меньше времени) оказываются вторичными! Ракеты не пилотируются людьми потому, что люди делают больше ошибок, а не потому, что автопилот не бастует и не болеет!

Чтобы покупатели не катались на автономных уборщиках Walmart, место водителя на них отгораживали в 2018 году жёлтыми ленточками³⁵⁵. А ещё 600 роботов BrainOS в 2022 вышли на работу по сканированию товарной выкладки³⁵⁶. Всего только на этой платформе роботов на конец 2023 года выпущено было 30 тысяч роботов-уборщиков, которые убирают площадь 3500 квадратных километров³⁵⁷. Если считать, что один робот заменяет одного человека (что не совсем так), то это небольшой городок уборщиков — но и убираемая площадь получается почти полторы Москвы (2511 кв. км), получается много, по 118000 кв. метров на одного робота. При этом на одной зарядке робот может убрать почти 3 тысячи квадратных метров. А ведь речь идёт только об одной робототехнической фирме и одном виде труда!

Уборщики — это далеко не единственный вид роботов в магазинах. Сами магазины становятся роботами (из них исчезают в том числе и кассиры, контролем наличия товара на полках занимаются роботы, и всё остальное тоже переходит к роботам)³⁵⁸.

Это нормально, этого не нужно бояться. Ещё недавно 90% людей были заняты сельским хозяйством, а сегодня — именно благодаря машинам — осталось всего 3% «крестьян» (хотя работников современных ферм меньше можно назвать «крестьянами», они больше похожи на заводских работников по стилю их жизни и виду занятий). Несмотря на это, все высвободившиеся из сельского хозяйства люди оказались заняты, даже с учётом того, что число людей на Земле сильно подросло! Более того, и пролетариата, заводских рабочих, сегодня тоже не так много, как ещё полвека назад! А бедность, тем не менее, существенно в планетарных масштабах уменьшилась.

Основная ошибка рассуждений на тему «роботы отберут работу» в том, что количество работы в мире не константа, постоянно появляется новая работа по мере вовлечения в деятельность людей всё новых ресурсов и бесконечного развития технологий. Все эти заявления «роботы заберут работу у людей» — пугалки из ненаучной фантастики, фэнтези. Люди (а через некоторое время люди с машинами) придумывают себе и машинам всё новые и новые занятия вместо тех, от которых их освободили машины, сумма труда в мире с распространением каждой подрывной технологии только растёт. И прежде всего уходит самый тяжёлый, неблагодарный, опасный труд.

Есть ещё и резерв увеличения свободного времени, которое можно потратить и на просто отдых, и на развитие/образование: люди радуются, а не печалятся, что «электричество и машины отняли работу». Одну работу отняли, пять других дали!

Этот тренд на сокращение рабочих часов для нормальной жизни проявляется и в росте свободной занятости (freelance, gig economy, platform economy³⁵⁹) с использованием для поиска работы онлайн-платформ для самых разных видов мастерства. Есть даже платформы для оплаты меценатами чьих-то хобби (patronization). Если ты мастер в каком-то хобби, то тебе за это могут заплатить! Хобби и работа постепенно теряют чёткую границу между ними, спорт (демонстрация того, что человек не утратил качества обезьяны — быстро бегает, хорошо дерётся, далеко кидает тяжёлые предметы, умеет командой загнать никому не нужный мяч в ворота при противодействии другой команды, и т.д.) стал для профессиональных спортсменов работой, а для миллиардов людей развлечением — вместо чтения книг, просмотра художественных фильмов или хотя бы какой-то физической активности (бег трусцой, танцы). Киберспорт продолжает эту традицию и тоже стремительно профессионализуется. Шоу-бизнес — это тоже бизнес, это не художественная самодеятельность, это серьёзные деньги. Праздной публике в Риме, как мы помним, нужно было хлеба и зрелищ, игнорировать это нельзя. Чем больше избыток хлеба, тем (при отрицательной полезности труда, помним об этом из праксеологии как варианта методологии!) больше желание развлечений — и избыток средств люди будут тратить на это.

Сдвиги в занятости налицо, растёт сектор услуг — заговорили даже о «маникюрной экономике» (the manicure economy)³⁶⁰, так назван очередной сдвиг массовых работ от офисной-распределительной к «грумингу»³⁶¹.

Это не первый такой сдвиг в занятости, мы уже упоминали, что раньше были сдвиги от заводской фабричной работы к современному состоянию увеличенной доли работы с высокой долей умственного труда, а ещё раньше — от крестьянской работы к заводской фабричной.

Количество маникюрщиц в мире за последние 20 лет увеличилось впятеро. Автоматизация потихоньку вытесняет текущие работы и уменьшает стоимость жизни. Люди могут позволить себе «выгорать» (то есть проявлять недовольство имеющейся у них работой настолько, что бросать её, не рискуя умереть с голоду) и заниматься тем самым грумингом как персонально оказываемыми услугами массажа, маникюра, банных и спа услугах, ароматерапии (при полном понимании, что это развлекательный ритуал и никто никого не лечит) и далее по всему списку подобных мероприятий. Массовое репетиторство тоже тут (а рынок ему создаёт, конечно, обязательный экзамен).

Маникюр начинает восприниматься как жизненная необходимость, причём он должен радовать, то есть быть разным. Надо иметь разнообразие лаков, но мелких упаковок «на один раз» нет, а кроме того, надо сошлифовывать предыдущий лак, что тоже делать самому неудобно, и вообще красить самому неудобно. Ногти быстро отрастают, раз в пару недель надо идти «на ногти» — и делать маникюр, при этом ещё и записываться, как к врачу, чтобы не стоять в очереди. Это породило даже мем:

Походы к психологу, массажисту, в спа — тот же тренд «персональных сервисов», люди делают груминг друг другу (в том числе и в мозгах). Есть несколько лет, чтобы рост маникюрной экономики продолжался, люди переходили с низкооплачиваемых работ, где контактируешь с оборудованием и материалом, но не людьми (типа «швея на фабрике» или вариант знаниевой работы «корректор в издательстве») на личное обслуживание друг друга. Только в США число рабочих мест в сфере ухода за кожей и профессионального макияжа выросло с примерно 14000 в начале нового тысячелетия до почти 70000 в 2023 году. Число рабочих мест в сфере маникюра выросло с менее чем 30000 до почти 150000.

В статье про маникюрную экономику дальше идёт список профессий с максимальным ростом занятости за двадцать лет. Там, конечно, есть машинисты метро и водители городских автобусов, равно как специалисты аэродромов и пилотов (транспортная сеть развивается), операторы по обслуживанию нефтяного и газового оборудования (нефть и газ всё-таки в основе энергетики, энерговооружённость растёт, в том числе и транспорта), и даже специалисты по надзору (compliance officers), но всё-таки это выглядит в табличке как исключение — они теряются среди массажистов, персональных финансовых советников и даже тренеров собак. По большому счёту, такси и курьеры — они тоже тут, работают по персональным заказам, «облечены доверием» и должны поддержать минимальную коммуникацию с клиентом, а не просто выполнить свою работу.

Этот тренд тоже недолгий, он будет перемолот двумя новыми технологиями:

• AI возьмёт на себя умственную часть работы, может даже развлекать клиента (разговоры с AI уже не редкость, рекомендательные системы для выбора сервиса делаются современными технологиями довольно просто — это проще, чем медицинская диагностика, а её делают уже не хуже врачей). С репетиторством тут ещё проще, эксперименты на эту тему идут вовсю, ибо программа экзаменов и что там нужно отвечать, хорошо известна, ошибки учеников тоже хорошо известны.

• роботы возьмут на себя физическую часть работы, в том числе и в маникюрном деле, при этом значительная часть работы уже выполняется даже не руками работника, а мелкими станочками, а маникюрные роботы³⁶² уже есть, им для распространения надо только подешеветь.

За среднеоплачиваемыми офисными работниками (в том числе линейными менеджерами) и даже высокоплачиваемыми инженерами тоже придут, конечно, но чуть попозже. Так, за двадцать лет потребность в работах вроде "бюджетный аналитик" уменьшилась на 40%, а в работах вроде авиационных и космических инженеров уменьшилась на 25% (данные из таблички всё в той же статье). Так что общий тренд тут — чем более высокооплачиваема работа, тем она оказывается стабильней (и часто она требует довольно плотных контактов с людьми), чем менее оплачиваема — тем больше от работы с чем-то неживым она оказывается переползающей к работе с людьми. Вот вам и рост soft skills — то есть умение не переругаться со всеми, а как-то наладить отношения.

Шутка: если вы занимаетесь личным стратегированием и пытаетесь понять, в получение какого мастерства вам надо инвестировать своё время, вам платят мало и вы мало общаетесь с другими людьми (скажем, вы сейчас инженер, который смотрит только в экран своего CAD), то подумайте о карьере массажиста, на некоторое время (пока не появится робот, который будет массажировать лучше вас, или другой инженер, который тоже переквалифицировался в массажиста, попутно получив медицинское образование) это поможет. И да, ещё надо будет научиться приятно общаться и самому хорошо выглядеть. При этом в этой шутке есть только доля шутки.

Чтобы в быстро меняющемся (иногда в корпоративном стратегировании говорят VUCA³⁶³ — volatility, uncertainty, complexity, and ambiguity) мире найти своё место, надо понимать, как вообще устроены отношения людей по поводу коллективной работы. Много людей разных профессий и роботов с разными инструментами коллективно делают что-то чудесное, объединяя свои уникальные знания — как они договариваются? Как можно договариваться, а ещё лучше — договаривать всех этих людей между собой эффективней? Например, задействовать мастерство сильного мышления — мастерство рациональной работы, системного мышления, методологии, системной инженерии. Как быстро выучить себя и коллег новому мастерству? Задействовать мастерство инженерии личности. Как хоть что-то уже знать про устройство организаций и проектов, в которых надо будет участвовать, понимать происходящее не только на уровне ощущений и эмоций, но и хоть как-то рационально — это мастерство системного менеджмента. Да, это ровно содержание программы рабочего развития мастерской инженеров-менеджеров. Другое дело, что эта программа для тех, кто уже имеет высшее образование, а надо бы такому учить ещё в школе или (если уж в школе никак не получается) в вузе.

В любом случае, готовьтесь менять работы и проекты часто, это бег по тонкому льду, долго удержаться на одном месте уже невозможно, а будет ещё невозможней. Ещё пару десятков лет назад человека, который быстро перелетал с одной работы на другую, называли «летун». Сейчас такому уже никто не удивляется. Удачных проектов, которые развивают какие-то системы много лет — их мало, больше проектов, которые успевают выпустить лишь несколько версий удачной системы, и затем в эти проекты приходит сбоку новая технология, и либо проект разваливается, либо этим новым начинают заниматься новые люди (или новые роботы).

Главное мастерство (людей, роботов, организаций — это неважно) уже сейчас — выполнить стратегирование, найти и затем быстро освоить новый очередной вид работы (очередную технологию, метод, культуру, инженерный процесс, рабочий процесс). Тут надо ещё понимать, что кроме собственно инженерной части (уметь разобраться с каким-то станком/софтом, чтобы на нём получить нужный результат), надо будет становиться частью какой-то организации, много общаться — и с людьми, и с системами AI, и даже с целыми другими организациями (например, другими оргзвеньями, другими предприятиями, другими рабочими группами проекта) как целым. Ибо рабочие роли, где надо просто крутить ручку на знаниевом или физическом конвейере, не обращая внимания на происходящее вокруг с людьми и их постепенно автоматизируемым окружением, будут исчезать.

Людям придётся массово превращаться из условных одиноких волков в условных кошечек, которые вроде гордые и независимые, но зато крайне симпатичны и даже ласковы, чтобы их кормили. Кошечки, конечно, по большому счёту не нужны, это даже не собаки, которые могут быть служебными. Но без кота и без маникюрщицы жизнь не та, поэтому эти занятости востребованы. То есть достаточно быть ласковым и ухоженным, а также уметь ходить в туалет, а не под себя, чтобы быть прокормленным не хуже котов, а также быть прогулянным не хуже собак. Но если хотите чего-то большего, придётся получить образование.

Образование (усиление интеллекта путём обучения интеллект-стеку фундаментальных методов, мы занимаемся образованием и при обучении методологическому мышлению по нашему руководству) как подготовка к жизни означает не то, что вы получаете какую-то профессию (она всё одно пропадёт через год-другой), а то, что вы быстро справитесь со сменой занятости. Каждый год у вас будет как «выпускной», снова «выход в жизнь», снова «начинаем работать».

При этом необразованных котов очень, очень неплохо кормят. И они крайне нужны, востребованы на рынке. Если верить данным производителя кормов и товаров для животных Mars Petcare, в 2021 году в России насчитывалось 40,8 млн домашних кошек и 22,6 млн собак. Такие животные были в 59% семей. А на маникюр и массаж ходят, даже если уже совсем сил не осталось, откуда и мем (хотя, конечно, не всё население ходит). Так что думайте: может быть, вам и не нужно хорошее образование с какими-то трудными hard skills типа умения разбираться с абстрактными неформальными и формальными описаниями методов (руководство по методологии). Классическое образование вообще когда-то учило мёртвым языкам, сейчас хотя бы живым языкам учат, хотя часть из них — языки программирования и моделирования. Эти языки программирования, моделирования, онтологизирования (иногда говорили «инженерии знаний») — про одно и то же, это языки описания алгоритмов, причём мы уже обсуждали, что алгоритмы выполнения компьютерами вычислений и алгоритмы выполнения создателями работ общего вида — это одни и те же алгоритмы. Получается, умение моделировать (в том числе моделировать методы/технологии/культуры) — это важнейшее умение, языками надо владеть в том числе и для того, чтобы выражать ими алгоритмы каких-то методов.

Но просто «быть умным» или даже «быть мудрым» явно не хватит для того, чтобы обрести стабильность. Автоматизация и добычи хлеба, и добычи развлечений гарантирует вам частую смену работы: вам не удастся много и долго заниматься в жизни одним и тем же делом, даже если вы перешли работать из реального сектора в сферу развлечений, удерживаться на работе долго — это точно невозможно ни фирме, ни человеку! Старая работа будет существовать некоторое время, а затем «неожиданно» подрываться и исчезать по самым разным причинам, приходящим «сбоку», поэтому и вам, и вашей (постоянно развивающейся, обучающейся новым рабочим процессам, новым технологиям, новым культурам производства, если она хочет уцелеть) компании нужно будет постоянно задействовать своё умение делать что-то новое.

Нужно будет регулярно вписываться в новые проекты, занимать какое-то место в прежде чужих для вас графах создателей. Если вы этого не умеете, то придётся научиться, то есть приобрести какой-то уровень интеллекта как способности решать проблемы, которые раньше не встречались. Вы должны уметь разобраться со стратегией той организации, в которую попали и согласовать свою собственную стратегию с этой стратегией организации. И лучше бы вам это сделать как симбионту для этой организации, чем как паразиту.

Подчеркнём ещё раз, что все эти рассуждения о неминуемой тотальной безработице и одновременно «многоработице» безмасштабны: они относятся к ролям личности, к личности в целом, а также к команде, коллективу (команде команд), организации в целом. Более того, это относится и к системам AI, и к роботам (проблемы роботов старых моделей, оказавшихся на свалке, очень частый сюжет в фантастике, но скоро это станет не фантастика. Сколько у вас дома оказалось вполне исправных телефонов и ноутбуков, которые просто устарели? Давно выкидывали последний такой? К вам и вашей организации это тоже относится: вы ведь тоже можете оказаться «старой моделью»).

Если организация вовремя не поменяла людей на машины, то конкуренты обязательно используют машины — и продукция организации будет или хуже, или более дорогой (или и хуже, и более дорогой одновременно). И при сопротивлении автоматизации (луддизм³⁶⁴ разного сорта) людей всё равно придётся уволить, но уже может быть вообще всех в силу того, что компания разоряется и не может больше платить зарплату (в этот момент это «зряплата»), а не только тех, кого нужно было вовремя заменить роботами. Если вы в компании много автоматизируете, причём больше, чем конкуренты, то парадоксально, но вы будете расти — скорее всего, вы будете не увольнять людей, а нанимать их. Но и это будет временно, вечный рост не гарантирован. В эволюции всегда так. Динозавры доминировали, но вымерли. Фирма Kodak была знаменитой, но сейчас она практически неизвестна.

Если в организации в ходе автоматизации/«цифровой трансформации»/интеллектуализации высвобождаются люди, необязательно сохранять им рабочие места. Высвобожденные люди найдут себе новую работу, причём не обязательно внутри этой же организации. Может быть, они найдут себе работу/job/занятость даже лучше, чем она у них была. Но если организация быстро растёт в силу той же автоматизации, новую занятость люди найдут в той же организации. В любом случае, уволенные не останутся безработными! Это не ответственность организации трудоустраивать всех высвободившихся работников, это ответственность работников находить себе работу/job/занятость и быть достаточно образованными для этого!

Инновации: всегда сбоку

Инновации — это не любые технологии, а только те, системы и сервисы для которых сумели выйти на рынок и продаются с прибылью.

Большие эволюционные переходы в технологиях называют подрывом/disruption: появление инновации, заставляющей производителей продуктов-конкурентов делать «вираж» или вообще исчезать с рынка. Скажем, появление автомобиля подорвало всю гужевую («лошадиную») инфраструктуру: сделать «вираж» или вообще уйти с рынка вынуждены были поставщики подков, кнутов, карет, конезаводчики.

Прорыв/breakthrough — это когда появилась инновация, которую способны повторить участники рынка, что даёт возможность этим участникам не исчезнуть. Обычно речь идёт о каком-то развитии технологии, но не её смене. Так, прорывом был переход от германиевых транзисторов к кремниевым: это резко удешевило производство и подняло характеристики. Но переход на кремний не привёл к подрыву каких-то бизнес-эко-систем, не заставил какие-то фирмы делать «виражи» или вообще разоряться.

Проблема с непредсказуемостью будущих технологий как прорывных или даже подрывных в том, что все прорывные и подрывные инновации происходят не из тех отраслей, где они реализуются — поэтому-то их и невозможно предвидеть, раннее их развитие невозможно отследить. Конечно, можно найти какие-то контрпримеры для использованного квантора всеобщности «все», но это будут, скорее, исключения, чем правило.

Речь идёт об изобретении как результате стратегирования: есть какая-то недоступная функция/метод/технология гипотетической системы, надо придумать конструкцию из экономически оправданных аффордансов, которые выдадут в своём взаимодействии эту функцию системы. Если нашли — то вот она, инновация: подрыв или прорыв. Если не нашли, или даже нашли, но экономически пока это невыгодно — ищем дальше, инновации нет, даже если есть работающий прототип. Тут можно спорить, должен ли быть MVP или MAP (minimal awesome product) экономически выгоден, или он должен быть всего лишь «доказательством идеи» (proof of concept, PoC).

В любом случае, нужные аффордансы приходят «сбоку», из других предметных областей, нежели рынок целевой технологии. Микроволновку изобрели спецы по радарам, а не производители кухонного оборудования — мясорубок и холодильников. Компьютер на радиолампах изобрели радиоэлектронщики, а не математики. Самолёт — владельцы мотоциклетной мастерской братья Райт³⁶⁵. Роботами-юристами начали торговать в России провайдеры сотовой связи МТС и Мегафон³⁶⁶. Они же торгуют ещё и музыкой. Сбербанк уже тоже торгует музыкой³⁶⁷, и он уже не «банк», а просто «Сбер». Рынок такси взрывает не только Uber, но в России это Яндекс.такси³⁶⁸, ибо Яндекс уже не только интернет-поисковик.

Откуда придёт подрыв вашей (личной или корпоративной, стратегирование в них имеет одну природу) технологии — непонятно, но чаще всего это будут «пришельцы сбоку». Своих-то конкурентов вы отслеживаете, но что делать с тем, когда самые сильные конкуренты появляются стремительно «из ниоткуда», «сбоку»? Их не отследить, слишком много предметных областей надо отслеживать на предмет потенциальных изобретений, это нельзя спланировать.

Экспоненциальные технологии делают эти подрывы стремительными. Вот пример вычислительной оптики:

В иллюстрации³⁶⁹ один из снимков сделан в сентябре 2016 году смартфоном iPhone 7 Plus, а другой — камерой-зеркалкой с большим объективом EOS650D. Вы можете угадать, какой снимок чем был сделан? Левый — смартфоном, правый — зеркалкой.

До сентября 2016 года было принято считать, что позиции производителей больших фотоаппаратов хорошо защищены законами физики: эффект bokeh³⁷⁰ красивого размытия фона при чёткой фигуре на переднем плане мог проявляться только на фотоаппаратах с большими объективами.

Apple пришёл на фоторынок, где его никто не ждал, принёс вычислительную оптику, а не большой объектив. Экспоненциальные технологии сделали дешёвыми процессоры и маленькую точную механику — потребовались две дешёвые маленькие камеры, а не один большой дорогой объектив. На улице 2016 года тем временем соревновались хипстеры: у кого фотоаппарат больше, тот и победил в качестве снимков!

Дальше всё быстро: эффект bokeh в сентябре 2016 года был продемонстрирован на двух камерах iPhone 7 Plus, но уже в сентябре 2018 года цена опять упала, AI даёт тот же эффект на одном сенсоре — Google Pixel 2 series, Apple iPhone XR. Да ещё и телефоны с 3-5 камерами стали обыденными. Потребность в фотоаппаратах стала нишевой (и эта история произошла уже после того, как цифровая фотография вытеснила плёночную), продажи фотоаппаратов (включая цифровые) шли в 2023 уже на уровне 1977 года, причём эти цифры продолжают падать³⁷¹.

И это было не последней точкой в удешевлении. Во время перехода на удалённую работу практически все сервисы видеоконференций предоставили возможность не только размыть фон, но и вовсе его заменить. Речь идёт уже о супердешёвых веб-камерах на ноутбуках и в компьютерах, и не о неподвижных картинках, а о видео, и ещё об универсальных процессорах. Экспоненциальные технологии делают своё дело: что было диковинкой на самых дорогих моделях телефонов в 2017 году, стало дешёвым общим местом везде. Заодно люди, которые до этой технологии стеснялись своей домашней обстановки, просто перестали её показывать, они заменили её на выбранный ими фон — и сэкономили на интерьере. Наоборот, показать крутую домашнюю обстановку стало привилегией богатых! Повторяется история с нейлоновыми рубашками: сначала их носили только самые богатые, а затем их стали носить только самые бедные. Такое типично для экспоненциальных технологий.

Вычислительная оптика также помогла к 2021 году разобраться со съёмкой смартфонами в темноте, в том числе и съёмкой видео высокого разрешения с повышенным контрастом. Нужда в больших и дорогих фото- и видеокамерах с особыми их возможностями резко упала. Tony Seba приводит хорошие примеры, почему прогнозы не оправдываются. Они не учитывают экспоненциальных зависимостей! Пару десятков лет назад точно такой же переход шёл от плёночной фотографии к цифровой — и всё началось и закончилось за пяток лет. С фотоаппаратами как таковыми происходит всё то же самое.

Производители смартфонов, а теперь и производители ноутбуков пришли в сферу фотографии «сбоку» и буквально за несколько лет дали доступ к качественному фото и видео для практически всех жителей планеты. Это дало возможность необычным применениям фото: контроль качества работы удалёнными сотрудниками (они фотографируют результаты своей работы, это практически бесплатно), платёж по карте, когда не нужно вводить её номер, а он распознаётся автоматически, платежи по штрих-кодам и QR-кодам, автоматизация переводов надписей на иностранных языках, прокторинг³⁷² для онлайн-сдачи экзаменов. Идут пробы новых применений, например было массовое увлечение играми типа Pokemon Go, где изображение покемонов накладывается на изображение реального мира, но широкого распространения это не получило. Тем не мене, представьте, сколько людей приложили свои знания и умения, участвуя в этих изменениях. А ведь это только один из небольших сюжетов происходящих перемен! Фотография, бывшая уделом немногих, превратилось в видеографию, доступную практически всем. У каждого видеокамера в кармане, и даже не одна (в смартфоне есть и камера для селфи, и камера для съёмки, и встроенный микрофон для записи звука на видео, и можно сделать «захват экрана» для видео происходящего на экране). К этому добавьте возможности «нейрохудожников», сервисы по изготовлению персонализированных аватаров и эмотиконов для социальных сетей, сервисы редактирования фотографий, сервисы производства видео, сервисы «оживления фотографий», возможности тут бесконечны, и это всё уже можно купить, а кое-что из этого доступно и бесплатно.

Но и это ещё не конец истории про «физика не позволит сделать объектив меньше»! В 2021 году физиками был предложен новый оптический элемент: «пространственная пластина» (spaceplate), которая позволяет убрать пространство между линзой и матрицей. Если заменить линзу плоской металинзой, а необходимое пространство за этой линзой заменить пространственной пластиной, то можно сделать реально плоский объектив. Как пишут изобретатели, вполне можно всю заднюю стенку смартфона превратить в объектив, получив в 14 раз лучше разрешение и чувствительность при съемках в темноте, чем у больших фотоаппаратов с большими объективами³⁷³.

Если перейти на подобную оптику, то можно получить плоские телескопы, плоские микроскопы, и никаких утолщений для камер на задней панели смартфонов — вопрос теперь только в том, чтобы это сделать коммерчески выгодным. В области микроволн такие устройства в составе аппаратуры (а не только в экспериментальной установке) уже сделали³⁷⁴, в оптическом диапазоне — пока нет. Такая новая оптика придёт в классическую оптическую промышленность сбоку, производители телескопов и микроскопов никак не ожидают, что подобная новинка появилась не от конкурирующих производителей телескопов и микроскопов. Предыдущий тип оптического элемента «линза» был предложен 400 лет назад, и с тех пор не было новинок — до 2021 года! Изобретатели «пространственной пластины» пришли из лаборатории квантовой оптики, а завод-производитель пространственных пластин будет не заводом оптического оборудования с парком шлифующих стёкла станков, а заводом нанометаматериалов с абсолютно другим оборудованием!

Когда речь идёт об информационных технологиях, всё происходит ещё быстрее и неожиданней. На удалённую работу даже там, где это было нельзя себе представить, мир перетянулся разве что не за пару месяцев. MS Teams как средство удалённой работы (отнюдь не все пользуются Zoom) поднял пользовательскую базу с 0 до 18 миллионов человек за два года, а потом за три месяца пандемии дорастил её до 77 миллионов человек. Ещё через год в MS Teams было уже 145 млн. человек³⁷⁵. Много фирм буквально за пару месяцев начала пандемии сообразили, что дорогой офис — это не преимущество, а недостаток. И начали нанимать сотрудников по всему миру, а не только проживающих недалеко от офиса. Это означает, что рынок офисной недвижимости был по факту подорван софтверными фирмами, обеспечивающими сервисы удалённой работы³⁷⁶, беда пришла «сбоку».

Мир меняется от принципиально непредсказуемых факторов, которые приходят «сбоку», из неожиданных мест. Вы не можете предсказать изобретения 8 миллиардов человек (хотя в реальности немного меньше, вычтите детей и необразованное население отсталых стран). В том числе и «антиизобретения» законодателей, типа пандемических локдаунов как неконституционно вводимых ограничений на передвижение, или запрета каких-то вычислений типа вычислений для криптовалютного рынка или вычислений для показа вебсайта кем-то запрещённой социальной сети. Вы не можете предсказать войну. Эти непредсказуемые изменения распространяются по земному шару крайне быстро — речь идёт об экспоненциальных, и даже гиперэкспоненциальных изменениях, у которых нет единого руководящего центра. Это техно-эволюция.

Примеры мы привели главным образом из производства, но примерно то же самое творится в науке. Современная лингвистика была закрыта буквально за несколько лет: много лет нарабатываемые лингвистами языковые модели оказались менее точными, и менее полезными на практике, чем языковые модели на основе нейронных сетей — и делали их отнюдь не лингвисты, а специалисты по машинному интеллекту. Математики, специалисты по архитектуре нейронных сетей, программисты для ускорителей матричных умножений (GPU) пришли в лингвистику «сбоку» — и они теперь на лингвистическом фронтире с момента появления архитектуры transformer³⁷⁷ в 2017 году, а не лингвисты с их тысячелетним багажом знаний. А теперь появились на базе этих изменившихся представлений о естественном языке и его природе научные работы, где по-новому оценивается роль естественного языка по сравнению с использованием формального математического языка в логике³⁷⁸.

Даже если брать математику в приложении к физике, то и тут всё быстро, и «классические учёные» могут уже не поспевать за прогрессом. Графовую нейронную сетку «дистиллировали» в алгебру, а затем подобрали в этой алгебре математическую форму (символьная регрессия³⁷⁹, или выявление/discovery символьных моделей) для выражения закономерностей в физических наборах данных. Чтобы проверить подход, переоткрыли уравнения ньютоновской механики, переоткрыли гамильтониан из квантовой механики, и предложили закон (математическую формулу) для описания гало тёмной материи в космологии — чтобы продемонстрировать не «переоткрытие», а «открытие»³⁸⁰. Основная физическая интуиция как раз и берётся символьной регрессией, в основе которой эволюционный алгоритм. Лидер в этой области символьной регрессии вполне уже коммерциализован: эволюционный/генетический алгоритм символьной регрессии Eureqa, вошёл в состав DataRobot³⁸¹. Новую физику теперь ждут из большой физической модели на нейросети, создаваемой по примеру большой языковой модели³⁸². Эти примеры можно продолжать и продолжать: критики продолжают утверждать, что автоматизация творчества (ибо наука вся базируется на творчестве) невозможна, а инженеры просто автоматизируют и творчество тоже.

По большому счёту всё равно: у вас предпринимательская гипотеза (концепция использования), научная гипотеза, инженерная гипотеза (концепция системы), бизнес-гипотеза (бизнес-модель): выдвижение гипотез и их рациональное оценивание относится к общим мыслительным умениям, хотя по-старинке называется «научным мышлением». Особо обратим внимание, что это мышление не одного человека, играющего роль учёного, разработчика, менеджера, продвиженца. Нет, это мышление безмасштабно и неантропоцентрично: реализуется и отдельными людьми с их компьютерами, и большими организациями с их компьютерами, и даже просто компьютерами с системами AI. Более того, это мышление выходит за рамки отдельных организаций в пределы сообществ и обществ (идёт обмен информацией).

Выдвижением гипотез/догадок (каких-то объяснений, дающих предсказания будущего — порождающих/generative моделей) и их проверкой (логической и экспериментальной) занимаются ежедневно миллионы учёных, но также и миллиарды самых разных работников: инженеров, менеджеров, продвиженцев, учителей, чиновников, разглядывающих многочисленные данные по их предметам интереса. Идеи для стратегирования — это гипотезы, догадки, они не научные гипотезы, но они одной природы с научными гипотезами, это догадки, которые должны выдержать проверку логикой, а затем и проверку жизнью (эксперимент)!

Автоматизация предлагает в том числе облегчение труда (вплоть до полной замены этого труда) для самых разных людей, занимающихся выдвижением догадок/гипотез/guesses в самых разных деятельностях. Современные системы AI вроде ChatGPT уже могут выдвигать какие-то гипотезы, но таких сервисов много, они уже конкурируют, цена рациональных объяснений всё более и более сложных явлений будет падать. При этом цена самых трудных объяснений будет оставаться прежней и не падать, зато доступная для этой высокой цены трудность поиска и разнообразность доступных приёмов объяснения будет всё время расти.

Разработчики алгоритма Eureqa не имели какого-то отношения к физике, ко всей этой космологии и гамильтонианам, они просто «разрабатывали алгоритмы искусственного интеллекта», что бы это ни значило. Им всё равно, объяснять ли подобным алгоритмом движение планет, или объяснять движение курсов акций на фондовом рынке. Но они со своими объяснениями сначала пришли в науку, и продемонстрировали, что их алгоритм выдвигает гипотезы не хуже Кеплера. Их алгоритм реализует научное мышление.

Так что и классическая наука уже не будет прежней, к ней тоже пришли «сбоку»: к физикам пришли люди, занимающиеся нейронными сетями и символьной регрессией, а не физикой. К биологам (в том числе фармацевтам) пришли с решением задач складывания белка люди, которые отработали алгоритмы на играх, таких как игра Го³⁸³.

Почему все эти вопросы обсуждаются в руководстве по методологии? Потому что стратегирование это всё должно учитывать, вы должны понимать, откуда в жизни берутся новые методы работы и поддерживающий их инструментарий.

Копают люди давно уже не руками, и не палкой-копалкой, и не лопатой, а экскаватором. Для вытаскивания законов природы из данных палка-копалка из нейронных сетей и символьной регрессии уже готова, опубликовано множество статей. А лет через пять ждём, что новые законы природы будут грести уже лопатой. Лет через десять можно ждать и «научного экскаватора». Просто удивительно, как мало людей, понимающих суть происходящих перемен. Если вы занимаетесь личным или корпоративным стратегированием, ваш горизонт прогнозирования (и затем горизонт планирования) хотя бы пара-тройка лет (а иногда и больше), то вы не имеете права игнорировать эти тренды.

В науке тоже всё новое приходит сбоку, и неудивительно, что «старые физики» не будут понимать (или уже не понимают), что происходит — как уже сейчас «старые лингвисты» не понимают, как устроены современные системы машинного перевода, которые вроде бы должны использовать разработанную классическими лингвистами теорию языка, но по факту они её не используют, поэтому огромное количество теорий языка в большинстве своём оказались невостребованными.

Искусственный (он же машинный) интеллект развивается сейчас особенно быстро, и Тим Урбан даже нарисовал про это иллюстрирующую экспоненциальные технологии картинку³⁸⁴:

Это картинка 2015 года. В то время трудно было представить, что робот-юрист возьмёт на себя 80% юридической работы в фирме, держащей миллионы контрактов. Или что AI победит чемпионов мира в Го, в StarCraft II — а потом эти алгоритмы будут использованы в промышленности. То, что GPT o1 будет отвечать на трудные вопросы на уровне докторов наук³⁸⁵ (хотя иногда и откровенно ошибаться в лёгких вопросах), но ещё она будет общедоступна сразу после её анонсирования³⁸⁶ — это тоже трудно было представить. Но это всё уже есть, и это только начало. Не верьте, когда говорят про принципиальные ограничения AI по сравнению с интеллектом людей — принципиальных ограничений нет. Да, искусственный интеллект может делать ошибки, и будет делать ошибки всегда. Но и люди тоже их делают.

Машинный интеллект по сфере своего использования такой же, как естественный: он может применяться везде. В том числе и в диджействе. Технология NeuralMix³⁸⁷ может разделить трек на вокал, перкуссию, бас и всё остальное. Смешивать два трека диджею можно уже не целиком, а отдельно каждую из инструментальных частей трека. Тут нейронные сети не просто автоматизируют труд диджея, но делают то, что человек раньше делать не умел. А ведь диджейство по факту массовая профессия: раньше учились массово семь лет в музыкальной школе, а теперь учатся год в школе диджеев — и пультов диджеев продаётся уж не меньше, чем роялей, просто на это уже мало кто обращает внимания. Сочиняет ли компьютер музыку? Да, конечно, таких сервисов уже много. Сочиняет ли новую музыку, или только перемешивает в новых сочетаниях давно известное? Конечно, сочиняет. Ответ юристов музыкального сервиса Suno³⁸⁸ на иск компании Sony в том, что в обучении были использованы треки этой компании был прост³⁸⁹: треки не копировались, а именно что были изучены, ровно как музыка изучается композитором. А потом неживой нейрокомпозитор сочиняет свою музыку, развивает музыкальную культуру. Он не копирует какие-то музыкальные произведения, он воспроизводит стили и жанры. Музыкальный AI моделирует методы, используемые музыкантами разных стилей и жанров, но не копирует произведения, там нет базы данных произведений! Есть знания о жанрах.

Последствия гиперэкспоненциального развития машинного интеллекта закрыты туманом будущего. Но уже сегодня понятно, что эти последствия будут весьма заметными для каждого человека на Земле. Масштабы? Например, треть IT-бюджетов реального сектора сегодня направлены на проекты с AI, это неожиданный, но факт³⁹⁰. Если вы занимаетесь стратегированием, учтите это!

Сегодняшние инвестиции дадут отдачу через пару лет, поэтому дайте время на разработку и запуск новых интеллектуальных IT-систем в производство. Жизнь на производстве будет меняться, и быстро: деньги-то в это изменение уходят не маленькие! Скажем, переход с плановых ремонтов (35% этих ремонтов «чинят не поломанное», то есть бесполезны) на ремонты по состоянию, моменты которых определяются программами AI, высвобождает в масштабах планеты огромное количество труда, который сейчас абсолютно бесполезен. Представляете, сколько это труда на планете — треть плановых ремонтов? Плановые ремонты — это зло! И победит их машинный интеллект. Дело не только в бесполезном труде людей. Если оборудование (например, турбину электростанции) не останавливать для ремонта, это дополнительный выигрыш. Человечество будет богаче. Машинный интеллект выгоден.

Машинный интеллект научился переводить с иностранных языков (включая самые экзотические) на уровне восьмиклассника (или уже десятиклассника? Или первокурсника? Или третьекурсника технического вуза? Качество перевода меняется так быстро, что не уследишь!). Профессиональные переводчики пока не потеряли работу, но изменения в мире оказались в другом — миллиарды людей получили доступ к плохому, но переводу через Гугл, Яндекс, и даже улучшенному качеству перевода через специализированный сервис DeepL³⁹¹ и отчуждённое от людей умение машины редактировать английский текст в соответствии с каким-то стилем в сервисе Grammarly³⁹². И это существенно добавило возможностей этих миллиардов людей на рынке труда. Никаких людей-переводчиков и редакторов-корректоров не хватило бы на такой объём обслуживания. Конкуренция на рынке труда возросла для многих работ, языковой барьер с учётом машинного перевода для этих работ перестал быть существенным, можно с мая 2025 года в реальном времени беседовать по видео с синхронным автоматическим переводом³⁹³.

А что с другими гиперэкспоненциальными технологиями? Там тоже всё интересно. Например, появились квантовые датчики, работающие на основе квантовой запутанности фотонов. И это даёт возможность построить новые типы микроскопов, которые могут изучать живые клетки в ходе их работы, не повреждая их лазерной подсветкой. Дальше появляется новый класс квантовых датчиков, и их цена тоже будет падать экспоненциально. Пульсоксиметры (измеряют как пульс, так и насыщение крови кислородом) в лучших моделях смартфонов появились ещё в 2015 году³⁹⁴, а в июне 2021 (мотивированный COVID-пандемией спрос породил предложение!) их стало можно купить в Москве даже в отдельном корпусе-напальчнике один и тот же по цене от 250 рублей (включая батарейку) до 2500 рублей: продавцы не успевают обновлять цены, всё этими пульсоксиметрами затоварено, цены упали за год практически вдесятеро — обнаруженная общая потребность так и работает: кратковременный всплеск цены и возгласы «дефицит», а затем современное производство мгновенно перестраивается, организует массовый выпуск и цены драматически падают. Это общий паттерн.

Если рассматривать алгоритмику в сочетании с новыми видами компьютеров (квантовые компьютеры), то и тут есть прорывы — квантовыми алгоритмами почти не занимались, ибо не было доступности квантовых компьютеров. Но вот когда такие компьютеры появились, появились и новые алгоритмы. Например, оказалось, что для успешного решения задачи коммивояжёра может требоваться всего один кубит³⁹⁵. Получается, что алгоритмика получает новое дыхание не только от математиков, которые придумывают новые алгоритмы, но и от физиков, которые придумывают новые компьютеры — компьютерная наука (информатика, computer science) является экспериментальной естественной наукой (подробней об этом — в руководстве по интеллект-стеку).

Время изменения массово используемых в мире технологий начинает быть более быстрым, чем время переобучения и человека, и отдельной организации, а затем и отдельных AI на задействование новых технологий. Люди не успевают переучиваться сами и не успевают переоснащать свои предприятия, чтобы успевать адаптироваться к новому быстро изменяющемуся миру. Вы можете пробовать переобучаться быстрее конкурентов, но они или начинают раньше, или сами учатся быстрее вас. Поэтому для выигрыша в конкуренции вам тоже приходится или начинать раньше, когда ситуация ещё малопонятна и надо рисковать, или переучиваться быстрее, когда ситуация уже понятна и риски не запредельны.

TEST Скорость обучения нейросети

!!! Прогресс в машинном интеллекте существенно зависит от мощности вычислителя и качества алгоритма. Известно, что мощность вычислителя растёт экспоненциально, по закону Мура. Что растёт быстрее — мощность аппаратуры, или качество алгоритмов обучения нейросети?

--- мощность аппаратуры, она растёт экспоненциально по закону Мура. С 2012 года, когда начали тренировать нейронные сети, к 2020 году согласно закону Мура скорость обучения была бы выше в 11 раз ### Нет, в реальности алгоритмы ускоряются быстрее — скорость вычислений стала больше в 44 раза за счёт алгоритмов, https://openai.com/blog/ai-and-efficiency/

+++ рост скорости алгоритмов обучения нейросети быстрее скорости роста аппаратуры ### Да, каждые 16 месяцев скорость алгоритмов увеличивается вдвое с 2012 года, это даёт x44 алгоритмически, а по закону Мура это было бы только x11, https://openai.com/blog/ai-and-efficiency/

Моделирование: всё новое приходит сбоку

Если бы во времена Чарльза Бэббиджа знали, как сделать вычислительную машину, то начали бы с отработки технологии надёжно работающих ламповых триодов. Если бы хотели сделать ракетную технику во время первой мировой войны, то начали бы с технологии жидкостных ракетных двигателей, если хотели бы делать микросхемы 100 лет назад, то начали бы с отработки технологии получения сверхчистого германия (или даже сразу кремния). Всё новое приходит сбоку. Заполните табличку для от трёх ключевых (основных, обеспечивающих конкурентное преимущество) технологий/методов/практик/«рабочих процессов» вашего проекта.

Заполните табличку для более чем трёх ключевых (основных, обеспечивающих конкурентное преимущество) технологий вашего проекта.

Архистратегии ежа и лисы

Корпоративное стратегирование (оргстратегирование) по большому счёту идентично личному, разница только в том, что пока сервис-ориентация (подробней об этом было в «Системном мышлении») не победила окончательно, компании могут ориентироваться на выпуск систем-продуктов, а личность всё-таки ориентируется на приложение своего мастерства как оказание сервиса. Помним при этом, что сервис — это синоним метода создателя-провайдера, только применяемого для изменения состояния внешних предметов метода, в том числе внешних систем (но могут быть и варианты, например, предметом метода может быть описание системы, но мысль провайдера в этом случае всё равно должна дотягиваться до физического мира и интересоваться тем, как будет использовано описание для изменения состояния каких-то систем).

Джим Коллинз в материалах своего сайта³⁹⁶ для книжки по корпоративной стратегии «От хорошего к великому»³⁹⁷ (2001 год) предложил вариант нахождения своего «призвания» (иногда сегодня это называют японским словом «икигай»³⁹⁸ — то, для чего вы просыпаетесь утром и вытаскиваете себя из постели).

При этом он неявно исходил из того, что в своей книжке назвал архистратегией (архистратегия — общий тип стратегии) ежа. Ёж использует один и тот же метод реагирования на неизвестную ему ситуацию: чуть что, он сворачивается в клубочек и выставляет миру свои иголки. Одно и то же действие в ответ на любое изменение вовне — каждый раз. И это ежа почти каждый раз спасает, стратегия оказывается эффективна.

Поэтому Коллинз предлагает в личном стратегировании найти эту стратегию ежа, найти своё главное преимущество, главное дело жизни. И дальше развивать это преимущество, сделать это своей профессией. В бизнесе это примерно соответствовало очень модному в 20 веке SWOT (Strengths, Weaknesses, Opportunities, and Threats)-анализу³⁹⁹.

В личном стратегировании Коллинз предлагал написать на трех разных листах бумаги списки деятельностей, которые а) вы делаете страстно, б) которые вы делаете лучше всех, в) за которые вы могли бы получать оплату.

После чего вам надо отдать эти листки вашим друзьям, чтобы не вы, а они обобщили то, что объединяет эти списки. Этим общим (тем, к чему у вас страсть, к чему есть талант, и за что платят) и занимайтесь, это и есть ваш личный икигай. Друзьям отдать списки надо, ибо у вас самих «глаз замылен», вы можете не заметить общее между пунктами в этих списках. Сегодня можно было бы отдать такие списки AI-ассистенту (заодно заметим, что ещё не каждый найдёт три листа бумаги для того, чтобы сделать эти списки по методу, предложенному Коллинзом всего четверть века назад).

Мы живём даже не во время перемен, а во время перемен перемен (меняется уже способ, которым проходят сами перемены), стратегия ежа сегодня перестала срабатывать! Коллинза критикуют, его теории стратегирования и для компаний, и для людей оказались не работающими!

Почему его способ не срабатывает даже для личного стратегирования? Все пункты в трёх списках закрываются туманом будущего. Меняется то, к чему у нас страсть (мы ещё не знаем, от чего будем без ума через пару месяцев, оно просто ещё не открыто, а к чему страсть была, к тому мы охладеваем — надоедает!), меняется то, к чему талант (мы тоже можем не знать об этой деятельности, но завтра выяснится, что у нас к ней талант!), а уж за что платят — так это и так очевидно, что существенно меняется каждые несколько лет.

Всё покрыто облачками тумана будущего, и поэтому приходится прибегать к другой архистратегии — архистратегии лисы. Лиса (недаром она считается «хитрой») каждый раз делает что-то новое при встрече с проблемой (которую пока неизвестно, как превратить в задачу, решаемую известным методом): то хвостом помашет, то засаду устроит, то тявкать начнёт, то побежит со всех ног, и всё это в зависимости от обстоятельств.

Лиса тоже добивается успеха во многих случаях, но в совсем новых обстоятельствах у неё появляется шанс угадать подходящее действие — этого шанса уже нет у ежа, он новое угадать не может, он гарантированно проиграет. Преимущество ежа пропадает, если изменения происходят быстро и изменения различны по своей природе. Какой выход? Просто выполняйте практику, предложенную Коллинзом, регулярно! Это не «определение вашего призвания в жизни». Это определение интересного, выгодного и посильного дела «на сейчас». Стратегия лисы — это просто «ситуативная стратегия ежа», которая выполняется не один раз, а ритмично, регулярно. Стратегия — это ничто, стратегирование — всё, каждый раз вы заканчиваете очередной такт стратегирования новой стратегией.

Все эти рассуждения идентичны для личного, командного (внутри крупной компании), корпоративного стратегирования.

Туман будущего не позволяет поставить какую-то долгосрочную цель, не позволяет долго использовать единожды выбранную стратегию ежа: быть меднолобым упёртым фанатиком, делающим одно и то же независимо от стремительно меняющихся обстоятельств. Если цель хорошо видна (то есть у вас есть концепция целевой системы, изобретение сделано, осталось только немного доработать идею до реализации), то она уже не в далёком будущем и поэтому не может считаться «мечтой». У вас будет просто рабочий проект, очередной шаг в жизни. Не романтично, ибо без «мечты», но зато работает!

Что же делать? Разве не стыдно не быть романтиком (хоть человеку, хоть компании — рассуждения тут похожи), не иметь какой-то очень далёкой и плохо сформулированной в далёком детстве цели существования?! Ежу-человеку или ежу-компании легче рассказывать о себе, ему не нужно думать: у него стратегический день сурка. Как жить, когда тебя с детства учат, что в плане мечты ты должен устроить себе этот день сурка, но обстоятельства жизни меняются с такой скоростью, что невозможность многолетнего преследования одной цели в резко изменяющихся обстоятельствах становится очевидной? «Если не можешь бежать в направлении цели, не можешь идти, то хотя бы лежи в направлении цели» — это враньё, поэтический язык, манипулирование.

Что делать с этой романтикой, с этой утопией вечной мечты, к которой тебя приучают с детства, но которая очевидно не работает — ибо реализуешь давнюю мечту не ты, и не твоя компания, а те, кто придут в эту мечту сбоку, из совсем других предметных областей? Ничего не делать, просто постоянно стратегировать: вовремя менять мечту. Новые обстоятельства — новая мечта, только и всего.

Интересно, что есть метод ретроспективного придания смысла, суть которого — замаскировать стратегию лисы под стратегию ежа, выдать более-менее случайный успех за тщательно спланированную удачу, результат выполнения какой-то долгосрочной стратегии. Про придание смысла довольно часто говорят в организационном развитии, ибо людям трудно признать, что большинство наблюдаемых событий являются не результатом реализации чьих-то стратегий и выполнения тщательно составленных планов, а результатом эволюции, одновременно реализующихся в условиях жёсткой конкуренции за ресурсы самых разных методов. Какие из них приведут к удаче обычно трудно предположить, но если не игнорировать эту удачу, то можно попробовать «придать смысл» задним числом, ретроспективно. Особенно этим славилась фирма IBM, которая в конце 20 века ставила довольно много разных экспериментов в части продукта, но во всех пресс-релизах по поводу выпуска удачных продуктов она писала, что «данный продукт стал итогом реализации дерзких стратегических планов наших учёных и инженеров», дальше выдавалась какая-то последовательность событий, в которой и впрямь можно было углядеть, что это были логичные шаги. Другое дело, что эти цепочки событий, которые и впрямь случались, не были запланированными, их не было предусмотрено в стратегиях. Поэтому не путайте стратегии, которые вы только что выбрали из многочисленного числа кандидатов и будете реализовывать (гипотезы о том, что метод сработает) и стратегии, полученные как «ретроспективное придание смысла» как попытку выдать какие-то результаты как мудрость стратегов, которые их предусмотрели.

Если вам в жизни что-то удалось, то довольно легко описать этот успех и сказать, что «я с детства об этом мечтал» — тогда все ваши проекты будут выглядеть как тщательная подготовка к успеху, долгий и трудный путь к успеху, результат собранности на реализации мечты. Не путайте «ретроспективное придание смысла» и стратегирование.

Моделирование: икигай по методу Коллинза

• Выполните нахождение икигая по методике Коллинза.

• Выполните нахождение икигая по методике Коллинза, но возьмите ситуацию пятилетней давности (проследите, чтобы в списках не оказалось ничего, что появилось в вашей жизни за последние пять лет)

• Сравните результаты

Задания

Поставьте отметку о выполнении следующих заданий:

1. Опубликован пост, где вы ретроспективно придаёте смысл вашей жизни как реализации какой-то стратегии (хотя вы прекрасно знаете, что никакой стратегии и не было, или она была, но реализовалось все как раз вопреки этой стратегии).

Мечту вполне можно иметь. На мечте просто нельзя застревать.

Если вам стыдно, что вы ещё не нашли смысла жизни, у вас нет долгосрочных планов, вам трудно сформулировать мечту — познакомьтесь с литературой, обсуждающей порочность долгосрочного мечтательного стратегирования. Такой литературы сегодня много, и это счастье. Раньше таких книжек не было, всех поголовно уговаривали выбрать «дело жизни», желательно в раннем детстве, и вот литературы про пользу «мечтаний надолго» (что означает разовое раннее стратегирование, при этом почему-то даже признавалось, что up-front планирования сделать нельзя, но up-front стратегию сделать можно — agile планирование «на лету» ведь следует за agile стратегированием «на лету»). Конечно, у вас может быть и смысл жизни, и мечта, и даже какие-то планы, даже долгосрочные. Другое дело, что это текущий смысл жизни, текущая мечта, текущие планы — это совсем другое дело, вчера они были одни, завтра будут другими. Но если вы считаете, что всё это должно появляться где-то в раннем детстве или хотя бы в студенчестве, а потом не меняться всю жизнь — вы глубоко не правы. Мечту можно иметь, но на мечте нельзя застревать.

Люди страдали, если у них не обнаруживалось цели в жизни, или эту цель в жизни приходилось менять каждые несколько лет. Это сильно противоречит тому, что предлагалось классической литературой, советами родителей и учителей — тех, кто постарше, кто помнит о временах не то что «профессий», но вообще «династий» (когда несколько поколений семьи выбирали одну и ту же занятость). Страдать от отсутствия «одной большой цели в жизни» не нужно, это абсолютно нормально! Концепт «цель жизни» и для людей, и для компаний (только там говорят «цель существования», а не «жизни») — придуманный, он абсолютно искусственный, в нём нет ничего естественного. В стратегировании вы должны вовремя замечать, что цели жизни у вас и цели существования компании неадекватны изменившейся ситуации — и после того, как заметили — вовремя заменить эти цели! Никаких «скреп», «заветов предков/основателей», «детской мечты», «столетней традиции». Жизнь изменилась так, что старые цели не работают — немедленно меняй цели, хоть личные, хоть корпоративные.

Интуиция подсказывает, что в текущей ситуации непрерывных технологических подрывов лучше долгосрочных целей не ставить, ибо это всё равно бесполезно, вы этих целей не достигнете, это будет источник постоянного расстройства. Но художественная литература вроде как требует такие цели иметь. Что делать?

Тут ещё нужно сказать, что само понятие «цель» размыто в своём значении. Например, есть устойчивое сочетание «цели и задачи» — и пытаются изобрести, чем «цели» отличаются от «задач». Или чем «цели» отличаются от «миссии» и «видения». Или чем «цели» отличаются от стратегии (а задачи приписываются тогда к тактике).

Мы считаем, что тут говорим о долгосрочной стратегии как методе работы, которого мы придерживаемся на протяжении какого-то долгого (годы) времени. Наличие стратегии полезно, её можно описать в виде самых разных моделей. Это явное описание стратегии позволяет согласовать предметы интереса многих ролей внутри личности, если речь идёт о личном стратегировании, или внутри организации, если это корпоративное стратегирование.

Поэтому от невнятных «долгосрочных целей» переходим к разговору о стратегии. Нужно часто обновлять (изменять частично, изменять полностью, то есть делать «вираж»/pivot) стратегию — метод, которым мы хотим изменить мир к лучшему, решить какую-то проблему. Стратегирование должно быть непрерывным, не прекращаться. Круто не меднолобо преследовать всю жизнь детскую мечту (личную или корпоративную), но всю жизнь развиваться самому и развивать мир вокруг себя, на многих системных уровнях. Бесконечно развиваться, преследуя самые разные цели развития — это много круче, чем быть романтиком-фанатиком и тем более пытаться сделать из компании романтика-фанатика, то есть слепо преследовать долгосрочную мечту!

А как же с мечтой типа начальной «послать оранжерею на Марс», которую лелеет тот же Элон Маск? Это отнюдь не детская его мечта. Эта мысль у него появилась, когда он был уже миллионером. Более того, сейчас эта мысль подросла: он хочет уже не просто послать оранжерею на Марс, а переселить туда миллион человек, чтобы как-то защитить человечество от космических экзистенциальных рисков.

Эта «мечта» не мешает Элону Маску заниматься самыми разными проектами, которые подворачиваются под руку — и электромобилями, и человекоподобными роботами, и искусственным интеллектом, и социальными сетями, и транспортными туннелями, и солнечными панелями, и ракетостроением (вроде бы это и отвечает мечте), и спутниковой связью. Одно дело «нарисованный пиарщиками образ», другое дело — реальные дела. Тут тоже есть «схемы» (оформление в каком-то приемлемом вовне формализме того, что реально происходит. Например, схемы уменьшения налогообложения). То что реально происходит, и как это подаётся широкой публике могут разительно отличаться. Да, у Маска есть «хотелка» летать на Марс и даже переселить туда часть человечества. Одна из множества «хотелок», но отнюдь не всепоглощающая страсть, не единственная «мечта детства».

Так что не надо стыдиться разнообразия своих проектов, это нормально. Быть меднолобым фанатиком одной идеи — вот это неправильно. Успевайте заметить, что вы застряли на уже неактуальной стратегии, что застряла ваша организация — и срочно меняйте методы работы (включая сигнатуру: какие состояния каких объектов вы хотите изменить вашей работой по стратегии), то есть меняйте стратегию!

Пожалуй, самая известная книжка из литературы по постоянному стратегированию как постановке краткосрочных жизненных и корпоративных целей и избеганию долгосрочных — это «Антихрупкость» Нассима Талеба⁴⁰⁰.

Описанный в книжке идеал — быть «рациональным фланёром⁴⁰¹», который пересматривает свой маршрут на каждом шагу, чтобы сделать его зависимым от полученной новой информации. Это ключевой момент: никогда не стратегировать «на будущее». Методы не надо выбирать такие, которые подробно расписывают многолетние занятия. Не надо также ставить каких-то долгосрочных (на много лет) конкретных достигаемых тяжёлой работой целей, то есть не надо бежать «куда». Наоборот, нужно всегда бежать со всех ног «откуда», в любом направлении (а не в одном «целевом»!) от появляющихся неудовлетворённостей, отталкиваясь от того, что вам уже известно про себя и про мир на текущий момент. Через довольно короткое время после первых же действий по этому бегу «откуда» будет известно о ситуации больше (в том числе и то, что ситуация изменилась — это уже другая ситуация), поэтому надо будет менять стратегию, делать новые ставки на то, что новая стратегия будет успешна.

Это хорошо соответствует теории active/embodied inference, где агент (личность, организация, сообщество, что угодно) избегает неприятного сюрприза (выживает, старается быть стабильным), а не стремится к какой-то особой цели. Это даёт свободу: вы не как зомби идёте к какой-то конкретной цели, но вы выбираете из огромного числа методов, которые позволяют вам наоборот — уходить от каких-то состояний.

Если всё вокруг хорошо, то всё рассуждение по-прежнему применимо, ибо речь идёт о предсказании неудовлетворённости: надо изменить себя (в том числе улучшить модели себя для этого) и мир (в том числе улушить модели мира для этого) так, чтобы предсказание говорило, что всё будет хорошо и в будущем!

Такое стратегирование полностью соответствует тому, что говорит мизесовская праксеология: действовать человека заставляет чувство неудовлетворённости, беспокойства от текущих и возможных в будущем проблем. Жизнь меняется, меняются текущие проблемы и меняются предсказанные возможные в будущем проблемы, а также меняется стратегия как предсказание лучшего способа ухода от этих проблем, предсказание лучшего способа добычи ресурсов для ухода от текущих и будущих проблем. Поэтому стратегия будет меняться по мере изменения состояний себя и состояний мира!

Не нужно быть рабом собственной мечты и уверенности в её незыблемости. Долгосрочная мечта призрачна, она обманет. Не чувствуйте вины от того, что вы и/или ваша компания «поменяли мечту»⁴⁰². Идите за текущим интересом, ибо ваш интерес тоже может меняться. Фланируйте, доверяйте интуиции. Но фланировать нужно рационально, не делать очевидных ошибок.

В книжке Талеб формулирует, что «ставить нужно на всё что угодно», ибо никто не знает, где лежит твоё счастье — будущее принципиально непредсказуемо. Но нужно быть «лохом»⁴⁰³, чтобы ставить на реализацию мечты, которую можно осуществить только через много-много не просто рискованных, но вообще непонятных шагов: когда у вас нет никакой стратегической идеи (идеи о методе создания целевой системы) в части концепции системы, которую вы создаёте, то есть нет идеи о том, существует ли в мире аффорданс (конструктивная часть, которую вы можете использовать для реализации функции, без которой система не заработает). Помним, что легко продать за довольно большие деньги вечный двигатель, скатерть самобранку, суперинтеллект — если будет понятно, из чего можно такое сделать в обозримое время. То есть «хорошая маркетинговая идея, наличие рынка» не означает автоматически успеха в стратегии.

На рисунке 24 в книге Нассим Талеб приводит картинку «штанги» во временном ряду, как главного способа достижения успеха и заработка:

Основная идея в том, что можно крупно выиграть в проекте один раз — и это покроет многочисленные убытки от прошлых проектов. Для этого нужно ограничивать величину убытка, и ввязываться в проекты, где не ограничен выигрыш. А дальше работает статистика: хотя бы один раз из многих проектов должно повезти, если не будете лохом, не наделаете ошибок, и не попадёте на неограниченный убыток. И этот один раз даст выигрыш во всей серии проектов. Проигрышей избежать не удастся: неожиданности всё равно будут, и плохие, и хорошие.

На каждый десяток обычных ожидаемых белых (известных, это не обязательно «хорошие» события, могут быть и обычные ожидаемые плохие события) лебедей обязательно прилетит один чёрный полностью неожиданный (тоже необязательно плохой, но полностью неожиданный — в книге это символ неожиданности, хорошей или плохой, раньше ведь не знали о существовании чёрных лебедей, они водились только в южном полушарии).

Главный вид ошибки: ставки, при которых можно проиграть неограниченно много. Такие ставки — ошибки, их просто не нужно делать. Нужно блюсти асимметричность: если потери будут, то они не должны превышать заранее известного маленького размера, а если выигрыш — то по величине он может быть неограниченно большим. На этой асимметричности малого проигрыша и возможно огромного выигрыша можно получать прибыль чисто статистически, если хоть как-то оценивать вероятности. А средних ставок с «умеренным риском» делать не нужно, это разорительно. Талеб по основной своей специальности как раз был трейдер на рынке ценных бумаг, поэтому он свои примеры и образы главным образом брал оттуда.

Талеб предупреждает: если вы знаете, куда идёте, или считаете, что знаете, куда идут другие (внешне «целеустремлённые», но вы же не знаете, что у них там на самом деле в мыслях!), то это ваше телеологическое (связанное с целеполаганием) заблуждение. Не заблуждайтесь, никакой разумной цели нет ни у вас, ни у других, честно фланируйте — рационально решайте куда идёте на каждом шагу, а не в начале пути, не стройте длинного маршрута заранее. И удача время от времени будет вам улыбаться, случай будет работать на вас.

Проект, в котором вы не знаете какой-то верхнеуровневой концепции системы — очень, очень сомнителен. Если вы оказались в проекте по созданию вычислительной машины во времена Бэббиджа, то вам ещё ждать сотню лет, чтобы появились электронные лампы, технология которых будет отработана в усилительной аппаратуре телефонии, в радиоприёмниках и радиопередатчиках. Если ваш проект полагается на то, что вы как-то сделаете изобретение и у вас появится концепция системы — то самое время считать ваше поведение нерациональным, вам надо немедленно менять проект. Менять ли и стратегию тоже? Да, если вы поняли, что другого сорта проектов по этой стратегии не будет. Дайте себе три дня поизобретать, чтобы вы нашли что-то такое, что «придёт сбоку и позволит сделать проект». Если не изобрели — бросайте, не факт, что изобретёте именно вы и до того момента, как кончатся деньги ваши и других инвесторов.

Не жалейте уже потраченные средства на заведомо убыточные проекты. Неудачи — они запланированы, просто списывайте затраты, и бросайте проект. Не будьте меднолобым достигателем несбыточных целей.

Если вы понимаете, что проект «дохлый» (системное мышление — санитар леса, быстро помогает такие проекты обнаружить) — бросайте его немедленно, даже если вы (человек или компания) долго им занимались! О затратах просто забудьте, не умножайте их. Каждая новая вложенная в этот «дохлый» проект копейка, каждая новая вложенная в такой проект минута, каждое новое вложенное усилие — это чистые потери, они не вернутся! Потратьте ресурсы на поиск нового, более выгодного проекта! Переключайтесь немедленно!

Если лодка тонет, не тоните вместе с ней, тонуть долго и несчастливо — это не доблесть! «Крысы бегут с тонущего корабля» — они ведь правильно делают, если очевидно, что корабль уже не спасти! А кто остаётся на безнадёжно тонущем корабле — герой? Да, герой для рассказов об упёртых неудачниках, в назидание потомкам. Если есть возможность спасти проект — спасайте, но если нет такой возможности — не ждите, что «как-нибудь наладится». Не наладится! Бегите, и не жалейте об уже потраченных силах, времени, деньгах.

Когда тебе весь мир из каждого утюга говорит «напрягись и вот-вот тебе будет счастье!» — не верьте, что вы такой гений, не верьте, что ваша компания такая гениальная. Не верьте, что вы и даже целая большая компания сможете быстро что-то изобрести. Не впадайте в ошибку выжившего⁴⁰⁴: приводимые вам из каждого говорящего утюга примеры показывают только отдельных счастливчиков, избежавших неудачи. Не факт, что вы повторите судьбу этих счастливчиков и станете вторым Биллом Гейтсом или Элоном Маском. Миллионы и миллионы проигравших безвестны, вас поэтому никто не предупредит об огромной вероятности неудачи, а пример ничтожной вероятности удачи подвесят как морковку, повторят сотню-другую раз в день.

Если собака укусила человека — это не новость, новость — это когда человек укусил собаку! Если кто-то (или какая-то большая фирма) потерпел неудачу в своих инвестициях — это не новость, в СМИ это не напишут, в соцсетях не прокомментируют. Новость, если вдруг инвестиции принесли огромный доход, вот это точно попадёт в СМИ, это точно будет обсуждаться в соцсетях! Если вы ввяжетесь в авантюру с неограниченным проигрышем, то с огромной вероятностью пополните ряды безвестных неудачников. Пополнить компанию миллиардеров вы тоже можете, но с вероятностью чуда. Не верьте пропаганде упорства, не верьте пропаганде безусловного выигрыша, связанного с бизнесом. Работает не пропаганда, а статистика.

При этом нужно понимать, что уклониться от принятия бизнес-решений (решений по поводу того, чем же будет заниматься ваша фирма или вы, что поднимет стоимость вашей фирмы или вас лично) нельзя. Любое ваше действие — это ваш бизнес-выбор о том, куда инвестировать собственные (в том числе вашей компании, даже и не собственные) ресурсы: вы выбрали делать именно то, что вы делаете, и тем самым выбрали не делать чего-то другого. Вы не завели собственного дела, но поступили к кому-то на работу: это бизнес-решение. Если речь идёт о вас самих, то вы вложились собой, своим временем, в которое вы могли бы зарабатывать каким-то другим способом. Например, поступив на работу в другое место; или совершая какие-то торговые или даже чисто финансовые операции; или отдыхать и набираться сил для другой работы, которая будет более выгодна — отложить заработок; или учиться для другой работы — тоже отложенный заработок; или путешествовать автостопом и питаться объедками в столовой — это неявный заработок, но он есть; или жить в лесу и питаться как дикарь, что тоже приносит доход, которого едва хватает на жизнь, и он не выражен в деньгах; или ещё делать что-то, и при этом не голодать: люди удивительно изобретательны в выборе того, чем им заняться. К фирмам это относится в полной мере. Если был выбран для обслуживания этот продукт, этот клиент — это означает, что ресурсы (время сотрудников, деньги) были вложены в это, а не что-то другое. фирма не стала сама торговать в розницу, но продаёт свои товары и сервисы какой-то большой фирме, как единственному клиенту. Это то же самое, что «поступить на работу» для личности, мышление тут будет одинаковым.

Уйти от принятия бизнес-решений (решений о том, что делать для того, чтобы поднялась стоимость вашей фирмы или вас лично) нельзя. Даже если вы будете ничего не делать, то это выбор: пробел тоже символ, ничегонеделание — это решение, избегание выбора — это ведь тоже выбор!

Но приведёт ли следование рекомендации Нассима Талеба «рационально фланировать» к успеху? Он ведь попсовый писатель, говорит не столько верно, сколько красиво. Что на эту тему жизненного успеха говорит наука, а не поп-наука?

Наука вместе с Талебом по этой теме говорит, что вы не должны быть лохом (то есть должны быть минимально умны, чтобы не делать явных глупых ошибок), но вот всё остальное — и впрямь дело случая! Вы должны оказаться в правильное время на правильном месте, и быть минимально умны (то есть должны быть умней кошки, хотя и кошек кормят). Люди и компании различаются по их интеллекту и умениям по абсолютной шкале (по сравнению с теми же кошками или слонами или даже кошачьими стаями и стадами слонов) весьма незначительно, а богатство/капиталы их различаются в миллионы раз. Главный виновник этих различий не уровень работоспособности, прозорливость, мудрость и т.д., главный виновник тут случай. Этот «успех» был выражен количественно и проверен в компьютерных экспериментах в 2018 году, модель хорошо соответствует реальности⁴⁰⁵. Должно ли это нас смущать? Нет, не должно. Богатые тоже плачут, а бедные тоже смеются. Уровень удовлетворённости жизнью и богатство не так уж сильно связаны.

Не шагай в туман, не надейся на «авось»!

Самая подробная книжка на тему «бесцельного» фланирования против достигательства далёких заранее намеченных целей — Kennet Stanley, Joel Lehman, «Why Greatness Cannot Be Planned: The Myth of the Objective»⁴⁰⁶.

Однократное раннее стратегирование (целеполагание) типа «мечта» объявляется в этой книге цивилизационным пороком. Мечта — это стратегия, рассчитанная на долгий срок её реализации, с отсутствием на момент её создания понимания, какие для предложенной сигнатуры метода существуют понятные варианты разложения метода, ибо эволюция ещё не предоставила набор технологий для разложения стратегии на понятные методы, все экспоненты подрыва ещё не отработали (то есть для концепции использования нет понимания концепции системы: какие физические объекты нужно взять, чтобы из их взаимодействия получить требуемую в использовании функцию). Если вместо сигнатуры метода как стратегии говорить про «цель», то можно сказать, что «цель есть, средства достижения ещё неизвестны или заведомо не могут существовать в обозримый период».

Мечта/утопия получить микроволновку в 19 веке, смартфон во времена изобретения радио, возвращаемую на землю ракету в двадцатом веке. Утопия — это всегда красиво, романтично, но гибельно.

Правильная жизнь по версии книжки Stanley и Lehman — это не страстное преследование мечты, не ввязывание в утопический проект длиною в жизнь, а поиск сокровищ (treasure hunt), который может продолжаться вечно. Реализация мечты, решение проблемы — однократно, оно имеет конец во времени и амбициях. Развитие может быть вечным по времени и бесконечным по амбициям!

Книжка вводит понятие шагов бесконечного развития как череды проектов, имеющих разные целевые системы (а не как череды проектов по достижению одной общей цели, «взбираясь на верхушки всё более высоких деревьев, в какой-то момент достанем до Луны»). Каждый проект — это ступеньки/stepping stone. Эти stepping stones — камушки, по которым переходят ручейки или лужи. На русском устойчивого эквивалента нет, но мы будем называть их «ступеньки» (то, на что наступают в каждом очередном шаге) или даже ещё проще — «камушки».

В стратегировании ты видишь варианты стратегий ближайших к тебе проектов, ближайших камушков-ступенек, на которые понятно как перескочить из твоего текущего состояния. И на этой новой ступеньке может оказаться сокровище, выигрыш — удачный бизнес: обнаружится понятная целевая система, которую понятно как можно успеть сделать и удачно продать в обозримое время. Или сокровище там может не оказаться, туман будущего не позволяет это разглядеть наверняка — пошли в проект, а он «не выстрелил». Ну что же, убытки списываем и забываем о них, будем прыгать по камешкам-проектам дальше.

Остальные ступеньки подальше во времени (или даже рядом, но о которых мало что понятно) — в тумане будущего, их вообще не видно, где они, эти стратегии пока даже нельзя сформулировать, эти цели пока даже нельзя поставить, в такие проекты непонятно даже как входить. Метафора подходит и для описания занятий бесконечным развитием какой-то одной системы, где каждая новая фича, каждый вариант архитектуры — это вначале гипотеза, которая может и не оправдаться, и проект в целом выглядит как перескакивание с камушка на камушек, где в любой момент может не хватить денежного потока от клиентов скакать дальше, так и для ситуации с виражами/pivot, когда каждый камешек — это проект по созданию и развитию совсем нового вида целевой системы, совсем новая ситуация.

В книге говорится, что ввязываться в проект, то есть вкладывать ресурсы/инвестировать, можно только для видной тебе ступеньки с понятной стратегией, а не той, которая в тумане. Планировать (говорить, какие ресурсы нужны для каких работ по каким методам) шаг смены проекта можно только тогда, когда видишь, куда шагать, вероятность выигрыша велика.

Когда сделаешь шаг — то дальше планируй делать следующий шаг на ту ступеньку, которая открылась с только что достигнутого. Многоходовые стратегии и многошаговые планы, составленные up-front — не работают, работает только пошаговое «на лету» и стратегирование, и планирование.

Если нет идеи, как реализовать стратегию («придумал скатерть-самобранку, продаваться будет на-ура по цене не выше тысячи долларов за штуку, осталось придумать, как она должна быть устроена, на это у нас целая команда лучших инженеров»), не инвестируй в неё, не ввязывайся.

Не шагай в туман, не надейся на «авось»! На каждой ступеньке сокровище или высоковероятно есть, или всё-таки после того, как мы вна эту ступеньку-проект придём, его не обнаружится. Где-то там, через много-много ступенек может быть большое сокровище, другой берег, ты на него придёшь раньше конкурентов и вытопчешь себе и всем твоим сотрудникам огромную полянку. А потом? А потом полянка окажется вытоптана, и ты опять куда-то будешь скакать по камням, заниматься догадками об умных мутациях каких-то систем — дадут ли эти мутации бизнес, или нет (т.е. выгодно ли будет заниматься этими новыми системами).

Вот так это примерно выглядит, это фрагмент картины Rob Gonsalves «Stepping Stones»⁴⁰⁷. Сама картина примерно это и показывает: камушки-ступеньки, прикрытые туманом будущего. Kennet Stanley и Joel Lehman дают именно такую картинку, в которой другого берега вообще не видно, и непонятно поэтому, на какой камушек прыгать, чтобы добраться туда быстрее. Задним числом придут историки и биографы, туман будущего для них отсутствует, и всё это путешествие к успеху для немногих прорвавшихся будет описано как очевидный «прорыв к успеху», как будто было понятно куда и как прыгать, и нужно было только упорство в прыжках, это «ретроспективное придание смысла»:

Правда же в том, что полная картина без тумана доступна только потом, когда развеется туман будущего. А прыгать приходится тогда, когда не очень понятно, какой камушек ведёт к другому берегу кратчайшим путём.

Совет у авторов книги тут один: прыгайте в тот проект, которым ещё никто не занимался (новые типы систем, новые методы создания), новизна важна. Как узнать новизну? Мнения экспертов (например, какого-нибудь инвестиционного комитета) разделятся:

• половина будут кричать, что там смерть,

• половина признают, что там успешный успех.

Это означает, что эксперты ничего понять не могут, вы на новой полянке. У вас есть шанс крупного выигрыша. И если вы не будете делать явных ошибок, что-нибудь может выгореть. Или не выгореть. При этом наличие комитета (коллегиальность решения) не позволит вам прыгнуть: если вероятность того, что 10 членов комитета каждый проголосует «за» рисковый проект будет 50%, то вероятность того, что инвестиция будет получена, будет ничтожна (вероятности-то перемножаются!). В ситуациях, когда никто ничего не понимает, коллективное принятие решений голосованием не будет работать, вероятности ведь перемножаются. Комитеты не позволят рискнуть!

А если эксперты и друзья кричат хором, что проект неудачный? Так и есть, вы попали в хорошо известную им область. Будет неудача, не ввязывайтесь. А если эксперты и друзья кричат хором, что это гениальная идея, советуют немедленно идти в этот проект? Это опасно, потому как область знакомая, и если там и впрямь так хорошо, то вы встретите жесточайшую конкуренцию, и вас быстро вышибут более богатые, умные и шустрые (ибо их эксперты и друзья тоже им советуют ввязаться в этот проект). Так что новизна — ваш шанс (но не более чем шанс!) и потенциальная защита. В случае успеха, пока богатые и шустрые развернутся и начнут с вами конкурировать, вы и/или ваша компания успеете что-то сделать, что-то заработать в этом проекте и тоже станете богатыми в достаточной мере, чтобы не проигрывать другим богатым из-за отсутствия ресурсов. Скорость и новизна важны.

Из мечтателя в реализации одной далёкой идеи с непонятным приходом сбоку какого-то инженерного решения по концепции системы (изобретения нельзя планировать, а если и планировать, то изобретение может оказаться не вашим, а ваших конкурентов — изобретения главным образом «приходят сбоку», исключения редки) нужно стать коллекционером проектов (stepping stone collector) — собирать прохождение ступенек, на которых лежат сокровища/ресурсы/бизнес, и с которых что-то видно дальше (умные мутации, которые могут дать успех бизнесу). Коллекционирование тут как метафора выбрано потому, что оно никогда не заканчивается, это не цель, это условие игры, архистратегия.

Нахождение сокровищ в каждом даже вроде понятном проекте не гарантируется, но шанс всегда есть. Выбирайте проекты на границе тумана — с понятными стратегиями, а не с непонятными, то есть выбирайте проекты, в которых вы знаете, как их реализовать — у вас есть гипотеза о том, какую конструкцию нужно сделать, чтобы получить требуемую функцию, какими методами работать, чтобы это было выгодно.

Скажем, если у вас есть идея сделать скатерть-самобранку, это отличная «мечта»! Не занимайтесь ей, если у вас нет гипотезы, какая конструкция будет у этой скатерти-самобранки и каким методом вы её получите («нанять лучших инженеров — этот метод не сработает). Но если есть идея по поводу конструкции системы и того, как вы будете работать — смело занимайтесь!

Бывает наоборот: у вас понятная идея, как сделать супер-пупер-генератор-чанста! Непонятно только, будет ли он хорошо продаваться по той цене, которая даст выгоду при его продажах. Это тоже «мечта», не занимайтесь им, пока не будет понятно, кому и как пригодится эта конструкция: будут ли люди готовы заплатить за её функции больше, чем вы потратите на создание конструкции этого генератора-чанста. Помним, что до 2007 года iPhone был невозможным: он был бы слишком дорогим, чтобы проект имел успех. В 2007 году туман будущего рассеялся, как сделать работающий смартфон за вменяемые деньги стало абсолютно понятно (точнее, это стало понятно чуть раньше: разработка iPhone, конечно, началась раньше 2007 года — но не сильно раньше).

Если вы наметите какую-то точку в тумане, где проект не имеет внятной стратегии и пойдёте туда, то вся затея гарантированно провалится, цели в тумане предают, они призрачно выгодны — но в реальности там с высокой степенью вероятности пустота. Вас туда могут заманивать тем, что вы и должны сделать из пустоты что-то стоящее — идите смело, если у вас на эту тему есть идея. Но если вы хотите всё время чувствовать себя обманутыми, ставьте (или принимайте от сладкоречивых других людей) стратегии, которые вам сразу не видно, как реализовать — и дальше упорствуйте, как вас и просят в классической литературе, как вас и учат. Поломанная жизнь гарантирована.

В книжке «Why Greatness Cannot Be Planned: The Myth of the Objective» чётко говорится: живите не «великим достижением», но вечным «поиском». Всю жизнь вы будете развиваться сами, выполнять самые разные проекты, создавать и развивать целевые и создающие системы одна сложней другой — техно-эволюция бесконечна.

Но вы сделали шаг, занялись новым проектом. Граница тумана отодвинулась. Что не было видно при вчерашнем стратегировании, стало видно сегодня — и нужно просто это учесть. И двинуться вперёд с обновлённой стратегией.

Важна не сама текущая стратегия, важно стратегирование как постоянный пересмотр текущей стратегии, чтобы учитывать постоянно меняющийся мир и постоянно меняющегося себя. Стратегия не подразумевает клятвы её придерживаться без изменений много лет или даже месяцев, это рабочий метод. Какое бы описание стратегии вы ни сделали, правильно считать его черновиком. Если что-то по-крупному пошло не так, меняем стратегию, даже не пытаемся продолжать действовать по-прежнему! Стратегия ничто, стратегирование — всё. Более того, многоуровневая (помним о многоуровневом разложении метода!) стратегия ничто, многоуровневое стратегирование — всё!

В конкуренции побеждает самый быстроменяющийся

В конкуренции побеждает не самый дешёвый, самый лучший и т.д. Побеждает самый быстроменяющийся: нужно выдержать много раундов изменений и в продукте или сервисе, и даже изменений вида продукта и сервиса. Выбор ступеньки — шаг на неё, выбор следующей ступеньки — шаг на неё, и чем быстрее, тем лучше, чем больше ступенек попробуете, тем больше вероятность, что сработает «штанга» Талеба.

Много-много раундов, которые не слишком удачны, и которые хорошо бы проходить как можно быстрее. И в какой-то момент следующая ступенька оказывается фантастически удачной, а конкурентам до неё быстро не добраться: вы успели измениться, успели заняться новым делом быстрее, чем они. Побеждает скорость, это универсальное конкурентное преимущество. Вы можете выйти в гонку вторым (идея может быть вами подсмотрена — куда прыгать в тумане узнаете по тому, куда прыгают соседи), но если вы двигаетесь быстро, то победите, станете в этом типе проектов первым.

Но и тут задержаться не придётся: нужно бежать со всех ног, чтобы только-только остаться на месте. Стратегировать надо не раз в год, даже не раз в полгода, стратегировать надо постоянно.

Вираж (коренное изменение стратегии, замена сигнатуры метода — полная смена продукта или сервиса) — это просто часть стратегирования как постоянной деятельности. «Целеустремлённость» как приверженность стремительно устаревающей стратегии — это синоним меднолобости, путь к провалу. А поскольку методы имеют многоуровневое разложение, то стратегирование может быть многоуровневым, виражи могут быть на каких-то достаточно глубоких уровнях разложения инженерного процесса большого проекта, а также многоуровневой может быть и «целеустремлённость». Имейте решимость делать вираж на любом из уровней, включая самый высокий: стратегию (метод работы) проекта в целом.

Фокус тут в том, что вы не знаете, какой сорт успеха вас может ожидать в новом проекте. Цели «добыть то-то и то-то», «победить вон того босса» у вас нет. Речь тут идёт об участии в техно-эволюции (книжка написана исследователями эволюции, занимающимися машинным интеллектом), а у эволюции содержательной цели нет, если не считать реализацию физического принципа минимума свободной энергии путём попыток найти всё более и более усложняющиеся конструкции систем самых разных системных уровней, появляющиеся в ходе этой вселенской (в буквальном смысле слова) оптимизации. Каждое техническое (по целевой системе) и бизнес (по системе создания) решение будет квазиоптимальным, у конкурентов будут абсолютно другие решения, но тоже не слишком оптимальные — близкие к вашим.

Время от времени будут происходить большие эволюционные переходы (major evolutionary transitions), когда вы или конкуренты будете находить решения, приводящие к уменьшению конфликтов между системами разных системных уровней, неустроенности/frustrations будут меньше. Эволюция будет находить всё более и более сложные и универсальные (хорошо адаптирующиеся к самым разным ситуациям) формы систем, отражающие всё больше и больше аспектов мира и позволяющие системам и создающим их бизнесам выживать во всё большем и большем разнообразии ситуаций. Это будет происходить и в том числе за счёт конвергенции (множество разных технологий, задействованных в одной системе), примерно так же, как конвергенция огромного числа химических реакций даёт в итоге одноклеточную, а затем и многоклеточную жизнь.

Если у вас есть мечта, и понятно, как её достичь — смело выполняйте проект по её достижению. Если непонятно, меняйте мечту. Мечта не обязана быть на всю жизнь. Меняйте мечту хоть каждый день, меняйте концепцию романтической утопии на концепцию бесконечного развития. Мечту вполне можно иметь. На мечте просто нельзя застревать.

Идея о том, что можно перед выполнением проекта сначала поставить цель, затем составить план по её достижению, потом получить деньги, затем выполнить проект строго по плану и достичь тем самым успеха в виде достигнутой цели — вредная, утопичность её уже давно очевидна, мы разбирали её во втором и третьем разделах нашего руководства. В инженерии и менеджменте против такой идеи выступило движение agile, где сама постановка цели как концепции системы выглядела как непрерывно уточняющаяся, равно как признавалось, что нельзя точно спланировать достижение этой непрерывно меняющейся цели (нельзя точно и однозначно навсегда указать концепцию системы, определить архитектурные решения, ибо концепция использования меняется по ходу проекта). Но в agile-движении поначалу тоже была заложена просто идея «уточнения постановки цели по ходу проекта», но не идея «непрерывного всего», включая смену целей проекта. Поначалу agile-движение выглядело как итеративный способ достичь конца проекта (однократного прохождения жизненного цикла), но не как вечное удержание системы и развивающего её бизнеса на плаву инкрементальными изменениями, которые сначала задумываются как гипотезы по улучшению продукта, а затем требуют подтверждения жизнью.

«Lean Startup»⁴⁰⁸ (2011), написанная Eric Ries книжка по современному бизнесу, которую изучают практически во всех бизнес-школах, рассказывает ту же идею: непрерывно экспериментируй с продуктом, фланируй, а если всё-таки «не взлетает», то делай крутой вираж/pivot, т.е. пробуй совсем другой продукт. И продолжай эксперименты, пока к тебе не повернётся лицом удача — не упирайся, не долбись в одну точку, не ставь все средства на заведомо неверную идею, получай знания на каждом шаге, в каждом эксперименте. Учись, учись, учись — ищи, ищи, ищи. Бесконечно в цикле новых возможностей (цикл! Нет надежды на одну попытку!) развивай свой продукт или сервис, бесконечно в цикле продуктов развивай свою компанию.

«Стартапом» в этой книжке называют какое угодно оргзвено, ибо в любой момент оказывается, что оргзвено/организация начинает новое дело — в непрерывном стратегировании ты всё время в ситуации, когда только-только выкинул старую стратегию, и начинаешь новое дело (а старые дела приносишь в жертву, они уже не соответствуют новой стратегии). Это у Эрика Риса и группа из пяти-шести человек, которая только-только образовала новое предприятие, и команда нового проекта на пару сотен человек, который стартует в большом предприятии, и даже большой холдинг, который меняет профиль своей деятельности. Основной посыл книги: нет надежды на одну попытку, одну версию выигрышной стратегии и её плановую реализацию с успехом в конце проекта.

В книге описано, что крутятся два цикла: совершенствования продукта (новые и новые фичи, эволюция продукта) и резкой смены продукта (вираж/pivot, организация при этом претерпевает существенные изменения, научается делать новый продукт — ибо старый продукт оказался бесперспективным).

А вот «видение» (у Эрика Риса это примерное понимание, чем занимается предприятие — блины печёт или ракеты в космос запускает, близко к пониманию стратегии как чисто сигнатуры метода) остаётся более-менее стабильным. Сейчас есть множество примеров, показывающих, что и этот «общий тип продукта» тоже существенно меняется. Фирма Tesla вроде как занимается электромобилями, и была создана для этого, но по факту выпускает и аккумуляторы для энергосети PowerWall⁴⁰⁹, и довольно активно готовится продавать человекоподобного робота Optimus⁴¹⁰.

Принципы стратегирования, которые предлагает Eric Ries в своей книге:

• Тестируй твои предположения (имей численные оценки)

• Фокусируйся на том, чего хочет клиент

• Уменьшай время цикла (но их там два!)

• Меньше документируй, больше делай (прямая отсылка к agile-манифесту, легко её понять неправильно как «вообще не документируй», но моделирование оказывается более чем важным)

• Правильные действия в правильные моменты (это так Рис говорит о lean/элегантности ведения работ организацией/стартапом как недопустимости потерь на ненужную работу/waste/muda/rework + «удавливание» многозадачности, об этом уже говорилось в руководстве по рациональной работе и будет ещё говориться в руководстве по системному менеджменту в разделе, рассказывающем об операционном менеджменте).

После того, как вся эта «целеустремлённость, несдавательность» и «благородная на всю жизнь мечтательность» в вашей голове будет проблематизирована, вы не только избавитесь от предрассудков и чувства собственной неполноценности, но и станете выделять паттерны бесконечного развития в разных других школах мысли.

Так, «недеяние» (у-вэй⁴¹¹) из восточных философий — оно оказывается про то же, про непостановку длинных целей. Вроде как «неделание», оно оказывается на поверку жутко деятельным, оно очень активно следует цепочкой дел за сиюминутной (привязанной к текущему знанию) интуицией о том, к чему нужно стремиться вот прямо сейчас. Прямо сейчас в каждый момент времени, но не всю жизнь. Нет долгосрочных установок на достижение какой-то мечты, в этом и есть плохо понимаемый западным умом секрет «деятельного недеяния».

Но «западный научный ум» никак нельзя недооценивать. По мере активно ведущихся компьютерных экспериментов с эволюцией и обучением, растёт понимание ситуации переоценки долгосрочного планирования.

Ещё одна книжка, в которой техно-эволюции в постоянном развитии методов посвящён довольно большой кусок, написана Pedro Domingos, исследователем машинного интеллекта — «The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World» (2015)⁴¹².

Эволюция преподносится там не как поиск/search в возможном «пространстве решений», а как вариант обучения/learn, что ближе к постановке оптимизационной задачи. Можно считать, что ты учишься сложности мира, то есть предсказанию поступающих от мира сюрпризов — в том числе учишься без учителя (unsupervised learning), или выступаешь учителем самому себе (self-supervised learning), давая самому себе задания и пытаясь их выполнять. Про это же самое можно рассказывать и как о «поиске сокровищ».

Бесконечное развитие можно обсуждать и как бесконечный поиск, и как бесконечное обучение (людей и организаций, Peter Senge говорит об «обучающейся организации», об этом будет позже): поиск бизнес-сокровищ в длинной череде проектов подразумевает обучение справляться с заранее неизвестными проблемами этих проектов. В машинном интеллекте парадигма бесконечного развития, бесконечного (life-long learning) обучения решать всё новые и новые проблемы вместо «решения одной хорошо поставленной проблемы» стремительно набирает вес.

Проектов создания и развития каких-то систем (и целевых, и систем создания, и даже системы «я, любимый») хватит для всех, особенно если учитывать критерий новизны при выборе проекта. Исследуйте новое на самой границе известного, это на долгих периодах окупается! И каждый шаг развития, каждый удачный бизнес (то есть создание и развитие какой-то целевой системы, предоставление сервисов для этого) позволит вам увидеть что-то ещё, шагнуть дальше.

Если не ходить проторенными туристическими тропами, на которых уже давно все сокровища расхватаны, то вам этих сокровищ на жизнь хватит. Главное — не загадывать заранее, какими должны быть эти новые камушки, новые проекты, какие именно сокровища там должны быть. Главное — не загадывать заранее мечту-утопию. В мечте будет встреча с изумрудом, а встретится вам алмаз. Не проходите мимо алмаза!

В австрийской школе экономики показывают, почему не может работать госплан⁴¹³ — невозможно рационально вычислить потребности большого числа людей, да ещё и на достаточно длительном интервале времени в будущем. Сколько каких продуктов производить, и по какой цене, вычислить рационально не удастся. Будущее покрыто туманом, и мы ничего не можем сказать о будущих продуктах, поэтому не можем знать, сколько каких деталей нужно произвести для того, чтобы собрать эти будущие продукты. Мы не знаем, сколько морковных пирогов захотят съесть потребители в будущем году, поэтому не знаем, сколько моркови надо выращивать сейчас, чтобы учесть этот будущий спрос.

Рыночная экономика — это процесс техно-эволюции, он подразумевает бесконечное создание и развитие всё новых и новых продуктов, появление всё новых и новых сервисов. Какие-то из них будут быстро отмирать, другие жить долгие и долгие годы, всё как в биологической эволюции, только быстрее.

Нет никакой «божественной миссии», «смысла жизни», есть вот эта техно-эволюция, которая детерминистична (то есть не случайна! Все события имеют физические причины!), но принципиально непредсказуема в силу квантовой природы физического мира⁴¹⁴.

Смело планируйте шаги на границу тумана будущего, ставьте абсолютно приземлённую цель — на один шаг развития, не на всю вашу жизнь, не на весь срок существования организации. Используйте интуицию — машинное обучение даёт абсолютно рациональные ей объяснения (и даже моделирует в глубоких нейронных сетях, человек и коллективы людей — это неплохие квантовоподобные вычислители). Маршрут на несколько шагов неизвестно куда в туман будущего (то есть когда непонятна концепция системы, нет идеи, как можно реализовать привлекательную концепцию использования) заведомо не получится ни реализовать, ни реалистично планировать: будущее непредсказуемо ни для человека, ни для компьютера, ни для большой организации из людей, компьютеров и самого разного другого оборудования.

Установка на достигательство во что бы то ни стало, установка на и мечтательность входит в мозг с младых ногтей, и трудно рационально её преодолевать. Но тренд налицо: вопрос ненужного упорства в достижении целей поднят, активно обсуждается, меднолобым фанатам с их «главное — в себя поверить» и «главное — не сдаваться, несмотря ни на что» начинают выставляться рациональные аргументы. В бизнес-школах уже рутинно учат быстро пробовать и отбрасывать неудачные корпоративные стратегии, то же самое надо бы учиться делать и с личными стратегиями.

Моделирование: варианты мечты

Мечты нужно регулярно обновлять, чтобы оставаться современным. Вспомните более трёх последних вариантов того, что могли бы назвать своей мечтой (или честно напишите, что «мечты нет»):

Бесконечное развитие (open-endedness)

Бесконечное развитие (open-endedness) — это идея, которая позволяет в разы компактней и точнее (т.е. с использованием формальных математических моделей) говорить про сложные вопросы «прогресса», «развития», «целеполагания», «эволюции», «вечного обучения», «постоянной инновации» и т.д. Идея бесконечного развития помогает отбросить бессмысленные споры по вопросам типа «труба ржавеет: можно ли сказать, что она развивается? Что будет прогрессом для трубы?».

Под словами «бесконечное развитие» сегодня скрывается более общий концепт, чем даже дарвиновская биологическая эволюция или техно-эволюция, которые будут тут только частными случаями. Речь идёт об алгоритмах, исполнение которых порождает всё более и более сложные объекты. Это алгоритмы вечно непрекращающегося творчества. Конечно, речь идёт не только об алгоритмах вычислений, но и об алгоритмах физических трансформаций, которые будут использованы универсальными создателями (в том числе для создания каких-то других универсальных создателей).

О чём угодно «лучшем» можно говорить как о «лучшем известном на сегодня», state-of-the-art (SoTA). Завтра лучшее будет другим, SoTA всегда имеет дату. Лучшая теория гравитации в 1600 году не включала силы гравитации, в 1800 году гравитация объяснялась как сила притяжения массивных тел, в 2000 году лучшая теория гравитации (теория относительности) говорит об искривлениях пространства-времени, и гравитация не является силой! SoTA в науке, инженерии и много чём другом меняется со временем, и это будет бесконечно.

Open-endedness переводится обычно как «открытость» или в крайнем случае «незавершённость», и весь аромат английского слова немедленно теряется. Поскольку это применяется к алгоритмам, которые по идее бесконечно (open-ended) научаются делать что-то новое, развиваются, то это мы будем переводить как бесконечное развитие. Это «что-то новое» в подобных алгоритмах и называется stepping stone/ступенька, но декларируется, что алгоритм должен быть такой, чтобы порождать новое бесконечно. Этим новым может быть биологический вид в эволюции, вид продукта или сервиса в техно-эволюции, или даже отдельная «фича» в продукте, вид мастерства в эволюции деятельности.

И как растёт видовое разнообразие и сложность организмов в биологической эволюции (напомним физическое обоснование для роста сложности, работу «Physical foundations of biological complexity»⁴¹⁵), растёт разнообразие и сложность продуктов и сервисов в технологической эволюции, растёт разнообразие и сложность их функций (задействуемых методов работы) и тем самым разнообразность и сложность мастерства в этих деятельностях. В бизнесе это идея «непрерывного всего» (continuous everything — непрерывная разработка, непрерывное тестирование, непрерывное развёртывание у клиента, непрерывное введение в эксплуатацию).

Люди на Земле владеют всё более и более разными видами мастерства (углубление разделения труда), и эти виды мастерства всё более сложно освоить, для надлежащего уровня какого-то сложного метода с нетривиальным разложением на составляющие и большой вариативностью требуется 4-10 тыс. часов прохождения ступенек в мастерстве от «полный новичок» через «иногда получается» до «настоящий мастер». Компании для выпуска хорошего продукта нужно обучить самым разным видам мастерства иногда одного человека, а иногда и десятки тысяч людей. Развитие целевых систем по факту означает и развитие создающих систем, которые познают/learn новые методы работы по созданию новых и новых версий развиваемых систем и приобретают мастерство в этих новых методах работы. Бесконечность развития целевых систем в ходе бизнес-проектов означает в том числе и бесконечность развития бизнеса, бесконечность прибыльности.

Базовый текст декабря 2017 года «Open-endedness: The last grand challenge you’ve never heard of»⁴¹⁶ написан в соавторстве с Lisa Soros теми же Kenneth O.Stanley и Joel Lehman, которые в 2015 году написали книжку про важность новизны, «Why Greatness Cannot Be Planned: The Myth of the Objective».

В соответствии с подходом бесконечного развития, нужно не просто решать проблемы — ибо сложность и элегантность/изящество решения при этом ограничены сложностью проблемы. Для того, чтобы бесконечно поднимать мастерство решения проблем, нужно не просто уметь решать проблемы, но и уметь порождать более сложные проблемы. Мало находить методы решения сложных проблем, надо находить методы порождения более сложных проблем!

Всё более и более сложные проблемы, которые агенты решают в ходе бесконечного своего развития, должны быть не любые, а находящиеся в зоне «ближнего развития» — ни слишком трудные для решения, ни слишком лёгкие (тут в английском используется ещё одно плохо переводящееся слово: goldilocks, означающее в том числе «не горячее, и не холодное, а в самый раз»). Бесконечное развитие требует ступенек-проектов, ни слишком близких и очевидных, ни слишком далёких в тумане. Скажем, основная идея концепции системы у вас есть, и моделирование показывает, что эта идея могла бы быть воплощена, но пока непонятно, кто бы мог её реализовать достаточно дёшево — и можно попробовать решить эту проблему, найти создателей.

В январе 2019 года Stanley (он сейчас возглавляет лабораторию искусственного интеллекта в OpenAI) и Lehman сделали один из вариантов алгоритма бесконечного развития, алгоритм POET⁴¹⁷. В марте 2020 года этот алгоритм был усилен, получен алгоритм Enhanced POET⁴¹⁸. Алгоритм демонстрирует основные идеи бесконечного развития: порождает своей стратегирующей частью всё более и более сложные рельефы местности (даёт параметры генератору рельефов: «ставит цель»), а затем его решающая часть-робот решает эти проблемы, то есть учится проходить заданные частью целеполагания рельефы. Выработка всё новых и новых вариантов универсальной стратегии (в английском — policy) как метода преодоления самых разных препятствий и есть цель работы. Что надо делать, чтобы метод улучшался бесконечно?

Оказалось, что постепенно наученные через «проблемы в зоне ближнего развития» агенты-роботы могут проходить в конечном итоге самые сложные среды, а попытки просто «решить проблему» без этих промежуточных научений, просто «научиться с нуля», без stepping stones/ступенек — проваливаются. Оказывается, без эволюции, без промежуточных ступенек агенты не могут научиться чему-то сложному! Обучение какой-то деятельности должно быть многоступенчатым, развитие должно проходить через ступеньки, находящиеся на границе тумана — ни слишком трудные (тогда научение невозможно), ни слишком лёгкие (тогда не будет накоплен опыт).

Скажем, в Tesla была проблема получить корпус автомобиля за один проход пресса. Это на момент формулирования проблемы как приоритетной для решения считалось невозможным, были посланы коммерческие предложения 16 фирмам, которые делали достаточно большие и сложные прессы, чтобы реализовать идею. 15 фирм отказались, одна взялась попробовать. И всё получилось, после чего к этой фирме в очередь выстроились все остальные автомобильные концерны. Почему? До этого корпуса собирались из примерно 40 деталей. А тут ничего не надо собирать — хлоп, и готово. Это очень дёшево, конкуренты не могут себе позволить не делать так же. Но у одной из 16 фирм уже были идеи, как такой пресс сделать, было понимание технической возможности. Это и есть «проблемы из зоны ближнего развития» этой фирмы. Но это были проблемы, недоступные для решения другими фирмами, поэтому «взять и решить» эту проблему не удавалось.

Примерно такая же история была с повторно используемыми ракетами, впервые это удалось сделать фирме SpaceX, но сначала SpaceX научилась просто надёжно запускать одноразовые ракеты. Вряд ли SpaceX удалось бы разработать повторно используемые ракеты «с нуля», без промежуточной ступеньки надёжного запуска одноразовых ракет.

Для алгоритма бесконечного развития (наша вселенная реализует именно такой алгоритм, и рыночная экономика тоже реализует такой алгоритм в техно-эволюции) нужно достаточное время, и мы получим удивительные результаты. Эволюция на Земле получила удивительный результат, ибо она как раз реализует такой алгоритм: условия существования Земли предъявляют всё более и более разнообразные и сложные проблемы развивающимся на ней животным и растительным видам, а эти виды достигают удивительного мастерства и универсальности в решении этих проблем. Интересные моменты тут — это развитие линии быстрого обучения, перехода от биологической эволюции к техно-эволюции: сначала получение биологического интеллекта дарвиновской эволюцией, затем интеллекта человека как вершины этой эволюции, затем развитие письменности как памяти для описаний методов и развитие интеллекта цивилизации в целом в ходе техно-эволюции, а сейчас и получение машинного интеллекта.

Человечество ставит и ставит себе всё более и более сложные проблемы, и научается эти проблемы решать. Эволюция и техно-эволюция описываются не столько как «появление новых и новых видов», сколько как «решение новых и новых проблем».

Этот алгоритм реализуется не только всей Землёй вместе со всей её биосферой (дарвиновская эволюция), не только всей цивилизацией со всеми её людьми и их компьютерами (техно-эволюция), но даже в одном мозге (это тоже своего рода эволюция). Автор когда-то задавал вопрос проф. John Grinder (одному из основоположников нейролингвистического программирования), считает ли он перспективными «остановку внутреннего диалога» и прочие средства обеспечения «единства сознания», «недуальности». John Grinder отвечал, что не считает: для развития всегда должно быть некоторое противоборство: порождение новых гипотез и их критика, а хоть и в одном мозге. Единство — это путь к стагнации, а не к развитию/эволюции/прогрессу, как это ни назови. Поэтому даже в одном и том же мозге постановщик проблем должен всё время предлагать проблемы к решению, а решатель проблем должен выдвигать гипотезы, чтобы научиться их преодолевать — и так развиваться до бесконечности. Никакой остановки, никакой стагнации, никакого успокоения при достижении «конечной цели». Каждая новая проблема для решения берётся не «любая», а выбирается или даже сочиняется/разрабатывается так, чтобы каждая новая ступень мастерства решения проблем была сложней предыдущей, цепочка этих ступеней никогда не заканчивается, это и есть бесконечное развитие. В технологиях это и есть «непрерывное всё».

В науке всё то же самое: наука ищет всё более и более точные объяснения того, как устроен мир и это никогда не закончится. SoTA в научных объяснениях постоянно меняется. И эти изменения будут бесконечны. Люди не знали о существовании микробов и вирусов, и поэтому смертность от инфекционных заболеваний (родильная горячка, например, как первое, с чем сталкивались буквально при рождении) была запредельно высока. Затем появились объяснения, которые рассказали о микробах и вирусах и их связи с заболеваниями, на основе этих объяснений были выработаны простые, но контринтуитивные предложения стратегий/методов борьбы с болезнями.

Родильную горячку победило мытьё рук! Этот метод «мойте руки, и не будет родильной горячки» был совсем, совсем неочевиден, пока не было объяснения причин: не рассматривались микробы как причина болезни. А теперь производством моющих средств (и отдельно — антисептиков) занято огромное количество людей, это огромный бизнес.

Но можно ли сказать, что всё уже известно про инфекционные болезни? Конечно, нет! Пример пандемии показывает, что неизвестного ещё много, в том числе неизвестного в том, какими методами избегать известных болезней. Или даже по-другому: неизвестно, что из известного действительно известно и какие методы действительно работают! Может быть, SoTA в знаниях об эпидемиях уже есть, но конкурирующие теории ещё не опровергнуты (или об их опровержении ещё не догадываются, не признают этого, обычное ведь дело в истории!), поэтому текущее SoTA не позволяет выработать хорошие предложения.

Так что защита от эпидемий ограничивается всё тем же мытьём рук и бессмысленными ритуалами типа поливания тротуаров хлоркой (что приносит вред здоровью и честно квалифицируется политиками не как защитная мера, а как «психологический сигнал гражданам о том, что намерения правительства серьёзны»). Наука игнорируется, ибо сама суть науки — это свободное обсуждение теорий для того, чтобы найти в них ошибки, но теории эпидемий обсуждать свободно сегодня нельзя — признанные госчиновниками теории считаются дальше безошибочными.

Например, SoTA в прививках от гриппа и коронавирусов говорит, что ввиду большой изменчивости штаммов прививки для этих классов вирусов оказываются неэффективны, хотя для других могут быть эффективны⁴¹⁹. Фармакологические компании, понятно, с этим не согласны. Кто победит в дискуссии, если одной из сторон рты затыкают не учёные своими аргументами и экспериментами, а власти и даже частные СМИ? И ещё в этом участвуют не просто деньги, а очень большие деньги фармацевтического лобби? Увы, рациональное обсуждение этой темы пока невозможно: пыль от пандемии пока не осела, запреты на критику как теорий, так и действий госорганов ещё действуют.

Идея о том, что у природы нет злого умысла, а для избегания неприятных сюрпризов (болезней, ураганов, голода и т.д.) не хватает лишь знаний — это идея оптимизма, о ней подробней говорится в первом же разделе руководства по интеллект-стеку.

Двигаясь по этой линии развития методов избегания неприятностей, основанных на всё лучших и лучших объяснениях (включая тем самым и объяснение болезней) можно надеяться на достаточный объем знаний для методов получения людьми биологического бессмертия. А дальше уже понятно, что можно будет менять и саму природу человека, почему бы и нет! Для этого сегодня просто не хватает знаний, а их получение — то же бесконечное развитие, в том числе создание методов получения новых знаний (например, автоматизация науки с задействованием методов искусственного интеллекта и роботов, которая обсуждалась в текущем разделе). Всё это — возможные темы для продуктов, выбираемых визионерами и для бизнесов, выбираемых бизнесменами в ходе стратегирования.

Существование звёзд-квазаров тоже было абсолютно неочевидно, объяснение того, что с ними происходит, было невозможно в рамках ньютоновской физики. Появилась эйнштейновская физика, которая разбирается с искривлениями пространства-времени в присутствии больших масс, и она решила много космологических загадок. Квантовая физика по историческим меркам появилась очень недавно, но она уже объяснила многое из происходящего на другом конце спектра размеров — поведение фотонов управляется её законами. А дальше? Бесконечное развитие: остаётся проблема квантовой гравитации, хотя и к этой проблеме есть уже подходы⁴²⁰, тоже нещадно критикуемые — пока какой-то вариант не выживет. Поиск новых научных проблем и последующее их решение, приводящее к постановке новых проблем, будет вечным. Мы исторически находимся в самом начале этого бесконечного развития, наука ещё очень и очень молода, если рассматривать её существование во вселенском масштабе времени.

Книжка оптимиста Дэвида Дойча о бесконечном росте знания, бесконечном росте человечества так и называется «Начало бесконечности. Объяснения, которые меняют мир»⁴²¹.

Эта книжка подробно объясняет, как устроена современная наука. Наука даёт знания, помогающие устранять зло. Вводимое ей понятие рационального (а не слепого!) оптимизма сводится к тому, что «всё зло в мире объясняется недостатком знаний». Если не мешать предлагать новое знание и критиковать и новое, и старое так, что в области знаний SoTA будет постоянно и быстро меняться, можно постепенно преодолевать самое разное зло. При этом будет меняться и понимание зла, и понимание того, каких знаний недостаёт, и понимание того, что такое объяснения. Оптимизм в том, что рост знаний будет делать жизнь лучше, и мы в начале бесконечного роста знаний: оптимизм в том, что почти все неблагоприятные исходы и почти все благоприятные у нас ещё впереди, мы как человечество находимся в самом начале бесконечного роста знаний. Нужно только не мешать этим знаниям расти, для этого поддерживать выдвижение новых и новых универсальных объяснений, получение новой и новой критики этих объяснений.

Мы предлагаем считать эту книгу частью руководства по методологии, которая описывает стратегирование, появление новых идей о том, как решать проблемы.

Неопровергнутые лучшие объяснения на каждый момент составляют SoTA науки, лучшее известное на сегодня научное знание. Оно будет бесконечно расти, давая при этом бесконечное число способов бороться со злом: смертью, болезнями, несправедливостью, глупостью и всем остальным, что только можно представить плохого. Люди (и их организации) готовы заплатить за системы и сервисы, реализующие это знание.

Лучшее на сегодняшний день понимание и науки (получение всё более и более точных и универсальных объяснений, порождающих/generative моделей мира), и инженерии (создание и бесконечное развитие целевых систем) и менеджмента (в части бизнеса как вложение ресурсов в проекты создания и развития систем создания) основано на двух идеях, подробнее разбираемых в руководстве по интеллект-стеку:

• Эволюционной эпистемологии (научное, инженерное, менеджерское и т.д. знание/episteme развивается в ходе бесконечной/open-endedness эволюции и техно-эволюции, непрерывного выдвижения новых идей).

• Критического рационализма (имеющееся знание критикуется на основе принципов рационального, то есть основанного на логике, следующего каким-то правилам, а не произвольного рассуждения, и эти рассуждения проверяются ещё и экспериментами в физическом мире, а не только мыслительными экспериментами). И помним, что речь идёт не только о «мышлении», но и действии, мышление деятельно, рационализм тем самым подразумевает действия, в него входит в том числе и теория решений.

Пользуемся тем знанием о мире, о целевых системах (продуктах), об агентах-создателях (людях, системах AI, их коллективах), которое лучше другого знания прошло критику логическую и экспериментальную/«проверку жизнью»: оно рационально. Принимаем это знание всерьёз, то есть кладём в основу тех методов, по которым мы собираемся работать. Но поскольку время от времени выдвигаются новые идеи, которые трудней критиковать, чем предыдущие идеи, переходим к использованию нового знания. Старое забываем, принимаем всерьёз уже новое знание, основываем свои стратегии дальше на новом знании — и так меняем свои знания, то есть учимся/познаём до бесконечности.

Бесконечное развитие (open-endedness), «непрерывное всё» и свобода выдвижения гипотез и их критики пронизывают всю жизнь, происходят на всех системных уровнях — и в науке, и в искусстве, и в инженерии, и в бизнесе/менеджменте, и в создании сообществ, и в политике.

Выдвижение визионерских и бизнес-гипотез (для себя лично, или для небольшого стартапа, или даже для большой транснациональной корпорации) не особо отличается от выдвижения научных гипотез. И проверяется похожим способом: часть этих гипотез можно отвергнуть простой проверкой их логики, а часть приходится проверять ещё и экспериментально. И ещё все эти гипотезы приходится согласовывать между собой. Методы многоуровневы, их задействование требует обширных знаний — и лучше бы эти знания были согласованы между собой, чтобы давать надёжное предсказание, и основанные на этих знаниях методы имели шанс достигать ожидаемого результата.

Детёныши млекопитающих сами ставят себе цепочку усложняющихся проблем, сами их решают в ходе своего обучения — это игры. В этих играх они учатся двигаться, учатся добывать пищу. По факту они тестируют, насколько сильно их влияние на окружение, где это ещё «они двигают собой», а где это уже «окружение двигает их». Иногда детёнышам помогают взрослые особи, но это происходит отнюдь не всегда. Дальше детёныши вырастают, и просто имеют какой-то уровень мастерства (знания и тренированное под специфические нагрузки тело и под специфическое внимание органы восприятия окружения и своего тела), уж какой позволяет их биологическая природа. Бесконечного развития не происходит, они перестают играть, они научились — и просто живут. Мастер-гепард умеет бегать, мастер-попугай умеет кого-то передразнить. И это на всю жизнь.

У людей и их организаций ситуация другая: детёныши людей и молодые стартапы тоже играют, в ходе игры находят себе проблемы сами — и сами научаются эти проблемы решать. Но значительную часть проблем ставят перед детьми взрослые, а для стартапов акселераторы, серийные предприниматели, менторы. Так, для детей взрослые предлагают некоторый обязательный (обязательное школьное образование! И даже вузовское образование такое же) учебный план/curriculum. А потом эти поставленные кем-то учебные проблемы заканчиваются — и развитие опять переходит к бывшему ученику. Школьные и вузовские «проблемы» — это больше не проблемы, а «задачи», но жизнь ведь будет подкидывать не эти задачи с выученными способами их решения, а новые проблемы. Дальше всё зависит от выпускника школы или вуза: «взрослые» из образовательных учреждений могут сказать о мире не больше, чем бывший ученик и сам уже знает.

Освоение новых видов мастерства этот бывший ученик себе может не запланировать, и его текущие знания и умения тогда быстро устареют, он рискует остаться на обочине жизни (всегда помним, что не нужно волноваться: котят и морских свинок кормят повсеместно, а уж человеку точно не дадут от голода помереть, если тот будет достаточно ласков с другими людьми. А вот компании дадут умереть, это ж не люди!). В другом варианте стратегом выступит начальник: на работе сотруднику будут ставить проблемы из ближней зоны развития, и развитие случится. Если же на работе будут одни и те же однотипные задачи, а не проблемы (проблемы — это когда неизвестен метод решения, для задач метод известен, надо просто выполнить работу по методу, интеллект превращает проблемы в задачи) — развития не будет. Ещё возможно, что человек после первичного обучения возьмёт ответственность за собственное развитие на себя — сам будет ставить перед собой всё более и более сложные и разнообразные проблемы, а потом учиться их решать. И так всю жизнь, а если это компания, то более сложные и разнообразные проблемы будет ставить перед компанией менеджмент этой компании, причём всё время существования компании, а не только в момент её создания.

Никого не волнует, научились ли вы решать какие-то проблемы сами, или вас кто-то научил. Волнует, что вы эти проблемы решать умеете. И помним, что «научить с нуля» делать что-то сложное невозможно, обязательно нужен опыт решения более лёгких проблем, чтобы приступать к более сложным проблемам. Развитие идёт по ступенькам, и перескочить через много ступенек одним учебным усилием невозможно. Поэтому не расслабляйтесь: берите стратегирование на себя, всегда имейте достойную проблему для решения, достойный проект — не слишком лёгкий, но и не невозможный. Имейте всегда цель на границе тумана, двигайтесь за горизонт.

TEST бесконечного развития

Укажите процессы бесконечного развития:

--- круглогодичный рост сельскохозяйственной культуры на вертикальной ферме ### Нет, тут нет постоянного решения новых проблем, это просто рост растения. Не тот масштаб времени, чтобы можно было говорить о биологической эволюции.

+++ улучшение характеристик микропроцессоров ### Да, это бесконечное развитие. Непрерывно ставятся и решаются новые и новые проблемы (скорость работы, размеры чипа, число элементов на чипе, энергопотребление, виды аппаратно поддерживаемых вычислений, и т.д.) и выдвигаются новые и новые способы их решения (материал подложки, конструкция транзисторов, компоновка элементов по вертикали, способы охлаждения, другая элементная база — мемристоры, и т.д.)

+++ предложение образовательных программ ### Да, это бесконечное развитие. Предлагается обучение всё новым и новым методам работы, для самых разных входных и выходных уровней мастерства, за самое разное время, по самым разным бизнес-моделям, и это обучение предлагается делать всё более и более продвинутыми методами — blended learning, flip teaching, collaborative interactive learning, adaptive learning и т.д.

--- рост мастерства пианиста ### нет, это не бесконечное развитие, ибо речь идёт о решении одних и тех же проблем одними и теми же способами, просто растут количественные характеристики: прежде всего более точное звукоизвлечение. И известен потолок (если не переходить на другие виды инструментов, другие виды музыки). Если речь идёт о мастерстве музыкального исполнения как такового и выходе за пределы именно человека-пианиста, то ответ мог бы быть другим (бесконечный рост возможностей музыкального исполнения — сначала людьми на акустических музыкальных инструментах, потом машинным интеллектом, в том числе интеллектом-мультиинструментом)

+++ развитие музыкальной культуры ### да, постоянно ставятся новые проблемы (звукозапись, музак/muzak, дискотеки, создание самых разных новых музыкальных стилей, в том числе на основе разнообразия world music, альтернативные тональные шкалы и эстетические принципы) и предлагаются новые их решения (прежде всего, это переход к электронной музыке — включая электромузыкальные инструменты, синтезаторы, диджеинг, в последнее время использование «нейрокомпозиторов» с алгоритмами AI)

Моделирование: версионирование стратегии

Чем отличалась предыдущая версия вашей стратегии для рабочего проекта от текущей, и когда было сделано изменение? Когда ожидается следующее изменение, и знаете ли вы о ведущихся обсуждениях изменений стратегии? Заполните табличку.

Моделирование: использование личной или корпоративной стратегии как фильтра

Стратегию надо использовать как фильтр, помогающий удержать собранность на выполнении работ по этой стратегии: если вы приняли решение работать по какому-то методу, то вы не будете отвлекаться на другие работы и методы, не соответствующие выбранной стратегии (или будете, но тогда надо признать, что поменяли стратегию!). Когда вы слышали про использование стратегии для быстрого отклонения или принятия нового личного или корпоративного проекта? Опишите более трёх случаев.

Задания

Поставьте отметки о выполнении следующих заданий:

1. Прочтена книга Kenneth O. Stanley, Joel Lehman «Why Greatness Cannot Be Planned: The Myth of the Objective», 2015. Опубликован пост с вашими мыслями по поводу прочтённой книги.

2. Прочтён текст Kenneth O.Stanley, Joel Lehman, Lisa Soros, "Open-endedness: The last grand challenge you’ve never heard of", 2017, https://www.oreilly.com/ideas/open-endedness-the-last-grand-challenge-youve-never-heard-of. Опубликован пост с вашими мыслями по поводу прочтённого текста.

3. Прочтена книга Эрик Рис, «Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» (оригинал вышел в 2011 году), и опубликованы свои мысли о бесконечном стратегировании, пришедшие в голову по ходу чтения этой книги.

4. Проведены беседы с десятком ваших сотрудников и по их итогам опубликовано эссе «Что знают о нашей текущей корпоративной стратегии сотрудники, и как они используют её в своей работе».

Теории счастья и богатства

Может показаться, что в таком мире, где нужно ежедневно заново вырабатывать новую стратегию и тем самым выбирать, кем ты будешь (новый метод работы — новая роль, требует нового мастерства!), а большинство проектов ещё и будут заведомо провальны, жить будет невыносимо нервно и люди будут несчастливы. Это и так, и не так: со счастьем субъективно будет «как всегда», но при этом общий уровень жизни будет расти! Посудите сами: «выгорание» ещё лет двадцать назад не существовало, это было просто «очень лень работать», а сегодня «выгорание» рассматривается как уважительная причина увольняться. Увольняться «в никуда» от нежелания работать на нелюбимой работе можно теперь себе позволить, этого массово раньше не было, мир стал неизмеримо богаче!

Научных исследований по счастью достаточно много. Подробный исторический обзор того, что происходит со счастьем в разных странах приводится в книге Стивена Пинкера 2018 года «Просвещение сегодня. В защиту разума, науки, гуманизма и прогресса»⁴²².

Основное содержание книги посвящено тому факту, что в эпоху Просвещения начался стремительный прогресс человечества, и он с тех пор не прекращался и привёл к существенному повышению уровня жизни человечества. Но принесло ли это счастье? Вот как там начинается глава 19, которая так и называется — «Счастье»:

Американец в 2015 году по сравнению с аналогичным полвека назад живёт на девять лет дольше, образовывается на три года больше, получает дополнительных $33000 в год на члена семьи (только треть из которых, а не половина как раньше, уходит на необходимое для жизни) и имеет дополнительных восемь часов в неделю на досуг. Он или она могут провести это досуговое время читая интернет, слушая музыку на смартфоне, просматривая фильмы на телевизоре высокого разрешения, разговаривая с друзьями или родственниками по скайпу или обедая тайской едой вместо жареных мясных консервов.

Но если руководствоваться распространённым впечатлением, сегодняшние американцы не в полтора раза счастливей (как они могли бы быть, если бы счастье определялось по доходу), или на треть счастливей (если бы счастье определялось по образованию), или даже на восьмую часть счастливей (если счастье определялось бы по продолжительности жизни). Кажется, люди жалуются, стонут, плачут, придираются, ноют столько же, сколько всегда, а пропорция американцев, которые сообщают социологам, что они счастливы, остаётся постоянной десятилетиями.

Дальше рассматривается само понятие «счастье», и оказывается, что оно само по себе довольно бессмысленно — усредняется по многим другим показателям, как «средняя температура по больнице», когда часть с нулевой температурой в морге, а часть в реанимации — но в целом температура нормальная! «Счастье» само по себе имеет мало смысла, нужно сразу уточнять, что имеется в виду. Так, слово «счастье» используется для сразу двух разных характеристик: обозначения кратковременного эмоционального состояния, настроения веселья и безмятежности, но также и для более-менее рациональной оценки долгосрочной (день или даже жизнь) характеристики качества жизни.

Социологи нашли, что люди плохо различают счастье, удовлетворённость жизнью, а также простое предпочтение широко понимаемой «жизни получше» против «жизни похуже», не говоря уже о wellbeing/благополучии, а то и вообще понимаемом как «самочувствие» или вовсе уж абстрактное «процветание». Да ещё оказывается, что долгие периоды качественной жизни, полной смысла и оцениваемой в этом плане очень положительно, не связаны с постоянным ощущением веселья и безмятежности, ибо какая уж тут безмятежность, когда ты тяжело работаешь? Зато потом есть что вспомнить, и это очень приятные воспоминания, ибо твоя жизнь в этим моменты была полна смысла, да ещё и принесла много важных результатов! А вот какая-нибудь вечеринка с друзьями, где ты вроде как бы был абсолютно счастлив несколько часов подряд — вот она даже не запомнилась, забыта через неделю!

Но и этих странностей мало для понятия «счастье». Пинкер приводит вот такой график:

На этом графике доход на душу населения в разных странах приводится по логарифмической шкале и очень чётко видно, что в каждой стране богатые счастливей бедных (угол наклона стрелки каждой страны показывает корреляцию), но уровень счастья в каждой стране сильно отличается, и люди с одинаковым доходом в разных странах счастливы абсолютно по-разному просто от того, что речь идёт о другой стране!

Оказывается, ответ на вопрос «счастливы ли вы» (и обратите внимание, что на графике речь идёт об «удовлетворении жизнью», это не совсем «счастье», меньше похоже на эмоцию) зависит больше от страны, в какой задаётся этот вопрос, чем от величины собственного богатства!

Вот ответ на вопрос о счастье в проведённом агентством Ipsos опросе по удовлетворённостью жизнью в 28 странах в августе 2019 года⁴²³:

В Австралии 86% чувствуют себя счастливыми, а вот в России — 47%, вдвое меньше. Но почему люди так себя ощущают? В разных странах в среднем по разным причинам. Во всех странах причиной ощущения счастья называют хорошее здоровье и физическую форму, наличие детей, отношения в супружестве, ощущение того, что жизнь имеет смысл, а также ощущение безопасности и защищённости от всяких рисков. Но в некоторых странах по-другому. Скажем, в Перу и Турции 87% населения считают, что источником счастья является признание тебя со стороны других людей успешным человеком. В Малайзии и Саудовской Аравии для 86% населения наибольшее ощущение счастья приходит от религии и духовных практик.

Важно, что благосостояние на Земле постоянно растёт. Люди со временем богатеют, и в последние годы человечество богатеет очень быстро. То есть жизнь ускоряется, люди при этом становятся богаче (впрочем, всё это ускорение как раз и приносит новые цивилизационные блага). Растёт здоровье людей, это во всех странах ведёт к большей удовлетворённости жизнью. Но вот даже наличие детей в одних странах коррелирует с тем, что человек-родитель чувствует себя более счастливым, чем бездетный, а в других странах — ровно наоборот!

Но и это не последняя проблема со «счастьем». Само понимание счастья раньше и сейчас изменилось, и что вам кажется «полным счастьем» сейчас, может не показаться счастьем в будущем. Раньше «я не могу себе позволить мобильник», а теперь «я не могу себе позволить быть без мобильника, это только по-настоящему богатые и беззаботные люди бравируют, что они могут не быть постоянно на связи» и вдруг это переходит в «я уже не делаю звонки, но вынужден быть постоянно на связи, сижу в чатах, просвета не видно, я устал». Сейчас добавляется ещё и нежелание ходить на работу, работать только удалённо, чтобы спокойно воспитывать детей и путешествовать, а не по восемь часов торчать в офисе, ещё час тратить на обед где-то далеко от дома и затем тратить ещё час-два на дорогу туда-назад.

Восприятие счастья меняется со временем, у разных поколений оно разное. Так, раньше самые разные исследования показывали, что с возрастом счастье растёт. Современные исследования показывают, что с возрастом счастья становится меньше⁴²⁴:

Как поднять счастье? В 2006 году было исследование⁴²⁵, что уровень счастья не зависит от денег, начиная с какого-то не слишком высокого уровня дохода. Но в прошлом году провели ещё исследования, и выяснили, что чем больше денег, тем больше ощущение собственного благополучия⁴²⁶. И это тоже новый тренд, тут тоже всё меняется: в прошлом веке счастье действительно меньше зависело от дохода! И уже понятно, что ответ на вопрос зависит даже не от дохода, а от страны проживания и от возраста!

Так что понятие «счастье» меняется со временем, точно так же, как и понятие «здоровья» (медики давно уже признают, что «здоровье» определяется «социально-биологически», а не чисто «биологически», подробней об этом будет рассказано в руководстве по инженерии личности при обсуждении психологии и психотерапии).

Счастье зависит главным образом от генетических факторов (вообще восприятие мира существенно зависит от генетических факторов, поэтому восприятие неудовлетворённостей собой и миром тоже генетически определено⁴²⁷), но частично и от характера⁴²⁸ (на 50%⁴²⁹ или на 80%⁴³⁰ — это не договорились). Характер тоже зависит от генетических факторов, особенно в детстве, но чем старше человек, тем больше этот характер можно менять — хороший характер, как ни странно, можно как-то выучить, хотя победить можно и не всё генетически заданное, и этот характер повиляет на ощущение счастья — не полностью, но всё-таки хоть как-то.

Но это всё статистика, «в среднем по планете», как ощущение счастья зависит от страны, возраста и дохода у вас, какие у вас убеждения по поводу счастья и что у вас с генетикой на этот счёт — неизвестно. Но легко предположить: если вы ничего не будете делать, ничего существенного не будете предпринимать — у вас не будет ни дохода, ни счастья.

Можно дальше обсуждать, насколько понятие «счастье» применимо к компаниям, к работающим в этих компаниях людям. Например, Amazon считается компанией, которая жёстко эксплуатирует своих сотрудников. Правда ли, что они от этого несчастны? А почему они, если всё так плохо, не уволятся? То есть сотрудники компании Amazon оценивают не-работу-в-ужасной компании как ситуацию более плохую. То есть они более счастливы в работе на «эксплуататора» Amazon, чем оценивают свою счастливость в ситуации, когда работать на Amazon не надо! Идеальной ситуацией для любого работника было бы просто получать деньги и ничего не делать (экономисты тут говорят об отрицательной пользе труда), но этого не бывает. Поэтому люди и их организации просто обязаны как-то рисковать на каждом такте бесконечного развития, прыгать с камушка на камушек с заранее неизвестным долгосрочным результатом, ввязываться в какие-то проекты, встраиваться в цепочки создания, что-то предпринимать, трудиться.

Без неизбежного принятия риска ввязывания в провальный проект и выполнения каких-то работ никакого счастья не получится, ибо будущее всегда покрыто туманом: заранее нельзя выяснить, успех или неудача, удовлетворение или разочарование будет в итоге любого вашего действия, всего на свете не просчитаешь. Но если ничего не делать и «плыть по течению» лёжа в кровати, то гарантированно придёт неприятный сюрприз от окружающей среды, а ресурса на предотвращение его последствий не будет.

Так что лучше не задаваться вопросом «буду ли я счастлив в будущем», а задаваться какими-то другими, более определёнными вопросами.

Так, во всех исследованиях счастья отмечается, что существенная составляющая ощущения удовлетворённости жизнью — это осмысленность существования, понимаемая чаще всего как преодоление каких-то неприятностей, помощь другим людям, достижение каких-то целей. Какие-то (понятные! достижимые!) цели нужно ставить, их нужно достигать — и это даст осмысленность жизни, что ведёт к долговременной составляющей ощущения счастья. Да, это не счастье-веселье, эйфория от момента. Но это счастье хорошо прожитой жизни, удовлетворённости жизнью. И эта цепочка проектов не обязана быть одним проектом, одним большим днём сурка. Вы вполне можете разнообразить жизнь, не застревать в одном деле (да вам жизнь и не даст застрять надолго). В некоторых культурах ценность жизни так и определяется — сколько разных впечатлений получил за жизнь человек. Если это не десятки лет самых разных трудовых впечатлений, а одно и то же впечатление, повторяющееся десятки лет — не факт, что это счастливая жизнь, хотя факт, что спокойная.

Если вы (и как человек, и как компания/организация) действуете, если ввязываетесь в разные проекты, то статистически время от времени вам должно везти, равно как часто будут и неудачи — как из-за ваших ошибок, так и просто из-за никак не зависящих от вас причин. При этом нельзя как ожидать, что вам удастся быть существенно счастливей, чем чувствуют себя люди в вашей стране, так и нельзя ожидать, что вы будете существенно несчастней!

Впрочем, можете постоянно бездельничать — выживают сейчас и неработающие нищие (бездельничать — это такая трудная, но работа!), и даже морские свинки, ибо они «миленькие» и их соглашаются кормить просто за то, что они есть, такие глупые и нелепые. Привыкнете и к одному, и к другому. Выбор за вами.

Но всё-таки: что с богатством? Как связано вечное развитие с богатством? Вот вы развиваетесь, становитесь очень умным — станете ли вы богатым, и поднимет ли вследствие этого развитие уровень вашего счастья? Скорее всего — нет. Исследования (в том числе компьютерное моделирование)⁴³¹ показывают, что богатство таки даётся случаем, и если человек минимально умён, чтобы не профукать свой шанс, то он будет богатеть. Богатство людей различается в миллионы раз (сто миллиардов долларов против ста тысяч долларов — это ведь как раз миллион), а умность людей на сегодняшний день различается не так сильно (особенно если сравнивать с маленькими детьми или животными, не только образованных взрослых друг с другом).

Вычислительные модели удивительно точно воспроизводят реальные данные, когда допускается влияние случая на успех или неуспех затеваемых людьми проектов. Самые богатые — это просто удачливые люди, которые оказались вовремя на нужном месте и не профукали свой шанс, возможно не профукали свой шанс неоднократно, они необязательно самые умные. Но они и не самые глупые. Самые глупые просто прозевают свою удачу, не заметят её. Представьте, что вы выросли в джунглях и попали в современный город: вы не закончили школу, не закончили университет. И вы даже вождь племени! Станете ли вы богатым?! Вряд ли. Рецепт богатства в этом случае будет «сначала подучиться, а там посмотрим».

И это хороший ментальный приём: представлять себя дикарём только из джунглей (ваши знания десятилетней давности, они бесконечно стары!) пытаться сориентироваться — что сейчас происходит в мире, пока я был в джунглях? Что изменилось вокруг, пока я был погружён в джунгли текущего своего проекта и не успевал поднять голову и оглядеться? Что я не понимаю в происходящем, что нового умеют окружающие меня люди? Чем я мог бы в этом новом мире заняться, чтобы преуспеть?

В любом случае: если вы не учитесь (не всему подряд! Только тому, что увеличивает дальше возможности!), то вряд ли станете миллионером. Хотя стать миллионером и даже миллиардером может помочь случай, например — получите наследство. Но если учитесь — вполне можете стать миллионером, заработать миллионы. Стать миллиардером, становясь умнее и умнее — это уже не получится, тут должна сопутствовать удача. Миллиардеров довольно мало, а умных людей — очень много. Компаний-единорогов (с капитализацией выше миллиарда долларов) мало, а самых разных больших, средних и маленьких компаний с очень талантливым руководством — очень много. Трезво оценивайте свои шансы!

Моделирование: личные стратегии

Заполните таблицу потенциальных личных стратегий (для корпоративных стратегий это тоже можно делать, но в таблице есть специфические оценки, например, «сила желания»). Удалите из неё те стратегии, для которых нет известных вам средств реализации (можете перед этим спросить AI-ассистентов вроде ChatGPT — это вы не знаете средств достижения, или они вообще ещё неизвестны человечеству), утопиями не нужно заниматься. Сравните текущую вашу стратегию и потенциальные другие цели (поставьте им всем оценки желаемости по десятибалльной шкале). Ответьте себе на вопрос, почему вы сейчас занимаетесь тем, чем занимаетесь, учитесь тому, чему учитесь — и не занимаетесь чем-то другим из вашего списка, рассортируйте на две таблицы: чем занимаетесь сейчас и чем будете заниматься «когда-нибудь» (возможно, никогда — тут надо быть перед собой честным).

Хочу изменить сейчас и занимаюсь этим:

Хочу изменить когда-нибудь и не занимаюсь этим:

Задания

Поставьте отметки о выполнении следующих заданий:

1. Текущая рабочая (не личная) стратегия вашего уровня (всей фирмы, или подразделения, или лично вас как оргзвена из одного человека) документирована в одном из предложенных в руководстве (возможно, адаптированном в ходе коллективных обсуждений) формате.

2. Вы провели не менее трёх раундов обсуждения документированной стратегии с сотрудниками, руководителями, собственниками/инвесторами и другими причастными к формулированию и реализации рабочей стратегии вашего уровня людьми. Вы хорошо понимаете, что происходит с результатами этих обсуждений, насколько разные люди готовы следовать этой стратегии или хотя бы не мешать её реализации.

3. Вы предложили, обосновали и приступили к выполнению хотя бы одного шага развития (научиться новому мастерству, приобрести оргвозможность), исходящего из текущей стратегии вашего уровня.

4. Вы помогли в обсуждении (обязательно с документированием обсуждённого и рассылкой документа участникам обсуждения!) стратегии не менее чем троим вашим друзьям и/или сотрудникам.

5. В блоге опубликован пост по теме «Стратегирование», где вы отметили, что изменилось в ваших представлениях о стратегировании после освоения методологической работы по нашему руководству, а также дали рекомендации для инженеров-менеджеров, осваивающих методологическую работу после вас (в том числе сообщили им, сколько времени вы затратили на освоение методологической работы по руководству — им эти оценки очень помогут).

Что дальше

Моделируйте альфы вашего проекта в каком-нибудь универсальном моделере (используйте таблицы!), не забывайте отслеживать их состояние: если вы долго не вспоминали о какой-то альфе и не интересовались, что с ней происходит, ждите там неожиданностей. Методы работы появляются в тот момент, когда вам нужно одно состояние какой-то альфы как предмета метода перевести в другое. Вы должны выбрать способ того, как это будет происходить, а потом кто-то (личность, команда, коллектив из нескольких команд, предприятие, производственная кооперация из нескольких предприятий) с мастерством выполнения этой практики и всеми необходимыми для выполнения работ по этой практике ресурсами должен будет выполнить эту работу. Всё это вполне работает и для личного стратегирования, личных проектов.

При взгляде на что угодно, происходящее в мире, задавайте себе вопросы: «это какой метод работы? Я в ней разбираюсь? Тот, кто выполняет эту работу, осознаёт метод своей работы и откуда он этот метод взял? Кто (культурно-обусловленная роль) обычно этим видом труда занимается, где они учатся трудиться именно так? Насколько современен этот метод работы? Нужно ли такую работу делать по другому методу, не упустили ли тут эволюционных изменений в способе работы?».