суббота, 15 декабря 2018 г.

Рождественская системноинженерная сказка “Волшебный карандаш и V-модель”. Релиз 1.0 от 03 февраля 2019.


Как нарисовать разноцветную картинку на конкурсе, где можно рисовать только одним карандашом так, чтобы за нее дали призовое место?
Надо:
а) Выявить интересы и требования заинтересованных сторон
б) Проанализировать ситуацию и найти подходящее техническое решение
в) Реализовать решение и проверить, удовлетворяет ли оно всем требованиям заинтересованных сторон.

Текст доступен в формате Word в редактурой и версткой от Константина Окорокова по этой ссылке.
Глава 1. “Помог бы уже ребенку”. Анализ бизнес-контекста и стейкхолдеров.

Системный инженер Борис сидел дома и листал новый выпуск “INCOSE INSIGHT”, где его коллеги делились опытом строительства завода по производству композитов. Бориса эта тема интересовала, он сам такой сейчас проектировал. Тут подошла его жена Юля и требовательно заявила: “Чего сидишь? Помог бы уже ребенку! Она третий день с этим школьным проектом мучается”. Борис встал и пошел к Саше в комнату. Дверь была закрыта и он постучал. “Закрыто”, - ответила Саша. “Я мистер Вульф, специалист по решению проблем,” - сказал Борис. “Кто-кто?” “Это из фильма Квентина Тарантино, древнего режиссера. Криминальное чтиво, вы на уроках истории в следующем году проходить будете, вместе с Тутанхамоном и Черчиллем”, - сыронизировал Борис. Была пятница и они посидели в баре с инженером по требованиям и руководителем проекта. Настроения заниматься с ребенком не было, но дело есть дело. Саша открыла дверь и сразу стала излагать ему ситуацию, Борис едва успел схватить бумажку и карандаш и начать записывать. Саша говорила 10 минут, но Борис исписал только пол-листка. Саша посмотрела на записи и обиженно сказала: “Ты меня совсем не слушал!” Листок был разделен на три графы, в заголовке которых были большие буквы “Ф”, “О” и “Т”. А под буквами был десяток записей. “В смысле не слушал? - удивился Борис, - я все записал. Факты, оценки, термины”. Вот что было у него написано:
Факты:
27 декабря (+2,5 нед.) будет конкурс художников.
Нарисовать надо на секретную тему, которую откроют в момент начала соревнований
Можно взять один карандаш.
Придумывать композицию можно 5 минут.
На рисование дают 60 секунд, записывают на видео процесс и фотографируют результат.
Спонсор конкурса - Инстаграм звезда и владелец дизайнерского агентства все это выкладывает на канал, за работы голосуют ее подписчики.
Победу присуждают по суммарному количеству лайков за фото картинки и видео в Инстаграмме на 19:00 следующего дня.
Оценки:
Победа будет зависеть от выбора карандаша потому что уровень исполнения у участников сравнимый, нет явных фаворитов.
Каждый карандаш диктует стиль рисовки.
Победа будет зависеть от того, насколько выбор карандаша и стиль рисовки попадет под выбранную тему.
Накрутки не разрешены, их вычислят и снимут накрученные лайки.
Термины:
Поверхность, штрих, стержень, стиль рисовки, композиция, исполнение, баллы, подписчики, Инстаграм.

“Я тебе полчаса рассказывала!” Борис не сдавался: “Если надо что-то добавить, что я пропустил, скажи”. Добавить Саше было нечего, Борис взял карандаш, чистый лист бумаги и стал рисовать. У него получилось вот что:




Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard


“Что это?” - спросила Бориса Саша. “Это онтология твоего проекта, список вещей, которые есть и важны для твоего проекта,” - ответил он. “А зачем ты это нарисовал? Что мы с этим будем делать?” Борис задумался: “Как бы тебе объяснить понятнее? Смотри, ты хочешь выиграть в конкурсе, но свои текущие шансы оцениваешь невысоко. Т.е., ты знаешь, как хочешь, и не можешь этого добиться, в этом твоя проблема. Для этого ты хочешь предпринять инженерный проект.”

“Э-э-э. Почему инженерный-то?” - “Потому что ты говорила, что тебе нужен особый карандаш, волшебный, чтобы выиграть соревнование. А новые штуки разрабатывают и делают инженеры.” “Я думала, что ученые.” “Ну, ученые тоже могут делать новые штуки, разрабатывать, например, атомную бомбу или лекарство, но инженеры обычно обходятся намного дешевле. И самое главное, я не ученый, я системный инженер.” “Ну ладно, а зачем мы эту онтологию сделали?” “Сама ты свою проблему решить не можешь, ее могут решить только другие, а им надо объяснить в чем состоит проблема и направить ход их мыслей в правильном направлении. Причем надо будет координировать работу различных специалистов. Этим и занимается системная инженерия, мы организуем работу кросс-функциональных команд. Для такой координации мы используем модель жизненного цикла, вот ее мы сейчас и будем делать, на основе онтологии. Точнее надо говорить не онтология, а онтологическое описание.” Борис взял фломастеры-текстовыделители и начал закрашивать понятия онтологического описания. У него получилась такая картинка:

“Смотри, у тебя есть три группы интересов - зеленая, желтая и голубая. Зеленая - группа интересов организаторов, желтая - группа интересов участников, голубая - группа интересов подписчиков и оценщиков. Эти три группы называются заинтересованными сторонами, в системной инженерии мы их называем стейкхолдерами. Стейкхолдеры занимаются практиками.” И Борис дорисовал картинку:

“И теперь заключительный момент - совмещаем практики и онтологическое описание.”

“Спагетти какое-то, слишком все сложно, - Саша смотрела на диаграмму с недоумением, - да и что она дает?” “Смотри, все достаточно просто. Организаторы на входе имеют Инстаграм канал и участников, а результатом их деятельности должен быть конкурс, тема и условия выступления, а также подписчики (надо контролировать, чтобы не было накруток лайков). Тема, конкурс и условия используются при проведении конкурса, но кроме этого во время проведения надо считать лайки, снимать видео и фотографии и оценивать работы. Еще надо устраивать соревнование, чтобы был накал и интерес, и в конце концов наградить участников. Остальное попробуй сама.” И Саша попробовала, с третьего раза у нее получилось и фразу: “А лайки учитываются при подведении итогов конкурса!” - она произнесла с видимым удовольствием. Но потом она все равно нахмурилась и спросила: “И все равно, что это дает?” “Ну как же? - удивился Борис, - теперь мы можем сделать две вещи - позвонить стейкхолдерам и узнать их потребности и понять твои потребности. Начнем с тебя, ты ближе. Покажи на модели жизненного цикла, где у тебя проблемы.” Саша уверенно ткнула в овал “Исполнение номера”. “Ага, практика Исполнения, т.е. ты стейкхолдер Артист. А в чем твоя проблема?” “Мне, как стейкхолдеру Артисту, надо иметь максимально большой набор композиций и стилей штрихов и пятен, чтобы в условиях ограничений конкурса я могла нарисовать подходящий под любую секретную тему рисунок и получить максимальное количество лайков.” “User story? - удивился Борис, - ну, будем работать с ней, нет проблем.” И попросил Сашу телефоны организаторов. “О чем ты с ними будешь говорить?” - удивилась Саша. “Как о чем? - удивился Борис не меньше ее, - ты смотри, сколько тем для обсуждения, там разговора на час, не меньше.” И он взял рабочую тетрадь, карандаш и ушел в кабинет. Через 1,5 часа он вышел оттуда с тремя плотно исписанными страницами. Вот что там было.

Глава 2. “На что жалуетесь, заказчик?” Выявление потребностей.

Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard


Лист 1 был озаглавлен “Проблема - эволюционная оппортунистическая модель жизненного цикла (риски интеграции и поставки).”, лист 2 “Проблема - неопределенность в правилах участия и интересах стейкхолдеров”. Третий лист Борис отложил в сторону и сказал: “Пока разберемся с этими.” Он взял еще один чистый лист и нарисовал такую картинку.


“Это каскадная модель жизненного цикла выставки. Мы последовательно уточняем состав выставки, художников, место, зал, цену билетов, поток посетителей, проектируем петлю просмотра. И когда определились со всем, развешиваем картины, настраиваем свет, организуем охрану и проводим выставку. Мы все знаем заранее. Вообще, понятнее было бы даже нарисовать эту модель жизненного цикла так:



“Папа, уже 11 вечера. Мы просидели 3 часа, карандаша как не было так и нет, есть только куча бумаги, поднятые на уши организаторы, которые стали менять правила организации, у меня мессенджер дзинькает каждые 30 секунд. Мне от тебя нужен был всего лишь нормальный карандаш.” Борис вздохнул - человеческий фактор, ничего не поделаешь. “Ладно, утро вечера мудренее, ложись спать, а я что-нибудь придумаю.” “Ладно, пап, не расстраивайся, просто тут надо пойти в магазин и просто купить карандаш, а не строить атомную станцию. Я скажу маме, что ты помог.” Борис вздохнул, Саша была не первым разочарованным заказчиком. И он знал, как с ними работать.
Встало низкое зимнее Солнце и Саша вышла на кухню, шаркая ногами. Рядом с тарелкой овсянки и тостами стоял высокий стеклянный стакан апельсинового сока и рядом лежали два карандаша. Первый был обычный механический, а второй был склеен попками из двух икеевских - черного и красного. Места хвата икеевских были обернуты какой-то лентой, похожей на изоленту. Маша с любопытством взяла его в руки и тут же положила обратно на стол, недовольно глядя на свои руки. Они были испачканы фиолетовым, прямо под цвет “изоленты”. “Что за шутки, папа?” - спросила она. “Это не шутка, это два варианта твоих волшебных карандашей,” - ответил ей Борис, который доедал свою порцию хлопьев. “Смотри, это механический карандаш, в нем 5 стержней разного цвета, твердости и мягкости. А икеевский вариант дает 4 цвета - черный, красный, фиолетовый и желтый, с двумя типами линий. Грифель от средних штрихов до толстых, а пастельные полоски позволяют делать фон. Достаточно необычно?” “Вот это то, что я хотела! Это просто суперское решение, папа! Пойду тренироваться.” “Не так быстро, вначале садись и поешь, а я тебе объясню, почему все не так просто.” “Да я ими легко нарисую, нет проблем,” - Маша рвалась обратно в свою комнату. “Ты не одна на белом свете и даже не одна в этом проекте по выставке. Если ты не будешь учитывать чужое мнение, успеха ты не добьешься. Почему ты думаешь, что тебя с этими карандашами допустят к соревнованиям?” “А почему могут не допустить? Это же один карандаш, пусть и рисует разными цветами.” “А что такое карандаш, дай определение этому термину. Как определить, что эта штука - именно один карандаш, а не 2? Этак ты сейчас весь набор скотчем обмотаешь и объявишь одним карандашом.” “Ну, здесь же не набор, здесь же один корпус.” “Дай определение термину карандаш.” “Хм. Это пишущий стержень в оправе. Хотя оправа не всегда бывает, есть же угольные и пастель. В общем, получается, это инструмент рисования из стержня.” “Т.е., стержень является отличительным признаком карандаша? Единственный карандаш означает единственный стержень?” “Получается, так.” “И тогда?”, - Борис замолчал и выжидательно посмотрел на Сашу, ожидая, что она подведет выводы. “Эти карандаши взять на выставку будет нельзя,” - разочарованно протянула Саша. “Садись и ешь кашу, а я расскажу тебе, что мы будем делать и где тут проблема,” - скомандовал Борис, и Саша послушно села и стала его слушать.
“Первый шаг в любом проекте - это наведение понятийного порядка. Я позвонил организаторам и мы обсудили каждый термин в онтологическом описании. Наибольшие непонимания были по карандашу, подписчикам и фото и видео.” “Про карандаш я уже поняла, а что с подписчиками и видео может быть не так?” “Тот трюк, который я придумал с карандашом, мне показался тривиальным, но организаторы про него не подумали, теперь определение карандаша и критерии допуска карандашей будут прописаны в правилах конкурса.” “Зачем ты сказал? Мы бы победили!” “Это слишком легко, любой догадается. Мы придумаем более сложную штуку, повторить которую будет намного сложнее. Теперь мы знаем, что критерием того, что карандаш признают единственным, является монолитность стержня. Т.е., нам надо создать карандаш, в котором один стержень будет рисовать разными цветами. Но про это чуть позже. Вторая проблема - это подписчики. Как избежать накруток? И мы определили критерии учета голосов, их тоже не было, было просто количество лайков, которым легко манипулировать. Теперь будут учитываться только голоса тех, кто был подписан на канал до объявления конкурса. И последний пункт - фото и видео. Понятно, что от качества фото и видео, которое будет выложено, зависит экспозиция и красота кадра. Поэтому положение камеры, освещение и параметры кадра тоже будут зафиксированы в правилах конкурса. И вот с этими входными данными мы можем начинать инженерную работу, а не гадать на кофейной гуще.” “Ты же пьешь эспрессо, а не варишь кофе в турке!”, - стукнула его в плечо Саша. “Заказчик начал шутить? Это хороший признак, - ответил ей Борис, допил эспрессо, вытер губы салфеткой и спросил Сашу, - до школы подбросить?” “Доеду на велике, время еще есть, - ответила Саша, - встретимся вечером, господин инженер!” “Встретимся вечером и продолжим работу,” - ответил ей Борис и они пошли по своим делам.
Борис не успел войти в дом и помыть руки, как Саша уже выбежала к нему и спросила: “Ну что, пойдем работать дальше?” “Пять минут, Турецкий”,- ответил Борис и достал из рюкзака свой любимый набор Copic Ciao.
“В общем, проблема у организаторов такая,” - начал Борис.



“Вот есть команда этого проекта - организаторы, ведущий Инстаграм канала и спонсор конкурса, подписчики канала. Они координируют свои работы по созданию целевой системы выставки. Целевая система выставки состоит из,” - и Борис нарисовал еще одну картинку.



“Вначале давай определим свое место в проекте по организации и проведению конкурса. Весь конкурс как система состоит из подсистемы галереи работ, подсистемы оцененного контента и остальной движухи, она нам неинтересна. Другими словами, нам интересны сами работы и контент канала Инстаграм, который создается из этих работ. Это и есть та часть целевой системы, которая влияет непосредственно на нас. Давай посмотрим детальнее. Галерея состоит из работ разных художников, которые будут участвовать в конкурсе. А конкретная работа состоит из штрихов и пятен, которые карандаш оставил на рабочей поверхности, ватмане. Всей выставкой, галереей и фото- видеосъемкой заведует художественный руководитель выставки. Но он не занимается логистикой картин, арендой зала, не продает билеты, всем этим занимается руководитель проекта. У руководителя своя система, которая называется обеспечивающей. Обеспечивающая система производит целевую систему. Но и саму обеспечивающую систему тоже надо проектировать и строить, этим занимаются руководители. В этом и есть разница между системными инженерами и менеджерами проектов. Системные инженеры занимаются целевыми системами, а менеджеры проектов обеспечивающими. Если ты спросишь руководителя проекта по проведению конкурса про работы художников, он тебе ничего не ответит, его целевая система не интересует. Зато его можно попросить выставить свет и организовать съемку в соответствии с правилами и спецификацией.” “Зачем ты мне это рассказываешь, папа?” “Ты хочешь победить в конкурсе, сама этого сделать не можешь, тебе надо организовать дело так, чтобы другие люди сделали все для твоей победы. Но чтобы общаться с ними, ты должна понимать, чем каждый из них занимается, о чем с ним можно говорить, а о чем нельзя. Надо понимать, что перед тобой не Валентин Петрович, а менеджер проекта, и задавать ему вопросы в зоне его ответственности и интересов. Иначе общение не заладится. Но мы отвлеклись, вернемся к структуре целевой системы и ее связи с V-моделью жизненного цикла.”



