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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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