Исчерпывающие методы/методологии ​

Мы уже упоминали, что один из стандартов ситуационной инженерии методов (ISO 24744) подчёркивал синонимичность метода и методологии для названия практик. У термина «методология/methodology» есть значения 1. отдельного метода/практики, 2. метода как совокупности практик для достижения каких-то значимых результатов «под ключ», а также 3. «общей теории/дисциплины, изучающей деятельность/практики/«методы работы»/труд»). А вот наоборот неверно, дисциплину называют методологией, но не называют методом. Метод --- это то, что изучает методология. Но с учётом синонимии, можно сказать и «методология изучает методологию» (то есть «методология изучает метод/практику/деятельность»). Повторим, что то же самое с геометрией («геометрия изучает геометрии, например геометрию Римана») и логикой («логика изучает логики, например модальную логику»). Так что из контекста должно быть понятно, имеется ли в виду методология как общая теория деятельности, или это просто назвали какую-то практику методологией.

Популярные полные/исчерпывающие/comprehensive методы/методологии разработки (development process), т.е. разные варианты agile методологий (например, DSDM, SCRUM, SAFe и т.д.)^[1], они же «гибкая методология разработки» (но она не одна, их много вариантов!), обеспечения качества (например, six sigma^[2]), архитектурной работы для предприятия (TOGAF^[3]) и даже методологии социальных танцев^[4] оказываются все согласованными между собой наборами множества детально прописанных практик создания и развития систем или каких-то отдельных свойств систем (как методологии обеспечения качества), или как раньше говорили, практик жизненного цикла, разве что не всех стадий от замысла до уничтожения, а какой-то одной (чаще всего проектирования, реже проектирования и изготовления, и всё чаще и чаще практик эксплуатации --- вместе это будет «разработка»/development, но вот практики визионерства, архитектуры, инженерии производственной платформы отсюда исключаются, полных методов для них нет, их собирают из отдельных практик «по потребности»).

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

• Общее описание дисциплины для многих составляющих методологию практик. Эта дисциплина вводит альфы методологии, а отдельные практики внутри методологии потом могут работать с подальфами этих альф. Например, agile-практики вводят альфу backlog^[5] как «список хотелок к реализации». Практики ТРИЗ-методологии используют понятие «идеального конечного результата»^[6], социальные танцы работают с понятием «коннекшн»^[7]
• Множество отдельных практик как инструкции «что и как нужно делать» в каждом конкретном случае: «если встретил X, то делай Y». Их обычно много разных, они могут вводить свои подальфы, но в целом посвящены переводу альф из одного состояния в другое.
• указания на то, как сочетать практики с работами в ходе создания систем/жизненного цикла, то есть прописывание предпочитаемой концепции/вида/модели жизненного цикла, или концепции создания и развития системы. Иногда даже слова «методология разработки» используют именно как указание на этот аспект (подменяя словами «методология разработки» слова «модель жизненного цикла», когда речь идёт о гибких методологиях разработки, в которых уходят от обсуждения однократного жизненного цикла к «непрерывному всему» с по возможности бесконечным развитием системы).

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

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

Для методологий разработки Ivar Jacobson (один из ведущих соавторов стандарта описания методов/процессов создания и развития систем OMG Essence) призывает «освободить практики от методологий», ибо они являются отличными единицами накопления опыта --- его доклад на SECR'17 так и называется: «Kill All Methods --- Free the Practices»^[8]. Никакого метода как полного набора практик для достижения результата «под ключ», работаем с отдельными культурно-обусловленными практиками, которые выбираем не из методов, а сразу из культуры. А если эта практика оказалась слишком большой (методом!), то разбираем на подпрактики и её --- и используем всегда только небольшую часть известных практик, а не работаем по детально прописанным сотням практик из какой-нибудь тяжеловесной всеохватной методологии.

Переход от тяжеловесных/heavyweight методологий (описываемых документами на сотни страниц и требующих неукоснительного соблюдения сразу всех требований этих сотен страниц) к легковесным/lightweight методологиям (описываемых короткими документами, и упирающих на очень компактный набор принципов, без длинных указаний о том, что и когда делать и без обязательного учёта всех этих принципов в их неразрывной совокупности) отражает современную культуру антиперфекционизма, стремление избавиться от ненужной работы в пользу только минимально необходимой. Это очень серьёзное изменение в культуре, и прошло оно за последние двадцать лет. В 2000 году легковесные методологии, в которых практики разобраны до чуть ли не отдельных независимо применяющихся принципов их дисциплин, выглядели очень несерьёзно, над ними смеялись. Сегодня наоборот: именно это оказалось серьёзным, а вот тяжеловесные методологии перестали даже рассматривать. Заявления о том, что «у вас практика SCRUM плоха, потому как вы не выполнили все до одного требования 600-страничного документа, её описывающего» хороши были в 2000 году, сегодня они вызывают улыбку. А что следование немногим принципам отслеживается много жёстче, чем следование заведомо невыполнимым уложениям сотен страниц тяжелых методологий, сегодня уже понятно: порядка в следовании легковесным методологиям больше, чем порядка в следовании заведомо невыполнимым тяжеловесным методологиям.

Разборка крупных методологий на отдельные практики происходит даже в танцевальных методологиях, повсеместно происходит переход к fusion dance^[9] как сплаву практик разных танцевальных стилей, определяемых разными методологиями этих стилей. Например, в социальных танцах это может быть смесь/mix или сплав/fusion практик танцевальных стилей танго, кизомбы, форро, сальсы (см. как пример проект системного мультиданса^[10]). Помним, что практика в танцевальном стеке практик поддерживается не только дисциплиной/теорией/каноном какого-то стиля танца, но и инструментарием в виде тела и звучащей музыки. Напомним стек танцевальных практик (он был рассмотрен подробней в курсе системного мышления)^[11]:

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

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

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

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

Сами методологии необязательно ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) классических инженерных (главным образом software engineering) и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик создания целевой системы, но только инженерии и эксплуатации команды разработчиков, то есть менеджерские^[12]. Методологии проектного управления наоборот: начиналось всё с операционного менеджмента, но сейчас всё больше и больше там обращают внимание на системную инженерию целевой системы (в последние годы в них даже появляются описания отдельных частных практик инженерии требований, хотя эти описания совершенно недостаточны для полноценной инженерной работы, да к тому же сама разработка требований уже устарела как практика --- системная инженерия успела измениться за последние пять лет, управляющие проектами это не отследили).

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