Введение
Курс «Методология» продолжает курс «Практическое системное мышление» (обязательный пререквизит), рассказывая о практиках (деятельностях, видах труда, способах и методах работы) жизненного цикла систем. Изложение идёт главным образом для практик таких создателей систем, как люди и их организации с их компьютерами и оборудованием. В курсе даётся современное понимание методов создания и разработки, даётся системная схема проекта как набор объектов, изменения которых должны отслеживаться в ходе всего проекта.
В курсе методологии даётся современная версия учения о методе (практиках работы, способах работы, деятельностях, видах труда, видах инженерии). Методология появилась как философская дисциплина о методах познания, но в современной инженерии и менеджменте «методология» стала учением о методах выполнения деятельности по изменению мира, то есть деятельности по созданию систем самых разных системных уровней. Изложение базируется тем самым не столько на философской литературе прошлых веков и литературе по общей теории систем прошлого века, сколько на методологических международных стандартах в менеджменте, инженерии, программной инженерии (особенно широко мы используем стандарт OMG Essence 1.2:2018, системная схема проекта дана по его мотивам). Подробно рассказывается, что произошло с понятием «жизненный цикл», как оно постепенно заменилось понятием «метод/процесс разработки» по мере перехода к «непрерывному всему» со включением эксплуатации в обязанность инженерной команды (you build it, you run it!). Мы также проводим линию рассуждения о растущей эволюционной сложности систем, которая подробно обсуждалась в курсе «Практическое системное мышление» для практик. Создатели систем и методы их работы тоже эволюционируют. Чтобы разбираться в этих постоянных изменениях, нужно уметь работать с понятием «практики» в мышлении и деятельности, отличать «практики» как методы работы от самих работ, этому и посвящён наш курс.
В изложении не затрагивается праксиология как общая теория деятельности (не раскрываются понятия целей и средств деятельности, блага, полезности, отрицательной стоимости труда и т.д.). В изложении также не даётся нормативная часть методологии, которая на сегодняшний день представлена безмасштабной версией системной инженерии. Это всё должно быть предметом отдельных курсов.
Курс выходит в виде онлайн-курса и книги в издательстве Ridero. Обязательными пререквизитами для понимания в нём сказанного будут прохождение курсов «Онтологика», «Собранность», «Практическое системное мышление» из программы «Бесконечное развитие» Школы системного менеджмента. Сам наш курс будет пререквизитом для курса «Системная инженерия» и «Системный менеджмент». Курс методологии — это курс обучения фундаментальной практике, так что по факту это курс-пререквизит для практически любых прикладных курсов.
В случае курсов по фундаментальным дисциплинам мы рекомендуем проходить наш курс повторно (при первом проходе неизбежны «ссылки вперёд», упоминание понятий, которые будут подробней раскрыты дальше по тексту курса. Повторное прохождение курса делает все эти места много понятней, восприятие материала курса существенно меняется, «читается, как первый раз, вычитывается много нового»). Не забывайте смотреть материалы по ссылкам на литературу, там много интересного. Особое внимание обращайте на задания по моделированию и мышлению письмом. Больше замечаний о том, как устроен курс, можно найти в первой главе курса «Практическое системное мышление», наш курс по факту является его продолжением.
Чтения учебника из курса абсолютно недостаточно для того, чтобы как-то освоить методологическое мышление. Необходимо выполнять упражнения по моделированию, в которых вы должны заполнять таблички. Методологическое мышление в жизни будет ровно вот этим: вы будете создавать и заполнять похожие таблички, превращая их в чеклисты и тем самым отслеживая выполнение работ по каким-то методам этих работ.
Студент после курса методологии должен хорошо различать управление работами и управление жизненным циклом, уметь определять практики и роли, исполняющие эти практики, понимать объекты (альфы в языке OMG Essence), за которыми нужно следить в проекте в ходе его выполнения.
Материал этого курса впервые появился как часть учебника «Системноинженерное мышление» в 2013 году, текущий текст — это его восьмая переписка.
Автор выражает благодарность студентам и преподавателям кафедры технологического предпринимательства МФТИ, где велось начальное преподавание методологии и был получен первый опыт обучения этой фундаментальной дисциплине, членам Русского отделения INCOSE, с которыми велись многочасовые обсуждения содержания курса, сотрудникам, студентам и волонтёрам Школы системного менеджмента, где велась доработка курса в последние несколько лет. Десятки замечаний было представлено читателями блога автора (http://ailev.livejournal.com, трансляции блога есть в телеграме, мордокниге, вконтакте, фрифиде), учтены замечания десятков бета-тестеров. Особая благодарность Роману Варьянко, который оперативно выполнил корректуру текста, не ограничиваясь грамматикой и орфографией, но и делая содержательные замечания.
Ваши замечания и предложения по поводу следующих версий книги/курса давайте в чат поддержки, он организован в телеграме и общий для курса «Практическое системное мышление», нашего курса «Методология» и курса «Системная инженерия»: https://t.me/systemsthinking_course
1. Методология как фундаментальная дисциплина
⠀
Что такое методология
В самых различных словарях и справочниках приводятся довольно путанные сведения о том, что такое методология. Термин довольно древний, первым его использовал Платон, значение его со временем менялось. Более того, определения для методологии, научного метода, философии науки, эпистемологии — все они про одно и то же: способы получения научного знания и о том, каково оно, научное знание. В философских энциклопедиях часто нет статьи по методологии, но есть статьи по методологиям отдельных философов как более-менее связным воззрениям на «метод».
После прагматического поворота в философии значение слова продолжало меняться и познание/исследование/learning перестало быть только моделированием мира, сейчас основное — это многоуровневое (действие на многих системных уровнях одновременно) изменение моделей мира и агента, а также физического мира и агента. Агент/IPU (information-processing unit) при этом мыслится безмасштабно и его разумность тоже может быть совсем разной: у молекулы нет порождающих/generative моделей мира и себя, у кошки их побольше, а команда людей может иметь множество подробных таких моделей (которые необязательно в мозгу, иммунная система тоже содержит такую модель, отличающую «своё» от «чужого», а ещё такие модели могут быть в компьютерах).
Методология тем самым становится безмасштабным учением о деятельности агентов по изменению мира и себя, и эта деятельность включает в себя и деятельность познания как изменение моделей мира и себя.
Подробней это рассматривается в курсе «Практическое системное мышление», там же даются какие-то азы методологии и разъясняются некоторые начальные понятия (роли, агента, практики). Наш курс продолжает этот рассказ, поэтому прохождение «Практического системного мышления» является обязательным пререквизитом к нашему курсу. Помним, что и «Практическое системное мышление» тоже имеет свои пререквизиты и рекомендации (так, его практически нельзя одолеть, если не пройти предварительно курс «Онтологика и коммуникация», а иногда и подготовительные курсы. Общая последовательность курсов изложена в программе «Бесконечное развитие» Школы системного менеджмента).
Слово «методология» может иметь два словарных значения:
• как «учение о методе»,
• как эквивалент слова «метод», это подчёркивается даже в инженерных стандартах.
Так что «методология разработки XYZ» или «метод разработки KLM», а также «ситуационная инженерия методов» как один из методов для самой методологии как учения о методе — так вполне можно говорить, а значения слова нужно выделять по контексту. Это точно такое же использование слова, как в случае «логики» — она тоже может быть учением о разных логиках, а «Аристотелевская логика» — это одна из логик, изучаемых учением о логиках. Или «геометрия» — это учение о разных пространственных объектах в пространствах разных размерностей, а «Евклидова геометрия» — это один из вариантов геометрии, изучаемых учением о геометриях.
Наше понимание методологии как учения о методе/практике/труде/деятельности/инженерии в целом и одновременно отдельных видах методов/практик/труда/деятельности/инженерий базируется на том, что методология — это отдельная полноправная фундаментальная трансдисциплина интеллект-стека. Подробней о том, как методология вписывается в ряд других дисциплин, можно узнать из курса «Образование для образованных».
Мы разделяем понятия
• дисциплины («научного предмета») «методологии» как набора тесно связанных друг с другом понятий и способов рассуждения о них. Это понятия агента/IPU с различными степенями разумности/cognition и способностями к планированию и действию, роли, практики/труда/метода/инженерии и т. д.
• учебного курса «методология» (который вы сейчас проходите), в котором могут объясняться понятия не только методологии, но и других фундаментальных трансдисциплин интеллект-стека (например, затрагиваются дисциплины онтологии и системной инженерии).
Понятия дисциплины «методология» вы начали изучать ещё в курсе «Практическое системное мышление», в котором были затронуты дисциплины физики (само понятие системы оттуда), семантики (различение описаний системы, документации по системе и самой системы — семантический треугольник и его вариации), онтологии (главным образом обсуждение иерархии объектов по отношению часть-целое и обсуждение способа установления того, что объекты с разным описанием представляют собой один и тот же объект), и методологии (роли, практики, агенты/IPU/«исполнители ролей», «системы создания»/создатели). При этом в курсе практического системного мышления понятия методологии используются для рассказа о понятиях системного подхода, которые развивались в самых разных фундаментальных дисциплинах — в заголовке это отражено как «системное мышление», а методология как выход в деятельность/практику/инженерию/труд отражена через один из синонимов — «Практическое системное мышление». Можно было бы назвать и «Методологическое системное мышление», «Трудовое системное мышление», «Деятельное системное мышление».
В нашем курсе методологии для раскрытия основных понятий методологии также будет использован системный подход. Но мы не будем говорить «системная методология» или «практическая/трудовая/деятельностная/деятельная/инженерная методология», это будет как «масло маслянное», ибо одно из определений «метода» — это «все практики/деятельности/„виды труда“/„виды инженерии“, нужные для достижения какого-то результата». «Системная методология» могла бы вызвать путаницу, так как уже есть конкретные варианты/школы методологии, называющиеся очень похоже — «системо-мыследеятельностная методология», СМД-методология. СМД-методология была (активное её развитие остановилось где-то с 1994 года, поэтому «была») довольно близка к излагаемой нами версии мышления о деятельности, но она использует довольно ранние версии системного подхода, а именно «второе поколение», в котором вокруг создаваемых систем появились уже люди, но ещё не рассматривался безмасштабный многоуровневый панпсихизм-физикализм и не проводилась последовательная деантропоморфизация мышления.
В нашей версии дисциплины «методология» мы отличаем её содержание от похожей по именованию «методологии исследований», которую выделяем в отдельную дисциплину интеллект-стека «исследования» — изучение того, как прирастает знание, каким образом мы получаем всё более точное знание. В чём состоит само полученное как результат «исследований» знание и как его дальше использовать (объяснительные теории, которые позволяют делать деятельностный выбор) выделяем в «рациональность».
В нашей версии дисциплины методологии мы изучаем устройство деятельности/практики/инженерии в их наиболее общей форме. Мы рассматриваем её как «истинную дисциплину» (в которой нет указания на то, что нужно делать, но есть указание на то, «как смотреть и что видеть»), в качестве нормативной дисциплины (в которой есть указание на то, что нужно делать) мы могли бы указать на системную инженерию, но в том числе и нормативную экономику, право, социологию.
Методология рассматривает понятия практики/деятельности/«рабочего процесса»/создания/труда/инженерии, агента/создателя/IPU, роли/функции агента, жизненного цикла системы, эволюции/развития, целей и средств.
Есть ещё одно название для методологии как общей теории деятельности — праксиология, и у праксиологии тоже есть самые разные понимания того, в чём предмет этой фундаментальной науки. Например, для праксиологии в варианте австрийской школы экономики предполагались построение на её основе дисциплин экономики, социологии и права, удачным оказался только проект создания самой австрийской экономической школы, совсем чуть-чуть было сделано в области права и практически ничего — в области социологии. Праксиология как методология и её особенности и проблемы затрагиваются в курсе «Системный менеджмент». В «Системном менеджменте» описывается связь менеджмента и экономики, а в части экономики даётся и обосновывается рекомендация изучения экономики в варианте австрийской школы, базирующейся на праксиологии как общей теории деятельности. Наш курс «Методология» не касается праксиологии как общей теории деятельности и исходит из других традиций описания деятельности, которые развивались прежде всего в инженерии и менеджменте на базе системного подхода.
Понятие метода
Метод/практика/труд/деятельность/инженерия/«рабочий процесс»/way of working — это способ, которым будет выполняться работа. Это функциональное определение, единица повторной используемости в работе, паттерн/похожесть в выполнении множества работ.
Метод/практика — это функциональный взгляд на поведение системы-создателя как оргроли/функционального объекта. Работа — конструктивный взгляд на поведение системы-создателя как оргзвена/конструктивного объекта.
Так что метод реализуется работой, которая выполняется ролью, указанной в методе/практике. Но так не говорят, а говорят о применении метода в работе.
В методе/практике/деятельности вполне могут быть шаги во времени, но они даются как относительные, без привязки к конкретным моментам времени, иногда говорят о «логическом времени». Абсолютное время (привязанное к календарю и часам) появляется, когда по данному методу выполняется актуальная работа, как физический процесс (не «рабочий процесс» или «процесс разработки», который чаще всего означает тоже метод/практику/способ работы, а физический процесс как физические изменения, происходящие от взаимодействия каких-то физических/конструктивных объектов в 4D пространстве-времени). Так что тут всё то же самое: как «принц Гамлет»::оргроль появляется в физическом мире, когда его играет/реализует «Вася Пупкин»::оргзвено (а до этого есть только её описание, но принца Гамлета в физическом мире нет), так и «моделирование табличками»::практика появляется в мире только в момент её реализации работой «моделирование в курсе методологии в ходе занятий 23 мартобря 2024». Практика/метод при этом выполняются оргролью «студент», а вот работа — конкретным оргзвеном, играющим роль студента, например, Зинаидой Фёдоровной.
Создатель — это «система создания»/агент/IPU, которая выполняет работу по какому-то методу/практике/деятельности/инженерии, приводящую в конечном итоге по длинной цепочке создания к созданию целевой системы. Метод/практика — это функция орг/деятельностной/трудовой роли создателя/constructor, а работа — это сервис создателя как физического объекта/агента/IPU. Конечно, во взаимодействиях и изменениях в ходе работ задействованы и другие физические объекты — рабочие продукты (расходные материалы, инструменты, оборудование). Но помним (из курса «Практическое системное мышление») о том, что нам удобно использовать понятие создателя, как его определял David Deutsch в constructor theory: это такая система, которая многократно может изменить/transform какие-то другие системы, сохранив при этом себя неизменной. Например, молекула-катализатор. Или станок. Или робот (станок с компьютером). Или человек (который может изготовить пять роботов, оставшись при этом неизменным, или даже изготовить человека, оставшись при этом неизменным!). Или транснациональная корпорация.
Методы обычно дробны. Метод обычно — это какой-то самый верхний уровень деления на практики, этим словом называют все практики, нужные для достижения результата работы. Иногда практику/труд/деятельность/инженерию/«процесс разработки» считают «методом» (то есть включающим все способы ведения работ, которые потребуются для достижения результата работ, всех требуемых изменений), а вот результат разбиения называют «видом» — «вид практики», «вид деятельности», «вид инженерии», «вид труда» и т.д.). Дробность труда/деятельности/метода в части выполнения частей какого-то метода разными агентами часто называют разделением труда, а получение всё новых и новых видов труда называют углублением разделения труда. «Разделение деятельностей» и «углубление разделения деятельностей» уже не говорят, дробность обсуждают традиционно главным образом со словом «труд». Но вполне могут сказать «подпрактика», «рабочий подпроцесс», но не «подтруд» или даже «подметод», «поддеятельность». Избегают говорить про «надметод», говорят просто «метод». Терминология обсуждения разделения труда довольно скудна и ограничена, но сама идея дробности метода, причём возможности дробить метод так, чтобы части его раздавать разным оргролям, в которых потом будут специализироваться разные агенты — это крайне важная идея. Особенно часто идея разделения труда обсуждается экономистами, ибо это даёт возможность каждому работнику специализироваться на отдельных методах работы (профессионализация), а также сдвинуть часть труда с людей на механизмы/станки, что резко увеличивает экономическую эффективность производства.
Скажем, инженерия в целом — это инженерия чего угодно, но есть виды инженерии как отдельные «инженерные практики». Эти «инженерные практики» — «масло масляное»: можно сказать инженерные практики, практические практики, трудовые практики, деятельностные практики, практические деятельности, инженерные деятельности, инженерная инженерия и т. д. Бытовой язык богат, имеется в виду одно и то же, причём один термин дублирует другой «на всякий случай», показывает разные оттенки смысла. Но нам в нашем курсе эти оттенки смысла не слишком важны. Наша задача — определить как-то используемое в методологии понятие и дать ему какое-то имя, чтобы мы могли его обсудить. А уж как оно называется в бытовой речи на самых разных естественных языках — дело десятое. Как удобно, так и называйте, но не путайте в голове оргроли и оргзвенья, практики и реализующие их работы, функции и реализующие их сервисы. Функциональный и конструктивный миры различны, про функциональный мир думаем в момент эксплуатации/функционирования целевой системы, про конструктивный мир думаем во время создания целевой системы, то есть во время эксплуатации/функционирования создателя.
Понятие практики контринтуитивно, люди очень плохо осознают, что любая их работа (включая любую работу коллектива людей, впрочем, и любую работу станка) выполняется каким-то способом. Нетренированные в методологии люди не могут отдельно обсуждать работу и отдельно способ этой работы, для этого нужно специальное обучение методологии. Наш курс ровно этому обучению и посвящён: чтобы при взгляде на работающего человека вы всегда задавались вопросом — можно ли получить результат другим, более эффективным методом, можно ли задействовать преимущества разделения труда.
Описание/view метода (идеальный объект!) называется методикой. Документация методики (рабочий продукт, физический объект!) может называться методичкой. Конечно, для этих понятий есть десятки синонимов: можете встретить BoK (Body of Knowledge), можете встретить «регламент», можете встретить «модель жизненного цикла», «инструкцию», «описание рабочего процесса». В каждой предметной области, на каждом предприятии может быть свой термин для описания метода (view) и для метода описания (viewpoint) описания метода/практики/труда/инженерии/деятельности.
Зачем изучать методологию
Задача нашего курса в том, чтобы вы могли свободно оперировать с методом/практикой/деятельностью/трудом как объектом первого класса. После курса вы должны понимать, как описывать практику, как дробить практику (в том числе как проводить разделение труда), как описывать разбиение/breakdown практик. И вы должны это уметь делать в самых разных рабочих проектах, независимо от тех практик, которые вам будут в них встречаться: одно и тоже рассуждение вы должны будете проводить и про практики танцев (деятельность танцоров), и про практики изготовления космических ракет (деятельность ракетостроителей), несмотря на всё содержательное различие самых практик.
Аргументы против изучения методологии:
• Не надо знать про существование методологии. Если говоришь прозой, то знать, что это «проза» необязательно. Если говоришь стихами, то знать про существование гекзаметра необязательно: это всё для особых любителей. Были бы тексты хорошими, а остальное не нужно. Рыбке нужно плавать, знание про то, что она плавает в воде, излишне. Если верить этому аргументу, то невозможно улучшить свою деятельность и обсудить чужую: для этого не будет правильных объектов внимания, начиная с самой «деятельности» (которая может не назваться никак, способ работ может «подразумеваться» и даже не будет прокритикован или выбран альтернативный, могут быть перепутаны практики и работы, что не позволит обсуждать проведение работ альтернативными методами, то есть не позволит быть эффективным и результативным).
• Методология нужна только методологам. Производственникам она не нужна, а если уж кому приспичит (в какой-нибудь «службе качества», где проверяющие потребуют очередной «список методов» или «список процессов») — то и без обучения разберутся, все эти «службы качества» аналитические по принципу, никакого качества они на-гора не выдают, а просто готовят какие-то описания для разных проверяющих да инвентаризующих. Учить этих людей можно, но необязательно: свои пухленькие стандарты они и без «методологии» прочтут. Если верить этому аргументу, то «методолог» — это не роль человека, который рассуждает о методе, а должность. Нет, «пловец» — это не только спортсмен, который плавает где-то на соревнованиях как член команды пловцов, это любой человек, которому нужно проплыть из точки А по воде в точку Б, и нет ни лодки, ни спасательного круга. И дальше выбор — плыть топориком, по-собачьи, кролем или брассом. Неплохо бы знать при этом различия этих стилей. Вот и с методологией так же: если обсуждать «как будем работать», то неплохо бы знать, на какие объекты в мире обращать внимание. Нужно знать типы мета-мета-модели «из учебника», чтобы обсуждать затем организацию работы в проекте.
• Никто нигде никогда этому специально в вузах или на производстве не учит, вот и мы не будем. Если верить этому аргументу, то «методологиям разработки», «методологиям инженерной работы» люди как-то учатся сами, не специально. Это означает, что они наверняка в разработке забудут о чём-то важном (ибо не знают явно, что в разработке важно), а неважное сделают вообще неправильно (ибо вопрос «как надо что-то делать», «каким способом работаем» будет обсуждаться непрофессионально).
Аргументы за изучение методологии:
• Методология позволяет отмоделировать метод/способ/приёмы труда/деятельности/инженерии: невидимое сделать видимым. После появления модели метода работы можно обсуждать и улучшать этот метод, осознанно меняя составляющие его практики и поддерживая коллективное обсуждение/мышление о методе.
• Большинство людей, которые явно занялись методологией в инженерных и менеджерских проектах, были поставлены перед задачей научить какую-то новую команду работать каким-то методом, которым они владели неосознанно. Они не знали, чему именно нужно учить людей: «что такое метод», как о нём рассказывать. Такая задача (научить новому способу работы/way of working какую-то команду, адаптировав этот способ работы к новым условиям) появляется перед людьми чаще, чем можно подумать. Задача переноса и адаптации практик/метода/деятельности появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии как таковой, а не только по конкретной технологии/методу/практике. Выучить один раз (наш курс!), а потом использовать во всех проектах.
• Если «простой практик/деятель» (инженер-конструктор, менеджер, врач, политик и т.д.) не осваивает постоянно новые методы/практики, то он порастает мхом, его работа обесценивается, он становится неконкурентоспособен. Чтобы он мог эффективно обновлять свои знания, ему нужно уметь сравнить два метода: его собственный и новый, и принять решение о том, какой из них SoTA. Для сравнения методов надо понимать, какие объекты внимания есть в методе и как их можно сравнивать.
Приложения методологии уже начинают изучать и на производстве, и в вузах, и не только неявно (то есть знакомством с разными Body of Knowledge как формой представления знаний о методах работы и неявным пониманием, что они по большому счёту устроены все примерно одинаково), но и явно через изучение методологических стандартов (обычно посвящённых какой-то записи способа работы, это OMG Essence, уже упоминавшийся ISO 24774:2014 и многие другие, обычно применяющиеся для описания «рабочих процессов», «процессов разработки», «видов жизненного цикла»). Эти стандарты стремительно отстают от жизни, и нужно иметь более общее знание о том, как устроены такие стандарты, чтобы замечать отставание и не следовать таким стандартам слепо.
Инженерия как нормативная наука основана на методологии. Если уж изучать инженерию, то придётся говорить о практиках и выполняющих их ролях, жизненном цикле системы или её фичи, развитии систем, а это и есть содержание методологии. Так что изучать методологию всё равно придётся, если планируется изучать инженерию.
Методология и системное мышление
Современная методология использует системный подход для описания способов работы создателей/агентов в цепочках создания каких-то систем. В том числе современная методология учитывает, что обычно речь идёт о каких-то командах агентов и коллективах (командах команд) агентов — то есть речь идёт об организациях агентов. Агенты из всего множества IPU выделяются как способные осознать себя и окружение и спроектировать изменения в своих моделях себя и окружения, а также себя и окружения, а также запланировать и провести действия по этим изменениям. Это довольно большой спектр систем, микробы тут вряд ли будут подходить под «агентов», кошки — в малой степени, а вот люди и тем более «люди с компьютерами»/cyborgs или даже «компьютеры с людьми в их составе»/hybrots как оргзвенья — вполне подходят. И когда мы говорим об агентах, мы чаще всего будем представлять не просто систему-агента, но агента-создателя.
Безмасштабная методология готова обсуждать и то, каким образом создателями могут выступать сообщества, общества и человечество (в них нет «поручений работ»), но это пока проработано крайне слабо — уже понятно, что для продуктивного создания комфортной/малорисковой среды обитания подходит рыночная экономика и нужно вводить понятия собственности (включая собственность на собственное тело, но и на рабочие продукты) и свободы обмена результатами труда, выходить на праксиологию. Вот, например, праксиология в варианте Murray Rothbard от 1951 года (и нельзя сказать, чтобы человечество сильно продвинулось в построении праксиологии):
⠀⠀
1. Теория изолированного агента (экономика Робинзона
Крузо)
2. Теория добровольного межличностного обмена
(каталлактика, или рыночная экономика)
⠀⠀⠀2.1. Бартер
⠀⠀⠀2.2. Со средствами для обмена
⠀⠀⠀⠀⠀⠀2.2.1. Свободный рынок
⠀⠀⠀⠀⠀⠀2.2.2. Эффекты насильственного вмешательства
⠀⠀⠀⠀⠀⠀в рынок
⠀⠀⠀⠀⠀⠀2.2.3. Эффекты насильственного запрета рынка
⠀⠀⠀⠀⠀⠀ (социализм)
3. Теория войны — враждебная деятельность
4. Теория игр (например, работы von Neumann
and Morgenstern)
5. Неизвестное
⠀
⠀
Как при этом должны быть устроены сообщества, общества и человечество в целом политически и как там должно быть устроено право, основанное на праксиологии как общей теории деятельности — это большой вопрос. Наш курс методологии не будет касаться в текущей версии практик/деятельности/труда сообществ, обществ и человечества, равно как будет мало говорить о «методе работы станка» или «методе работы робота», хотя в этом случае всё будет проще и понятней, разве что станок и робот не могут принимать решений о методе своей работы, это за них делают люди и организации людей, в состав которых входят и станки, и роботы. Но сейчас с развитием машинного интеллекта возможен и другой вариант рассмотрения: какой-нибудь отдел может быть представлен как компьютер, в состав которого входят люди — и по мере развития постепенно люди замещаются компьютерами, это и есть тренд «автоматизация всего», концепция киборга (cybernetic organism) как образа агента будущего заменяется концепцией гиброта (hybrot — hybrid robot).
Само содержание нашего курса методологии связано с тем, что мы рассматриваем проекты создания систем, которые выполняются создателями этих систем. Так что последующие главы можно рассматривать как продолжение курса практического системного мышления. В понятия системного подхода второго поколения включают и понятие «жизненный цикл» как проводимые создателями работы, а с появлением третьего поколения системного подхода и понятие развития как происходящее в ходе эволюции. Мы рассматриваем эти понятия в рамках курса методологии, а не курса системного мышления.
2. Создание и развитие: не жизненный, не цикл
Биологический жизненный цикл
Поскольку системный подход поначалу развивался на примерах сложных биологических систем, то часть его терминологии осталась с тех времён. Учёные-биологи хотели найти подходы к обсуждению таких сложных объектов, как заливной луг со всеми его взаимосвязанными сотнями видов растений, животных и сменой времён года — а слов для этого обсуждения не было. Они эти слова придумали, например «жизненный цикл». Вот жизненный цикл печёночного сосальщика:
Этот паразитический плоский червь проводит свою жизнь в разных состояниях (яйца, личинки, цисты, взрослого червя), проходя метаморфозы (полную перестройку своей внутренней структуры) за время своей жизни. При этом никто не придумывает и не проектирует систему-червя, нет такой стадии в жизненном цикле. Это сделала эволюция, она безлична и бесцельна. Никто также не изготавливает систему червя, полностью документированную в его ДНК: все эти стадии изготовления происходят без вмешательства человека, это и есть жизнь. А ещё всё повторяется, начиная с яиц червя.
В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так:
• целевые системы сами не растут и не проходят метаморфозы, их придумывают, проектируют, изготавливают, эксплуатируют, модернизируют, выводят из эксплуатации системы создания, то есть люди с их средствами производства. Это означает, что в самих системах никакой жизни нет, жизненный цикл оказывается не жизненным, системы создания ведут целевую систему по её циклу, а не она сама продвигается по своим состояниям.
• Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.
Жизненный цикл оказался для неживых систем не жизненным и не циклом, но сам термин остался, причём он постепенно менял своё значение. Проблема в том, что многие из этих «исторических» значений используются до сих пор, наряду с современными значениями, и это создаёт путаницу при обсуждении проектов по созданию и модернизации самых разных систем.
Более того, даже для живых систем (бактерии в биореакторе, стадо коров на ферме, поле генно-модифицированной пшеницы, гектар леса) также применяется мышление про создателя (биоинженера, фермера, агронома, лесника) и его целевую систему и то, как создатель создаёт свою целевую систему. Никто сегодня не предполагает, что есть жизненный цикл коровы, который она проходит самостоятельно без фермера, поколение за поколением живя в лесу. И лес — за ним присматривает лесник, если мы изменяем лес к лучшему.
Жизненный цикл по факту означает происходящее с одним организмом, то есть не включает обсуждение мутаций. Если включить в рассмотрение другой масштаб времени, эволюции, на котором обезьяны превратились в людей, а динозавры в птиц, то это уже не будут называть «жизненным циклом», а назовут эволюцией/развитием. Техно-эволюция/техно-развитие носит другую природу, нежели дарвиновская эволюция: основные знания об устройстве как целевой системы, так и создателя находятся не в самих этих системах (геном: совокупность наследственного материала), а в системах-создателях (мемом: совокупность материала с «проектной документацией», хотя тут тоже можно делить дальше на меметическую эволюцию человеческой культуры, где мемом хранится в книгах, мозгах и материальной культуре в форме «шаблонов вещей», и техническую эволюцию, где мемом именно в проектной документации, текстах технических стандартов, учебников инженерии). Мы редко будем рассматривать развитие живых систем в ходе дарвиновской эволюции, но часто будем рассматривать развитие систем в ходе техно-эволюции. Поэтому мы будем сокращать: не говорить «техно-развитие», а говорить просто «развитие», но в случае эволюции мы всё-таки будем частный случай техно-эволюции на основе проектируемого мемома называть именно техно-эволюцией, чтобы не путать её с дарвиновской биологической эволюцией на основе мутирующего генома.
Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы
Поначалу жизненный цикл (life cycle) просто обозначал отрезок времени, во время которого происходили проводимые системами создания работы с целевой системой, при этом по аналогии с биологическим циклом последовательно проходящие работы относили к разным стадиям (stages), иногда называемым фазами (phase) жизненного цикла — отрезкам времени, в которых система была в каком-то состоянии. Никакой эволюции, никаких гипотез, только выполнение требований. Хотя прототипы могли рассматриваться, но это были «последовательные приближения к окончательному варианту», никакого «бесконечного развития», «непрерывного всего», а «достижение цели»: результата работ.
Жизненным циклом чайника называли отрезок времени, в течение которого с ним проводились работы (чайник ведь сам себя не сделает, это не биология — все работы с ним должны провести какие-то внешние по отношению к нему системы создания). Эти системы создания должны решить сделать чайник (а не кофейник), задокументировать требования, затем (последовательность важна! Сначала требования, потом проектирование — это будут «стадии») запроектировать чайник (выбрать внешний вид и материалы), сделать чайник (согласно проекту закупить материалы и изготовить), затем использовать для заварки чая (эксплуатировать), затем разбить и выкинуть. Вот всё это время прохождения работ создателя с чайником как целевой системой и называли «жизненным циклом»::«отрезок времени», а сами работы в их самом верхнеуровневом разбиении: принятие решения о чайнике, проектирование чайника, изготовление чайника, эксплуатацию чайника, ликвидацию чайника называли «стадиями/фазами жизненного цикла»::работы. Обратите внимание на разницу в типах объектов: жизненный цикл — это отрезок времени (измеряется в часах), а стадии — это работы, когда кто-то что-то с чем-то делает, меняет мир. Работы — это динамический объект/изменение/поведение, а не отрезок времени существования этого объекта, то есть отрезок времени, пока идут изменения. Жизненный цикл был «двадцать лет», делился на «сформулировать требования к забору», «спроектировать забор», «построить забор» (и вот уже прошло два года), «следить, чтобы забор был в рабочем состоянии» (восемнадцать лет), «разобрать забор и выкинуть строительный мусор» (последние две недели из двадцати лет жизненного цикла).
Назовём это понимание «жизненным циклом v1.0», оно разрабатывалось где-то в 70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте, который в те времена считался более-менее «психологической» особой дисциплиной, а не просто изводом системной инженерии для организационных систем. В системном подходе уже тогда признавали непосредственно выходящими из него не только системную инженерию, но и operations research/исследование операций — исследование работ/operations с целью принятия лучших решений по ускорению их прохождения. Исследование операций скоро перестало быть «аналитикой», то есть только исследованиями, и в его синтетической/управленческой ипостаси стало operations management (операционное управление, акцент не только на понимании и отчётах, но и на действиях на основе этих исследований — собственно управлении, изменении ситуации в части ускорения прохождения потока работ через производящие эти работы ресурсы).
Дальше это направление управления работами/операционное управление/операционный менеджмент на базе каких-то представлений тогдашнего системного подхода развилось в классическое проектное управление/project management, как его понимают сегодня в менеджменте (хотя к нему кроме собственно управления операциями добавилась сегодня ещё и организация команды проекта, это подробней объясняется в курсе системного менеджмента). Мы же считаем операционный менеджмент эксплуатационной (то есть происходящей с уже созданной системой) инженерией организационной системы.
Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner «Project Management: A Systems Approach to Planning, Scheduling, and Controlling». То есть управление проектами в момент его появления было применением системного подхода к планированию, построению графика работ и контролю выполнения работ. Это похоже на то, как понималась в те времена и классическая «железная» системная инженерия: применение системного подхода к инженерной работе.
Конечно, использование системного подхода в менеджменте не ограничивается сегодня только операционным управлением. По сути, весь менеджмент как специализация системной инженерии для создания и развития организаций строится на базе системного подхода.
Понятие жизненного цикла 1.0 как времени производства работ создателя с создаваемой целевой системой (о цепочках создания речь не заходила) активно разрабатывалось и в системной инженерии, и в проектном управлении для принятия решений о планировании и составлении графика работ.
Работы — это конкретные процессы, в которых участвуют ресурсы для этих работ. Анастасия забивает гвозди молотком в доски. Забивание гвоздей — это и есть работа, которую она выполняет. Работы чаще всего называются не по их цели, а по их текущему содержанию — не «скрепление досок», что может предполагать и клеевое соединение, и гвоздевое, а именно «забивание гвоздей», хотя тут есть множество и других вариантов. Но в целом работы оказывались сеансами сервиса систем-создателей как провайдеров сервиса (помним онтологию сервиса из «Практической системной инженерии»). Эти сеансы сервиса, рассматриваемые как работы, совсем уже теряли специфику: это просто было поведение каких-то ресурсов, участвующих/participate в работе::поведение/изменение.
Анастасия с её молотком в роли плотника как оргзвено, материальные и наличные гвозди, молоток и доски — ресурсы, без доступности которых выполнение работы/сервиса оргзвена Анастасии невозможно.
Для планирования работ обычно составляется план, в котором прописываются ответственные за выполнение работ (собственники ресурсов — если не собственники, то выполнение работ будет проблематичным), и время, за которое эти работы должны быть сделаны (проектное управление имеет дело с нормированными работами — т.е. работами, для которых накоплено достаточно статистики, чтобы понимать их время выполнения при наличных ресурсах. Например, это строительные работы и нормы выкладки кирпича, заливки бетона и т.д.). То есть работы — это экземпляры выполнения сервисов оргзвеньев, поведение по изменению состояния каких-то систем в окружении провайдеров сервиса (время создания для изменяемых в ходе сеансов сервиса/работы систем, момент эксплуатации/использования для создателей).
За забивку гвоздей у нас ответственна Анастасия в должности «плотник» (не путать с оргролью «плотник»), и обычно она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3 мартобря 2029 года, и планируемая её продолжительность — десять минут. За это время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места на досках.
Работы легко наблюдать: это просто взаимодействующие между собой ресурсы (включаемые в работу по отношению участия/participation, это такая специализация отношения composition/состава/is_part_of/часть-целое), но взятые не только как объёмы в пространстве, но и протяжённые во времени. Так, работа «забивка гвоздя» состоит из взятых на интервале 30 секунд молотка, гвоздя, доски и забивающего их работника. Их нужно собрать вместе на эти 30 секунд, чтобы произошла эта 30-секундная работа.
Обсуждение работ обычно является предметом операционного менеджмента и затрагивает логистический предмет интереса: времени прохождения потока работ. Интересует тут не столько содержание работы (это обсуждается как метод/практика/способ работы/way of working), а как задействовать для этой работы имеющиеся ресурсы, чтобы получить оптимальное время прохождения потока работ (не всегда минимальное, ибо иногда важней равномерность задействования ресурсов, чем именно минимальное время выполнения, требующее обычно очень неравномерной загрузки ресурсов). В операционном менеджменте интересуются фактами работы в отрыве от способов работы. Область интересов операционного менеджмента включает такие важные характеристики, как время согласования выделения ресурсов на работы, время задействования ресурсов на работы, цены задействования этих ресурсов (неважно, как и что они делают, с этим разбираются в других практиках другие трудовые роли, операционному менеджеру важно только сколько ресурсы работают и сколько они будут стоить), и времени самой работы без погружения в способы её выполнения. Жизненный цикл 1.0 как последовательность крупных работ-стадий тем самым отражает модульное/конструктивное/продуктное представление о работах систем создания. Проект — это работы оргзвена как группы организованных (то есть с понятными полномочиями по распоряжению трудом, материалами и прочими ресурсами) агентов биологических и не очень, с каким-то оборудованием и материалами, полномочиями по проведению работ (то есть проект — это даже не работы оргзвена, а работы оргвозможности/capability). Проект имеет целью его работ (хотя тут более корректно говорить о цели оргзвена или даже оргвозможности, «цель работ» тут — метонимия) создание и развитие какой-то системы. Дальше мы будем считать, что если речь идёт об оргзвене, то оно уже достигло состояния оргвозможности — все умения, ресурсы и полномочия по распоряжению ими оргзвеном уже получены.
Терминологически проект иногда означает работы оргзвена проекта (рабочей группы проекта, проектной организации — терминология тут самая разная), а иногда и само оргзвено, то есть проект как организация проекта. В жизни встречаются оба значения термина, и надо их как-то различать: путать рабочую группу проекта (чаще всего она меняется медленно) и работы этой группы (которые легко будут перепланированы) не стоит. «Проект изменил цвет забора с красного на синий» можно понимать и как «работы изменили цвет забора» и как «команда изменила своими работами цвет забора», так что просто надо быть внимательными к контексту — иногда эти онтологические различия неважны, иногда важны. Но вот письмо работам направить нельзя, а письмо команде — можно. Поэтому «я написал проекту письмо» — тут уже будет онтологический дребезг.
Мы в курсе будем тоже использовать оба значения, но чаще проектом мы будем считать оргзвено со всеми приданными ему ресурсами и полномочиями (то есть оргвозможность). Проект::организация в этом понимании ведёт работы, и «создать проект», «организовать проект» — это означает создать организацию, которая будет дальше выполнять работы проекта как сервисы этой организации.
Чтобы собрать какую-то нужную нам (целевую, думаем о времени эксплуатации/использования) конструкцию из досок, нам нужно создать проект/project/создателя::оргзвено. Этот проект (создатель, думаем о времени создания конструкции из досок как целевой системы) состоит из модулей Анастасии-с-ответственностью, молотка, 20 гвоздей, четырёх досок. Нам нужно ещё запланировать эти все ресурсы на 20 минут, иначе работы не случится. Это всё менеджерские работы: проекты создают менеджеры (создатели организаций).
Нам нужно всё это откуда-то взять, а результат работы (скреплённые доски) куда-то отдать — тоже задача не инженерная, а менеджерская (логистическая, т.е. на перемещение ресурсов от одного места их обработки к другому). Операционного менеджера (роль, выполняющая практику/труд операционного менеджмента) интересует только логистика, «как собрать работу из её частей-вещей/ресурсов». Не интересует «каким способом происходит работа, почему она даст результат», как вообще нужно забивать гвозди, и почему нужно скреплять доски гвоздями, а не склеивать их, или вообще приматывать их друг ко другу верёвками, и не интересует, как сделать гвоздевое соединение прочным. А раз так, то по работам бесполезно обсуждать, как же именно эти работы в их взаимодействии будут двигать систему по её состояниям в жизненном цикле. Обсуждение работ не связано с функциональностью/ролями этих работ, оно связано с планированием ресурсов и контролем выполнения плана: минимизацией времени прохождения потока работ, это типовое предпочтение операционного менеджера. Для обсуждения «как работать» нужно обсуждать не работы, а практики!
Обратите внимание, что по факту жизненный цикл ничего не говорит о целевой системе и её состояниях. Он говорит про то, что делают системы создания: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «истории болезни», case file — это папка «Дело №__»). В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) — это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс будет назван по его предмету — «гвоздь» (предмет этих работ). Описывает это вариант операционного менеджмента, известный как case management в его разных вариантах, например adaptive/dynamic/advanced case management, который в последнее время перестал быть в силу общей распространённости отдельной компактно излагаемой дисциплиной, а поддержка со стороны программного обеспечения перешла в системы с облегчённым программированием, универсальные моделеры, LowCode). Очень часто «проектом» называют и более-менее крупный кейс. Значение слова «проект» окончательно оторвалось от классического «проектного управления».
Это только в биологическом жизненном цикле в дикой природе любое яйцо или гусеница создают сами себя! Помним, что создателями/«системами создания»/«enabling systems»/constructors в системном мышлении называют не системы, которые делают снабжение/заправку/подкормку в ходе эксплуатации (это обычно делает окружение, системы времени эксплуатации), а системы, которые во время создания, модификации и ликвидации системы ведут/двигают её по жизненному циклу, а затем повторяют это много раз в ходе развития/эволюции системы.
Методология использует системное мышление и смотрит на такие системы создания, как проекты/оргзвенья/предприятия/команды/коллективы/организации, точно так же, как смотрит на любые другие системы:
• Как на функциональные объекты, и видит их как набор оргролей, которые выполняют практики/работают по методу.
• Как на конструктивные объекты, и видит их как оргзвенья, в ходе их использования «выполняющие работы»/«предоставляющие сервис» (а уж по какому методу там работает этот конструктивный объект — дело десятое. Конструктивное представление стремится абстрагироваться от метода получения результата работы).
Рассуждения про то, что создателями могут быть сообщества, общества и человечество пока формулируются не так строго. Так что мы в последующих главах ограничимся создателями-людьми и их организованными (понятно кто распоряжается трудом и другими ресурсами) группами, то есть создателями-организациями/оргзвеньями. И не забывайте, что в связи с развитием машинного/искусственного интеллекта (AI) и появлением безмасштабного мышления на фоне тренда тотальной автоматизации появляется ещё и альтернативное понимание: оргзвенья представляются «полуавтоматом», то есть компьютером (возможно, с датчиками и исполнительными устройствами), который обслуживается людьми. Это всё симметричное представление — человек и компьютер, которые вместе выполняют сервис S на интерфейсе I могут рассматриваться как «станок и его оператор», а могут рассматриваться и как «оператор с его станком».
Конечно, формально создателем/системой создания может быть и не оргзвено, а только его часть — станок, обрабатывающий деталь целевой системы. Но если этот станок будет плохо работать для вашей детали, вы тут же вспомните, что этот станок входит в состав оргзвена: уговаривать сам станок и требовать от него переделки детали вы не будете, вы просто найдёте тех людей, кто полномочен распоряжаться этим станком, и будете разбираться с ними. Если речь идёт о системах создания, то мы ни на секунду не забываем, что главное в них — люди, и работы выполняют люди, а хоть и с помощью технологий (оборудования, материалов). Экземпляры сервисов, выполняемых оргзвеньями — это и есть работы. Симметрично, если мы обсуждаем «оргзвено из людей» — надо помнить, что люди никогда не работают голыми руками, а в последнее время и «голой головой», поэтому забыть включить в состав оргзвена станок — это большая ошибка. Общее правило тут простое: если думаешь про людей, не забудь про их станки, если думаешь про станки — не забудь про людей. В этом плане современное производство — это всегда «полуавтомат», но тренд в нём — повышать уровень автоматизации.
Итак, Анастасия, предоставляющая сервис забивки гвоздей, берёт свой молоток и забивает выданный ей гвоздь №143 в доску #26, то есть выполняет работу. Жизненный цикл гвоздя в представлениях прошлого века (первое поколение, 1.0) состоит уже не из состояний гвоздя («лежит в коробке», «взят в руки», «нацелен», «забивается», «забит»), а происходящих с ним работ, которые, конечно, можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем создания, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном не цикле принят аналог «аристотелевской физики», где палец давит на стол, а стол не давит на палец. Работают системы создания, а гвоздь в ответ не работает, он пассивный объект для систем создания, он просто меняет состояния по мере выполнения с ним работ. И системное мышление даже в этой первой версии представления жизненного цикла как цепочки работ отслеживает, чтобы речь шла о полном жизненном цикле, а не только его кусочке в моменте нанесения по гвоздю ударов Анастасией. Работы самой Анастасии — это только часть работ! Вот примерный жизненный цикл гвоздя как стадии/работы (это же — «кейс гвоздя», только он будет рассказываться как «прохождение гвоздём состояний», а практики работ по переводу гвоздя из состояния в состояние будут подбираться, исходя из ситуации):
• Обнаружение потребности в гвоздевом соединении (гвоздь запланирован — но так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE2, это хорошая практика именования. Помним, что «большой кейс называют проектом», а уж связь кейс-менеджмента и проектного менеджмента будет рассказана подробней в курсе «Системный менеджмент»).
• Закупка (или гвоздь закуплен — помним, что в жизненном цикле 1.0 волнуют работы, а не состояния гвоздя! Состояния гвоздя волнуют тогда, когда обсуждаем целевую систему и прохождение ей различных состояний в ходе жизненного цикла — то есть прохождение различных состояний в ходе работ с целевой системой. Состояние «гвоздь закуплен» тут указывает на результат выполнения сервиса по закупке гвоздя, а работа с гвоздём — «закупка», её и указывали, и даже слово «гвоздь» забывали указать, сокращали даже «закупка гвоздя» до просто «закупка». Менеджеры любят обобщать, когда пишут о работах, их не волнует содержание работы и специфика этой работы).
• Выдача в монтаж (или гвоздь доступен в месте забивки — указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).
• Нацеливание гвоздя (гвоздь нацелен).
• Вколачивание гвоздя (гвоздь вбит).
• Проверка крепости соединения («гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем).
• Эксплуатация соединения (соединение держит и стабильно при нагрузках)
• Вытаскивание гвоздя (гвоздь вытащен).
• Ликвидация гвоздя (гвоздь выкинут — жизненный цикл всегда идёт до исчезновения объекта работ).
Жизненный цикл — это всегда, даже в первых его версиях, работы создателей от появления идеи целевой системы до уничтожения целевой системы (включая эксплуатацию: мы считаем, что её тоже ведут создатели, хотя в момент эксплуатации система уже создана. И ликвидация/вывод из эксплуатации ведётся создателями, хотя это обратное созданию действие). Дальше к жизненному циклу в момент появления третьего поколения системного подхода с его временем эволюции/развития добавляют ещё и развитие. То есть в ходе развития проходит множество жизненных циклов систем и отдельных фич этих систем.
Методология удерживает внимание участников проекта/создателей не только на текущих операциях с целевой системой, но на всех от момента появления идеи, до уничтожения системы, а также на множестве этих операций в ходе развития/эволюции системы, а не только однократного замысливания-проектирования-изготовления-использования-ликвидации. Всегда удерживаем во внимании команды или даже коллектива (команды команд) проекта то, что было с целевой системой раньше, что происходит сейчас, что будет происходить потом, а также удерживаем во внимании создателей (команды или коллектива) то, что происходит с самими создателями в цепочке создания, и не ограничиваемся одной версией системы, помним о развитии.
Выполнение работ оргзвеньями
Ведение жизненного цикла (принудительное изменение снаружи целевой системы её состояний в ходе её замысливания, создания, эксплуатации, ликвидации, т.е. «жизни неживого») делается оргзвеньями — людьми с материалами и оборудованием, находящимися в распоряжении этих организованных людей. Чаще всего оргзвенья сами не инициируют работы. В коллективной деятельности одни оргзвенья имеют полномочия просить сделать работу у других оргзвеньев, у которых есть обязанности такие просьбы выполнять — это и есть организация. Если вы попросите в пиццерии пиццу, то вам выполнят работы по её приготовлению — и это само по себе факт замечательный. Попробуйте попросить в пиццерии приготовить вам летние босоножки, и посмотрите, что будет после этой просьбы.
Организовывание сотрудничества в части выполнения просьб о работе и есть предмет одной из практик системного менеджмента: практики оргразвития/organizational development/организационного управления/organizational management (подпрактики оргпроектирования и лидерства): кто кого (оргзвенья) о чём (работы/сервисы) имеет право попросить так, что просьбы вызывают их выполнение, а не удивление, вопросы и сопротивление вместо сотрудничества.
Речь тут продолжает идти не о том, как и почему выполняются работы с содержательной точки зрения (то есть системах создания как функциональных частях), а о логистике работ: как сделать так, чтобы кто-то как ресурс эту работу выполнил (сервисах систем создания как конструктивных частях/модулях/оргзвеньях). Системное мышление позволяет рассуждать про системы создания и системы окружения целевой системы с использованием одних и тех же понятий. Понятия/типы, организующие внимание в мышлении для всех видов систем (целевых, окружения, создателей в цепочках) одни и те же, хотя терминология/слова для этих понятий могут различаться. В этой компактности сила фундаментальных дисциплин, в том числе методологии, обсуждающей способы работ по созданию систем.
Каждая работа проходит следующий цикл взаимодействия оргзвеньев (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO и курсе «Системный менеджмент»):
• Работа затребована оргзвеном-инициатором, часто в виде её появления в каком-то плане (с заданной последовательностью выполнения работ, а если план-график, то и указанными сроками выполнения) или бэклоге (backlog, набор работ к выполнению — но без указания строгой последовательности их выполнения, в том числе сроков): координационный акт, речь идёт об информационном мире поручений-согласований-обещаний оргзвеньев, но не о реальной физической работе по изменению мира или даже работе по изменению описаний системы.
• Работа принята оргзвеном-исполнителем к исполнению, это тоже координационный акт.
• Работа выполняется оргзвеном-исполнителем. Это производственный акт (production act), реальное выполнение работы. Именно это учитывается в жизненном цикле целевой системы, над которой выполняется работа. В жизненном цикле обсуждаются только производственные акты, а не координационные акты! Учёт координационных актов и требуемых на них трат ресурсов и задержек времени на «согласование» и «выдачу поручения» (иногда нужно год интенсивно работать, чтобы получить разрешение на пятиминутную реальную работу) ещё ждёт адекватного отражения в методологии. Пока же это рассматривается в дисциплине рациональности как «рациональное принятие решений» на базе теории принятия решений.
• Работа предъявлена к приёмке оргзвеном-исполнителем, это координационный акт.
• Работа принята оргзвеном-инициатором работы, координационный акт.
Деление на координационные и производственные акты важно, чтобы делать правильные оценки времени: от момента затребования работы до момента принятия работы на координационные акты легко может уходить до 60% времени, и только 40% времени на проведение самой работы, в случае знаниевых работ это может быть и 80% на 20% в среднем (ибо работы по «обоснованиям решений» очень трудоёмки сами по себе). Поэтому жизненный цикл гвоздя может занимать в разы больше времени, чем время выполнения самих работ, затрагивающих физический гвоздь, как производственных актов. Трудность в осуществлении координационных актов (решений о проведении работ, при этом нужно понимать, что принятие этих решений требует не только коллективной чисто мыслительной/вычислительной работы, но и каких-то действий, экспериментов, получения дополнительной информации — то есть траты ресурсов) часто называют в организациях «отсутствие политической воли»: все материальные возможности для ведения работ есть, но работы не ведутся, ибо решения об их проведении полномочными оргзвеньями не принимаются! Иногда это и впрямь не хватает собранности, иногда это нежелание вкладывать ресурсы в условиях жесточайшей неопределённости, а снятие неопределённости может тоже требовать ресурсов, которые тоже не будет «политической воли» вкладывать!
Как планировать работы — по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами (проектного управления, управления процессами, управления программами, управления кейсами) отвечают на этот вопрос по-разному. Управление работами как раз занимается планированием работ и контролем выполнения работ как единиц поведения оргмодулей/ оргзвеньев/конструктивных оргединиц — без обсуждения того, как правильно выполнять работы так, чтобы они меняли целевую систему в нужном направлении (т.е. без обсуждения оргролей и их функций/практик жизненного цикла).
В предметах интереса управления работой нет функциональности происходящих с системой действий жизненного цикла, то есть в управлении работой не рассматриваются функции систем создания, системы создания не рассматриваются как оргроли/функциональные части, выполняющие практики с каким-то назначением, но только как конструктивные части-ресурсы, которые не важно что по содержанию делают, но важен факт их наличия или отсутствия в нужном месте в нужное время для выполнения работы.
Оргзвенья играют оргроли, оргроли реализуются оргзвеньями (функциональные объекты реализуются конструктивными, это отношение реализации, помним 4D экстенсионализм). Оргроли выполняют практики/методы/труд (функциональное/ролевое/прикладное инженерное рассмотрение), а оргзвенья выполняют работы/сервисы (конструктивное/организационное/менеджерское рассмотрение).
С момента начала использования понятия «жизненный цикл» в проектах системной инженерии в этот «жизненный цикл первой версии» стали включать и время работ, которые происходили в начальный (до изготовления частей будущей системы) период времени, т.е. время работ по описанию будущей целевой системы и документированию этих описаний, то есть работы не с самим воплощением системы, не работы по изготовлению-сборке. Такого в биологических системах не бывает! Геном и мемом отличаются в работе с ними: дарвиновская эволюция не может полагаться на «умные мутации», а техно-эволюция — может. В дарвиновской эволюции можно оперировать только изменениями всего организма, поскольку феном разворачивается из мутировавшего генома, а вот в техно-эволюции можно оперировать изменениями только в рамках одного тщательно спроектированного модуля, внося изменения и в мемом (он хранится отдельно от создаваемой системы) и в феном готовой системы. Помним: геном и мемом — это наследуемый материал (гены в ДНК и мемы на каких-то носителях информации), а феном — это проявленный в организме наследуемый материал. Техноэволюция идёт быстро, и в жизненный цикл (то есть не жизненный и не цикл) заодно попали стадии/работы, в которых идёт работа по получению и развитию мемома как описания целевой системы, проект/design целевой системы. Слово «проект» в русском языке имеет ещё и значение создаваемого мемома, описания ещё не реализованной системы. Мы будем отличать проект-работы и проект-описание-системы как проект/project и проект/design.
С момента включения стадий проектирования (работ с мемомом будущей системы) жизненный цикл вообще перестал ассоциироваться с изменением состояний воплощения системы (на чём был сосредоточен жизненный цикл биологических живых систем), а значение термина перешло полностью на работы систем создания как с описаниями, так и с воплощениями целевых систем. Жизненный цикл перестал быть жизненным, перестал быть циклом и перестал быть жизненным циклом самой системы — он просто через именование целевой системы стал указывать на работы/сервисы систем создания. И ещё окончательно по сравнению с биологией и физикой исчезло понятие «эволюция» в пользу «однократного проектирования», «нециклового прохождения жизненного цикла». От «системного мышления про сложные системы» произошёл ход на «методологию как мышление про способы работы создателей».
Целевая система осталась только как «объект проекта/кейса», объект для группы работ, объединённых понятием «жизненный цикл объекта проекта/кейса»: указание того, над чем идут эти работы жизненного цикла. Жизненный цикл гвоздя — это работы завода::создатель, выпускающего гвозди, сети торгующих гвоздями дистрибуторов::создатели, плотника::создатель (причём плотник тут даже не «оператор» времени эксплуатации, ибо оператора гвоздю, когда он держит соединение, то есть эксплуатируется, не требуется, а инженер по вводу в эксплуатацию, «наладчик»! ). Сам гвоздь при этом ничего не делает, не «живёт». Делают с ним.
Вскоре повсеместно жизненным циклом стали называть уже не сам отрезок времени жизни целевой системы, а работы как выполнение сервисов систем создания: совокупность стадий/фаз жизненного цикла в его понимании первого поколения. Эти работы упоминались на всём времени существования системы: от появления первых описаний до ликвидации использованного и уже не нужного никому воплощения. Создание оказалось ведением жизненного цикла как ведением работ, необходимых для изменений состояний целевой системы в ходе её «жизни» как изменений внешними силами.
Сама целевая система при этом просто была маркером, который позволял отметить все относящиеся к системе (как к воплощению системы, так и к описанию системы) работы, кто бы их ни производил в самых разных предприятиях, которые занимались системой на всём протяжении жизненного цикла.
Когда говорили «жизненный цикл АЭС», то имели в виду разбитые на стадии/крупные работы все работы с АЭС, которые выполняли своими сервисами многочисленные предприятия/оргзвенья от момента замысла АЭС и поиска денег на её проектирование и строительство до момента вывода её из эксплуатации с получением после этого зелёной площадки. Когда говорили «жизненный цикл танца», то имели в виду работы по замыслу танца, его постановке, последующих перформансах. Эти работы мыслились как что-то целостное, кто бы ни занимался ими в самых разных командах всё это время с момента замысла танца до момента прекращения его просмотра (помним, что танец мог ещё жить и на записи, поэтому его жизненный цикл необязательно завершается в момент исполнения).
Итак, жизненный цикл «чего-то» в версии 1.0 означает просто последовательность работ, которые производят сервисы создателей этого «чего-то»:
• создатели — это модули/конструктивные единицы систем ведения жизненного цикла, взятые как единицы их организованности (возможности давать и выполнять поручения), оргзвенья. Это предприятия, рабочие группы проектов/команды, кооперации из нескольких предприятий и т. д.
• Сервисы создателей — это внешнее поведение создателей/оргзвеньев, осуществляемое через интерфейс/канал (как и любого другого модуля: рассуждения абсолютно идентично для модулей систем создания, систем окружения, целевой системы, подсистем, надсистем — всё это системы, поэтому рассуждаем с использованием понятий системного подхода).
• Работа — единица задействования сервиса/внешнего поведения оргзвена, которую можно атрибутировать к заданному множеству ресурсов.
• Жизненный цикл (в начальном его понимании, 1.0) — набор работ, выполняемых с целевой системой её системами создания.
• Стадия жизненного цикла — набор работ в какой-то период времени. Период времени обычно выбирается как время, занимаемое ведущей/самой характерной/ключевой/важной работой этого времени.
Изображение жизненного цикла как работ (ЖЦ 1.0)
Изображались такие жизненные циклы с периодизацией работ очень просто: такими «колбасками», в которых поминались производимые последовательно крупные работы каких-то периодов времени внутри периода времени всей работы. Эти крупные отрезки времени внутри всего времени работ по изменению состояний системы были названы стадиями/фазами жизненного цикла. Вот примеры такого изображения жизненного цикла разных типов систем из стандарта ISO 15288, и обратите внимание на то, что каждое название стадии там говорит о поведении/работах систем создания, а не о состоянии целевой системы (хотя иногда и случаются наименования состояния, но они используются как альтернативное название проводимых работ для достижения этого состояния, в духе положений PRINCE2 о том, что работы лучше бы называть по их результату):
Нижняя строчка там представляет собой один из вариантов типового/обобщённого жизненного цикла, который в том или ином виде может быть определён для почти каждого типа целевой системы. В нашем курсе мы вместо «идея» говорим «замысливание», вместо «разработки» и «изготовления» общее для них «создание», вместо «использования» и «поддержки» — «эксплуатация», вместо «списания» — «ликвидация/уничтожение». Вы можете предложить и свой вариант: главное тут в том, что жизненный цикл распространяется и на работы с описаниями системы, и на работы с воплощением системы. Но в этом первом поколении обычно ещё не включает в себя работы с самими системами создания (учёт цепочек создания, создание систем создания какими-то другими системами создания): чтобы построить атомную станцию или мост, нужно организовать стройку, построить целый посёлок в месте строительства, доставить туда необходимую строительную технику. А если это совсем что-то новое разрабатывается, то иногда и проектный институт нужно создать, а не только стройку. Это всё цепочки создания, они в современном системном мышлении обязательны к рассмотрению, планирование их работ тоже обязательно. Но мы тут пока говорим о первом поколении — и это «первопоколенческое» понимание до сих пор широко распространено, получавшие образование лет двадцать назад инженеры и менеджеры его широко используют, в литературе полно этих «колбасок», так что с этим первым поколением понимания ЖЦ вам нужно разобраться хотя бы для того, чтобы общаться с этими людьми.
В «колбасных» диаграммах жизненного цикла часто стадии «использование/эксплуатация» и «поддержка/техобслуживание и ремонты» показывают даже не последовательно, а в одном и том же месте «колбаски» (или название в одном «ломтике» колбаски, как показано на картинке, или даже сам ломтик делят на две «перекрывающихся стадии», две половинки по горизонтали). И в этот момент приходится признавать, что стадии жизненного цикла не так уж и последовательно следуют друг за другом, они могут пересекаться — то есть работы разных стадий могут выполняться в одно и то же время.
Вот этот же жизненный цикл, но там уже используются не ломтики «колбаски», а «шеврончики вправо», означающие «процесс» с последовательными стадиями как шагами процесса. Представление жизненного цикла как последовательности работ подчёркивает разворачивание во времени, это «процедурное», а не «декларативное» описание работ систем создания целевой системы. Описания работ при этом — это одно из описаний систем создания. «Проектирование» (работы по проектированию целевой системы) делает система создания, а не целевая система. Описание работ относится к тому, что делают системы создания, а не что делает целевая система:
На этой картинке уже нельзя указать точные моменты времени, когда начинается один процесс и заканчивается другой, и это намеренно — стрелочка одной стадии буквально входит в хвостик другой стадии так, что нельзя провести вертикальную линию, чётко отделяющую один «шеврончик вправо» от другого. Иногда этот факт размытого времени перехода из одной стадии в другую отражают тем, что ломтики в «колбаске» разделяют не прямыми линиями, а диагональными — типа как работы одной стадии потихоньку заканчиваются, а другой стадии потихоньку начинаются, нет момента резкой остановки работ стадии и резкого начала работ других стадий. Это точнее соответствует тому, что видим в жизни: работ в каждой стадии обычно много, и когда работы одной стадии начинаются (например, начинается изготовление каких-то частей/деталей/подсистем будущей системы), работы другой стадии вполне могут ещё продолжаться (например, проектирование других деталей будущей системы не закончено).
Сам термин «жизненный цикл» всегда означает «полный», то есть от работ систем создания по замыслу до работ по прекращению существования/ликвидации/уничтожению/списанию/выводу из эксплуатации проэксплуатированной целевой системы. Это всё работы создателей, ибо целевая система себя не замысливает, это создатели её замысливают! И то же с другими стадиями, системы обычно сами себя не создают, не эксплуатируют, не ликвидируют. В этом и была сила системного подхода, сам термин указывал думать о полном жизненном цикле, всех необходимых его работах, а не о его отдельных частях-стадиях, не о части проводимых с целевой системой работ! Термин «жизненный цикл» указывал думать о проводящих работы системах создания в их цепочках, а не только о системах в окружении целевой системы. Упоминание жизненного цикла заставляло ни на секунду не выпускать из внимания организации/команды/коллектива проекта работы систем создания.
Методология (обсуждение способов выполнения работ, а не только последовательности выполнения работ и группировки работ в стадии/фазы) пришла чуть позднее. Идея безмасштабности создателей (например, понятие создателя/constructor из constructor theory Дэвида Дойча) пришла ещё позже, по большому счёту эта идея ещё не вошла в методологический мейнстрим, это ещё фронтир. И уж совсем поздно пришла идея, что однократным проектированием-изготовлением дело не обходится, системы эволюционируют, они непрерывно развиваются — но не столько развиваютСЯ (сами себя развивают), сколько их развивают их создатели.
Жизненный цикл проекта
Но поскольку уже было понятно, что речь идёт о работах, а естественной максимальной (соразмерной стадиям ЖЦ) единицей работ в проектном управлении стал «проект» (project, а не design), то появился ещё один термин: жизненный цикл проекта (project life cycle) — он означал те работы полного жизненного цикла системы, которые попадали в рамки конкретного проекта. Проекты эти обычно совпадали с работами, проводимыми для каких-то полных стадий жизненного цикла, одной или нескольких. Это было естественным делением жизненного цикла, потому что разные проекты часто выполнялись разными организациями — и нужно было как-то выделять части жизненного цикла, за которые несла ответственность проводящая проект организация/оргзвено.
По факту системное мышление и проектное управление/управление проектами/project management вот так и были связаны: жизненным циклом называли происходящие по поводу целевой системы работы, которые являлись предметом проектного управления в разнообразных проектах по поводу целевой системы.
В этот момент в самом системном мышлении не очень было принято думать о системах создания (в биологии этого не было, а в технических проектах инженеры «железных», программных и киберфизических систем редко думали о системах создания так же тщательно, как о целевых системах, предоставляя это менеджерам и основателям компаний/«предпринимателям»), поэтому проектное управление как менеджерское движение в 80х и 90х годах прошлого века довольно много сделало для того, чтобы в системном мышлении появились мысли не только об окружении, но и о системах создания, а методология из учения о методах познания стала вполне инженерной фундаментальной дисциплиной (в том числе появились методологические стандарты первой волны и понятия инженерии методов и ситуационной инженерии методов).
По большому счёту и проектные роли/stakeholders как методологическое понятие пришли в жизнь в существенной мере по линии проектного управления: они же часто входят в состав различных систем создания как их функциональные части! Если я разработчик шестерёнки для часов, то разработчик часов (концепция использования часов, задающая ориентиры для значений точности хода и т.д., это будут потребности для проекта шестерёнки, концепция часов, где он предложил шестерёнки вместо электроники), кторый будет принимать от меня результат — воплощение шестерёнки, вот эта роль и есть внешняя проектная роль «заказчика» для моего проекта шестерёнки, причём там эта роль может быть и дальше разбита — проектировщик часов, технолог производства часов как сборки их из готовых шестерёнок (то есть «заказчик» вдруг распадётся на подроли, и кроме инженерных ролей разработчика и технолога производства появится ещё и менеджер, финансист, юрист, логист и т.д.). А в проекте часов для всех тамошних ролей это будет стадия жизненного цикла часов «создание деталей часов», где будет учтена моя работа проекта по созданию шестерёнки. Если не вводить понятия «роли», то в таком проекте легко запутаться: кто что может делать, кто на что влияет, какие «зоны ответственности», кто кому за что платит, кто делает оценки сроков, кто эти оценки сроков учитывает при планировании.
Мышление о создателях происходит существенно с использованием полного жизненного цикла целевой системы (все работы с мемомом и наладкой фенома), а в последнее время сюда добавляя и понимание, что это и впрямь цикл. Говорят и просто жизненного цикла, слова «полный» и «целевой» в таком длинном словосочетании из предыдущего предложения обычно опускают. Если не указано иного — то речь о целевой системе и полном жизненном цикле, все жизненные циклы всех проектов, связанных с целевой системой) и его части — жизненного цикла проекта. Хотя и не только этих понятий (ведь кроме метода описаний жизненного цикла 1.0 будет и метод описания жизненного цикла 2.0, и там будет речь об оргролях и практиках. А ещё помним, что есть ещё и время развития/эволюции — и там понятие «полного жизненного цикла» даёт сбой, ибо появляется возможность использовать его и для указания на работы развития системы, то есть прохождения многих «полных жизненных циклов системы» в рамках «ещё более полного жизненного цикла».
Часто жизненный цикл системы в методе его описания 1.0 (т.е. в представлениях проектного управления) обозначали просто линией времени с засечками для разграничения его стадий/фаз (упрощённая «колбаска»), при этом он всегда обозначался полный: от работ по замыслу до работ момента прекращения существования. В этом указании полного жизненного цикла был смысл системного мышления, удерживать коллективное внимание всех команд всех проектов на всех работах по поводу системы, а не только на работах одной из команд одного проекта. Как всегда, системное внимание разворачивает мышление вовне, от границ одного проекта::создатель к объемлющему проекту::создатель (от создателя::система к надсоздателю::«надсистема систем»/SoS, которая включает всех создателей в цепочке создания, понимаемых как одна система с какими-то сложными процессами создания собственных частей внутри неё — сложное переплетение отношений часть-целое, признания автономности в развитии частей, а также отношений создания, указывается как целый объект всё это переплетение, как объект в пространстве-времени, и в него включается достаточное время для отработки цепочек создания).
Но на такой линии с засечками для стадий вполне можно было указать и жизненный цикл проекта, который обычно короче жизненного цикла системы (например, может включать в себя только работы по замыслу и проектированию/design, или только работы по изготовлению/воплощению системы как физического объекта, или только работы по эксплуатации — тут могут быть самые разные варианты).
Поскольку проект в классическом project management имеет конкретные даты начала и конца, конкретные ресурсы, то «жизненный цикл проекта» понимается просто как проект из проектного управления, а большие куски жизненного цикла, или даже полный жизненный цикл понимаются не как проект, а как программа. В проектном управлении программа — это набор проектов, посвящённых какой-то цели, но проекты из этого набора планируются по мере осознания в них потребности, а не сразу в момент старта программы.
Так, в военной системной инженерии киберфизических систем про жизненный цикл какого-то военного самолёта могут говорить как о программе этого самолёта — это ровно вот эта подмена нейтрального для самых разных практик/деятельностей/инженерий (киберфизики, менеджмента, основания предприятий/предпринимательства) понятия жизненного цикла понятием из проектного управления, которое сегодня развилось из просто project management в program and project management (иногда этот переход называют «третье поколение проектного менеджмента», совместное мышление о программах работ и проектах как частях программы работ). При этом при переходе от проекта (от даты-1 до даты-2) переходят к «открытой дате окончания» (её просто не указывают).
Проектные и программные менеджеры сегодня (прошли десятки лет с момента появления дисциплины!) уже утеряли связь с системным подходом и методологией, и чаще всего думают о просто «программе работ», связанных с целевой системой, нежели об этих работах как о «жизненном цикле» какой-то системы и уж тем более времени развития, «программе развития»/«программе работ создания и развития» — и тут же теряют понимание целостности системы, которая берётся в системном мышлении как целое, в том числе в части способов её создания/практик/деятельностей, что обсуждается в методологии — всегда разные практики всех работ от замысла до ликвидации целевой системы, причём ещё и в проходе по цепочке создания, жизненный цикл системы всегда полный, а с учётом цепочки создания ещё и «более полный». А сейчас и вообще от «полного жизненного цикла с учётом цепочек создания» переходят просто к разговору о создании и непрерывном/continuous развитии системы (не поминая особо «жизненный цикл») в рамках концепции «непрерывное всё» (подробней будет обсуждаться в курсах «Системная инженерия» и «Системный менеджмент»), так что приведённую картинку нужно из линии сделать кольцом, а ещё лучше бы чем-то типа витой пружинки, чтобы учесть время (тот самый «не жизненный, но всё-таки цикл»), и «не жизненный, но цикл» проекта изображать как части такой «пружинки». Всё сразу запутывается в этих сложных представлениях, поэтому от графических представлений в моделировании «не жизненного, но цикла» в рамках изображения техно-эволюции быстро отказываются, разве что иллюстративно на диаграммах всяких «методов разработки» рисуют те или иные кольца (мы приведём примеры чуть позже), и эти кольца ещё и не учитывают создание и развитие создателей. Так что сейчас и рисуют на диаграммах, и обычно просто говорят о создании и развитии целевой системы, а слова «жизненный цикл системы» опускаются, просто «создание и развитие системы».
Программа работ чаще всего имеет единого для всех входящих в неё работ управляющего программой, но вот в системном мышлении жизненный цикл не требует выделения актёра для роли управляющего программой или проектом на всём протяжении жизненного цикла. Системное мышление — это трансдисциплина по управлению вниманием в сложных проектах, это не прикладная дисциплина типа программного и проектного управления, которая подразумевает работу прикладного мастера, владеющего прикладной практикой менеджмента, классической инженерии, культурного строительства, образования или прикладной практикой какой-то иной деятельности по созданию самых разных систем. «Программа партии/движения» — это ведь тоже программа работ, где создатель/мастер — партия/«общественное движение»::сообщество! И «Программа» уже обычно не содержит терминологии «жизненного цикла», она как-то ближе в её понимании к идеям создания и параллельного с использованием непрерывного развития системы, а не просто «задумали, спроектировали, затем родился — жил — умер».
В ходе полного жизненного цикла системы и уж тем более в ходе всего времени развития/эволюции системы выполнять работы могут люди из разных организаций (и они могут включать и представителей разных сообществ и обществ на должностях как раз этих «представителей»), управлять работами будут полномочные для этого люди из этих разных организаций/предприятий/оргзвеньев, а методология на основе системного подхода поддержит целостность представлений о всех работах от замысла системы до её ликвидации, а не только работах программ и проектов отдельных организаций.
Попробуйте перестать рисовать целевую систему (да и любую другую) квадратиком или кружочком. Вместо этого рисуйте её жизненный цикл, обозначая его стрелочкой с засечками. Это будет напоминать не только о воплощении целевой системы, но и длительности всех работ с целевой системой, и об её системах создания, то есть напомнит учитывать организации/предприятия/оргзвенья/команды/проекты, ведущие эти работы. А теперь подумайте о том, что надо в это изображение включить множество таких «жизненных циклов», то есть перейти к идее создания и развития системы. Обычно на диаграммах создание и непрерывное развитие системы изображается замыканием «не жизненного не цикла» опять в цикл — как в биологии, возврат к циклу! Самые разные методы разработки (например, SCRUM) в своих диаграммах обязательно будут содержать какие-то «закольцованности», это и есть отражение идей развития/эволюции.
Тем самым мы не просто от статических рассмотрений целевой системы как неизменного объекта перешли к динамическим, но и перенесли фокус с самой целевой системы на её системы создания. Эксплуатирующаяся/функционирующая/оказывающая сервисы система в её окружении — это просто одно из многих её состояний, но она проходит множество самых разных состояний в ходе её создания и уничтожения. Жизненный цикл отражает этот факт. И он указывает на организационные системы, меняющие своими работами/сервисами состояние целевой системы от момента её замысливания до момента её вывода из эксплуатации — указывает на системы создания. Эти системы создания/ведения жизненного цикла (конструкторские бюро, заводы, учебные заведения, медицинские службы и т. д. — они самые разные для самых разных видов целевых систем) не являются системами из окружения, которое мы обычно рассматриваем только на стадии эксплуатации целевой системы (когда не столько над целевой системой работают, а сама целевая система работает). Эти организационные системы из совсем других системных разбиений, из разбиений систем создания.
Целевая система в её ближнем (подсистемы надсистемы, которые включают и целевую) и дальнем (системы из иерархии надсистем) окружении — это разбиение (иерархия по отношениям часть-целое) операционного окружения/operation environment, то есть времени работы/эксплуатации системы. Создатели — это системы создания/ «ведения жизненного цикла»/«ведения работ над целевой системой» — они из других разбиений, разбиений систем цепочек создания, они части совсем других систем в совсем другое время, и поскольку создатели часто ярко выражены как агенты (автономны! Это редко станки и компьютеры, чаще люди со станками и компьютерами, и даже организации людей!), то это обычно системы систем/system of systems/SoS, что делает их во много раз трудней в рассмотрении.
Между целевой системой и создателем отношение не часть-целое, а создания (то есть замысливания, проектирования, изготовления, проверки, обслуживания, модернизации и даже уничтожения после эксплуатации каждого экземпляра системы, но продолжение развития мемома — проекта/design)! Садовник создаёт (в данном случае замышляет, проектирует, выращивает) цветок (поставляет сервисы/ведёт работы, которые замысливают появление цветка в конкретном месте, дают посадку семечка, полив семечка, а потом и растения, проводят удаление сорняков из окружения растения, производят удобрение почвы для благоприятного окружения цветка, а после цветения выводят из эксплуатации отцвётший цветок — садовник производит работу/сервис по его выкидыванию. Цветок ничего не делает сам, всё делает его система создания в лице оргзвена-садовника. Система создания цветка не часть его окружения (садовник не часть каких-то систем окружения цветка). Системы окружения не части создателей, создатели не части систем окружения, они рассматриваются в разных временах. Я жарю шницель: шницель не часть меня, я не часть шницеля! Это другое отношение, отношение создания. Я рисую/описываю дерево: дерево не часть меня, я не часть дерева, я и дерево не части описания, описание не часть меня или дерева. Есть и другие отношения, кроме отношений «часть-целое»/композиции. Отслеживайте типы объектов, но отслеживайте и типы отношений, минимально это классификация, специализация, композиция, реализация, создание. Без знания теории понятий (работа с типами и отношениями объектов) и онтологии (учение о многоуровневой нарезке мира на объекты, находящиеся друг с другом в каких-то отношениях) системное мышление невозможно!
Итого: жизненный цикл в начальном (1.0) понимании — это по-крупному разбитые все работы создателей над замысливаемой, разрабатываемой, воплощаемой, эксплуатируемой, уничтожаемой целевой системой. По инерции в такое понимание включают и работы развития. А уж одна создающая организация выполняет все эти работы, или много разных, занятых разными жизненными циклами проекта — это менее важно. Главное тут — не забывать о полноте жизненного цикла, «от рождения до смерти» и даже «круговорота рождений и смертей, особенно если речь идёт об отдельных фичах».
Проблемы с жизненным циклом 1.0
Но не успело новое (по сравнению с жизненным циклом как сменой состояний целевой системы) понятие жизненного цикла (как поделённых на стадии работ создателей) прижиться, как начались проблемы.
Первая проблема понимания жизненного цикла как последовательности крупных работ проекта: в реальных проектах по созданию систем массово начала вырождаться стадийность. Сначала в agile (гибких) подходах к разработке софта появились не тематические по видам работ «стадии», а безымянные «итерации» какой-то фиксированной длины — и на этих итерациях было очень трудно отследить, какая же там преимущественная тематика работ. По факту там в каждой итерации и замышляли кусочек системы, и разрабатывали её, и делали, и испытывали, и эксплуатировали, и вроде как понятно было, что всё это нужно обсуждать, но вот идея «стадия как время ведения однотипных работ, а потом другая стадия как время ведения однотипных работ другого типа» не выжила. Эпоха «водопада» как «последовательного прохождения стадий жизненного цикла» кончилась даже до появления полноценной идеи «непрерывного развития», в которой множество линейных жизненных циклов и системы в целом, и её фич замыкались в изначальное «квазибиологическое» кольцо/цикл. Квазибиологическое кольцо — это всё-таки техно-эволюция, а не дарвиновская биологическая эволюция, мутации не случайны, наследственный материал не реплицируется вместе с системой.
Затем в строительных проектах появилась параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным «тематическим» стадиям жизненного цикла: одновременно велось и проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать (например, крыло недостроенного здания).
Тем самым в начале нулевых годов 21 века возникли вопросы к идее о том, что работы на стадиях жизненного цикла ведутся с каким-то определённым состоянием целевой системы. Система разными своими частями находилась в разных состояниях, а все виды работ велись одновременно над разными частями системы: если корабль красили, то не как раньше — сначала зачищали всю поверхность, потом всю её грунтовали, потом всю красили, всю сушили. Нет, чаще всего сначала зачищали кусочек, потом его грунтовали, и одновременно начинали зачищать следующий кусочек, потом первый кусочек красили, второй грунтовали, а третий начинали зачищать — и «сначала» и «потом» оказывалось сугубо локальным для кусочка, а не глобальным для всей целевой системы. Стадии «зачистки», «грунтовки», «покраски», «просушки» оказывались перекрывающимися во времени/параллельными/concurrent, то есть они перестали быть последовательными стадиями, группировкой последовательности работ!
С одной стороны, последовательность работ была всем очевидна (красить нельзя без грунтовки, грунтовать без очистки), а с другой стороны — нельзя было сказать, что «вот система в целом очищена, а теперь загрунтована, а теперь покрашена». Время для системы в целом при описании последовательности видов работ (это уже обсуждаем не ресурсы, а содержание! Функциональное рассмотрение, а не конструктивное!) оказалось логическим/функциональным/содержательным, а не физическим. Сами работы физичны, а вот виды этих работ в части их содержания оказались чем-то другим, содержание работ и их «логическую» последовательность/взаимосвязь нужно было обсуждать другим способом.
Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным/содержательным. Работы и ресурсы обсуждать было продуктивно (операционный менеджмент!), а вот стадийность работ — уже нет. И поэтому понятие жизненного цикла как набора стадий как «укрупнённых работ похожей направленности» стало не очень удобным в использовании.
Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются):
Вторая проблема понимания жизненного цикла как последовательности крупных «тематических» работ: интерфейсы между работами обсуждались с точки зрения потока работ, операционного менеджмента, доступности ресурсов в проектном управлении. Результаты предыдущих работ/output становятся доступны для следующих в цепочке потока работ/input. Это было очень удобно, когда речь шла о точном ответе на вопросы стадии «как сделать работы»: «когда и кем будет выполняться работа, когда она будет закончена?». Но когда обсуждались функциональные вопросы (как вообще этот набор работ создаёт систему? Почему эти работы, а не другие?), как лучше в части технологии (а не как быстрее, то есть инженерный вопрос, а не менеджерский) выполнить работы, то понятий не хватало. Нужно было обсуждение того, как и зачем менять содержательно набор работ, а не оптимизировать время запуска каждой предварительно известной откуда-то работы или оптимизировать ресурсное снабжение каждой предопределённой кем-то работы — информации категорически не хватало: нужна была информация о видах работ, назначении работ и их содержании, а не о самих работах и их ресурсах безотносительно их содержания.
⠀
Практики
⠀
Модульное/продуктное/конструктивное представление работ жизненного цикла «как в управлении проектами» очень нравилось менеджерам, а вот для инженеров оказывалось недостаточным, как это обычно и бывает в системном подходе: область интересов инженеров отличалась от области интересов менеджеров, занимавшихся операционным управлением. Для проектирования, «изготовления», «наладки» самой последовательности работ (то есть проектирования, изготовления, наладки создателей/оргзвеньев, выполняющих эти проектирования, изготовления, наладки работ) нужно было выходить на функциональное/ролевое представление, обсуждать виды работ с точки зрения их ролевого назначения/функций, а оргзвенья создателей рассматривать в их оргролях. Работы как поведение/«экземпляры сервисов ресурсов»/«конструктивных объектов»/оргзвеньев должны выполнять функции/практики функциональных/ролевых объектов/оргролей в создателях, удобных для обсуждения «как работают системы создания, чтобы целевая система меняла своё состояние в ходе жизненного цикла и становилась успешной». Что именно делает Вася Пупкин, не понимая его текущей роли — всегда непонятно (он своей «работой» играет роль Отелло? Принца Гамлета? Офелии? Видно, что Вася Пупкин занят, работает. Но что и зачем он делает?!). Что делает та или иная работа для менеджера-проектировщика (который вроде как должен её запроектировать) непонятно, нужно смотреть на задаваемое прикладным инженером «содержание работы»/«способ работы»/метод/практику/«функциональную ипостась работы».
Рассмотрение поведения систем создания как функций оргролей/проектных ролей/деятельностных ролей в жизненном цикле произошло не сразу: ресурсы в системах создания ведь были конструктивными объектами, и как системы с их ведущим пониманием как именно функциональных объектов не воспринимались! Систем создания не было как систем, не было системного рассмотрения! «Оргроли» при этом это всё те же функциональные/ролевые объекты, которые играются оргзвеньями. «Орг» просто подчёркивает, что речь идёт об организации, то есть существует договорённость о том, кто может просить исполнителя роли выполнить работы этой роли. Проектная роль — тут подчёркивается, что речь идёт о проекте. Деятельностная роль — что речь идёт о множестве проектов и множестве организаций. Но в принципе это всё про одно и то же: это функциональные/ролевые объекты, которые выполняют содержательные действия в организационной системе как системе создания целевой системы (включая все цепочки создания, если это оказывается нужным). Об этой же оргсистеме говорилось и как о «системе ведения жизненного цикла целевой системы», а сейчас говорят как о «системе создания и развития целевой системы», то есть системе-создателе или даже просто создателе. Оргроли, проектные роли, деятельностные роли — это всё роли в создателе.
Переход к диаграммам типа принципиальных/функциональных схем для систем создания произошёл постепенно (и помним, что во всех этих диаграммах было отражено не создание и последующее развитие/эволюция системы, а однократное прохождение «не жизненного не цикла» — это «отрезки», а не «кольца/циклы»). После классических «колбасок» для стадий жизненного цикла поначалу появилось множество гибридных диаграмм, пытавшихся отразить сразу и конструктивную/логистическую и функциональную/назначения ипостаси жизненного цикла как поведения систем создания. И это не случайно: ключевые/концептуальные решения по устройству жизненного цикла — это решения о том, какие оргроли будут выполняться какими оргзвеньями, а в другой формулировке — какими работами будут выполнены те или иные практики/виды работы/деятельности. Это принятие решений по концепции жизненного цикла (по аналогии с концепцией системы) и организация выполнения этих решений стали называться управлением жизненным циклом (life cycle management, ср. work management/управление работами. В управлении работами нет концептуальных решений по жизненному циклу: не идёт речь о содержании и технологии работ, то есть о практиках, но только о длительности работ и потребных ресурсах безотносительно к «способу выполнения работ»/«way of working»/методу).
Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP):
В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций» как групп работ, по-старинке разбитых на «стадии» во времени, появился новый тип объекта, практика (practice, деятельность, род/вид работы, труд, инженерия как изменение чего-то в мире каким-то явным способом), именованная по её теоретической инженерной или менеджерской дисциплине (discipline, теория).
«Практика» и есть культурно-обусловленное функциональное/ролевое поведение создателей. Работы оргзвеньев выполняют роль тех или иных практик культурно-обусловленных оргролей, а жизненный цикл состоит как раз из работ по этим методам/практикам, называемых по их дисциплинам (а иногда слово «дисциплина» включает и собственно «теорию», и использование материалов и инструментов — то есть отсылает к самому методу/деятельности/инженерии, а не только к теоретической их части).
⠀
Роли и практики, объекты и их поведение неразлучны, всегда вместе. Системный архитектор (роль) выполняет практику системной архитектуры (поведение роли). Авиапредприятие (роль) выполняет практику строительства самолётов (поведение роли). И не надо сочинять каждый раз роли и практики «с нуля», надо брать их из культуры, они культурно-обусловлены, они определяются успешно реплицирующимися (и при этом эволюционирующими) мемомами этих практик. Если раньше практика свидания включала шаблон «под часами» (хороший ориентир плюс возможность сверить время), то сейчас мобильная связь привела к тому, что шаблон не выжил — свидание назначается в приблизительно условленном месте в более-менее приблизительное время, а «точная встреча» уже корректируется с учётом доступной технологии, практика свидания изменилась, эволюционировала. Поэтому культурная обусловленность:
• Включает общеизвестность мемома практики: если кто-то что-то как-то делает, то он вряд ли придумал свой метод сам. «Взял из воздуха» — это задействовал те мемы, которые у него уже были. Может быть, где-то уже есть мемы и получше, более современные. Но «изобрёл практику» — это крайне редкая ситуация.
• Привязана ко времени. Так, дисциплина Requirements в диаграмме 1996 года была очень и очень современной, культурно-обусловленной. А сейчас это воспринимается как анахронизм, привет из прошлого.
⠀
Как проверить культурную обусловленность? Обычно по культурно-обусловленным практикам есть учебники. А если это кулибинство/«я сам придумал!», то учебника обычно нет — и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как выполнять практику мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем). Методология не учит, что делать в этом случае, но заставляет удерживать во внимании практики работы и интересоваться их культурной обусловленностью.
Работы разных практик как-то распределены по времени жизненного цикла в его начальном (1.0) представлении как «последовательности работ». В RUP это работы по практикам организационного моделирования/business modeling (помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельная подпрактика не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому), испытаний (сегодня это «инженерные обоснования»/quality assurance), разворачивания (но вот delivering нет как «введение в эксплуатацию»), управления конфигурацией и изменениями, управления проектом, работы с окружением. И это никак не закольцовано, хотя и выделены «порции работ по всем практикам вместе» как «итерации» — но это просто «постепенное достижение конечного результата», а не создание и потом развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились, удовлетворили требования — всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса — за рамками жизненного цикла».
Эти работы делятся на стадии, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) из проектного управления, в то же время практики (названные на «горбатой диаграмме» по их дисциплинам) отражают разделение труда (division of labor).
Разделение труда (практик, деятельности, инженерии) на качественно различные виды не нужно путать с разделением работ, которое количественно. Разделение работ обсуждает, как много работы разбить по ресурсам (например, если нужно выполнить однородную работу вдвое быстрее, то нужно поставить вдвое больше людей, или использовать станок с большей производительностью), а вот разделение труда обсуждает, как практику для одного исполнителя с одной ролью разбить на подпрактики, у которых в качестве их исполнителей возможны разные агенты, которые будут играть по этим подпрактикам разные роли как подроли общей роли для начальной общей практики. Дальше исполнитель подпрактики может углубить своё мастерство, ибо он не должен тратить время на выполнение всей общей практики и может достичь уровней мастерства выше, чем по начальной практике без разделения труда.
Врач раньше занимался всеми дисциплинами, а потом прошло глубокое разделение врачебного труда, и врач-гинеколог начинает существенно отличаться по своей квалификации от врача-дантиста. Веб-мастер занимался всеми работами по небольшому вебсайту, а потом прошло глубокое разделение труда, и этими же работами занимаются программист бэк-энда, программист фронт-энда, дизайнер, контент-менеджер, редактор и ещё много других деятельностных ролей. Инженер раньше был «просто инженер», а сегодня без уточнения того, какой именно это инженер, сказать ничего нельзя. И так практически со всеми практиками. Там, где был один учебник одной дисциплины, появляется десять учебников по десяти дисциплинам.
Работы — это про количество работы и её скорость, а труд/деятельность/практика — это про назначение и разнообразие видов/родов/сортов/способов работы и их уместность/полезность/назначение/роль в проекте.
На горбатой диаграмме в строчке каждой практики показано, что интенсивность этих работ разная в разные моменты жизненного цикла (и это будет отражаться также и в ходе закольцовывания такой диаграммы или разбития её на поддиаграммы для множества команд, занимающихся развитием тех или иных фич системы в ходе её развития/эволюции, а не только однократного проектирования-изготовления-использования, как это подразумевается оригинальной линейной диаграммой): специализирующиеся на разных практиках роли то больше, то меньше задействованы для выполнения работ жизненного цикла в разные его моменты. Тем самым на графике зависимости интенсивности работ от времени появляются «горбы», отсюда и название «горбатая диаграмма». Напомним, что работы — это взаимодействующие продукты/люди/оборудование/ресурсы, участвующие в выполнении сервиса/поведения оргзвена из жизненного цикла. Но работы выполняют какие-то практики (поведение взаимодействующих функциональных/ролевых единиц), они определяются этими практиками.
В 21 веке описания жизненного цикла перестали обсуждаться как описания только поделенных на стадии работ. Эти описания включили в себя и практики: основные (не все! Описания жизненного цикла обычно делаются на уровне концепции, а не детального проектирования) практики оргролей, которые выполняются как производимые оргзвеньями работы. Концепция создателя как концепция системы — это не только функциональная/деятельностная/ролевая декомпозиция ролей как подсистем создателя, но и декомпозиция их поведений, то есть практик, а также не только конструктивный/продуктный/модульный синтез организации/оргзвеньев, но и синтез работ. Для полноценного системного рассмотрения создателей нужны и оргроли, и оргзвенья, и их поведения (практики/функции и работы/сервисы) и дальше размещения и стоимость. Упоминание жизненного цикла (линейного однократного «не цикла», или включающего развитие, «цикла, хотя и без размножения») — это указание не столько на целевую систему, сколько на поведение систем создания, рассматриваемых и как организационные роли и практики этих ролей, и как назначенные на оргроли оргзвенья и выполняемые ими работы, реализующие практики этих ролей.
Жизненный цикл скворечника на вчера рассматривался как главным образом плотницкая практика, реализованная плотницкими работами, выполняемыми Фадеем (оргзвено) в оргроли плотника, а всего несколько лет назад он бы рассматривался как работы Фадея, и неважно по какой практике (плотницкая практика подразумевалась, но явно не обсуждалась). Сегодня понятие «жизненного цикла скворечника» было бы размыто, и больше бы говорили про программу создания и развития скворечника — ибо ожидались бы какие-то непрерывные улучшения в конструкции и материалах скворечника, способах его изготовления, и ещё бы неявно в рассмотрение попал Фадей и его мастерство плотника.
Жизненный цикл атомной станции на сегодня рассматривается как набор практик замысливания, проектирования, сооружения, эксплуатации, модернизации (увы, мы тут не можем говорить о развитии — отрасль серьёзно зарегулирована), ликвидации, реализуемый работами, выполняемыми проектными, строительными, монтажными, эксплуатирующими организациями в самых разных организационных ролях: основателя компании, линейного/операционного менеджера, инженера в целевой предметной области. А всего несколько лет назад обсуждались бы прежде всего работы как «стадии», а не практики этих работ.
Жёсткие условия госрегулирования делают очень трудным разговор о развитии/эволюции атомной станции, поэтому вопрос развития даже не ставится: «модернизация» по факту идёт только как «продление срока службы энергоблоков» (по факту это ремонт, а не улучшение со smart mutations в проекте/design атомной станции) — именно так понимается «управление жизненным циклом» на объектах атомной энергетики. В любом случае, обсуждаются (инженерами АЭС) по линии управления жизненным циклом прежде всего наборы практик, а не наборы работ — работы обсуждаются по линии операционного менеджмента, управления работами.
Обсуждение практик при этом первично: если не знаешь, как ты будешь работать, то ничего про саму работу сказать нельзя. Скрепить две детали — какая практика? Если не знаешь, сварка это, проклейка, болтовое соединение — ничего сказать про работу нельзя. Поэтому практика (функциональное рассмотрение поведения) обсуждается всегда логически сначала, работа (конструктивное рассмотрение) — всегда логически потом, и они итеративно утрясаются так, чтобы удовлетворять условиям доступности в проекте, экономической эффективности и прочим архитектурным характеристикам, которые должны быть удовлетворены системой создания. Ибо жизненный цикл даже энергоблока АЭС — это разговор не столько про саму АЭС и её архитектуру, сколько про создателя АЭС (проектные и строительные организации, поставщики оборудования) и его орг-архитектуру (создатель АЭС — это организация, поэтому говорим не просто про архитектуру, а организационную архитектуру).
Системы создания имеют первичные названия по основной функции/практике, по их организационной роли. Эти названия строятся как и названия любых других систем, вопрос подробно разбирался в курсе «Практическое системное мышление». Парикмахерская выполняет работы своего сервиса как оргзвено (например, как частный парикмахер Ольга, как предприятие ООО «Причешем», или подразделение холдинга Всёрежьчешиукладка), а практику выполнения причёсок выполняет как …парикмахерская! Оргроль парикмахерской — «парикмахерская», «делатель причёсок»! Увы, оргроли в бытовом языке не имеют своих специальных слов для названия. А проектные роли? Это они и есть.
В проектной роли может быть не только человек (на сегодня это самое маленькое оргзвено, агенты сегодня главным образом люди), но и любое другое оргзвено из группы людей и их оборудования. Главное тут не впадать в сверхобобщение, оргроль «клиника» или ещё более обобщённое «лечебное заведение» обычно не даёт возможности что-то содержательно обсуждать: лечебное заведение выполняет слишком много практик/деятельностей для целевых систем с самых разных системных уровней, и лучше бы такие «сверхроли» сразу дробить до ролей с более-менее понятными компетенциями, которые мог бы выполнять отдельный человек как оргзвено. Проектные роли не «клиника», а «врач» и «техник медицинской аппаратуры», а ещё лучше не «врач», а «гинеколог» и «дантист». Принцип почтальона хорошо бы соблюдать и с оргролями (они тоже функциональные части, только систем создания!), а не только с функциональными частями целевых систем: адрес предмета обсуждения лучше бы давать точно, без «на деревню дедушке Константину Макарычу».
А оргзвено? Для каждой более мелкой роли будет более мелкое оргзвено. Для клиники — предприятие; для врача — не слишком понятно, что (и это должно напрягать: модульный синтез будет трудным); для гинеколога — человек, обладающий мастерством в/знающий дисциплину и владеющий инструментами/практикующий гинекологию и занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами/оборудованием: оргзвено размером с одного человека. Является ли сообщество, или общество, или даже человечество оргзвеном? Вряд ли: «орг» тут означает организованность, то есть известность всем тех агентов, которые распоряжаются ресурсами оргзвена. С натяжкой можно говорить, что в социалистических диктатурах всеми ресурсами понятно кто распоряжается (диктатор, и дальше идёт какое-то делегирование полномочий диктатора «на места»), но это на больших масштабах оказывается крайне неэффективным в части распределения труда: потребности людей в масштабах общества учесть невозможно, организовать (наладить систему поручений что-то делать) труд так, чтобы число производимых шнурков как-то билось с числом производимых ботинок оказывается в масштабах общества нерешаемой задачей (до сих пор калькуляционный аргумент Мизеса, который это формулирует, не опровергнут). Так что в нашем курсе мы ограничиваемся оргзвеньями минимально как отдельными личностями (существа как оргзвенья не подойдут, кошечек и слонов не организуешь, у компьютеров достаточного уровня интеллекта ждём), а максимально как компаниями/организациями со всеми их компьютерами, куда включены на нижних уровнях конструкции и компьютеры, и люди, и другое оборудование.
В системном менеджменте не ограничиваются обсуждением практик и работ. Сегодня там большое внимание уделяют понятию оргвозможности/capability для указания ресурсной доступности какой-то практики (то, что на выполнение практики-поведения назначено какое-то компетентное оргзвено, и ему выданы все полномочия по распоряжению ресурсами, нужными для выполнения этой практики. Компетентное — это которое знает, как выполнять практику, включая компетенции отдельных людей и компетенции по объединению труда/деятельности этих людей, а ресурсы включают необходимое оборудование и материалы). По большому счёту, вас интересует не «теоретическая возможность выполнения работы» (все люди обучены, оборудование и материалы есть — практика поставлена), а реальная организационная возможность (практика поставлена, ресурсы есть, плюс выдано полномочие работать по этой практике, тратить на это ресурсы). Переход от состояния организации «практика поставлена, по идее можно работать» до «а вот теперь и правда можно работать» может занимать много лет. Вы можете уметь пользоваться новейшим гвоздезабивальным автоматом, и этот автомат может быть уже закуплен и развёрнут, и закуплен запас специальных гвоздей для этого автомата, но команды им пользоваться не будет, не будет проявлена уже поминавшаяся в нашем курсе «политическая воля» — и вы будете забивать обычные гвозди камнем или микроскопом. Молотка у вас тоже не будет, ибо «мы же только что купили гвоздезабивальный автомат! Он полностью заменяет молоток, и даже лучше!». Вот это типичная для организационного менеджмента ситуация, в которой мы должны отличать практику («как это обычно делается», описана в учебнике) от оргвозможности (как мы это будем делать у нас в проекте). Но повторим: когда мы говорим об оргзвене, чаще всего мы говорим об оргвозможности — то есть это не «оргзвено, которое просто есть», а «оргзвено, которое вполне способно выполнять работы/сервис по известной ему практике, и имеет для этого все полномочия и ресурсы». Как сделать так, чтобы появилась оргвозможность — это рассказывается в курсе «Системный менеджмент».
Жизненный цикл 2.0: практики, по которым выполняются работы
Недостаточность и ограниченность описания жизненного цикла как поведения создателей (view) через метод описания (viewpoint) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Назревала необходимость смены метода описания поведения создателей.
Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного планирования отдельных работ. Разработка везде велась, как судебные дела, «непрерывно открывающимися обстоятельствами», и только производство/изготовление можно хоть как-то было планировать, ибо к этому моменту уже было хотя бы известно, что производить, и какие нормы производительности хотя бы примерно существуют. А нормы мыслительной деятельности и количество порождённых и раскритикованных гипотез в ходе разработки — этого оценить нельзя. Инженеры на невозможности up-front/предварительного планирования и строго последовательного выполнения заведомо успешных мыслительных/знаниевых работ (knowledge works) настаивали, менеджерам это не нравилось, они требовали чётких планов, затем оценки инженеров по поводу планирования (гипотезы!) менеджеры объявляли обещаниями и считали их требованиями. То есть жизнь в проектах шла одним образом, но в учебниках продолжали писать, «как надо»: планировать постадийную работу!
Наборы различных концепций планирования выполнения практик в виде последовательностей работ получили название модели жизненного цикла (life cycle model, вид/форма жизненного цикла). Концепция тут понимается примерно так же, как концепция системы: как увязаны функциональное и конструктивное понимание (а также размещение и оценки стоимости), но не частей системы, а поведения системы, причём не целевой, а системы-создателя.
Концепции/модели жизненного цикла грубо можно разместить между двух крайностей:
1. практики и работы-стадии совпадают и для их выражения хватает «колбаски» с интерфейсами между работами (обсуждается «видимость работ», как обычно в модульных диаграммах — нельзя из работ одной стадии затребовать ресурсы соседней стадии),
2. практики и работы не совпадают и для их выражения нужны какие-то сложные структуры с акцентом на связь практик, т.е. даже внешне похожие на принципиальные схемы с их «логическим, а не физическим временем» и «потоками альф, меняющими по ходу этих потоков состояния», а не модульные диаграммы с их «видимостью интерфейсов».
Первый вид жизненного цикла (квинтэссенция подхода 1.0, «проектное управление с непересекающимися стадиями») получил название «водопад» (cascade, каскад). Работы практик жизненного цикла выполняются однократно, созданные рабочие продукты/артефакты как output передаются как input-ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик. Водопад/каскад течёт всегда сверху вниз, назад возвратов нет! Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступени настоящего водопада:
Между стадиями осуществлялись действия по инженерным обоснованиям (проверки, приёмки, испытания, экспертные оценки) результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ по всей системе. Эти инженерные обоснования с принятием решений между стадиями жизненного цикла для всей системы по итогам оценки рисков успешности проекта на разных стадиях его реализации получили название гейтов (gates, ворота — не путать с milestones/вехами, которые не связаны с решениями о прекращении всего проекта в целом и служат лишь для контроля скорости его прохождения. Ворота могут быть закрыты, а вот вехи просто отмечаем глазами на обочине). Вообще-то решений в гейтах обычно не два типа (go — no go), а три (доработать результат стадии и повторить гейт; переходить к следующей стадии; остановить проект):
Но данная концепция/модель жизненного цикла оказалась для проектов с существенной долей работ с новыми для разработчиков типами систем полной утопией, она более-менее выполнялась лишь в проектах, где можно было накопить огромный опыт сборки/изготовления многочисленных очень похожих систем «из вещества» (там небольшая вариативность), например, гражданское (жилищное) блочное строительство.
Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (в те времена типично было, например, указание на инженерию требований в ходе стадии работ «формирование требований» — понятно, что разработанные требования говорили «какая должна быть система, чтобы быть успешной», и дальше ожидалось, что можно просто спроектировать и изготовить такую систему для гарантированной успешности) после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях — то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять новые работы, выполняющие практики работ предыдущих стадий жизненного цикла. Требования постоянно оказывались не «долженствованием», а «мы чуток ошиблись, гипотеза не подтвердилась», «мы тут не уточнили, давайте сформулируем по-другому». Пробы и ошибки всё равно были, новые и новые переделки/reworks не позволяли хоть как-то соотносить запланированные стадии жизненного цикла и реально ведущиеся работы. «Водопад» был только на бумаге в учебниках инженеров и в мечтах менеджеров.
«Водопад» оказался утопией, типа менеджерского философского камня или эликсира бессмертия: очень привлекательно, но абсолютно нереалистично, нереализуемо. Проблема в том, что следование этой утопии в планировании и отслеживании планов во многих организациях происходит до сих пор! В договорах, планах и отчётах до сих пор можно найти именно «водопад», а то, что в жизни всё совсем не так, никак не влияет на эти документы, поэтому они не отражают реальную жизнь. Эта ситуация известна как проблема «а чо такова?», то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия — плод фантазии, но всё-таки следовать им. «Водопад» оказывается утопичен, фантазиен, но всё-таки люди считают, что он хорошо описывает проект и дальше пытаются ему следовать.
Использующим «водопадную» концепцию жизненного цикла в своих проектах инженерам приходилось признавать, что с практиками приходится работать в ходе всего полного жизненного цикла (те же самые «утверждённые требования», которые и до сих пор используются, менять по многу раз в ходе проекта, иногда чуть ли не в момент окончания работ, чтобы получить приемлемые инженерные обоснования). Работы назначать (и выделять ресурсы для проведения этих работ) на практики приходилось независимо от «водопадной» модели жизненного цикла, каждая практика (особенно легко это объяснять на примерах управления работами/операционного менеджмента, управления конфигурацией и прочих «управлениях») встречается на всех стадиях «водопада», их принципиально непонятно как выносить на какую-то обособленную во времени стадию. Но это же верно и для всех остальных практик, есть только ложное убеждение, что «мы утвердим очередной рабочий продукт, например, архитектурное решение, и больше никогда к нему не вернёмся». Нет, так не получится. Непрерывное всё, придётся постоянно работать над изменениями. Так что деление на стадии при принятой концепции «водопада» в жизненном цикле отражается не столько на реальных работах (они идут как надо, а не как задокументировано в планах!), сколько на договорной документации и официальных документах, которые должны идти в архив. «Водопад» путает классических инженеров в части описания того, какими методами они работают, а менеджерам/«инженерам предприятия» даёт нереалистичные оценки как в части рациональной организации работ (архитектуры предприятия, облегчающей инженерию целевой системы), так и в части операционного менеджмента (работы оказываются совсем не такими, какие можно ожидать, и происходят они в неожиданные моменты — предсказания модели «водопада» очень плохие).
Каждый раз, когда люди говорят «у нас принята водопадная модель» — это означает, что они думают «колбаской», а в жизни у них не-пойми-что, но только не эта «колбаска» с последовательным продвижением по стадиям. Тем самым описание проекта сильно отличается от жизни, а это недопустимо, это само по себе вносит риск в проект! Если у вас на чертежах собачья будка, а в жизни это получается скворечник — то к такому проекту будут вопросы. Но если на «чертежах» самого проекта (то есть в договорной документации, в отчётных документах — это и есть «проект/design проекта/project»/«чертежи проекта», по этому проекту/design планируется разворачивать работы проекта/project) «водопад», а в жизни получается какая-нибудь спираль или что-то другое, лучше отражающее непрерывные изменения, «цикличность/продолженность/непрерывность развития», то принято делать понимающее выражение на лице. Но ведь это то же самое: системное мышление по отношению к целевой системе и системам создания устроено одинаково, и описание должно соответствовать воплощению!
Менеджерам и особенно госчиновникам в военных проектах гейтовая схема была очень удобна, ибо она позволяла легко организовывать финансирование проектов, деля деньги по их стадиям. Проектные управляющие до сих пор пользуются гейтовой схемой из «водопадной» модели как основным описанием для организации своей проектной работы. Страдают при этом не менеджеры, страдают инженеры-технари: функциональные диаграммы, говорят, например, что нужно доработать концепцию использования (при этом для концепции системы ещё и требуют «для архива» разработать требования, которые потом будет очень трудно менять!). А у менеджеров финансирование работ на разработку требований уже закончено, а концепция использования вообще не учтена, ибо «как же вы будете работать без требований?». И инженерам-технарям (или не технарям, а из других сфер деятельности, где они даже «инженерами» не называются) средства на доработку концепции использования поэтому не дают, «поезд ушёл». Конечно, дорабатывать самые разные описания системы в жизни таки приходится, но это будут «неучтённые работы», и поэтому в проектах с официально принятым «водопадом» в качестве концепции жизненного цикла всегда наблюдается управленческий хаос, непримиримые конфликты менеджеров (инженеров организаций) и инженеров-технарей (прикладных инженеров целевой системы).