У нас есть контрольная точка проекта “КТ0. Решение о проведении выставки принято, бюджет определен”. Она относится к самому верхнему уровню целевой системы - к уровню выставки. В этот момент никто не думает о конкретных работах, карандашах и освещении, это слишком детальное рассмотрение для этой стадии.
Затем идет контрольная точка “КТ1. Тематика выбрана, художники определены, композиция и петля посетителей зафиксированы”. Это уже системным уровнем ниже, мы рассматриваем как саму выставку в целом, так и галерею, контент канала и может быть даже отдельные работы, которые особенно важны для выставки. Но мы все равно не опускаемся до уровня штрихов и отдельных фотографий.
Потом идет самый нижний системный уровень, который мы рассматриваем в этом проекте - контрольные точки “КТ2. Картины выбраны и их логистика определена” и “КТ3. Место проведения законтрактовано, дата выставки определена, продажа билетов и маркетинг организован, выставка оформлена и управление рисками выстроено, картины доставлены”. Тут мы уже занимаемся тем, что часто называют “есть слона по кусочкам”, производим составные части нашей целевой системы. Когда у нас есть все составные части (картины), мы собираем из них подсистемы - ряды галереи, а из подсистем целевую систему - выставку, конкурс, которую и передаем в использование стейкхолдерам “посетителям/пользователям”. Этому соответствует контрольная точка “КТ4. Плановая выручка достигнута, отзывы и рецензии положительные, экспонаты в целости”. Остается только закрыть проект “КТ5. Экспонаты возвращены владельцам, роялти начислены, депозиты возвращены, договоры закрыты”. Т.е., в V-модели жизненного цикла мы вначале спускаемся по системным уровням, а потом опять поднимаемся. И так мы делаем для целевой системы - спускаемся от уровня всей выставки и галереи до уровня отдельных штрихов и потом опять поднимаемся до уровня выставки.
Правая и левая часть V-модели разделяет определение и воплощение целевой системы.” “Воу-воу-воу, постой, о чем это ты?” - по Саше было видно, что информации слишком много, Борис как всегда увлекся. “Смотри - мы вначале весь проект прокручиваем в голове. Наше представление о проекте называется определением. Частично эти определения мы можем записать, зарисовать и т.п., это будут описания. А потом мы делаем что-то руками и получаем штуку, это называется воплощение. Допустим, представь рисунок розы.” “Представила.” “Теперь запиши мне то, что ты представила.” Саша написала “красная свежая роза в узкой вазе.” “А теперь нарисуй.” Саша быстро нарисовала розу. “Теперь еще одну, такую же.” Саша нарисовала еще одну, немного другую. “Смотри, важная штука. Ты думала вроде бы об одной и той же розе, определение было одно, но воплощений у тебя получилось два. И ты еще можешь 20 роз нарисовать, которые будут соответствовать определению и описанию. В левой части V-диаграммы у нас находятся определения и описания, они описывают типы вещей. А в правой у нас сами воплощения, вещи. И мы можем проверить, соответствует ли созданная нами вещь определению и описанию. Посмотри на рисунок розы - он соответствует твоему замыслу, определению? А описанию?” Саша послушно кивнула головой оба раза. “Давай я проверю, как я поняла,” - сказала она. “Давай”,- радостно согласился Борис. “Вот есть конкурс, который мы с тобой обсуждаем. Его воплощения еще нет, оно будет только через две недели. А сейчас у меня есть его определение, представление о том, как это будет круто. И есть еще правила конкурса, план-график его проведения - это описания конкурса. И когда конкурс начнется, можно будет проверить свои представления об этом конкурсе, сравнить их с реальностью, и с планом-графиком, правилами. Так?” “Да, все верно. Это называется проверкой, верификацией и приемкой, валидацией, я их показал на графике стрелочками. Молодец, поехали дальше, - и он продолжил, -
На каждом системном уровне мы обращаем внимание на ту часть онтологии, которая важна для этого системного уровня - для отдельной картины это штрихи и пятна, которые выполняют свою задачу в композиции, а для всей выставки картина и ее расположение в экспозиции. Методисты системного подхода часто говорят, что системный подход направляет наше внимание на ту часть мира, которая его требует.” “Э-э-э. Мы начинали с проблем и потребностей стейкхолдеров, как мы зашли сюда?” Борис достал первый листок, на котором было написано “Проблема - эволюционная оппортунистическая модель жизненного цикла (риски интеграции и поставки)” и сказал, что вначале ужин, а потом они перейдут к решению проблем.
Борис задумчиво смотрел в окно, вокруг огромного снеговика бегала детвора, во что-то играла. Сзади подошла Юля: “Ну что, проектанты, скоро выпускать документацию будете?” “Выходим на формулирование спецификации требований, так что уже скоро, дальше пойдет быстрее.”
“Как, по-твоему, будет проходить конкурс?” - спросил Борис Сашу. Она удивилась: “Ну, мы зайдем, выходит ведущий, говорит тему и мы рисуем. Все, наверное.” “Хорошо, а как вас снимают на видео? Да еще и со стандартным освещением, с одного ракурса?” “Ну, по-одному.” “То есть, тему узнают в один момент, но кто-то сразу начинает рисовать, а кто-то думает несколько минут, пока другие рисуют?” “Хм, я что-то не подумала об этом.” “Не ты одна, организаторы тоже не подумали, пока я их не спросил. В общем, вы будете сидеть в комнате и выходить по одному, вам будут говорить тему, и вы будете рисовать. И главный вопрос, как ты понимаешь - это ...” “Отобрать телефоны и планшеты, чтобы те, кто сидит в комнате, не смогли подготовиться заранее!” “Именно, - Борис был доволен, - надо еще одновременно все выложить, перемешать работы между собой, но это уже технический момент.” Борис достал лист 2 “Проблема - неопределенность в правилах участия и интересах стейкхолдеров”. “Давай запишем что уже есть,” - и он начал писать.
Стейкхолдер Организатор.
ПтрСХ №1. Мне, как Организатору, надо организовать конкурс так, чтобы его можно было провести в соответствии с правилами, чтобы никто не обвинял организаторов в предвзятости и несправедливости конкурса.
ПтрСХ №2. Мне, как Организатору конкурса, надо провести конкурс так, чтобы участники не нарушали его правил, чтобы никто не обвинял организаторов в предвзятости и несправедливости конкурса.
ПтрСХ №3. Мне, как Организатору конкурса, надо чтобы секретная тема раскрывалась одинаково всем участникам, несмотря на различие во времени их выступления, никто не обвинял организаторов в предвзятости и несправедливости конкурса.
ПтрСХ №4. Мне, как Организатору конкурса, надо организовать и провести конкурс так интересно, чтобы Инстаграм канал получил новых подписчиков, а конкурс получил информационное покрытие, чтобы Спонсор заплатил деньги за конкурс и был доволен его проведением.
Стейкхолдер Владелец Инстаграм канала.
ПтрСХ №5. Мне, как Владельцу Инстаграм канала, надо получить информационное покрытие и получить достаточное количество активных клиентов с LTV не ниже целевого, чтобы окупить спонсорство конкурса, иначе я потеряю деньги на спонсорской программе.
Стейкхолдер Участник.
ПтрСХ №6. Мне, как Участнику конкурса, надо придумать и представить самую лучшую свою работу в ограниченное регламентом соревнований время, чтобы иметь максимально высокие шансы на победу в конкурсе.
ПтрСХ №7. Мне, как Участнику конкурса, надо обеспечить узнаваемость и авторитетность конкурса, чтобы сам факт моего участия повышал мою рыночную оценку как артиста, и даже если я проиграю в конкурсе, само участие в нем было бы для меня выигрышным.
Стейкхолдер подписчик/оценщик.
ПтрСХ №8. Мне, как подписчику, нужно отличное зрелище и чувство собственной важности, влиятельности и возможности влиять на судьбы людей, чтобы потешить свое самолюбие.

“Смотри, наша модель жизненного цикла конкурса полностью определяет формулировки потребностей и объекты внимания в нашем проекте. Это и есть системный подход - помнить о важном и игнорировать неважное. Мы называем это моделированием куска реального мира,” - Борис обвел рукой все рабочие продукты, взял кнопки и прикрепил их на стену. Последним он повесил третий листок, который он принес с интервью организаторов. На нем было написано.
Глава 3. “Не говорите инженерам как решать проблему”. Анализ требований и проектирование архитектуры.

“Что такое карандаш?”
Саша смотрела на Бориса с недоумением: “В смысле? Я же тебе уже говорила - это пишущий стержень в оправе, инструмент рисования из стержня” “Ага! Типичная ошибка в стадии определения системы. Я ее называю аристотелевской, определение дается повышением уровня абстракции.” “А нормальным языком можешь объяснить?” “Вот есть конкретный карандаш, - Борис взял со стола красный Кох-и-нор, - и есть другие конкретные карандаши других цветов, марок и т.д. Как ты понимаешь, что объект, который тебе показывают, является карандашом?” “У карандаша есть свойства. Он пишет стержнем, у него есть цвет, толщина линии.” “Ты же не по толщине линий и не по цвету проверяешь карандаш это или нет.” “Ну да, карандаш - это стержень, в смысле это не кисточка и не перо.” “Т.е., ты задаешь конструктивную особенность всех карандашей. Карандаш - это определенная конструкция. Хорошо, а если сделать карандаш толщиной полметра и весом 200 килограмм, это будет карандаш?”
“А он пишет?” “Да, он пишет.” “Ну, тогда это карандаш.” “А с таким тебя допустят на соревнование?” “Наверное, нет.” “Хорошо, а если это будет карандаш в 20 раз больше обычного?”
“Ты к чему клонишь, папа?” “Видишь, сколько проблем и вопросов возникает с определением даже обычного карандаша. Эти проблемы связаны с тем, что интуитивно мы определяем вещи с помощью абстракций. Мы не помним конкретных вещей, мы помним только их признаки. Например, если ты придешь в магазин, то увидишь там 20 совершенно одинаковых с виду карандашей в одном стакане.”
“У них у всех одинаковые свойства, ты не можешь отличить один карандаш от другого. Вещи разные, но ты не можешь сказать, чем они отличаются, для тебя это один карандаш-как-абстракция. Любой карандаш, у которого есть такие свойства, будет для тебя именно этим карандашом. Системные инженеры называют такие группы предметов классами или типами. И когда ты говоришь, что тебе нужен волшебный карандаш, ты говоришь про тип волшебного карандаша, потому что я могу тебе сделать 20 различных экземпляров этого типа волшебных карандашей, которые ты примешь как заказчик, скажешь, что это то, что надо. Вот отсюда и проблема.” “Ну, я поняла, что мы думаем в типах, а делаем в экземплярах, но не поняла в чем проблема.” “Проблема в том, как мы подводим экземпляры типа под тип, проблема в определении типа карандашей, которые организаторы допустят до соревнований с одной стороны, и которые помогут тебе выиграть соревнование с другой стороны. Вот смотри. Возьмем 20 сантиметровый карандаш и покажем его трем судьям, что скажут?” “Ну, что такой они не допустят.” “А почему ты так думаешь? Может, кто-то скажет, что пусть рисует, почему нет?” “Ну, может и скажет.” “Т.е., нужно все важные признаки допуска карандашей выписать и добавить в правила.” “Либо просто проверять все карандаши перед началом и говорить - с этим можно, а с этим нельзя, хотя это, конечно, будет спорно и возможно несправедливо.” “Да, тут ты права, вспомни потребность организаторов ПтрСХ №1, правила допуска карандашей должны быть однозначными и объявляться заранее. И вот тут-то у организаторов и есть ключевая проблема. Если просто говорить, что допускаются монохромные карандаши с одним стержнем, то что такое монохромный, как и кто определяет? Если говорить, что стержень у карандаша один, то что такое стержень, как определяется его монолитность? А если есть излом внутри корпуса, становится ли он двухстержневым и должен ли он дисквалифицироваться? А можем ли оправа оставлять красящий след? А кто сказал, что нет? И таких вопросов много, что делать?” Саша растерянно смотрела на Бориса: “А как же заводы и самолеты строят и сдают заказчикам, если даже с карандашом все так сложно?” “Надо забыть про аристотелевскую суть вещей. Не абстрагироваться, а наоборот, опредмечиваться. Вот представь, что этот волшебный карандаш уже есть, что ты про него можешь сказать?” “Ну, его удобно держать в руке, им удобно рисовать и писать, он не скользит, его штрих хорошо виден, им можно рисовать в определенном художественном стиле, он хорошо точится.” “Достаточно. То, что ты говоришь, это субъективные факты. Это уже лучше, чем аристотелевское определение, уже не так абстрактно, потому что я могу тебе дать конкретный экземпляр волшебного карандаша, и ты мне скажешь, удобно ли его держать, удобно ли им рисовать и прочее. Но есть проблема, какая?” “Тебе придется все время спрашивать меня.” “Нет, это самая малая из проблем. Проблема в том, что пока я не сделаю карандаш, я не смогу проверить, а то ли я делаю. Нужны более конкретные вещи, они называются...” Саша прервала его: “Факты!” “Ну, можно сказать и так, хотя я хотел сказать требования, - не смутился Борис, - в общем-то, требования это и есть факты, только предъявляемые не к конкретной вещи, не к конкретному объекту, а к типу объекта. Например, если я говорю, что Саша должна вернуться с пижамной вечеринки не позднее 10 вечера, то это не совсем требование, потому что я определяю поведение не типа, а конкретного объекта, в который я могу ткнуть пальцем. А вот если бы я говорил, что девочки должны возвращаться с пижамных вечеринок домой до 10 вечера, это уже было бы больше похоже на требование. Да, я забыл сказать, что требования указывают на поведение системы, а не на его устройство. Я называю это принципом “не говорите инженерам, как решать задачу”. “А почему? Заказчик редко разбирается в предметной области достаточно хорошо, чтобы предложить подходящее техническое решение. Поэтому лучше когда он просто говорит, что он хочет делать, как он это хочет делать, а конкретную техническую реализацию инженеры придумают сами. Но мы отвлеклись, давай вернемся к требованиям. Итак, мы определяем поведение типа волшебный карандаш, у нас уже есть потребности и нам надо записать их в виде проверяемых фактов для экземпляров типа,” - и он нарисовал несколько диаграмм.

Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard




Сейчас никакого карандаша (конкретного экземпляра) еще нет, но ты уже имеешь представление о том, каким он должен быть. Это твое представление о карандаше называется концептом. Концепты - это абстракции конкретных вещей, они есть только в голове. На деле вполне можно сделать несколько карандашей, которые будут подходить под твой концепт. Эти несколько карандашей можно объединить в какой-то тип карандашей. И мы можем достаточно точно описать этот тип карандашей с помощью спецификации требований (составить описание вещей). В отдельных требованиях спецификации мы опишем, какие факты мы должны наблюдать, когда у нас будет конкретный экземпляр типа карандашей. Когда мы сделаем конкретный экземпляр типа карандашей, то сможем проверить, а выполняются ли для этого экземпляра требования, которые мы предъявили к типу, наблюдаем ли мы факты.

Другими словами, когда мы хотим создать волшебный карандаш, то этот карандаш как-то отражается в нашем восприятии, и у нас возникает концепт карандаша, и мы описываем этот карандаш с помощью спецификации требований. Эта спецификация требований имеет смысл в том плане, что описывает тип карандаша, и если конкретный экземпляр карандаша отвечает требованиям спецификации требований, то он с высокой вероятностью будет восприниматься как подходящий под концепт. Спецификация связывает мир абстракций, концептов с миром физических вещей.

“Отсюда есть практическая задача, которой мы сейчас займемся. Мы напишем системные требования к карандашу. А для того, чтобы их написать, нам надо определить системные интерфейсы карандаша.” “Все, я сдаюсь, не могу больше.” “Ну хорошо, ты иди, а я пока напишу требования, потом обсудим.”
За обедом Саша с Юлей обсуждали тонкости макияжа “под морозный румянец”, Борис пытался было сказать, что бренд это пример типа, общие признаки которого (цена, качество, престижность) разделяются на уровне онтологии каким-то сообществом (целевой аудиторией бренда) и маркетинг занимается изменение онтологии агентов, но его тут же прогнали и попросили не мешать обсуждению. Когда Саша вернулась в свою комнату, у нее на столе лежали две аккуратные распечатки.



СИ - системные интерфейсы


Спецификация системных требований

Код требования - Формулировка требования
СТ1. Не менее 95% общей длины штрихов всех целевых композиций должны распознаваться стандартным наблюдателем
СТ2. Не менее 95% общей площади рисунка должно по колориметрическому индексу совпадать с целевой гаммой целевой композиции при индексе цветопередачи источника освещения более 90
СТ3. После обработки ластиком любого штриха карандаша, нанесенного согласно процедуре А, в соответствии с процедурой Б, должно остаться не более 5% следа, измеренного по процедуре В
СТ4. При исполнении целевой композиции проскальзывание пальцев по месту хвата должно быть не более 1 мм для поверхности рук, удовлетворяющей спецификации Г
СТ5. След, который оставляет карандаш, после съемки на камеру по спецификации Д, должен наблюдаться стандартным наблюдателем в 95% случаев на экране смартфона, соответствующего спецификации Е
СТ6. Целевые композиции, снятые на камеру по спецификации Д, должны получить оценку не менее 65 по процедуре измерения привлекательности видео по спецификации Ж

Она взяла листки и пошла в кабинет отца. Борис посмотрел на нее, улыбнулся и спросил: “Готова работать дальше? Ну тогда приступим к анализу требований. Вначале вспомним твои потребности как стейкхолдера.” Он достал тетрадку, нашел нужную страницу и прочитал вслух:
“ПтрСХ №6. Мне, как Участнику конкурса, надо придумать и представить самую лучшую свою работу в ограниченное регламентом соревнований время, чтобы иметь максимально высокие шансы на победу в конкурсе.
ПтрСХ №7. Мне, как Участнику конкурса, надо обеспечить узнаваемость и авторитетность конкурса, чтобы сам факт моего участия повышал мою рыночную оценку как артиста, и даже если я проиграю в конкурсе, само участие в нем было бы для меня выигрышным.
ПтрСХ №8. Мне, как Подписчику, нужно отличное зрелище и чувство собственной важности, влиятельности и возможности влиять на судьбы людей, чтобы потешить свое самолюбие.”
“Что мы видим? Все системные требования, которые я записал в спецификацию, уточняют скорее потребности стейкхолдеров №7 и 8, и почти никак не отвечают на №6. Я уж не говорю про остальные потребности других стейкхолдеров. Так обычно и бывает, предлагаемая система решает только часть проблем части стейкхолдеров надсистемы. Фактически, нас интересует только две вещи - допуск на соревнования и красивая картинка, на это мы и делаем ставку. А вот в детали я предлагаю углубиться.” И Борис с Сашей стали обсуждать, как создать целевые композиции, как измерить их привлекательность на экране смартфонов при заданной организаторами расстановке камер и освещения, коснулись даже различия в спецификациях бумаги. Через час спецификация требований с кучей красных поправок легла на стол с подписью заказчика. То есть Саши. “Дату не забудь поставить и расшифровку,” - добавил Борис. “Ну вы и бюрократы, господа системные инженеры,” - сыронизировала Саша. “Да, мы такие! А теперь пойду делать варианты системной архитектуры.” “Архитектура - это же про строительство?” “Ох, с термином проблема. Давай я тебе объясню,” - и Борис набрал поисковой запрос и кликнул по какой-то картинке.

“Что это?” “Буква А. Варианты написания буквы А, в разных шрифтах.” “А как ты понимаешь, что это буква А? Ведь очень разное написание?” “Ну, как-то понятно же.” “Вот это понятно же и есть архитектура. Что-то самое важное в системе, что иногда сложно выразить словами или в чертежах. Иногда только и можно договориться что вот это системная архитектура, а вот это нет. И она субъективна. А больше и не грузись, тут даже опытные системщики закапываются.” И Борис ушел с утвержденной спецификацией требований к себе в комнату. Саша пошла делать уроки. До конкурса оставалось 2 недели ровно.
Глава 4. “Почему лучшие решения самые рискованные?” Прохождение развилок, выпуски и базисы.
Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard


Утром Борис встретил дочь с комплектом эскизов на миллиметровке и картонной коробкой, в которой что-то перекатывалось. “Прототипы, - радостно потряс он коробкой и разложил все на столе. - Самое плохое что может случится с системным инженером это паралич от анализа”. “Что это за штука?” - удивилась Саша. “Это застревание в левой части V модели, происходит когда команда строит все более точные модели и уточняет свои концепты, а к действиям не переходит. Все эти спецификации и чертежи нужны только для того чтобы по ним сделать что-нибудь реальное”. И он нарисовал на бумажке иллюстрацию мысли:



