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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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