[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Дальше мы должны рассматривать целевую систему. Мы должны найти нашу систему, свою систему среди чужих систем. Где мы ее сейчас будем искать? Мы ее будем искать прежде всего где-то на каком-то уровне холона, то есть мы понимаем, что все системы вложены друг в друга как вот такие вот матрешки, и мы должны понимать, что есть много довольно-таки терминологии используемой, и мы помним, что вы можете воткнуть как бы вот такой штандарт, флажок, какой-то колышек забить в то место, где у вас целевая система, и дальше все как в полярных координатах начинает раскручиваться вокруг целевой системы, то есть вы должны найти, что вы хотите сделать, чем вы озабочены, после чего определить и обеспечивающую систему, и определить, какая там была использующая система, и все вокруг вот начнет разворачиваться. При этом, почему именно целевая система? То, что мы хотим сделать, то, что мы хотим изменить в реальном мире, приводит к тому, что мы выбираем все средства вокруг этого, мы выбираем это окружение, и если вы хотите сделать коробку из-под обуви, это совершенно не то, что вы хотите изготовить, например, ракету спроектировать или фуникулер на склоне какой-нибудь горы Фудзи. То есть целевая система определяет весь остальной разговор. К сожалению, определить ее чрезвычайно трудно. Ошибки постоянны, они дорогостоящие. Решение абсолютно субъективно, потому что «система в глазах смотрящего», и она зависит от стейкхолдеров. Если у вас собрались одни стейкхолдеры, в одних ролях, они по-одному определяют систему, другие стейкхолдеры в других ролях по-другому определяют систему. Если эти наборы стейкхолдеров в рамках одной команды, они должны провести довольно-таки трудные переговоры, чтобы определить, какую систему вместе они хотят делать. И, может быть, не все стейкхолдеры после этого окажутся в проекте. Нет строгих правил, все зависит от того, как хорошо играют стейкхолдеры свои роли и сколько стейкхолдеров вы собрали, сколько стейкхолдеров представлены. При этом я не могу вам сказать, что сейчас возьмите пять-шесть разных типов проектов, и вот вам правила, которые позволяют работать в рамках этих проектов. Никаких правил, никаких «запомните, так всегда делают». Каждый раз каждый проект уникален, даже два подряд проекта, которые абсолютно одинаковы, вы два раза разрабатываете вот такой кликер, они будут отличаться, потому что вы в первом проекте наберете опыт, у вас по-другому будет представление о рисках, у вас будут разные представления, какие стейкхолдеры должны поучаствовать в ваших проектах, что вы должны услышать от них, вы выберете разные способы, поскольку есть даже эффект второй системы такой, что когда вы делаете вторую систему, вы ее делаете совершенно другую, у вас появляются новые возможности, вы делаете ее из новых деталей, у вас появляются новые эмерджентности, вы можете использовать ее в другой использующей системе. Поэтому каждый проект уникален, даже если вам кажется, что вы делаете одно и то же, поэтому запоминать можно, но опыт особо не переносим, разве что опыт в рамках исполнения ролей, вы чуть-чуть по-другому будете понимать, работает сценарий, то есть принц Гамлет будет чуть-чуть другие реплики произносить, если он имеет опыт работы в каких-то проектах. И мы при этом помним, что для того чтобы возможность была переноса опыта из проекта в проект, мы даже если проектируем какую-то одну систему, какой-то один уникальный мост, который в одном месте, или уникальную Эйфелеву башню, которая только в одном месте на планете, или уникальную ракету, которая взлетает и летит на Марс один только раз, мы ведем проектирование в классах. То есть мы говорим не в терминах экземпляра конкретного с серийными номерами системы, а мы говорим в терминах ролей, в терминах функций, в терминах типов, для того чтобы иметь возможность переносить знания, для того чтобы возможность иметь накапливать некоторое мышление. И поэтому мы мыслим в ролях, имея в виду при этом всегда те объекты, которые замещают вот эти вот роли, которые исполняют вот эти роли. И как мы проверяем, об одном и том же ли мы говорим? Мы просто понимаем, что речь идет об одном и том же куске пространства, которое мы описываем тем, что мы описывали вот в мышлении, используя мышление в терминах ролей, классов. И с другой стороны, понимая, что вот это место пространства в данный момент заполняется каким-то объектом, который исполняет физически вот роль физического объекта, конструктива для этого класса, для этой функции. Главное, итак, определить целевую систему. Какая же у нас целевая система, как о ней думать? У вас есть два способа мышления об этой целевой системе. Прежде всего, вы можете думать об этой целевой системе как о продукте, который вы должны создать. То есть вы должны создать какую-то вещь. И все понимают, что это либо сапог, либо, вот как тут нарисовано — чугун серый литейный, чушки чугунные, либо это кинокамера, либо тот же самый кликер, либо вы даже хотите сделать какого-то человека, и вот стоит прекрасный человек. Это первый способ думать. Но система ценна обычно своим сервисом. А сервис, если вы помните, мы говорили, что сервис — это на какой-то границе системы есть вовне наблюдаемое поведение. Ну, условно говорим, что это поведение вовне называется сервис, оно функционально, это поведение имеет некоторое назначение по отношению к системному окружению, к использующей системе. А внутри самой системы идут процессы, но это уже прозрачный ящик, мы понимаем, что там внутри находится, и мы можем отложить вот этот разговор, что находится внутри системы. Поэтому есть два способа мышления. Первый — мы разворачиваем систему как вот что-то, находящееся в пространстве, немножко игнорируя аспект времени, и второе — мы можем обсуждать систему, как находящуюся больше как бы во времени, как что-то такое разворачивающееся во времени, как функцию, как глагол, то, что выполняется как-то. Текущим трендом является то, что традиционная еще лет 50 назад продуктная ориентация, ориентация на результат, на продукт, она превращается в то, что продуктом мы начинаем считать сервисы, то есть функции, то есть какие-то процессы, внешне наблюдаемые, которые выполняются по какому-то определенному назначению, выполняют какую-то предписанную функцию в окружающем мире. Более того, в некоторых языках, например в языке Архимейт, слово «продукт» перестало означать вещи, а имеется в виду банковский продукт, страховой продукт, то есть то, что мы привыкли обычно называть сервисами. Этот тренд называется сервисоориентацией. Возьмем те же самые чушки чугунные. Еще лет 20–30 назад неожиданно заметили менеджеры, что там и тогда, где и когда на производстве мы перестаем говорить о продуктах как о вещах, мы получаем неожиданно большую гибкость в предложении на рынок. И вот тут уже нельзя говорить — в предложении продукта на рынок, а в предложении уже получающегося сервиса на рынок. Как только мы говорим, что мы не чугун делаем, а мы предоставляем чугун, мы поставляем чугун. Смотрите, появляются слова инговой формы по-английски, инговое окончание. А по-русски это отглагольные существительные. Предоставляем, поставляем чугун. Чугун тут является как бы дополнением, а акцент падает на то, что мы занимаемся поставкой, то есть поставляем, а поставка (отглагольное существительное) чугуна, то немедленно мы можем обсуждать, как мы это делаем. То ли мы запас чугуна поддерживаем на территории нашего клиента, то ли мы поставляем этот чугун прямо в его производственный процесс, прямо в какой-то конвертер отгружаем, то ли мы делаем запас чугуна у себя и поставляем этот чугун по потребности, то ли мы делаем с чугуном все, как было, но единственное то, что мы предоставляем дополнительные части поставки, например, какие-то финансовые операции проводим, осуществляем некоторое кредитование. То есть оказывается, как только мы переходим от обсуждения вещей к обсуждениям изменений этих вещей, у нас появляется множество дополнительных объектов, которые меняют границы системы и заставляют обсуждать вот эти изменения, и появляется сразу пространство обсуждения возможности, как мы свой вот этот вот объект вставляем в использующую систему, что там меняется, в какой момент он нужен в использующей системе. И люди начинают лучше проектировать, лучше реализовывать, лучше эксплуатировать свои системы. Но, смотрите, при этом мы, когда думаем о сервисе, мы всегда думаем не столько о самом сервисе, как о вот этом вот поведении, сколько на самом деле о системе, о продукте, который оказывает вот этот вот сервис. Целевой же системой часто, если вы думаете именно о сервисе целевой системы, является часто то, что вот этот сервис, если вы делаете систему, оказывающую сервис, вы можете думать о ней как об обеспечивающей системе, а целевым продуктом будет являться та система, те фрагменты системы, на которые направлен наш сервис. Например, вы можете думать о той же самой парикмахерской, которая делает прическу как целевую систему, но когда мы думаем о парикмахерской, мы, конечно, думаем о прическе, но делать нам приходится, основное время заниматься обеспечивающей системой, то есть парикмахерской как сервис-предприятием, и мы рассматриваем в полном системном ее рассмотрении. Тут нет ничего объективного. Все зависит от конкретного проекта, от его стейкхолдеров, что мы в данный момент назовем системой обеспечивающей, и будет ли у нас сервис предоставлять обеспечивающая система, либо это сервис будет внешнее поведение в составе использующей системы или даже в составе целевой системы, потому что у нас там будет несколько разных сервисов, но тренд точно есть: то, что мы смотрим эти системы не как вещи, не системы-вещи, а как системы-процессы, то есть системы-«танцы», то есть «танцы» с некоторым назначением, с изменением поведения в окружающей среде. При этом, когда мы смотрим... Я все время говорю: все зависит от стейкхолдеров, все зависит от того, что нам надо. При этом вы должны понимать, что проекты коллективны. То есть то, что мы рассматриваем, это не построение какого-то конкретного объекта вами самим и предоставление его окружающим, а то, что у вас есть команда, это всегда есть некоторое количество стейкхолдеров, и надо всегда помнить, что ты, конкретно ты, это не тот человек, который тыкает пальцем и говорит: «Мы вот это будет делать!», и все за ним идут, а ты обычно в третьем ряду, кто-то, какой-то конкретный стейкхолдер, у тебя ограниченное количество ролей и свой специфический взгляд на эту систему. Есть другие люди, они по-другому думают об этом же проекте. Надо договариваться. Целевая система определяется для команды проекта, а не индивидуально — как раз для возможности скоординировать деятельность. Вот этот очень важно. У твоей группы или у тебя может быть просто «подсистема». То есть совершенно необязательно, что вы, занимаясь каким-то болтиком, говорите, что вот этот болтик является моей целевой системой. Нет. Целевой системой является, может быть, все устройство, где этот болтик выполняет конкретную совершенно функцию как «подсистема». Ничего страшного. Вы его считаете целевой системой, но вы его даже не называете целевой системой, потому что лучше бы вы называли целевой системой (много лучше) вот эту коробочку. Во-первых, если вы делаете подсистему, это заставит вас лучше разобраться в том, куда этот ваш болтик втыкается, и вы легче пройдете валидационные испытания для вашего болтика. Вы не попадете в ситуацию, которую я описывал в байке «катафалк», то есть вы не сделаете катафалк вместо свадебного лимузина. Поэтому лучше вы назовете подсистемой, но вы назовете правильные границы системы. При этом команда — это может даже необязательно быть именно твоя группа проекта, а обязательно это может быть и большое предприятие, потому что система может пересекать границу предприятия, а все остальные считаются вашей командой. Ну есть, конечно, у вас там ты и двое твоих друзей из твоего отдела, но действительно они делают что-то небольшое в рамках большой системы. С другой стороны, вы можете быть более или менее автономны, и ваш продукт может использоваться в слишком большом количестве разных использующих систем. Вам выгодно его описать отдельно, тогда вы будете его называть, конечно же, целевой системой и рассматривать разные варианты использования в разных вариантах операционного окружения. Ничего тут нельзя сказать. Все это, конечно же, субъективно. Единственное, что тут надо запомнить, что вы должны в этом случае поддерживать два рассмотрения: ты обычно стейкхолдер или ряд их, а не «объективный и нейтральный системный инженер или системный менеджер», с одной стороны, ты должен учитывать точку зрения твоей инженерной специальности — что ты там хотел бы видеть в этой целевой системе. А с другой стороны, ты четко должен понимать, что у тебя есть еще и дополнительное системное рассмотрение, что ты учитываешь и все другие специальности твоей команды, а также других внешних стейкхолдеров, в том числе и команд твоих клиентов, например, и команд, возможно, регуляторов, и мало ли кого там из стейкхолдеров ты еще увидишь в своем проекте. И вот эта вот двойственность восприятия, она системным мышлением подразумевается. То есть вы всегда думаете и как стейкхолдер, понимая, что это вот такая позиция в проекте, и одновременно поддерживая часть мышления в целостности.
