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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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