Системный инженер

Предисловие

«Время кулинарии. Сегодня мы с вами будем готовить гуся.

— Гусь, ты готов?

— Да.

Гусь готов, друзья. Приятного аппетита!» (анекдот про стейкхолдеров)

Достаточно сложно определить на русском языке, что такое системная инженерия, уже только потому, что само понятие «инженерия» вобрало в себя со временем слишком много всего, не говоря уж об инжиниринге. Большую работу на тему определения и стандартизации системной инженерии на русском языке провел Виктор Константинович Батоврин, поэтому я не буду на этом останавливаться подробно. Отмечу лишь, что процесс пересмотра стандартов системной инженерии в профессиональных сообществах идет постоянно. Не так давно в Москве сформировалось Русское отделение международного совета системных инженеров INCOSE, где вопрос определения системной инженерии периодически обсуждался и продолжает обсуждаться по сей день. Наиболее простым и понятным определением, хотя и не академическим, я считаю для себя следующее, предложенное Анатолием Игоревичем Левенчуком:

«Системная инженерия — это инженерия с системным подходом в голове».

Под инженерией я, в свою очередь, буду понимать в этой книге любое спланированное изменение окружающего мира, результат которого может быть проверен на соответствие задуманному плану. Поскольку эмпирический научный метод Бэкона время от времени переживает очередную реинкарнацию, например в цикле Шухарта-Деминга (рис. 1), то мне ничего не остается, как сослаться на Бэкона и его предшественников (античных и, возможно, более ранних), пытающихся формализовать здравый смысл или, как чаще говорили в те времена, Божественный замысел. В итоге получим, что инженерия — это эмпирический научный подход к прикладным задачам. Теперь, внимание. Поскольку инженерия, сама по себе, тоже является прикладной задачей, то можно себе представить эмпирический научный подход к инженерии. Это и есть системная инженерия.

Системный подход — тема для отдельного собрания сочинений. Сейчас уже, как мне кажется, бесполезно говорить об истоках системного подхода, потому что уровень информационного шума вокруг этой темы слишком велик. Я, конечно, не откажу себе в удовольствии сослаться на работы Берталанфи и Холла, но надо понимать, что всё то же самое, только другими словами, существовало гораздо раньше. Все содержание этой книги, собственно, и будет посвящено конкретным примерам применения системного подхода к инженерии. Теоретическую базу системного подхода, или даже правильнее сказать — системных подходов, потому что у многих авторов он свой собственный, вы всегда сможете найти в многочисленной литературе. Системный подход, в самой прямой трактовке, без каких-либо лишних теоретизирований, означает следующее — работа с объектом как с системой. К сожалению, определений системы тоже очень много, и мне снова придется давать свою вольную трактовку — рекурсивное определение системы. Заранее предупреждаю, что программистам будет проще пережить следующий абзац.

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

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

Фактически, жизненный цикл системы — это расширенное четырехмерное (пространство и время) понимание системы, включающее в себя также и другие системы, которые обеспечивают «жизнь» первой.

Например, когда мы говорим о жизненном цикле моста, то обсуждаем конкретную деятельность, в том числе, работу проектно-строительных компаний, а не только сам мост.

Заинтересованные стороны (стейкхолдеры) — это роли, в которых окружающие систему люди воздействуют на систему, а система имеет воздействие на них хотя бы раз в течение всего жизненного цикла системы.

Весь системный подход, в современном его изложении, крутится вокруг стейкхолдеров и их интересов. На рисунке 2 приведена схема связи между определением и воплощением системы через стейкхолдеров.

Определенные выше понятия будут активно использоваться в дальнейшем изложении. Более подробное описание этих понятий, но на английском языке, вы можете найти в своде знаний по системной инженерии (SEBoK). Если эта книга у вас пойдет тяжело, рекомендую сначала разобраться с дисциплиной системного мышления, прекрасно изложенной в учебных курсах и материалах Анатолия Игоревича Левенчука.

Если говорить о близких к SEBoK русскоязычных учебниках, то их не так много. Академическое изложение предмета системной инженерии вы найдете в учебнике Александра Косякова и др. «Системная инженерия. Принципы и практика», переведенного с английского языка под редакцией Виктора Константиновича Батоврина. В МФТИ издано учебное пособие «Базовый курс системной инженерии», написанное Виктором Юрьевичем Николенко.

Что касается книги, которую вы читаете сейчас, то она никак не может быть названа учебником, однако представляет собой до боли актуальный кейс — пример использования системной инженерии в реальном проекте с множеством жизненных ситуаций, о которых обычно нигде не пишут. Опыт преподавания системной инженерии в Уральском федеральном университете (УрФУ) показывает, что для уровня системно-инженерной магистратуры катастрофически не хватает сборников кейсов, шаблонов, примеров и т. д. и т. п. В этой книге я постарался собрать те частные методы описания (методики, техники, методы, фреймворки и др.), а также инструменты, которые я сам чаще всего использую в работе. Так проще объяснять мне, и так быстрее системная инженерия становится понятна моим студентам.

