Системный инженер. Как начать карьеру в новом технологическом укладе - Вячеслав Мизгулин

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

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

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

Таблица 4. Потребности стейкхолдеров системы с рабочим названием умный бизнес-центр

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

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

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

Остановимся на потребности (П1) – меньше платить за электричество и водоснабжение. Важной способностью системного инженера должно быть сценарное (или алгоритмическое) мышление. Можно выделить несколько основных видов мышления по времени приложения: рассуждения о настоящем времени; рассуждения о прошедшем времени; рассуждения о будущем времени. Думаете, это все? Можно еще рассуждать о прошлом из прошлого, о прошлом из будущего, о будущем из прошлого и т. д. Успешный системный инженер должен думать во всех временах с одинаковой изворотливостью и быстротой.

В прошлом, владелец бизнес-центра переплачивал за электричество и водоснабжение, потому что арендаторы неэкономно пользовались ресурсами. Арендная плата учитывала возможные переплаты, но сейчас настали тяжелые времена, поэтому необходима оптимизация расходов, иначе бизнес может стать убыточным. Если владелец бизнес-центра купит и внедрит целевую систему, то фактические затраты на электричество и водоснабжение сократятся, следовательно, при сохраненной арендной плате владелец сможет получать дополнительную прибыль с арендаторов. Первый вопрос заключается в сроке окупаемости целевой системы. Второй вопрос – какие конкретные функции должна выполнять система, чтобы сокращать затраты? Этот вопрос адресует нас напрямую к требованиям.

Таблица 5. Требования владельца и пользователя системы (СХ1) для потребности (П1)

Вариантов требований может быть очень много. Можно вспомнить про парковки, про влажность воздуха, про авторегулирование освещения и многое другое. Требования всегда имеет смысл ранжировать. Уровень важности того или иного требования может оценить каждый стейкхолдер. При этом, каждый стейкхолдер может быть «по секрету» взвешен, на предмет собственной важности. Снимать требования в зависимости от их низкого ранга «просто так», конечно, нельзя. Но так легче понять, какие требования можно вынести на обсуждение со стейкхолдерами, как необязательные. А уже потом – убрать.

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

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

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

Глава 3. Функциональное моделирование

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

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

Рис. 3. Контекстная функциональная модель системы управления потреблением электроэнергии и воды в бизнес-центре

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

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

Первый вариант, который мы рассмотрим, будет заключаться в укрупнении задачи. Давайте назовем функцией системы – поддержку комфорта в бизнес-центре (рис. 4). Таким ходом мы ставим себе задачу четкого определения термина «комфорт», вплоть до математической формулы. Для начала давайте декомпозируем комфорт, например, вот в такой кортеж:

Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>