“Наконец-то а то я уж думала что ты на работе только документами и занимаешься!” В ответ Борис взял маркер и нарисовал такой график.
Процент стоимости жизненного цикла накопленным итогом.

“Вот видишь, на моделирование и размышление уходит примерно пятая часть всех расходов и 40% всего бюджета проекта по созданию системы. Конечно, это правило для проектов по созданию сложных систем, но ты должна понять общую идею. Общая идея заключается в том, что времени на планирование действий и достижение понимания в команде жалеть не стоит, это хорошая инвестиция. Это и есть настоящий тимбилдинг, а не дурацкие коллективные игры. Главное вовремя закончить моделирование и выйти в реальный мир”.




“У системных инженеров переход от планов и дизайна к воплощению называется “выбором”, по-английски trade-off. Выбор состоит из принятия решения, оформления решения и согласования зависимых решений”. Борис поймал непонимающий взгляд Саши и стал рисовать.

“Когда мы начинаем думать о том, какая конструкция должна быть у нашей системы, мы думаем широкими категориями. Например, считаем, что карандаш может быть механическим или иметь сплошной корпус. Корпус может быть деревянный или пластмассовый, а толщина стержня может быть от 1 мм до 5 мм. Если мы говорим, что стержень должен быть 4,7 мм, то это сразу задает ограничения на лепестки держателя механического карандаша либо ширину канала карандаша сплошного стержня. Лепестки должны с достаточной силой держать стержень при рисовании, а если карандаш сплошной, то стержень должен помещаться в канал. Словом, выборы взаимосвязаны и если инженер говорит А, то он должен сказать и Б. Принимая одно решение, он принимает и все вытекающие из принятого решения последующие решения. При этом само решение он принимает в голове, решение - это концепт. Но это концепт такой, точечный, по принципу ‘делаем стержень 4,7 мм, сплошной деревянный корпус из кедра марки Б13’.

Дальше инженер смотрит, удовлетворяет ли такая конструкция спецификации требований. Потому что какой толк в конструкции, если она не понравится заказчику. Если удовлетворяет, то получившаяся конструкция оформляется в конструктивное решение, по-английски point design, конструкция, отвечающая заданным требованиям. Множество point design и есть пространство выборов”. “Я тогда не поняла, почему trade-off. Что на что торгуют, меняют?” “О, в этом и заключается суть. Видишь шкалы пространства выборов? Вес и толщина. Это и есть критерии выбора архитектуры. Мы обмениваем выборы одного параметра на выборы другого параметра. Чем толще я сделаю стержень, тем тяжелее будет карандаш, тем неудобнее им будет работать. Но толстый стержень позволяет использовать больше техник рисования. Поэтому инженер выбирает такую конструкцию, которая с одной стороны способна удовлетворить согласованной спецификации требований, а с другой будет оптимальной для использования и производства”.
“После того, как инженер сделал выбор, оно оформляет его в конструкторской документации и выпускает эту документацию. Это еще называется релизом. Но релиз штука серьезная, часто дорогая и длинная, поэтому лучше бы проверить выбранный вариант конструкции с заказчиком на прототипе. Что мы сейчас и сделаем”, - и Борис вручил Саше два варианта карандаша, один механический, а другой цельный. Ни один из них не писал, чему она и удивилась. “Это же не функциональные прототипы, они просто дают представление о весе и удобстве. Опытные образцы, которыми можно будет рисовать, мы сделаем чуть позже”, - разъяснил ей Борис. “Ну, наверное удобнее будет сплошной, - решила Саша, - где подписаться?” “Моя школа! - рассмеялся Борис. - Пока нигде, не будем доводить до абсурда. А пока собирайся и поедем к мейкерам”. “К кому?” “Не к кому, а куда, в X-makers, фабрика мейкеров, будем производить твои карандаши”.

Борис стоял на очередном светофоре, Саша слушала свою музыку и вдруг вытащила наушники и спросила его: “Хорошо, а после выпуска конструкторской документации что происходит?” Борис вздохнул, он не любил этот вопрос, потому что тема была сложная, запутанная и заказчики часто в ней терялись, но деваться было некогда и он сказал пару слов. “Когда инженер выпускает чертеж, ведомость или спецификацию, то закупщики, производственники и руководитель проекта начинают проверять, а могут ли они купить материалы и комплектующие, в какие сроки можно изготовить этот компонент, не сорвет ли это график проекта и нет ли риска превышения бюджета.


Именно это мы сейчас и выясним у мейкеров - я им дам спецификацию требований, варианты конструкции, а они дадут свои оценки, сколько будет стоить изготовление каждого варианта и когда они будут готовы. А мы вместе решим, какой из этих вариантов нам больше подходит”. Тут они подъехали к месту назначения и Борис сразу ушел на стойку оформлять заказ. Через три минуты к нему подошел какой-то парень в форменной спецовке и они вместе ушли в какую-то дверь. Саша ничего этого не видела потому что уткнулась в телефон и потеряла счет времени. Очнулась она от того, что на экране всплыло сообщение с иконкой Бориса: “Подними глаза”. Она оглянулась, из полуоткрытой двери цеха выглядывал Борис и махал ей рукой, мол подходи сюда. Она вытащила наушники из ушей, взяла сумочку и пошла в цех. В цеху было шумно от станков и вытяжки. Борис повел ее вглубь к 3Д принтеру. Сквозь прозрачный колпак было видно, как головка принтера печатает контуры, в которых угадывался эскиз, который Саша видела сегодня утром. Саша прикинула сколько еще ждать и достала телефон и начала оглядываться в поисках диванчика или кресла. “Пойдем, покажу тебе”, - сказал Борис и пошел с ней в дальний угол. “Вернемся к выпуску документации, - продолжил он. - Вот выпустил инженер комплект документов, в твоем случае оператор 3Д принтера сделал 3Д модель карандаша и указал материалы стержня и корпуса по моим эскизам. Если это не такая мелочь как карандаш, а какой-нибудь станок, то после этого производство считает сроки изготовления и отгрузки, логисты и закупщики считают как изменится цепочка поставки, где закупать комплектующие, все эти расчеты и оценки идут руководителю проекта и он проверяет меняется ли календарный график и надо ли пересмотреть бюджет. Обычно это все происходит на специальном собрании, которое называется комитет по одобрению изменений, по-английский change approval board meeting, CAB meeting. Если все согласны, то получившийся набор из комплекта конструкторской документации и всех сопутствующих планов производства, логистики и плана проекта собирается в комплект, который называется базисом, по-английски baseline,” - и он дорисовал диаграмму с вариантом конструкции, отвечающей заданным требованиям.

“Базис моделирует соглашение команды создавать изделие по какому-то скоординированному плану. Это закрепленная детальная договоренность по совместным действиям. А теперь подумай насколько реалистичен базис?”, - Борис ехидно посмотрел на Сашу. “Ты хочешь сказать, что базис нереалистичен?”, - Саша удивилась. “Вопрос хитрый и ответ зависит от горизонта планирования. За пару недель он вряд ли изменится, но гарантированно станет неактуальным через пару месяцев. И что же тогда делать?” “Делать новый базис?” “Не делать новый, а менять старый. Для этого есть запросы на изменения. А для руководителя проекта до утверждения базиса вообще еще проект не начался, хотя он уже вовсю идет. С точки зрения проектного менеджмента все, что происходит до утверждения базиса это запуск и планирование проекта. А потом под этот базис выделяется бюджет, утверждаются сроки, дают людей и ресурсы”, - Борис замолчал и заметно погрустнел. Саша смотрела на него несколько секунд и не выдержала: “Чего ты?” “И вот тут у меня в проекте есть проблема. Она в том, что бюджет и сроки проекта уже утверждены, внесены в контракт, а базиса у нас не то что нет, до него еще пару месяцев работы. Получается, что все обещания, которые руководитель проекта дал, не основаны ни на каких серьезных расчетах, команда не поручилась, что может выполнить эти обязательства и вообще непонятно, сможем ли мы что-то заработать на этом проекте. От этого мне грустно”, - они оба замолчали и сидели несколько минут, слушая ритмичную музыку сервоприводов, форсунок и работающей вентиляции. Борис взял листок бумаги и быстро начиркал в нем рисунок.

“Покажу как это происходит на примере спецификации требований. С другими документами все аналогично. Вот мы утвердили базис, в базисе есть начальная спецификация требований. Приходит запрос - снять такое-то требование потому что оно дорогое в реализации или его долго выполнять или оно вообще стало ненужным. Его снимают, меняют спецификацию, выпускают новую версию 02. Потом приходит еще один запрос на изменение. Опять собирается комитет по изменениям и в этот раз обсуждают, что надо изменить какое-то требование, переформулировать его или изменить численные показатели. Требование изменяют, выпускают спецификацию требований 03. Приходит третье изменение, в этот раз добавляют требование и выпускают спецификацию версии 04. Каждый из этих запросов проверяет комитет по одобрению изменений. Главное, что они делают - это смотрят каждый в своих документах, а не нужно ли что-то в них изменить, не будет ли противоречий, если одобрить этот запрос. Например, меняется требование по мягкости стержня карандаша, это означает, что надо изменить конструкторскую документацию, указать там другой материал стержня. Когда закупщики видят изменение материала стержня, то они говорят, что надо поставлять его от другого поставщика, а это изменение сроков поставки. Тут вмешиваются производственники и говорят, что окно для производства есть только на 42 неделе, а дальше 4 недели линия будет занята срочным заказом, поэтому график производства переносится на 6 недель. Тут вмешивается руководитель проекта и говорит, что эта задача лежит на критическом пути и ему придется наверстать 6 недель не говоря уже о том, что непонятно, чем таким полезным занять людей эти шесть недель, пока не придет новый материал, а платить просто так он не может. И изменение отклоняют. Ну, или не отклоняют, но тогда много что меняется в планах, документах и договоренностях. Весь этот процесс называется управлением конфигурацией или контролем инженерной документации”. Тут принтер пропищал что-то победное, колпак откинулся, и оператор достал из принтера новый еще теплый карандаш. “Опытный образец!” - обрадовалась Саша и побежала в машину. Борис пришел туда только через пять минут, с новой папкой, на которой была эмблема X-Makers, бросил все на заднее сиденье и протянул руку: “Верни карандаш, он не для тебя”. Саша не поняла: “Как это не для меня?” “Это опытный образец, он нужен для допуска тебя к соревнованиям. Помнишь, у меня была дискуссия с организаторами, признают ли они эту штуку карандашом или нет. Так что нам предстоит сдача-приемка или верификация. Так что давай сюда опытный образец”, - и он требовательно протянул руку.

Они встретились за завтраком, Борис нарезал овощи для вока, шеф-нож быстро стучал о доску. На столе лежала коробка с опытным образцом карандаша, рядом с ней лежала папка X-makers. Саша открыла папку и стала перелистывать страницы, там были счета, калькуляция стоимости и отдельным листом была табличка с названием “ВЕДОМОСТЬ МАТЕРИАЛОВ изд. №116382 01” с распечатанным в верхнем колонтитуле названием файла bill-of-materials 031018 rev.02. Табличка была необычной, между строками был двойной интервал, некоторые позиции были исправлены красным архитектурным маркером. “Я вот не очень поняла одного момента, - начала Саша. - Ты говорил, что процесс изменения базиса называется управлением конфигурацией. А конфигурацией чего и что такое конфигурация вообще?” “Хороший вопрос. Вообще, процесс изменения базиса это не само управление конфигурацией, это управление изменениями. Вообще, чтобы понять, что такое управление конфигурацией надо разобраться с понятием конфигурации”. Борис высыпал нарезанные овощи в вок и стал рассказывать. Вот что законспектировала Саша.


Базисов на самом деле два - один создается во время проектирования и описывает состав, версии и содержание проектной документации, он называется проектный базис, и исполнительский базис, в котором фиксируется из чего же в самом деле сделали изделие, какой у него фактический состав и характеристики. И тот и другой базис это набор документации, в первом случае проектной документации, которая описывает замысел, а второй комплект описывает фактическое состояние дел. Вот это фактическое состояние дел и есть конфигурация. Документальное описание конфигурации описывается спецификацией продукта. Например, спецификация на сашин iPhone:
https://support.apple.com/kb/SP770?locale=ru_RU
описывает конструктивный состав, он состоит из корпуса, дисплея, процессора, камеры, модуля связи, модуля геопозиционирования, кнопок, аккумулятора и источника питания, датчиков, операционной системы, приложений. У каждого конструктивного элемента есть важные функции, например, у подсистемы питания:
- Работает до 2 часов дольше, чем iPhone 7
- В режиме разговора (с беспроводной гарнитурой): до 21 часа
- При работе в интернете: до 12 часов
- Воспроизведение видео по беспроводной сети: до 13 часов
- Воспроизведение аудио по беспроводной сети: до 60 часов
- Возможность быстрой подзарядки: до 50% заряда за 30 минут
- Встроенный литий-ионный аккумулятор
- Беспроводная зарядка (совместима с зарядными устройствами стандарта Qi)10
- Зарядка через USB от компьютера или адаптера питания

Спецификация создается для пользователя и оператора, а вот системная архитектура - это те условно десять ключевых решений по устройству системы, которые принимает команда для того, чтобы система отвечала заданной спецификации на продукт. Спецификация на продукт в корне отличается от спецификации требований, хотя пункты спецификации похожи на требования. Но требования - это выражения, которые составляется в соответствии с какими-то стандартами, и соответствие требованиям проверяется командой проекта, а спецификация пишется достаточно свободным языком, понятным пользователям и операторам, и формально пункты спецификации на изделие командой проекта не проверяются напрямую, а только опосредованно через соответствующие пунктам спецификации на изделие системные требования. Ну, например, в спецификации на изделие просто напишут “Воспроизведение видео по беспроводной сети: до 13 часов”, а в требованиях обязательно будет ссылка на то, по какому стандарту это проверяется, в каких условиях, при каком уровне зарядки аккумулятора и как этот уровень зарядки измеряется, какая выборка аккумуляторов проверяется и прочие технические детали, совсем неинтересные пользователям. Проектный и исполнительский базис должны соответствовать спецификации на изделие и если они не соответствуют, обязательно необходимо выпустить запрос на изменение, который откорректирует расхождение между базисом и спецификацией на изделие. Конфигурация и базисы хранятся в специальных программах, которые называются Product Data Management или Product Lifecycle Management. Эти же программы не только хранят спецификацию на изделие и документы базисов, но и автоматизируют процессы запроса на инженерные изменения, выпуска конструкторской документации, оповещения о произошедших изменениях и управления ведомостями материалов, по-английски BOM management.

По сути, когда мы говорим о конфигурации, то моделируем изделие в виде композиции объектов. Композиция объектов - это когда мы говорим, что объект состоит из других объектов, которые находятся в отношениях часть-целое. Например, рука является частью человека. Возьмем, к примеру, телефон:


Функциональность каждого объекта моделируется с помощью свойств, атрибутов. Например, функциональность камеры моделируется следующими атрибутами объекта “Камера”:
- Камера 7 Мп
- Режим «Портрет»
- Портретное освещение (бета-версия)
- Animoji
- Съёмка HD-видео 1080p
- Вспышка Retina Flash
- Диафрагма ƒ/2.2
- Расширенный цветовой диапазон для фотографий и Live Photos
- Автоматическое включение HDR
- Сенсор BSI
- Распознавание лиц и фигур
- Автоматическая стабилизация изображения
- Серийная съëмка
- Контроль экспозиции
- Режим таймера

Эта модель объектов и свойств подстроена под нужды конкретного стейкхолдера, и поэтому скажем вспышка Retina Flash здесь просто атрибут, хотя для разработчика камеры это будет отдельный объект, у которого будут свои атрибуты, важные при выборе подходящего технического решения. Поэтому спецификация может быть для любых отдельных объектов-частей изделия, даже если в конечной спецификации изделия эти части моделируются атрибутами.
С точки зрения управления проектом разработки и производства iPhone нам важно понимать состояние разработки и изготовления каждого объекта от iPhone в целом до последнего винта и стандартной программы. Чтобы отразить это состояние, объекту кроме свойств приписывается еще и статус. Обычно этот статус указывается в конструкторской документации как литера, указывающая на стадию разработки документации. Т.е., состояние объекта может быть “Техническое предложение” (литера П), “Эскизный проект” (литера Э), “Технический проект” (литера Т), “Рабочая конструкторская документация” (литеры О1 и О2), “Рабочая конструкторская документация серийного производства” (литеры А, Б и т.д.) Есть правило, что если в состав объекта входят объекты с одной литерой, то вышестоящий по сборке объект не может иметь литеру выше самой низкой литеры объектов, входящих в его состав. Например, если экран находится в стадии эскизного проекта, то документация на сам iPhone не может быть выпущена в стадию технического проекта. Смена стадий означает смену ответственных за основной поток работ в проекте, смену бюджетов, с которых финансируются работы, поэтому обычно инженеры и менеджеры очень внимательно относятся к учету выпусков. Передача ответственности и переключение финансирования проекта с бюджета на бюджет происходит в т.н. “гейтах”, контрольных точках принятия решений. Таким образом, есть отдельно выпуски технической документации (изменение статуса разработки объекта), отдельно утверждение конфигурационных базисов (т.н. “релизы”, события согласования проектной и технической документации) и отдельно гейты (события передачи ответственности за проект между исполняющими этот проект организациями).
Отсюда вытекают различные модели жизненных циклов изделий, которые базируются на трех типах логики.
Консервативная логика, каскадный жизненный цикл. Вначале инженеры выпускают всю техническую документацию до очередной литеры. После этого на основе выпущенной технической документации согласуется остальная проектная документация по закупкам, производству, логистике, персоналу, маркетингу и т.д. Комплект технической и проектной документации формирует конфигурационный базис, который ставится под управление изменениями. На основе конфигурационного базиса проводится защита конфигурационного базиса и если она прошла успешно, то проект переходит в следующую стадию, меняются центры затрат и ответственность переходит к организации, которая отвечает за работы следующей стадии. Если защита была неуспешной, то техническая и проектная документация возвращается на доработку, которая идет по запросам на изменения. Это самый дорогой вид жизненного цикла и он годится для простых типовых систем, где процедуры перехода от стадии к стадии отработаны сотнями повторений, а системная архитектура ясна на старте проекта и не требует уточнения. Фактически, все выборы в таком проекте и критерии прохождения развилок ясны с самого начала, а неопределенность мала.
Логика снижения рисков, инкрементальный жизненный цикл. Система делится на высокорисковую часть и низкорисковую часть, например, по срокам поставки или производства компонентов. В случае iPhone высокорисковым компонентом будет экран. Работа над высокорисковым элементом выделяется в т.н. инкремент. Инкремент - это часть проекта разработки, которая идет по своему виду жизненного цикла, как правило каскадному. Вначале разрабатывается и выпускается техническая документация на экран, параллельно разрабатывается и выпускается проектная документация, которая нужна для перевода технической документации на экран в следующую стадию. Создается частичный конфигурационный базис, который включает в себя техническую и проектную документацию на инкремент, этот базис используется для авторизации работ над инкрементом в следующей стадии. Иногда бывает, что после 1-2 первых стадий неопределенность в проекте настолько снижается, что со стадии технического проекта или рабочей документации разработка и производство идет по каскадному жизненному циклу. Инкрементов может быть несколько, если в системе есть несколько рискованных элементов. Инкремент стоит рассматривать как покупку ключевой недостающей информации по тому, как проектировать или производить систему. Иногда инкрементом может быть не часть системы, а вся система, если принято решение параллельно разрабатывать конкурирующие варианты конструкции и дальше выбрать наилучший.
Системные инженеры все решения оформляют в виде выпусков, базисов и инженерных изменений. Руководители проектов оформляют свои решения в виде защит проектной документации в гейтах.
КОНЕЦ КОНСПЕКТА