На практике чаще всего встречаются следующие системно-инженерные роли:

системный инженер — отвечает за весь жизненный цикл системы;

системный аналитик — отвечает за требования к системе;

системный архитектор — отвечает за системную архитектуру;

системный тестировщик — отвечает за тестирование системы;

системный администратор — отвечает за обслуживание системы.

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

Примерами систем могут быть: автомобиль, самолет, система документооборота, завод, смартфон, месторождение полезных ископаемых, клиника и т. д.

В этой книге мы уделим внимание ролям системного аналитика и системного архитектора, а предметную область выберем самую актуальную — Интернет вещей.

Часть 1. Тренировка на салфетках

Глава 1. Разделение зон ответственности

Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам, потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков — залатывать дыры.

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

Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).

В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.

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

Присутствие различных стейкхолдеров на совещании — это, действительно, очень хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.

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

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

Если двигатель внутреннего сгорания в автомобиле заменить на электрический двигатель, то менять надо практически всё. Поэтому системная архитектура часто представляется в виде структуры принципиальных решений, поскольку одни изменения тянут за собой другие.

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

Если вы решились взять на себя роль системного инженера, придется помогать всем остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой таблички будет видно, какие роли в каких проектах представлены минимально. По иронии судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.

Ниже пример таблицы, которая может получиться в результате. Не надо пугаться, на практике в проектах, к сожалению, бывает по 3 менеджера, 5 архитекторов и 1 программист.

Не надо думать, что проблема в неправильном назначении ролей. Менеджер, вполне возможно, все правильно распределил. Проблема в том, что на деле сотрудники берут на себя совсем иные роли, чем было предусмотрено.

Когда менеджер проекта начинает на совещании предлагать системно-архитектурные решения, то он играет роль системного архитектора — не свою. Учитывая, что время ограничено, то, скорее всего, такой менеджер не успеет полностью отыграть свою роль, в результате чего сорвутся сроки.

Ниже приведена другая таблица распределения ролей. Если вам со временем удастся добиться такой организации команды, будет здорово.

Работа системного инженера начинается с упорядочения среды, в которую он попал. Чтобы сформировать целостное представление о системе, которую вам предстоит делать, надо, прежде всего, четко разделить зоны ответственности членов команды проекта. Это нужно сделать сначала в своей голове, а потом в действительности. Необходимо следить за тем, чтобы каждый член команды «играл» свою роль. Здесь вам потребуется деликатность и лидерство, а также поддержка руководства. По моему скромному опыту (и богатому опыту моих коллег), большинство срывов проектов связано именно с конфликтами на почве зон ответственности. Системный инженер, являясь посредником между менеджерами и различными специалистами, должен следить за тем, чтобы члены команды действовали в соответствии со своими ролями, но делать это так, чтобы никого не обидеть и не разозлить.

Даже если вы предлагаете рациональные решения, кто-то обязательно будет «против», потому что затрагиваются его интересы. Кто-то из стейкхолдеров (среди которых всегда есть и члены команды проекта) имеет определенного рода интерес, чтобы всё было именно так «как есть». А еще именно этот стейкхолдер обычно старается сделать так, чтобы остальные не смогли увидеть ситуацию в целом. Это может касаться чьих-то скрытых доходов или того хуже.

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

Репутация системных инженеров складывается из успешных и провальных систем, которые были реализованы в результате их деятельности.

Если ваша система изначально не имеет шансов на успех из-за чьих-то интересов или их отсутствия, либо эти шансы очень малы… решать вам. Обеспечивать проект тоннами документации, в которой невозможно разобраться, — не самая привлекательная перспектива. Поэтому давайте сразу договоримся, что тут мы будем говорить именно про инженерные проекты, а не про бумажные.

Вот на совещание пришел заместитель директора по проектам и начал доказывать системному архитектору системы, что надо все переделать, потому что много инноватики. У компании, по мнению замдира, достаточно опыта, чтобы решать задачу проверенными классическими методами. Если вы обратитесь к нежданному гостю с вопросом: «А какая твоя роль в проекте?», — он может быть фраппирован. Вся команда должна понимать, что человеку иногда надо выговориться. Возможно, имеет смысл искать полезную политическую информацию между строк. Потом всегда можно составить протокол, зафиксировать предложение и обосновать на бумаге отказ с подписью технического директора, например. К сожалению, такое бывает. Да, на это приходится тратить время.

Вы заметили, что представители заказчика не интересуются вашим проектом: не звонят, не ругаются? Это верный признак того, что им этот проект не нужен.

Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным специалистам. Хорошо организованная команда молодых специалистов может даже из такого «заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят проблему, постарайтесь разглядеть возможность.

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

Разделяйте зоны ответственности команды проекта и зоны интересов стейкхолдеров, чтобы понимать, какая реальная задача перед вами стоит, и сколько ресурсов вы реально можете в нее вложить.

