Читать онлайн
Системный инженер. Как начать карьеру в новом технологическом укладе
Как начать карьеру в новом технологическом укладе
Вячеслав Мизгулин
© Вячеслав Мизгулин, 2017
ISBN 978-5-4485-4498-9
Создано в интеллектуальной издательской системе Ridero
Предисловие
«Время кулинарии. Сегодня мы с вами будем готовить гуся.
– Гусь, ты готов?
– Да.
Гусь готов, друзья. Приятного аппетита!» (анекдот про стейкхолдеров)
Достаточно сложно определить на русском языке, что такое системная инженерия, уже только потому, что само понятие «инженерия» вобрало в себя со временем слишком много всего, не говоря уж об инжиниринге. Большую работу на тему определения и стандартизации системной инженерии на русском языке провел Виктор Константинович Батоврин, поэтому я не буду на этом останавливаться подробно. Отмечу лишь, что процесс пересмотра стандартов системной инженерии в профессиональных сообществах идет постоянно. Не так давно в Москве сформировалось Русское отделение международного совета системных инженеров INCOSE, где вопрос определения системной инженерии периодически обсуждался и продолжает обсуждаться по сей день. Наиболее простым и понятным определением, хотя и не академическим, я считаю для себя следующее, предложенное Анатолием Игоревичем Левенчуком:
«Системная инженерия – это инженерия с системным подходом в голове».
Под инженерией я, в свою очередь, буду понимать в этой книге любое спланированное изменение окружающего мира, результат которого может быть проверен на соответствие задуманному плану. Поскольку эмпирический научный метод Бэкона время от времени переживает очередную реинкарнацию, например в цикле Шухарта-Деминга (рис. 1), то мне ничего не остается, как сослаться на Бэкона и его предшественников (античных и, возможно, более ранних), пытающихся формализовать здравый смысл или, как чаще говорили в те времена, Божественный замысел. В итоге получим, что инженерия – это эмпирический научный подход к прикладным задачам. Теперь, внимание. Поскольку инженерия, сама по себе, тоже является прикладной задачей, то можно себе представить эмпирический научный подход к инженерии. Это и есть системная инженерия.
Рис. 1. Обобщенная схема инженерной деятельности как цикл Шухарта-Деминга
Системный подход – тема для отдельного собрания сочинений. Сейчас уже, как мне кажется, бесполезно говорить об истоках системного подхода, потому что уровень информационного шума вокруг этой темы слишком велик. Я, конечно, не откажу себе в удовольствии сослаться на работы Берталанфи и Холла, но надо понимать, что всё то же самое, только другими словами, существовало гораздо раньше. Все содержание этой книги, собственно, и будет посвящено конкретным примерам применения системного подхода к инженерии. Теоретическую базу системного подхода, или даже правильнее сказать – системных подходов, потому что у многих авторов он свой собственный, вы всегда сможете найти в многочисленной литературе. Системный подход, в самой прямой трактовке, без каких-либо лишних теоретизирований, означает следующее – работа с объектом как с системой. К сожалению, определений системы тоже очень много, и мне снова придется давать свою вольную трактовку – рекурсивное определение системы. Заранее предупреждаю, что программистам будет проще пережить следующий абзац.
Система – это элемент другой системы, обладающий протяженностью в пространстве и времени, и предназначенный для выполнения определенного набора функций в другой системе в интересах ограниченного набора сторон, а также состоящий из элементов, функции которых отличны от функций определяемой системы, и функции определяемой системы не являются результатом сложения функций ее элементов.
Система обладает жизненным циклом, захватывающим пространственно-временную протяженность системы не только на стадии функционирования, но и на всех других – от замысла до вывода из эксплуатации. Жизненный цикл системы, в простейшей трактовке, представляет собой отрезок времени, разбитый на стадии. Однако, каждая стадия жизненного цикла соотнесена с практиками, которые используются на этой стадии обеспечивающими системами. Способ разбиения временного отрезка (от замысла до вывода из эксплуатации) на стадии, определяемые уникальными наборами практик, сегодня часто называют моделью жизненного цикла системы.
Фактически, жизненный цикл системы – это расширенное четырехмерное (пространство и время) понимание системы, включающее в себя также и другие системы, которые обеспечивают «жизнь» первой.
Например, когда мы говорим о жизненном цикле моста, то обсуждаем конкретную деятельность, в том числе, работу проектно-строительных компаний, а не только сам мост.
Заинтересованные стороны (стейкхолдеры) – это роли, в которых окружающие систему люди воздействуют на систему, а система имеет воздействие на них хотя бы раз в течение всего жизненного цикла системы.
Весь системный подход, в современном его изложении, крутится вокруг стейкхолдеров и их интересов. На рисунке 2 приведена схема связи между определением и воплощением системы через стейкхолдеров.
Рис. 2. Связь между определением и воплощением системы через стейкхолдеров (ISO 42010 – OMG Essence), из материалов А. И. Левунчука
Определенные выше понятия будут активно использоваться в дальнейшем изложении. Более подробное описание этих понятий, но на английском языке, вы можете найти в своде знаний по системной инженерии (SEBoK). Если эта книга у вас пойдет тяжело, рекомендую сначала разобраться с дисциплиной системного мышления, прекрасно изложенной в учебных курсах и материалах Анатолия Игоревича Левенчука.
Если говорить о близких к SEBoK русскоязычных учебниках, то их не так много. Академическое изложение предмета системной инженерии вы найдете в учебнике Александра Косякова и др. «Системная инженерия. Принципы и практика», переведенного с английского языка под редакцией Виктора Константиновича Батоврина. В МФТИ издано учебное пособие «Базовый курс системной инженерии», написанное Виктором Юрьевичем Николенко.
Что касается книги, которую вы читаете сейчас, то она никак не может быть названа учебником, однако представляет собой до боли актуальный кейс – пример использования системной инженерии в реальном проекте с множеством жизненных ситуаций, о которых обычно нигде не пишут. Опыт преподавания системной инженерии в Уральском федеральном университете (УрФУ) показывает, что для уровня системно-инженерной магистратуры катастрофически не хватает сборников кейсов, шаблонов, примеров и т. д. и т. п. В этой книге я постарался собрать те частные методы описания (методики, техники, методы, фреймворки и др.), а также инструменты, которые я сам чаще всего использую в работе. Так проще объяснять мне, и так быстрее системная инженерия становится понятна моим студентам.
На практике чаще всего встречаются следующие системно-инженерные роли:
системный инженер – отвечает за весь жизненный цикл системы;
системный аналитик – отвечает за требования к системе;
системный архитектор – отвечает за системную архитектуру;
системный тестировщик – отвечает за тестирование системы;
системный администратор – отвечает за обслуживание системы.
Системно-инженерная роль подразумевает не только ответственность, но и способность (компетенцию). Таким образом, чтобы избежать путаницы, сразу условимся, если, например, главный конструктор (по должности) отвечает, в том числе, за требования, но не обладает компетенциями системного аналитика (то есть не знает соответствующих дисциплин и не имеет нужного инструментария), то его нельзя называть системным инженером (по роли).
Примерами систем могут быть: автомобиль, самолет, система документооборота, завод, смартфон, месторождение полезных ископаемых, клиника и т. д.
В этой книге мы уделим внимание ролям системного аналитика и системного архитектора, а предметную область выберем самую актуальную – Интернет вещей.
Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам, потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков – залатывать дыры.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая на плечи новичка, является отличным поводом к моделированию вашей организации. На языке системной инженерии – вы имеете ценнейшее время, чтобы определить обеспечивающую систему для будущих проектов, то есть ту систему, которая будет, например, проектировать и воплощать целевые системы.
Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).
В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.
Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика. Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.
Присутствие различных стейкхолдеров на совещании – это, действительно, очень хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.
Если у вас в команде есть системный архитектор, то конечное решение о системной архитектуре принимает именно он, а не коллективный разум программистов. На деле мы всегда наблюдаем такую картину, что рядовые инженеры с удовольствием готовы порассуждать над вариантами архитектуры. И вот эти самые абстрактные рассуждения, иногда претворенные в бумажных почеркушках, и любят называть системной архитектурой.
Мы будем говорить, что системная архитектура – это принципиальные инженерные решения, изменение хотя бы одного их которых приводит к существенному изменению всей конструкции.
Если двигатель внутреннего сгорания в автомобиле заменить на электрический двигатель, то менять надо практически всё. Поэтому системная архитектура часто представляется в виде структуры принципиальных решений, поскольку одни изменения тянут за собой другие.
Другим примером ролевой болезни в инженерной практике является изображение из себя заказчика. Часто этим заболеванием страдает руководитель проекта. Опять-таки, умение руководителя интерпретировать потребности заказчика – важнейшая составляющая успеха проекта, но злоупотребление этим прекрасным умением приводит на практике к тому, что заказчика и вовсе перестают спрашивать о чем-либо, а еще чаще, просто, со временем забывают о его существовании, дистанцировавшись огромной бюрократической машиной. Тем временем, присутствие реальных представителей заказчика на ключевых совещаниях по проекту могло бы существенно снизить риски, и не позволить впасть в придумывание чужих потребностей, чем так часто болеют инженерные команды.
Если вы решились взять на себя роль системного инженера, придется помогать всем остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой таблички будет видно, какие роли в каких проектах представлены минимально. По иронии судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.