Саша дописала конспект, закрыла ноутбук и легла спать, была глубокая ночь, а завтра им предстояло ехать на приемочную комиссию убеждать организаторов в том, что это именно карандаш и что ее можно допустить до выступления. Она закрыла глаза и тут же заснула.

Глава 5. “Как доказать, что это тот самый карандаш, который согласовал заказчик?” Верификация.
Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard


Она проснулась от запаха куриных грудок в тэрияки, быстро оделась, умылась и села за стол. Юля раскладывала порции по тарелкам, а Борис проверял заточку ножей на вчерашней газете. Судя по тому, как он морщился, заточка ему не нравилась. “Мойте руки и садитесь”, - позвала всех Юля и они сели завтракать. Раньше Саша завтракала в школе, но она перестала набирать вес и мама посадила ее на домашнюю еду: “Так я буду по крайней мере знать, что ты ешь сколько положено, - аргументировала она свое решение. - Какие у вас планы на сегодня, как я понимаю, собираетесь ехать к организаторам?” Борис кивнул: “Едем, будем сдаваться”. Борис протянул Саше столовый нож и попросил сделать ему бутерброд с апельсиновым джемом для чая. Саша взяла нож и стала резать батон, но он только крошился и сминался в месте резки. Наконец, она отрезала кусочек батона, намазала на него масло, положила джем тонким слоем и протянула Борису. “Что-то он не очень аппетитно выглядит”, - ответил ей Борис. “Потому что столовым ножом батоны не режут”, - тут же ответила ему Саша. “Ха! - развеселился Борис. - Вот мы сейчас и поговорим про стейкхолдеров, эпистемологию и верификацию”. “Плотник и Морж какой-то. Как бы не съели всех за этим разговором”, - мрачно пошутила Саша, ей очень не нравилось учить кучу нового, но отцу она доверяла и знала, что ничего лишнего и ненужного он ей не даст.
“Вспомни, что ты подумала, когда я тебя попросил порезать батон этим ножом?” “М-м-м. Я подумала, что это глупая идея”. “Хорошо, а почему ты так подумала?” “Ну, столовым ножом хлеб не режут, он тупой”. “Смотри, получается, что ты ни разу не резала этим ножом этот батон, а уже представляешь, что получится в результате. Ты смогла точно спланировать, предсказать результат”. “Не понимаю восторгов, это очевидно”. “Ничего очевидного здесь нет, потому что точно также люди планируют строительство ракет, например. Вот смотри. Ты видишь два предмета - нож и батон. Ты понимаешь, что ножом можно резать батон. Это позиция знания, когда ты можешь предсказать что можно делать и какой результат получится и тебе даже пробовать не надо. Чем более сложные знания есть у человека, тем более сложные умственные построения и прогнозы он может строить. Я, например, могу оценить, сможем мы построить завод или нет, а есть люди, которые могут спрогнозировать, можно ли ракету на Марс отправить и что надо для этого сделать. Когда у человека есть знание, он может составить реалистичную картинку части мира и развернуть ее во времени, посмотреть, что может быть, как могут развиваться события, какие есть сценарии”. “Ты имеешь в виду, что знания есть только в голове? А книги, статьи, учебники? Разве это не знания?” “Ну хорошо, вот тебе куча статей по системной инженерии, - и Борис протянул ей свой планшет. - Как у тебя, знаний прибавилось? Можешь мне что-нибудь нового рассказать?” “Нет, вначале почитать надо”. “То есть знания все-таки не в самих книгах и не на YouTube? Знания в голове?” “Получается, что так”. “А что тогда в книгах?” “В книгах описание знаний”. “Вот, правильно. Сами знания - это концепты в голове, мы про них уже говорили. Точнее сказать, что знания - это связанные классы и их отношения. И мы эти классы и отношения можем описать на носителе, используя какое-то соглашение по передаче смыслов, которое описывается семантикой. Например, есть семантика литературного или разговорного русского языка, которой мы сейчас пользуемся. И я передаю свои концепты тебе с использованием носителя, это звуковые волны с помощью семантики разговорного русского языка, - он взял планшет, разблокировал его и открыл диаграмму. - Смотри, у меня есть знания по тому, как проводится соревнование среди художников, и я его выражаю таким документом”.


“Но если я ничего с этими знаниями делать не буду, то они бесполезны, поэтому есть еще и деятельностная позиция. Давай вернемся к тому, как ты делала бутерброд. Ты знала, что резать батон этим ножом будет плохо, затем ты взяла его и стала резать. Это деятельностная позиция. Пока ты резала, у тебя появились факты, которые подтвердили правильность твоих планов”. “Подожди, нам скоро надо ехать разговаривать с комиссией, а ты мне тут теорию рассказываешь”, - не выдержала Саша. “Мои объяснения напрямую относятся к этой задаче, и я постараюсь покороче”, - не растерялся Борис.


“А теперь ответь мне, а как ты узнала, что одни ножи режут хорошо, а другие ножи режут плохо?” “Я резала разными ножами и в одних случаях резать получалось, а в других нет. Все просто”. “Смотри, получается, что у тебя в голове есть концепт объекта нож, у этого объекта есть свойство остроты. И еще у тебя в голове есть концепт объекта батон, у этого объекта есть свойство твердости, ведь нож может быть острым, но все равно резать плохо, если материал, который он режет, твердый. И эти два концепта у тебя в голове связаны отношением нож режет батон. Это логика, с помощью которой ты вычисляешь, рассчитываешь варианты развития событий, строишь сценарии”. “Со сценариями ты сейчас посмешил. Я понимаю, когда ты проект считаешь, там есть сценарии, а тут-то что?” - не выдержала Юля, которая загрузила всю посуду в посудомойку и стояла слушала объяснения Бориса. “Да? Ты думаешь, что все так просто? - Борис завелся и повысил голос, и у него появились ироничные нотки. - Ну давай посмотрим, применимы ли сценарии к резке хлеба, - он достал из держалки шеф-нож, взял с полки оселок и провел пару раз по острию ножа, затупив его. - Что скажешь, сейчас он разрежет батон?” “Легко”, - ответила Юля, она знала, что Борис обычно точит ножи очень хорошо и так просто их не затупить. Тут Борис взял оселок погрубее и несколько раз сильно провел по лезвию. После этого он вопросительно посмотрел на Юлю. Она сомневалась. Тогда Борис взял листок бумаги и попытался надрезать кромку, обычно нож спокойно разрезал ее под любым углом, но тут острие только скользнуло по кромке бумаги, не оставив и следа. Юля тут же ответил: “Вот сейчас он тупой и ничего не режет”. “Что мы увидели? - спросил Борис, но и Юля и Саша молчали и ничего не понимали. Борис продолжил, - мы увидели, что любое мышление вероятностное. Вы только что видели как я наточил ножи. Вы знаете, что я точу их хорошо и они точно режут батон. То есть в своей голове вы классифицируете этот конкретный экземпляр, индивид ножа как острый. В вашей логике острые ножи легко режут батоны. Это ваше знание я могу записать в виде модели”.

“Модель позволяет вам предсказать результат ваших действий с конкретными экземплярами каких-то классов”. “Ты обещал про сценарии рассказать, не отклоняйся от темы”, - подала голос Юля. “Любая модель обобщает некоторые важные факты. В данном случае, есть факт того, что я наточил нож, а когда ты, Юля, покупала сегодня утром батон, то знала, что он свежий и мягкий. И ты с помощью своей модели делаешь логический вывод, что нож легко разрежет батон. Кажется, что никаких сценариев у тебя в голове нет, но это не так. Представь, что ты берешь нож и начинаешь резать батон, а он не режется, что ты думаешь?” “Что нож тупой ну или это какой-то фокус, розыгрыш”. “Т.е., в голове у тебя всегда есть альтернативные сценарии, просто их вероятность мала, ты считаешь какой-то сценарий основным, наиболее вероятным. Но если появляются факты, которые не укладываются в логику твоей текущей модели, по которой ты считаешь этот сценарий, ты отказываешься от него и ищешь модель, которая бы объяснила имеющиеся факты и вновь появившиеся. У тебя происходит процесс познания, ты меняешь свои знания о ситуации. Например, ты можешь выяснить что даже острый нож плохо режет замороженную утку.”
“Ты что-то усложняешь”. Борис вздохнул, он часто слышал эти слова: “Да, для такого простого примера, когда все кажется очевидным, это кажется переусложнением. Но возьмем, к примеру, завод. Чтобы его построить, нужна работа людей множества специальностей - архитекторы, проектировщики конструкции, специалисты по инженерным системам, логисты, закупщики и многие другие. Чтобы организовать работу, им надо согласовать свои планы. Чтобы спланировать работу, им нужны модели. Причем эти модели будут принципиально разные для одних и тех же объектов, индивидов. К примеру, какая-нибудь труба для проектировщика будет относится к классу трубопроводов и ее моделью будет конструкторская документация, для монтажника к классу единиц монтажа и ее моделью будет план-график монтажа, а для закупщика это тендерная позиция и моделью будет закупочная спецификация и коммерческие предложения. А отвечаю за то, чтобы труба оказалась на месте вовремя я. В голову я залезть к людям не могу, поэтому мне нужно, чтобы они вынесли содержимое головы. Они выносят это мне в виде такого плана”.


“Т.е., у нас есть конкретный индивид трубы, который установлен по месту монтажа. Допустим вот здесь, - Борис открыл дверцу под раковиной и постучал по колену фановой трубы, уходившей в стену. - А есть проектная документация, которую заложил проектировщик. И ответьте мне на вопрос - а проектировщик заложил этот конкретный индивид трубы или нет?” Юля и Саша молчали, наконец Саша неуверенно ответила: “Нет, он заложил класс трубы, потому что он вообще не знает, какой индивид трубы он получит, это ведь не он закупает трубу”. “А почему он закладывает трубу, если даже не знает, какая конкретная труба придет? Т.е., он даже к реальности не привязан”. “Ну как не привязан, он же знает, что трубы вообще вот используются для таких целей”. Борис довольно кивал головой: “Любая наша логика работает не только с конкретными индивидами, но и с абстракциями. Т.е., когда стейкхолдер находится в деятельностной позиции, он работает с экземпляром класса, а когда планирует, проектирует, думает, принимает решение, он работает с абстракциями, с классами, с моделями. И эти модели задают логику мышления стейкхолдера. Но жить-то приходится не с абстракциями и логикой, жить приходится с реальностью. Поэтому модели надо сверять с реальностью. Нужны факты, которые подтвердят, что конкретный экземпляр трубы, который пришел на стройку и который смонтирован по месту, отвечает модели, которую заложил проектировщик”. “А, и такой вот сбор фактов и есть верификация?”, - наконец поняла Саша. “Бинго, детка! - улыбнулся Борис. - У нас есть несколько моделей системы - спецификация продукта, спецификация требований и конструкторская документация. Когда мы получаем воплощение карандаша, вот оно лежит в коробке, мы сверяем его на соответствие этой документации. А так как мы думаем всегда в сценариях, вариантах будущего, то в этом воплощении мы можем узнать то, что заложено в моделях или не узнать. Когда мы говорим про верификацию, то мы фактически говорим про доказательство стейкхолдерам того, что мы сделали то, что закладывалось в согласованной с ними проектной документацией. Для этого нужны убеждающие конкретно их факты соответствия”. “Как-то это все субъективно”, - расстроилась Саша. “Мир несправедлив, системная инженерия субъективна, объективного успеха не бывает и мы успешно с этим живем”, - ответил Борис. “Подожди, а ты что, с ними уже проектную документацию согласовал?” - вдруг поняла Саша. Борис только улыбнулся ее наивности, взял листок бумаги и начертил диаграмму.

Саша покрутила ее в руках и сказала: “Похоже на научное мышление, которые нам объясняли на школьном проекте”. “Так и есть. Системная архитектура задает набор гипотез по тому, как должна работать система и как она может быть устроена, чтобы работать так, как надо. А модель жизненного цикла задает набор гипотез по тому, как надо организовать работы для того, чтобы спроектировать и произвести систему в соответствии с заложенной архитектурой и жизненным циклом логикой. Верификация собирает корпус фактов, которые доказывают, что конкретный экземпляр системы, индивид, отвечает заложенным моделям. И верификация, как и научный метод, должна отвечать критерию фальсифицируемости. Вообще, тут же еще интересный вопрос про верификацию экземпляра и верификацию типа, мы же не можем при массовом производстве проверять все выпускаемые экземпляры, это будет слишком дорого, поэтому мы проверяем один экземпляр, а потом говорим, что если другие экземпляры выпущены в соответствии с проектной документацией, то они тоже по идее должны проходить такую проверку. И это такая гипотеза, которая регулярно проверяется отделом качества”. “А верификация всегда проходит на экземплярах?” “Нет, в некоторых случаях это невозможно по одной простой причине - это дорого. Помнишь график стоимости жизненного цикла в разбивке по стадиям? Со стороны заказчика он выглядит еще хуже, если дорисовать туда выделение бюджета, то будет примерно так”.

“Видишь, что в стадии проектирования затрачено 15% общей стоимости жизненного цикла системы, но заказчик уже заложил 70% всех расходов, это означает, что он эти деньги заморозил и не может вложить их в другие проекты. А в стадии разработки он выделяет уже 85%. Поэтому заказчики обычно требуют серьезных доказательств того, что заложенные модели и логика работы и производства работоспособны, а ведь никаких экземпляров в этот момент еще нет. Поэтому для того чтобы проверить одни модели, инженеры делают другие”.
“Верификации проводятся регулярно потому что стоимость ошибки растет примерно в 5-10 раз при переходе от стадии к стадии. Но в то же время нельзя проверять все подряд, и тратить на это кучу денег. Поэтому системные инженеры считают экономическую обоснованность различных типов проверок и проводят только те, которые дают самую ценную информацию. Обычно ценность этой информации в том, что снижаются общие риски проекта”. Он все еще что-то рассказывал, но Саша его уже не слушала, она погрузилась в свои мысли, автоматически собрала в коробку опытные экземпляры, документацию и пошла с Борисом в машину. Их ждал заказчик.
Глава 6. “Телепаты в отпуске или как насчет поговорить?” Сдача-приемка и приобретение орг.способности.
Все диаграммы в удобном интерфейсе, с масштабированием находятся в RealTimeBoard


Саша и Борис сидели в дайнере перекусывали после удачной встречи с заказчиком. “Я все-таки не понимаю, как объект для одного может быть атрибутом для другого”, - сказала она, дожевывая остатки сэндвича. Борис свой уже съел и пил маленькими глотками американо. Он отодвинул стакан в сторону и стал рисовать на салфетке.

