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

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

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

---

Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой – относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно – (СХ6) техобслуживание.

Требования к целевой системе мы можем теперь разделить на 4 группы:

– требования к управлению сервисами (Т2, Т3);

– требования к управлению средой (Т1, Т4);

– требования к мониторингу среды;

– требования к мониторингу сервисов.

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

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

– идентификатор;

– короткое название;

– полное название;

– входные параеметры;

– выходные параметры;

– иные функциональные связи.

У начинающих системных аналитиков часто возникает вопрос: «А когда нужно прекращать декомпозировать? Сколько уровней должно быть?». Если спецификация функции занимает меньше A4, значит её уже не надо декомпозировать. Еще вариант – если по спецификации можно найти и купить соответствующий модуль.

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

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

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

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

Глава 4. Жизненный цикл системы и проекта

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

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

Рис. 8. Типовой жизненный цикл проекта

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

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

Рис. 9. Типовой вариант спирального жизненного цикла проекта

Вам могли показать другой вариант жизненного цикла, например как на рисунке 9. Спиральный жизненный цикл часто используют в индустрии программного обеспечения и информационных систем, даже чаще, чем это официально преподносится. Идея такого жизненного цикла предельно проста. Каждый виток – полный набор стадий от замысла до, иногда, продажи и сопровождения. Переход на новый виток выполняется в том случае, когда завершенный виток был успешен и есть благоприятный прогноз развития проекта. Обычно каждый новый виток значительно дороже предыдущего, разрабатываемый функционал шире, сама система сложнее. Вопрос в том, сколько должно быть приемок и валидаций в таком жизненном цикле?

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

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

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

Если не обговорить необходимость в таких крупных затратах «на берегу», что остается делать в середине проекта? Можно просто сделать «коробочку», а потом продавать её – сразу. Как вы думаете, если сделать новый двигатель, пропустить стадию испытаний на разных, например, автомобилях, и сразу выставить продукцию на продажу – будет ли проект успешен? Какие могут быть последствия от выбора такого жизненного цикла? Самое время обсудить проектные риски с руководством.