Закат тяжеловесных методологий
Мы уже упоминали, что один из стандартов ситуационной инженерии методов (ISO 24744) подчёркивал синонимичность метода/method и методологии/methodology. У термина «методология/methodology» есть в инженерии значения как минимум:
- отдельного метода/практики/«вида инженерии»,
- метода как совокупности частных методов в его разложении (процессов, практик) для достижения каких-то значимых результатов «под ключ», например, «инженерный процесс»/«метод разработки»/«методология разработки» или одного достаточно объёмного метода, например «методология управления проектами»,
- общего метода мышления о методах (предмет нашего руководства)
- учения/теории/дисциплины о методах (описание метода мышления о методах).
Повторим, что то же самое с геометрией («геометрия изучает геометрии, например геометрию Римана») и логикой («логика изучает логики, например модальную логику»). Так что из контекста должно быть понятно, имеется ли в виду методология как общее учение о методе, или это просто назвали какой-то достаточно общий метод работы методологией.
Популярные полные/исчерпывающие/comprehensive методы/методологии/процессы разработки (development process), т.е. разные варианты agile методов/методологий/процессов (например, DSDM, SCRUM, SAFe и т.д.)[1], они же «гибкая методология разработки» (но она не одна, их много вариантов!), обеспечения качества (например, six sigma[2]), архитектурной работы для предприятия (TOGAF[3], но осторожней: там те же проблемы с архаичностью, что и у ISO 15288, и у NASA SEM) и даже многочисленные варианты старинных по их идеям (но по датам выпуска стандарта — вроде свежих!) методологий системной инженерии, оказываются все согласованными между собой наборами множества детально прописанных разложений методов создания и развития систем или каких-то отдельных свойств систем.
Такие «полные/исчерпывающие/comprehensive/тяжеловесные/heavyweight методологии» в реальной работе сегодня прекращают использоваться, хотя их знание помогает в общении с коллегами, имеющими опыт работы в предыдущих, ныне уже безнадёжно устаревших культурах инженерии и менеджмента. При этом до сих пор процветает деятельность по продаже сертификатов на знание таких методологий. «Сертифицированный профессионал/специалист» по системной инженерии, проектному управлению и т.д. — это как раз тот, который сдал экзамен, чтобы подтвердить, что он «знает BoK исчерпывающей методологии». Вовсе необязательно, что этот специалист имеет мастерство этой методологии, то есть может по этому методу реально работать так, чтобы получать запланированные методом результаты, но он выучил пухлый томик «методологии» как описания метода и сдал экзамен на то, что может отвечать на вопросы по тексту.
Такие «прикладные методологии для сдачи экзаменов» часто содержат в себе три части:
- Общее описание дисциплины/объяснений для многих составляющих методологию методов. Эта дисциплина вводит предметы общего метода, поэтому можно сформулировать сигнатуры составляющих методов и ввести альфы общих предметов для этих составляющих методов. Составляющие методы прикладной методологии потом могут работать с подальфами этих альф. Например, agile-методологии вводят альфу backlog[4] как некоторый «список хотелок к реализации». Практики ТРИЗ-методологии используют понятие «идеального конечного результата»[5], методологии социальных танцев работают с понятием «коннекшн»[6].
- Множество отдельных методов как инструкции «что и как нужно делать» в каждой конкретной ситуации: «если встретил ситуацию X, то делай в ней Y с объектами Z». Их обычно много разных (десятки, если не сотни в одной методологии), они могут вводить свои подальфы, но в целом посвящены переводу альф из одного состояния в другое.
- указания на то, как сочетать методы с работами (итерациями, спринтами, стадиями, этапами, кейсами) в ходе инженерного процесса. Иногда даже слова «методология разработки» используют именно как указание на этот аспект, а в более старых стандартах говорят о «модели жизненного цикла».
Сегодняшний тренд**—** это разборка немногих оставшихся крупных**/тяжеловесных методологий на отдельные небольшие методы. Это контркультурный тренд lean/элегантности/«минимального** действия**». Помним, что сегодняшняя контркультура — это часто завтрашняя культура, просто в момент смены культуры новое воспринимается как отрицание культуры.** «Немногих оставшихся» тут сказано потому, что большинство таких исчерпывающих методологий (иногда их называют «монструозными», невозможными к полному воплощению в жизнь, заведомо утопичными и избыточными) уже отвергли, то есть перестали даже пытаться их воплотить в жизнь в каких-то предприятиях. Такие методологии иногда используются разве что для покупки разных сертификатов подтверждения соответствия, чтобы поучаствовать в тендерах/конкурсах госзакупок и приложить сертификат к конкурсной документации, чтобы поднять шансы. В случае отдельных людей сертификация тоже используется для того, чтобы указать «я знаю сложный метод, я читал книжки» (но сертификация не значит, что «я знаю сложный метод, я могу этим методом эффективно работать и добиваться конкурентоспособных результатов».
Ещё лет десять назад считалось, что нужно обязательно использовать в работе все описанные какой-то тяжеловесной методологией составляющие её методы, и без задействования всех этих методов результат разработки будет плохим, «несовершенным», незавершённым. Сегодня такого уже нет и такой подход «всё без пропусков, иначе работать не будет» жёстко критикуется, он не соответствует принципам элегантности/lean.
Для методологий разработки Ivar Jacobson (один из ведущих соавторов стандарта описания методов/процессов создания и развития систем OMG Essence) призывает «освободить практики от методологий» (помним, что «метод» и «методология» часто используются как указание на то, что они содержат в себе довольно много мелких методов, называемых в этом случае практиками). По Ivar Jacobson небольшие объяснения/знания отдельных методов являются отличными единицами накопления опыта — его доклад на SECR’17 так и называется: «Kill All Methods — Free the Practices»[7]. Никакого метода как полного набора практик для достижения результата «под ключ», работаем с отдельными культурно-обусловленными практиками, которые выбираем не из тяжеловесных методов/методологий, а сразу изо всех возможных источников знаний. А если эта практика оказалась слишком большой (её в инженерии часто называют «методом»), то разбираем на составляющие практики и её — но используем в работе всегда только небольшую часть известных нам практик, а не работаем по детально прописанным сотням практик из какой-нибудь тяжеловесной всеохватной методологии.
Переход от тяжеловесных/heavyweight методологий (описываемых документами на сотни страниц и требующих неукоснительного соблюдения сразу всех требований этих сотен страниц) к легковесным/lightweight методологиям (описываемых короткими документами, и упирающих на очень компактный набор принципов, без длинных указаний о том, что и когда делать и без обязательного учёта всех этих принципов в их неразрывной совокупности) отражает современную культуру элегантности, стремление избавиться от ненужной работы в пользу только минимально необходимой.
Это очень серьёзное изменение в культуре (культура — это синоним для получивших распространение инженерных процессов), и прошло оно за последние двадцать лет. В 2000 году легковесные методологии, в которых входящие в их состав методы/практики работы разобраны в их описании до чуть ли не отдельных независимо применяющихся принципов их дисциплин, выглядели очень несерьёзно, над ними смеялись. Сегодня наоборот: именно это оказалось серьёзным и эффективным, а вот тяжеловесные методологии перестали даже рассматривать.
Заявления о том, что «у вас метод SCRUM не работает, потому как вы не выполнили все до одного требования 600-страничного документа, её описывающего» хороши были в 2000 году, сегодня они вызывают улыбку. А что следование немногим принципам отслеживается много жёстче, чем следование заведомо невыполнимым уложениям сотен страниц тяжеловесных методологий, сегодня уже понятно: порядка в следовании легковесным методологиям оказывается в итоге больше, чем порядка в следовании заведомо невыполнимым тяжеловесным методологиям.
Разборка крупных методологий на отдельные небольшие методы происходит даже в танцевальных методологиях/методах/стилях. Повсеместно происходит переход от жёсткого соблюдения в танце одного какого-то стиля (хотя на конкурсах жёстко отслеживается чистота стиля!) к fusion dance[8] как сплаву разных танцевальных стилей. Например, в социальных танцах это может быть смесь/mix или сплав/fusion танцевальных стилей танго, кизомбы, форро, сальсы (см. как пример проект системного мультиданса[9]).
Объединение разных танцевальных стилей требует дополнительного развития тела как инструмента для составного fusion-стиля. чтобы оно могло выполнить движения нескольких стилей. Часто нужно и подстраивать музыку, чтобы в ней были проявлены музыкальные акценты многих ритмов, использующихся в «сплаве» стилей. Если хотите смешать практики из стиля/культуры/методов хип-хопа и стиля/культуры/методов кизомбы, а вами был освоен только один стиль, то придётся доразвить тело и подобрать подходящие музыкальные треки. Но это возможно! Помним, что «стиль», который мы тут обсуждаем — это просто один из синонимов метода. Подход с «тяжеловесными методологиями» (требование строгого соблюдения одного стиля, зато в его полноте) практически исключал такие смешения, мультидисциплинарные (задействующие множество знаний/дисциплин/объяснений многих методов) работы были крайне трудны — и в танцах, и в инженерии, и в менеджменте. Это презрительно называлось «эклектика». Но нет, оказалось, что тщательный подбор методов из разных их разложений в новый составной метод — это секрет к получению новых стилей/культур/методов, это и есть проявление эволюции, путь к развитию.
Думать о таком смешении нужно примерно так же, как о приготовлении пищи: когда вы смешиваете разные продукты, то получаете эмерджентные свойства у результата — борщ по вкусу не равен сумме вкусов входящих в него продуктов, винегрет по вкусу отличается от вкусов входящих в него продуктов. И такой результат запоминается, реплицируется, если оказывается удачным (а вот гречка с шоколадом — не реплицируется, вкус не слишком оказывается удачным).
То же самое с методами работы: оказалось, что если смешивать/сочетать отдельные тщательно отобранные составляющие методы, то можно получать очень элегантные хорошо работающие составные ситуационные методы. А вот отдельные тяжеловесные методологии уже ни с чем не смешаешь. Из свёклы можно и борщ получить, и винегрет, а вот борщ с винегретом — уже не очень хорошо получится смешивать — хотя это всего-навсего метафора, но она передаёт основной посыл выделения отдельных важных методов, из которых потом будут составлены самые разные составные методы. Нужно понять, какие есть исходные методы (иметь кругозор!), из которых в конечном итоге можно приготовить всё остальное, если в этом в какой-то ситуации возникнет потребность.
В реальных проектах создания самых разных видов систем при сочетании методов, взятых из разложения тяжёлых методологий, тоже приходится не только обучать людей необходимым фрагментам объяснений этих методологий, но и дорабатывать инструментарий, чтобы он поддерживал разные объяснения одновременно (скажем, современные issue trackers поддерживают и построение диаграмм Ганта на верхнем уровне: методы управления кейсами и проектного управления смешиваются — директивный график берётся из проектного управления, а реальная работа в её мелком дроблении проходит согласно управлению кейсами).
Сами методологии необязательно ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) классических инженерных (главным образом software engineering) и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик создания целевой системы, но только инженерии и эксплуатации команды разработчиков, то есть менеджерские[10].
Методологии проектного управления наоборот: начиналось всё с операционного менеджмента, но сейчас всё больше и больше там обращают внимание на системную инженерию целевой системы (в последние годы в них даже появляются описания отдельных частных практик инженерии требований, хотя эти описания совершенно недостаточны для полноценной инженерной работы, да к тому же сама разработка требований уже устарела как практика — системная инженерия успела измениться за последние пять лет, управляющие проектами это не отследили. Но и управление проектами сегодня немного архаично выглядит, ибо на смену ему приходит управление кейсами).
Методология как фундаментальный метод мышления даёт похожим образом думать о****б инженерном процессе создания и развития самых разных систем (вещества, киберфизических систем, существ, личностей, организаций, сообществ, обществ).При этом, конечно, используются и остальные фундаментальные методы мышления интеллект-стека. А учитывая то, что развитие агентов/IPU/создателей — это освоение ими мастерства выполнения новых методов, методология позволяет обсуждать и организационное развитие: создание оргвозможностей для новых методов работы, а также сознательный отказ от ранее использовавшихся оргвозможностей, то есть отказ от работы по старым методам**.**
http://2017.secr.ru/lang/en/program/invited-speakers/ivar-jacobson ↩︎
https://en.wikipedia.org/wiki/Fusion_dance, пример fusion кизомбы с разными другими стилями см. в https://ailev.livejournal.com/1373388.html ↩︎