“Если я хочу заточить неизвестный мне нож, то вначале мне надо измерить его текущий угол заточки, чтобы не сточить лезвие и не тратить кучу времени на переточку лезвия. В этом случае я прямо конкретно представляю себе, что есть такой объект в мире как угол заточки, потому что практика заточки ножей подразумевает, что мы думаем об угле заточки, от этого зависит много чего и поэтому он требует отдельного нашего внимания. Я выставляю этот угол заточки на точилке, я выдерживаю его при заточке, у меня могут быть требования, связанные с углом заточки. Но у уже заточенного ножа нет никакого угла заточки как отдельного объекта, потому что самого угла заточки не существует, есть лезвие. И вот свойством лезвия будет какой-то угол заточки хотя бы для того, чтобы его можно было не измерять при последующих заточках, а сразу выставить. Поэтому угол заточки скорее всего должен пойти в спецификацию продукта нож как важная характеристика”. “Не очень поняла все равно”. “В общем, если мы говорим про знания, то первая характеристика знаний - это их переносимость между различными ситуациями и возможность повторного использования. Сами знания могут касаться либо абстракций, работать с классами, либо касаться конкретных экземпляров этих классов. Например, можно знать как работать шеф-ножом вообще и уметь более-менее управляться с любым шеф-ножом, а можно уметь работать с конкретным шеф-ножом. Или уметь работать в САПР в принципе и понимать ее функциональность и устройство в целом либо уметь как обезьянка нажимать кнопки в конкретном релизе, чтобы получить конкретный выдрессированный результат. В случае со знаниями, которые касаются конкретных экземпляров, говорят о навыках”. “Подожди, но ведь знания и навыки - это совсем разные вещи?” “Да? Почему это?” “Ну, знать это же не уметь сделать...” “Вот смотри, представь, что сейчас выходит совершенно новый САПР, в котором я ни разу не работал. Я не мог физически сформировать навык работы в нем. Как думаешь, смогу я в нем начать проектирование?” “Э, не знаю, наверное что-то сможешь сделать”. “Да, скорее всего смогу, если там не заложена какая-то принципиально новая дисциплина мышления. То есть у меня есть переносимое между ситуациями знание относительно классов объектов, инструментов, которое при работе с конкретными экземплярами становится навыком той или иной степени отработанности”. “Не понимаю в чем дело, почему так?” “Все просто. И знания и навыки имеют одну и ту же реализацию, воплощение. И знания и навыки есть просто определенным образом сконфигурированная нейронная сетка. Вот допустим пример - на твоем iPhone есть skill узнавать твое лицо и разблокировать телефон только тебе. А еще есть skill назначать совещания, звонить и выполнять другие твои голосовые команды. Как он это делает? У него есть знание того какие бывают голоса, чем они отличаются и как распознавать голоса людей друг от друга. Ну, или лица или отпечатки пальцев. И когда ты настраиваешь iPhone под себя в начале, ты эти знания привязываешь к конкретному экземпляру голоса, отпечатков, твоему лицу. Это еще называется подведением под тип. Так что знания и навыки суть одно и то же”. “Ты мне прямо сейчас мозг сломал”. “Давай вернемся к знаниям. Системная инженерия это такая полезная бюрократия, нас не интересуют знания и информация, то есть то, что внутри людей, концепты. Нас интересует семантика, выражение этих знаний, другими словами, информация и данные. Отличие между информацией и данными очень простое - информация передает смысл в произвольной форме, а данные имеют строгую заранее определенную структуру. В системной инженерии обычно говорят, что есть справочные данные, которые выражают знания, и проектные данные, которые касаются конкретных результатов конкретной работы в конкретном проекте”. “Подожди. Что такое проектные данные и что такое справочные данные. И давай на конкретном примере, - Саша взяла в руки стакан из под кофе, допила остатки, открыла крышку, вытерла салфеткой остатки кофе, опять закрыла ее и поставила стакан перед Борисом. - Так капать не будет”.
“С какой позиции тебе рассказать?” - удивился Борис. “Подожди, вот стакан. Какие данные об этом стакане будут проектными, а какие справочными? Вот материал например или его габариты - это проектные данные или справочные? А цена?” “Так я тебе и говорю, что нельзя сказать, что какие-то данные справочные или проектные, если не уточнять с какой точки зрения, с позиции какого стейкхолдера мы на них смотрим”. “Чушь какая-то. У тебя же не может быть одна и та же информация быть как справочной, так и проектной?” “Давай разбираться, - сказал Борис, на что Саша кивнула и внимательно посмотрела на него. Борис вздохнул и начал. - Вот есть конструктор стаканов. Ему принесли спецификацию требований, что он по-твоему делает дальше?” “Придумывает конструкцию, которая отвечает этой спецификации требований”. “Не одну конструкцию, а несколько. Должно быть пространство выборов. Он из своего опыта и из инженерных каталогов и справочников знает, что одноразовые стаканы бывают полипропиленовые прозрачные, полипропиленовые окрашенные, бумажные, бумажные с покрытием, полистироловые, ПЭТ ну и наверное какие-то еще. Он понимает, что есть стаканы бывают для кулеров, для ручного розлива, для вендинговых автоматов, для холодного и горячего, что они бывают с теплоизоляцией и без нее, окрашенные и неокрашенные, с возможностью печати и без возможности печати и много какие еще. Что это все, как назвать одним словом?” “Классификаторы”. “Да, есть множество различных знаний о стаканах и они все хранятся как классификация этих стаканов. Вообще, классы и есть выражение знаний, запомни эту мысль, мы к ней вернемся. Классификаторы описывают эти классы стаканов где-то в информационной системе. Эти классификаторы уже существуют, хранят описания знаний в тот момент, когда разработчик стаканов решает разработать свой стакан. Какие это знания для него?” “Справочные, наверное, ведь они уже хранятся в классификаторах для его справки”. “Да, это справочные знания. А теперь представь 1940 год, когда открывался МакДональдс и такого массового производства одноразовых стаканов для холодного, горячего с печатью и без, с крышечками и без крышечек еще не было. Существовали все эти классификаторы тогда?” “Может и были, но точно не такие полные”. “Во! Эти классификаторы создавались, кто-то их придумывал. И вот когда их придумывали, то это были проектные данные, данные, которые создают в каком-то проекте по разработке изделия. Теперь вернемся в текущий момент. Вот разработчик читает спецификацию требований и выбирает между вариантами полипропиленового и бумажного стаканчика и решает, что больше подойдет бумажный емкостью 280 мл с гофрированным кольцом для теплоизоляции. Это высокоуровневое проектирование, иногда его еще называют архитектурным проектированием. Весь процесс разработки, проектирования по сути и есть выбор какого-то класса, процесс принятия решения по устройству изделия, уточнение онтологии проекта. Вот в данный момент мы выбрали класс бумажный стакан 280 мл с гофрированным кольцом. Что произошло с этими данными?” “Какими данными?” “Вот смотри. Есть справочные данные - стаканы бумажные и стаканы полипропиленовые, стаканы 350 мл и стаканы 280 мл. Разработчик делает выбор, оформляет его выпуском документации, что в этот момент становится со справочными данными?” Борис смотрел в непонимающие глаза Саши, достал маркер, взял со стола салфетку, развернул ее и нарисовал табличку.

Point design стакана (спецификация изделия) на стадии высокоуровневого проектирования:
Материал -- бумага
Емкость -- 280 мл
Жидкость -- до 100 ℃
Накладка -- гофрокартон

“Видишь, справочные данные в момент выбора point design становятся проектными данными”. “Интересно”. “Не это даже самое интересное. Вот подумай, эти проектные данные кому и для чего нужны?” “Ну, наверное, изготовителю”. “Еще нет, если ты отнесешь это изготовителю, то он сразу спросит - а какая бумага нужна, плотность, марка, клей, какой полипропилен на крышку, конструкция крышки, толщина гофры, в общем еще куу информации. Как ее получить?” “Отдать получившийся высокоуровневый дизайн конструктору”. “Да, а для конструктора вот эти данные чем будут? Справочными данными или проектными. И не спеши с ответом, он не так очевиден, как кажется”. Саша напряженно думала вслух: “Эти данные в свою очередь являются классификаторами. Например, бумага может быть различной плотности, различной водостойкости и иметь разную теплопроводность. Емкость 280 млн можно получить стаканами разной формы, да гофрокартон может быть очень разный. И еще они могут подлежать повторной обработке или нет”, - Саша была за ответственное потребление. “Правильно, каждый вариант конструкции, оформленный выпуском документации, можно уточнить дальше, и тогда то, что было проектными данными на предыдущей стадии, станет справочными данными для следующей стадии. Так, например, проектные данные, что стакан надо изготовить из пищевого картона марки КПБ-12 толщиной 0,5 мм станут справочными данными для закупщиков, которые будут искать поставщика такого картона и производство стаканов, которое будет работать с этим материалом. А изготовитель стаканов, который произведет их из картона КПБ-12, запишет в своей MRP системе, что лот 15 был произведен с использованием этого картона. Данные лота 15 будут для изготовителя проектными данными, а для кафе, которое закупило этот лот и разлило кофе в один из стаканов этого лота информация по лоту будет справочными данными. И так далее”. “Получается, что стадии - это тогда, когда какой-то набор данных остается в статусе справочных и проектных? Например, стадия высокоуровневого проектирования - это когда point design архитектурного проектирования находится в статусе проектных данных и не перешел в статус справочных данных, другими словами не оформлен выпуском с литерой Э?” “Именно так, но только с инженерной точки зрения. Потому что у руководителей проектов свое деление по стадиям, которое основано на гейтах, контрольных точках принятия решений, защитах проектной документации”. “Ага, понятно. Получается, это и есть управление конфигурацией - согласование справочных и проектных данных, поддержание их согласованности?” “Ну, в целом так и есть, управление конфигурацией состоит из четырех процессов - управление выпуском конструкторской документации, запрос и проведение инженерных изменений, это два процесса и управление ведомостями и спецификациями материалов. Если смотреть на бизнес крупно, то для инженерно-производственной компании нужны:
а) деньги для запуска компании и перехода от прибылей к процветанию
б) инструменты - здания, техника, пресс-формы, ПО и т.д.
в) люди и те установки/практики, что они выбирают
г) продукт, воплощенный в проектных чертежах и спецификациях.

Управление конфигурацией обеспечивает организацию актуальными и непротиворечивыми справочными и проектными данными, которые полностью описывают продукт, который предприятие производит”. “А где эти данные хранятся?” - Саша задумалась на секунду, вернулась к реальности и задала осмысленный вопрос. “Справочные и проектные данные хранятся в PDM либо PLM системе. Либо в BIM, иногда еще в MRP, ERP, EAM. Смотря что тебя интересует”. “Ладно, с остальным разберемся потом, расскажи, почему ты вначале выделил PDM и PLM, в чем различие между ними?”

Борис перевернул стакан, показал пальцем на кромку дна и спросил Сашу: “Видишь покрытие?, - Саша помотала головой, тогда Борис взял со стола столовый нож и поскреб им донышко. - А теперь, обрати внимание на то, что в месте, очищенном от покрытия, четко виден голый картон, а на остальном ободке есть матовая пленка, ее хорошо видно по отсвету”. “Ага, теперь заметила. Что с ней?” “Зачем нужна эта пленка? Почему она является элементом конструкции?” “Это же водостойкий картон, просто покрытие, чтобы он не размокал от налитой жидкости”. “Эта часть стакана снаружи, какая здесь жидкость? Это ведь целая дополнительная технологическая операция - нанести пленку с двух сторон картона, она стоит денег, зачем это заложено в конструкцию? Почему принято такое решение?” “Ну, не знаю, какая твоя гипотеза?” “Смотри, я думаю, что это не водоотталкивающее покрытие, потому что когда я провожу по нему пальцем, то оно не скользит так, как скользит палец, когда я провожу пальцем по внутренней стороне стакана”. “Это и есть верификация продукта, то что ты сейчас делаешь?” “Подожди, сейчас доберемся до этого. Пока это просто факт - покрытие на ободке дна стакана противоскользящее, его коэффициент трения явно выше, чем у обычного картона. Скорее всего это не просто так, а было такое требование, которое и реализует этот элемент конструкции. Теперь вопрос, а зачем было требование условно _Наполненный_Стакан_ должен иметь _силу_трения_покоя_ 10 Н?” “Возможно, есть потребность, чтобы стакан не скользил по подносу и по столу”. “Почти. Скорее я бы сказал, что есть потребность, чтобы полный стакан не упал и не разлился, а отсюда возникает потребность, чтобы дно стакана не скользило по поверхности при небольшом наклоне либо слабых толчках. И вот от этих потребностей и возникает системное требование”.


“Теперь вопрос, а откуда приходит потребность в том, чтобы полные стаканы не падали и не разливались? Хотя даже так - к какой стадии жизненного цикла относится эта потребность?” “К стадии использования, эксплуатации”, - не растерялась Саша. “Да, это стадия использования одноразового стакана. И вокруг этого стакана есть эксплуатационный контекст”, - Борис взял вторую салфетку и нарисовал.

“Это уровень бизнес-операций, на котором есть потребности и требования заинтересованных сторон. Какие потребности и требования ты можешь задать исходя из этой диаграммы эксплуатационного контекста?” “Мне, как посетителю кафе, надо чтобы стакан обеспечивал высокую температуру кофе, потому что холодный кофе невкусный. Мне, как посетителю кафе, надо чтобы напиток не проливался на меня, если стакан или поднос толкнут, потому что это может испортить одежду или я обожгусь”. “Здесь я тебя остановлю. Теперь какие требования вытекают из этих потребностей?” “Посетитель кофейни не должен облиться содержимым стакана при проверке стакана на проливаемость по условиям спецификации испытаний №123. Это первое требование. Второе - Стакан должен удерживать _температуру_жидкости_ в пределах 15℃ от _температуры_сервировки_ в течении 15 минут”. “Это уже системное требование, но ладно, запишем его. Замечу, что эксплуатационный контекст отвечает на вопросы маркетингового обоснования проекта, из него мы понимаем, зачем продукт нужен потребителю. Например, одноразовые стаканы по сравнению с обычными чашками позволяют брать напитки на вынос, обеспечивают защиту от дождя и снега, защищают напиток от чихающих людей вокруг. Вот ровно эти штуки и можно рекламировать”. “Плюс, он не скользит по столу и из него на вас не прольется горячий кофе”. “На вас и на вашего ребенка. Все так. Но эксплуатационный контекст может не ответить на вопрос экономического обоснования. Улучшить обслуживание клиентов - это здорово, но надо понять, а что же станет лучше в бизнесе, где и на чем мы заработаем, только под такое спонсор проекта дат деньги и ресурсы. И поэтому надо рассмотреть одноразовые стаканы в бизнес-контексте”. “Мне кажется, мы что-то далеко ушли от темы отличия PDM и PLM”. “Мы плавно подходим к различию между ними. Слушай внимательно. Представь, что ты владелец сети кофеен и сейчас вы используете керамические чашки. К тебе приходит твой сотрудник и предлагает проект по переходу от чашек к одноразовым стаканам, объясняет, чем это хорошо для клиента - можно брать на вынос, гигиена, безопасность, вот это все. Давай, что для тебя будет важно?” Саша задумалась на пару секунд и начала перечислять: “Прежде всего, себестоимость этих стаканчиков не должна превышать стоимости использования керамических кружек. Либо покупатели должны быть готовы заплатить разницу, я не буду работать себе в убыток, - Борис довольно кивал и Саша раздухарилась. - Можно, конечно, сэкономить, делая раздельный сбор стаканчиков и остального мусора, отправлять их на переработку, так можно сэкономить на себестоимости сырья. Эти стаканы должны помещаться на подносе как и керамические чашки. Еще стаканы можно сделать намного больше по емкости, значит можно продавать больший объем напитков. Храниться они должны в тех же контейнерах, по крайней мере в том же объеме, потому что переоборудовать места хранения во всех кафе под новые стаканчики будет дорого. Что еще? Да, мусорные контейнеры надо будет либо убирать чаще, либо ставить другие потому что у стаканов большой объем. Зато можно брендировать стаканы и летом задешево получать дополнительную рекламу от тех, кто берет на вынос. Получается, что надо будет еще заключить договор на регулярную поставку этих стаканов и развозку их по точкам. Еще учет надо поменять, чтобы персонал не тащил домой или не продавал. Вроде все”. Саша довольно улыбалась, Борис удовлетворенно кивнул: “Я бы накидал еще несколько пунктов, но для иллюстрации различий хватит и этого. Смотри, представь, что ты посчитала затраты на этот проект и оцифровала выгоды. Оформила технико-экономическое обоснование, а ключевые переменные и факторы ТЭО зафиксировала как бизнес-требования. Допустим, себестоимость стаканов должна быть не выше 20 центов, инвестиции в проект не больше 1 миллиона, окупаемость 12 месяцев, удовлетворенность клиентов больше 90%, рост операционных затрат меньше 0,3%, повышение уровня товарных запасов не более, чем на 1 день, риски судебных разбирательств со стороны клиентов меньше на 200 тыс. долларов в год. ТЭО говорит тебе, что проект стоящий и ты начала его делать.”

“Если ты обратишь внимание, я связал противоскользящее покрытие на дне стакана с бизнес-потребностями. Поэтому, если какой-то эффективный менеджер придет и скажет, что давайте, ребята, снизим себестоимость производства на 1,5 цента и уберем это покрытие, я сразу увижу, что это повлияет на бизнес-цель по количеству судебных исков и смогу подготовить ответ почему убирать покрытие - плохая идея. Теперь представь, вот ты стартовала проект по внедрению бумажных одноразовых стаканов. Проектировщик придумал первые варианты конструкции и принес их на обсуждение команды. Замечу, в этот момент point design хранится в САПР и в PDM системе, потому что мы говорим о продукте. Что произойдет дальше?” “Ну, они обсудят конструкцию и решат что-нибудь”. “Смотри, есть целевая система одноразового стакана, но чтобы встроить эту целевую систему в деятельность предприятия нужны обеспечивающие системы. Если есть стаканы, то нужно, чтобы их кто-то разработал, изготовил, перевозил, их надо где-то хранить, собирать в мусор, перерабатывать. Вот все эти системы, которые создаются в проекте по внедрению бумажных стаканов и называются обеспечивающими системами”.

