Глава 5. В которой Лидия знакомится с целеполаганием, замыслом и функцией целевой системы.
Лидия рассказывала команде о последних договоренностях с Донаги. Команда Викрама позавчера подготовила сводку по развилкам как самого проекта, так и по развилкам технических решений в нем. Благодаря информации этому Лидии удалось получить ряд послаблений и отсрочек, так что за столом все понемногу выдыхали по мере того, как она снимала одну задачу за другой из бэклога. До этой минуты мало кто понимал, какое напряжение накопилось в проекте за последний месяц. Общая часть совещания закончилась, остались только руководители секций, которые быстро получали свои указания и уходили. Последним оставался Викрам. Лидия быстро проинструктировала его по поводу задач, которые надо было завершить за неделю, и потом сказала: "Не уходи, я сейчас". Вернулась через две минуты с двумя чашками травяного чая и тарелочкой печенья. "Я последние пару дней думала про то, что ты мне говорил насчет фактов и объектов и все равно не до конца понимаю как вся эта теория помогает принимать решения в условиях неопределенности и неполной информации. И уж тем более мне непонятно, как все это приводит к тому, что такие разные картины мира разных людей согласуются между собой. Если уж что я и понимаю про людей, так это то, что достаточно большие группы не договорятся между собой никогда, всегда будут противоположные мнения. Я верю, что за твоими словами стоит более-менее цельная логика, но пока ее не поняла".
"Прежде, чем мы разберемся с тем, что такое неопределенность, давайте поймем, а что такое решение вообще?" - Викрам взглянул на нее с легкой иронией. Лидия откусила печеньку, запила чаем и задумалась. Интуитивно все было понятно, но четкая формулировка ей в голову не приходила. "Хорошо, давай свой вариант", - сдалась она секунд через десять размышлений. "Решением может называться как сам процесс так и результат выбора цели и способа действий. Фон Нейман называл решением акт выбора из заданного набора альтернатив по заданному критерию. Я обычно говорю, что решение заключается в выборе или корректировке цели, оценке ее достижимости и выборе такого курса действий, который вызывает наименьшее противодействие со стороны стейкхолдеров. Другими словами, решение не то, чтобы должно полностью удовлетворять интересы, оно скорее должно подходить им, не вызывать отторжения. Стейкхолдеры не должны быть довольны решением, хорошее решение - это всего лишь приемлемое решение". "Ты знаешь, по такому критерию в Any Corp просто гении принятия решений, у нас любое решение компромиссное настолько, что из него вся суть уходит". "Решение без жертвы решением не является, мы об этом говорили, когда обсуждали развилки. Хорошо, уточню этот момент отдельно.
Решение - это процесс и результат выбора или корректировки цели орг.единицей, оценки достижимости этой цели, исходя из имеющихся у нее орг.способностей и ограниченных ресурсов, и выбора курса действий по достижению цели. При этом выборы цели и курса действий по достижению цели делаются из набора альтернатив с оценкой этих альтернатив по каким-то заранее заданным критериям. Набор альтернативных целей и курсов действий составляется таким образом, что каждая альтернатива имеет оценку по каким-то параметрам лучше, а по каким-то хуже других альтернатив.
Другими словами, не должно быть ситуации 'девочка, ты хочешь гулять и мороженное или тебя в угол поставить?' Альтернативы должны находиться на пространстве выборов, где мы ухудшаем одни характеристики за счет других. Если можно улучшить обе характеристики, надо просто их улучшить. Чтобы начать правильно думать о развилках и пространстве выборов, надо понять, что такое прагматическое мышление и факт-событийная модель мира. Но для этого надо перевернуть обычные представления о том, что такое факт, объект, событие и начать смотреть на мир совсем иначе. Чтобы понимать, что такое альтернативы, надо научиться видеть такую штуку как поток.
Поток (flow, stream) - пространственно-временная структура составного объекта, для которого справедливо следующее:
- у каждой части этого составного объекта есть начальное и целевое состояние
- все преобразования между начальным и конечным состоянием непрерывно происходят в границах этой пространственно-временной структуры
- составной объект и все его части полностью входят в область обсуждения без исключений.
Примеры: движение поезда Сапсан 752/761 (один и тот же подвижной состав), калиево-натриевый насос, поток материалов и автокомпонентов при проектировании и производстве автомобиля, покупательская петля в торговом зале магазина.
Контрпримеры: обмен товарно-транспортными накладными между организациями, передача данных между ИТ-системами, движение балки моста под нагрузкой.
Как видите, чтобы понять, что такое поток, надо понять, что такое объект, что такое состояние объекта и как все это связано с поведением объекта, его свойствами. Вообще, с объектами дело обстоит все не так просто, как кажется. Не такое это простое дело - найти правильный объект".
Викрам подошел к своему столу, достал из рюкзака блистер с таблетками и спросил Лидию: "Какой это объект?" "Таблетка, блистер, упаковка. Тут их три, они вложены друг в друга, таблетка является частью блистера, блистер является частью упаковки", - быстро ответила Лидия. "Типично менеджерский взгляд, - Викрам получил ожидаемый ответ и дальше он шел на автомате. - Конечно, он верный. И в самом деле тут есть объект таблетка и производные от него. Но это выделение объекта-как-модуля, логистический и производственный аспект выделения объектов. Менеджерам важно учитывать изготовление и отгрузку, а для этого нужно выделять объекты-как-модули. Но вот какой объект здесь увидит врач или бактериолог?" Лидия задумалась на пару секунд и выдала: "Доза, дозировка". "Да, врач увидит здесь другой объект - разовую дозу и курсовую дозу лекарства. Это выделение объектов-как-компонентов. Выделять объекты-как-компоненты обычно намного сложнее, в школе нас этому не учат. Все легко видят такие объекты как отель, самолет, магазин или навигатор, и могут легко сказать про свойства и возможные состояния этих объектов. Мы легко представляем себе жизненный цикл самолета или отеля, канал Дискавери нам в помощь. Но мы не обращаем особого внимания на набор состояний заполненного номера и не можем с ходу сказать какие свойства у него есть. То же самое с посадочным местом в самолете, клиентским визитом в магазин или парикмахерскую или с поездкой по навигатору. Компоненты увидеть намного сложнее, чем модули. Хотя бы потому, что компоненты существуют только во время использования системы, а модули как часть потока появляются намного раньше, в стадии изготовления. Из-за важности и сложности выделения компонент в хорошем методе принципам выделения и компонент и модулей уделяется много внимания. Если вернуться к таблеткам, то можно подметить интересный факт - именно компонентное выделение объектов по большей части определяет модульность. То есть сколько будет в таблетке действующего вещества, сколько таблеток в упаковке - все эти решения проектировщиком принимаются прежде всего исходя из того, для чего и как будет использоваться лекарство. Но пример с лекарством еще достаточно простой, а вот если взять бактерию, то ситуация станет сложнее. У бактерий как объектов есть свойство устойчивости к антибиотикам. То есть некоторые антибиотики вообще никак не влияют на жизнедеятельность некоторых штаммов бактерий, хотя другие штаммы той же самой бактерии от этого антибиотика погибают. Интересно тут то, как у бактерии появляется устойчивость к антибиотикам. Вначале появляется одна-единственная бактерия, которая устойчива к лекарству. А затем в штамме происходит горизонтальный перенос генов устойчивости и вот через какое-то небольшое время уже весь штамм становится устойчив к лекарству, оно перестает на него действовать. Другими словами, когда мы подбираем лекарство для лечения или проектируем антибиотик, то объектом у нас выступает не бактерия, а штамм". "Это терминологические тонкости, которые никак не влияют на наши действия", - Лидия была скептична. "Смотрите, одним из механизмов защиты бактерий от лекарства может быть закрытие колонии защитной пленкой. Колония просто закрывает себя куполом и лекарство не может добраться до бактерий. Этого свойства у отдельной бактерии нет, оно появляется только у штамма. Так что правильный выбор объекта крайне важен. В начале проекта системные инженеры довольно много времени тратят на формирование наиболее подходящего набора объектов в области обсуждения, потому что правильный выбор объекта во многом определяет ход мысли. В особенности сложно дело обстоит с проектами НИОКР. Там вообще бывает непонятно, какой объект мы изучаем, его зачастую приходится конструировать в ходе исследования. Для этого исследователи создают новые понятия, которые могут описать объект и его свойства, и затем проверяют верность такой концептуализации. В качестве нейтрального примера приведу пример с витамином С и цингой. Витамины как концепт открыли чуть больше ста лет назад, хотя про их действие, про их характеристики, знали еще в 15 веке".
Викрам достал телефон, что-то искал несколько секунд и включил личного помощника, который стал зачитывать найденный Викрамом текст: "Как люди 500 лет умирали от цинги, при этом владея знаниями, как лечить эту болезнь.
В 1500 году до н.э. египтяне знали, что если будешь есть печень, то будешь лучше видеть в темноте. Они не подозревали про существование витамина А, но уже понимали как он действует. Точно также европейцы в 1400-х годах не подозревали про существование витамина С, но знали, что свежая еда и цитрусовые предотвращают появление цинги.
Но дальше произошло то, что можно было бы назвать комедией ошибок, над которой не особо посмеешься. Европейцы, которые вообще-то считают себя довольно умным народом, по меньшей мере семь раз забыли и переоткрыли этот секрет борьбы со страшной болезнью, которая унесла жизни более миллиона моряков, больше, чем погибло во всех морских сражениях за тот же самый период. А ведь цинга бушевала и на суше, в осажденных крепостях, тюрьмах, удаленных поселках. Васко де Гама, первооткрыватель Индии, а затем Губернатор Португальской Индии и вице-король Индии, из-за цинги потерял 100 человек своей экспедиции из 160.
Почему же европейцы, которые знали как лечить цингу в 1400-х, переоткрывали это знание в 1593, 1614, 1707, 1734, 1747, 1794, пока, наконец, в 1904 году не выяснили все окончательно? Ответ простой - плохая коммуникация и неважное состояние науки.
Люди - это одни из немногих животных, организм которых не вырабатывает витамин С. Но при нормальном питании мы получаем его в достатке с пищей, и его запаса в организме хватает на 4 недели. Если мы будем только тратить запасы, например, питаться только консервами и макаронами, то через 4 недели может начаться цинга. Тонкость здесь заключается в том, что витамин С разрушается при высокой температуре, например, при готовке и на открытом воздухе, так что в обработанной еде или в еде, которая долго хранилась, вы его не обнаружите. В 1400-х годах итальянские моряки знали, что цитрусовые фрукты предотвращают появление цинги, а португальские моряки даже выращивали апельсиновые деревья на островах, которые лежали вдоль морских путей, но это знание было впоследствие утрачено.
Но что же случилось с повторными открытиями этого знания в 1593, 1614, 1707 и далее? Ведь цинга уносила жизни еще сотни лет подряд? Почему великие державы потеряли 1,000,000 подготовленных моряков от этой болезни, все время владея простым и доступным секретом ее лечения? Открытия 1593-1794 были просто проигнорированы, потому что шли вразрез с общепринятым тогда представлением, что цинга вызывалась “внутренним гнилостным разложением, вызванным плохим пищеварением”. Да, я думаю, мало у кого хорошо пахло изо рта в то время, в эту идею было легко поверить. Британский флот в начале 19 века использовал лимоны для профилактики и лечения цинги, но это знание было утрачено в 1867 году, когда лимоны заменили соком лаймов. Сок - это обработанный фрукт, а если его еще подержать в тепле и на свету, и хранить в медных трубках, то витамина С в нем почти не останется. Но утрата соком лаймов лечебных свойств прошла незамеченной потому что корабли стали быстрее, плавания стали короче, питание на суше получше, и моряки просто не успевали потерять накопленные в организме запасы. Кто-то в снабжении, наверное, получил премию и звездочку за оптимизацию, а флот приобрел скрытую проблему. В длительных морских походах моряки продолжали умирали от цинги, и сок лаймов не спасал. И тогда выдвинули новую теорию, которая говорила, что цинга вызывается пищевым отравлением из-за некачественной пайки консервных банок, а некоторые даже говорили что причиной цинги был упадок боевого духа или плохая гигиена.
В 1907 году провели эксперименты на морских свинках. Это был удачный выбор подопытного животного, они точно также как и люди не вырабатывают витамин С в организме и поэтому у них может развиться цинга. И когда обнаружился факт, что свежая еда спасет от цинги, идея, наконец, прилипла и овладела общественностью. Мы все теперь знаем, что надо есть свежую пищу и пить витамин С. Цинга причинила огромное количество страданий, унесла множество жизней, и привела к огромным последствиям для человечества, потому что трудно ожидать милосердия к туземцам от команды моряков, у которых половина товарищей умерла на их глазах в страшных мучениях. И что печально, все это время люди владели знаниями по тому, как легко и просто лечить эту болезнь.
Что интересно, Петр 1 при создании морского флота организовал поставку лимонов и апельсинов с юга Европы, хотя обеспечение флота клюквой по американскому примеру или квашенной капустой по немецкому могло решить проблему гораздо проще. В 1932 году за окончательное доказательство того, что цинга вызывается недостатком витамина С, дали Нобелевскую премию."
"В наших проектах ничуть не лучше, - сказала Лидия и усмехнулась. - Мы тоже все время повторно открываем уже имеющиеся знания".
Викрам улыбнулся и продолжил рассуждение. "Опять-таки, налицо были факты - симптомы цинги, плохое питание, но если в голове нет понятия о витамине С, то эти факты между собой никак не связаны. А если они не связаны, то нельзя сделать ничего полезного, того, что предотвратило бы цингу. Связь между понятиями идет либо через эмпирики типа той, что лимоны спасают от цинги, либо через объекты, понятия, концепции, типа той, за которую дали Нобелевскую премию по медицине в 1932. Витамин С - это понятие, который связывает причинно-следственной связью дефицит этого витамина в организме с проявлениями цинги. Если у вас есть такое понятие, вы можете не просто пользоваться эмпириками, вам не надо как Петру 1 везти апельсины из Италии для Балтийского флота за бешенные деньги, вы можете просто дать им квашенной капусты или клюквы да даже простого картофеля, потому что понятие витамина привязано к целой группе объектов, к пространственно-временной структуре, экстенту. Ваше мышление дисциплинируется, появляется переносимая между различными ситуациями логика планирования и действий. Вам не нужны знания того, как действовать в конкретной ситуации с заранее известными объектами, вам не нужны эмпирики, вы их создаете по месту и по необходимости из понятий. Понятия и логика связей между ними собирают в себе факты, но они же позволяют вычислить другие возможные факты и понять последствия действий. Другими словами, системные инженеры не просто используют какие-то концепты для решения задач, они всегда измеряют корректность использования концепта, делают его операционализацию через какой-то измеримый операнд. Например, корректное применение концепта витамина С очевидно должно снижать количество случаев заболеваемости цингой. Применение концепции вакцинации должно снижать количество заболеваний и особенно количество эпидемий. Применение концепции социальных сетей должно увеличивать количество слабых связей между людьми. Это все и есть операционализация понятий, перевод абстракций в численно измеримые факты".
"Знание немногих принципов освобождает от знания многих фактов? Так?" - Лидия улыбнулась. Сейчас все всё знают, вопрос не в знаниях, а в умении применять концепции к реальной жизни, строить модели. Под моделью я подразумеваю структуру, которая описывает область обсуждения. Модель состоит из концептуальной схемы (структуры фактов) и набора базовых фактов, относящихся к области обсуждения. Но мало построить модель, надо потом еще и действовать в соответствии с тем, что эта модель предсказывает. У людей это плохо получается, даже в тех случаях, когда модели общепризнаны, как, например, схемы сбалансированного питания и соблюдение режима физической активности. Мы в массе своей не применяем эти самые общепризнанные истины в реальной жизни. Мы плохо и нерегулярно питаемся и мало двигаемся. Что уж говорить о сложных моделях, которые заложены в управлении проектами или управлении рисками, их понять еще сложнее, а следствия их применения к реальным проектам еще менее приятные, чем в случае с диетой и физкультурой. Надо ведь признавать ошибочность принятых решений, менять контракты и обязательства, вести крайне неприятные разговоры и принимать трудные решения. Поэтому знать люди знают, но вот применять к своей жизни не спешат. Поэтому скорее речь идет о том, что вначале надо начать правильно действовать, а потом структурировать опыт в правильный метод. В общем, основы андрогогики. Это кадетов можно загнать на 5 лет в военное училище, дать им основы большого метода, потом пять лет службы и загнать 25-летних толковых офицеров в академию, где дать уже метод в полном объеме. И вот тогда, спустя лет 15 подготовки, какой-то существенный процент прошедших такой путь будет владеть методом. Дальше вопрос нагона лидов в эту воронку. Но этот путь не годится для коммерческих компаний, у нас среднее время работы 18 месяцев, мы не можем насаживать метод целиком и сверху. Мы можем его только проращивать снизу и только в том, объеме, который люди считают полезным, нужным и применимым. Взрослые не будут учить то, что считают ненужным. Черт, я когда смотрю статистику по просмотрам на своем канале в YouTube четко понимаю, что у меня есть 15 секунд, чтобы объяснить почему зрителю надо потратить еще 15 минут на просмотр ключевой части объяснения. Дети, по крайней мере у нас, могут годами учить английский или математику потому что так сказали взрослые. Со взрослыми такой трюк уже не прокатывает". Викрам взял полную руку маркеров и стал рисовать на флип-чарте диаграмму и попутно объяснять.
Системный подход - это набор совместимых техник для:
- построения мультидисциплинарной модели организационно-технического решения, которое решает определенную проблему или набор проблем в области обсуждения, причем каждая модель отдельной предметной области, из которых состоит мультимодель, связана минимум с одной другой моделью предметной области через операционализованный операнд.
- научно обоснованного выбора операционализованных операндов, которые представляют некоторые концепции в виде численно выраженных базовых фактов области обсуждения. Эти концепции представляют объекты сквозного потока создания, развертывания, использования и вывода из эксплуатации определенного организационно-технического решения в прогнозируемом или имеющемся операционном и бизнес-контексте.
- проверки применимости полученной мультимодели к разделяемой стейкхолдерами цели и курсу действий по достижению цели по изменению реального, объективного мира
- организации разделения работ и коммуникации стейкхолдеров по проекту изменения реального мира с учетом множественности сценариев достижения целей, имеющихся альтернатив, предпочтений и интересов стейкхолдеров.
Рассуждения и выводы в системном подходе всегда иерархичны и их можно структурировать по пирамиде Минто.
Приведу пример организационно-технического решения. Один из моих первых проектов, еще во время дипломного проекта, была комната для допросов в полицейском участке. Ключевое требование там было с одной стороны возможность записи всех разговоров и наблюдать за интервью, а с другой отсутствие возможности подслушивать разговоры подследственных с адвокатами при выключенной записи. Технически это была простая задача, но вот организационная часть решения получилась не такой простой. Из-за того, что полиция имеет не самую лучшую репутацию, люди просто не верили, что их не подслушивают и отказывались вести разговоры в этом помещении. А конвоирование туда-сюда резко ухудшало ситуацию с загрузкой комнаты для допросов. И тогда мы сыграли ровно на этой вере в коррумпированность полицейских - мы открыли анонимный ящик, на который полицейские могли скинуть доказательства того, что комнату незаконно прослушивают. Кто мог доказать такой факт, получал сумму денег, достаточную, чтобы выйти на пенсию. Логика была такая - если реально можно прослушать, то обязательно найдется такой полицейский, который воспользуется этим призом. Но поскольку такой технической возможности не было, наша ставка была надежной, и при этом мы быстро создали необходимый уровень доверия к нашему варианту решения. Сама комната и оборудование была техническим решением, а анонимный ящик и премия за whistle-blowing организационным решением.
Когда я говорю про научно обоснованный выбор, то подразумеваю постоянное уточнение модели. Например, при наблюдении звездного неба, Луны и Солнца без приборов птолемеевская модель хорошо и точно описывала и предсказывала движение и положение звезд и светил. Но по мере уточнения набора базовых фактов, траекторий движения, эта модель все больше усложнялась до тех пор, пока не стала полностью непрактичной для целей навигации. И тогда ей на смену пришла гелиоцентрическая модель Коперника. В реальном бизнесе такие штуки постоянно случаются с продуктовыми и маркетинговыми гипотезами и в области управления рисками - по мере пополнения набора базовых фактов существующие модели теряют свою предсказательную и описательную силу и нам надо их уточнять.
И тогда мы приходим к идее коллективного мышления и моделирования области обсуждения. И практика коллективного мышления и моделирования требует от нас особого, прагматического общения. В прагматическом общении у нас каждая коммуникация имеет смысл в том плане, что приближает нас к созданию целевой системы. И чтобы обсуждать прагматическое общение, нам нужен семантический треугольник.
Как строятся модели коллективного мышления по достижению общей цели
"Вы замечали, в каких случаях возникают холивары и споры о терминах? Они возникают в тех случаях, когда у людей нет общей цели, нет привязки к конкретному изменению куска мира. Как только людям надо согласовать действия по достижению разделяемой цели, они сразу начинают договариваться. А если цели нет, начинается бесконечное уточнение терминологии, определений, находятся смысловые оттенки, которые вдруг становятся предельно важными. Мы описываем метод для того, чтобы внутри какой-то коллаборации договориться по тому, как мы проектируем и строим определенный класс систем. И при создании метода мы используем прагматический подход. Неважно, что люди думают, важно, что они делают. И если люди в одной и той же ситуации ведут себя одинаково, то можно сказать, что они думают одинаково. Нет различий в действиях - нет различий в мышлении". "Другими словами, метод должен быть привязан к конкретным фактам, которые важны для участников проекта?" "Именно так. Для людей мир есть не совокупность объектов, а совокупность фактов. Но что такое факт? Это просто любое выражение, которое бизнес считает истинным.
То есть у нас есть такой объект, как положение вещей, ситуация. Это положение вещей может быть фактическими обстоятельствами, то есть происходить прямо сейчас, быть актуальным событием. Либо оно может быть каким-то целевым. Проще всего рассматривать положение вещей как какой-то набор событий, где события - это момент создания или появления объекта, перехода его в определенное состояние. Какой-то набор событий характеризует начальное, целевое и промежуточные состояния объекта, которые и образуют поток.
Область обсуждения - это совокупность конкретных и абстрактных объектов, которые относятся к области реального мира, и которые выбраны в соответствии с интересом, который эти вещи представляют для целевой системы и ее окружения. Другими словами, вот у нас есть целевая система, есть ее окружение - системный контекст, операционный контекст и бизнес-контекст, который еще называют организационным контекстом. Для того, чтобы описать, как мы будет проектировать и строить целевую систему, как она будет работать, с чем взаимодействовать, и какую пользу она принесет организации, которая приобрела эту систему, мы выделяем какой-то набор конкретных объектов в реальном мире и абстрактных, возможных к существованию в области обсуждения объектов. Допустим, если мы строим дом, то даже если мы еще не купили участок, не вырыли котлован и не залили фундамент, мы все равно можем обсуждать строительство дома как будто эти объекты существуют, хотя существуют они только в логическом пространстве конкретного метода. Метод определяет, какие физические и абстрактные объекты будут составлять область обсуждения, universe of discourse и как эти объекты моделируются. Все это делается для того, чтобы все люди занимались логически обоснованной, полезной работой. А то часто подходишь к человеку, начинаешь разбираться, чем он занят, и выясняется, что работа, которую он делает, не нужна для получения результата. И тогда я слышу в ответ - ну, по крайней мере я делаю что-то. Меня этот подход поражает, это все равно что я приду к доктору и пожалуюсь на то, что у меня в ухе стреляет, а он начнет мне ногу отпиливать со словами - ну, по крайней мере я делаю что-то". "Давай я приземлю для себя понимание. Правильно ли я поняла, что область обсуждения - это все то, что хранится в PLM? Все объекты PLM - это и есть область обсуждения?"
Викрам помотал головой: "PLM - это знаки, выражения. Содержание PLM - это модель области обсуждения, это то, что находится слева от пунктирной линии. Сама область обсуждения находится в реальном мире, в объективной, а точнее в межсубъектной реальности и в абстрактных логически существующих объектах".
"А чем тогда такие абстрактные объекты отличаются от понятий, концептов? И почему тогда концепты находятся слева от разделительной линии, в описании проекта, а эти абстрактные объекты справа, в области обсуждений?" "Ключевое отличие в том, что у объектов есть состояние, с изменением которого связаны события. У концептов состояний нет и событий, связанных с концептами тоже нет. Я, по крайней мере, не могу придумать. У объектов есть пространственно-временная структура, объем, а концепты находятся в голове, по ним не постучишь. Даже если мы говорим про объекты с логическим существованием, у которых прямо сейчас нет никакого объема, все равно мы понимаем, что если сделать некоторые действия по созданию этих объектов, то у них появится объем. Но у самих объектов нет смысла, нет назначения, функции. Смысл, назначение и функция у объектов или событий появляется тогда, когда мы привязываем к ним понятия, именно понятия позволяют нам видеть смысл в событиях, в какой-то ситуации.
Например, если мы говорим про ИТ-системы, то там есть куча абстракций, такие как маршрутизация трафика, технологические стеки, интерфейсы, бизнес-объекты, классы, фасады, виртуальные машины, да куча всего. При этом физически, как объекты, есть только электрические цепи, которые включаются, выключаются или переходят в состояние высокого импеданса. Компьютеры как таковые ничего не вычисляют, это просто умно сконструированные машины с кучей различных состояний, и вот эти самые состояния мы концептуализируем, осмысливаем как результат вычислений. Точно также, как механические калькуляторы ничего не вычисляли, там просто крутились шестеренки, а люди просто интерпретировали какое-то положение шестеренок как результат умножения".
Лидия посидела, подумала и сказала: "Можно было сказать намного проще.
1. Есть какое-то состояние дел, ситуация.
2. У конкретных людей есть по поводу этой ситуации предложение что-то с ней сделать.
3. Эти люди формулируют свою позицию по поводу этой ситуации.
Три вершины семантического треугольника - что происходит, что конкретные люди думают по этому поводу, что они хотят предпринять и как они об этом договариваются с другими. И мы должны определиться с методом, потому что разный набор практик и процессов метода даст нам разный контекст, разные ситуации, хотя вроде бы все, что меняется - это наши договоренности по тому, как работаем. Единственное, ведь есть же и другие абстрактные объекты - производственный брак, например или справедливость. В реальности у нас есть трещина в детали или какой-то поступок и реакция на него, но в зависимости от метода это может быть, а может быть или не быть браком или справедливым решением".
"Да, такие абстрактные объекты тоже есть. Давайте на простом примере разберем? Например, возьмем отпуск. Есть Трудовой кодекс и в нем прописана такой абстрактный объект как отпуск. На конкретном рабочем месте будет конкретный промежуток времени, в котором человек будет не на работе, будет конкретный объект с пространственно-временным объемом. Но когда мы будем обсуждать график отпусков в конкретной команде, выбирать когда и кто пойдет на какой срок, мы все равно будем оперировать абстракциями - право на отпуск, продолжительность, очередность, минимальная длительность, отгулянный отпуск. Это все абстрактные объекты, прописанные в законе, с существованием которых мы соглашаемся потому что у нас здесь одинаковое понимание, одинаковые концепты. Потому что как выделяется объект в мире, неважно, конкретный он или абстрактный? Объектом мы называем что-то, на чем задерживается наше внимание. Все, что можно постичь или понять. Если мы можем понять деньги, архитектуру, команду, маршрутизацию IP пакетов и алгоритмы, то они существуют в области обсуждения нашего проекта точно также как это кресло или Солнце". "Ты меня опять запутал. Чем отличаются абстрактные объекты в области обсуждения от понятий?" "Понятия - это знания, это шкафы и полочки, по которым мы сортируем факты. Объект - это что-то доступное коллективному восприятию, пусть даже и эфемерное, абстрактное. Например, если мы совместно договоримся, что такое лояльность работодателю, архитектура, эффективность, бережливость, то мы сможем увидеть эти абстрактные объекты. Вот смотрим на какую-то ситуацию, я говорю, что это лояльное поведение и вы с этим соглашаетесь. Мы видим это разделяемое понятие в конкретной ситуации, это разделяемое понятие является частью области обсуждения. А подойдет третий человек, с которым мы не договорились что такое лояльность, и он будет с нами не согласен. Скажет, что нет, это поведение нелояльное. Объект - это какая-то часть мира, на которой несколько человек могут сосредоточить внимание". "То есть область обсуждения подразумевает смысловую согласованность стейкхолдеров? То, про что ты вчера говорил 'нет различия в действиях, нет различия в понимании'?" "Да, хотя и необязательно именно смысловую согласованность, по крайней мере непротиворечивость. Потому что если области деятельности не пересекаются, то какая разница, что другая рабочая группа себе думает, на функциональное взаимодействие это не влияет".
"Хорошо, эта часть более-менее ясна. Но ведь в проекте обсуждать приходится прошлое, настоящее и будущее, следовательно, в области обсуждения должны быть объекты прошлого, которое уже недоступно, будущего, которое не определено, и только настоящее можно обсудить, привязать к нему понятия и увидеть в области обсуждения абстрактные объекты?" "Да, тут мы вступаем на сложную территорию", - признался Викрам. "То есть это была еще и простая часть?" - усмехнулась Лидия. Викрам улыбнулся и продолжил: "Для того, чтобы обсуждать прошедшие и будущие события, мы должны разделить область обсуждения еще на три части - на настоящее, на прошлое и на будущее. В системной инженерии говорят, что у ситуации есть признак актуальности. Ситуация является актуальной, текущей, если события происходят прямо сейчас и стейкхолдеры потенциально могут проверить ее, сформировать свое мнение по поводу ситуации, привязать понятия, договориться о том, какие понятия должны быть разделяемыми, войти в онтологию, стать частью коллективного мышления. Хотя если это космический корабль на орбите или как в нашем случае автомобиль, который уехал за две тысячи километров, то есть определенные сложности с практической пользой от признака актуальности ситуации. В таких случаях мы в рассуждениях все равно опираемся только на модели". "Подожди, Викрам, это что, получается, актуальность это когда говорили-говорили про Брекзит, воображали себе что-то, а потом он раз, произошел, и все оказалось совсем не так, как люди себе представляли, и они начали переосмысливать свои слова?" "Ну, можно взять и более банальный пример, чем Брекзит, например, рождение детей. Можно что угодно воображать и как угодно готовиться к их появлению и воспитанию, но в реальности путь каждого родителя особенный. Пример Брекзита, впрочем, тоже подойдет. Так вот, мы делим ситуации на текущие и не текущие. По большому счету, когда мы говорим про текущую ситуацию, мы говорим, что она межсубъектна, что каждый человек может пойти и посмотреть своими глазами, составить свое мнение по поводу того, что происходит. И, конечно, когда мы говорим, что онтология проекта привязывается к реальным вещам, в первую очередь под этим подразумевается, что каждое понятие в конкретной голове соотносится с конкретными и абстрактными объектами в области обсуждения. Что метод и его описание, которые находятся слева от пунктирной линии, как-то соотносятся с областью обсуждения, которая находится справа от пунктирной линии".
Они посидели пару минут в тишине. Время уже было позднее и Викрам поглядывал на часы. "Две вещи пока непонятны и кажутся излишним переусложнением:
1. Зачем различать семантику и концепты? Зачем нужно отдельно говорить про понятия, если общение все равно идет через символы, диаграммы, тексты?
2. Почему мы говорим, что вещи в области обсуждения существуют, хотя фактическое существование физических объектов в текущий момент и логическое, вероятностное существование объектов в будущем явно разные штуки? Область обсуждения становится такой свалкой объектов, в которую намешано все в кучу".
Викрам задумался на целую минуту, Лидия пошла к кофе-машине, налила себе чашку эспрессо и села в кресло. Викрам крутил в руке маркер и что-то задумчиво бормотал под нос.
"Вся эта громоздкая конструкция нужна только когда у нас достаточно большой проект. В случае простого проекта, когда у нас есть 20 человек, считая представителя заказчика, углы смысла и выражения схлопываются, у вас получается набор ситуаций, событий на одном конце и выражений, которые описывают эти ситуации и события на другом конце. Все 20 человек, в пределах малого числа Данбара, могут настолько плотно между собой общаться, что смысл выражения всем очевиден. Но если у вас есть проект на 1,500 человек, как у нас, то в нем неизбежно появляются различные сообщества. В системной инженерии говорят, что есть смысловые сообщества и речевые сообщества. Допустим, у нас есть фул-стэк разработчики на Java, часть из которых сидит в Германии, а часть в России. Они говорят об одних и тех же вещах, оперируют одинаковыми смыслами, но при этом терминология у них различная, хотя бы в плане немецкого и русского языка.
И другой пример. Скажем, бизнес-аналитики используют один и тот же набор терминов: проект, процесс, сервис, орг.единица, бизнес-функция. Но при этом если столкнутся два бизнес-аналитика разных школ, то неизбежно возникнет холивар по поводу некоего правильного понимания термина процесс, проект и т.п. В таких случаях нам и нужна структурированная коммуникация, управляемая семантика. С помощью семантического треугольника мы можем избежать спора о терминах, просто выводя смысл выражения из контекста и координировать действия в привязке к реальному миру". "Викрам, давай конкретику без всей этой философии, пожалуйста".
Викрам подошел к флип-чарту, перевернул на чистый лист и стал рисовать: "Вот у нас есть Скрам-команды, каждая из которых работает над своей частью системы. У каждой команды есть своя онтология, свое пространство смыслов и своя терминология, свой метод работы. При этом пространство смыслов и словарь проекта, терминология, у них различается, потому что одни занимаются аппаратной частью, вторые мехатроникой, третьи пишут обработчик реального времени, четвертые занимаются виртуализацией и бэк-апом, пятые тестируют и ставят на производство и т.д. Теперь вопрос, как организовать или, как у вас тут принято говорить, фасилитировать собрание Agile Release Train во время PI?" Тут Лидия заинтересовалась потому что бардак на Program Increment был болезненным местом в любом крупном проекте.
"Суть Скрама в том, что на каждом спринте мы обсуждаем изменившуюся область обсуждения, причем дельта изменения у нас имеет признак актуальности. То есть мы обсуждаем не изменившееся описание системы и ее контекста, а изменившийся реальный мир, поэтому нам гораздо проще привязывать разные смыслы и терминологию к реальности. Вместо абстрактной строчки в плане проекта 'мы сделаем то-то и то-то' у вас есть реальная штука, которую можно обсуждать. Проверяемый кусок межсубъектной реальности. И когда разные стейкхолдеры в разных командах наблюдают эту дельту области обсуждения, у них в голове рождаются смыслы. То есть у них в голове появляются:
- понятия своей предметной области - бухгалтерские проводки, проектные ресурсы, клиентскую петлю или кассовый разрыв;
- факты, фиксация событий, которые произошли в проекте, с какой-то ролевой позиции. Приход товара на склад (событие) порождает множество фактов - изменение остатков, движение товара, изменение баланса, появление накладной. Количество фактов, которое порождает событие, зависит от количества точек зрения в проекте;
- правила, универсальные обязательства команды по отношению друг к другу;
- вопросы, уточнения, которые им нужны, чтобы конкретизировать понятия, уточнить классификацию вещей, которые они увидели;
- смыслы выражений.
Смыслы выражений, в свою очередь, делятся на три типа - факты и правила.
Поэтому когда мы говорим про смысл, как про что-то, что подразумевается под словом, диаграммой или выражением естественного языка, то смысл будет сводиться к одной из четырех вещей - понятию, факту, правилу или вопросу. Я еще раз дам определения:
Понятие - это единица знания, созданная уникальной комбинацией характеристик (по ISO 1087-1).
Смысл выражения - смысл выражения, которое не является парадоксом и которое не изменяет смысл после перефразирования или перевода, включая замену слов на синонимы.
Вопрос - смысл вопросительного выражения. Надо разделять вопрос в как формулировку в каком-то языке и вопрос как смысл. Если мы зададим вопрос на двух языках, скажем, английском и немецком, то у нас будут две формулировки, два синтаксических вопроса, при этом у обоих формулировок будет один смысл, один семантический вопрос.
Факт - смысл выражения, которое считается истинным.
Правило - смысл выражения, которое обязывает к чему-то.
Приведу пример. На последнем PI мы обсуждали аппаратный API и разработчики "железа" говорили, что пользоваться надо только им, все остальные механизмы обращения к аппаратным ресурсам они перестают поддерживать. В данной коммуникации используются три концепта - 'API', 'аппаратный ресурс', 'другие механизмы обращения к аппаратным ресурсам'. Устанавливается ряд фактов - существует API, существуют другие механизмы обращения, кроме API, программисты пользуются и тем и тем. Устанавливается правило - программисты должны использовать только API. Можно задать уточняющий вопрос - а за какой срок надо перенести все механизмы работы с "железом" на API? Вся эта коммуникация направлена на прагматический аспект - что должен сделать каждый конкретный стейкхолдер после того, как эта коммуникация произошла? Прагматическая коммуникация всегда направлена на то, чтобы изменить чье-то поведение. Если поведение в результате коммуникации не изменилось, то она была неуспешной.
Отвечаю на ваш первый вопрос: разделение понятийного аппарата и семантики решает задачу того, что разные языковые сообщества используют различные термины для обозначения одних и тех же вещей и смыслов. Использование разных терминов не должно блокировать коммуникацию, мы все равно должны делать общее дело даже если говорим на разных языках и используем разную терминологию. Нас не должны смущать эти различия в терминологии, мы должны оперировать смыслами и координировать конкретные действия, распределять работу, обязанности между членами команды. Мы не должны цепляться к словам и требовать от всех использования одного самого правильного словаря. Хотя и неплохо иметь единую терминологию внутри проекта.
Теперь поговорим про логическое и физическое существование объектов в области обсуждения. Объекты в области обсуждения могут находиться в прошлом, настоящем и будущем. Скажем, мука существовала раньше, хотя сейчас она часть булки, а если оставить булку во влажном и теплом месте, то булка покроется плесенью. Булка как объект проверяема, вот она лежит на столе. Тому, что булка была сделана из муки, есть свидетельства, хотя самой муки уже нет, она превратилась в булку. И мы понимаем, что если булка будет заражена грибком, то на ней вырастет плесень. Такая булка с плесенью находится в возможном мире будущего. И если с прошлым и настоящим все более-менее понятно, то вот с тем, откуда берется логическое существование булки с плесенью в возможном мире будущего, стоит поговорить отдельно. Для этого мы используем разделение объектов в области обсуждения на цели и средства достижения целей. Орг.единицы при этом - это те агенты, которые определяют эти самые цели и средства достижения целей. Принятие решений и заключается в определении этих целей и средств их достижения.
Для того, чтобы сделать работу мы объединяемся в организационные единицы - предприятия, организации, комитеты, проектные группы, Agile release Trains и т.п. Орг.единицы фиксируют какое-то текущее состояние и устанавливают конечные цели своей деятельности. Для проекта это будет AS IS и TO BE, у коммерческого предприятия есть набор стратегических целей, некоммерческая организация имеет миссию и видение. Для того, чтобы достичь этих конечных целей, орг.единица определяет средства их достижения. Конечные цели описываются в двух аспектах - какого-то идеального состояния, видения, и желаемого достижимого результата, который можно описать по SMART. Средства достижения целей уточняются:
- приказами, которые поддерживают достижение желаемого результата;
- стратегией и тактикой;
- и комплексом организационных способностей.
Что такое орг.способность? Вот есть орг.единица "Отдел проектирования бортовой электроники", у нее есть какие-то компетенции, например, компетенция проектирования высокочастотных печатных плат 12 класса точности 5 класса надежности. Эта орг.единица имеет стратегическую цель, на пути к которой есть проблема. Например, надо спроектировать такую плату за 4 недели, а они такой работы раньше не делали. Если существует такой сценарий, при котором компетенция решает эту проблему, то говорят, что у орг.единицы есть способность. Например, если есть такой план проекта, который позволяет спроектировать печатную плату 12/5 за 4 недели, то говорят, что у орг.единицы есть способность "Проектирование бортовой электроники по SLA12/5/4". Если говорить очень упрощенно, то орг.способность = компетенция + сценарий (бизнес-процесс, типовой проект, ноу-хау).
Запомнить это можно так:
«Орг.единица А может пилить» — это не способность, это навык. «Орг.единица А может перепилить рельсу зубочисткой в условиях полярной ночи» — это способность, компетенция в системном окружении. Онтика «наличие рельсы в ночи» — констатация возможности для орг.единицы А реализовать свою способность.
«Возможность» относится к конфигурации окружения, «компетенция» — к конфигурации орг.единицы, а «способность» — к их пересечению.
У орг.единицы обычно есть не одна орг.способность, а целый комплекс. Отдел может не только проектировать платы, но и испытывать их, отлаживать, заказывать изготовление, проводить имитационное моделирование, нагрузочное тестирование и пр.
Итак, у орг.единицы есть цели и средства. Средства - это орг.способности, тактика и стратегия, а также приказы. Для человека все то же самое: если есть цель стать системным инженером, то нужны подтвержденные компетенции, нужны планы по обучению и накоплению опыта и нужны конкретные решения по тому, идти на какой-то курс или принимать предложение по работе или нет. Если нет способностей или планов или человек вовремя не принимает решения, то цель достигнута не будет. Раньше эта формула называлась "цели - задачи - ресурсы", сейчас она немного модифицирована.
Если говорить про цели, то под целями в языке могут подразумеваться как потребности, которые есть в голове людей, так и какая-то желаемая ситуация в будущем, какой-то набор конкретных и абстрактных объектов с определенными состояниями в области обсуждения. Я полностью убираю из рассмотрения потребности, личные цели и под термином "конечная цель" всегда подразумеваю какую-то межсубъектную ситуацию в будущем, а не хотелки отдельных людей, какими бы могущественными и авторитетными для проекта они не были.
Поскольку конечная цель всегда находится в будущем, то на момент ее постановки эти объекты в области обсуждения будут иметь статус не актуального существования, а логического существования. Другими словами, исходя из логики орг.единицы, конечная цель достижима, она существует в логическом измерении. Со средствами достижения конечных целей все запутаннее, они могут как фактически существовать, иметь признак актуальности, в смысле "вот они здесь, их можно задействовать", так и существовать логически, "мы можем купить, создать, нанять необходимый ресурс".
Для того, чтобы различать статусы существования объектов в области обсуждения, системные инженеры используют концепцию жизненного цикла. В жизненном цикле выделяется ключевая стадия использования, воплощения системы. Это как раз тот период времени, когда объекты, которые составляют систему, ее части, имеют признак актуальности, доступны для восприятия стейкхолдерами. Причем межсубъектность системы проявляется даже раньше, после того, как ее изготовили. Но пока система не размещена в операционном контексте, пока все объекты области обсуждения не стали актуальными, пока стейкхолдеры не получили возможность их проверить, получить непосредственный опыт взаимодействия с ними, валидация функции системы невозможна. По большому счету, любой объект в области обсуждения имеет свой жизненный цикл, последовательность состояний, через которую он приходит в статус актуальности. Но как минимум жизненный цикл отслеживается для целевой системы.
Так вот, возвращаясь к конечным целям. Конечные цели в этой терминологии - это какое-то состояние области обсуждения после завершения проекта. Какая-то желаемая для орг.единицы конфигурация области обсуждения, набор состояний объектов, которые составляют область обсуждения. Конечная цель всегда будет состоять из воплощений объектов реального мира, конечная цель межсубъектна, стейкхолдеры могут наблюдать ее и составлять о ней впечатление. И эта конфигурация записывается минимум в трех разрезах - структуры, функции и размещения. Описание этой целевой конфигурации области обсуждения и есть основное наполнение системы управления жизненным циклом системы. PDM/PLM нужна в первую очередь для того, чтобы записать цель какого-то проекта. Записать целевую конфигурацию области обсуждения есть основная функция этого класса систем. А система управления проектом нужна для планирования и учета действий по переходу из текущего состояния в это целевое, записанное в PDM/PLM, поэтому все попытки поставить проектное управление без внедрения управления конфигурацией обречены на неудачу".
"Так это то, что произошло у нас в проекте?" "Именно. Управление проектом - это контролируемый переход к базису конфигурации, планирование и учет средств достижения конечной цели".
Конечная цель существует только в логическом измерении. Текущее состояние области обсуждения, актуальный набор объектов и цель соединены между собой средствами достижения конечной цели - орг.способностями, тактикой и стратегией и приказами. Другими словами, если на старте проекта у нас область обсуждения в основном наполнена объектами с логическим существованием, то к завершению проекта она должна быть наполнена только реальными объектами с физическим существованием и абстрактными объектами. PDM учитывает только объекты с физическим существованием и тех объектов с логическим существованием, которые им предшествуют. По факту, PDM хранит знания о том, как проектировать, закупать или изготавливать и производить систему. Можно сказать еще, что она хранит знания по жизненному циклу системы".
"А где тогда учитываются абстрактные объекты области обсуждения?" "В системе управления корпоративной архитектурой, т.н. enterprise architecture management, системе управления требованиями, requirement management system либо в управлении системной архитектурой, systems architecture management".
Цель, замысел, функция целевой системы и сервис целевой системы
"Так что целью проекта является создание или модификация воплощения целевой системы. А вот замыслом является изменение функционирования операционного контекста и бизнес-контекста, которое происходит в результате достижения цели. И поэтому метод делится на две части - первая часть его организационно-технологическая, она говорит нам как от текущей ситуации с имеющимися орг.способностями и ресурсами перейти к ситуации, где целевая система воплощена в запланированной конфигурации. Целевая система определяется по тому, что мы точно можем изменить, на что у нас хватит ресурсов и полномочий. Операционный и бизнес-контексты - это те части области обсуждения, на которые мы влияем косвенно, вставляя туда нашу целевую систему. И вторая часть метода как раз прогнозирует как изменится функционирование надсистем в операционном и бизнес-контекстах из-за того, что мы внедрили свою целевую систему. Одна из ключевых ошибок целеполагания заключается в том, что команда недостаточно точно понимает границу между целью, которую она может достичь, и замыслом, который реализуется как результат действия механик, стоящих за пределами контроля. Условно, когда врач прописывает антидепрессанты, избавление от депрессии является замыслом и оно находится вне контроля врача и пациента. Депрессия прекратится тогда, когда внутренняя биохимия придет в порядок, это может сделать только сам организм. А вот целью является исполнение плана лечения, над этим у врача и пациента есть контроль, полномочия, это они могут сделать. Вопрос, приведет ли исполнение цели к исполнению замысла?
Теперь вернемся к вопросу как в области обсуждения выделяются вещи. Любая вещь нужна нам для чего-то, мы обращаем внимание на ее существование только потому, что она играет какую-то роль в нашей жизни. В системной инженерии говорят, что объект исполняет функцию. Причем эта функция есть только в связи с другими существующими объектами. К примеру, если перенести нефтяной танкер на сто лет назад, когда не было терминалов, нефтеперерабатывающих заводов, навигационных систем, команды, которая может управляться с таким судном, то и сам танкер как вещь не существовал бы. Танкер существует только в отношении некоторого операционного контекста, системного окружения. Точно также, как слова приобретают смысл только в окружении других слов, вещи получают назначение только во взаимосвязи с другими вещами. Возьмем для примера классический пример галеона. Галеон как военно-транспортный корабль имел свое назначение и выполнял изначальную функцию только в окружении множества других вещей - команды, обученной на нем ходить, навигационных средств 16 века, портовых сооружений, грузов, арсеналов и пушек, адмиралов, которые думали о морских сражениях определенным образом, купцов, которые определенным образом торговали, рынков и т.п. Как только этот контекст изменился, появились линкоры и фрегаты. И сейчас те галеоны, которые есть, выполняют совсем другую функцию, чем они выполняли пятьсот лет назад. На них нельзя регулярно перевозить грузы и пассажиров, они просто не вписываются в существующий контекст. Точно также берем любой другой объект и его функция будет определяться операционным окружением, другими вещами, с которыми этот объект взаимодействует. Отсюда вытекает основное правило определения операционного контекста.
В операционный контекст входят все объекты и агенты, которые определяют функцию целевой системы и в отсутствии любого из которых целевая система не сможет реализовать один или несколько сценариев выполнения функции.
Под функцией я понимаю такое поведение целевой системы, которое стейкхолдеры признают полезным, которое они готовы оплачивать. Замысел проекта по созданию целевой системы подразумевает, что целевая система, которая выполняет заданную функцию, при встраивании в операционный контекст решит имеющуюся проблему и не создаст существенные риски появления новых проблем больших размеров.
Сервис - это функция целевой системы, развернутой в операционном контексте с каким-то контрактом на стоимость и производительность.
И если определение операционного контекста можно сделать с высокой степенью определенности, то где и как провести границы бизнес-контекста, для которого определяются риски, возможности и эффекты - это всегда вопрос договоренностей, компромиссов и соглашений. Бизнес-контекст очень зависит от горизонта планирования, используемых моделей оценки, микроэкономики предприятия, иногда политики и макроэкономики, экологии и прочих штук. Этот вопрос лежит сильно за границами классической системной инженерии в области предпринимательства, менеджмента и архитектурной работы с цепочками и сетями создания и захвата ценности. Для обсуждения всех этих штук одной функции целевой системы недостаточно, поэтому вводится понятие сервиса целевой системы. Типичный пример - один магазин торговой сети в городе не способен дать целевую выручку и прибыль, но если открыть их 10 или 50, то все вместе они дадут необходимый для городского окружения уровень сервиса и выйдут на целевые показатели. Цепочки создания и захвата ценности обсуждаются всегда в терминах сервисов, а не функций. Поэтому в системном подходе мы будем в основном рассматривать три составные вещи - целевую систему, ее операционное окружение и жизненный цикл как совокупность всех сквозных потоков, которые необходимы для воплощения целевой системы, которые образуют все сценарии ее эксплуатации и обслуживания, а также вывода из эксплуатации. И замысел мы будем понимать в ограниченном смысле того, что целевая система выполняет заданную функцию в операционном окружении, решает проблему. А вот достижение бизнес-эффектов и исполнение бизнес-замысла лежит в руках других ролей, системный подход здесь не сильно помогает, речь идет о социальной инженерии, практиках пиар, политике. Мы предоставляем другим орг.способность, а что они с ней будут делать, какая будет стратегия применения итогового комплекса орг.способностей нас уже не волнует.
Теперь я бы хотел вернуться к понятию решения как выбора цели и решения как выбора пути. Всего есть три компоненты принятия решений - альтернативы, ресурсы и согласование стейкхолдерами, у которых есть возможность влиять на ситуацию сейчас или в будущем. Эти решения могут быть упакованы в три вида моделей:
1. Модели требований, которые описывают альтернативы, ресурсы и согласование стейкхолдерами желаемой конфигурации целевой системы и состояния операционного и бизнес-контекста
2. Архитектурные модели, которые описывают варианты, ресурсы и интересы стейкхолдеров по реализации функции целевой системой
3. Модели жизненного цикла, которые описывают варианты, ресурсы и интересы стейкхолдеров по путям и способам реализации имеющихся согласованных наборов требований и вариантов архитектур.
Но уже поздно и мы все устали. С этой точки рассуждений и начнем нашу следующую беседу, пока, Лидия. Но Лидия уже спала в кресле и не слышала его. Викрам встал, собрал свои вещи и вышел из офиса. На небе была полная Луна, падал легкий снег. Он застегнулся до горла, накинул капюшон и зашагал в сторону метро.
