«Времена» рассмотрения системы

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

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

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

1. Время эксплуатации**/****использования/run-time/**operations, оно в момент «разработки с нуля»/greenfield, а также разработки фич (модернизации, brownfield). Это время работы уже существующей готовой и работающей целевой системы. Оно в ходе проекта часто находится в будущем, и поэтому приходится думать о будущей системе как уже существующей и успешной (т.е. удовлетворяющей потребностям проектных ролей, а то и превосходящей их ожидания). Это время эксплуатации может быть очень небольшим, например, 20 миллисекунд для исполнения какого-нибудь софта или реализации взрыва. Это также может быть тремя минутами для танцевального перформанса, или восьмьюдесятью годами бесперебойной работы энергоблока атомной электростанции. В этот момент система уже создана и её экземпляр прошёл какое-то развитие. Экземпляр системы находится в физическом мире, настроен и работает, взаимодействует со своим окружением в составе надсистемы, нанося этому окружению непоправимую пользу. Взрыв крушит всё вокруг, софт перемалывает данные, танцевальный перформанс происходит и три минуты радует людей, энергоблок АЭС производит электричество. Ведущий аспект рассмотрения целевой системы тут — функциональный, система создания обычно не рассматривается (но может рассматриваться из неё оператор, который работает как раз в это время).
2. «Время **созданияи развития»/«designandconstructiontime****»/«developmenttime****»** как время работы создателя целевой системы, состояние целевой системы при этом необязательно готовое для работы, она может быть вообще ещё в виде сырья или даже существовать только в форме идеи/замысла, то есть создаваемая система в это время может ещё и не существовать в физическом мире. Это design-time или development у айтишников (начиная с замысливания и включая «непрерывное всё»), но мы включаем сюда и время изготовления, наладки, испытаний, ввода в эксплуатацию, модернизации и техобслуживания для «железных систем», что часто в программной инженерии не рассматривается как отдельные работы. Софт контроллера в подушке безопасности автомобиля работает 20 миллисекунд, но время его создания и развития — три года разработки начальной версии и три года эксплуатации (где актуальное срабатывание — только 20 миллисекунд, остальное — время ожидания включения, но это ожидание включения — тоже время эксплуатации). Но длительность создания и развития контроллера в подушке безопасности будет всего не шесть лет, а много больше — ибо каждый год выходит новая улучшенная версия, и так продолжается уже двадцать пять лет, и непонятно, сколько ещё будет продолжаться («непрерывное всё» в технической эволюции может быть ограничено по времени, но в целом развитие жизни, включая техносферу, бесконечно по времени, и мы рассматриваем уже «систему как вид», эволюцию системы). Можно подразделять это время на создание MVP, развития/эволюции, можно выделять из времени развития ещё и время создания каждой очередной версии системы (время создания инкремента, время создания фичи), считая, что время развития состоит из времён создания множества инкрементов, но это уже детали. Главное, что речь идёт о рассмотрении работы систем создания и состояний целевой системы, которая ещё не работает**.**Ведущий аспект рассмотрения тут — рассмотрение не столько целевой системы, сколько методов работы и работ создателей из их графа.
3. Методологическое (обсуждения «как делать») время, вынесенное за пределы каких-то проектов — время создания команды создателей целевой системы**.** Методологических времён может быть несколько: а) основатель фирмы работает во время основания фирмы (создаёт менеджерскую команду, создаёт инвестуру), б) менеджерская команда дальше организует инженерную команду (и уже инженерная команда работает во времени создания). Работы методологического времени обычно считаются проходящими вне времени самого проекта. Это самое трудное для понимания время, ибо рассмотрение работ этого времени требует удержания внимания на времени эксплуатации целевой системы по довольно длинной цепочке рассуждений. И это даже множество времён, ибо в графах создателей множество «систем создания и развития». Это методологическое время легко понять, если обращаться к идее пространства-времени, в котором по определению у систем (целевой, в окружении, создания в их графе) нет ни «уже», ни «ещё», они все одновременно присутствуют. В методологическом времени мы думаем и о времени использования, и о времени создания и развития, думаем о культурно-обусловленных (выходящих за рамки проекта) методах/практиках/культурах/технологиях работы, думаем о доработках мета-моделей и мета-мета-моделей. Мы думаем о проекте, выходя за его рамки (даже если сами по уши вовлечены в проектные работы времени создания), но мы занимаемся методологической работой: думаем о методе работы, как работать, как организовать проект, а не работаем в проекте во время создания и развития**.** И это обычно мышление о будущем, и даже «неопределённом, неясном будущем», ибо вы можете только предполагать/проектировать, как оно там будет, но не можете гарантировать того, что действительно случится в этом будущем. Вот вы, размышляющий о своём рабочем проекте и своём месте в нём в ходе освоения методологической работы по нашему руководству — вы как раз в методологическом времени, а когда вы выполняете сами работы этого проекта — вы сразу оказываетесь во времени создания и развития. Методологическое время иногда называют временем рефлексии, но рефлексия — это взгляд в прошлое, на уже совершившиеся действия, а методологическое время предполагает рассмотрение и прошлого, и будущего. Ведущих аспектов рассмотрения тут нет, ибо представлены все аспекты для самых разных систем. Методологическое время легче представлять как время просмотра и обсуждения какого-то кинофильма «создание и развитие системы», находящегося прямо перед внутренним взором. В европейской традиции при этом линия времени такой «развёртки во времени кадров фильма» представлена на уровне глаз слева направо как кадры в киноленте (но это не кадры, а живые сценки, «гифки»), и можно наблюдать сразу за всем фильмом на всём его протяжении, просто крутя головой, рассматривая разные участки этой киноленты. Конечно, фильм «создание и развитие системы» мог занимать десяток лет до момента такого рассмотрения, а потом и на десяток лет залезать в будущее (легко представить фильм, показывающий будущее!). Но легко представить и такой фильм, проходящий перед вашим взором спереди (будущее впереди) назад (прошлое позади). Тогда находящееся прямо перед глазами «здесь и сейчас» занимает у вас всё поле зрения, будущее не видно и поэтому не учитывается в действиях, а прошлое уже прошло и поэтому тоже не учитывается в действиях. Рассмотрение методологического времени теряется, вы оказываетесь по факту только в текущем кадре, в какой-то момент времени создания и развития или даже в момент времени эксплуатации.

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