“Созданием целевой системы занимаются инженеры, созданием и поддержанием обеспечивающих систем занимаются менеджеры, если очень просто. Теперь смотри, проектировщик принес конструкторскую документацию на стакан, значит он подготовил выпуск как минимум концепции стакана. Смотрим на обеспечивающие системы - отдел закупок и производство смотрит на эскизную документацию и говорит - мы спросим производителей, посмотрим, какие они дадут цены на эту конструкцию. Логистика будет считать стоимость упаковки и транспортировку с хранением, операции будут прикидывать как они будут это хранить, поместиться ли такой стакан на поднос и смогут ли в него разливать напитки на текущем разливном оборудовании. Административный отдел будет смотреть, поместятся ли плановое количество стаканов в мусорные баки, предусматривает ли текущий договор утилизации мусора вывоз этих стаканов и какой уровень утилизации может быть. Допустим, рабочая группа дала добро и эскизный проект одобрили. Инженер делает технический выпуск и проектные данные, которые он создал, становятся справочными данными. Это означает что?” “Что другие будут ими пользоваться”. “А значит?” “Они должны лежать в общем хранилище”. “И еще?” Саша думала, но ничего больше в голову не приходило. “Справочные данные можно менять только по определенной процедуре. Потому что справочные данные вводятся во множество разных систем и если ты их изменяешь, то надо менять согласовано во всех системах. Например, если ты указала, что спецификация бумаги такая-то, то эта информация будет внесена в производственную систему, в закупочную систему, в таблицы отдела качества, в пищевые сертификаты. И если инженер хочет изменить чертеж и указать там другую спецификацию на материал стакана, то это изменение должно быть отражено во всех этих системах. Покажу тебе на почти реальном примере. Вот представь, что стакан спроектирован, выпущена документация с литерой О, изготовлены опытные образцы, которые поставили на испытания. И тут выясняется, что крышка не всегда достаточно плотно закрывается, на чертежах поставлен слишком большой допуск, а угол скоса слишком крутой. Это означает, что спецификация на продукт не выполняется и надо выпускать извещение на инженерное изменение. Проектировщик меняет чертеж, правит допуск, увеличивает крутизну скоса и для сохранения объема уменьшает высоту стакана. Готовит новые чертежи и приносит их на комитет по изменениям. Вначале отдел закупок говорит, что изменение потребует изменения оснастки и это будет стоить 15000 и займет три недели. Плюс, такая конструкция меняет эффективность раскроя и с этими листами выход годных уменьшается на 12%, что в конечной себестоимости это изменение приведет к +4,3% и выйдет за целевую цену. Чтобы снизить цену надо изменить размер закупаемого листа, у текущего поставщика нужного размера нет и придется заключать еще один контракт, это еще 4-6 недель включая тендерную процедуру. Потом слово берет начальник производства, который говорит, что надо будет изменить формовочную фикстуру и переоборудовать стол проверки качества. Плюс, новую конструкцию надо будет обкатать на пилотной партии, потому что непонятно, сможет ли машина для нанесения клея без перенастройки переключаться между этой конструкцией и текущими производственными заказами. По идее должна, но этот шов на грани возможностей производственной линии. Отдел логистики говорит, что из-за уменьшения длины стаканов в один тубус транспортировочной тары влезет больше, и придется изменить размер транспортировочной партии, поставлять в точки партии больше. Тут выходят операции и говорят, что им и это некуда класть, куда уж больше, это же увеличение товарных запасов в производстве, у них и так KPI по ним жесткие. Хотя уменьшение высоты им нравится, потому что текущая конструкция еле влезает под разливочные краны”. И это обсуждение длится достаточно долго, пока комитет по изменениями не принимает, наконец, решения, одобрить его, но с отложенной датой вступления в силу, т.к. иначе график запуска выдержать будет нельзя, это было решающее мнение руководителя проекта. Чертежи и спецификация материалов одобряются в системе контроля инженерной документации и публикуются для общего доступа. Остальные подразделения начинают отрабатывать изменения в своих процессах и вносить изменения в ИТ-системы. Так вот, ИТ-система, в которой хранятся новые чертежи, спецификации стаканов, ведомости материалов, брошюры и руководства по ним, называется PDM, product data management. А весь комплекс программ, который содержит все данные и по обеспечивающим системам, включая данные по закупкам, производству, обслуживанию, качеству, плюс данные по продукту, называется PLM. PLM поэтому еще называют подходом, концепцией, потому что редко бывает, что вся необходимая информация по жизненному циклу хранится в одном программной комплексе. BIM - это специализированный для строительства и монтажа PDM вместе с САПР с функциями параллельной разработки и публикации 3D либо 4D моделей с функциями сравнения версий и стандартной моделью атрибутов объекта капстроя. Вот, примерно так”, - выдохнул Борис, закончив объяснение, и какое-то время они сидели и слушали негромкий гомон дайнера. “Т.е., PDM содержит информацию только по целевой системе, по продукту, его чертежам, спецификациями и моделям, а PLM содержит данные по всему жизненному циклу? И получается управление информацией по продукту - это управление конфигурацией, а управление данными жизненного цикла - это управление изменениями?” “Ну, в общем, близко к истине. Иногда говорят, что управление изменениями это управление именно конфигурацией обеспечивающей системы. Т.е., чертежи и спецификации стакана отдельный процесс, а изменение конфигурации всего того, что надо для того, чтобы произвести стакан нужной конфигурации - это управление изменениями. Инженеров и производственников волнует управление конфигурацией, а руководителей проектов волнует управление изменениями”. “Смотри, получается, что жизненный цикл хранит знания о том, как разработать, произвести, использовать и вывести из эксплуатации продукт?” “Жизненный цикл просто есть. Это эволюция, стадии изменений, которые проходит продукт, система. Вот у бабочки есть жизненный цикл - яйцо, личинка, гусеница, кокон, взрослая особь, труп. Фактически, мы можем сказать, что вещь бабочка состоит из 6 других вещей, временных, темпоральных частей. Ты же отличаешь летающую бабочку от гусеницы?, - Саша кивнула, она стала понемногу понимать логику. - А вот модель жизненного цикла продукта да, хранит информацию, не сами знания, конечно, про то, как разработать продукт и его концепцию, произвести его, использовать, вывести из эксплуатации и переработать. Наверное да, так и можно сказать, что системная инженерия это набор согласованных между собой методов по извлечению, строгой записи и применению всех ключевых знаний, которые нужны для реализации жизненного цикла продукта”. “А я думала, что знания есть только у людей. А тут ты говоришь, что практика системной работает со знаниями. Что-то не очень понимаю. А разве практика менеджмента не описывает ключевые знания по разработке и созданию продукта?” “Под словом менеджмент много что может скрываться. Если подразумевать под ним управление операциями, то там три ключевых понятия - это ресурсы, очереди и проход работы через организацию. Задача менеджера так организовать деятельность, чтобы работы были выполнены с минимальной стоимостью задержки и приносили максимальную пользу с минимальными рисками. Как видишь, менеджеры работают с индивидами, экземплярами классов, в правой части V-модели. Системные инженеры же больше стремятся работать с моделями, больше работать в левой части V-модели. Ну и опять-таки, системные инженеры думают обо всем жизненном цикле, менеджеры делятся на тех, кто организует разработку и производство, это проектные менеджеры и на тех, кто организует использование, операционные или бизнес-менеджеры. Системные инженеры думают о целевой системе по большей части, а менеджеры об обеспечивающей, об организации. Менеджеры нацелены на прибыль, системные инженеры на успех системы, удовлетворенность стейкхолдеров”. “Ага, вроде стало понятнее. Т.е., системные инженеры управляют жизненным циклом, а менеджеры управляют работами?” “Да, все верно”. “Хорошо, а менеджер - это стейкхолдер?” Борис чуть не поперхнулся: “А что такое стейкхолдер по-твоему?” “Это человек, который исполняет какую-то практику жизненного цикла системы. И вот когда он исполняет эту практику жизненного цикла он держит в уме, что надо произвести эту целевую систему, это его цель. Но практика накладывает рамки на эти цели и эти рамки задают его деятельностные интересы, отсюда и вытекает какое-то его ролевое поведение, которое можно предсказать и по поводу которого происходит координация в команде”. “Ого, ты что, мои посты читала?” “Да, было дело”, - улыбнулась Саша. “Да, стейкхолдер - это агент. И как у любого другого агента у него есть цель, она задается определением целевой системы ну или концепцией продукта, как эту штуку не назови. У этого агента есть знания в какой-то области, он может построить в голове реалистичную картину мира и прокрутить ее в динамике, понять, какие могут быть последствия тех или иных действий. Знания стейкхолдеру нужны для того, чтобы понять, какие действия будут наилучшими для достижения цели. То есть стейкхолдер не только знает, но и делает. Можно сказать, что у стейкхолдера есть позиция действия и позиция знания. Но знание, как мы уже говорили, есть класс, а действовать надо с индивидами. Например, я смотрю на этот стол и понимаю, что этот предмет является ножом, мои знания позволяют классифицировать его как нож. Как только я классифицировал предмет как нож, я могу с ним работать с использованием своих знаний о ножах. Я понимаю, что им можно давить, можно пилить, можно резать, как его держать и как им не порезаться. Куча знаний, которые я получил в течение всей жизни и которые являются частью меня как агента, закодированы в моих нейронных сетях. И какая третья позиция есть у стейкхолдера? - но Саша не знала. - Позиция познания. Еще говорят онтология, позиция знания, классификаторы всех вещей, которые есть в мире. Классы определяют знания. Деятельность, умение работать с конкретными индивидами, навыки. И эпистемология, по- знание. Как мы получаем знания. То есть как я узнал, что нож режет? Как я понял, что этот предмет, который подходит под класс ножа на самом деле нож и я могу использовать практику работы с ножами?” Борис положил нож на стол, потому что на них стали оглядываться с соседних столов, и понизил голос. “Смотри. Я вижу какой-то предмет. Мои знания, онтология, говорит мне, что это нож. Я с помощью знаний строю в голове план - взять нож, разрезать булочку, намазать на нее масло, положить нож так, чтобы другие им не порезались. Это стейкхолдер в позиции знания. Потом я беру нож, режу булочку, намазываю масло, кладу его на место. План выполнен. Это стейкхолдер в позиции деятельности. Когда я режу ножом булочку, то постоянно проверяю, а режет ли нож? Является ли этот предмет ножом? Можно ли им исполнять практику работы с ножом? Если он вдруг не режет, я проверю его заточку. Если он острый, но не режет, я очень удивлюсь, это будет новое для меня знание, что есть, оказывается, такие ножи, которые острые, но не могут разрезать булочку. Это позиция познания”.

“Проверь, правильно ли я поняла. Вот я умею печь блины. Думаю - надо 2 стакана муки, яйцо, молоко, масло, горячая сковорода. Это позиция знания. Потом я беру все это, замешиваю тесто, это позиция действия. Я вижу, что тесто жидковато и блины будут слишком тонкие, уточняю свои знания для конкретно этой муки и молока, для индивидов, потому что знания у меня касаются муки и молока как классов, в общем, я еще раз планирую - надо досыпать муки, это опять позиция знания. Досыпаю, это позиция действия. Вижу, что тесто нормальное по консистенции, начинаю печь, проверяю цвет блинов, скорость запекания, пробую их на вкус, думаю, что надо добавить сахара, это рефлексивная позиция знания”. “Да, похоже на правду”. “Хорошо, стейкхолдер - это агент, у которого цель создать продукт и у него есть три позиции - знания, познания и действия. А что такое практика тогда?” “Ты одна умеешь печь блины на всем свете?” “Нет, конечно”. “Вот все стейкхолдеры, которые умеют печь блины, объединяются, агрегируются в класс, множество стейкхолдеров-блинопеков. Такое множество, класс и называется практикой печения блинов”. “То есть вся эта толпа народа и есть практика?” “Еще раз, что я говорил про классы?” “Не помню”, - смутилась Саша. “Повторяю в который раз, запомни, пожалуйста. Есть индивиды, воплощения, физические, реальные объекты. По ним можно постучать, их можно куда-нибудь положить, сфотографировать в конце концов. А есть классы, это абстракции, концепты. Вот практика и есть такая абстракция”. “А эта абстракция воплощается в конкретном стейкхолдере, да?” “Верно, практика воплощена в конкретном стейкхолдере, в человеке, который сейчас, в конкретный момент времени исполняет эту практику, цикл PDCA. А практика идеальна, она состоит из знаний предметной области, они называются дисциплиной, как, например, дисциплина тригонометрии, машиностроения или кулинарии, и из технологии. Какое первое слово приходит тебе в голову, когда я говорю технологический?” “Прогресс, процесс”. “Во, технология часто моделируется и обозначается как процесс. Например, процесс печения блинов - это технология практики печения блинов, процесс вождения автомобиля - это технология практики вождения автомобиля. Процесс работает с какими-то объектами, мы их называем операндами, как в математике, операнды функции. Можно еще их называть объектами деятельности или на жаргоне ИТ-шников информационными объектами или бизнес-объектами. Это те самые прямоугольники, которые мы с тобой рисовали вначале, и из которых состоит онтология проекта”. “Смотри, если у нас уже есть стейкхолдеры, то зачем нам нужны практики, я не понимаю. Это же одно и то же, нет?” “Практики абстрактны, стейкхолдеры конкретны. Вот зачем тебе рецепт блинов? Чтобы печь разные блины в разных условиях. Практика строительства заводов по производству композитного волокна позволяет планировать проект строительства не привязываясь на начальных стадиях к конкретным подрядчикам, людям, организациям и имеющимся в наличии материалам и оборудованию. С конкретикой уже работают операционные менеджеры, а системные инженеры работают с абстракциями, копят знания о том, как производить такой класс систем в целом. Операционные менеджеры же копят знания о реальности, о конкретных поставщиках, исполнителях и регламентных особенностях конкретных юрлиц”. “А-а-а! То есть определение жизненного цикла системы хранит в себе такие вот переносимые между ситуациями знания? А план проекта приземляет эти абстракции на конкретные условия, исполнителей и отношения?” “Ага”. “Подожди, а кто соединяет эти миры абстракций и реальности? Вы, системные инженеры?” “В части железок да. А вот в части людей этим занимаются лидеры”. “Это как?” “К примеру, я как системный инженер закладываю в жизненный цикл практику печения блинов потому что знаю, что она очень важна для производства целевой системы, допустим, моего живота. Дальше, из позиции операционного менеджера я говорю, что ты должна выполнить задачу и испечь стопку блинов. Ты мой ресурс и стейкхолдер-блинопек, у тебя есть знания, ты умеешь это делать, у тебя есть компетенция по печению блинов. А ты такая говоришь, что не хочешь печь блины, может быть завтра испечешь или через неделю, но сейчас настроения нет. Стой, говорю я из позиции операционного менеджера, блины нужны мне сейчас, у меня отгрузка живота через неделю, надо показать прирост 300 грамм минимум, а лучше полкило. Но ты не соглашаешься. И тогда я встаю в лидерскую позицию, взываю к твоим лучшим чувствам, умоляю и обещаю разные хорошие вещи типа дополнительно 30 минут на YouTube в неделю. Вот это совмещение личности и предполагаемой организацией проекта стейкхолдерской роли и есть предмет лидерских практик”. “А получается, что лидер должен иметь на входе модель жизненного цикла продукта?” “Да, модель жизненного цикла, самих людей, из которых надо построить команду, и модель архитектуры предприятия”. “Что такое архитектура предприятия?” “А про это мы поговорим чуть позже, пока собираемся и едем дальше”. 

Саша спустилась к завтраку хмурая, даже не пожелала доброго утра. Отказалась от омлета с салатом и насыпала себе кукурузных хлопьев с медом и орешками. Борис осторожно спросил ее: “Ковырялся ли кто-то в носу вчера в школе?” Саша удивленно посмотрела на него. “Если бы школа была аттракционом, какой бы это был аттракцион?” - не унимался Борис. “Что стало с обычным как дела?” - наконец ответила Саша. “Как дела вопрос слишком абстрактный, далекий от реальности, ответить на него можно все что угодно. Так ты ничего не выяснишь. Вопросы должны быть с одной стороны открытыми, предполагать развернутый ответ, а с другой максимально конкретными. Вот тогда ты получишь качественную информацию”. “Рубрика бизнес-анализ по утрам началась, - заметила Юля. - Ты бы еще спросил если бы инопланетяне прилетели в школу, чтобы забрать троих детей — кого бы они выбрали?” “Меня-меня-меня!” - закричала Саша и подняла руку, да так громко, что даже кот оглянулся на нее и ушел с кухни. “Вот мы и подобрались к сути, - радостно заявил Борис. - Теперь рассказывай, ребенок, что произошло за ночь?” Он приготовился было услышать очередную историю про переписку и комментарии к фото или видео, но Саша грустно сказала: “Не получается ничего приличного нарисовать этим карандашом. Столько сил и времени, а все зря”. “Ага, радио есть, а счастья все еще нет. Это нормально”, - ответил ей Борис. “Нормально в смысле с этим можно что-то сделать?” “Сделать точно можно, вопрос в том, уложимся ли мы в проектные ограничения и как в них оптимально уложиться. Но раз уж мы заговорили на эту тему, то давай поговорим про архитектуру предприятия”. “Серьезно? Осталось два дня, ничего не получается и ты хочешь прочесть еще одну часовую лекцию?” “Надо уметь делать, понимать, как ты это делаешь и понимать почему ты это делаешь именно так, чтобы вовремя переключиться на более результативное поведение. Можешь назвать это стейкхолдерской осознанностью”. Саша взяла архитектурный маркер, который лежал на скетче производственной линии, и написала на обороте красивыми буквами MINDFULNESS. “Да, только без эзотерики и Тони Роббинса, - скривился как от кислого Борис, и спросил Сашу. - На каком примере будем разбирать?” “На котиках!” “На котиках тоже будем, но они сложные, а для начала я хотел бы чего-нибудь попроще”. “Чего в котиках сложного?” “В котиках все сложное, особенно архитектура, поверь мне. Не одного студента я завалил вопросами про котиков. То, что ты посмотрела сто тыщ видео про их поведение не делает тебя системным инженером со специализацией на кошачьих”. “Ну ладно, давай котиков потом, - Саша выглянула в окно, посмотрела на улицу, увидела красивую витрину с багетами и хлеба и предложила, - давай булочную”. “Хорошо, возьмем даже уже, не всю булочную, а пекарню”. Когда мы говорим про архитектуру, то какие две вещи первыми всплывают в памяти? “Форма следует за функцией. Форма и функция, две вещи”. “Все верно, ребенок. Теперь расскажи-ка мне про функцию и форму пекарни”. “Ага, в начале надо замесить тесто, для этого нужны ингредиенты, из получившегося теста слепить булочки, и запечь их”. Борис нарисовал диаграмму и спросил Сашу: “Ничего не забыла?”


“Да, форму забыла. А что здесь будет формой вообще?” “Вот тут-то и хитрость. Кто замешивает тесто, кто лепит булочки, кто печет булочки?” “Булочник”. “Я же водил тебя на производство, там то, на всех станциях и постах один человек стоит? Или того, кто лепит булочки допускают к замесу теста?” “Нет, там были отдельные люди и ты говорил, что замес теста штука сложная”. “Формовка тоже может быть непростой, да и печь надо уметь. Это три разные структуры, которые исполняют три разные функции. Назови их”. “Замешивающий, лепильщик и хлебопек, хотя звучит это ужасно”. “Что это тебе напоминает, из того, что мы недавно обсуждали?” “Это стейкхолдеры?” “Именно. Форма, структура, может представляться стейкхолдерами, давай так и запишем”, - и он дорисовал диаграмму.

“Описывает ли эта диаграмма организацию выпечки? Если не хватает, то чего?” “Ты говорил, что практика = дисциплина + технология. Дисциплину мы указали, у нас есть стейкхолдеры. Осталась технология, здесь ее нет”. Борис довольно кивнул и дорисовал диаграмму еще.

“Вот смотри, - сказал он. - Жизненный цикл проекта по созданию булочки. Это модель такого жизненного цикла, здесь показана функция и форма. Инструменты - рецепты, миксер, форма, печка, вытяжка, еще называются инфраструктурой проекта. И одна из обязанностей руководителя проекта - обеспечивать доступность инфраструктуры для того, чтобы вовремя выполнить работы, которые подразумевает практика жизненного цикла. Без модели жизненного цикла в явном виде руководитель проекта обязательно забудет про какие-то элементы инфраструктуры, не договорится с владельцами ресурсов, и сроки работ будут сорваны”. “Почему ты сказал, что это модель жизненного цикла проекта, а не жизненного цикла системы?” “Жизненный цикл системы включает в себя создание концепции булочки, разработку ее рецепта, ее потребление, сервировку, и утилизацию. А здесь мы рассматриваем только ее приготовление по рецепту. Кстати, покажи мне на этой диаграмме различие между PDM и PLM”. “Ага, ну давай попробую. Надо для объектов указать атрибуты. Объекты здесь ингредиенты, тесто и булочка. И инструменты тоже объекты”, - Саша взяла в руки маркер и дорисовала диаграмму.

