Цепочки создания
Нужно всегда понимать, о какой системе (целевой, в окружении, или создающей) вы говорите в каждый конкретный момент --- ибо речь идёт о вашем осознанном внимании к разным объектам, да ещё и разным временам. Например, когда вы просто упоминаете «топор», то непонятно --- вы делаете топор (топор --- целевая система), вы используете топор для колки дров (целевая система --- дрова, топор --- «один из создателей»/«одна из систем создания», необходимая для подготовки целевой системы-дров к эксплуатации --- сгоранию в печке) или топор для вас одна из систем в окружении целевой для вас колоды, совместно с которой топор должен колоть дрова и свойства которого вы выясняете для того, чтобы спроектировать и изготовить правильную колоду[1].
С самого начала обсуждения жизненных циклов в инженерии было понимание, что они связаны между собой через стадию эксплуатации/использования в длинные цепочки создания, ибо стадия эксплуатации создателя --- это когда создатель участвует в работах жизненного цикла целевой системы. В цепочке это может распространяться на несколько уровней.
Есть простой способ показывать цепочки создания для разового жизненного цикла: сам жизненный цикл на них рисуется изображающими время стрелками с зарубками, отделяющими стадии жизненного цикла, а отрезки эксплуатации каждой системы, оказывающей сервис по созданию другой системы как работы проекта/оргзвена/системы создания, показываются стрелкой-скобочкой на линии времени жизненного цикла очередной системы в цепочке создания:
На таких диаграммах (её рисовать несколько секунд!) удобно рассказывать истории про цепочки создания типа «мы организуем стартап, который создаст САПР, при помощи которого мы затем спроектируем топор, при помощи которого мы потом будем колоть дрова, при помощи которых потом мы приготовим обед» --- и для каждой системы в цепочке создания в такой диаграмме понятно, что она проходит довольно долгий период собственного изготовления перед тем, как быть использованной/проэксплуатированной. Недостаток такой картинки --- она по факту про физическое время, хотя и предельно абстрактно нарисованное (одно из ранних пониманий жизненного цикла как «водопада» стадий::работ, а не практик), но главное --- системы не просто разово вводятся в эксплуатацию, они продолжают модифицироваться в ходе эксплуатации, то есть после ввода в эксплуатацию продолжается стратегирование новых возможностей/фич, их проектирование, изготовление, инженерное обоснование успешности системы с этими фичами, интеграция в уже работающие системы.
Давайте вспомним об альфах, они вводились в курсе системного мышления. Перейдём к языку не работ, а практик: альфы --- это объекты отслеживания в проекте, ибо по ходу создания систем альфы меняют свои состояния, поскольку для смены состояний альф проводятся работы по каким-то практикам.
Давайте представим какие-то области интересов по именам типовых систем, которыми занимается какое-то предприятие/фирма:
- Целевая система: система, которую делает фирма
- Надсистема для целевой системы (у клиентов есть потребности как раз в надсистеме)
- Создатель целевой системы (команда инженеров, занимающаяся прикладной инженерией, например, программной инженерией, если целевая система --- это софт)
- Создатель команд фирмы (который будет создавать команду инженеров и команду создателя агентуры, то есть команда менеджеров фирмы, занимающихся её развитием)
- Создатель создателя команд фирмы, который создаёт инвестуру --- группу инвесторов, которые дают фирме необходимый для развития капитал (то есть команда основателей фирмы, которая проводит соответствующие переговоры с инвесторами, оформляет инвестиционные сделки и организует/создаёт и развивает команду менеджеров)
- Создатель агентуры, который создаст группу агентов (команда продвиженцев)
- Создатель клиентуры (агентура, то есть группа агентов, которая будет вербовать клиентов)
- Клиентура (группа клиентов, у которых есть потребности в системе, они создают свои надсистемы и интересуются целевой системой)
В каждой области интересов будет несколько альф, которые мы будем потом отслеживать: система, её описание, её работы. Пока нас интересуют работы создания, чтобы обсудить цепочки создания, составляющие граф. Не будем показывать ни работы, ни практики, ни состояния альф, ни описания систем. Но покажем, что фирма создаёт агентскую сеть (агентуру), которая приносит клиентов (клиентуру), у которых есть надсистемы, в которых и будет использоваться наша система. Про основателей фирмы помним, но инвестуру (инвесторов, которых основатели фирмы создают из владельцев свободных денег) прописывать не будем. Задача: отмоделировать все эти объекты внимания, чтобы чего не забыть. Список из предыдущего абзаца как раз такая модель, и её будет достаточно, чтобы проводить довольно много обсуждений предприятия, каждый раз отчётливо понимая, какую именно альфу из области интересов к какой системе вы обсуждаете.
Когда мы рассматриваем системы попарно: создатель::система «создаёт и развивает»::деятельность «свою систему»::система, то если «своя система»::создатель, эту цепочку можно продолжить. А ещё один создатель может создавать несколько систем, и цепочки в этот момент оказываются графом.
Исключительно для иллюстративных целей приведём диаграмму графа создания как набора цепочек создания (в жизни вы будете создавать и заполнять списки и/или таблички, а не диаграммы, ибо замучаетесь вносить постоянные изменения в диаграмму, но про таблички расскажем чуть позже)[2]:
Все цепочки создания в графе создания так или иначе ведут к целевой системе, но при желании можно показать, что целевая система тоже что-то создаёт, она вполне может быть не последняя в цепочке (это легко может оказаться станком, который купил у вас клиент). Цвета областей интереса взяты по мотивам стандарта OMG Essence: относящиеся к целевой системе альфы даются на жёлтом фоне, надсистеме --- на салатном фоне (клиентура как внешние проектные роли имеет потребность каких-то характеристик надсистемы, которые может дать целевая система в составе надсистемы, так что клиентура тоже попадает на салатный фон), а вот команды-создатели в их цепочках даны на голубом фоне. По большому счёту, мышление про все эти показанные системы в их цепочках одинаково, так что цвет в рассуждениях оказывается не так важен. Но можно его учитывать. Так, жёлтое --- это начало всех начал, целевая система, и поэтому все рассуждения должны как-то приводить к её созданию и улучшению, зелёное --- это системы и команды (внешние проектные роли) вовне фирмы, а голубое --- это и есть сама фирма, внутренние проектные роли. Это альфы, так что разговор про огроли, а оргзвенья тут будут с точки зрения OMG Essence рабочими продуктами, по которым мы будем определять состояние альф. И помним, что в OMG Essence онтология кривовата (об этом предупреждалось ещё в курсе системного мышления), поэтому любителям строгости и формализмов приходится туго, но мы не будем тут что-то сочинять своё, а будем задействовать язык/language/дисциплину этого стандарта --- OMG Essence как раз предназначен для описания методов/процессов/практик разработки, вот мы и будем использоватьего понятия для этих целей, разве что не советуем использовать предлагаемую этим стандартом нотацию (как текстовую, так и диаграммную) и предложенный в нём набор областей интереса и альф (в языке стандарта это kernel, «основные альфы»). Не нужно копировать эту диаграмму, не нужно даже её рисовать свою, адаптированную. Нужно будет прописывать ваши варианты цепочек создания для вашего проекта, а также описывать состояния альф из этих цепочек создания в табличках в каком-то универсальном моделере. Как это делать, будет рассказано дальше.
Мы (кто мы? Команда, коллектив команд, предприятие? Владельцы, менеджеры, инвесторы?) создаём софтверную компанию, которая разработает софт ведения общей модели данных в ходе строительства моста, проектный институт предусмотрит этот софт при проектировании стройки, а стройка будет эксплуатировать этот софт, когда будет строить мост. А целевая система? Мост (как провайдер «транспортного потока», эту цепочку создания можно продолжать!). И придётся тщательно проработать всю эту цепочку создания (она тут ещё и не вся прописана! Создателей в самых разных цепочках, и даже не столько цепочках, сколько графах создания тут много больше). Если вы не научитесь моделировать и документировать такие цепочки, каждый раз доводя их до целевой системы, то вы будете вынуждены находиться в клубке бесконечных обсуждений того, чем же вы занимаетесь в рамках какой-то невнятно «тусующейся» толпы самых разных людей из самых разных служб самых разных компаний со всеми важными и неважными деталями описания. Плохо будет понятно, чем из всего обсуждаемого нужно заниматься, и нужно ли вообще этим заниматься. Если вы моделируете и документируете цепочку создания, то вы очень быстро говорите, зачем и почему нужен ваш проект (обычно он где-то в середине какой-то из цепочек создания в графе создания), как он приведёт к успеху целевой системы (ну, или понимаете, что проект не влияет на успех целевой системы, поэтом никому кроме вас не нужен, и закрываете этот бесперспективный проект).
Чем дальше по цепочке создания вы находитесь от целевой системы, тем больше внимания вам нужно ей уделять: от вашего мышления потребуются усилия, чтобы удерживать её во внимании. Системное мышление требует собранности: найти целевую систему, а после этогоспроектировать и обосновать всю цепочку создания до«вашей» системы, не пропуская ни одной системы в этой цепочке и удерживая во внимании пользу всего проекта для целевой системы. Без собранности у вас не получится не терять из виду целевой системы. Совет тут обычный для усиления внимания: документируйте описание/модель цепочки создания! Это поможет удержать внимание к целевой системе.