Глава 2. Потребности и требования

Предположим, ваш срок «устаканивания» в компании прошел за 3 месяца, и теперь вам доверили поучаствовать во вполне себе реальном проекте. Ваша компания решила сделать новый продукт — умный дом, а вам предложили поучаствовать в этом проекте в качестве системного аналитика.

Для начала вопрос — что должен делать системный аналитик? Что является результатом его работы? Не факт, что вам кто-то будет объяснять, что, собственно, от вас требуется. И не факт, что обязанности системного аналитика в предыдущих «учебных» проектах будут как-то коррелировать с новыми обязанностями в реальном проекте, где на кону — деньги и репутация компании. Я бы на вашем месте не задавал никому подобных вопросов, а начал тщательно разбираться со стейкхолдерами, их потребностями и требованиями.

Потребности и требования — принципиально разные понятия. Сначала, надо разобраться, какие стейкхолдеры есть у системы с рабочим названием умный дом. Нас пока даже не должно интересовать, что это такое — умный дом. Вопрос исключительно в стейкхолдерах.

Называть стейкхолдеров нужно в честь их роли относительно целевой системы.

Не путайте с ролью в проекте, должностью, названием организации, ФИО и чем-угодно другим. Роль относительно целевой системы должна быть однозначно интерпретируемой, подразумевая конкретный интерес. Например, стейкхолдером может быть: инвестор, заказчик, пользователь, сервисный инженер, но не может быть: Константин Константинович, ООО «яКомпания», начальник отдела сбыта.

Самое главное — не путайте заказчика проекта и заказчика целевой системы.

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

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

Есть некий потенциальный собственник, который желает улучшить свой дом (пока не понятно, какой дом) — имеем определенного рода спрос. Ваша ИТ-компания желает выйти на этот новый рынок, поэтому готова вложиться в разработку. У компании есть партнеры, которые могут поставлять комплектующие. Есть программисты, готовые реализовать алгоритмы поведения системы. Есть необходимые специалисты для сборки, монтажа и обслуживания системы. Имеется также коммерческая структура, способная обеспечить продажи системы. В этом контексте главным источником информации о потребителе будет стейкхолдер-продавец (СХ7), но забывать об остальных стейкхолдерах категорически нельзя.

Рассматриваемая ситуация может показаться очевидной, но могла быть другая. Заказчиком умного дома и проекта в одном лице мог быть вполне конкретный человек (например, автоматизация конкретного дома под заказ). Тогда не нужно было бы делать предпродажную работу, исследовать рынок. Жизненные циклы таких двух проектов существенно отличаются.

Начинается первая и самая непредсказуемая часть разработки — определение границ системы. Вам надо дать системе название.

В системной инженерии принято называть систему по основной функции, которую она выполняет.

Как известно, система выполняет функции на стадии эксплуатации. Какую главную функцию выполняет умный дом?

Очень часто проекты называют беспредметно и абстрактно. Часто приходится слышать такие названия проектов как «Система управления сервисами платформы того-то» или «Сервис управления системами сего-то». Чаще всего целью проекта является разработка какого-нибудь маленького модуля, а в названии пишут чуть ли не «Разработка системы управления миром».

Система, которую заказал директор, совсем не дом. Насчет «ума» у меня тоже есть сомнения. Речь идет, скорее всего, о датчиках, контроллерах, каких-то управляющих механизмах, проводах, компьютерах и ИТ-коммуникациях. Все это вместе в одной коробке — умный дом. На деле это автоматизированная система управления освещением, тепловым оборудованием, звуковым оборудованием или чем-то еще в этом роде. Вряд ли кто-то сможет сразу ответить нам на вопрос, чем эта система должна управлять. В такой ситуации я бы предложил начать с формулирования потребностей.

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

Я, как <стейкхолдер>, хочу <потребность>, потому что <проблема>.

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

Коммерческий отдел или отдел маркетинга вряд ли будет формулировать потребность именно в такой форме. Ваша задача, как системного инженера, привести к одной форме все потребности. Однако надо учесть, что коммерсанты могут перевернуть вам представление о проекте в один счет.

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

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

Потребность должна оставаться актуальной вне зависимости от целевой системы.

Пользователь хочет платить меньше независимо от существования умного дома. Требование актуально относительно целевой системы и ее элементов. Будем использовать следующую переходную конструкцию от потребности к требованию:

Я, как <стейкхолдер>, считаю, что система должна <требование>, чтобы <потребность>.

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

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

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

Итак, допустим, что в результате переговоров с коммерческим отделом и другими стейкхолдерами, вам удалось сформулировать следующие потребности (таблица 4). Очевидно, что контекст этих потребностей пока еще очень размыт. Тем не менее, не бойтесь делать различные описания системы. Со временем они будут становиться более строгими и конкретными.

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

систему верифицируют на соответствие требованиям (на проверочных испытаниях), а валидируют (например, на приемочных испытаниях или еще до них) систему на предмет удовлетворения потребностей.