“Это то, что хранится в PDM системе, данные по продукту. Это справочные данные, шапка таблицы. Конкретные значения состава, температурного режима, сроков хранения будут проектными данными”. “Будь осторожна, тут надо быть аккуратной, где там справочные, где проектные. Проектные - это те данные, которые появляются в данном проекте в результате работ. Я бы поделил по-другому, но не будем останавливаться на этом”.

“А если к этим данным еще добавить данные по инструментам, инфраструктуре проекта, то будет PLM. В ней будут храниться данные всего жизненного цикла, а не только данные по продукту”. “Основы ты поняла, это очень хорошо. Теперь приступим к самой сложной штуке - научимся видеть в людях не только стейкхолдеров, но и оргзвенья”.

“Подожди, ты же говорил, что мы будем про архитектуру предприятия говорить, а пока это все тот же жизненный цикл”. “Вот к ней я и подхожу, к тому, что же такое архитектура предприятия. Там тебе будут и котики и все остальное, но вначале надо понять, что такое оргзвено, сервис, обязательства и оргспособность”. “Короли и капуста”, - опять вздохнула Саша и села слушать. “Итак, какие вещи есть в этом проекте, какая его онтология?” - спросил ее Борис. “Ингредиенты, тесто, булочка, рецепт, миксер, формы, обсыпка, печка, вытяжка”. “Так, начинаем исправлять ошибки. Разве рецепт - это вещь?” “Конечно, вот он лежит распечатанный на столе, чем это не вещь?” “Нет, рецепт - это описание вещи. Рецепт описывает ингредиенты, тесто, булочку. Это не вещь, не индивид, он не в 4Д. Теперь поговорим про ингредиенты, тесто и булочку. Я согласен, что это разные вещи, но нельзя ли их объединить в одну?” “Как это их объединить в одну? - ехидно спросила Саша. - Ты что, муку от готовой булочки не отличаешь?” В ответ Борис полез в телефон и показал Саше картинку: “Что это?” “Это зигота, похоже, что человеческая”, - Саша любила биологию. “Вот теперь скажи мне, если бы это была зигота, из которой выросла ты, то мог бы я сказать, что это и есть ты? Что это одна и та же вещь, объект?” Саша задумалась: “Вопрос философский. Когда человек становится человеком?” “Да, а когда завод становится заводом? Вот когда бетонные плиты производятся на панельном комбинате это часть завода или еще нет?” “И какой ответ правильный?” “Дело не в правильности, дело исключительно в удобстве и компактности получающихся моделей. Проще считать, что зигота - это уже человек, проще считать, что мука и яйца - это уже булочка. Просто такая стадия жизненного цикла. Ведь мы смотрим на гусеницу и понимаем, что из нее вырастет бабочка. Это и есть тот самый критерий непрерывности 4Д экстента. Если мы понимаем, что вот есть зигота и она непрерывно существует в пространстве-времени и вырастает в девушку, то значит зигота и девушка есть один объект”. “То есть ты хочешь сказать, что в каждой стадии жизненного цикла система является одновременно вещью-как-целым объектом, так и вещью-стадией-всего-объекта?” “Да, системные инженеры видят одновременно несколько объектов в одной вещи. Например, эта чашка может быть емкостью для воды, может быть производственным инвентарем, может быть единицей транспортировки, может быть единицей финучета, в зависимости от того, из какой стейкхолдерской позиции я на нее посмотрю, я буду в ней видеть разные объекты и буду делать с этой чашкой разные штуки. Могу перевозить, могу учитывать, могу очищать от примесей”. “А-а-а. То есть, предмет один, но он может попасть под множество классификаторов, в зависимости от твоих знаний? От онтологической позиции?” “Да, нас же не интересует некая истинная природа этой чашки, то ,чем она является на самом деле. Интересует только то, что мы хотим с ней сделать все вместе, всей командой, для чего она нужна и как мы ее используем в своей работе. Прагматизм”. “Так, теперь я кажется поняла. Нет, опять не поняла, еще больше запуталась. Ты говоришь, что я-как-зигота и я-как-девушка есть два разных объекта и в то же время есть один индивид, так как занимаю один и тот же пространственно-временной экстент. А мы сейчас говорили про классы, а классы ведь абстрактные? Или что?” “Вот есть моя рука. Моя рука - это отдельная вещь?” “Да, рука - это отдельная вещь”, - согласилась Саша с неоспоримым фактом. “Но рука-то и есть я?” - не сдавался Борис. “Да, рука - это ты”, - пришлось опять согласиться ей. “Я и рука находимся в отношении часть-целое. Моя рука - это физическая часть меня”. “Так, тут я еще понимаю”. “А теперь представь меня как такого темпорального червяка, который простирается сквозь пространство и время. Ну вот как на фотографиях с большой выдержкой показывают шоссе с автомобилями и виден длинный след его фар и габаритных огней”. “Представила тебя в виде твоего червяка”. “Вот часть этого червяка - это часть меня? Я, в момент вот этого разговора сейчас с тобой - это часть меня-как-экстента?” “Да, определенно, если смотреть на мир так, как ты предлагаешь, это правда”. “А чем отличается рука как моя физическая часть от меня-как-разговаривающего-с-тобой как моей темпоральной части меня-как-4Д-индивида? Вот с точки зрения логики?” “Какая-то метафизика, не понимаю, зачем это надо”. “Это надо затем, что либо ты будешь вручную разбираться с каждой управленческой ситуацией и принимать решение на чуйке или опыте или сможешь формально описать логику, чтобы другие люди могли принимать решения, похожие на твои. А лучше даже не люди, а компьютеры. Но если ты хочешь принимать все 15 миллионов решений самостоятельно, то вперед”. “Сколько?” “А ты думала. В среднем проекте принимаются миллионы и десятки миллионов решений. Чем лучше продумана логика проекта, тем эти решения согласованнее и меньше противоречат друг другу”. “Хорошо, ты получил мое внимание, рассказывай дальше”. “Вернемся к моему исходному вопросу - можно ли объединить ингредиенты, тесто и испеченную булочку в один объект, есть ли какой-то индивид, который объединяет все эти вещи?” “В твоей логике, которая мне кажется странной, это все один индивид - булочка. И у этой булочки есть темпоральные части, стадии - стадия ингредиентов, стадия теста, стадия отформованного теста, стадия испеченной булочки”. “Что тебя смущает?” “Ты говоришь, что системная инженерия прагматична, но я все равно не понимаю, зачем нужно так извращаться и вводить все эти стадии, экстенты. Какой толк от этого?” “Вот смотри. Есть зигота, есть эмбрион, есть рождающийся ребенок, есть новорожденный, есть младенец, есть дошкольник, есть школьник, есть подросток, есть девушка, есть престарелая женщина, есть старуха. Чтобы они успешно жили и развивались, им как - одни и те же специалисты нужны или все-таки разные?” “Разные, конечно, совсем-совсем разные”. “Вот теперь представь, что мы пытаемся спланировать, какие специалист нам нужны и как они должны совместно работать, чтобы вырастить полезного для общества, счастливого и востребованного человека. И у нас есть зигота, ребенок, взрослый, старик. Они вообще друг на друга не похожи, ты понять не сможешь один это человек или нет. А данные-то как ты будешь собирать о нем? Вот у тебя есть генетики, есть акушеры, есть педиатры, есть учителя, есть специалисты, есть менеджеры. У всех на этого человека разные данные в разных ИТ-системах. Разные планы, разные отчеты. Как им собрать все вместе? Как скоординировать свои действия? Ты же по их системам будешь проходить вообще под разными идентификаторами, именами, все будет разное. Есть только один способ - это указать на индивид в реальности. Т.е., мы говорим, что вот зигота и девушка есть один объект, непрерывно существующий в пространстве и времени. И вот все данные и план, которые есть у разных стейкхолдеров в разных стадиях жизненного цикла все относятся к этому индивиду. И тогда все данные разных стейкхолдеров можно объединить. Но нас даже не объединение данных волнует, а координация действий. Если все одинаково понимают объект приложения своих сил, понимают, по поводу чего они сейчас договариваются, то всякие расхождения в терминах, неточности и прочие искажения в коммуникации решаются намного проще. Вот он тебе, прагматический аспект”. “То есть. ты хочешь сказать, что мука - это темпоральная часть булочки?” “Вот представь, что я у тебя уберу муку, когда ты хочешь приготовить тесто. У тебя получится испечь булочку?” “Нет”. “Ну и что тебя смущает тогда в выражении мука является (темпоральной) частью булочки. Чем темпоральная часть отличается от физической, с точки зрения логики?” “Необычно просто. Не соответствует реальности”. “Откуда ты знаешь, какая она, эта реальность? Вот есть в реальности нейтроны, протоны, бактерии и вирусы? Или черные дыры?” “Конечно есть, они же объективно доступны для наблюдения?” “Да правда что ли? Это все просто такие модели, которые объясняют факты мира и позволяют прогнозировать результат действий. Вот сказали, что пусть будет протон, и тогда мы можем объяснить вот такой-то набор фактов. Ну да, модель протона объясняет этот набор фактов сейчас, но кто сказал, что не откроется такие факты, которые опрокинут модель протона? В истории науки такое происходит постоянно. Как шутил мой преподаватель - все знания вероятны, но это неточно. Можешь на досуге почитать про фальсифицируемость научных теорий и критерий Поппера”. “Ладно, товарищ Поппер, что ты там говорил про оргзвенья?” “Я лучше картинку нарисую”, - сказал Борис и нарисовал.


“В стадии Ингредиентов у нас есть три вещи - ингредиенты, та часть инфраструктуры, связанная с их подготовкой, и есть стейкхолдер замешиватель”.

“Потом у нас есть стадия теста, где появляется стейкхолдер лепильщик. И стадия формованного теста, где появляется хлебопек”.

“Чем хороша такая модель планирования и координации совместной деятельности? Вот как ты думаешь?” “Я вообще не вижу, в чем ее отличие от обычного плана”. “Тем не менее, эти отличия есть. Во-первых, здесь только индивиды, нет классов. Чем это хорошо?” “Не перепутаешь, потому что можно ткнуть пальцем”. “Да. Обычная проблема регламентов, планов и прочих документов координации в том, что их можно прочесть различными способами в разных ситуациях либо даже в одной, но с разных позиций. Как только мы указываем индивиды, либо так строим модель, что она однозначно вычисляется в конкретной ситуации и может быть интерпретирована только одним способом, мы резко улучшаем координацию. Плюс, если модель строго логична, ее можно автоматизировать и вообще не думать о том, как ее применить в конкретной ситуации, за нас это сделает компьютер. В этом суть PLM систем. Какой второй плюс, не менее важный?” “Не знаю, говори”. “Второй плюс в том, что модель не привязана к конкретным людям, которые будут исполнять эту работу в конкретный момент времени. Системный инженер не занимается оперативным менеджментом, это обязанность руководителя проекта. Поэтому модели системной инженерии не должны быть привязаны к исполнителям, иначе нам придется переделывать всю документацию и модели каждый раз, когда меняется оперативная обстановка, а она меняется очень часто. Наши модели быстро разойдутся с реальностью и станут бесполезными. Поэтому системные инженеры работают в основном в классах, а не в индивидах, но наши модели должны точно и однозначно привязываться к реальности и к конкретным индивидам”. “Потому что координация в отношении абстракций, классов очень сложна?” “Да, по большому счету она вообще невозможна. Вот есть, например, юристы, они работают по большей части с абстракциями, и поэтому есть поговорка, что где два юриста, там три мнения”. “Так, то есть системная инженерия - это метод связывания моделей различных дисциплин в единое логически непротиворечивое целое?” “Да, такая модель, состоящая из множества других моделей, называется мультимоделью. Например, про модель BIM так и говорят, что в ней есть дисциплины архитектуры, инженерных коммуникаций, дизайнерские и разные другие. Это хороший и понятный пример мультимодели, чистой воды системная инженерия в стройке”. “Хорошо, понятно более-менее. А как стейкхолдеры из системной инженерии связаны с исполнителями работ в проектном управлении?” “Вот тут мы и подобрались к понятию оргзвена”. “Наконец-то, а то я думала, что опять за полночь будем сидеть”. “Вот посмотри на работу пекарни как на черный ящик, который оказывает какой-то сервис. Что бы ты тогда добавила в эту модель, чего в ней не хватает?”

“Это просто, пекарня оказывает сервис выпекания булочек”. “Да, но чего не хватает в нашей модели, чтобы описать такой сервис? Какое понятие связано с сервисом? Вот прямо есть устойчивое выражение, что это обозначить?” “Уровень сервиса”. “Уровень сервиса, верно. Как бы ты его определила, в чем?” “В количестве и качестве булочек. Даже в количестве булочек за смену”. “Да, понятие сервиса напрямую связано с понятием обязательств. Эти обязательства обычно фиксируются в контракте, договоре об оказании услуг либо соглашении об уровне сервиса, SLA. Теперь внимание вопрос - а кто дает эти обязательства?” “Люди”. “Какие люди? Любой человек с улицы?” “Стейкхолдеры, в твоей терминологии”. “Подожди, вот есть стейкхолдеры замешиватель, лепильщик и хлебопек. Кто из них дает обязательство по исполнению уровня сервиса?” “Мы забыли еще одного стейкхолдера - менеджера, который всеми ими управляет. Вот он и дает обязательства, это его обязанность”. “Какую практику исполняет стейкхолдер менеджер?” “Практику управления пекарней”. “А другие стейкхолдеры, получается, не несут обязательств?” “Нет, они наемные работники”. “То есть получается, что есть два типа стейкхолдеров - исполнители без ответственности и менеджеры с ответственностью и обязательствами?” “И полномочиями еще, без полномочий обязательств брать нельзя”. “Так, а теперь представим ситуацию, когда ты работаешь в пекарне одна. Ты закупаешь ингредиенты, месишь тесто, печешь и продаешь. Ты исполняешь все роли стейкхолдеров и еще несешь обязательства. Может такое быть?” “Может”. “Как твоя модель это объясняет?” “Ну, сейчас не могу придумать, сложно”. “Во! Сложно. Как только ты начинаешь для объектов одного типа, в данном случае стейкхолдеров, вводить вычисляемые свойства - у тебя есть менеджеры, которые несут ответственность и исполнители, которые не несут ответственности, у тебя усложняется вся логика, планы становятся запутанными и непонятными и проект выходит из-под контроля. Какой выход?” “Какой?” “Ввести еще один объект - оргзвено. Стейкхолдер обозначает исполнителя практики, ответственность за действия, за исполнение, в английском языке это responsibility, responsible. И вводится понятие оргзвена, ответственность за результат, за уровень сервиса, за исполнение обещанного, за количество и качество булочек. В английском языке accountability, accountable, а само оргзвено на английском будет business actor”. “И получается, что если функция организации показывается практикой, то структура может быть представлена как стейкхолдерами, так и оргзвеньями?” “Да, все верно. Чаще оргзвеньями, но часто приходится описывать структуру организации, показывая взаимодействие стейкхолдеров”. “Тогда я не понимаю, зачем нужно заводить две сущности”. “Ну как. Если говорить про про железки, то конечно достаточно иметь одну сущность для моделирования функции и одну для моделирования формы, структуры. Но у люди, в отличие от железок могут нести ответственность, и поэтому нужно показать как саму структуру, которая исполняет функцию, стейкхолдера, так и структуру, которая несет ответственность”. “Т.е., оргзвено - это стейкхолдер с ответственностью? Чем это отличается от моей конструкции?” “Давай я тебе приведу три конкретных примера оргзвена - конструкторский отдел, завод по производству композитов, исполнительный комитет. Чем, по-твоему, они отличаются от стейкхолдеров?” “У них есть инструменты, активы”. “Правильно подметила”.

“Есть оргзвено А, которое состоит из стейкхолдера замешивателя и инфраструктуры замешивания, оно отвечает за то, чтобы из ингредиентов получилось тесто. Это его внутренний сервис, который оргзвено А оказывает смежникам - оргзвену Б, отвечающим за лепку из теста сформованных булочек. А все вместе они образуют оргзвено Г, которое оказывает весь сервис выпекания булочек”. “То есть оргзвено Г, которое включает в себя все остальные оргзвенья и отвечает за исполнение согласованного уровня сервиса?” “Да, именно так. Допустим, есть модель Хабермааса с тремя мирами - объективным миром, субъективным миром и социальным миром. Так вот, системные модели тоже касаются объективного мира, это модели, описывающие работу железа, софта, здания, линейные объекты. Это модели, описывающие субъективный мир - модели стейкхолдеров. И это модели, описывающие социальный мир - модели оргзвеньев”.

“И системный инженер работает в основном над тем, чтобы те изменения объективного мира, которые мы делаем в своем проекте, отвечали субъективным критериям успешности, главное для нас удовлетворение потребностей стейкхолдеров. А вот руководители проектов нацелены на то, чтобы изменения объективного мира максимально отвечали договоренностям, обязательствам, то есть для них главное справедливость.” “Интересная схема”. “Да, она многое объясняет и хорошо соответствует принципу кооперации Грайса. Делай свой вклад в разговор таким, какого требует данный момент именно в той ситуации, когда идет разговор, с той целью и в том направлении, куда идет разговор, в который ты вовлечён.
В этом принципе есть четыре максимы, достижение которых способствует полному соблюдению принципа:
Максима качества информации:
- Не говори того, что считаешь ложным;
- Не говори того, в чем сомневаешься, для доказательства чего нет исчерпывающих аргументов
Максима количества информации:
- Изложи не меньше информации, чем требуется;
- Изложи не больше информации, чем требуется
Максима релевантности:
- Не отходи от темы
Максима ясности:
- Будь последовательным:
- Избегай неясности;
- Избегай двусмысленности;
- Будь краток;
- Будь систематичен”.
“Хорошо, но если вернуться к сервисам. Я ведь не могу соблюдать уровень сервиса, исполнять обязательства в любых условиях, должны же быть ограничения”. “Да, точно так же, как практики связаны между собой информационными объектами, которые они передают друг-другу, организационные звенья связаны между собой интерфейсами, оргинтерфейсами. Это точки в пространстве-времени, в которых оргзвенья исполняют свои обязательства по сервису. Примеры оргинтерфейсов - окно выдачи заказов МакДональдс, комната, в которой проводится тренинг, интернет-банк, через который выплачивается зарплата. В общем, любое такое место, в котором можно проверить факт исполнения обязательств, исполнение договоренностей”. “Хм, получается, что переговоры - это согласование уровня сервиса и оргинтерфейса?” “В целом да. Есть содержательное общение, между стейкхолдерами договаривающихся оргзвеньев и есть переговоры, между начальниками оргзвеньев”. “А, так я была права насчет стейкхолдера-менеджера!” “В каком-то роде, но стейкхолдер отражает субъективный аспект коммуникации и организации, а начальник социальный аспект. Стейкхолдер должен быть правдивым, а начальник справедливым”. “То есть начальник может врать и это ок?” “Начальник как представитель оргзвена вообще не может врать, врать может стейкхолдер, подумай над этим в свободное время”. “Подожди, а как тогда совмещается между собой это стейкхолдерское представление организации и оргзвенья?” “Очень просто. Есть практики, которые исполняют стейкхолдеры. Эти практики обмениваются информационными объектами, и вот эти информационные объекты как раз и передаются через оргинтерфейсы между оргзвеньями согласно уровню сервиса. - Он увидел непонимание в глазах Саши и развернул пример. - Вот есть дядя Вася, это личность, у него есть 4Д экстент. Дядя Вася работает экскаваторщиком, это стейкхолдер, часть 4Д экстента дяди Васи. Приходит к дяде Васе бригадир дядя Гена, который тоже личность и 4Д экстент, но тут он не стейкхолдер, а оргзвено, представляющее бригаду строителей фундамента. И как оргзвено бригада запрашивает у оргзвена экскаваторщик на экскаваторе сервис по выкапыванию канавы. Дядя Вася начинает уточнять глубину, ширину канавы, есть или нет коммуникации, которые нельзя задеть при выкапывании. Это он как стейкхолдер экскаваторщик осуществляет планирование своей деятельности. Думает дядя Вася без экскаватора, ему он не нужен, модель работы экскаватора есть у него в голове в виде концептов. У кого дядя Вася как стейкхолдер экскаваторщик уточняет эти детали? У дяди Гены как управляющего стройплощадкой, у стейкхолдера, не у бригадира как оргзвена. Получается, что есть две практики - экскаваторных работ и организации стройработ обмениваются информационными объектами параметры канавы и препятствия. Эти практики воплощены индивидами стейкхолдеров ,а информационные объекты воплощены конкретной канавой, конкретными трубами и кабелями, которые лежат в конкретных местах на стройплощадке. Но вот знания про них лежат в виде классов в голове дяди Васи и дяди Гены и применимы к любой стройплощадке, куда бы они не пришли работать”. “Так, пока я отслеживаю”. “И когда дядя Вася уточняет у дяди Гены, он надеется, что во-первых, факты будут правдивы, а дядя Гена будет честен, не захочет его подставить и наказать за то, что дядя Вася пришел сегодня на стройплощадку выпивши. И чтобы убедиться в этом, он как оргзвено экскаваторщик с экскаватором ведет переговоры с оргзвеном бригадир, что мол выкопает он канаву к обеду, но за это дядя Гена обязуется не писать докладную начальству и ничего не говорить ему. Смотри, сервис копания оргзвено экскаваторщик на экскаваторе оказывает на границе ковша с землей, а исполнение договоренностей проверяется при личном общении дяди Гены и дяди Васи. Теперь вопрос - ты видишь дядю Васю или дядю Гену?” “Нет”. “А если вместо дяди Гены или дяди Васи будет тетя Люба и тетя Валя, что-нибудь в моих построениях изменится? А если стройплощадка будет в Саранске или под Нюрнбергом? Нет, ничего не меняется, это переносимое между ситуациями знание, хотя оперативные планы в каждом конкретном случае будут принципиально разные. В этом сила системной инженерии - знание по тому как проектировать и строить систему сохраняется и переносится между проектами”. “Хорошо, вроде бы разобрались чем системный инженер отличается от руководителя проекта, здесь неясности намного меньше стало. А чем занимается архитектор предприятия все еще непонятно”. “Вот смотри, есть оргзвено экскаваторщик на экскаваторе. Если ему топлива не привезти, сможет он работать?” “Нет, и если ты хочешь спрашивать дальше, то он еще не может работать без другой инфраструктуры типа планов коммуникаций, вешек, столовой, освещения стройплощадки и прочего”. “Да, оргзвено может оказывать согласованный уровень сервиса только как часть организации. Другими словами, организация - это и есть такой набор оргзвеньев с таким ресурсным обеспечением, которое позволяет выдерживать обязательства оргзвеньев друг перед другом и перед внешним клиентом. Организация позволяет один раз договориться кто какими ресурсами распоряжается и кто кому какие команды может отдать, чтобы не договариваться и не вступать в переговоры по любой работе, которую нужно выполнить. Все, ты теперь мастер оргдизайна”. “В смысле, это и есть архитектура предприятия?” “Да, вот 10 самых важных решений по тому, как устроена организация и будут архитектурой предприятия”. “Подожди, практический смысл всего этого какой?” “Самый главный практический смысл в том, чтобы понимать ты сейчас стейкхолдер или оргзвено? Ты практику исполняешь и тебе надо обращать внимание на информационные объекты практики либо ты оргзвено и тебе надо договариваться о сервисе и его уровне, об обязательствах. Переговоры ты сейчас ведешь или по существу общаешься”. “То есть, для управления проектом нужны все трое - и системный инженер, руководитель проекта и архитектор предприятия?” “В идеале да, системный инженер отвечает за то, чтобы изменения реального мира приводили к удовлетворению субъективного определения успеха стейкхолдеров, руководитель проекта отвечает за то, чтобы изменения реального мира производились в соответствии с договоренностями, ограничениями проекта, а архитектор предприятия отвечает за оптимальную организацию работ по этим изменениями”. “Подожди, ты говорил, что модель жизненного цикла системы описывает знания по проектированию, производству и эксплуатации системы. Может, модель архитектуры предприятия тоже какие-то знания описывает?” “Да, модель архитектуры предприятия описывает оптимальную организацию предприятия. Она показывает, как можно организовать работу, а как не стоит. Фактически, архитектура предприятия - это заделы, знания того, как организационно устроено хорошее предприятие”. “Получается, организация - это тоже такая вещь, индивид?” “Организация нет, организация - это абстракция. А вот индивидом, 4Д экстентом, который воплощает эту организацию, является дядя Вася как стейкхолдер экскаваторщик на экскаваторе, с его взаимодействии со снабженцами, инженерными службами и прочими частями организации, которые позволяют ему выкопать 30 метров канавы в день. Вот эта вещь называется организационной способностью, оргспособностью. Воплощение предприятия физически состоит из оргспособностей. Наиболее распространенный стандарт архитектуры предприятия TOGAF называет их capabilities, а модели capabilities называет architecture building block, строительные блоки архитектуры предприятия”. “Итак, правильно ли я поняла, что когда мы рассматриваем предприятие, то его функция показана в модели жизненного цикла, его форма показана в модели оргспособности?” “Да, все именно так. И модель архитектуры предприятия показывает только ключевые решения, а не все подряд. Архитектурные описания компактны и в этом их отличие от огромных моделей бизнес-процессов, ИТ-ландшафтов, запутанных органиграмм. Только ключевые решения, которые влияют на ключевые моменты деятельности”.



“Ты обещал котиков, папа. Или дядя Вася и был котиком? Тогда это был так себе котик”. “Хорошо, вот тебе котики. Когда мы с тобой ездили на праздники кататься на лыжах, ко мне позвонил магазин, который доставляет еду на кота. И они попросили уточнить, когда я могу принять заказ. Я ничего не заказывал, и ответил им, что они напутали и пусть отменяют, мы не в городе, принять ничего не можем. Когда мы вернулись, я понял, что котовые припасы подошли к концу. Я зашел на сайт и вошел в историю заказов, чтобы повторить свой последний заказ, как я это делаю обычно. Но кнопка Повторить_заказ исчезла, я не мог повторить заказ, привычный шаблон действий был сломан. Вместо этого можно было Создать_шаблон на основе прошло заказа. Ладно, делать нечего, я создал шаблон. Шаблон создался, я увидел корм и наполнитель, который обычно заказываю, но я не мог откорректировать количество, и мне обязательно надо было поставить периодичность повтора заказа от 1 до 12 недель. Другими словами, разработчики считают, что вне зависимости от количества животных, их размера, количества корма и наполнителя в упаковке, уходимость этого корма и наполнителя будет кратна емкости упаковки и неделям и будет неизменной. Это очевидно некорректное предположение, сенбернар и наш кот не могу потреблять в одном паттерне. К этому моменту вместо обычной минуты на сайте я провожу уже около 5, пытаясь создать заказ и переписываясь с оператором. Это очень важный момент, архитектурный, потому что заказ онлайн тем и хорош, что все происходит быстро и ни от чего не зависит. Сделав эту доработку, разработчики изменили архитектуру предприятия, и чуть было не потеряли лояльного клиента, который постоянно и много закупается. И я думаю, что я был не один такой недовольный клиент, потому что через пару дней доработку откатили, вернув старый способ размещения заказа через повтор и коррекцию количества. Правда, при этом остались некие шаблоны, которые не несут никакой полезной функции, потому что и раньше можно было поставить напоминание и автоповтор заказа безо всяких шаблонов”.
“Ну хорошо, а чем бы им помогла модель архитектуры предприятия? Вот она была бы и что?” “Тут начинается самое интересное. Я сделал реверс-инжиниринг архитектуры предприятия этого Интернет-магазина и вот что у меня получилось”.


“Ошибка №1. Есть два оргзвена - сеть магазинов товаров для питомцев и клиент. Между ними есть оргинтерфейс, который описывается соглашением об оказании услуг. Этот оргинтерфейс изменился, условия поставки стали другими, но меня никто не оповестил”. “Ну, это можно было бы сделать и без модели архитектуры”. “Я уже говорил, что вся системная инженерия - это концентрированный здравый смысл. Ничего удивительного ты не услышишь, все будет очевидно, но что интересно самые большие ошибки обычно как раз из разряда тупняка. Все потом удивляются как это они допустили такую глупую ошибку. Ошибка №2. Закрыли возможность разместить заказ привычным способом. Я не думаю, что был единственным клиентом, кто смотрел последний заказ, корректировал количество и повторял его”. “Т.е., ты хочешь сказать, что они глупую ошибку и модель архитектуры предприятия позволила бы не делать эту доработку?” “Дело не в этом. Смотри, я же делал реверс-инжиниринг, и восстановил логику, почему они вообще задумались о таком проекте. Ясно, что корм для животных штука очень дорогая в доставке, думаю, что около 30, а то и 40% себестоимости заказа является логистика последней мили. Поэтому желание улучшить экономические показатели этой практики понятно, если заранее составлять и выдерживать график поставки, то можно сильно снизить стоимость этой доставки и зарабатывать больше. Другое дело, что сама идея прогнозировать потребление на уровне отдельных животных глупая, потому что паттерн потребления отдельных животных предсказать нельзя. Поэтому что надо было сделать?” “Прогнозировать спрос на многих животных? Чтобы работала статистика?” “Да, а как это сделать?” “Прогнозировать потребление на уровне района и составлять графики доставки в район”. “Бинго, к этой схеме они в конце концов и пришли, а я получил еще одного клиента, которого я консультирую”. “Ладно, звезда предпринимательства, кончай хвастаться. Про архитектуру предприятия я поняла, что мне делать с моей проблемой?” “Провести внедрение и сделать поставку продукта пользователям мало, этот продукт должен привести в появлению новой или изменению текущей оргспособности. На это требуется время, вот его я тебе и дам. Держи мою записку освобождения от школы и у тебя 48 часов на то, чтобы научиться рисовать этим монстром”. Борис оделся, взял рюкзак и вышел из дома. Саша пошла к себе в комнату тренироваться.


Эпилог.
Саша стояла у дверей лепрозория, рядом с ней стоял Зурзмансор. Здесь было холодно, вместо дождя шел снег, но мокрецы засыпали все солью, и под ногами была жидкая каша, а воздух был сырой и промозглый, несмотря на смешные минус 5. "Значит еще тридцать лет осталось? - переспросил Борис. - Значит, есть еще время, время есть".

Заключение.
Мир и работа становятся все сложнее. Системная инженерия и системное мышление - единственный инструмент, надежно помогающий справиться с этой сложностью. Затраты на его освоение по моему мнению хорошая инвестиция в будущее. Разным людям подходят разные методы изучения, ниже я даю ссылки на стандарты, курсы и тренинги.

Международные стандарты
ISO15288 Systems and software engineering - System life cycle processes
ANSI/EIA-632 Processes for engineering a system
ISO 26702 Systems engineering - application and management of the systems engineering process
SEBok Guide to the systems engineering body of knowledge
ISO TR 24748 Systems and software engineering - Life cycle management - Part 1 and 2
ISO 24765 Systems and software engineering - Vocabulary
ISO 29148 Software and systems engineering - Life cycle processes - Requirements engineering 
ISO 42010 Systems and software engineering - Architecture description
ISO 10303-233 - Industrial automation systems and integration - Product data representation and exchange - Part 233: Application protocol: Systems engineering
CMMI-DEV v.1.3 Capability maturity model for development
ISO 15504-6 Information technology - Process assessment - Part 6: An examplar systems life cycle process assessment model
ISO 15289 Systems and software engineering -- Content of life-cycle information items (documentation)
ISO 15939 Systems and software engineering -- Measurement process
ISO 16085 Systems and software engineering -- Life cycle processes -- Risk management
ISO 16326 Systems and software engineering -- Life cycle processes -- Project management
ISO 24748-4 Systems and software engineering -- Life cycle management -- Part 4: Systems engineering planning
ANSI/AIAA G-043A-2012e Guide To The Preparation Of Operational Concept Documents
ISO 15026 Systems and software engineering -- Systems and software assurance -- Part 2: Assurance case

Национальные стандарты
ГОСТ Р 56713-2015 Системная и программная инженерия. Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация)
ГОСТ Р 56920-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
ГОСТ Р 56921-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования
ГОСТ Р 56922-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования
ГОСТ Р 56923-2016 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры
ГОСТ Р 57102-2016 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288
ГОСТ Р 57193-2016 Системная и программная инженерия. Процессы жизненного цикла систем
ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 25001-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление
ГОСТ Р ИСО/МЭК 25040-2014 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости
ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию
ГОСТ Р ИСО/МЭК 26555-2016 Системная и программная инженерия. Инструменты и методы технического менеджмента линейки продуктов
ГОСТ Р ИСО/МЭК 29155-1-2016 Системная и программная инженерия. Структура сопоставительного анализа эффективности выполнения проектов информационных технологий. Часть 1. Понятия и определения

Курсы:
https://www.coursera.org/learn/system-thinking
http://system-school.ru/engineering

Ролики:





Тренинги и симуляции:
1. Бизнес-моделирование “с нуля”. Для сотрудников бизнес-подразделений и руководителей. Решает проблему четкой и однозначной коммуникации в сложных и запутанных ситуациях. Участники учатся четко и точно формулировать свои мысли, предложения и планы с помощью простых моделей, проверять свои и чужие модели на корректность понимания, проверять факты и правильность выводов.
2. От стратегии к панели показателей. Для руководителей. Решает проблему измерения продвижения к стратегическим целям. Участники учатся переводить размытые и нечеткие критерии успеха “удовлетворенность клиентов”, ”качество продукции”, “удовлетворенность рабочим местом” в измеримые экономически осмысленные показатели и отказаться от оценки работы и принимаемых решений в баллах и процентах.
3. От стратегии к портфелю продуктов. Для руководителей и специалистов. Решает проблему четкого формулирования стратегии в привязке к конкретной рыночной ситуации и преобразованию стратегии в набор проектов, продуктов и сервисов. Участники учатся формулировать и непрерывно уточнять стратегию компании с учетом актуальной рыночной обстановки и формировать продуктовый и проектный портфель, который реализует эту стратегию.
4. Актуальная документация по проекту. Для руководителей и технических специалистов. Решает проблему точной и актуальной технической документации по продукции. Участники учатся основам управления технической и инженерной документации и процессам ее актуализации (управление конфигурацией и изменениями в проектах).
5. Передача дел от ответственных работников. Для руководителей. Решает проблему выявления и точной передачи самых важных знаний от ключевых работников. Участники учатся выявлять самые важные знания, ключевые решения и правила принятия этих решений при сдаче-приемке должностных обязанностей. Возможно обучение методам компактной записи этих знаний с помощью современных инструментов.
6. Расстановка приоритетов задач и проектов. Для руководителей и технических специалистов. Решает проблему экономически обоснованной и не вызывающей споров в коллективе расстановки приоритетов задач в многопроектной среде с частичной занятостью людей на проектах. Участники учатся качественно формулировать проектные и технические требования в проектах, составлять очереди разработки и расставлять приоритеты проектных задач и ИТ-доработок.

Проектная симуляция "Системная интеграция и поставка".
Для руководителей и технических специалистов. Решает проблему организации проектных коммуникаций и поддержания актуальности и порядка проектной документации. Участники на практике получают основные знания и навыки по управлению жизненным циклом и управлению конфигурацией продуктов.
В игре участвуют 5 команд заказчика и организаторы. 3 команды поставляют сборочные узлы и модули команде интеграторов продукта, которые должны правильно распределить работы между командами, собрать итоговый продукт и сдать его заказчику. Одна команда служит складом и поставщиком всех комплектующих.
В этой симуляции за 3 дня вы увидите все слабые места вашей текущей схемы коммуникации в проектах и поймете где и как их можно значительно улучшить. Организаторы также дают рекомендации по приобретению PLM и PDM систем, а также СЭД.

За подробностями обращайтесь по телефону +7(925)673-44-84 или alex.turkhanov@gmail.com, Александр Турханов.