Вячеслав Мизгулин
Системный инженер. Как
начать карьеру в новом
технологическом укладе
«Издательские решения»
Мизгулин В.
Системный инженер. Как начать карьеру в новом технологическом
укладе / В. Мизгулин — «Издательские решения»,
ISBN 978-5-44-854498-9
Системный инженер — это самая востребованная профессия будущего.
Это умение видеть и менять будущее, работать в одной команде с самыми
разными специалистами, исправлять как можно больше ошибок еще
до того, как они будут сделаны. Системный инженер — это, в первую
очередь, инженер. Это достойное призвание, требующее полной отдачи себя.
Системная инженерия — это ключ к воплощению Интернета вещей, умных
производств и городов, а также многих других нашумевших технологических
идей.
ISBN 978-5-44-854498-9
© Мизгулин В.
© Издательские решения
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Содержание
Предисловие
Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Глава 2. Потребности и требования
Глава 3. Функциональное моделирование
Глава 4. Жизненный цикл системы и проекта
Глава 5. Бизнес-анализ
Глава 6. Совещание со стейкхолдерами
Глава 7. Системное проектирование
Интерлюдия
Часть 2. Пора брать в руки инструмент
Глава 8. Когда проектирование против конструирования
Глава 9. Системная инженерия и процессы жизненного цикла
Глава 10. Управление информацией
Глава 11. Моделе-ориентированный бизнес-анализ
Глава 12. Моделе-ориентированная работа со стейкхолдерами
Глава 13. Моделе-ориентированное системное проектирование
Кода
Послесловие
6
10
10
14
19
25
30
36
44
52
53
53
61
71
82
90
95
105
107
4
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Системный инженер
Как начать карьеру в новом
технологическом укладе
Вячеслав Мизгулин
© Вячеслав Мизгулин, 2017
ISBN 978-5-4485-4498-9
Создано в интеллектуальной издательской системе Ridero
5
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Предисловие
«Время кулинарии. Сегодня мы с вами будем готовить гуся.
– Гусь, ты готов?
– Да.
Гусь готов, друзья. Приятного аппетита!» (анекдот про
стейкхолдеров)
Достаточно сложно определить на русском языке, что такое системная инженерия, уже
только потому, что само понятие «инженерия» вобрало в себя со временем слишком много
всего, не говоря уж об инжиниринге. Большую работу на тему определения и стандартизации
системной инженерии на русском языке провел Виктор Константинович Батоврин, поэтому
я не буду на этом останавливаться подробно. Отмечу лишь, что процесс пересмотра стандартов системной инженерии в профессиональных сообществах идет постоянно. Не так давно
в Москве сформировалось Русское отделение международного совета системных инженеров
INCOSE, где вопрос определения системной инженерии периодически обсуждался и продолжает обсуждаться по сей день. Наиболее простым и понятным определением, хотя и не академическим, я считаю для себя следующее, предложенное Анатолием Игоревичем Левенчуком:
«Системная инженерия – это инженерия с системным подходом
в голове».
Под инженерией я, в свою очередь, буду понимать в этой книге любое спланированное
изменение окружающего мира, результат которого может быть проверен на соответствие задуманному плану. Поскольку эмпирический научный метод Бэкона время от времени переживает очередную реинкарнацию, например в цикле Шухарта-Деминга (рис. 1), то мне ничего
не остается, как сослаться на Бэкона и его предшественников (античных и, возможно, более
ранних), пытающихся формализовать здравый смысл или, как чаще говорили в те времена,
Божественный замысел. В итоге получим, что инженерия – это эмпирический научный подход
к прикладным задачам. Теперь, внимание. Поскольку инженерия, сама по себе, тоже является
прикладной задачей, то можно себе представить эмпирический научный подход к инженерии.
Это и есть системная инженерия.
Рис. 1. Обобщенная схема инженерной деятельности как цикл Шухарта-Деминга
Системный подход – тема для отдельного собрания сочинений. Сейчас уже, как мне
кажется, бесполезно говорить об истоках системного подхода, потому что уровень информационного шума вокруг этой темы слишком велик. Я, конечно, не откажу себе в удовольствии
сослаться на работы Берталанфи и Холла, но надо понимать, что всё то же самое, только другими словами, существовало гораздо раньше. Все содержание этой книги, собственно, и будет
посвящено конкретным примерам применения системного подхода к инженерии. Теоретическую базу системного подхода, или даже правильнее сказать – системных подходов, потому
6
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
что у многих авторов он свой собственный, вы всегда сможете найти в многочисленной литературе. Системный подход, в самой прямой трактовке, без каких-либо лишних теоретизирований, означает следующее – работа с объектом как с системой. К сожалению, определений
системы тоже очень много, и мне снова придется давать свою вольную трактовку – рекурсивное определение системы. Заранее предупреждаю, что программистам будет проще пережить
следующий абзац.
Система – это элемент другой системы, обладающий протяженностью
в пространстве и времени, и предназначенный для выполнения определенного
набора функций в другой системе в интересах ограниченного набора сторон,
а также состоящий из элементов, функции которых отличны от функций
определяемой системы, и функции определяемой системы не являются
результатом сложения функций ее элементов.
Система обладает жизненным циклом, захватывающим пространственно-временную
протяженность системы не только на стадии функционирования, но и на всех других –
от замысла до вывода из эксплуатации. Жизненный цикл системы, в простейшей трактовке,
представляет собой отрезок времени, разбитый на стадии. Однако, каждая стадия жизненного цикла соотнесена с практиками, которые используются на этой стадии обеспечивающими
системами. Способ разбиения временного отрезка (от замысла до вывода из эксплуатации)
на стадии, определяемые уникальными наборами практик, сегодня часто называют моделью
жизненного цикла системы.
Фактически, жизненный цикл системы – это расширенное
четырехмерное (пространство и время) понимание системы, включающее
в себя также и другие системы, которые обеспечивают «жизнь» первой.
Например, когда мы говорим о жизненном цикле моста, то обсуждаем конкретную деятельность, в том числе, работу проектно-строительных компаний, а не только сам мост.
Заинтересованные стороны (стейкхолдеры) – это роли, в которых
окружающие систему люди воздействуют на систему, а система имеет
воздействие на них хотя бы раз в течение всего жизненного цикла системы.
Весь системный подход, в современном его изложении, крутится вокруг стейкхолдеров
и их интересов. На рисунке 2 приведена схема связи между определением и воплощением
системы через стейкхолдеров.
7
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 2. Связь между определением и воплощением системы через стейкхолдеров (ISO
42010 – OMG Essence), из материалов А. И. Левунчука
Определенные выше понятия будут активно использоваться в дальнейшем изложении.
Более подробное описание этих понятий, но на английском языке, вы можете найти в своде
знаний по системной инженерии (SEBoK). Если эта книга у вас пойдет тяжело, рекомендую
сначала разобраться с дисциплиной системного мышления, прекрасно изложенной в учебных
курсах и материалах Анатолия Игоревича Левенчука.
Если говорить о близких к SEBoK русскоязычных учебниках, то их не так много. Академическое изложение предмета системной инженерии вы найдете в учебнике Александра Косякова и др. «Системная инженерия. Принципы и практика», переведенного с английского языка
под редакцией Виктора Константиновича Батоврина. В МФТИ издано учебное пособие «Базовый курс системной инженерии», написанное Виктором Юрьевичем Николенко.
Что касается книги, которую вы читаете сейчас, то она никак не может быть названа учебником, однако представляет собой до боли актуальный кейс – пример использования системной инженерии в реальном проекте с множеством жизненных ситуаций, о которых обычно
нигде не пишут. Опыт преподавания системной инженерии в Уральском федеральном университете (УрФУ) показывает, что для уровня системно-инженерной магистратуры катастрофически не хватает сборников кейсов, шаблонов, примеров и т. д. и т. п. В этой книге я постарался
собрать те частные методы описания (методики, техники, методы, фреймворки и др.), а также
инструменты, которые я сам чаще всего использую в работе. Так проще объяснять мне, и так
быстрее системная инженерия становится понятна моим студентам.
На практике чаще всего встречаются следующие системно-инженерные роли:
системный инженер – отвечает за весь жизненный цикл системы;
системный аналитик – отвечает за требования к системе;
системный архитектор – отвечает за системную архитектуру;
системный тестировщик – отвечает за тестирование системы;
системный администратор – отвечает за обслуживание системы.
Системно-инженерная роль подразумевает не только ответственность, но и способность
(компетенцию). Таким образом, чтобы избежать путаницы, сразу условимся, если, например,
8
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
главный конструктор (по должности) отвечает, в том числе, за требования, но не обладает компетенциями системного аналитика (то есть не знает соответствующих дисциплин и не имеет
нужного инструментария), то его нельзя называть системным инженером (по роли).
Примерами систем могут быть: автомобиль, самолет, система
документооборота, завод, смартфон, месторождение полезных ископаемых,
клиника и т. д.
В этой книге мы уделим внимание ролям системного аналитика и системного архитектора, а предметную область выберем самую актуальную – Интернет вещей.
9
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять
какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего
общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы
устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам,
потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков – залатывать дыры.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая
на плечи новичка, является отличным поводом к моделированию вашей организации. На языке
системной инженерии – вы имеете ценнейшее время, чтобы определить обеспечивающую
систему для будущих проектов, то есть ту систему, которая будет, например, проектировать
и воплощать целевые системы.
Целевой системой будем называть тот конечный продукт, подлежащий
эксплуатации, за работу над которым инженерным организациям платят
деньги или выдают еду (в зависимости от места работы).
В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов
команды, как стейкхолдеров.
Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель
проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика.
Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь
заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.
Присутствие различных стейкхолдеров на совещании – это, действительно, очень
хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют
других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть
палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам
этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.
Если у вас в команде есть системный архитектор, то конечное решение о системной архитектуре принимает именно он, а не коллективный разум программистов. На деле мы всегда
наблюдаем такую картину, что рядовые инженеры с удовольствием готовы порассуждать над
вариантами архитектуры. И вот эти самые абстрактные рассуждения, иногда претворенные
в бумажных почеркушках, и любят называть системной архитектурой.
Мы будем говорить, что системная архитектура – это принципиальные
инженерные решения, изменение хотя бы одного их которых приводит
к существенному изменению всей конструкции.
Если двигатель внутреннего сгорания в автомобиле заменить на электрический двигатель, то менять надо практически всё. Поэтому системная архитектура часто представляется
в виде структуры принципиальных решений, поскольку одни изменения тянут за собой другие.
10
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Другим примером ролевой болезни в инженерной практике является изображение
из себя заказчика. Часто этим заболеванием страдает руководитель проекта. Опять-таки,
умение руководителя интерпретировать потребности заказчика – важнейшая составляющая
успеха проекта, но злоупотребление этим прекрасным умением приводит на практике к тому,
что заказчика и вовсе перестают спрашивать о чем-либо, а еще чаще, просто, со временем забывают о его существовании, дистанцировавшись огромной бюрократической машиной. Тем временем, присутствие реальных представителей заказчика на ключевых совещаниях по проекту
могло бы существенно снизить риски, и не позволить впасть в придумывание чужих потребностей, чем так часто болеют инженерные команды.
Если вы решились взять на себя роль системного инженера, придется помогать всем
остальным ролям «не выходить из себя», то есть из роли. Итак, вам следовало бы первым делом
завести табличку, в которой каждому сотруднику из штатного расписания, с которым приходится совместно работать ставились бы в соответствие те роли, которые сознательно или несознательно взяли на себя эти люди во всех проектах, в которых они принимают участие. Из этой
таблички будет видно, какие роли в каких проектах представлены минимально. По иронии
судьбы так часто получается, что, например, роль менеджера проекта зачастую представлена
хуже всех, потому что сам менеджер любит хвататься за все задачи подряд, забывая свою основную компетенцию. В итоге страдает командный дух, сроки нарушаются, бюджеты превышаются. Исходя из ситуации в вашей компании, вы могли бы постепенно занять самую критичную
роль в соответствии со своими полномочиями. Такой шаг дает быстрый результат: проекты
разгружаются, эффективность работы растет, настроение поднимается, в том числе у руководства.
Ниже пример таблицы, которая может получиться в результате. Не надо пугаться,
на практике в проектах, к сожалению, бывает по 3 менеджера, 5 архитекторов и 1 программист.
ектах
Таблица 1. Неудачный (как обычно бывает) вариант распределения ролей в текущих про-
Не надо думать, что проблема в неправильном назначении ролей. Менеджер, вполне возможно, все правильно распределил. Проблема в том, что на деле сотрудники берут на себя
совсем иные роли, чем было предусмотрено.
Когда менеджер проекта начинает на совещании предлагать системно-архитектурные
решения, то он играет роль системного архитектора – не свою. Учитывая, что время ограничено, то, скорее всего, такой менеджер не успеет полностью отыграть свою роль, в результате
чего сорвутся сроки.
Ниже приведена другая таблица распределения ролей. Если вам со временем удастся
добиться такой организации команды, будет здорово.
11
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Таблица 2. Удачный вариант распределения ролей в текущих проектах
Работа системного инженера начинается с упорядочения среды, в которую он попал.
Чтобы сформировать целостное представление о системе, которую вам предстоит делать, надо,
прежде всего, четко разделить зоны ответственности членов команды проекта. Это нужно сделать сначала в своей голове, а потом в действительности. Необходимо следить за тем, чтобы
каждый член команды «играл» свою роль. Здесь вам потребуется деликатность и лидерство,
а также поддержка руководства. По моему скромному опыту (и богатому опыту моих коллег), большинство срывов проектов связано именно с конфликтами на почве зон ответственности. Системный инженер, являясь посредником между менеджерами и различными специалистами, должен следить за тем, чтобы члены команды действовали в соответствии со своими
ролями, но делать это так, чтобы никого не обидеть и не разозлить.
Даже если вы предлагаете рациональные решения, кто-то обязательно будет «против»,
потому что затрагиваются его интересы. Кто-то из стейкхолдеров (среди которых всегда есть
и члены команды проекта) имеет определенного рода интерес, чтобы всё было именно так
«как есть». А еще именно этот стейкхолдер обычно старается сделать так, чтобы остальные
не смогли увидеть ситуацию в целом. Это может касаться чьих-то скрытых доходов или того
хуже.
Прежде чем браться за дело, нужно взвесить все интересы вокруг. На первом этапе
не надо никому ничего доказывать. Главное, что надо сделать – понять, существует ли возможность реализовать успешную систему в рамках проекта или в будущем (на основе результатов
вашего проекта)? Если такая возможность есть, то системный инженер должен эту потенциальную систему четко определить. Она, скорее всего, будет существенно отличаться от заявленной в исходном техническом задании.
Репутация системных инженеров складывается из успешных
и провальных систем, которые были реализованы в результате их
деятельности.
Если ваша система изначально не имеет шансов на успех из-за чьих-то интересов или их
отсутствия, либо эти шансы очень малы… решать вам. Обеспечивать проект тоннами документации, в которой невозможно разобраться, – не самая привлекательная перспектива. Поэтому
давайте сразу договоримся, что тут мы будем говорить именно про инженерные проекты,
а не про бумажные.
Вот на совещание пришел заместитель директора по проектам и начал доказывать
системному архитектору системы, что надо все переделать, потому что много инноватики.
У компании, по мнению замдира, достаточно опыта, чтобы решать задачу проверенными классическими методами. Если вы обратитесь к нежданному гостю с вопросом: «А какая твоя роль
в проекте?», – он может быть фраппирован. Вся команда должна понимать, что человеку иногда надо выговориться. Возможно, имеет смысл искать полезную политическую информацию
между строк. Потом всегда можно составить протокол, зафиксировать предложение и обосновать на бумаге отказ с подписью технического директора, например. К сожалению, такое
бывает. Да, на это приходится тратить время.
12
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Вы заметили, что представители заказчика не интересуются вашим
проектом: не звонят, не ругаются? Это верный признак того, что им этот
проект не нужен.
Возможно, у кого-то из партнеров внезапно оказались неосвоенные деньги, а вашей компании перепало оказаться каналом их освоения. Конечно, никто ничего не успел толком согласовать, поэтому интерес у стейкхолдеров весьма формальный, однако для вашей организации
это отличный способ инвестировать в молодые кадры. Этот проект можно доверить неопытным
специалистам. Хорошо организованная команда молодых специалистов может даже из такого
«заброшенного» проекта получить пользу. Возможно, это будет какая-то инновационная разработка. Может быть, удастся отработать «слабые места» технологии. Там, где другие видят
проблему, постарайтесь разглядеть возможность.
Если вас достают звонками – это нормально. Если все время требуют что-то – это очень
хорошо. Значит, скорее всего, заказчик заинтересован в результате, и система будет эксплуатироваться. Значит, вы работаете не зря. Значит, надо проявить максимум своих компетенций.
Разделяйте зоны ответственности команды проекта и зоны интересов стейкхолдеров,
чтобы понимать, какая реальная задача перед вами стоит, и сколько ресурсов вы реально
можете в нее вложить.
13
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 2. Потребности и требования
Предположим, ваш срок «устаканивания» в компании прошел за 3 месяца, и теперь
вам доверили поучаствовать во вполне себе реальном проекте. Ваша компания решила сделать новый продукт – умный дом, а вам предложили поучаствовать в этом проекте в качестве
системного аналитика.
Для начала вопрос – что должен делать системный аналитик? Что является результатом его работы? Не факт, что вам кто-то будет объяснять, что, собственно, от вас требуется.
И не факт, что обязанности системного аналитика в предыдущих «учебных» проектах будут
как-то коррелировать с новыми обязанностями в реальном проекте, где на кону – деньги
и репутация компании. Я бы на вашем месте не задавал никому подобных вопросов, а начал
тщательно разбираться со стейкхолдерами, их потребностями и требованиями.
Потребности и требования – принципиально разные понятия. Сначала, надо разобраться,
какие стейкхолдеры есть у системы с рабочим названием умный дом. Нас пока даже не должно
интересовать, что это такое – умный дом. Вопрос исключительно в стейкхолдерах.
Называть стейкхолдеров нужно в честь их роли относительно целевой
системы.
Не путайте с ролью в проекте, должностью, названием организации, ФИО и чем-угодно
другим. Роль относительно целевой системы должна быть однозначно интерпретируемой,
подразумевая конкретный интерес. Например, стейкхолдером может быть: инвестор, заказчик, пользователь, сервисный инженер, но не может быть: Константин Константинович, ООО
«яКомпания», начальник отдела сбыта.
Самое главное – не путайте заказчика проекта и заказчика целевой
системы.
Вспомните определение системы из введения и отметьте для себя, что заказчик целевой
системы – это тот, кто просит собрать/поставить целевую систему в ее физическом воплощении
(обычно еще на определенной территории). Заказчиком проекта может быть ваша же ИТ-компания в лице директора, который вкладывается в разработку и производство опытных образцов. Как правило жизненный цикл проекта значительно короче жизненного цикла системы.
Поэтому, чтобы не запутаться между проектами, стейкхолдеров надо называть в честь ролей
относительно целевой системы на всем ее жизненном цикле. Не менее важный момент заключается в том, что за проект не всегда платит заказчик. Инвестировать работы может совершенно другая организация или несколько организаций с разными интересами. Начать можно
с таблицы.
Таблица 3. Стейкхолдеры целевой системы с рабочим названием умный дом
14
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
На самом деле стейкхолдеров гораздо больше, но не надо думать, что вам удастся сразу
составить полный список. Уточняйте список по ходу работы. Тем более, пока вы не начали
прямые контакты с людьми, все эти списки являются лишь заготовкой, которая может помочь
вам составить список вопросов для проведения интервью или модерации совещания. Реальное
положение дел может оказаться совсем не таким, как вы думаете сейчас.
Есть некий потенциальный собственник, который желает улучшить свой дом (пока
не понятно, какой дом) – имеем определенного рода спрос. Ваша ИТ-компания желает выйти
на этот новый рынок, поэтому готова вложиться в разработку. У компании есть партнеры, которые могут поставлять комплектующие. Есть программисты, готовые реализовать алгоритмы
поведения системы. Есть необходимые специалисты для сборки, монтажа и обслуживания
системы. Имеется также коммерческая структура, способная обеспечить продажи системы.
В этом контексте главным источником информации о потребителе будет стейкхолдер-продавец (СХ7), но забывать об остальных стейкхолдерах категорически нельзя.
Рассматриваемая ситуация может показаться очевидной, но могла быть другая. Заказчиком умного дома и проекта в одном лице мог быть вполне конкретный человек (например,
автоматизация конкретного дома под заказ). Тогда не нужно было бы делать предпродажную
работу, исследовать рынок. Жизненные циклы таких двух проектов существенно отличаются.
Начинается первая и самая непредсказуемая часть разработки – определение границ
системы. Вам надо дать системе название.
В системной инженерии принято называть систему по основной
функции, которую она выполняет.
Как известно, система выполняет функции на стадии эксплуатации. Какую главную функцию выполняет умный дом?
Очень часто проекты называют беспредметно и абстрактно. Часто приходится слышать
такие названия проектов как «Система управления сервисами платформы того-то» или «Сервис управления системами сего-то». Чаще всего целью проекта является разработка какогонибудь маленького модуля, а в названии пишут чуть ли не «Разработка системы управления
миром».
Система, которую заказал директор, совсем не дом. Насчет «ума» у меня тоже есть сомнения. Речь идет, скорее всего, о датчиках, контроллерах, каких-то управляющих механизмах,
проводах, компьютерах и ИТ-коммуникациях. Все это вместе в одной коробке – умный дом.
На деле это автоматизированная система управления освещением, тепловым оборудованием,
звуковым оборудованием или чем-то еще в этом роде. Вряд ли кто-то сможет сразу ответить
нам на вопрос, чем эта система должна управлять. В такой ситуации я бы предложил начать
с формулирования потребностей.
Анализ потребностей мог проводиться ранее отделом маркетинга. Результатами этой
работы нельзя пренебрегать. Порой очень ценная информация о потребностях стейкхолдеров
есть у директора и топ-менеджеров компании. Потребность, на начальном этапе, будем определять через выражение следующего вида:
Я, как <стейкхолдер>, хочу <потребность>, потому что <проблема>.
Например, я, как владелец умного дома, хочу меньше платить за электричество, потому
что сейчас приходится платить слишком много из-за неэффективно использующегося оборудования, например, ночью.
Коммерческий отдел или отдел маркетинга вряд ли будет формулировать потребность
именно в такой форме. Ваша задача, как системного инженера, привести к одной форме все
потребности. Однако надо учесть, что коммерсанты могут перевернуть вам представление
о проекте в один счет.
15
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
На очередном совещании выясняется, что спрос на системы типа умного дома
резко вырос у бизнес-центров. Этот рынок достаточно новый и большой. Вопрос заключается в том, есть ли принципиальная разница между умным домом для коттеджа и для бизнес-центра? Вероятно, потребности стейкхолдеров умного бизнес-центра будут значительно
шире. Ценник будет отличаться, возможно, на порядок. Требования будут значительно жестче.
Тем не менее, если бизнес-центр научится экономить ресурсы, оставив стоимость арендной
платы на прежнем уровне, это позволит увеличить прибыль.
Обычно выявлением потребностей занимаются отдельные специалисты. Системный
инженер должен структурировать потребности относительно стейкхолдеров системы (простейшая форма дана выше), а затем для каждой потребности сформулировать набор требований.
Требование формулируется относительно самой системы или ее элементов.
Потребность должна оставаться актуальной вне зависимости от целевой
системы.
Пользователь хочет платить меньше независимо от существования умного дома. Требование актуально относительно целевой системы и ее элементов. Будем использовать следующую переходную конструкцию от потребности к требованию:
Я, как <стейкхолдер>, считаю, что система должна <требование>,
чтобы <потребность>.
Например, я, как владелец умного бизнес-центра, считаю, что система должна автоматически выключать кондиционеры после часа работы в пустых помещениях, чтобы мне меньше
приходилось платить за электричество.
Итак, вам понадобится для старта набор базовых потребностей, чтобы понять, какую
систему предстоит сделать. Потом вы сможете задавать стейкхолдерам правильные вопросы,
чтобы сформулировать требования. Повторюсь, что стейкхолдеры будут формулировать
потребности и требования как-угодно, только не по форме. Приведение к форме – задача
системного инженера. Слова, которые произносит стейкхолдер в ответ на ваши вопросы,
можно называть по-разному в зависимости от ситуации: интервью, лозунги, протокол, стенограмма и др.
Требования бывают очень разные, но все они начинаются одинаково: «Система
должна…». В разных отраслях промышленности требования группируют по-разному (требования к назначению, к показателям функционирования, к функциональным характеристикам,
к безопасности, к защите интеллектуальной собственности, к документации и т.д.). Иногда
выделяют еще ограничения. Они отличаются от обычных требований тем, что направлены
на внутреннее устройство системы, то есть на системную архитектуру или того конкретней. Нет
ничего хорошего в том, что стейкхолдер настаивает на определенных ограничениях. Системный инженер должен стараться эти ограничения снять в процессе переговоров и согласований. Однако, бывают ситуации, когда ограничения снять нельзя. Например, как в нашем
случае с умным бизнес-центром. У нас есть стейкхолдер – поставщик комплектующих. Соответственно, уже на начальном этапе известен список возможных комплектующих, из которых
нам предстоит собирать систему.
Итак, допустим, что в результате переговоров с коммерческим отделом и другими стейкхолдерами, вам удалось сформулировать следующие потребности (таблица 4). Очевидно, что
контекст этих потребностей пока еще очень размыт. Тем не менее, не бойтесь делать различные описания системы. Со временем они будут становиться более строгими и конкретными.
16
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Таблица 4. Потребности стейкхолдеров системы с рабочим названием умный бизнес-центр
Для каждой потребности необходимо предложить сценарии использования системы,
по которым можно будет судить об удовлетворении потребности, а также о степени удовлетворения, если необходимо. Именно сформулированные потребности помогают системному инженеру спланировать валидацию системы, например в рамках приемочных испытаний.
На практике я часто встречался с ситуациями, когда проверочные и приемочные испытания
представляли собой примерно одно и то же, поставленное в календарном плане друг за другом.
Сейчас, когда вы формулируете потребности и требования, давайте зафиксируем:
систему верифицируют на соответствие требованиям (на проверочных
испытаниях), а валидируют (например, на приемочных испытаниях или еще
до них) систему на предмет удовлетворения потребностей.
Если системному инженеру удается обосновать целесообразность проекта набором
непротиворечивых потребностей/проблем, заставляющих стейкхолдеров проявлять активность, значит можно идти дальше. Чаще всего идея приходит внезапно, поэтому на практике
целесообразность нового проекта доказывают уже постфактум с помощью анализа потребностей, хотя, казалось бы, логичнее формулировать идею проекта исходя из предварительного
анализа потребностей, то есть наоборот.
Остановимся на потребности (П1) – меньше платить за электричество и водоснабжение.
Важной способностью системного инженера должно быть сценарное (или алгоритмическое)
мышление. Можно выделить несколько основных видов мышления по времени приложения:
рассуждения о настоящем времени; рассуждения о прошедшем времени; рассуждения о будущем времени. Думаете, это все? Можно еще рассуждать о прошлом из прошлого, о прошлом
из будущего, о будущем из прошлого и т. д. Успешный системный инженер должен думать
во всех временах с одинаковой изворотливостью и быстротой.
В прошлом, владелец бизнес-центра переплачивал за электричество и водоснабжение,
потому что арендаторы неэкономно пользовались ресурсами. Арендная плата учитывала возможные переплаты, но сейчас настали тяжелые времена, поэтому необходима оптимизация
расходов, иначе бизнес может стать убыточным. Если владелец бизнес-центра купит и внедрит
целевую систему, то фактические затраты на электричество и водоснабжение сократятся, следовательно, при сохраненной арендной плате владелец сможет получать дополнительную прибыль с арендаторов. Первый вопрос заключается в сроке окупаемости целевой системы. Второй
вопрос – какие конкретные функции должна выполнять система, чтобы сокращать затраты?
Этот вопрос адресует нас напрямую к требованиям.
17
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Таблица 5. Требования владельца и пользователя системы (СХ1) для потребности (П1)
Вариантов требований может быть очень много. Можно вспомнить про парковки, про
влажность воздуха, про авторегулирование освещения и многое другое. Требования всегда
имеет смысл ранжировать. Уровень важности того или иного требования может оценить каждый стейкхолдер. При этом, каждый стейкхолдер может быть «по секрету» взвешен, на предмет собственной важности. Снимать требования в зависимости от их низкого ранга «просто
так», конечно, нельзя. Но так легче понять, какие требования можно вынести на обсуждение
со стейкхолдерами, как необязательные. А уже потом – убрать.
Требованиям должна в конечном итоге соответствовать реализация, поэтому даже
в начале проекта необходимо иметь некоторое представление о вариантах архитектуры
системы. Это во многом ограничивает требования и их фокусирует.
Всегда фиксируйте каждое новое требование в процессе работы над проектом. Когда
новые требования начнут противоречить исходному техническому заданию – идите к менеджеру. Это очень серьезная проблема, которую нельзя игнорировать.
Составьте список стейкхолдеров целевой системы, определите их реальные потребности в ходе переговоров, маркетинговых исследований, консультаций с экспертами. Отталкиваясь от потребностей, вы сможете точнее формулировать требования к системе и быстрее согласовывать их со стейкхолдерами.
18
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 3. Функциональное моделирование
Сбор и анализ требований будет гораздо эффективнее, если кроме «послойного осаждения» в документации, они еще отразятся в функциональной модели системы.
Иногда о функциональной модели говорят: «Взгляд снаружи внутрь». То есть, в какойто мере, функциональная модель представляет собой структуризацию и уточнение требований до той степени, когда не возникает вопросов, что именно должна делать целевая система.
Давайте попробуем нарисовать функциональную модель системы умный бизнес-центр. Для
этого нам необходимо назвать ее основную функцию. Мы снова вернулись к этому вопросу.
Можно было бы нарисовать вот такую схему «на салфетке» (рис. 3).
Рис. 3. Контекстная функциональная модель системы управления потреблением электроэнергии и воды в бизнес-центре
Если мы напишем все функции системы через запятую в одном названии, то, фактически, мы словом «система» подменим, просто, некоторое объединение. На самом деле, мы будем
проектировать в таком случае несколько разных систем, которые работают в некоторой связке:
одна управляет электроэнергией, а другая – водоснабжением (может быть еще несколько аналогичных систем). Никакого системного эффекта здесь не просматривается. Можно было бы
обобщить до понятия «ресурсы», но, опять таки, это обобщение не раскроет системного
эффекта, возникающего при связанном функционировании перечисленных систем.
Еще одна неувязка заключается в том, что большинство требований относятся не столько
к «коробочке с проводами», как мы охарактеризовали умный дом, сколько к некоторой инфраструктуре всего здания. То есть наших стейкхолдеров интересуют не сигналы управления
на выходе, а конкретные действия по регулированию воды или электричества. Должен ли
входить в нашу систему, например, кондиционер? И все-таки, кто же наши пользователи?
Владельцы бизнес-центров, персонал, арендаторы или системные интеграторы, монтирующие
«коробочку с проводами» в инфраструктуру здания? А может быть, мы должны проектировать
всё здание «под ключ» вместе с умным бизнес-центром внутри?
Первый вариант, который мы рассмотрим, будет заключаться в укрупнении задачи.
Давайте назовем функцией системы – поддержку комфорта в бизнес-центре (рис. 4). Таким
ходом мы ставим себе задачу четкого определения термина «комфорт», вплоть до математической формулы. Для начала давайте декомпозируем комфорт, например, вот в такой кортеж:
Комфорт = <Температура воздуха, Влажность воздуха, Уровень
автоматизации, Экономия>
Можно декомпозировать дальше:
Уровень автоматизации = <Включение и выключение эскалаторов,
Автоматическая подача воды порциями и т.д.>
19
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Когда мы знаем структуру, можно предложить различные математические критерии оценивания этого самого комфорта, например с помощью развесовки и суммирования. Каждый
из субкритериев можно привести к нормализованному виду от 0 до 1, тогда задача оценки
уровня комфорта не составит никакого труда. Но не будем углубляться в оценку – это предмет системного анализа, а не системной инженерии. Проблема в том, что поддержать тот или
иной уровень комфорта система может только тогда, когда в неё входят приборы, взаимодействующие со средой, например, тот же кондиционер. Коробка с проводами сама по себе комфорт не обеспечивает – это не ее функция. Системный инженер должен обязательно обсудить
с менеджерами такую проблему. Скорее всего, будет предложено не выходить за рамки идеи –
коробки с проводами. Оборудовать здание кондиционерами, электроприборами и батареями –
не совсем та задача, которую мы хотели решать сначала.
тре
Рис. 4. Контекстная функциональная модель системы поддержки комфорта в бизнес-цен-
Второй вариант функции системы (в сторону уменьшения задачи) – минимизация денежных расходов на ресурсы в бизнес-центре в реальном времени (рис. 5). Чем интересен этот
вариант? Во-первых, в названии появились деньги. Мы говорим не о разных системах, которые регулируют разные ресурсы, а пересчитываем всё в деньги – тут просматривается системный эффект. Во-вторых, минимизация, как любая оптимизация, может решаться при заданных
ограничениях, например, на тот самый уровень комфорта. Но для целевой системы не важно,
что будет стоять за этими ограничениями. В-третьих, мы указали, что всё происходит в реальном времени, то есть целевая система не подводит итоги в конце квартала, чем мог бы заниматься рядовой специалист, а принимает и воплощает решения непосредственно в процессе
потребления ресурсов. Такая формулировка уже наводит на мысль, что этим занимается компьютер, потому что, в противном случае, пришлось бы нанимать слишком много персонала
и организовать их коммуникации с помощью, например, комплекта раций: один на электрощитке, а другой – у стояка и т. д. Обратите внимание, что, по сравнению с первой схемой,
изменилось только название, но как принципиально это отразится на всей дальнейшей работе.
Рис. 5. Контекстная функциональная модель системы минимизации денежных расходов
на ресурсы в бизнес-центре в реальном времени
Интуитивно может показаться, что сейчас самое время начать функциональную декомпозицию системы, чтобы понять, как она должна работать, но это не так. Я настоятельно
рекомендую выполнить обратное действие – давайте представим функцию нашей системы
20
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
в составе функциональной декомпозиции использующей системы, то есть той системы, которая использует целевую систему. Чтобы это сделать, надо понять – что есть использующая
система? В русскоязычной литературе часто встречается термин «надсистема», но он мне
не нравится, поскольку не задает «потолок» рассуждениям о границах. Мы будем говорить
именно о той системе, которая использует целевую систему «умный бизнес-центр», то есть
«коробочку с проводами», то есть «систему минимизации денежных расходов бизнес-центра
в реальном времени». Судя по всему, использующая система и есть бизнес-центр, но какая
у него функция?
Мы уже вели рассуждения о комфорте. Если немного переформулировать функцию, связанную с комфортом, получим неплохую формулировку для использующей системы – система
поддержки комфортных условий для ведения бизнеса. Вполне логично, что для комфортного ведения бизнеса нужна близкая к комнатной температура, продуманное управление потоками людей, наличие санузлов, электричества и многое другое. Немаловажно – чтобы все
это укладывалось в реалистичный бюджет. Было бы неплохо весь список этих условий включить в новый кортеж, характеризующий уровень комфорта. Он будет похож на предыдущий,
но более полный, потому что мы теперь правильно определили системные уровни для поставленной задачи.
Основной критерий правильного использования функциональной
модели – резкое ускорение процесса проектирования. Если у вас возникают
трудности в разработке, вернитесь к функциональной модели. При этом
неважно, занимались вы функциональным моделированием «на бумаге»
или нет. Все равно в вашей голове есть какая-то функциональная модель.
Нарисуйте то, что у вас в голове, используя один из формализмов
функционального моделирования.
Что вы делаете? Систему, которая обеспечивает комфорт или систему, которая экономит
деньги? Это же два абсолютно разных проекта. Какой бюджет у модернизации бизнес-центра,
а какой – у создания «коробочки с проводами»? Самые частые ошибки в инженерных проектах, которые я наблюдал на практике, были связаны с неверными представлениями о функции
целевой системы. Когда в голове «комфорт», а проект про «коробочку с проводами», будут
большие сложности с принятием решений.
Итак, обратимся к использующей системе – бизнес-центру. Мы определили функцию
использующей системы и можем выполнить функциональную декомпозицию следующим способом.
Определяем входные потоки:
– внешние условия, включая погоду, механические воздействия, городской шум и другое;
– ресурсы, приходящие к нам через инженерные коммуникации: вода, электричество, газ
или еще что-то;
– запросы на сервисы – в любом бизнес-центре нужны санузлы, уборщицы или что-то
более специфичное типа эскалаторов (сервис транспорта), центров печати.
Определяем выходные потоки:
– мы ожидаем, что здание обеспечит нам внутренний комфортный климат, огородив
от внешней среды;
– мы ожидаем, что услуги/сервисы будут оказаны, в результате чего мы получим воду,
напечатанные документы, поменяем местоположение и т. д.
Обращаю внимание, что рассуждение про потоки идет параллельно рассуждению о конструкции: здание, инженерные коммуникации, эскалаторы и т. д. То есть мы немного забегаем
вперед, простраивая логическую архитектуру. Для системной инженерии это обычное дело,
когда приходится перескакивать между разными точками зрения (частными методами описа21
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
ния), чтобы удержать в голове целостность системы. Для кого-то, возможно, было бы удобно
нарисовать схему логической архитектуры уже сейчас в каком-то виде: показать стены, инженерные коммуникации, эскалаторы, санузлы и т. д. Я этого делать не буду. К логической архитектуре мы подойдем чуть позже. На данном этапе нам не столько важны варианты воплощения, сколько общая идея того, что происходит внутри использующей системы. Важно –
использующая система пока существует без «коробочки с проводами».
есть)
Рис. 6. Функциональная диаграмма использующей системы без целевой системы (как
Далее нам надо понять, какие изменения претерпевают потоки, пока они доходят от входа
к выходу, и как они влияют друг на друга внутри использующей системы. Это творческая
задача, требующая хорошей технической подготовки. Каждый факт изменения потока мы фиксируем в виде той или иной функции, которую использующая система должна выполнять,
чтобы реализовать свою главную функцию. Так и получается декомпозиция использующей
системы.
Это один из возможных способов. Более академический вариант – выполнить поиск аналогов, а также (что гораздо сложнее) найти описания функционирования этих аналогов, потом
выбрать наиболее близкое к вашему случаю описание и представить его в виде функциональной модели.
Стейкхолдер (СХ1), то есть владелец бизнес-центра, хочет экономить. То есть хочет регулировать использование ресурсов так, чтобы ему это обходилось дешевле, а условия ведения
бизнеса при этом держались на заданном уровне. Вставляем целевую систему в качестве новой
функции и смотрим, что получилось (рис. 7). Будем целевую систему и потоки, связанные
с ней, рисовать жирными линиями, чтобы смотрелось нагляднее. Введем идетификаторы для
элементов: ПТ – потоки; ИС – использующая система; СОО – системы в операционном окружении; ЦС – целевая система, которую вы сейчас проектируете.
22
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 7. Функциональная диаграмма использующей системы с целевой системой
Каждый поток, входящий или выходящий из использующей системы,
может быть ассоциирован с потребностью.
Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать
центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов,
повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью,
ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно
и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой – относятся к целевой
системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть
дополнительно – (СХ6) техобслуживание.
Требования к целевой системе мы можем теперь разделить на 4 группы:
– требования к управлению сервисами (Т2, Т3);
– требования к управлению средой (Т1, Т4);
– требования к мониторингу среды;
– требования к мониторингу сервисов.
В скобках приведены идентификаторы тех требований, которые мы уже писали ранее.
Как видно, мы интуитивно заметили только две группы требований. Требования к мониторингу сервисов могут быть связаны, например, с количеством сервисов, которыми система
должна управлять, типами сервисов и их результатов; это могут быть расстояния, время,
частота получения информации и многое другое. Мониторинг среды также имеет свои особенности, например: количество точек сбора информации, конкретные измеряемые характеристики, периодичность измерений и многое другое.
Самое время определиться с тем, какие именно ресурсы и сервисы будут связаны с целевой системой. Это приведет к декомпозиции как самой функции системы, так и к декомпозиции потоков. Важно заметить, что каждый элемент схемы нуждается в спецификации, включающей как минимум:
– идентификатор;
– короткое название;
– полное название;
– входные параеметры;
– выходные параметры;
23
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– иные функциональные связи.
У начинающих системных аналитиков часто возникает вопрос: «А когда
нужно прекращать декомпозировать? Сколько уровней должно быть?». Если
спецификация функции занимает меньше A4, значит её уже не надо
декомпозировать. Еще вариант – если по спецификации можно найти и купить
соответствующий модуль.
Когда функциональное описание использующей системы вместе со встроенной целевой
системой будет закончено, нужно вспомнить, что было на рисунке 1. У нас есть первый вариант плана. Самое время оценить осуществимость такого плана. На данном этапе, конечно,
рано выполнять подсчет затрат на весь проект. Требования совсем «сырые». Однако, имеет
смысл пересмотреть список стейкхолдеров. В частности, существуют стейкхолдеры, связанные
с системами в операционном окружении, от которых очень сильно зависит успех проекта. Как
видно из рисунка 7, целевая система взаимодействует с системами обеспечения комфортных
внутренних условий (вентиляция, отопление, увлажнение и проч.) и системами обеспечения
сервисов (санузлы, эскалаторы, центры печати и проч.). Наша «коробочка с проводами» начнет
использоваться только тогда, когда будет подключена ко всем требуемым системам в операционном окружении. Если отталкиваться от того, что валидация должна выполняться на предмет
удовлетворения потребностей стейкхолдеров, то становится не очень понятно, как это сделать,
когда система еще не встроена в использующую систему, но уже произведена и должна быть
продана, чтобы компенсировать затраты на производство. Валидация, с точки зрения системной инженерии, возможна лишь в условиях эксплуатации (или максимально приближенных)
и должна проводиться с участием пользователя и заказчика.
Если вы проектируете «коробочку с проводами», а ваша компания
не планирует выполнять монтажные работы, потому что это другой бизнес, то,
выходит, вы не можете гарантировать удовлетворение потребностей в рамках
текущего проекта.
Получается, что успешность нашей системы зависит от того, как сработают еще две
группы стейкхолдеров, относящихся к системам обеспечения сервисов и к системам обеспечения комфортных внутренних условий (среды). Это огромное количество различных стейкхолдеров, занимающихся эскалаторами, принтерами, кондиционерами, инженерной инфраструктурой, проводкой и т. д. Их то мы и забыли включить в таблицу 3. Надо это обязательно сделать.
Тем не менее проблема зависимости от этих стейкхолдеров в вопросе успеха «коробочки»
остается нерешенной. Как выполнять валидацию? Валидация – это практика жизненного цикла
системы. Может быть, сейчас правильнее задать вопрос – а какой у целевой системы жизненный цикл?
Определите основную функцию целевой системы, выделяющую ее среди других систем
в операционном окружении. Определите использующую систему, найдите стейкхолдеров
на уровне использующей системы. Свяжите потребности с входами и выходами использующей системы, а требования – с входами и выходами целевой системы.
24
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 4. Жизненный цикл системы и проекта
Конечно, менеджеры к этому моменту уже должны были согласовать жизненный цикл,
но есть ли в нем валидация? Обычно менеджеры без особых проблем решают организационные вопросы с помощью модели жизненного цикла. Часто его выбирают исходя из опыта
управления и не ждут сюрпризов, но сейчас возникла ситуация, в которой успех целевой
системы «повис на волоске» из-за неоднозначности приемки и валидации, а это, между прочим, непосредственно относится к модели жизненного цикла, то есть инженерные и менеджерские задачи теперь неразделимы.
Допустим вы пойдете к менеджеру проекта и попросите показать выбранную модель жизненного цикла. Самое частое представление, которое я наблюдал на практике в ИТ-компаниях,
может быть изображено так (рис. 8).
Рис. 8. Типовой жизненный цикл проекта
Часто проект не любят официально заканчивать. Вообще, у нас понятие проекта иногда
имеет под собой какой-то мистический смысл. Ну и, как следствие, есть путаница между жизненным циклом проекта и жизненным циклом системы. В результате, а где, вообще, в жизненном цикле – валидация целевой системы? Если бы всё было так просто – взять и перерисовать
этот жизненный цикл – но проблемы заключаются в деньгах.
Каждая стадия жизненного цикла имеет свой бюджет, во многом
связанный с различными интересами вполне конкретных стейкхолдеров.
Добавить еще одну стадию – забрать деньги из другой.
Рис. 9. Типовой вариант спирального жизненного цикла проекта
Вам могли показать другой вариант жизненного цикла, например как на рисунке 9. Спиральный жизненный цикл часто используют в индустрии программного обеспечения и информационных систем, даже чаще, чем это официально преподносится. Идея такого жизненного
цикла предельно проста. Каждый виток – полный набор стадий от замысла до, иногда, продажи и сопровождения. Переход на новый виток выполняется в том случае, когда завершенный
виток был успешен и есть благоприятный прогноз развития проекта. Обычно каждый новый
25
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
виток значительно дороже предыдущего, разрабатываемый функционал шире, сама система
сложнее. Вопрос в том, сколько должно быть приемок и валидаций в таком жизненном цикле?
В целом, впечатление от знакомства с жизненным циклом проекта
у любого инженера обычно сумбурное и смутное, как будто речь идет не о том,
чем занимается инженер, а о какой-то другой реальности. Это очень плохо,
когда так происходит.
Часто валидацию осуществляют путем имитации условий эксплуатации. Например,
чтобы выполнить валидацию двигателя, надо где-то взять несколько автомобилей, соответствующих выявленным потребностям, вставить туда новые двигатели, провести тесты, то есть поездить на этих автомобилях, проанализировать результаты, подвести итоги.
То же самое, с точки зрения системной инженерии, нужно сделать и для вашей «коробочки умного дома». Надо где-то взять несколько домов, соответствующих выявленным
потребностям (то есть это будут бизнес-центры определенного класса), вставить туда ваши
«коробочки», подключить, провести тесты, проанализировать результаты, подвести итоги.
В процессе валидации обязательно должны участвовать люди, поэтому надо быть готовым
к обработке анкет. Все это довольно масштабное мероприятие, порой даже самое дорогое
в проекте.
Если не обговорить необходимость в таких крупных затратах «на берегу», что остается делать в середине проекта? Можно просто сделать «коробочку», а потом продавать её –
сразу. Как вы думаете, если сделать новый двигатель, пропустить стадию испытаний на разных,
например, автомобилях, и сразу выставить продукцию на продажу – будет ли проект успешен?
Какие могут быть последствия от выбора такого жизненного цикла? Самое время обсудить
проектные риски с руководством.
Системному инженеру было бы интереснее взглянуть на модель жизненного цикла такого
рода (рис. 10).
Рис. 10. Вариант совмещения жизненного цикла системы и жизненного цикла проекта
На представленном рисунке видно, насколько могут различаться жизненные циклы проекта и системы.
Жизненный цикл системы – это набор связанных процессов,
реализуемых одновременно, а жизненный цикл проекта – разовая
последовательность работ. Проект – это, как бы, один проход через полный
или частичный жизненный цикл системы.
Самый главный вопрос, который возникает при просмотре этой диаграммы, заключается в том, когда должен закончиться проект? Это любимый вопрос менеджеров проектов,
отводящий нас к цели проекта. Хорошие менеджеры обычно планируют заработать денег
на проектах, благодаря чему они отлично знают, когда нужно остановиться. Но это далеко
26
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
не всегда так. Бывают случаи, когда проект перерастает в другой проект, в новый процесс,
в программу, а иногда он просто кончается, порой внезапно. Прогнозировать подобные исходы
весьма затруднительно, поэтому инженеру нужно стараться всегда делать системы как можно
лучше. Используя наработки по успешным системам, гораздо проще инициировать новые проекты.
Менеджер будет стараться экономить деньги. Инженер должен стараться
сделать систему лучше, а для этого потребуются дорогие материалы, модули,
участие экспертов. Валидация может стать корнем раздора между менеджером
проекта и системным инженером, особенно когда системный инженер
подключается к проекту не с самого начала, потому что уровень затрат
на валидацию может стать сюрпризом для менеджера.
Между делом выяснилось, что группа специалистов уже давно проектирует
умный бизнес-центр без вашего участия. Так получилось, что ваша работа проистекает
в команде менеджера проекта и отвечаете вы за документацию, а настоящая разработка идет
в другой комнате третий месяц подряд – возможно даже она началась до формальной инициации проекта. Ваша реакция?
Скажем так, это неплохо, когда разработка и концептуализация идут параллельно.
Плохо – когда они не связаны между собой в рамках проектирования. Само слово «проектирование» в России имеет несколько значений:
– чаще всего это слово означает любую работу на бумаге, включая концептуальный этап,
разработку инженерных решений, иногда даже работу конструктора;
– иногда под проектированием понимают именно написание документации;
– редко, но встречается такой вариант, когда проектирование смешивают с управлением
проектом, что нас, как системных инженеров, не устраивает.
Путаница связана с тем, что слово «проект» можно перевести на английский как project
и как design. Когда я буду говорить про проект, я обычно буду иметь в виду project, а под проектированием я буду понимать design, при том я буду понимать под проектированием любую
работу на бумаге (в компьютере), предшествующую непосредственному изготовлению изделия. Если изделие изготавливается в процессе проектирования – будем называть это конструированием. Если изделие изготавливается серийно, когда проектирование завершено – это уже
производство.
Итак, группа специалистов уже запроектировала «коробочку с проводами», которая оперирует набором условий типа:
«Если (выполняется комплекс условий по входам), то (выходной вектор
преобразуется по определенным правилам)».
Многие специалисты искренне не понимают, зачем нужны системные специалисты, ведь
и так всё понятно, что надо делать. С точки зрения группы специалистов – этот продукционный решатель является, собственно говоря, конечным продуктом. Ну и чего же в нем не хватает? Даже не важно на каком уровне решена задача: микросхемой, программным обеспечением, либо, вообще, механически или гидравлически. Самое удивительное на данный момент
заключается в том, что эти специалисты собрали готовый, с их точки зрения, продукт, когда мы
с вами еще только обдумываем жизненный цикл системы. Упрекать их в этом, конечно, нельзя.
Вас не должна пугать параллельность в работах. Для того, чтобы уместить в голове такой
жизненный цикл и управлять им, используйте горбатую диаграмму (рис. 11).
27
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 11. Горбатая диаграмма жизненного цикла проекта
На горбатой диаграмме представлены распределения человеко-часов по стадиям и практикам жизненного цикла проекта. Практика разработки концепции применяется на стадии
исследований и немного захватывает разработку. Инженерия требований идет с некоторой
периодичностью вплоть до производства итерациями согласований. Архитектура обычно прорабатывается «большим горбом», потому что изменение архитектуры ведет к непредсказуемым последствиям – прорабатывают один раз и надолго. Дизайн, изготовление, сборка
и проверка идут взаимозависимыми колебаниями довольно часто, поскольку речь идет о постоянном выпуске прототипов (опытных образцов). Валидация выполняется в конце разработки
(в т.ч. имитационно).
Надо понимать, что между стадиями жизненного цикла есть интервалы времени (гейты)
для принятия решения о переходе на следующую стадию. В этом, собственно, и состоит смысл
планирования, чтобы расставить интервалы (гейты) принятия решений. Как правило, следующая стадия дороже предыдущей, поэтому решение принимается долго, иногда дольше самой
стадии. Системный инженер должен это понимать, и читать планы проектов и диаграммы жизненного цикла правильно.
Часто реальная продолжительность стадии жизненного цикла вдвое
меньше запланированной именно из-за согласований, которые «сжирают»
основное рабочее время.
Вот, вы пришли к руководителю проекта и начали тяжелый разговор:
– Ингеборг Карлович, есть несколько проблем.
– Каких? – недовольно пробурчал менеджер проекта.
– Во-первых, у нас не налажены отношения со стейкхолдерами, поэтому все время меняется концепция продукта, из-за этого невозможно составить список адекватных требований и,
вообще, непонятно что мы делаем в конечном счете. Как мы поймем, что система будет сделана правильно, если у нас даже не запланированы затраты на валидацию? Какой реальный
срок проекта? Какая цель? Кто, вообще, ставит задачи команде? Почему так получилось, что
я еще пишу требования, а разработчики уже паяют там что-то в своей коморке?
– Так… – растянул Ингеборг Карлович, почесав затылок, – ты у нас системный аналитик.
Вот и отвечай, почему такой бардак происходит? Чтобы завтра к обеду у меня на столе лежало
техническое задание на умный бизнес-центр, понятно?
Как вы, наверное, уже догадались – так разговор начинать нельзя.
Предположим, что прошлый разговор вам приснился в страшном сне,
а настоящий разговор будет только сейчас.
– Ингеборг Карлович, есть несколько предложений.
28
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Каких? – безучастно пробурчал руководитель проекта.
– Давайте добавим в планы по проекту валидацию системы.
– Зачем? У нас же есть стадия разработки. Там предусмотрены различные проверки.
– Там не предусмотрены испытания нашей программно-аппаратной системы внутри
самого бизнес-центра.
– Какого бизнес-центра? – удивился руководитель проекта.
– Ну мы ведь должны ориентироваться на определенный класс бизнес-центров. Чтобы
выпустить продукт, нам нужен хотя бы один успешный кейс.
– Так вы сначала сделайте систему, – улыбнулся Ингеборг Карлович, – потом мы её продадим и проверим.
– А если она не заработает?
– А это уже ваша работа – чтобы она заработала.
– Тут не поспоришь, – промелькнуло в голове.
В этот момент становится отчетливо понятно, что внедрение системной инженерии
на предприятии зависит не только от наличия системных инженеров. Теоретически можно
попытаться держать в голове менеджерский жизненный цикл и системно-инженерный жизненный цикл одновременно, отдавая себе отчет, что стадия продаж – это, на самом деле, производство, где, как бы, заложены приемочные испытания (и валидация).
Реальная проблема заключается в том, что руководитель проекта сказал фактически следующее:
– Сделайте что-нибудь, а мы потом это как-нибудь продадим, чтобы убедиться, что вы
сделали именно то, что надо.
Когда дело касается сложных систем, в том числе информационных,
порой становится сложно понять, что происходит в проекте. Так или иначе,
всегда есть хорошая аналогия между ИТ-проектом и строительным проектом.
Сейчас самое время воспользоваться такой аналогией со стройкой. Если бы Ингеборг
Карлович был руководителем проекта по строительству жилой многоэтажки, то его слова звучали бы так:
– Вы мне спроектируйте нормальную жилую многоэтажку, да так чтобы я ее мог воткнуть
в любую инфраструктуру на любой местности, в любом районе, независимо от класса жилья –
там же все одинаково, а потом мы ее будем всем продавать. Когда продадим первую, вторую,
третью – построим все по-быстрому и проверим, хороший у вас проект или нет.
Есть такие руководители, которые действительно не понимают, почему у них проблемы
случаются. Некоторые искренне верят, что все делают правильно. Конечно, крупные компании
с большим опытом порой выделяют инвариант среди своих продуктов и переходят на платформы, получая линейки продуктов. Что же делать системному аналитику в случае, когда речь
идет об универсальной разработке с бюджетом разового проекта, которую, кроме всего прочего,
собираются выводить на конкурентный рынок? Я бы сказал так – без вас этот проект завалят.
Давайте спасать.
Используйте практики и стадии для моделирования жизненного цикла проекта
и системы, чтобы оценить реалистичность проекта и возможность воплотить успешную
систему. Четко определяйте периоды принятия решений между стадиями жизненного цикла.
Помните, что стадии жизненного цикла разделяются гейтами, которые, порой, занимают
много времени.
29
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 5. Бизнес-анализ
Проектировать какой-то умный дом, который внезапно стал умным бизнес-центром,
в бурлящих условиях всеразличной деятельности стало совсем невозможно. Кто-то вам чтото сказал, кто-то дал какие-то документы, переслал письма, а что-то вы нашли сами, но все
это время было непонятно, кому это все реально надо. Есть несколько легенд, какие-то идеи,
мнения – больше ничего.
Чтобы работать дальше, вам нужны реальные стейкхолдеры, а не те люди,
которые ими притворяются.
Все что вы действительно знаете о проекте наверняка – его финансирует директор компании. Человек вряд ли станет тратить свои деньги на ветер. Есть еще собственники компании,
о которых вы ничего не знаете, но можете узнать через директора. Надо идти к нему.
Встретиться с директором гораздо проще, чем кажется, если компания ведет деятельность. Сложности чаще возникают с менеджерами среднего звена. Допустим, вы узнали у коллег, где кабинет директора, и направились прямо туда. Секретарша спросила:
– Как вас представить?
Далее даже не важно, что вы ответили. Например, что-нибудь типа:
– Это по поводу умного дома, то есть бизнес-центра. По проекту.
Через какое-то время вас пустят в кабинет директора. Топ-менеджеры бывают разные,
но их объединяет одно – цепкий взгляд. Итак, вы встали в центр кабинета директора.
– Слушаю внимательно, – сказал директор, не отрываясь от монитора.
– Я работаю системным аналитиком в проекте «умный дом», то есть «бизнес-центр».
К сожалению, на сегодняшний день я пришел к выводу, что проект спланирован неверно.
– Очень интересно, – ухмыльнулся директор, – а что по этому поводу думает Ингеборг
Карлович?
– Он со мной не согласен, судя по всему.
Вообще, это «стукачество». Вопрос этики здесь стоит в полный рост. Давайте постараемся рассудить с разных сторон. Сказать директору, что его менеджер не справляется с задачей, значит «ударить в спину» менеджеру. Следовало бы, пожалуй, вступить в спор с менеджером проекта, стараясь решить вопрос лично, либо переманить весь коллектив на свою сторону.
Так было бы честно. Но теперь вы «настучали» на начальника, в чем, кроме всего прочего,
просматривается еще желание его «подсидеть», что еще более мерзко. С другой стороны, если
подумать о том продукте, который будет сделан в результате всей этой деятельности, то его
успех напрямую зависит от квалификации членов команды, тем более руководителей.
Что важнее? Отношения внутри коллектива исполнителей или реальные
потребности будущих пользователей умного бизнес-центра (или еще чего-то
иного)?
– Что, собственно, не так? – спросил директор, наконец, отвернувшись от монитора.
– В проекте не учтены затраты на валидацию системы. Возможно, поэтому у нас нет
информации о том, куда именно будет встраиваться наш продукт. В итоге, мы проектируем
некий универсальный умный дом, но ни у кого из коллектива нет опыта проектирования подобных систем даже локального характера. Шансы на успех очень малы, поэтому я решил вас предупредить. Я не хочу работать в заведомо провальном проекте.
Директор немного помолчал и спокойно ответил:
– Такое действительно иногда бывает, но сейчас ситуация иная. Сейчас мы переживаем очередную волну экономического кризиса, поэтому спрос на нашу основную продукцию,
30
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
информационные системы, резко упал. Безработица растет, поэтому автоматизацией заниматься никто не хочет.
– А умный бизнес-центр, разве, не относится к автоматизации?
– Все верно, но в этом проекте иная, так сказать, мотивация. Здесь важно – кто платит.
Компания Наномегасвязь, например, и другие крупные сетевые компании используют кризис
в своих целях. Для них сейчас настало отличное время, чтобы создать новый рынок цифровых
сервисов, соединяющих мобильные устройства с инфраструктурой и оборудованием.
– Интернет вещей?
– Да, это он и есть, – кивнул директор.
– Можете тогда пояснить, какое место в этом деле отведено для нас?
– Нам нужно встроиться между крупной сетевой компанией и крупной строительной
компанией, – сказал директор таким тоном, будто ничего проще не придумаешь, и вопросов
после такого исчерпывающего ответа никаких возникнуть не должно.
Давайте сделаем паузу. В данной ситуации надо понимать, что директор говорит на своем
языке. Говорит очень нужные вещи, но этот язык не инженерный и не должен быть инженерным. Из его слов следует, будто бы нам надо придумать бизнес, а не систему. Придумыванием
бизнеса занимаются предприниматели, а не системные аналитики, поэтому нам следует предположить, что всё уже придумано. Потребности директора, как заказчика, мы записали уже
давно, но только после этого разговора становится понятно, что реально происходит. Самая
страшная ошибка, которую можно сделать именно сейчас, заключается в том, чтобы начать
допрашивать директора на тему конкретной инженерной задачи. Я предлагаю поступить иначе,
и сказать следующее:
– Мне для работы очень важно понимать бизнес-модель, которую вы планируете использовать по отношению к новому продукту.
– Хорошо, – растянул директор, видимо думая о чем-то параллельно, – Похоже, тебе
действительно нужно это понимать. Мы предполагаем, что компания Наномегасвязь сможет
сделать мощную систему управления для новых сервисов, тем самым заметно расширив свой
«личный кабинет». Основное назначение этой системы управления – экономить на потреблении ресурсов: вода, электричество, газ. На самом деле, смотря правде в глаза, сделать бы
хотя бы для электричества. На рынке уже сегодня огромное количество wifi-приборов. Некоторые умельцы самостоятельно делают себе умные дома. Все что сделает Наномегасвязь – монополизирует рынок за счет демпинга. Если через Наномегасвязь будет проходить вся информация со всех приборов, то эта информация окажется гораздо дороже, и покупатель на нее
найдется посерьезней.
– Это больше похоже на бизнес-модель Наномегасвязи.
– Да, это контекст. Вся техника на прилавках в скором времени будет с wifi, даже выключатели света, батареи, раковины и душевые. Потребители захотят управлять всем этим богатством, в том числе дистанционно. Станет очень легко проверить с работы, выключен ли утюг,
закрыто ли окно и многое другое. Можно будет разогреть суп или сварить кофе к своему приходу. При этом потребители будут точно знать, за что платят квартплату, смогут оптимизировать свои расходы. Рецепты можно будет скачивать сразу в мультиварку, фотографии с телефона перекидывать на телевизор в один клик… Учитывая тот объем данных, который будет
поступать с датчиков, Наномегасвязь возьмет на себя, в первую очередь, роль хоста. Они сделают некую панель управления, но… они не смогут самостоятельно разработать все необходимые сервисы – их слишком много. Тем более, многие сервисы будут завязаны на конкретное оборудование. Наш бизнес – готовые пакеты решений для бизнес-центров. Мы покупаем
у Наномегасвязи хостинг, базовые сервисы управления ресурсами, покупаем у поставщиков
wifi-оборудование и делаем удобные красивые панели управления под конкретные задачи,
а потом продаем это всё «под ключ». Такая бизнес-модель.
31
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Сейчас самое время попросить листочек и начеркать схемку, по которой еще раз уточнить, всё ли понято правильно. Директора такая просьба может удивить. Надо обязательно
аргументировать важностью вопроса. Некоторые начальники сами любят все рисовать. Тут
не угадаешь. Либо секретарша принесет листочек, либо директор достанет оборотку. Давайте
изобразим этот самый контекст, пока «железо горячо», используя формализм функционального моделирования.
Рис. 12. Функциональная модель бизнес-контекста целевой системы
На рисунке 12 овалами обозначены функции, которые выполняют предприятия в рамках
общей бизнес модели. Черным цветом выделены функции, которые с точки зрения директора,
должна взять на себя ваша компания. Стрелками обозначены акты передачи продуктов и оказания услуг, которые должны быть предусмотрены договорами. Маршрут движения денежных
средств на данном этапе предсказать затруднительно. Возможно, деньги пойдут в обратном
направлении относительно актов. Может быть, всем заплатит тот, кто планирует использовать
бизнес-центр. Для нас это сейчас не так принципиально, но с точки зрения системной инженерии очень важно разделить два представления. На одном – мы показываем «как работает»
рассматриваемый бизнес-контекст, а на другом можно показать, какие есть варианты организации бизнес-контекста. Когда мы будем говорить уже не о функциях, а о структуре, предлагаю
использовать прямоугольники вместо овалов (рис. 12). Овалы напоминают нам об абстрактном
уровне сущности, а прямоугольники выглядят более конкретно, как блоки.
Рис. 13. Структурная модель бизнес-контекста целевой системы (маловероятный вариант, приближенный к функциональной модели)
На структурной модели стрелкой обозначаются интерфейсы между структурными элементами. В данном случае, стрелка – это договор, а направление стрелки отражает направление денежного потока.
32
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 14. Более реалистичный вариант структуры бизнес-контекста целевой системы
Схемы на рисунках 13, 14 относятся к стилю логической бизнес-архитектуры. Если вместо названий блоков вставить названия конкретных организаций, получим стиль физической
бизнес-архитектуры. Чтобы не потерять связи между функциями и структурой, заполняют матрицы соответствия. Пока элементов немного, отложим это дело.
Очень важно помнить, что на одну функциональную модель может быть
несколько логических архитектур, а на каждую логическую архитектуру –
несколько физических архитектур.
Директор скорее всего посмотрит на схемы «с высока», но даже если у него не возникнет
никаких замечаний – это прекрасно. Идеально, если он почеркается на бумажке вместе с вами.
На бумаге все становится очевидно, и, если вопросов нет, этого достаточно.
Самое время спросить:
– А Наномегасвязь не сможет сделать пакеты готовых решений для бизнес-центров?
– Если мы всё сделаем быстро и хорошо, – тут директор сделал длинную паузу, – им будет
проще купить решение у нас, либо купить часть компании.
– Понятно. А мы можем все-таки как-то учесть валидацию?
Конечно, директор мог бы разозлиться на вашу назойливость, но ведь дело касается его
кошелька.
– Мы всё можем. Нужны конкретные предложения, – отрезал директор.
К такому повороту разговора нужно быть готовым с самого начала.
– Нужен конкретный бизнес-центр, в который мы встроим свою систему, то есть конкретный заказчик системы.
– Ты имеешь в виду пилотный проект? – хитро улыбнулся директор.
– Не совсем. Ну, можно так сказать. Самое главное – нам нужны конкретные люди, которые оценят нашу работу еще до того, как мы выйдем на рынок с новым продуктов.
– Пилотный проект мы и так хотели делать. Я пока никаких проблем в планировании
не заметил. Если тебе нужны конкретные люди, подойди завтра в полтретьего ко мне в кабинет.
Я дам контакты, – подытожил директор и отвернулся к монитору.
Разговор окончен. Остается только кратко поблагодарить руководителя за выделенное
время и пойти на свое рабочее место. С первого взгляда может показаться, что директор просто
потерял время, разговаривая с вами, но это совсем не так. В ответ на ваши вопросы директор,
возможно, впервые сформулировал реальную задачу. Менеджеру действительно не принципиально, когда начинать пилотный проект, потому что с его точки зрения, если он не вникает
в техническую часть, разработка и пилот – это совершенно разные проекты с разными стейкхолдерами и командой, а поэтому сформулированную вами проблему директор, как и руководитель проекта, действительно не понял. Но в отличие от руководителя проекта директор
почувствовал в ваших словах какую-то скрытую угрозу, поэтому пошел навстречу, пообещал
передать контакты. Есть шанс, что никакого пилота не планировалось, но директор не мог просто так согласиться с критикой подчиненного. Завтра утром, вполне вероятно, срочно собе33
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
рут совет директоров и запланируют пилотный проект. Можно также предположить, что идея
работать сразу под пилот понравилась директору сокращением цикла разработок. Интуитивно
понятно, что если сначала что-то сделать, а потом адаптировать под пилотный проект, то это
будет дольше, чем сразу сделать пилот по требованиям партнеров.
Почему всегда так не делать? Вопрос хороший. Мне кажется, что
причина заключается в слабо развитых коммуникационных способностях
в некоторых компаниях, вездесущем недоверии, страхе проиграть.
Менеджер не пойдет договариваться с партнером, пока у него в руках не будет прототипа, а партнер не захочет ничего обсуждать, пока не увидит что-то работающее. При этом,
учитывая полную неопределенность такой ситуации в части ожиданий и требований, критерий,
по которому будет принято решение о сделке, скорее касается некой научной школы, чем самой
«поделки». Может быть, проще показать список публикаций или портфолио? На моей практике многие компании действительно просят сделать демонстрацию продукта еще до составления технического задания на его покупку, понимая прекрасно, что продукт будет разрабатываться под них почти «с нуля». Конечно, это связано еще с тем, что поставку организовать
проще, чем разработку. И времени на поставку будет месяца три. Формальности необходимо
соблюсти. Возможно, поэтому все так любят говорить о платформах.
С точки зрения системной инженерии, платформа – это просто
универсальный модуль, с использованием которого можно производить
линейку продуктов.
Часто под платформой понимают некую сверхсущность, которая способна генерировать
коммерческие продукты за 3 месяца. Такого не бывает. Даже если фирма продала что-то, сгенерированное за три месяца на самопальной платформе, то в эксплуатацию это что-то полноценно войдет через пару-тройку лет. Все это понимают, но продолжают требовать прототипы и платформы, прежде чем начать разговор о реальной задаче. Если кто-то решил делать
«с нуля» новую платформу, то, скорее всего, дело кончится бесполезной безделушкой. Реальные платформы выделяют из множества конфигураций как инвариант, и потом долго думают,
как изменится схема интеграции/сборки зависимых продуктов.
Проектирование умного бизнес-центра без валидации фактически означает, что результатом работы будет стопка чертежей.
Программный код – это тоже, своего рода, чертежи. Программа – это
не система, а ее описание.
Если вы работаете над программной разработкой, системная инженерия начнется только
тогда, когда вы задумаетесь о тех компьютерах, на которых будет «крутиться» ваш софт, проводах, которые их соединяют, принтерах, мониторах, клавиатурах, людях, которые пользуются
софтом – по чему можно постучать или на что показать пальцем.
Уже сейчас становится понятно, что директор видит систему совсем иначе, чем те же
разработчики, которые доделывают свой прототип. Возможно, партнеры скажут еще что-то
интересное. Умный бизнес-центр, который вам нужно спроектировать, может оказаться чемто неожиданным. В XXI веке не пытайтесь проектировать системы, исходя из их объективных
функций. Нет никаких объективностей в сложных системах. 50 лет назад можно было спроектировать, например, просто автомобиль, и он бы продавался, но сейчас уже нет ничего простого даже на потребительском рынке.
Умный бизнес-центр – это уже точно не система оптимизации расходов, потому что
такую систему делает Наномегасвязь. Речь идет о некотором промежуточном звене между
Наномегасвязью и заказчиком, при том не только на этапе интеграции, но и на этапе эксплуатации бизнес-центра. Надо узнать, какое промежуточное звено потребовалось заказчику биз34
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
нес-центра, либо уже начинать думать о том, что реальный заказчик – Наномегасвязь. Нет
смысла проектировать архитектуру системы, пока нет ясности в этих вопросах.
Очень важно посмотреть на систему глазами стейкхолдеров, найдя их реальные интересы и «зацепившись» за них. В том случае, когда ситуация по проекту неоднозначна, реальные
задачи недоопределены, не нужно боятся прояснять ситуацию напрямую с заказчиком. Всегда
выходите на реальных стейкхолдеров с реальным интересом именно к системе, а не только
к зарплате. Один и тот же стейкхолдер «заказчик» может быть представлен разными
людьми. Стейкхолдер, выдающий себя за заказчика, может оказаться даже исполнителем.
35
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 6. Совещание со стейкхолдерами
Допустим, некоторым хитросплетенным путем вы вышли на совещание с заказчиком
конкретного бизнес-центра. Ваш директор поучаствовал в переговорах и свел вас, заказчика
(который будет использовать систему и платит основные деньги), инвестора (который дает
заказчику деньги на инновационную часть проекта) и поставщиков услуг «умного поведения» (в данном случае – менеджер из Наномегасвязи). Участники собирались в большом зале
для совещаний. Войдя в зал, вы, конечно же, поздоровались с присутствующими вслух без
рукопожатий, и дали каждому по визитке, получив визитку в ответ – такой ритуал. Отметим для художественной выразительности, что зал был полностью глянцево-белый: с белой
встроенной техникой, белыми стульями, столами, белыми роллами на окнах. Даже ноутбуки
у всех участников совещания были белыми. Заказчик, Александр Сергеевич, был в черном
повседневном пиджаке поверх растянутой яркой футболки с большим круглым воротом, рваных укороченных джинсах и розовых кедах на голую ногу. У него отовсюду торчали черные
волосы и бороду с усами он носил как-то особенно небрежно, хотя аристократические черты
лица превращали всеобщую неряшливость в то, что называют look (или «образ», по-русски).
Несмотря на то что Александру Сергеевичу было уже около пятидесяти лет, внешний вид его
не казался нелепым, как это часто бывает в подобных ситуациях. Просто, такой вот человек.
Рядом сидел представитель инвестиционного фонда, Джон Берри. Это был американец, проживший в России много лет. Джону было около шестидесяти. На нем была клетчатая немного
помятая рубашка, тоже джинсы, но без стилистических повреждений, кроссовки и круглые
очки, настолько увеличивающие его глаза, что они не входили в оправу. Джон сидел сложа ногу
на ногу все совещание. Менеджер из Наномегасвязи пришел последним. На нем был синий
дорогой костюм, красный галстук, белая рубашка. Он извинился непонятно за что и занял
место за столом. Все были в сборе.
Александр Сергеевич прервал тишину легким покашливанием и, направив взгляд в окно,
начал говорить, будто продолжая ход своих мыслей, который все остальные, по его разумению,
должны были как-то телепатически слышать до этого:
– И вот вы заходите после тренировки в душевую. Все было бы чудесно, но вода в душе
все время не такая, как вы привыкли у себя дома. И этот смеситель слишком сильно реагирует
на любые движения: то горячо, то холодно. И вот вы приняли такую позу, чтобы рукой дотягиваться до смесителя, но всем телом отстраняетесь от лейки. Как глупо…
Все участники совещания внимательно слушают заказчика, пытаясь понять, к чему это
он говорит.
– Но у нас будет не так, – отрезал Александр Сергеевич, – Вам достаточно запомнить температуру воды, которая вам нравится. Вы заходите в душевую, с помощью сенсорного экрана
вводите свою температуру, напор, если хотите, и нажимаете кнопку. Умная система не пускает поток сразу в лейку. Сначала она последовательно настраивает температуру и напор в служебном контуре, и только потом душ дает желтый предупреждающий сигнал (скоро польется
вода), а затем зеленый. И вы сразу получаете то, что хотели. Это займет всего несколько секунд.
Понимаете? Это очень просто.
– Александэ Селгеевич, – не без акцента произнес Джон, – Вы абсолютно правы. Это
фантастика.
– Александр Сергеевич, – перебил менеджер Наномегасвязи, – Наша компания может
воплотить это в жизнь, но, я думаю, нам нужно конкретизировать список таких сервисов.
– Опять вы о своем, – брезгливо отмахнулся Александр Сергеевич, – Это ваша задача.
Составьте мне список! Я хочу знать, сколько это может стоить!
36
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Разработка технического задания стоит у нас около трех миллионов дукатов, – не уступал менеджер.
– Александж Селгеевич, – снова попытался начать американец, – У нас есть еще один
участник совещания. Мне сообщили, что он мог бы заняться концепцией.
Все оценивающе посмотрели на вас. Вам надо теперь сказать что-нибудь кстати, например:
– Да. Мы готовы поучаствовать в этом проекте на стадии концепции… и потом тоже
готовы.
Александр Сергеевич бросил недоверчивый взгляд на Джона, а потом на вас.
– Мне важно, чтобы те затраты, которые выходят за рамки моего бюджета, покрыл
фонд, – пояснил заказчик, – Я не смогу доверить проект вашей небольшой компании, но, если
вы сможете получить финансирование от фонда, ваше участие в проекте я обеспечу.
Самое время спросить:
– А что вы в таком случае понимаете под концепцией?
В этот момент менеджер Наномегасвязи захихикал.
– Хороший вопрос, – кивнул американец, – Думаю, правильнее было бы сказать, что
от вас требуется заявка на финансирование по форме фонда. Я вам эту форму предоставлю или
вы сами ее можете найти на сайте. Эта заявка, по сути, и есть концепция, за которую требуют
деньги в Наномегасвязи.
– Они ничего не будут делать. Просто выкатят типовое ТЗ, – пояснил Александр Сергеевич. Менеджер в костюме нахмурился. После неловкой паузы, Джон продолжил:
– Александр Селгеевич, не могли бы вы, в таком случае, рассказать хотя бы вкратце
нашему коллеге, что вы хотите от этого умного бизнес-центра?
– Конечно. Я хочу суперсовременный бизнес-центр. Вы, наверное, уже поняли из моего
примера, как это должно чувствоваться. На самом деле, сейчас в России очень выгодно открывать бизнес, особенно зарубежным компаниям. Вы сами понимаете – это дешево. При этом русские любят тратить последние деньги на роскошь. Чудесная черта. Чем заманить иностранцев?
Комфортом, конечно. В моем бизнес-центре будет всё, чем только можно порадовать избалованных гостей. При этом, что очень важно, в отличие от русских, мои клиенты очень экономны. Они не знают местных тарифов. Им нужно понимать за что они платят деньги вплоть
до каждого прибора. Вот вам электричество, а внутри есть освещение, чайник, кондиционер –
всё посчитано. Даже графики эксплуатации нарисованы. Вот такая безумная смесь экономии
и комфорта, да-да. Мне тоже надо экономить, потому что центр обойдется мне недешево. Надо
посчитать, сколько будут стоить все эти навороты, потом посчитать, сколько я буду экономить
на этом умном поведении в год. Если мое предложение по аренде будет не сильно дороже среднерыночного, то тогда это имеет смысл. Умный душ за те же деньги, что и глупый – выглядит
заманчиво, хе-хе, а вот переплачивать за умный душ мало кто решится.
– То есть вся эта умная система нужна только для того, чтобы эффектно выглядеть?
– Все равно, главное – экономия. Если эта ваша система позволяет экономить деньги, мне
надо понимать, сколько именно? Просто, знаете, признаться в желании сэкономить не каждый
захочет. Тут такая игра: покупаешь ради комфорта, а на самом деле – экономишь.
– Не забывайте, что есть интерес стратегического характера, – вставил слово менеджер
Наномегасвязи, – Нам нужна информация со всех приборов.
Джон Берри дождался, когда возникла секундная пауза, и увесисто произнес:
– Условия фонда таковы, что вам нужна будет действительно инновационная идея. Если
интеллектуальная собственность защищена, то все будет проще, а если нет – придется срочно
защищать. У вас, я так понимаю, совсем все на начальном уровне. В общем, проблема в том,
что времени очень мало.
37
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Проектирование бизнес-центра начнется через полгода. Если вы не успеете получить
финансирование на этот проект, я буду строить обычный бизнес-центр. Мне некогда ждать, –
объяснил заказчик.
– Фонд не сможет профинансировать ваш проект сразу на такой сырой стадии, – продолжил Джон, – Вы должны очень быстро начать защиту вашей интеллектуальной собственности. В принципе, фонд может вам помочь с этим, но ведь вопрос в том, а есть ли у вас эта
интеллектуальная собственность? Откуда она возьмется за полгода? Через три месяца нужна
готовая заявка на патент и готовая концепция системы, в которой используется ваше изобретение. Но изобретение должно быть очень существенным, чтобы комиссия пропустила проект
на стадии заявки.
Немного помолчав, Джон продолжил:
– Чем больше грант или приз, тем меньше вероятность случайных победителей. Учитывая, что мы хотим профинансировать крупный строительный проект, вы должны понимать, что
это не лотерея, однако никто не возьмется за ваше продвижение, если не будет уверен в отдаче.
Уважаемый читатель, здесь я хочу раскрыть одну очень важную деталь. Многие говорят про конкурсы и гранты, будто в них «всё куплено». Опыт показывает, что это, действительно, почти всегда так и есть, но с важной оговоркой. На самом деле, конкурс начинается
задолго до мероприятия и до официального объявления конкурса. Обычно на момент задумки
конкурса уже есть потенциальные победители, а смысл инвестирования в этих потенциальных
победителей состоит только в том, чтобы потом заработать денег на них же.
Конкурсы выигрывают не те, кто лучше всех справляется с конкурсной
задачей, а те, кто способен отработать в последствии вложенные деньги.
Это касается любых конкурсов: музыкальных, танцевальных, конкурсов красоты, научных, инженерных, даже спортивных. Во всех вариантах конкурсов организаторы, имея информацию о всех участниках, стараются выстроить мероприятия так, чтобы победили конкретные
участники. Сейчас вы оказались в роли того самого фаворита, но подумайте, как много работы
нужно будет провернуть, чтобы пройти этот путь. Не исключено, что у них есть несколько
таких фаворитов.
Когда призовой фонд невелик, больше смотрят на самого конкурсанта,
но если деньги большие – смотрят на тех, кто стоит за конкурсантом, кто его
продвигает.
Совещание подходило к концу. Участники поблагодарили друг-друга за участие и начали
расходиться. Менеджер из Наномегасвязи остался недоволен совещанием. Проходя мимо Вас
в коридоре он пробурчал:
– Очень умно. Вы бесплатно напишете для нас техническое задание, а потом вас выкинут
из проекта.
Выходя на улицу после таких совещаний, как-то особенно приятно дышать свежим воздухом, смотреть на деревья, дома и даже на машины. Весна была в разгаре. Грязь к полудню уже
высохла, городская пыль еще не накопилась в воздухе после ночного дождя, солнце грело, ветерок приятно обдувал. Немного посидев на скамейке в центре города, вы направились в офис
докладывать директору. Чтобы объяснить директору ситуацию, было бы неплохо самому, для
начала, разобраться. Как нам уже известно, рисование схем прекрасно помогает разобраться
в сложных ситуациях. Потратим несколько минут, чтобы почеркаться на бумажке (рис. 15).
38
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 15. Схема взаимодействия стейкхолдеров (первый вариант)
Допустим, в таком виде вы и принесли схему директору, чтобы объяснить ситуацию. Он
посмотрел, подумал и задал резонный вопрос:
– То есть, выходит, нас могут запрячь выполнять всю работу, а Наномегасвязь будет
деньги получать?
А потом, чуть помолчав, задал второй резонный вопрос:
– Или мы отдадим Наномегасвязи концепцию, и они нас после этого пошлют подальше?
– Но сейчас мы работаем за свой счет безо всякой реальной задачи… не лучше ли иметь
шанс заработать денег или хотя бы понимать реальные потребности?
– Согласен, – пожал плечами директор, – Мы все равно платим зарплату.
После очередной паузы директор сказал:
– Ну тогда на рисунке не хватает связей. Кто согласовывает работу между исполнителями
по системе и по объекту? Вряд ли заказчик будет этим заниматься сам.
– Возникает еще одна роль, которую нам придется взять на себя, если мы хотим добиться
успеха. Давайте нарисуем (рис. 16).
Рис. 16. Схема взаимодействия стейкхолдеров (второй вариант)
– Да, получается, что мы косвенно отвечаем за весь проект в целом, но формально выполняем только инновационную часть, связанную с каким-то изобретением.
39
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Значит, давай опишем такое изобретение, – предложил директор – чтобы оно вбирало
в себя все сразу. Иди, думай. Если по проекту тебе будут нужны люди, заходи. У Ингеборга
Карловича кого-нибудь позаимствуем на время.
Основная беда всех этих «умных» домов, приборов и всего этого
Интернета вещей, в первую очередь, в том, что до сих пор совершенно
не ясны их системные функции. У многих потребителей в связи с этим есть
интуитивное ощущение фейка, вполне оправданное.
Джон Берри вместе с Александром Сергеевичем, по сути, предложили вам придумать
эту функцию и оформить как изобретение. Директор одобрил такой подход. Если идея будет
хорошей, то фирме выделят деньги на работы.
Я бы предложил начать с анализа сценариев использования системы. Заказчик говорил
про настройку душевой кабины с помощью сенсорного экрана. Если все так будут делать, экран
быстро сломают, да и не удобно будет за каждым перестраивать заново. С другой стороны –
директор рассуждал про wifi-управление на расстоянии, про панель управления. Если бы
душевая кабина сама настраивалась как вам надо, когда вы только подошли к ней – это было бы
удобней и экономичней. То же касается и других приборов. Кофемашина, например, знает,
какой кофе вам нужно еще до того, как вы нажали на кнопку. Кондиционер знает, какой режим
вам нравится. Это вполне реально, если привязаться к смартфону или смарт-часам или еще
какому-нибудь гаджету, который удобно будет брать даже в душ, например к смарт-кольцу
(или чипу под кожей). Когда несколько девайсов знают, кому какой режим кондиционера нравится, то сам кондиционер (или его внешний интеллект) будет стараться найти компромисс.
Если кондиционер не сможет найти компромисс, то он так и скажет. Может быть, кого-то стоит
пересадить, чтобы всем работалось комфортно?
Итак, представим, что повсюду спрятаны датчики расстояний. Вы подходите к душу
и ваши водонепроницаемые часы (которые, видимо, теперь всегда у вас на руке, если еще
не вживлены под кожу) сами говорят вам:
– Хозяин, вы впервые пользуетесь функцией настройки душевой кабины. Введите удобным для вас способом желаемую температуру и напор.
Вы можете вручную настроить умный душ в соответствии со своими предпочтениями,
а потом сказать умным часам:
– Запомни. Теперь всегда так настраивай душ для меня.
Умные часы запомнят, и когда вы подойдете к душу в следующий раз, вам достаточно
будет сказать, чтобы душ включился, и тут же польется вода нужного вам напора и комфортной температуры. Пока люди пользуются смартфонами, надо предусмотреть в душевой кабине
место, куда можно было бы убрать телефон. Это будет вполне полезная техническая деталь,
сама по себе.
Аналогичный сервис можно продумать для кофемашины. Но в случае варки кофе, ваш
выбор, возможно, будет зависеть от настроения, поэтому при приближении к кофемашине,
ваш смартфон или часы предложат вам несколько вариантов. Самое важное здесь то, что разные приборы будут делать очень похожий кофе. Не одинаковый, конечно, в силу разных причин, но очень похожий, как вы любите. Если кофемашина дешевая и не может сделать, как вы
любите, она сама вам в этом признается и предложит альтернативу.
Итак, ключевая идея в персонализации работы умных приборов с помощью вашего
умного девайса, а также поиск компромиссных решений при обслуживании группы людей.
Учитывая интересы вендоров, у душевой кабины или кофеварки будут свои собственные приложения для дистанционного управления. Вопрос в том, что нужно от здания, чтобы оно потом
могло стать умным, наполнившись умной техникой? Определение расстояний между приборами сегодня можно считать решенной задачей, хотя эти технологии еще не используются мас40
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
сово. Остальное делают производители оборудования. Стандартизацией протоколов тоже уже
давно занимаются на достаточно высоком уровне.
Есть подозрение, что умный бизнес-центр станет умным уже только от того, что
туда поставят умную технику, а оптимизацию затрат обеспечит система Наномегасвязи. Те
панели управления, про которые говорил директор, похоже, сделают без вас… Думаю, самое
время отказаться от идеи большой системы управления. Изобретение, которое от вас ждут,
вовсе не обязано быть крупномасштабным. Оно должно быть соразмерно возможностям компании. Сейчас не так много производителей умного оборудования, поэтому стоит подумать,
какого рода умное оборудование больше всего пригодится в умном бизнес-центре и, просто,
получить деньги на его разработку.
Все быстро забудут свои желания проектировать непонятно что, когда
вы сделаете реальное предложение.
Итак, нам нужно выбрать, какую часть бизнес-центра мы хотим модернизировать. Учитывая, что устройство бизнес-центров хорошо известно, воспользуемся структурным анализом, а не функциональным (рисунок 17). Каждый прямоугольник на такой схеме соответствует
реальному объекту или деятельности, то есть имеет 4D-экстент. Такой вариант частного описания системы понятен многим стейкхолдерам и полезен при обсуждении концепции на совещаниях.
Надо понимать, что между структурными элементами существует множество горизонтальных связей, например, пропускную систему, очевидно, следует тесно интегрировать
с информационной. Впрочем, информационная система, видимо, будет основным интегрирующим звеном для всех других систем, особенно в «умной» концепции.
Рис. 17. Структурная декомпозиция бизнес-центра (фрагмент)
41
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Пора рассказать директору о том, чем вы занимаетесь, и спросить его мнение насчет
сужения тематики. Отмотаем время немного вперед. Скажем сразу, директор не был в восторге от вашего предложения.
– Какие у тебя конкретные аргументы, чтобы отказаться от проекта, который ведет
Ингеборг Карлович? – раздраженно спросил директор.
– Наномегасвязь сделают приборы для диспетчеризации ресурсов, только без проводов,
и сами для них создадут облачные сервисы на собственной платформе. У них нет никакого
интереса с нами сотрудничать в этой части. Специализированные умные сервисы для бизнес-центров, в основном, касаются поведения конкретного оборудования, а это значит, что
производители этого оборудования (особенно зарубежные) сами сделают «умное» ПО. Взаимодействие через смартфоны обеспечат производители смартфонов, а протоколы утвердят
на уровне международных организаций. Если мы хотим участвовать в создании Интернета
вещей, нам нужно сконцентрироваться на каком-то конкретном оборудовании, а не делать универсальную систему управления непонятно чем.
Директор внимательно слушал.
– Вот структурная декомпозиция. Если мы хотим участвовать в строительстве и обслуживании бизнес-центра, то нам нужно выбрать, какой прямоугольник – наш.
– Это всё, конечно, логично, – растянул директор, – но где на твоей схеме розетки
и выключатели?
– Розетки являются интерфейсами электрической системы с другими системами,
а выключатели, пожалуй, входят в электрическую систему.
– В общем, слушай, что я об этом думаю, – авторитетно начал директор после очередной
паузы, – Все эти связи с большими компаниями нужны нам только в качестве вспомогательных.
Я бы не стал делать на них такую ставку. Тем не менее, твоя работа с ними помогла мне понять
одну очень важную вещь. Мы действительно можем сделать маневр в плане позиционирования
на рынке.
Директор додумывал мысль на ходу. Он хотел побыстрее высказать идею, которая
пришла ему в голову, но никак не мог её сформулировать.
– В общем, все эти прожекты – о далеком будущем. Есть гораздо более понятный рынок
уже сегодня. Очень много людей перманентно делают ремонт. Они все время покупают себе
какие-то вазы, тумбочки, кресла, кровати, лампочки и многое другое. Магазины такого рода
постоянно переполнены людьми. Люди переезжают, покупают коттеджи и квартиры в центре.
Конечно, большая часть недвижимости остается «неумной». Это нормально. Но вот твои эти
разговоры про дистанционное управление навели меня на мысль, что через wifi, например,
можно было бы легко решить одну важную бытовую проблему. На самом деле, конечно, ее
решают и сейчас, но не так элегантно, как можно было бы, – тут директор остановился, проверил, что вы его еще слушаете, и продолжил, – Вот я собираюсь на работу. Опаздываю. Тороплюсь. И уже у выходной двери я не могу вспомнить (а я обувь то надел), выключил ли утюг,
свет и многое другое. Если бы на выходе висела такая сенсорная панель, на которой я бы мог
посмотреть, какие выключатели и розетки сейчас активны, да еще и с подписями… И если бы
такая конструкция работала без проводов… То есть я иду по торговому центру и вижу упаковку «Умный дом 2.0» или что-то вроде того. Стоит тысяч пять и туда входит набор розеток, выключателей (красивых) и некий управляющий планшет. Всё. Монтируется вручную без
специалистов… что еще? Есть приложение для мобильника, чтобы с работы проверять, когда
Интернет подключен. Я могу заменить свои розетки и выключатели, на планшете вписать, что
как называется, и вперед! Жена меня, просто, заставит купить такую штуку. Но важно, чтобы
всё это было красиво.
42
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Действительно, хорошая идея. И валидацию легко сделать. Можно, просто, всем сотрудникам раздать такие комплекты. Заодно собрать обратную связь от жен.
– И на рынок выводится элементарно. Достаточно договориться с ремонтно-строительным магазином, – добавил директор, радостно улыбаясь.
– Пожалуй, даже, всё можно изготовить самим, кроме планшетов, но это надо еще подумать, как будет дешевле. И уложимся ли мы в пять тысяч?
На ранней стадии проекта постановка задачи может существенно меняться. Любые
инструменты, облегчающие общение со стейкхолдерами здесь хороши. В нашем случае
помогла схема взаимодействий стейкхолдеров и структурный анализ. Главная задача системного инженера в такой ситуации – сводить все разговоры к четкой постановке задачи. Очень
часто ключевая идея рождается из сценария использования, однако вести разговоры только
на уровне идей долго нельзя. Главное, вовремя вцепиться в удачную идею и начать её воплощать: сначала в концепциях, потом в дизайне, а затем в реальности.
43
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 7. Системное проектирование
Несколько дней новая идея бродила по головам менеджеров вашей компании. Проводились совещания, принимались решения, оценивались риски. Менеджеры задались вопросом
сроков и стоимости. Чтобы рассчитать стоимость разработки системы, спланировать работы
и защитить проект перед руководством, нужно приступить к проектированию системной архитектуры. Это следующий шаг после разработки функциональной модели. Некоторая работа
по функциональному моделированию уже была проведена в главе 3. Давайте разберемся, что
изменилось в результате ваших совещаний со стейкхолдерами.
Во-первых, использующая система у нас теперь точно не дом. Да и функция системы
сейчас вполне понятна – мониторинг домашней электросети. Межсистемные связи будут такие:
– жилец получает от квартиры/дома комфортные условия проживания (его интересует
жилье в целом, а не электричество);
– квартира/дом выполняет свою функцию обеспечения комфортных условий проживания, используя электрическую систему в своем составе (этот тезис частично определяет
системную архитектуру жилья, поскольку является принципиальным инженерным решением
при возможных альтернативах);
– электрическая система выполняет свою функцию своевременного обеспечения электроэнергией.
Своевременность здесь играет ключевую роль, поскольку, например, ночью большинство
приборов должно быть выключено, а утюг и вовсе не должен работать постоянно. Если сделать
допущение, что жилец знает состояние электрических приборов, то системе достаточно функции ввода типа «вкл/выкл», что мы обычно и наблюдаем дома.
Идея. Электрическая система должна использовать систему мониторинга
домашней электросети в своем составе, чтобы лучше выполнять
свою функцию своевременного обеспечения электроэнергией. Улучшение
заключается в том, что снимается допущение об осведомленности жильца
насчет состояния электроприборов – человеческий фактор. В результате,
электрическая система работает более эффективно (только в нужное время).
Для осведомления жильца необходим дополнительный вывод информации.
В свою очередь, обеспеченная своевременность увеличивает комфорт жильца,
то есть улучшает выполнение функции всего дома/квартиры. Жилец не тратит
свое время на последовательную проверку электроприборов перед уходом.
Давайте попробуем изобразить эту связку с помощью немного усложненной диаграммы
вариантов использования (рисунок 18).
Рис. 18. Диаграмма вариантов использования системы дом/квартира с детализацией
до уровня целевой системы
44
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Теперь, наконец, можно построить функциональную модель новой целевой системы
(рисунок 19). В процессе разработки придется ее неоднократно менять. Сейчас на схеме
не отражены функции самих розеток и выключателей, которые входят в систему. Кроме того,
вопрос о необходимости интеграции со смартфоном через Интернет – непростой. Действительно ли достаточно визуализировать информацию, либо надо, все же, делать некий анализ?
Например, может быть полезно, чтобы система сама напоминала жильцу, что он не выключил
утюг перед уходом. Придумать можно очень многое.
Среди основных критериев принятия тех или иных инженерных
решений на столь ранней стадии я бы отметил затраты и зрелость
технологий.
Учитывая сложившуюся ситуацию, нам нужен минимальный функционал, достаточный
для того, чтобы вызвать интерес у потребителя. Определить этот минимальный функционал –
задача системного инженера.
Рис. 19. Функциональная модель системы мониторинга домашней электросети
(Ф – функции, С – связи)
Функциональная модель помогает обсуждать требования к системе. Касательно требований назначения можно сказать, что важной характеристикой является размер домашней
электросети. Сколько розеток и выключателей мы сможем охватить, используя беспроводное
соединение? Можно ли эту систему применять в бизнес-центре? Для принятия такого решения нам нужна информация о возможностях технологий. Можно параллельно рисовать логическую архитектуру (рисунок 20). Однако, очень не рекомендуется смешивать в одном представлении функциональную и архитектурную схемы.
45
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 20. Логическая архитектура системы мониторинга домашней электросети
(Б – блоки, И – интерфейсы)
Теперь, чтобы убедиться, что в логической архитектуре учтены все функции и связи,
нужно составить матрицу соответствия (таблица 6). Пока вы рисуете «на салфетках», не бойтесь совмещать функции и связи, а также блоки и интерфейсы на одной матрице, потому что
системные уровни поначалу могут быть выстроены нечетко, и функциональная связь запросто
может соответствовать не интерфейсу, а блоку,
Таблица 6. Матрица соответствия логической архитектуры и функциональной модели
системы мониторинга домашней электросети
По результатам анализа соответствия введены дополнительные функции и связи, которые
нужно добавить в функциональную модель:
Ф9 – обеспечить безопасное подключение электроприборов;
Ф10 – обеспечить безопасное замыкание/размыкание ключа;
С13 – ток к электроприбору от розетки;
С14 – ток к элекроприбору от ключа.
Для более удобного анализа матрицы можно использовать электронную таблицу (таблица 7).
Таблица 7. Матрица соответствия логической архитектуры и функциональной модели
системы мониторинга домашней электросети (электронная таблица)
С помощью матрицы соответствия функциональной модели и логической архитектуры можно оценить сложность модулей или интерфейсов (строка с суммой функций/связей
на модуль/интерфейс). При суммировании часто используют веса.
Итак, чтобы оценить срок и стоимость проекта, системному инженеру нужно:
46
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
1) Определить функции продукта, который должен получиться в результате проекта.
2) Определить архитектуру и модульную структуру (конструкцию) продукта в соответствии с функциями.
3) Разработать пакет технических требований по всем модулям.
4) Получить обратную связь по техническим требованиям, в особенности по срокам
и стоимости.
5) Собрать все в один документ и посчитать суммарные затраты и продолжительность.
Когда понятно, как работает система (рис. 19), можно продолжить формулирование требований, не боясь что-то упустить. По сути, каждое требование привязывается либо
к самой функции (например, для Ф6 необходимо указать максимальное расстояние), либо
к связи (например, для С1 следовало бы подробнее указать особенности электрического тока,
с которым придется иметь дело).
Для каждого требования должен быть справедлив вопрос «зачем?». С этой точки зрения,
все требования, на самом деле, функциональные, поскольку ответ на вопрос «зачем?» должен
приводить нас к той функции, которую требование определяет. Эстетическая функция также
может быть заложена в концепцию, но формализовать в виде овала со стрелочками ее не стоит.
Тот или иной, например, цвет корпуса может относиться как к эстетической функции, так
и к более техническим функциям. Некоторые компоненты системы должно быть просто найти,
то есть они должны быть яркие (красные, желтые), в интересах безопасности, ускорения сборки
или обслуживания. Так или иначе, подобные требования направлены на то, чтобы система
выполняла свою функцию лучше, то есть они относятся к системе в целом. Однако, чтобы
не путаться, кроме функциональных требований выделяют:
– требования к назначению;
– требования к надежности и ремонтопригодности;
– требования к безопасности;
– требования к охране окружающей среды;
– логистические требования;
– технические требования и многие другие…
Многие из этих групп требований можно найти в ГОСТ на разработку технических заданий.
Когда понятно, как устроена система (рис. 20), можно определять технические требования. Требования к совместимости, например, обычно выводятся из интерфейсов. Технические требования относятся к устройству (структуре или конструкции) системы, а функциональные – к модели функционирования (принципиальной схеме), однако технические
требования все также остаются в каком-то смысле функциональными, поскольку направлены
на реализацию конкретных функций.
Зачем об этом думать? Чтобы все требования были связаны единой сетью
и не терялись. Пускай, для начала, эта сеть начнет появляться у вас в голове,
потом на салфетке, а потом – найдем где ее развернуть.
Требования нужны не только на момент разработки технического задания. В реальных
проектах с реальными стейкхолдерами требования могут меняться ежедневно. Чтобы сохранить целостность требований и сделать, в итоге, успешный продукт, уложившись в срок и бюджет, нужно тщательно следить за всеми изменениями, знать причинно-следственные и другие
связи между требованиями, а самое главное – понимать место требований в системной иерархии.
Самая типовая проблема, возникающая при развитии системы, связана
с большим риском всё сломать из-за небольшой правки в требованиях.
47
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Наличие связей между требованиями может значительно прояснить картину возможных
последствий модификации.
Чтобы разработать требования для блоков Б1-Б3 нужно детализировать логическую
архитектуру. В данном случае я бы нарисовал, для начала, структурную декомпозицию нашей
системы (рис. 21). На нижнем уровне декомпозиции будем использовать обозначение «М» –
модуль.
Иерархическая нумерация блоков раскрывает нам принцип сборки
системы, а линейная нумерация модулей помогает нам выявить
повторяющиеся элементы системы.
Рис. 20. Структурная декомпозиция системы мониторинга домашней электросети
Теперь сведем все к одной спецификации (таблица 8). Каждому пункту таблицы должны
быть поставлены в соответствие конкретные требования. Это задача для вас, системного аналитика.
48
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Таблица 8. Спецификация модулей системы мониторинга домашней электросети
Особенные трудности сегодня возникают с описанием программного обеспечения в классических формализмах системной инженерии. Вот, например, М5-М7 выглядят как дублирование. Даже в такой, казалось бы, простой системе, как ваша мониторинговая, возникают
проблемы с описанием функций и структуры ПО. Напомню, что программное обеспечение,
с точки зрения системной инженерии, – это часть определения (описания) системы, а не ее
49
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
воплощения. То есть, программное обеспечение – это текст. Его нельзя потрогать, на него
нельзя показать пальцем. Однако, несмотря на этот факт, программное обеспечение представляют отдельным модулем, чтобы назначать по нему работы. Устройство скорее всего купят,
а вот ПО придется разрабатывать. При том, системное ПО скорее всего будет в составе устройства, хотя может потребоваться какое-то иное. Несмотря на одни и те же формулировки функций (дублирование) в таблице, а также несмотря на использование технологического акцента
при формулировании функций, такой подход полезен, чтобы не пропустить никаких требований. При получении состояния розетки или выключателя (Ф3) нас могут интересовать особенности самого wifi-адаптера в составе устройства (М5), принципы обработки информации
в системном ПО (М6), либо, например, структуры данных или методы, используемые в прикладном ПО (М7). Это все разные требования.
Когда мы говорим, что программное обеспечение – это модуль, мы,
как бы, мысленно заменяем его на микросхему, специально спроектированную
под нашу программу.
Несмотря на кажущуюся простоту модификации программного кода, последующая
модификация этой «мысленной микросхемы» в конечном продукте обычно оказывается большой и сложной задачей. Программистам полезно мыслить о своем коде, как о чем-то материальном. Я уже приводил пример со строительной аналогией.
В этом смысле, программное обеспечение можно было бы сравнить
с каким-нибудь маленьким заводиком, таинственным образом встроенным
в структуру нашей системы.
Итак, каждая строчка из таблицы 8 должна превратиться в набор технических требований, достаточных для начала разговора с инженерами по специальности. Напоминаю, что каждый элемент системы (Ф, С, М, И, Б…) должен быть представлен в спецификации и иметь
четкое и понятное описание. Работа только начинается. Самое время предложить самостоятельную работу для читателя.
1) Определить требования к каждому элементу системы.
2) Связать требования с потребностями.
3) Подобрать варианты физической архитектуры под требования.
4) Сравнить варианты и принять архитектурное решение.
5) Разработать техническое задание.
Если у Вас возникают трудности с первым шагом, представьте, что вы взяли таблицу
8 «как она есть» и пошли к инженеру. Он посмотрит на таблицу и задаст вам сходу очень много
вопросов. Например, про (М3) его явно будет интересовать:
– какого размера должен быть передатчик, чтобы влезть в коробку?
– какого рода крепление?
– какие будут датчики? Какого размера?
– почему WiFi?
– где будет питание?
– на какие расстояния надо передавать сигнал?
– будут ли барьеры при передаче сигнала?
– сколько таких передатчиков будет использоваться одновременно?
– сколько состояний у датчика?
– сколько состояний распознает приемник?
И это только основные вопросы. Думаю, их будет гораздо больше. Системному инженеру необходимо очень много общаться, ведь ответы на большинство вопросов нужно уточнять у других инженеров, а что-то у менеджеров. Ответы на эти вопросы практически напрямую приведут вас к формулировке требований.
50
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Системное проектирование может выполняться очень интенсивно и быстро, когда
функция целевой системы четко определена внутри использующей системы. В противном
случае, возможна излишняя абстрактность и, вообще, потеря смысла. Работа над функциональной моделью и системной архитектурой направлена, в первую очередь, на конкретизацию
постановки задачи и разработку технического задания. Те результаты системного проектирования, которые не попадают в техническое задание (в силу его стандартизации), должны
сохраняться в виде частных описаний, например в пояснительной записке. Такая пояснительная записка сыграет огромную роль на стадиях производства, сопровождения и развития
системы.
51
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Интерлюдия
Работа над требованиями к системе мониторинга домашней электросети шла уже который день, а директор все пытался придумать, как увязать между собой проект Ингеборга Карловича, инновационный проект для Александра Сергеевича и вашу текущую деятельность. Он
ходил по кабинету из стороны в сторону, тихо бурча что-то себе под нос. На улице шел дождь,
залетая в кабинет через открытое окно редкими каплями. Солнце еле-еле пробивалось сквозь
тучи, внезапно выстреливая директору в глаз своим ослепляющим лучом. В кабинете словно
стоял туман. Ситуация в компании была непростая: деньги быстро кончались, а проектов было
слишком много.
– У этого аналитика все очень неплохо получается, – думал директор, – но что дальше?
Нельзя же просто так взять и выкинуть остальные проекты! Отказываться от бизнес-центра
тоже было бы глупо…
В кабинет зашел Ингеборг Карлович. Он был чем-то недоволен.
– Мои программисты пишут какую-то чушь для этого пацана!
Директор развел руками, восприняв приход менеджера проекта как должное. Ингеборг
Карлович продолжил осуждать новое начинание, напоминая о дефиците бюджета.
– Если этот новый проект такой плохой, почему тогда в него бегут все наши специалисты?
Почему им интересно? – спросил директор, разглядывая тучи за окном.
– Потому что там за ними никто не следит, и они могут писать всякую чушь!
– Возможно.
Снова повисла тишина.
– У нас, Ингеборг Карлович, все равно не хватит денег на ваш проект. Вы их слишком
интенсивно расходовали. На что, если не секрет?
– Как на что? Бухгалтерия то… – выпучил глаза менеджер проекта.
– Ваш проект я не вижу смысла финансировать, но и этого аналитика поставить руководителем пока не решаюсь.
Ингеборг Карлович замер.
– Вы, как человек опытный, – продолжил директор, – могли бы очень помочь нашей компании. Если хотите успешно завершить свой проект и получить хорошую премию, принесите
в компанию деньги.
– Какие деньги?! – не выдержал Ингеборг Карлович.
– Не пугайтесь, не ваши, – улыбнулся директор, – Есть фонд, готовый профинансировать нас при наличии инновационной составляющей проекта. Вытащите из ваших разработок
инновацию и подайте заявку. Я вам дам все контакты. Это надо сделать срочно. Если будет
необходимо, привлечем вашего любимого аналитика, но пока его не трогайте.
Ингеборг Карлович вышел из кабинета подавленный и злой. В середине проекта менять
концепцию, заниматься какой-то бумажной работой и разгребать дела за амбициозным сопляком – это было совершенно омерзительно. Однако, директор был, конечно, прав, что в условиях дефицита бюджета требовались финансовые вливания, и что поручать столь ответственное дело молодому парню было бы очень рискованно. Директор остался доволен своим
решением. «Вставлять палки в колеса» он не хотел, но и оставлять в свободном плавании
молодого специалиста было нельзя. По задумке директора, Ингеборг Карлович мог бы стать
серьезным конкурентом (или даже оппонентом) для вас, несмотря на разницу в должностях.
Когда дышат в спину, бежишь быстрее.
Как это обычно бывает в художественных произведениях, дождь почти кончился, а изза туч выглядывало солнце.
52
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Часть 2. Пора брать в руки инструмент
Глава 8. Когда проектирование против конструирования
Леха никогда не любил больших проектов, однако не был обделен творческим потенциалом, смекалкой и стремлением к великому. Когда Лехе сказали, что надо написать программу
для умного дома, он несколько смутился и даже немного обиделся. С его точки зрения, программист (а он себя гордо называл разработчиком) вовсе не для того получает высшее образование, учит математику и теорию автоматов, чтобы потом делать дэшборды и прочую глупость
для подсчета коммуналки, тем более что все эти дэшборды давно делаются в электронных таблицах даже самими менеджерами. С точки зрения руководства, задача была тоже абсолютно
понятной и не требовала никаких разъяснений, и уж тем более технических заданий. Начальник отдела разработок, Саня, пришел к Лехе и сказал:
– Леха, нам поручили состряпать дэшбордик. Там тема такая. Есть датчики – с них поступают сигналы на планшет по вайфаю. Драйвера готовые уже есть. Надо сигналы эти читать
и в табличке показывать типа датчик-сигнал. Ну, например, утюг включили – у тебя сигнал
появился. Забыли выключить – ты перед уходом на экран посмотрел – и вспомнил. Вот и все.
– Понятно, – сказал Леха.
– До вечера пятницы сделаешь? – спросил Саня.
– Сделаю, – ответил Леха, отмерив в голове оставшиеся два полных дня. Был вечер среды.
Конечно, Лехе было очень скучно делать такую простую вещь, а поэтому он решил внести
некоторые авторские правки. Во-первых, Леха подумал, что нельзя просто так взять и отобразить состояние этого датчика. Надо все сигналы писать в базу данных, логировать, чтобы потом
можно было собирать статистику и делать прогноз. Вообще, наличие базы данных открывает невероятные возможности, поэтому Леха первым делом принялся за неё, когда пришел
на работу в четверг утром. Чтобы хранить состояние датчиков Леха создал таблицу и тут же
понял, что ему нужен справочник датчиков, ведь датчиков может быть больше или меньше.
Кроме того, каждый датчик соответствует какой-то функции или прибору, например утюгу или
свету в гостиной. Само состояние тоже, вероятнее всего, может иметь ограниченный набор значений, каждое из которых имеет свою интерпретацию. Появилась реляционная модель. Затем
Леха очень быстро сообразил, что планшет, на который приходят сигналы с датчиков, в доме
может быть не один, а в случае какого-нибудь бизнес-центра, о которых в последнее время было
много совещаний, нужен какой-нибудь центральный дэшборд, связанный с локальными через
надежную корпоративную сеть. Знание о состоянии электроприборов в сети давало чудесную
возможность оптимизации энергопотребления, если бы можно было пересчитывать состояния
во что-нибудь более физичное… Когда Леха развернул сервер баз данных, сервер приложений
и уже заканчивал читать статьи по сетевым архитектурам, рабочая неделя внезапно закончилась, и откуда ни возьмись появился начальник Саня.
– Как дела? – поинтересовался Саня как бы невзначай.
– Я почти все сделал, – бодро ответил Леха, не отрываясь от монитора. В понедельник
давай посмотрим.
Саня не стал спорить, наблюдая вдохновленного сотрудника, поэтому спокойно отправился домой. Все выходные Леха провел за компьютером. Он написал генераторы случайных сигналов, которые имитируют состояния электрических приборов, сделал виртуальную
сеть, в которой на разных устройствах фиксировались сигналы из разных помещений. Каждое
устройство имело свою базу данных, но была также и центральная база данных, которая синхронизировалась с остальными. Веб-приложение на центральном виртуальном сервере отобра53
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
жало состояния приборов, а также выводило графики динамики в реальном времени и на ходу
строился прогноз. Пунктирная линия прогноза перестраивалась на графиках незамысловатым
«прыгающим» образом, но, в целом, глядя на это творение создавалось впечатление центра
управления космической миссией. С помощью вкладок можно было включить визуализацию
плана здания, в котором загорались или выключались фонарики в соответствующих комнатах
на разных этажах. На ходу рассчитывалось потребление электроэнергии и происходила автоматическая перенастройка сети. На большом и жирном графике явно показывалась разница
между обычным поведением системы и оптимизированным. Сэкономленная сумма выводилась на экран в рублях и время от времени мигала, видимо, для привлечения внимания.
Когда Саня увидел в понедельник сие творение, он понял, что ни в коем случае нельзя
«плевать человеку в душу». Леха с таким умилением показывал свое детище, что необходим был такт. Саня подавленно улыбался и повторял «Да, прикольно» до тех пор, пока Леха
не повторил свою демонстрацию пять-шесть раз. В итоге Леха выдохся и, просто, как ни в чем
не бывало, пошел в уборную. Саня знал, что скоро Леха начнет замечать недостатки в своем
творении, а потом оно начнет его бесить настолько, что ему захочется все переписать. Нужно
было выждать момент возникновения самокритики, чтобы «под руку» дать разработчику ценные советы. Потом, пока Леха еще не захотел все переписать, нужно добиться хоть какогото результата и тут же околдовать коллегу восхищениями и похвальбой. Если все сделать правильно, то к концу второй недели есть шанс получить первую версию программы, которую
можно показать менеджерам. Так Саня и сделал.
Сначала Саня выжидал, когда на Леху нападет самокритика. Где-то в среду Леха внезапно подошел к Сане и сказал, что идея с центральной базой была не лучшей, потому что
синхронизация баз данных – тот еще «гемморой». Саня не имел права упустить момент:
– Слушай, я тут посмотрел… А давай мы с первого экрана уберем динамику и прогнозы.
Это же аналитика. Я предлагаю сделать вкладки так… На первой только табличка, на второй –
прогнозы, на третьей – план, а на четвертой вся эта экономия. Так ведь понятней будет?
– Пожалуй, ты прав, – кивнул Леха.
– Генератор сигналов я бы тоже включал по отдельной кнопке. Сделай, чтобы при запуске
в табличку просто записывались сигналы случайные. А если динамику смотреть, то эта кнопка
генератора должна быть на вкладке с графиками…
– Да, наверное. А то мельтешит, – продолжал соглашаться Леха, – Ну базу я сделаю одну.
Пусть он пишет сразу в неё, без локальных хранилищ.
– Да, ты прав, – согласился Саня.
Саня понимал, что сейчас самое главное – внешний вид, а все эти архитектурные изменения, базы данных – никто не увидит и не поймет. Но нельзя было сбивать творческий процесс
Лехи, иначе он мог впасть в депресссию, а когда Леха впадал в депрессию, он делал больше
глупых ошибок в коде. Саня давно работал с Лехой и манера управления у него сложилась
весьма утонченная. Через некоторое время содержимое первой вкладки стало похоже на то,
что представлял себе Саня – просто табличка.
В ближайшую пятницу Саня показал интерфейс команде менеджера проекта. В целом,
всем понравилось, но без восторга. Всех волновала себестоимость продукта, поэтому затраты
на покупку планшета планировались очень низкие. Сане передали опытный образец планшета
для тестов и попросили через неделю показать все то же самое, но уже на нем. Системный
аналитик обратил внимание, что сценарий использования продукта предусматривает как вывод
состояний приборов, так и ввод названий приборов, а также перетаскивание строчек в таблице.
Леха чуть не выкинул планшет в окно, когда Саня достал его из сумки.
– Это что за помои?! Он будет греться, там памяти нет, там экран – говно! Да там процессор от тамагочи! Это что, вообще, такое?! – раздосадовался Леха.
54
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Ну, продукт должен быть дешевый. Иначе никто не купит, – попытался объяснить Саня,
не осознающий пока еще масштаба проблемы.
– Такое говно никто на стену не повесит! – возмущался Леха.
Другие разработчики тоже подняли насмех всю затею создания такого продукта,
но от грозного взгляда Сани разбежались по местам.
– Поставь туда все – там посмотрим. Пусть они сами увидят, что греется, – отрезал
Саня. Ему совершенно не хотелось снова собирать совещание и что-то там решать, тем более
что сами менеджеры были настолько упрямые, что нашли бы тысячу причин, почему нужно
использовать именно этот планшет.
Леха расстроился. Во-первых, развернутая им архитектура требовала значительно
больше памяти, чем имел этот опытный планшет. Во-вторых, возникла проблема записи.
В последней версии Леха оставил только центральную базу данных, а поэтому, чтобы сменить
название прибора, необходимо было обращаться к другому серверу через сеть, рыться там
в базе данных, менять название поля в справочнике, а потом новым запросом вытаскивать
таблицу. Все это явно не лучшим образом должно было сказаться на производительности и без
того «тормозного», как выражался Леха, планшета. С другой стороны, наличие центральной
базы с веб-интерфейсом снижало требования к самому планшету. В результате, Леха принял
решение развернуть сервак в облаке, а на планшете просто смотреть табличку через браузер.
Саня принес на следующее совещание с менеджерами укомплектованный софтом планшет. Он невероятно быстро нагревался, быстро садился, жутко тормозил и всем не понравилось, что интерфейс отображается в браузере. Саня попытался объяснить, что на таком планшете лучше не сделать, но ему доходчиво дали понять, что «лучше» сделать не только можно,
но и нужно. Дали еще неделю. Всю эту неделю Леха депрессовал, но на выходных психанул
и написал за три часа простейшее приложение для планшета с одной-единственной таблицей.
Менеджеры были довольны. Подходил к концу первый месяц разработки.
Тем временем на другом конце города разворачивалась деятельность, которая, на первый
взгляд, никак не связана ни с Лехой ни с Саней, однако относящаяся к тому же самому проекту. Эти две параллельные действительности соотносила лишь когда-то кем-то нарисованная
диаграмма Ганта. С улицы доносилось жужжание трактора, в кабинете пахло клеем и ДСП,
на окнах висели какие-то дурацкие, местами поломанные, жалюзи, периодически раздуваемые
разболтанным вентилятором, который за время своей работы приобрел цвет слоновой кости;
под ногами сморщено лежал неестественно-салатного оттенка линолеум, повторяющий выпуклости и вогнутости дощатого пола, по углам стояли шкафы и полки, а за самым большим шкафом были высвобождены два с половиной квадратных метра для того, что местные работники
называли «кухней»: там умещался стол, два стула, полка с чаем, чайником и чашками, какие-то
сувениры и в нижнем закрытом ящике коллекция особенно красивых бутылок коньяка. Говорят, на некоторых таких кухнях иногда умещался даже аквариум с рыбками.
Ингеборг Карлович вошел в помещение довольно резко, тут же зацепившись ботинком
за плохо приклеенный кусок линолеума, но сумел устоять. Все шестеро работников, плотно
упакованных в кабинете вопреки всякому феншую, безучастно повернули головы на гостя,
затем то ли приветственно кивнули, то ли покачали головой, издали тихий шипящий подавленный звук, похожий на «зсте» и вернулись к своим делам. Любовь Ивановна восседала за самым
большим столом с многоэтажными полками, забитыми битком толстенными папками с причудливыми подписями, напоминающими номера моделей терминаторов из одноименного кинопроизведения. Она была тут начальником.
– Ингеборг Карлович, здравствуйте! – воскликнула она внезапно хриплым низким голосом, выдержав предварительно секундную паузу, видимо, чтобы гость окончательно преодолел линолеумовое препятствие – Никак не можем этот кусок присобачить еще с тех пор, как
евроремонт сделали.
55
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Не страшно. Оторвали бы к чертовой матери – и дело с концом! – важно произнес гость
и степенно повесил берет, шерстяной шарфик и плащ на рогатую серую вешалку, воткнутую
между шкафом и неприметной мусорной корзиной.
– Да уж Василич предлагал оторвать, а дырку краской закрасить, чтобы незаметно было,
да вот некогда всё. Работы много, – пояснила Любовь Ивановна, бросив в сторону шкафа с папками измученный взгляд.
– Как Лидочка поживает? – поинтересовался Ингеборг Карлович, раскрывая портфель
и выкладывая на стол Любови Ивановны файлы с документами.
– Да всё так же. Гуляет всё, – махнула рукой Любовь Ивановна.
– Ай-ай-ай… – покачал головой гость.
– У вас как дела?
Офисные работники старались не обращать внимания на разговор, но у них явно не получалось, поскольку голоса у говорящих были весьма громкими, даже звенящими. Любовь Ивановна все время поправляла свой воротничок, немного покачиваясь на стуле, а Ингеборг Карлович будто что-то жевал и часто прятал глаза в пол. Вот уже целый месяц он приходил
сюда на согласование различных технических и организационных вопросов, считался чуть ли
не родным, но никак не мог привыкнуть ко всей этой обстановке. Через какое-то время портфель был уже закрыт, шляпа, шарф и плащ надеты, а все документы – в нужной папке.
Ингеборг Карлович обменялся прощальными любезностями с Любовью Ивановной, торопливо
вышел из кабинета в коридор и со щелчком захлопнул за собой дверь. Табличка на двери возвещала «Отдел проектного управления Иннофонда».
Ингеборг Карлович занимался подготовкой заявки на грант. Любовь Ивановна сумела
перестроить всю его работу и полностью разрушить комфорт несколькими простыми требованиями:
– документы согласуются только в оригиналах и со всеми подписями;
– документы принимаются только от руководителя проекта лично;
– нарушение оговоренного срока исправлений в документах приводит к аннулированию
всей заявки без возможности восстановления.
В результате, первые два системных аналитика разной величины были моментально развернуты, написан выговор, сделаны нужные звонки и Ингеборг Карлович стал самостоятельно
ездить с бумажками к Любови Ивановне чуть ли не каждый день. Его это, конечно, неописуемо раздражало, но сделать он ничего не мог. Занимаясь бумажно-курьерcкой работой, Ингеборг Карлович перестал что-либо отслеживать в процессе разработки и окончательно потерял
связь с программистами. С точки зрения Любови Ивановны, проектное управление заключалось именно в согласовании проектной документации, а разницы между жизненным циклом
и планом работ она не видела никакой. В ее сознании слово «проект» однозначно ассоциировалось со стопкой бумаг, по которым будут делать изделие, а содержимое этих бумаг конкретизировало: что, где и когда нужно делать. В этом месте Любовь Ивановна проводила границу
между инженерами-конструкторами, технологами и инженерами-проектировщиками (кем она
себя считала). Конструктору и технологу, по ее мнению, предстояло ответить на вопрос «как
именно делать?». Она же, ни за какую конкретику отвечать не собиралась. Слова «менеджер»
у Любови Ивановны в обиходе не было. Она искренне не понимала, что это по сути своей
значит, и более всего ассоциировала менеджера с продавцом сим-карт из салона мобильной
связи. Поскольку сама она была начальником отдела проектного управления, то очень хорошо
понимала – что такое руководить. Фактически, она делала всю работу, а то, что не успевала –
поручала своим подчиненным, как она их называла. Любови Ивановне никогда не приходило
в голову, что какой-нибудь проект (стопка бумаг), который она собирает несколько месяцев,
может потерять актуальность сразу после начала работы. Кроме того, Любовь Ивановна очень
56
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
гордилась, что на ней все держится, и если, по какой-то причине, она не будет работать, весь
Иннофонд тут же перестанет функционировать.
В Иннофонде работали и те самые менеджеры, которых Любовь Ивановна не могла осознать и называла просто – большое начальство. Они планировали бюджеты, каким-то образом определяли сроки проектов (которые от слова project), какие-то правила игры. В конечном
счете, основная работа фонда сводилась к инициации конкурсов, разработке конкурсной документации, приему заявок, организации экспертизы, принятию решений по заявкам, инициации проектов, потом ведению проектов, закрытию проектов и принятию решений по проектам. Любовь Ивановна в глубине души надеялась, что если долго и хорошо работать, то потом
можно стать тоже большим начальством, и тоже ничего не делать, но чем больше и старательнее она работала, тем еще больше работы сваливалось на нее со стороны большого начальства.
Любовь Ивановна прекрасно поддерживала дисциплину, соблюдала сроки, на все имела соответствующую бумагу. С Ингеборгом Карловичем их объединяла общая черта – им было абсолютно не важно, что будет с тем продуктом, процессами создания которого они управляют.
Это безразличие имело глубокие корни. Их с детства учили решать задачи, но никто не рассказывал, откуда эти задачи берутся.
Первый вариант заявки Ингеборга Карловича назывался «Проект разработки экономичной системы управления реального времени для деловых центров». Любовь Ивановна высказала следующие замечания:
– слово «проект» убрать;
– «разработка» – это стадия проекта, поэтому нужно тоже убрать;
– уточнить объект управления и инновационную специфику экономичной системы
управления реального времени;
– почему только для деловых центров?
Второй вариант заявки Ингеборга Карловича назывался «Экономичная система распределенного управления электрооборудованием в реальном времени». Любовь Ивановна снова
оказалась недовольна, ответив официальным письмом:
– термин «система» не дает четкости в понимании конечного результата проекта;
– распределенное управление – известная и решенная задача, поэтому инновационности
до сих пор нет;
– электрооборудование – слишком широкое понятие.
Потом были варианты заявок: три, четыре, пять и т. д. Изменение названия тянуло
за собой множество изменений внутри заявки, концептуальных «перекосов». В общем, учитывая, что Любовь Ивановна совершенно ничего не знала о предлагаемом проекте, она тем
не менее сумела коренным образом повлиять на его дальнейшую судьбу. Ингеборг Карлович знал, что и эта, сегодняшняя, заявка будет подвергнута критике. Времени оставалось еще
пара месяцев, а процедура согласования регламентировалась весьма короткими промежутками, и из этого плена никак нельзя было сбежать. Иногда казалось, что Любовь Ивановна
отчитывается перед большим начальством количеством согласований.
Ингеборг Карлович слышал, что разработано новое приложение для планшета. Когда-то
Саня и Леха отчитывались ему по всем вопросам. Сейчас было не до них. В этом бесконечном
потоке бумаги уже не было никакой надежды, что реальная работа как-то свяжется с проектной
документацией, а поэтому Ингеборг Карлович лично принял решение, что бумага бумагой,
а ребята пусть делают, что хотят. С каждой итерацией согласования тема уходила все дальше
и дальше от Интернета вещей и умных домов.
Мораль этой
дезорганизованность
истории заключается в том, что вопиющую
часто выдают за объективные причины или
57
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
методологические проблемы, которые якобы не дают никакой возможности
работать эффективно.
Разработчики ПО Саня и Леха совершенно не интересуются положением дел на уровне
всего проекта, а Ингеборг Карлович даже и не пытается связать бумажную работу с реальной деятельностью. В результате – проект становится оторванным от жизни, а результаты разработок – никому не нужными артефактами. Чтобы скрыть возникший разрыв между проектом и реальностью, проектировщики придумывают удобные для себя ключевые индикаторы,
по которым легко отчитываться, а разработчики придумывают себе удобные задачи, которые
легко (интересно и весело) решать. Исходя из реальной практики, все должно быть наоборот.
Поскольку проект должен быть направлен на реальные изменения в жизни, то достижение ключевых показателей является априори трудной задачей, требующей, так сказать, борьбы с костной материей. Потребности стейкхолдеров, как правило, очень далеки от обыденного мышления разработчиков и лежат в совершенно других аспектах жизни, чем об этом привыкли думать
инженеры. Зачастую настоящие задачи, приходящие от заказчика или пользователя системы,
имеют рутинный характер.
В который раз остановлюсь на теме проектирования, проектного управления и разработки/дизайна/конструирования. Спорить о терминах можно бесконечно, поэтому предлагаю
расставить точки над i.
Менеджер проекта отвечает, прежде всего, за работы, качество результата и бюджет.
Когда, например, речь идет о строительстве жилого дома, то классическое проектное управление работает в полную силу: надо спланировать ресурсы, связать задачи между собой, мониторить риски и все это контролировать, отчитываться по вехам. В таком варианте нет необходимости говорить о жизненном цикле проекта (хотя так часто говорят). В данном случае,
жизненный цикл и план – это синонимы.
Однако, если мы вводим в проект (под ответственность руководителя проекта) стадию
разработки рабочей документации здания, то все значительно усложняется. Интеллектуальный труд, в том числе инженерный, не поддается точной оценке, потому что «на берегу»
невозможно оценить все технические тонкости. Например, необходимость адаптации тех или
иных инженерных решений под определенные внешние условия (использование более прочного материала в условиях высоких температур) может привести к необходимости сначала
пересчета, а потом и модификации остальной конструкции. Практики работы на стадиях разработки и строительства – существенно отличаются. Чаще всего на разных стадиях работают
разные компании из разных городов. В таком случае уместен подход жизненного цикла, и это
уже значительно больше, чем просто план.
Модель жизненного цикла должна определять связи между разными
стадиями, имея в виду, что стадия – это уже не период времени, а предприятие
с конкретными границами ответственности.
Исторически такой подход все также ассоциируют с проектным управлением, однако
более правильно теперь говорить об управлении жизненным циклом, а руководителя этой деятельности называть менеджером жизненного цикла (или менеджером продукта).
Проектирование может быть отдельным проектом, а может быть стадией большего проекта, включающего строительство, конструирование или даже исследования. Чаще всего под
проектированием понимают постановку задачи и планирование работ по уточнению задачи,
в том числе по созданию конструкторской документации, если это необходимо. Основным
рабочим продуктом проектирования является техническое задание, совмещающее требования
к продукту, требования к обеспечивающим системам, а также к работам. Результаты проектирования часто включают трехмерные модели, планы зданий, схемные решения и т. д.
58
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Проектирование оперирует готовыми
и должно увязывать их между собой.
модулями/конструкциями
На практике часто используют типовые проекты (речь про технические задания с приложениями), поэтому само проектирование часто ассоциируется с внесением изменений в типовой проект, его адаптацией или развитием. Отсюда часто проектирование называют проектной разработкой, разработкой проекта. В английском языке разработка и развитие имеют один
эквивалент development.
Таким образом, проектирование действительно имеет сходство с проектным управлением в части планирования работ, однако в проектировании работы посвящены постановке
задачи, а в проектном управлении работы могут быть любыми. На начало проектирования
обязательно должны быть определены потребности стейкхолдеров, проблематика, известны
и согласованы цели и сроки всего проекта.
Конструирование тоже может быть отдельным проектом, а может быть стадией большего. На начало конструирования необходимо наличие технического задания, а поэтому проектирование должно быть либо в разгаре, либо на завершающей стадии. Рабочим продуктом
конструирования является конструкторская документация – в конечном счете рабочая документация, ради которой затевалось проектирование. По этой рабочей документации можно
строить здание, либо точить деталь, либо печатать изделие.
С точки зрения системной инженерии, программная документация (включая полный
текст программы) во многом напоминают рабочую документацию. Изделием, произведенным
по программной документации, будет являться компьютер, отвечающий аппаратным требованиям, с установленным программным обеспечением, включая текст программы.
Конструирование, как правило, выполняется с целью улучшить или
адаптировать типовую конструкцию к определенным внешним условиям,
поскольку в наши дни известно уже множество конструкций.
Конструирование сначала происходит в голове, а потом отображается на чертеже. Этот
очевидный тезис нельзя забывать, чтобы не заниматься чертежами ради чертежей (моделями
ради моделей). Мы имеем аналогичную ситуацию, как с проектированием. Конструирование –
это разработка (развитие, девелопмент) конструкции. Обычно, когда говорят «разработка» без
пояснения, имеют в виду именно конструкторскую разработку или разработку программного
обеспечения. Надо лишь помнить, что употребляя эти слова, мы не явно говорим именно о развитии, а значит надо очень хорошо понимать, что не устроило заказчика или руководителя
проекта в продуктах, имеющихся на рынке. Многократно доказано практикой, что, в большинстве случаев, разработка обходится на порядок дороже, чем покупка готового решения. Если
вам нужно повторить готовое решение – это реверс-инжиниринг. Реверс-инжиниринг должен
стоит значительно дешевле разработки и планировать его значительно легче. Только нужно
помнить про интеллектуальную собственность.
Воспользуемся ролевой таблицей, чтобы закрепить результаты по этой главе.
59
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Таблица 1. Сравнение ролей руководителя проекта, инженера-проектировщика и инженера-конструктора (один из вариантов разделения ответственностей в системно-инженерном
проекте)
В прошлой части мы пробежались по практикам системной инженерии и можем с уверенностью сказать, что инженер-проектировщик, при правильной постановке процессов, становится тем самым системным инженером. Он занимается одновременно и продуктом и деятельностью, его интересует цельная постановка задачи, он заинтересован в успехе, понимая
потребности, сроки и бюджет, при этом разбираясь в реализации. Конечно же, работа проектировщика должна продолжаться в течение всего жизненного цикла, увязывая всех со всеми, но,
сожалению, так происходит далеко не всегда. Чаще всего роль проектировщика берет на себя
конструктор в начале проекта, а потом благополучно эту роль с себя снимает. В частности,
роль системного аналитика, отвечающего за требования, должна быть вспомогательной в рамках работы команды инженеров-проектировщиков.
Не допускайте разрыва процессов конструирования и проектирования. Никакие причины
(короткие сроки, небольшой бюджет, бюрократия) не должны сбивать вас с курса на успешный результат. Налаживайте коммуникации между различными командами, берите на себя
роль лидера и мотивируйте работать вместе. Всегда держите в голове, какая направленность
у вашего проекта – развитие, реверс-инжиниринг или что-то совсем другое.
60
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 9. Системная инженерия
и процессы жизненного цикла
Весь этот месяц вы были заняты переосмыслением происходящего в компании, поэтому
не успели заметить, насколько стремительно менеджерские решения о смене курса дошли
до исполнителей. Вы чувствовали, что не управляете процессом в действительности, но прежде
чем бросаться останавливать лавину, изображая из себя кризис-менеджера, нужно было совершить какой-то важный маневр в голове – вы это понимали, и сосредоточились именно на этом
маневре. Может быть, и не нужно было никого из себя изображать. Вы точно понимали только
то, что вам не удастся успешно отыграть роль системного аналитика в текущей ситуации,
потому как проект постепенно впадал в полную дезорганизацию, но и роль руководителя вам
никто играть не даст. Вам уже не хватало одного лидерства, чтобы связать всех вместе.
Первое, что нужно было сделать как можно скорее – выстроить логическую цепочку
от стейкхолдеров до реализации. Высказанная вами идея о мониторинге домашней электросети была воспринята позитивно благодаря тому, что внесла реалистичность в разработку.
Реалистичность с двух сторон – со стороны тех, кто будет это делать, а также со стороны тех,
кому это может быть нужно. Который день менеджеры обсуждали актуальность такой системы,
вопросы масштабирования конечного продукта, адекватность российскому рынку. Вам оставалось радоваться тому, что вброшенная идея стала мощным драйвером развития. Настоящими
стейкхолдерами, способными влиять на весь проект, оставались Александр Сергеевич и группа
его партнеров, включая Иннофонд и Наномегасвязь. Интерес директора вашей компании тоже
нельзя было забывать, ведь он был еще и соучредителем. Проблема на данный момент заключалась в том, что цельной картины между всеми этими интересами нарисовать не удавалось.
Наверное, уважаемый читатель, искушенный опытом реальных проектов, давно уже
заметил, что я беспринципно выкинул из методологии даже намеки на исследование рынка,
анализ альтернативных решений и прочие крайне важные вопросы, без которых невозможен
успех проекта. Обычно с этого начинаются все учебники по системной инженерии, этому
вопросу уделяется наиболее пристальное внимание, и, пожалуй, многие системные аналитики
(особенно в бюрократических структурах) посвящают этой работе большую часть своего времени. Конечно, я поступил так осознанно. Основная причина заключается в том, что работа
с аналогами становится основной рутиной для тех организаций, которые прошли уже определенный путь, понимают рынок и работают именно над развитием. Таким организациям порой
достаточно иметь прослойку системных аналитиков, бездумно упорядочивающих информацию о конкурентах и новых технологиях, анализирующих протоколы совета директоров и прочих важных совещаний, читающих все приказы и положения и т. д. и т. п. Готовить таких специалистов – большая ответственность, однако цель этой книги заключается не только в том,
чтобы дать нужные техники работы, но еще и ответить на вопрос «зачем это надо?». Еще точнее – эта книга, по задумке, должна помочь поставить системно-инженерную деятельность,
а не только ее поддерживать. Именно поэтому материал дается не в методологической последовательности, а в исторической, согласно тем естественным процессам, которые должны произойти на пути от хаотичной деятельности, когда компания мечется из стороны в сторону,
к поставленным процессам системной инженерии. Не могу не отметить, что студенту (для которого эта книга предназначена, в первую очередь) гораздо проще вникать в дисциплину, когда
материал излагается по мере необходимости и напрямую увязывается с практикой, а не декларативно.
Именно сейчас, когда все стейкхолдеры стали понимать, что же такое вы собрались
делать, когда встали вопросы оценки сроков, бюджетов – можно осознанно провести поиск аналогов и задуматься о позиционировании продукта. Вся работа, выполненная до этого момента,
61
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
очень редко как-либо регламентируется. Часто эту стадию называют предпроектной. На ней
мобилизуется вся команда, запускается различная деятельность, инженеры и программисты
что-то черкают в блокнотах – все это для того, чтобы понять – что же мы собираемся делать.
Когда компания, как в нашем случае, решается на изменение направления развития (от чистого
ИТ в умные дома), такая стадия неизбежна.
Системная инженерия может существенно помочь в сокращении сроков
предпроектной стадии, а также сохранить понимание, родившееся на этой
стадии, на весь оставшийся проект, что само по себе – бесценно.
Что значит, понять – что мы собираемся делать? Это значит – четко определить класс
целевой системы, но на этот раз уже не функционально, когда мы еще не определились
с вариантом реализации, а с точки зрения конструкции. Класс системы может быть описан
набором ключевых слов, которые позволяют найти на рынке аналоги. То есть прежде чем
делать, например, умный утюг, вы идете в магазин и смотрите, что есть в продаже. Понятно,
что цель поиска аналогов состоит в том, чтобы потом сравнивать собственный продукт с ними
некоторым способом. Планшет для мониторинга домашней электросети – это лишь первый
шаг к определению класса системы, исходя из потребностей небольшой группы стейкхолдеров:
конечный потребитель (которому это удобно использовать), инженер (который понимает, как
это делать) и продавец (который понимает, как на этом заработать). Теперь, чтобы система
была успешной, нужно учесть интересы инвестора, заказчика, поставщиков комплектующих
и т. д. Желательно сделать это так, чтобы принципиальные инженерные решения не претерпели
значительных изменений, иначе можно бесконечно метаться из стороны в сторону. Учитывая, что проектируемая система напрямую взаимодействует с электрической системой, нельзя
забывать про еще одного стейкхолдера, которого пока ни о чем не спрашивали – это, собственно, электрик. Строители часто называют таких стейкхолдеров смежниками. Именно эти
смежники будут ставить разъемы на стены и тянуть проводку. Другие смежники будут заниматься теплом, третьи – газом, четвертые – канализацией и т. д.
Очевидно, что вам не угнаться за всеми стейкхолдерами, вы не будете успевать контролировать всех конструкторов, программистов и проектировщиков, не сможете сами все сделать
собственноручно. Зато вы можете принять непосредственное участие в выстраивании процессов жизненного цикла. Стандарт ISO/IEC 15288:2015 предлагает следующую карту процессов
(рис. 21). Очень важно помнить, что за каждым процессом стоит:
– дисциплина, то есть написано много книг и учебников, рекомендаций или стандартов,
которые нужно изучить, прежде чем ставить этот процесс;
– технология, то есть конкретный инструментарий, без которого работа будет неэффективной, либо бесполезной.
Понятие «процесс» в этом стандарте несколько отличается от традиционного понимания,
связанного с последовательным выполнением действий. Я буду пользоваться языком Archimate
для моделирования системно-инженерной деятельности. В Archimate есть элемент «бизнес-функция», который подходит для моделирования процессов из стандарта гораздо больше,
чем «бизнес-процесс». Обратите внимание на определения из спецификации Archimate 3.0.
Бизнес-функция – это набор бизнес-поведений, основанный
на определенных критериях (обычно, требуемые бизнес-ресурсы и/или
компетенции), тесно связанный с организацией, но не обязательно четко
регламентированный организацией.
Бизнес-процесс – это последовательность бизнес-поведений,
приводящая к получению конкретного результата, такого как определенный
набор продуктов или бизнес-сервисов (услуг).
62
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Чтобы не расходиться с ISO/IEC 15288, я буду пользоваться термином «процесс»,
но понимать под этим термином я буду «бизнес-функцию» из Archimate.
Рис. 21. Процессы жизненного цикла ISO/IEC 15288:2015 в нотации Archimate
63
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Начнем с блока «Б1. Организационные процессы обеспечения проектов».
В нашем случае речь идет о процессах предприятия, в котором вы работаете.
Пр1. Процесс управления моделью жизненного цикла – это очень ответственная деятельность, направленная на определение бизнес-окружения проекта или всего предприятия
с целью обеспечения успеха конечного продукта. Надо понимать, что предприятие может быть
в середине жизненного цикла системы.
Только правильно определенная модель жизненного цикла системы
и, соответственно, правильно определенное бизнес-окружение проекта
(предприятия) даст возможность осознанно работать с пользой.
Управление моделью жизненного цикла, как правило, означает оптимизацию взаимодействия процессов жизненного цикла, в том числе планирование соответствующих изменений
на будущее и достижение целевых показателей. Типовые модели жизненного цикла рассматривались в прошлой части в 4 главе «Жизненный цикл системы и проекта». Важно понимать,
что работа с моделью жизненного цикла очень тесно связана с бизнес-моделированием и бизнес-анализом, который обсуждался в 5 главе «Бизнес-анализ» 1 части и еще встретиться нам
в технических процессах. Судя по тому, что вам пришлось заниматься этим в одиночестве,
необходимо ставить этот процесс в компании «с нуля».
Пр2. Процесс управления инфраструктурой, как правило, в каком-то варианте обычно
присутствует в любой компании. К сожалению, не всегда этим занимаются отдельные команды.
Речь идет, как минимум, об организации рабочих мест, предоставлении доступа к корпоративным информационным системам, ИТ-сервисам и другим корпоративным услугам. Кроме
того, вопросы управления инфраструктурой касаются поддержки актуальности, адекватности
и интеграции технологий. В нашей конкретной ситуации особых претензий к управлению
инфраструктурой пока нет.
Пр3. Процесс управления портфелем необходим, в первую очередь, для того, чтобы
не заниматься чем-то изначально обреченным на провал из-за нехватки бюджета или несоблюдения сроков. Этот процесс в вашей компании курирует непосредственно директор, поэтому
к нему тоже претензий пока нет.
Пр4. Процесс управления кадрами часто сильно недооценивается. На данный момент
в вашем проекте от него ничего сверхъестественного не требуется, но надо помнить, что ключевым фактором успеха компании, решившейся на смену вектора развития, являются специалисты, соответствующие этому новому вектору. Если все пойдет хорошо, очень скоро вам
придется бежать в отдел кадров и требовать новую команду специалистов.
Без надежного и профессионального отдела кадров предприятие
рискует однажды потерять ключевых специалистов и быть исключенным
из жизненного цикла системы.
Пр5. Процесс управления качеством чрезвычайно важен, когда вы собираетесь позиционировать продукт на рынке. Вам уже сейчас совершенно необходима команда специалистов,
которая не только готова разобраться в содержательной стороне проекта и помочь в формализации требований, исходя из возможностей испытательного оборудования, а также выстроить
систему этих испытаний, но и сумеет прикрыть ваш продукт необходимыми свидетельствами,
сертификатами и аттестатами. Будем считать, что такая команда специалистов есть, но она
не встроена в жизненный цикл нового продукта.
Пр6. Процесс управления знаниями необходим в долгосрочном бизнесе, поскольку кадры
меняются, а накопленный задел компании терять никому не хочется. Когда ваша работа даст
ощутимые результаты и мы с уверенностью скажем об успехе проекта, будет необходимо задуматься, как сохранить полученные знания и опыт для последующих поколений инженеров
и менеджеров. Как сделать так, чтобы никому не приходилось повторять уже выполненную
64
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
кем-то работу? Чтобы не нужно было каждый раз искать в литературе ответы на основные
(и всегда повторяющиеся) вопросы.
В целом, все описанные выше процессы довольно часто встречаются на практике,
поскольку так или иначе преподаются в образовательных программах по менеджменту и бизнес-администрированию. Интерес к этим программам до сих пор весьма велик, что и отражается в действительности.
Наиболее принципиальным (требующим особого внимания) процессом
для перехода к методологии системной инженерии на предприятии является
процесс управления моделью жизненного цикла.
Б2. Процессы соглашения (поставки и приемки) являются неотъемлемой частью деятельности любого предприятия, но вынесены в стандарте отдельно, поскольку не относятся
к вопросам управления, и требуют особенного пристального внимания. Очень часто эти процессы не налажены в провинции, где поток заказов не очень велик. В результате, из-за разницы
в темпах столичных и провинциальных менеджеров, возникает множество проблем и недопонимания. Процессы согласования должны работать как машина – это важнейший фактор
успеха при внедрении системной инженерии.
Везде и всюду встречается ситуация, когда, например, техническое
задание на поставку ходит по инстанциям неделями, а то и месяцами,
безо всякого содержательного продвижения – исключительно в ожидании
очередной подписи. При этом курсы валют стремительно меняются, товары
лежат на складе, зарплаты выплачиваются и т. д. и т. п.
Блок «Б3. Процессы инженерного менеджмента» уже более специфичен в отношении системной инженерии, поскольку сама системная инженерия определяется в классических
учебниках вроде А. Косякова и др. как часть (субдисциплина) управления проектами. Когда
говорят о системной инженерии, обычно имеют в виду либо конкретные практики типа проектирования логической архитектуры, либо целую методологию (подход), либо и то и другое
одновременно, как в SEBoK. Невозможность одного без другого должно напоминать нам о том,
что мы имеем дело с системным подходом.
ISO 15288 четко дает понять – жизненный цикл системы должен быть
в голове и у инженера, и у руководителя проекта, и у директора компании, и,
очень желательно, у собственников.
Пр9. Процесс планирования проекта чаще всего сводится к рисованию диаграммы Ганта.
Какой бы сложной ни была модель жизненного цикла, менеджеру проекта все равно придется
разбить временную ось на этапы, между этапами расставить логические переходы, в этапах
выделить работы, работы назначить на исполнителей. Эта работа должна исходить из понимания цели проекта, а цель должна исходить из проблемы или возможности. Хороший план –
половина дела, но чтобы его сделать хорошим, требуются колоссальные усилия. Вот у Ингеборга Карловича сменилось уже несколько вариантов этих планов по ходу проекта.
В отсутствии согласованной и утвержденной модели жизненного цикла
системы, писать план проекта – очень самонадеянно.
Пр10. Процесс оценивания и контроля проекта позволяет держать руку на пульсе. В водопадном жизненном цикле этот процесс отрабатывает только на вехах, а иногда (в гибких методологиях) этот процесс имеет многоуровневую реализацию. Надо помнить, что оценивание
требует экспертизы, а поэтому данный процесс обходится довольно дорого. Гибкая методология, в этом плане, часто значительно дороже «водопада». В этом процессе главный вопрос –
ну что? идем дальше или нет?
65
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Оценивание и контроль являются важнейшей мотивацией для команды.
Ежедневные планерки с коротким отчетом, кто и что сделал, например
в варианте Scrum, действительно драйвят работу, потому что любому члену
команды банально стыдно сказать при всех – я ничего не сделал, особенно
когда дело касается интересного и хорошо оплачиваемого проекта.
Ежемесячные демонстрации стейкхолдерам – другой очень важный способ контроля,
мотивирующий и направляющий работу, благодаря актуальной обратной связи. Совместное
планирование очередной итерации или спринта, заключающееся в коллективном оценивании
трудоемкости задач тоже поднимает мотивацию, а также дает возможность гибко вносить изменения в проект по ходу его реализации. Главный вопрос «идем дальше или нет?» при этом
обычно поднимается не реже, чем раз в полгода и обычно связывается с дорожной картой
выпуска версий (новых моделей изделия). Здесь оценивание и контроль идут «нога в ногу»
с процессом управления конфигурацией, о котором будет несколько слов чуть позже.
Пр11. Процесс управления принятием решений – очень характерная деятельность
в системно-инженерной методологии. Учитывая, что системные проекты относят к междисциплинарным, то не предполагается наличие такого специалиста или начальника, которого
можно было бы обо всем спросить. Большинство вопросов, во-первых, требуют коллективного
обсуждения. Во-вторых, различным вопросам свойственны различные приоритеты. В третьих,
принятое решение необходимо не только довести до сведения команды, но и дать однозначно
интерпретируемое обоснование. Решения, о которых идет речь в этом процессе, как правило касаются упомянутых выше бюджетов, сроков и принципиальных характеристик системы.
Подобные решения должны приниматься не очень долго, поскольку тянут за собой существенную перестройку проекта, а с этим лучше не затягивать, чтобы не делать лишнюю работу.
К сожалению, если поместить менеджеров в одну комнату и попросить
договориться «на пальцах», то такое обсуждение может затянуться очень
надолго – именно поэтому необходим специальный процесс поддержки
принятия решений.
Пр12. Процесс управления рисками – базовый процесс технического управления
и системной инженерии в целом. Если бы мы могли рассчитывать, что в нужном месте в нужное время внезапно материализуется система умный дом, то ничего бы не нужно было делать.
Если бы рабочие могли с первого раза произвести, собрать и запустить систему умный дом, то
инженеры были бы не нужны. Если бы инженеры могли безо всяких проблем спроектировать
и продумать работу техников, то менеджмент был бы ни к чему.
Любая деятельность – это, в какой-то мере, ответ на риск, с точки зрения управления рисками. При этом любая деятельность порождает дополнительные риски, а поэтому приходится
взвешивать те или иные последствия тех или иных решений. Риски, связанные с применением
инноваций, порождают дополнительные стадии перспективных разработок; риски, исходящие
от ненадежных поставщиков, заставляют прорабатывать несколько вариантов системной архитектуры.
Принять меры против всех рисков невозможно, поэтому цель
управления рисками – максимальное снижение вероятности провала,
имеющимися ресурсами. Управление рисками – это отправная точка
во всей системной инженерии.
Пр13. Процесс управления конфигурацией заключается прежде всего в том, чтобы в нужное время появилась версия продукта, отвечающая ожиданиям стейкхолдеров и соответствующая документации. Для этого все модули системы должны быть промаркированы и было
выставлено однозначное соответствие – что с чем соединять при сборке конкретной версии.
66
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Кроме того, важно иметь дорожную карту выпуска версий, а кастомизация продукта под различных клиентов не должна разрушать базовую сборку.
При правильно поставленном процессе управления конфигурацией
внесение изменений в конструкцию системы должно стать обычной рутиной.
Управление конфигурацией тесно связано с управлением рисками и управлением принятием решений. Когда этот процесс не выстроен, любое даже незначительное изменение может
породить полный хаос и затянуться на непредсказуемый срок.
Пр14—16. Процессы управления информацией, измерений и контроля качества я бы
рассмотрел вместе, поскольку чаще всего они очень тесно связаны. Логика здесь следующая:
чтобы контролировать качество процессов и продукта, необходимо выстроить схему сбора
и переработки информации от исполнителей к менеджменту. Для контроля качества нужны
дэшборды с круговыми диаграммами, графиками и гистограммами, визуализирующими ключевые показатели – подготовить их на основе «сырых данных» должен процесс управления
информацией. «Сырые данные» сами ниоткуда не возьмутся – ввести их в информационному
систему (максимально объективно отобразить какие-то реальные ситуации в виде чисел или
категорий) должен процесс измерений. Надо отметить, эти процессы в равной мере помогают
всем остальным процессам технического управления. Управление информацией в особенности полезно в управлении принятием решений.
Итак, блок процессов технического управления выглядит достаточно насыщенным. Все
процессы очень тесно связаны, но разделены для однозначности распределения ролей и зон
ответственности, о чем мы уже много говорили еще в 1 главе 1 части «Разделение зон ответственности». Для вашего проекта сейчас наиболее принципиальным процессом технического
управления является планирование. То что Ингеборг Карлович сейчас делает в связи с подготовкой заявки на грант очень похоже на процесс планирования, но поставлен он неверно,
потому что оторван от действительности. Надо придумать, как использовать эту деятельность
для достижения успеха проекта. Необходимо, как минимум, скоординировать процесс планирования с процессом управления моделью жизненного цикла. Затем надо понять, как запустить остальные процессы технического управления. Возможно, Ингеборг Карлович и здесь
сможет помочь своими компетенциями, если правильно все организовать.
Б4. Блок технических процессов – ядро системной инженерии. О них и написана эта
книга.
Пр17. Процесс бизнес-анализа (или анализа миссии) продемонстрирован в 1 части главе
5 «Бизнес-анализ».
Пр18. Процесс определения потребностей и требований стейкхолдеров затронут
в 1 части главе 2 «Потребности и требования» и 1 части главе 6 «Совещание со стейкхолдерами».
Пр19. Процесс определения системных требований дан в классическом варианте функционального моделирования в 1 части 3 главе «Функциональное моделирование».
Пр20. Процесс определения архитектуры представлен в 1 части 7 главе «Системное проектирование».
Разница между процессами определения архитектуры (Пр20) и определения дизайна
(Пр21) раскрыта в 1 главе данной книги (2 части) в теме о проектировании и конструировании. Нюанс только в том, что определение дизайна в большей степени касается задачи выбора
из альтернатив, а не 3D моделирования или кодирования.
Проектирование, в привычном смысле, затрагивает и архитектуру
и план проекта, что вполне разумно, поскольку одно без другого обычно
не встречается.
67
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Конструирование, по большей части, соответствует процессу определения дизайна,
но когда процесс определения архитектуры не поставлен, конструирование начинает естественно расширяться в зоне своей ответственности. В результате, в некоторых вузах инженеров-конструкторов учат заменять собой всех остальных инженеров. Иногда даже шутят, что
инженер-конструктор – это и есть единственный инженер. То что начертит (смоделирует) конструктор – потом пойдет на станок или на аддитивную печать – то есть в реальность – поэтому
не удивительно, что именно инженеры-конструкторы пользуются особым уважением. С другой стороны, слесарь-сборщик, у которого не сошлись детали, может надавать конструктору
по рукам и будет прав, поэтому не стоит искать в процессах жизненного цикла системы главного или второстепенного участника.
В этой книге я ставил себе задачу – показать, как процессы жизненного
цикла сочетаются вместе в одном «оркестре». Отличие системной инженерии
от классической инженерии в первую очередь в том, что не может и не должно
быть одного единственного дирижера.
Всего на рис. 1 мы видим 30 процессов. Это означает, что системной инженерией в полной мере можно заниматься, когда у вас в компании есть минимум 30 высококлассных специалистов, способных отвечать за соответствующий процесс. У каждого из них, как правило,
набирается команда около 10 человек. Вот уже штат 300 человек. Например, при средней зарплате 70000 дукатов в месяц, фонд оплаты труда составит четверть миллиарда дукатов в год.
Не каждая компания готова похвастаться даже такими оборотами. Тем не менее я уверен,
что международный опыт системной инженерии, непосредственно системный подход и личная
мотивация могут помочь выстроить процессы не хуже даже в среднестатистической компании,
решившейся на разработку умного дома.
Мы уже говорили вначале, что системный подход к инженерной деятельности является
достаточным условием, чтобы признать факт применения системной инженерии. Проблема
такого определения заключается в том, что системный подход, для большинства инженеров,
такой же незнакомый термин, ассоциирующийся с «продумыванием всего». Поскольку «продумать все» невозможно, особенно в сложных проектах, то такое определение выглядит со стороны противоречивым.
Очень важно дать «внешнее» определение системной инженерии, чтобы
вы могли пользоваться им в разговорах с инженерами по специальностям,
менеджерами, маркетологами и т. д.
Классическое определение из SEBoK про «подход и средства обеспечения реализации
успешных систем» еще более «внутреннее», чем про системный подход в голове, поскольку
надо быть системным инженером, чтобы его понять. Дело в том, что вас часто будут спрашивать, чем вы занимаетесь в проекте. Если вы хотите использовать международный опыт системной инженерии, то придется доходчиво объяснять, чего вы собираетесь добиться в результате.
Как ни странно, я считаю, что подобная рефлексия наиболее эффективна не в самом начале
работы, а через некоторое время. Вот прямо сейчас.
Что такое, например, система отопления? Это много труб, вентилей, насосов и много
чего еще, включая воду. Все это нетривиальным образом связано в пространстве и времени
и вместе позволяет поддерживать определенную температуру воздуха в доме. С одной стороны, можно посмотреть на систему теплоснабжения с точки зрения функций, преобразующих давление и потоки во времени. С другой стороны, можно посмотреть с точки зрения
дискретной последовательности логических операций. С третьей стороны, можно посмотреть с точки зрения статического крепления модулей или последовательности крепления при
сборке. Можно посмотреть с точки зрения пространственного размещения конкретных модулей, а можно нарисовать граф расстояний между компонентами. Все эти представления вме68
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
сте могут дать полное или фрагментарное описание системы. Каждое частное описание будет
интересно определенному стейкхолдеру. Если все стейкхолдеры получат частные описания,
которые они понимают, в виде рабочих продуктов (документов, артефактов), согласуют представленные там модели, то риски провала заметно снизятся. Но ведь системами теплоснабжения занимаются совсем не системные инженеры, а теплоэнергетики. Есть, еще например,
подсистемы электроснабжения, электрические сети, на тему которых у вас сконцентрировался
проект. Там работают инженеры-электрики. А чем же тогда занимаются системные инженеры?
Системная инженерия (системотехника в СССР) пришла из военной темы. Думаю, эти ее
истоки можно смело рассматривать в качестве объяснения этой самой неоднозначности понятия «система». Во-первых, засекреченные разработки. Во-вторых, новые технологий, не имеющие названий. Такие, часто большие, проекты удобно было называть системными, а сами
результаты – системами. Особенность системного проекта в том, что команда проекта отвечает, в первую очередь, за конечный результат, и уровень этой ответственности очень высокий,
и обычно – нет второго шанса, как, например, при пуске ракеты. Необходимость четкого понимания и переосмысления планируемого результата, а также его многосоставность и многоаспектность положили начало системно-инженерному подходу. Это происхождение до сих пор
дает о себе знать, поскольку большинство западных системно-инженерных вакансий сегодня
выставляются предприятиями оборонно-промышленного комплекса и государственного сектора. В современной России это исходное понимание системной инженерии осталось, в основном, в сфере авиакосмоса.
После холодной войны крупных проектов становилось все меньше, и системная инженерия постепенно углубилась в вопросы автоматизированных систем управления. В этот период
она обросла огромным количеством математики и сильно перемешалась с соседней дисциплиной «Исследование операций», сконцентрировавшись на оптимизации и имитационном моделировании. Часто системных инженеров ищут типично АСУшные предприятия. Но это уже
не те системные инженеры из авиакосмоса. На западе эта дисциплина (АСУ) чаще встречается
под названием control systems engineering, хотя соответствующие специалисты любят причислять себя к системным инженерам.
Больше всего системная инженерия пригодилась в информационных технологиях,
поскольку вычислительные комплексы и программное обеспечение для них – до сих пор считаются сложными объектами, а разработка программного обеспечения приравнивается (например, в России) к научной работе. Здесь системно-инженерный подход и практики быстрее всего
начали развиваться и, в результате, стали задавать темп всей дисциплине.
Сегодня, в большинстве стран, системный инженер ассоциируется с серверной комнатой
и огромным количеством проводов. В России и Германии – это точно так. Во Франции, например, преобладает понимание системной инженерии из авиакосмоса, как и в США. В Британии
по-разному, но, исключительно по моим ощущениям, крен в сторону АСУ.
В общем, у дисциплины непростая история. Если бы меня попросили определить системную инженерию «на понятном языке», пользуясь международным стандартом ISO/IEC 15288,
получилось бы следующее.
Системная инженерия – это подход к организации междисциплинарной
инженерной деятельности, в котором значительная часть времени посвящена
согласованию постановки задачи между всеми участниками проекта из разных
процессов и стадий жизненного цикла на основе пакета моделей (системной
архитектуры), чтобы максимально снизить риски.
Такое определение можно назвать негативным, по сравнению с позитивным вариантом
из SEBoK, где акцент не на снижение риска, а на успех. Я думаю, любая деятельность направлена (ну или должна быть направлена из здравого смысла) на успех, но не каждая – на сниже69
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
ние рисков. Однако, с другой стороны, подход к системной инженерии как к снижению рисков обычно разводит бюрократию, очень страшную бюрократию, поэтому всегда помните, что
одно дело – объяснить кому-то, а другое – понять самому.
Итак, если отталкиваться от ISO 15288, то можно сказать, что системные инженеры –
это специалисты, реализующие один или несколько процессов из блока технических процессов.
Системно-инженерные менеджеры – это специалисты, реализующие один или несколько
процессов из блока процессов технического управления . За все технические процессы отвечает
главный системный инженер, а за все процессы технического управления – руководитель
проекта, но работать им приходится всегда вместе, потому что все очень связано. За обеспечивающие процессы обычно отвечает технический директор.
Перед развертыванием системно-инженерной деятельности необходимо связать между
собой четыре блока процессов жизненного цикла. Системно-инженерных процессов много
и вам следует хорошенько разобраться в каждом из них отдельно, прежде чем говорить
о внедрении методологии. Лучше всего назначить на каждый процесс ответственного сотрудника. Всегда помните про процессы поставки и приемки. Менеджеры высшего звена не смогут оперативно управлять этими процессами, руководители проектов будут заняты другим,
а инженеры в этом не компетентны.
70
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 10. Управление информацией
Каким бы скучным занятием не казалось моделирование процессов, жизнь становится
значительно интересней, когда начинаешь ставить эти процессы на практике. Чтобы сдвинуться с мертвой точки, вам нужно вписать идею монитора домашней электросети в определенную модель жизненного цикла и четко спозиционировать продукт в бизнес-контексте. В одиночку вам этого не сделать, однако без вашей помощи, даже если кто-то уже готов ответить
на эти вопросы, бизнес-контекст не свяжется с инженерным контекстом, а затем и с самими
техническими решениями. Для начала вам нужно синхронизироваться с актуальным пониманием директора. Вот он сидит в своем кабинете.
– Извините, можно вас побеспокоить? – спросили вы, осторожно приоткрыв дверь в кабинет.
– Да, заходи, – кивнул директор и повернулся к вам, – Как раз хотел тебя позвать. Какой
вопрос?
– Какая сейчас рабочая бизнес-модель? – спросили вы.
– То, что вы с ребятами сделали, показали нескольким потенциальным партнерам, в том
числе Александру Сергеевичу, – улыбаясь начал директор, – Ну и всем очень понравилось.
Правда, партнеры сразу захотели сильно увеличить функционал этой штуковины, но в пределах разумного. В общем, поздравляю! У нас есть большой заказ. На следующей неделе начнутся встречи с техническим руководством – будем работать над техническим заданием и договором.
– Ничего себе!
Очень скоро стало известно, что особенностью умного продукта с точки зрения партнеров стала возможность дистанционного включения и выключения приборов и настройка сценариев их взаимодействия. Выходит, системная архитектура снова нуждается в переработке.
Многие противники системной инженерии убеждены, что рисование
многочисленных архитектурных схем – бессмысленная работа, потому что
делать, в конечном счете, будут все равно по-другому. Вроде как, поэтому
достаточно верхне-уровневых схемных решений. Как всегда, в любом деле,
это мнение не лишено здравого смысла. Наиболее классическим примером
ошибочного понимания системного проектирования является декомпозиция
до деталей. Такое понимание свойственно инженерам-конструкторам, а также
программистам.
С точки зрения рабочих продуктов метод системной инженерии должен обеспечивать прослеживаемость (трассировку) через потребности, требования, проектно-технические
решения и рабочую документацию. Глубина прослеживаемости характеризует глубину внедрения методологии системной инженерии на предприятии. Вовсе не обязательно в каждом
проекте связывать конструкторскую документацию на конкретную деталь с потребностью
стейкхолдера. Для космической миссии это может быть необходимо, а для коммерческого продукта на потребительском рынке дешевле быстро внести исправление, чем затягивать разработку, даже если речь идет, например, об отзыве автомобилей. Прослеживаемость от технических решений до сервис-деска, например, тоже является предметом системной инженерии.
Если глубина внедрения касается декомпозиции системы, то можно еще говорить об охвате
внедрения методологии системной инженерии, который связан с количеством стадий жизненного цикла, на которых выстроены процессы, обеспечивающие прослеживаемость, а следовательно – возможность валидации и верификации.
71
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Возможно, в каких-то компаниях системная инженерия и внедрена
полностью «в глубину и в ширину», но их очень мало. Поскольку, как мы уже
обсудили, назначение системной инженерии плотно связана с минимизацией
рисков, то и внедрение должно быть там, где эта неопределенность наиболее
высока и болезненна.
Системная инженерия должна обеспечивать согласованность работ (оркестрацию)
с позиции проектного менеджмента. Учитывая, что за разные работы отвечают разные коллективы или даже предприятия, порой имеющие разные отраслевые стандарты – главной зоной
ответственности системных инженеров является именно удержание целостности между всей
проектной документацией, создаваемой в разных процессах и стадиях.
Изобразим на схеме ту системно-инженерную деятельность, которую вы самостоятельно
вели в прошлой части (рис. 22), не забывая про обозначения из рис. 21. Будем называть
эту часть процессов – определение системы. Обратите внимание, что несмотря на итеративность системно-инженерной деятельности, ее нельзя назвать последовательной. Все процессы
(бизнес-функции) работают одновременно. Для моделирования коммуникаций между процессами будем использовать бизнес-объекты. Определение бизнес-объекта в спецификации языка
Archimate достаточно абстрактно и не имеет дословного перевода на русский язык.
Позволю себе использовать бизнес-объект в качестве некоторых
смыслов (концептов), которыми обмениваются процессы в ходе работы.
Работа системных инженеров связана именно со смыслами, а не только с документами,
которые являются лишь представлениями смыслов в определенный момент времени. Отношения между бизнес-объектами и процессами имеют тип доступ. В нашем случае процессы взаимодействуют через совместную работу над объектами, поэтому разрешены чтение и запись
(стрелки в обе стороны).
Рис. 22. Схема деятельности по определению системы в нотации Archimate
72
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Допустим, деятельность по определению системы запущена приказом (Соб1) и стартует
процесс бизнес-анализа (Пр17). Я не буду переписывать в текст все обозначения с рисунка 22,
но постараюсь изложить основную логику взаимодействия процессов. Бизнес-анализ (Пр17)
должен в конечном счете привести к появлению технико-экономического обоснования (Док1),
используя возможности всех остальных процессов. После создания моделей бизнес-контекста и списков стейкхолдеров должны быть уточнены потребности и требования, рассмотрены
варианты архитектуры, критическое технологии. Если можно так выразиться, на технико-экономическое обоснование (Док1) работают все процессы определения системы, но с разной
интенсивностью. Если ТЭО одобрили, то обычно дело идет к подписанию контракта. К этому
контракту нужно приложить техническое задание на целевую систему (Док2), работа над которым также выполняется всеми процессами определения системы одновременно: дорабатываются модели бизнес-контекста, уточняются цели, стейкхолдеры, исследуется использующая
система, потребности, требования, а также вырабатываются варианты архитектурных и технологических решений. После заключения контракта продолжается работа над системными требованиями (Док3) до тех пор, пока не становится возможным сформулировать технические
требования к каждому модулю (Док4), чтобы объявить тендер или, просто, запросить технические предложения (Док5) у потенциальных подрядчиков (Соб2). Когда речь идет о больших
системах, этот процесс от приказа об инициации проекта (Соб1) до приказа о закупках (Соб2)
может идти годами.
Системный анализ помогает убедиться, что технические предложения, формирующиеся
в процессе определения дизайна (Пр21), а также и вся остальная документация на систему
с разных уровней – отвечают актуальным бизнес-целям, потребностям и требованиям стейкхолдеров. Чтобы системный анализ работал, необходимо обеспечить прослеживаемость через
все те смыслы, которые были рождены в процессе работы. Эту прослеживаемость обеспечивают матрицы трассировки (Об12), которые связывают системные требования, архитектуру
и дизайн, и матрицы соответствия функциональных и структурных элементов (Об15), а также
связи между бизнес-целями, стейкхолдерами, потребностями, требованиями стейкхолдеров
и системными требованиями.
На деле системная инженерия значительно проще, чем в виде схем и методологических
текстов. Впрочем, так можно сказать про любой процесс. Но сейчас нам нужно поставить
процессы, поэтому формализация необходима. Взглянем на всю карту технических процессов
(рис. 23) укрупненно. Чтобы на данной стадии не погружаться в детали всех процессов, которые мы еще не испытали на практике, воспользуемся элементом языка Archimate по названием «Бизнес-взаимодействие». Действительно, как мы видели на рисунке 22 – все процессы
определения системы взаимодействуют (Взд1) ради общего результата. То же самое касается
и процессов реализации системы (Взд2), а также процессов развертывания и использования
системы (Взд3). Сейчас нам важно понимать, что взаимодействие по определению системы
позволяет создавать документацию на систему (Пт1) – это поток документации. Взаимодействие по реализации системы (Взд2) формирует поток воплощенных систем (Пт3). От взаимодействий по реализации (Взд2), развертыванию и использованию системы (Взд3) приходит
обратная связь к взаимодействию по определению системы (Взд1) в виде потоков запросов
на изменения (Пт2, Пт4).
73
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис 23. V-Модель жизненного цикла системы в нотации Archimate
На рис. 24 представлена одна из возможных схем взаимодействия процессов инженерного менеджмента. В левой части диаграммы размещены документы, создаваемые процессами
определения системы. Как мы уже замечали ранее, над этими документами системный инженер и менеджер работают вместе – с разных сторон. В ТЭО (Док1) будут приведены планы
и бюджеты, в ТЗ (Док2) – работы и календарный план, системные требования (Док3) позволят
контролировать сложность системы и оценивать работы, технические требования к модулям
(Док4) станут основой для выбора оптимальных конфигураций.
Рис. 24. Схема взаимодействия процессов инженерного менеджмента с точки зрения
определения системы
Остальная часть диаграммы содержит взаимодействия процессов, описанные с помощью
отношения типа «обслуживание». Процессы управления принятием решений (Пр11) и управления рисками (Пр12) являются обслуживающими по отношению к процессам планирования
проекта (Пр9), оценивания и контроля проекта (Пр10), и управления конфигурацией (Пр13).
Всю эту деятельность обслуживает процесс управления информацией (Пр14), а его, в свою
очередь, обслуживает процесс измерений (Пр15). На обеспечение качества (Пр16) работают
практически все процессы, кроме первого звена. Конечно, это далеко не полная модель взаи74
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
модействия процессов технического управления. Она нужна нам, чтобы явно указать на совместную работу менеджеров и инженеров над документацией.
Чтобы не потерять целостность, нужно часто проверять порождаемые смыслы, как мы
ранее говорили, на непротиворечивость и связность. Эту работу лучше поручить машине.
Для этого необходимо все бизнес-объекты представить в виде объектов данных, связать их
в схему данных и обеспечить работу с этими данными через программные компоненты. На рис.
25 представлена диаграмма, демонстрирующая как это можно сделать. Голубыми цветом обозначаются элементы программного обеспечения. Стрелки от программных элементов к бизнес-объектам – отношения реализации. То есть конкретный объект данных является реализацией бизнес-объекта (смысла, концепта). Преобразование этих смыслов в строгий вид
объектов данных (например, записей в БД) – очень важная часть работы системного инженера.
Это как после продолжительного размахивания руками и объяснения на пальцах мы начинаем
оформлять мысли по регламенту.
75
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
76
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 25. Программное обеспечение системной инженерии и основные объекты данных
Возможно, из-за необходимости работы с базами данных и программным обеспечением,
системных инженеров стали путать с ИТ-специалистами. На самом деле, как вы понимаете,
поставить процессы системной инженерии и заниматься самой системной инженерии – две
очень разные вещи. Тем не менее, никто кроме системных инженеров не понимает, что такое
системная инженерия, а поэтому приходится ставить процессы и разворачивать ПО самим.
Для начала вам будет достаточно следующих функций:
Ф1. Системный анализ – именно эта функция должна выдавать вам оценки целостности,
связности, оптимальности и т. д.
Ф2. Анализ и визуализация данных – результаты системного анализа могут быть многомерными графиками, теплокартами и т. д. Все это нужно как-то отображать и анализировать.
Ф3. Управление базой данных – все результаты моделирования и анализа нужно куда-то
записывать и откуда-то читать по определенным правилам.
Ф4. Редактирование диаграмм – без этой функции будет очень трудно вносить правки
в модели.
Как вы понимаете, имея все эти диаграммы, мы можем написать целое ТЗ на внедрение
процессов системной инженерии, но не будем сейчас распыляться. В вашем случае с умным
бизнес-центром времени очень мало, поэтому именно вам придется выступить коммуникатором между процессами. Какой же минимальный инструментарий системного инженера, обеспечивающий целостность системы и прослеживаемость?
К всеобщей радости новая версия языка Archimate 4.0 уже адаптирована к проблематике
кибер-физических систем, а огромное количество методов системного анализа уже реализовано на языке R.
Киберфизическая система обрабатывает потоки материалов (в т.ч.
информации и энергии), встроена в бизнес-процессы, управляется
программным обеспечением, людьми.
Умный бизнес-центр является типичной киберфизической системой. Если вам нужно
определить систему другого рода, например, «легковой автомобиль», то для обеспечения процессов системной инженерии нам точно также будет более чем достаточно Archimate. При
этом у вас всегда будет возможность легко добавить в архитектуру автомобиля «кибер-компоненты» типа искусственного интеллекта, подробно описать бизнес-контекст, использующую
систему, потребности и стейкхолдеров. На рис. 26 представлен вариант джентельменского
набора системного инженера, с которым можно начать управлять информацией. Зеленым цветом выделены элементы, относящиеся к технической реализации. В данном случае символом
«А» маркированы артефакты (рабочие продукты), представляющие собой текстовые файлы.
Эти «зеленые» файлы нам с вами и предстоит сделать, чтобы начать управлять информацией.
77
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 26. Джентльменский набор системного инженера
Таким образом, ничего не мешает нам продолжать пользоваться языком Archimate,
но уже для описания целевой системы, а не обеспечивающей. Учитывая, что Archimate предназначен для проектирования архитектуры предприятия (TOGAF), необходимо сделать мэппинг на системно-инженерные объекты, с которыми мы планируем работать (рис. 27). Жирными линиями на рис. 27 обозначены отображения системно-инженерных объектов данных
в элементы языка Archimate. Я сознательно не использую в этом мэппинге уровень приложений из Archimate (голубой), поскольку им занимается программная инженерия. С точки зрения системного инженера, программа – это артефакт, расположенный внутри структурного
элемента (например, рабочей станции).
Вам вряд ли захочется на такой ранней стадии знакомства с системной инженерией покупать дорогостоящие информационные системы или профессиональные сервисы, поэтому бесплатный программный пакет Archi с четким мэппингом на системную инженерию – вполне
неплохой вариант. Я бы даже добавил, что коммерческие системные моделеры часто уступают
в гибкости и удобстве open source средствам.
78
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 27. Мэппинг системно-инженерных концептов и элементов языка Archimate через
объекты данных
Бизнес-контекст (правая сторона рисунка) представлен бизнес-структурой (например,
организациями, которые в Archimate моделируются с помощью элемента «бизнес-роль»),
связанными бизнес-интерфейсами (например, договорами). Стрелка, проходящая через бизнес-интерфейс, показывает на получателя (в прошлой части направление показывало движение денежных средств). Бизнес-структура может декомпозироваться (например, у строительной компании может быть ИТ-отдел). С другой стороны, бизнес-контекст представлен
бизнес-функциями (например, «разработать документацию на систему»), между которыми
79
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
есть функциональные связи (например, «документация на систему»). Бизнес-функции могут
декомпозироваться (например, «разработка системы» может разбиться на разработки подсистем). Бизнес-функции характеризуют бизнес-состояния (например, состоянием может быть
стадия разработки). Состояния могут переходить одно в другое.
Элемент бизнес-структуры – это, с одной стороны, субъект деятельности, а с другой
стороны – стейкхолдер, то есть заинтересованная сторона, относящаяся к целевой системе
своей бизнес-функцией. Фиолетовым цветом на схеме обозначены элементы целеполагания.
От стейкхолдеров во многом зависят бизнес-цели. Их формулированием занимаются, как правило, менеджеры, но системный инженер должен правильно отобразить эти цели в своих моделях.
Бизнес-цель, как минимум, должна быть конкретной (то есть определять
бизнес-интерфейс) и измеряемой (то есть определять бизнес-связь).
Фактически, бизнес-цель связывает функциональную и структурную модели бизнес-контекста. Нельзя забывать о сроках. Одна и та же цель с разными сроками может иметь принципиально разные инженерные решения.
Потребности стейкхолдера возникают из недостатков бизнес-функций и связей между
ними. Именно потребности стейкхолдера являются отправной точкой в формулировании
системных требований. Через определение потребностей мы перебираемся из бизнес-контекста (правая сторона рисунка) в инженерный контекст (левая сторона рисунка).
Для моделирования потребностей будем использовать элемент
языка «драйвер», поскольку именно драйвер (согласно определению
из спецификации Archimate) заставляет стейкхолдера что-либо изменять
и определяет мотивацию стейкхолдера.
Когда стейкхолдер требует что-то от системы – будем называть это требованием стейкхолдера. Такое требование должно удовлетворять потребность стейкхолдера через системное требование, либо становиться ограничением. Многие требования стейкхолдеров известны
заранее – это стандарты.
В элементах языка Archimate нет однозначно подходящего варианта
для моделирования требований стейкхолдера, но надо отметить, что и сами
требования стейхолдера не очень-то определены в литературе и стандартах.
Если учесть, что требования стейкхолдера в конечном счете попадают
в техническое задание на систему, а потом уже анализируются, а также учесть,
что требования стейкхолдера носят, как правило, общий характер, то ближе
всего будет элемент «принцип».
То есть стейкхолдеры в техническом задании на систему могут лишь определить основные принципы. Как я уже писал выше, требование стейкхолдера может реализоваться через
системное требование, либо ограничение.
Системное требование связывает функциональную и структурную
модели системы, поскольку должно быть, как минимум, конкретным
(определять интерфейс) и измеряемым (определять функциональную связь).
Функции связаны между собой функциональными связями (например, электрическим
сигналом), могут декомпозироваться (например, детектирование может разбиться на получение сигнала, распознавание и формирование ответа), а также характеризуют состояния (например, функция ввода параметров характерна только для состояния настройки). Конструкции
связаны через интерфейсы (например, wifi-интерфейс между датчиком и элементом управле80
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
ния) и могут декомпозироваться (например, умная розетка может состоять из коробки, датчика и передатчика).
Таким образом, в этом фреймворке мы можем связывать инженерные решения с бизнес-целями. То есть мы можем всегда проверять, ведет ли текущая архитектура системы
к успеху всего бизнеса или нет.
Управление информацией – один из ключевых процессов жизненного цикла, поскольку
обеспечивает коммуникации между заинтересованными сторонами. Организуйте себе рабочее место с системно-инженерным программным обеспечением и ваша эффективность существенно увеличится. Описание процессов системной инженерии в вашей организации поможет
разобраться в текущей ситуации и найти решения многих проблем. Для начала работы вам
будет достаточно редактора диаграмм и математического пакета с открытыми форматами данных.
81
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 11. Моделе-ориентированный бизнес-анализ
Обычно бывает так: на столе менеджеров лежит ТЗ, переполненное абстрактными формулировками типа «система должна быть эффективной», «системна должна быть кроссплатформенной», а у инженеров на столе – схемы с мельчайшими подробностями реализации. Все
понимают, что ТЗ – это чтобы деньги получить, а «мы тут работаем – не мешайте нам».
Часто так бывает, что процедура согласования инженерных решений
с большим начальством представляет собой определенного рода магический
обряд, который способны делать лишь опытные шаманы.
В ИТ-сфере то же самое: в системе управления задачами висят тысячи user story, в базе
знаний «тонны» страниц с какой-то логикой и мокапами, но когда приходит запрос на изменение – у всех стресс – никто не знает, на что повлияет это изменение. Когда система еще
маленькая – легко это изменение внести, потом проверить и сделать релиз. Но когда система
разрослась (тем более, когда требуется производство) – проверки последствий каждого изменения могут стать слишком затратными и по времени и по деньгам.
Пожалуй, именно потребность в управлении изменениями заставляет
многие компании обратить внимание на системную инженерию.
Однако, если компания попытается с наскоку воспользоваться, например, CPS
Framework, специально разработанном для кибер-физических систем не без системного подхода, то очень скоро может выяснится, что ничего из этого не выходит. В большом количестве
аспектов, интересов и практик трудно разглядеть приоритеты, специфику и много чего еще.
Именно поэтому мы начали с самых базовых аспектов.
После того, как вы узнали, что стейкхолдеры задумали поменять требования к системе
мониторинга электросети, самое время перерисовать схемы с салфеток (из 1 части) в среду
Archi. Начнем с бизнес-анализа. Новая функциональная модель бизнес-контекста, с учетом
всех прошедших совещаний, представлена на рис. 28. Новая структурная модель бизнес-контекста представлена на рис. 29.
В этих представлениях продуктом называется та система, которую вы
проектируете.
82
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 28. Функциональная модель бизнес-контекста
83
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 29. Структурная модель бизнес-контекста
Чтобы определение целей и стейкхолдеров не стало гаданием на кофейной гуще, можно
использовать следующий, уже знакомый вам, инструмент – матрицу соответствия. Бизнес-цели
лежат «между» бизнес-интерфейсами и бизнес-функциональными связями (рис. 30), а стейкхолдеры лежат «между» бизнес-функциями и бизнес-структурами (рис. 31).
Диаграммы могут быть не очень эстетичными – вы в этом еще
убедитесь на практике – они должны быть рабочими инструментами,
а не произведениями искусства. Помните, что системные модели, в первую
очередь, нужны, чтобы ничего не забыть, а не чтобы ими любоваться.
84
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 30. Матрица определения бизнес-целей
Там, где есть соответствие между бизнес-интерфейсом (БИ) и бизнес-функциональной
связью (БФС) – системный инженер ожидает найти бизнес-цель. Для трассировки используется
отношение типа «реализация». Не надо путать функции с процессами. На выходе функции
должен быть вектор. Например, «БФС7. Бизнес-центр» в нотации функциональной модели –
это вектор характеристик бизнес-центра, а не сам бизнес-центр. Бизнес-цель (то есть желаемые
координаты вектора бизнес-функциональной связи, достигаемые а рамках бизнес-интерфейса)
может быть еще не сформулирована, но место под нее лучше забронировать заранее.
Формулировка бизнес-цели должна быть от лица заказчика целевой
системы.
В матрице со стейкхолдерами ситуация чуть сложнее. Чтобы не запутать диаграмму, все
стейкхолдеры-регуляторы вынесены наверх одним каскадом.
Как правило, бОльшую часть ТЗ на систему занимают требования
регуляторов, скопированные из стандартов.
Нижняя часть матрицы организована привычным образом. Стоит обратить внимание,
что одна бизнес-структура может представлять собой разных стейкхолдеров. Как и в случае
с целями, не все стейкхолдеры могут быть представлены в проекте на момент рисования диаграмм, но забронировать им место нужно как можно раньше.
85
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 31. Матрица определения стейкхолдеров
В системной инженерии более правильно называть целевой системой ту
систему, жизненный цикл которой мы моделируем.
Это нужно для того, чтобы все инженеры в проекте называли целевой системой одно
и то же. С этой точки зрения, сейчас мы уже уверенно должны говорить, что в нашем с вами
конкретном случае целевая система – это бизнес-центр. Поскольку вам еще предстоит
сделать ТЭО с учетом новых пожеланий стейкхолдеров, то учтите, что обосновывать вам придется – разработку блока управления питанием приборов в подсистеме электроснабжения бизнес-центра. Использующая система для этого блока – подсистема электроснабжения. Она для вас наиболее интересна, чтобы включиться в проект. Использующая система
целевой системы – это некая бизнес-инфраструктура, о которой мы пока очень мало знаем.
Знать о ней, конечно, полезно, чтобы определять реальные потребности и предлагать эффективные решения, но в вашем случае более правильно отложить моделирование инфраструктуры до лучших времен, а пока больше внимания уделить ближайшим стейкхолдерам. Нужно
будет поработать с потребностями этих ближайших к вам стейкхолдеров, чтобы понять – чем
именно и как надо управлять. Тогда слово «управление» мы сможем заменить на что-то более
точное.
Напомню, что еще недавно менеджеры обсуждали стратегию продаж умных приборов
оптом и в розницу. Параллельно обсуждался вопрос включения в проект бизнес-центра. Никто
не запрещает вам смоделировать альтернативный бизнес-контекст, в котором вы тоже планируете работать. Конечно, в таком случае будет больше противоречий в целях, но, возможно,
в интересах бизнеса лучше хорошо поработать и придумать, как эти противоречия разрешить, чтобы не оказаться в ситуации, когда проект закончился, а ваш продукт больше никому
не нужен. Оставлю задачу моделирования альтернативного бизнес-контекста для
уважаемого читателя.
Итак, что дальше? Например, Ц4 – построить бизнес-центр за миллион дукатов через два
года, а Ц9 – оказывать услуги бизнес-центра, включая аренду офисов, с прибылью миллион
дукатов в год через год после окончания строительства. При этом Ц2 – тратить на инфраструктуру не более 100 тысяч дукатов в год. Как мы видим: одни цели влияют на другие. Напомню
также, что бизнес-цели определяются от лица заказчика целевой системы, ведь все обоснования нужно делать для него.
86
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
То есть наличие или отсутствие вашего управляющего блока влияет
на все остальные цели в бизнес-контексте.
Схема влияния целей друг на друга представлена на рисунке 32. Схему надо читать следующим образом: каждая «Ц» – это функция, на выходе которой набор целевых показателей
(вектор), а на входе целевые показатели из другой «Ц» (тоже вектор). Конечно, можно попробовать перевести эту схему на язык математики, но чаще всего закономерности между целями
не тривиальные. На ранних стадиях проекта чаще всего выполняют несложные расчеты сроков и бюджета. Сами же взаимосвязи нужны в больше степени для принятия решений, когда
в проекте предлагается что-то поменять. В таком случае надо всегда иметь под рукой чек-лист
со всеми целями, на которые оказывает влияние ваш продукт.
Рис. 32. Схема взаимосвязей между бизнес-целями
Чтобы четко определить Ц6 – стоимость вашего продукта, необходимо решить следующую задачу совместно с командой менеджеров:
– продукт должен привлекать не менее x 1 дополнительных клиентов;
– стоимость продукта должна быть не больше x 2 доли стоимости арендной платы, полученной от привлеченных клиентов;
– обслуживание продукта должно увеличивать обслуживание бизнес-центра не более чем
на x3;
– использование продукта должно уменьшать инфраструктурные затраты бизнес-центра
не менее чем x4;
– инфраструктурные затраты не продукт должны быть не более x 5;
– бизнес-центр с продуктом должен приносить прибыль не менее чем на x 6 процентов
больше.
Со сроками можно провернуть аналогичную работу. Для инженера срок и бюджет являются самыми понятными и важными ориентирами, которые приходят со стороны менеджмента. Если эти ориентиры удается строго обосновать и уложить в бизнес-модель, то споров
вокруг этого вопроса становится значительно меньше, а, собственно, на инженерию – времени
остается значительно больше.
Теперь чтобы ассоциировать стейкхолдеров с целями можно было бы сделать аналогичную матрицу соответствия (что, в целом, правильно), но учитывая, что в данном случае почти
все стейкхолдеры влияют на почти все цели, а времени у вас не очень много, то проще сделать
следующий хитрый ход. Введем понятие интегральной цели. Это такая цель, которая фактически состоит из всех «Ц». Схематически этот лайф-хак представлен на рис. 33.
87
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 33. Связь целей и стейкхолдеров через интегральную цель
В Archi имеется штатное средство для визуализации полного графа со всеми элементами.
Выглядит это как на рис. 34. Ничего особенно интересного с этим инструментом не сделаешь, поэтому давайте сейчас проделаем небольшое упражнение, которое еще пригодится вам
в будущем. Нам для этого потребуется среда R с установленным пакетом iGraph. Из Archi сделаем экспорт модели в формат CSV. Затем напишем следующий скрипт для R (код 1) и запустим его. В окне вывода увидим следующее изображение (рис. 35). Будем считать это нашим
небольшим «Hello World».
Рис. 34. Граф со всеми элементами бизнес-модели в среде Archi (не самый удобный
инструмент)
Код 1. Импорт модели Archimate в R
library (igraph)
nodes <-read. csv (»/Users/mizgulin/Downloads/elements. csv»)
links <-read. csv (»/Users/mizgulin/Downloads/relations. csv»)
88
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
#Убираем вершину, соответствующую всей модели
nodes <-nodes [-1,]
#Готовим данные для преобразования в граф
links<-data.frame (from=links$Source, to=links$Target, type=links$Type)
nodes<-data.frame (id=nodes$ID, name=nodes$Name, type=nodes$Type)
#Создаем граф
net <– graph_from_data_frame (d=links, vertices=nodes, directed=T)
#Визуализация графа
plot(net,vertex.size=5, vertex.label=NA, edge.arrow.size=.4, edge.curved=.1,
vertex.label.cex=.5,vertex.color=nodes$type,edge.color=links$type,
layout=layout_with_mds)
Рис. 35. Визуализация графа элементов бизнес-контекста в среде R с помощью iGraph,
метод MDS (разными цветами обозначены типы связей и типы элементов)
Итак, теперь мы имеем не только набор диаграмм, но и полноценную математическую
модель, которую можно использовать для проверок различных бизнес-гипотез. Мы постепенно
будем описывать систему вплоть до модулей и, в конечном счете, модель станет довольно большой.
Использование моделера позволяет подойти к задаче бизнес-анализа со всей строгостью. Для конкретной и непротиворечивой постановки задачи очень важно понимать конкретные и непротиворечивые цели. Практики системной инженерии помогают однозначно
определять цели и стейхолдеров, а также бизнес-модель, тем самым сближая инженерную
и менеджерскую дисциплины. Адекватные действительности диаграммы могут стать основой для математической модели, которая, в свою очередь, поможет в принятии решений.
89
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 12. Моделе-ориентированная
работа со стейкхолдерами
Основной интерес стейкхолдеров к той или иной системе связан со стадией эксплуатации. Бизнес-функция «БФ6. Использовать бизнес-центр» концентрирует в себе требования
и потребности стейкхолдеров. Теперь, когда бизнес-цели определены и, может быть, даже
рассчитаны целевые экономические показатели, следует взглянуть на использующую систему
нашего блока управления, не забывая о том, что целевая система – это бизнес-центр. На рис.
36 представлена функциональная модель системы электроснабжения в бизнес-контексте.
Рис. 36. Функциональная модель системы электроснабжения бизнес-центра в бизнес-контексте
Функция бизнес-центра «Ф (-2). Обеспечить комфортные условия для ведения бизнеса»
является реализация бизнес-функции «БФ6. Использовать бизнес-центр». Электроэнергия
(ФС1) входит в инфраструктурные сервисы (БФС9). Питание прибора – часть пакета услуг
бизнес-центра. Логично, что, арендуя бизнес-центр, вы ожидаете получить возможность включить компьютер в офисе. Однако, кому-то может потребоваться развернуть центр обработки
данных. Таким образом, вам есть, о чем спросить стейкхолдеров. Функция управления питанием приборов (Ф0), которую мы хотим реализовать, пополнилась таким выходом как «ФС6.
Сигнал управления» и входом «ФС9. Команда управления». Нумерация при моделировании
в Archimate сменилась по сравнению с первой частью. Исходная использующая система представлена в классическом варианте абстракции тремя звеньями: получить, обработать (распределить), отдать (питать). Такое представление очень удобно нам, чтобы начать работать с требованиями стейкхолдеров. Для этого нужно найти стейкхолдеров, которые более тесно связаны
90
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
с использованием целевой системы, а затем сопоставить их с входами и выходами использующей системы и проектируемой системы. Получим матрицу как на рис. 37.
Рис. 37. Матрица определения требований стейкхолдеров
Необходимо убедиться, что у каждого стейкхолдера, который относится к использованию
целевой системы (бизнес-центра), имеются (либо не имеются) требования к перечисленным
на рис. 37 функциональным связям.
Требования стейкхолдеров правильнее формулировать наиболее близко
к тому, что было реально сказано или написано стейкхолдером.
ТСХ17, например, является блоком требований конкретного стейкхолдера к конкретной функциональной связи, который может быть декомпозирован (рис. 38). СХ17 (арендатор) наверняка имеет требования к «ФС9. Команда управления» типа ТСХ17.1: «Должна быть
возможность одновременно включать или выключать все приборы в офисе». Другой пример:
регулятор инфраструктурных сервисов (СХ15) обычно выдвигает требования к потреблению
электроэнергии (ТСХ1).
Формулировки требований стейкхолдеров нужно, по возможности,
сопровождать ссылками на стандарты, нормативы, законы, приказы,
постановления, протоколы и т. д.
Важно помнить – требования стейкхолдеров обязательно нужно связывать с самими
стейкхолдерами, чтобы всегда можно было узнать, кто выдвинул требование. Если вы выдвигаете требования самостоятельно, пытаясь догадаться, что стейкхолдер считает именно так,
а не иначе – это будет ваше требование, будь вы разработчик, владелец продукта или кто-то
другой. Требования от команды проекта, конечно, следует тоже собирать, особенно когда речь
идет о рыночном продукте. Такие требования в процессе анализа будут менее приоритетны,
чем требования заказчика, пользователя или других стейкхолдеров, не входящих в команду
проекта. Не увлекайтесь выдумыванием требований.
Рис. 38. Декомпозиция требования стейкхолдера
91
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Требование стейкхолдера, если оно не связано с потребностью (как в случае стандартов
или политики компании), как правило, приводит к появлению ограничения. В случае, когда
потребность удается выявить, то требование стейкхолдера встает на второй план, а исходя
из потребности уже предлагаются системные требования. Вариант представления для сопоставления требований стейкхолдеров с потребностями стейкхолдеров и ограничениями представлен на рис. 39.
В результате анализа требований стейкхолдеров не должно остаться
ни одного требования стейкхолдера без потребности стейкхолдера, либо без
ограничения.
Рис. 39. Представление для сопоставления требований стейкхолдеров, потребностей
стейкхолдеров и ограничений
Вы не сможете сразу сформулировать ограничения, к которым приводят требования
стейкхолдеров без потребностей, но забронировать для них место – полезно уже сейчас, чтобы
потом не забыть. Системные требования напрямую не выводятся из потребностей стейкхолдеров. Они чаще возникают при сопоставлении потребностей и системной архитектуры.
Вы, наверное, уже заметили, что чаще всего проектирование начинается
с технических идей – варианты конструкции известны намного раньше,
чем потребности. Классическое изложение системного подхода, в котором
структура как бы рождается из функционала, я бы отнес к категории мифов.
В реальной жизни у вас не будет времени на рассуждения об абстрактных
функциях некой системы.
Пока вы работаете со стейкхолерами – нужно как можно точнее сформулировать именно
их требования и потребности, а не какие-то другие. Про системные требования и ограничения пока лучше забыть. Работа со стейкхолдерами требует высокой концентрации и терпения,
поскольку польза от результата этой работы напрямую зависит от количества стейкхолдеров,
которых удалось охватить в процессе работы. Если не выдумывать за других – такая работа
действительно становится кропотливой, требующей большого количества встреч, звонков, разговоров, совещаний и т. д.
Потребность имеет свой жизненный цикл:
– ощущаемая потребность;
– выявленная потребность;
– формализованная потребность;
– удовлетворенная потребность.
На каждой следующей стадии формулировка и описание потребности должны быть более
точными и адекватными.
Вот уже несколько дней вы занимаетесь моделированием текущего положения
дел. Наконец-то, стало более-менее понятно, какой продукт делает ваша компания. Стало
92
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
понятно, с кем обсуждать требования. Интерес со стороны стейхолдеров был явно продемонстрирован, судя по тому, что сказал вам директор. Все бы хорошо, но разрабатывать в одиночку все модели стало невозможно. Вы сидели за столом в офисе, не выпуская голову из рук.
Был поздний вечер. Внезапно в офис вошел Ингеборг Карлович, весь промокший под дождем,
и вода полилась с его плаща на пол. Он брезгливо бросил верхнюю одежду на кожаное кресло
рядом с входной дверью и начал разговаривать, скорее всего с вами, но глазами обратившись
куда-то в сторону окна.
– Что за безобразие в этих всех проектах-шмаректах… – ворчал он, отряхивая брюки
от мокрой грязи – какие-то бессмысленные бумаги, писанина… кому это все надо?
– Ингеборг Карлович, – вдруг, захотелось вам ответить – а в чем проблема?
– В чем проблема?! – взорвался Ингеборг Карлович – Да как это в чем проблема?! Я
уже вон сколько времени мотаюсь к этим дебилойдам со стопками бумажек, а они нихрена
не могут вменяемого ответить!
– Я, честно говоря, не совсем в курсе. Может быть, я могу чем-то помочь?
– Помочь? – удивился Ингеборг Карлович? – А чем помочь?
– Ну, если у вас есть время сейчас, мы могли бы обсудить…
Ингеборг Карлович неуверенно прошагал до середины офиса, и как-то неловко двинулся
в сторону небольшого столика на несколько мест, как бы приглашая вас неуловимыми поступательно-вращательными движениями всего тела. Вы встали из-за своего рабочего стола и медленным шагом подошли к Ингеборгу Карловичу. Он сел за стол переговоров первым. Вы последовали за ним.
– Все шло своим чередом, пока ты не влез со своими идеями – грозно начал Ингеборг
Карлович, – Мы делали обычную систему управления, которую всегда можно было адаптировать под конкретные хотелки клиентов. У нас был классический проект… а сейчас что?
– Ингеборг Карлович, – ответили вы, – руководство компании, просто, не захотело
финансировать работы без четкого понимания результата. Все чем я сейчас занимаюсь – пытаюсь сформулировать – что должно быть в результате проекта. Ведь то же самое нужно и вам
для защиты в Иннофонде. Сейчас у всех стало появляться общее понимание, и его очень важно
зафиксировать… Наш продукт – блок управления питанием электроприборов для системы
электроснабжения бизнес-центра. Этот блок, если его делать «в лоб», выйдет очень дорогим.
Представляете, если заменить все выключатели света в бизнес-центре на планшеты, насколько
дороже выйдет проект? А обслуживание? Заказчик хочет легкости, простоты управления электрическом, но пока еще не подозревает, насколько коряво все может получиться в результате.
Нам действительно нужна инновация. Нам нужны не планшеты… нужны, быть может, какието дистанционно взаимодействующие объекты из новых материалов. До сих пор совершенно
не ясно, за счет чего мы будем делать бизнес. Я понять не могу, как вы можете что-то планировать в таких условиях…
– Как планирую? Опыт! – захохотал Ингеборг Карлович.
Повисло неловкое молчание.
– Ваш опыт был бы очень полезен для решения нашей общей проблемы, – тихо проговорили вы, – Может быть, вы попробуете вынести на обсуждение с фондом проект по разработке экономичной технологии дистанционного управления электропитанием? Или что-то
еще глубже? Какие-то новые материалы, прикосновение к которым приводит к изменению сигнала…
– Но это же? – хотел возразить Ингеборг Карлович.
– Это та инновация, которая нам действительно нужна для успеха проекта.
Бывший руководитель проекта сидел грустный и подавленный. Он то бегал глазами
по сторонам, то останавливал взгляд на каком-нибудь неподвижном предмете и проваливался
в тяжелые мысли. Он понимал, что давить на вас уже не может, кроме того ему действительно
93
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
была нужна помощь с заявкой. Новый поворот казался очень рисковым, но привлекательным. Даже по формальным признакам получить деньги на новые материалы было значительно
проще, чем на систему управления.
Встреча с техническим руководством случилась через несколько дней. Это были
менеджеры нескольких направлений, отвечающие за разные аспекты функционирования будущего бизнес-центра. Большинство из них искренне не понимали, чем вы занимаетесь, и зачем
нужны все эти умные побрякушки. Разговор бы совсем ушел в сторону, если бы вы не показали
им функциональную модель использующей системы (рис. 36).
– Так, а что за состояния там можно будет посмотреть? – поинтересовался один из участников совещания.
– До сих пор предполагалось, что это будут индикаторы «вкл/выкл», – ответили вы, –
но потом стали думать, что туда можно еще добавить.
– Ну а как этот новый блок будет подключаться? – спросил другой.
– Изначально считали, что блок будет продаваться с комплектом ключей и разъемов,
соединенных преднастроенной беспроводной сетью.
– Сколько же будет стоить такой комплект? – ехидным голосом спросил кто-то.
– У нас есть возможность сделать этот продукт достаточно дешевым, чтобы обеспечить
выгоду в течение первых лет эксплуатации, – декларировал менеджер по продажам, расположившийся рядом с вами.
– Ну а за счет чего? – усомнился кто-то из высшего технического руководства, сверкающий ядовито-зеленым галстуком.
– Ну, как минимум, работы по установке ключей и разъемов выйдут дороже, – заметили
вы, – во-вторых, любая перепланировка будет дешевле, учитывая, что количество проводов
на каждое помещение заметно снизится.
– У нас будет около сотни офисов и более десяти холлов. Давайте выполним расчет,
и убедимся, что ваше решение хотя бы потенциально дает тот эффект, о котором вы говорите, –
предложил один из технических менеджеров.
– Вы не могли бы прислать планы помещений? Если они уже есть… – попросил кто-то
из ваших коллег.
– Да, конечно. Еще не финальные, но уже вполне пригодные планы у нас есть. Сколько
вам нужно времени на расчет?
И здесь я позволю себе сделать комментарий. От того, что сейчас будет сказано, во многом зависит успех проекта, ведь если попросить слишком мало, то можно не успеть или наделать ошибок. Если взять слишком много, то интерес у партнеров может пропасть. Если в такой
ситуации удается уйти от ответа, например, предложив обсудить сроки на следующий день,
когда вы посовещаетесь с техническими специалистами, то будет совсем хорошо. Недели,
с одной стороны, может хватить, но ведь прямо сейчас ваши сотрудники могут быть заняты
другими задачами, поэтому будьте бдительны и не давайте коллегам уступать. Как вы заметили, пока никого особо не волнует содержательная сторона проекта. Всех интересует экономическая целесообразность. Если вы покажете, что экономический эффект есть, то есть бизнес-цели адекватны, то можно будет переходить на тему обсуждения требований. Пока вы
не доказали стейкхолдеру, что бизнес-цели будут реализованы, говорить с ним о требованиях
бессмысленно.
Накопление списков стейхолдеров, требований и потребностей стейкхолдеров в одной
модели помогает удерживать целостность системы. Начните определение требований стейхколдеров с описания использующей системы. Чем больше контекстов целевой системы вы
рассмотрите, тем меньше неожиданностей вас ждет в будущем.
94
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Глава 13. Моделе-ориентированное
системное проектирование
После совещания вы пришли домой, закрылись в комнате, и сразу сели за компьютер.
Работать по ночам на ранних стадиях проектов приходится довольно
часто, при том что никто за это «спасибо» не говорит (а хочется, чтобы
говорили).
У вас до сих пор не перенесена в нотацию Archimate системная архитектура, тем более
что она уже была видоизменена, а эти изменения никто не формализовал, и происходит на данный момент в разработке тоже непонятно что. Примерно через час работы вам удалось смоделировать следующее (рис. 40). Учтены моменты, которые ранее всплывали в процессе проектирования, плюс добавлены новые функции. Схема выглядит более нагруженной, потому
что функциональные связи обозначены блоками, а не стрелками. Преимущество такого представления в том, что интуитивно мы начинаем уделять столько же внимания связям, сколько
и функциям – и это правильно. Стрелки часто выпадают из внимания.
95
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 40. Функциональная модель проектируемой системы (блока управления питанием
приборов подсистемы электроснабжения бизнес-центра)
Далее вы сделали структурную модель, основываясь на спецификациях и прокручивая
в голове новые функции (рис. 41). На структуру ушло тоже примерно около часа. Затем
выполнили трассировку функций и конструкций. Для этого в Archimate есть связь «реализация» (рис. 42). Когда функции и конструкции поставлены в соответствие, можно заложить
основу для системных требований. Для этого предлагается воспользоваться матрицами как
на рис. 43—44. Системный инженер ожидает увидеть системное требование на пересечении
интерфейса и функциональной связи. Это не единственное место, куда можно вписать системное требование, но, пожалуй, наиболее принципиальное.
Часто вы будете сталкиваться со случаями, когда элементу конструкции
не хватает соответствующей функции. Возможно, потребуется еще развивать
96
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
функциональную модель, но пока, для подобного случая, ограничимся
связью системного требования только с модулем, отдавая себе отчет, что
на «моделирование всего» времени не хватит.
Рис. 41. Структурная модель проектируемой системы (блока управления питанием приборов подсистемы электроснабжения бизнес-центра)
97
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 42. Матрица соответствия функций и конструкций проектируемой системы
Рис. 43. Матрица определения системных требований к проектируемой системе
98
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 44. Матрицы определения системных требований к подсистемам
Что ж, если учитывать, что каждое из потенциальных системных требований, которые вы
обнаружили, будет декомпозировано еще на 5—7 в процессе проектирования, то очень быстро
количество системных требований перевалит за сотню. Это на заметку тем замечательным
людям, которые не знают, что писать в техническом задании. При этом системные требования – не всегда короткие и емкие формулировки.
99
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Системные требования к интерфейсу, например, удобнее
формулировать с помощью сценариев, user story, сопровождая разного рода
макетами типа wireframe’s, mockups и т. д.
Когда архитектурные модели были закончены и выполнена трассировка, вам пришло
в голову перенести модель в математический граф с помощью уже знакомого кода (см. код
1). Получилась следующая картина (рис. 45). Графовая модель удобна, чтобы получить одним
запросом полную спецификацию требований. При этом такую спецификацию можно будет
получать после любого изменения архитектуры за пару секунд. Порепетируем с помощью следующего скрипта (см. код 2). На рис. 46 представлен граф с интересующей нас областью.
В этой книге я не буду останавливаться на вопросах построения отчетов.
Вы можете использовать для управления системной моделью графовые или
реляционные базы данных, а может быть еще что-то, например, Issue Tracker
или Project management system. Здесь у каждого свои предпочтения. Давайте
двигаться дальше.
Рис. 45. Граф полной модели Archimate после системного проектирования (визуализация
в среде R с помощью iGraph)
Код 2. Выделение вершин, которые нужны для построения спецификации требований
library (igraph)
nodes <-read. csv (»/Users/mizgulin/Downloads/elements. csv»)
links <-read. csv (»/Users/mizgulin/Downloads/relations. csv»)
#Убираем вершину, соответствующую всей модели
nodes <-nodes [-1,]
#Готовим данные для преобразования в граф
links<-data.frame (from=links$Source, to=links$Target, type=links$Type)
nodes<-data.frame (id=nodes$ID, fullname=nodes$Name, type=nodes
$Type)
#Формируем доплнительный столбец с метками
ss<-strsplit(as.character (nodes$fullname),».»)
for (i in 1:length (nodes$fullname)) {
100
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
nodes$name [i] <– (ss [[i]] [1])
}
#Создаем граф
net <– graph_from_data_frame (d=links, vertices=nodes, directed=T)
#Находим все элементы, связанные с системными требованиями
и раскрашиваем граф
neigh.nodes <– adjacent_vertices (net, V (net) [type==«Requirement»],
mode=«all»)
second.nodes <– adjacent_vertices (net, unlist(neigh.nodes), mode=«all»)
vcol [1:length (V (net))] <-«blue»
vcol [V (net) [type==«Requirement»]] <-«red»
for (i in 1:length(neigh.nodes)) {
vcol[neigh.nodes [[i]]] <– «orange»}
for (i in 1:length(second.nodes)) {
filter<-vcol[second.nodes [[i]]] ==«blue»
vcol[second.nodes [[i]] [filter]] <-«yellow»}
#Визуализация графа
plot(net,vertex.size=10, edge.arrow.size=.4, edge.curved=.1,
vertex.label.cex=.5,vertex.color= vcol,edge.color=links$types)
Рис. 46. Граф с выделенными элементами (красные – системные требования, оранжевые – соседние вершины системных требований, желтые – «соседи соседей» системных требований), iGraph
Графовая модель дает много интересных возможностей, например, можно посчитать
«в одну строчку» матрицу расстояний между системными требованиями и стейкхолдерами,
чтобы упорядочить свою работу над техническим заданием (рис. 47).
101
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 47. Матрица расстояний между системными требованиями и стейкхолдерами
На следующий день бизнес-аналитики сообщили вам, что никакой экономической целесообразности быть не может, пока нет дешевых беспроводных выключателей или панелей управления приборами. Планшет, конечно, можно поставить в несколько
комнат, но не в каждую. То, о чем вы говорили с Ингеборгом Карловичем, стало настоящей
проблемой. Нужен был какой-то коммуникатор, элемент управления – совсем не дорогой.
Перед очередным совещанием вы распечатали структурную декомпозицию и положили на стол
(рис. 48).
102
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
103
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Рис. 48. Структурная декомпозиция проектируемой системы
– И что ты хочешь этим сказать? – поинтересовался директор, расхаживающий вдоль
и поперек переговорки.
– У нас не очень сложный продукт – здесь все его составляющие части. Мне кажется, нам
надо планшет (Б3) и смартфон (Б4) исключить из продукта, но… оставить в системе. Ну, то
есть мы можем прописать к ним требования, спроектировать интерфейсы, но продавать будем
только умные розетки и выключатели поштучно. Если это будет действительно так выгодно, то
наши стейкхолдеры найдут способ решения проблемы с пожарной безопасностью и другими
потенциальными трудностями.
– Ты предлагаешь продавать просто розетки? – удивился кто-то из менеджеров.
– А что?
Пауза.
– Мы, на самом деле, должны очень хорошо спроектировать всю систему, чтобы было
удобно и эффективно, но продавать будем розетки, – пояснили вы.
– Наверное, самое главное тут – приложение для смартфона? – задумался директор.
– Не знаю, ведь сейчас уже довольно много приложений для умных приборов и протоколы уже какие-то сформировались. Может быть, имеет смысл пользоваться чужим приложением…
– Ну уж нет. Давайте лучше попробуем сделать просто очень классное приложение!
Чтобы оно знало расстояние до смартфона, включало и выключало приборы по разным правилам, позволяло мониторить состояние сети и т. д. – предложил кто-то из другого конца комнаты.
– Нечто подобное уже есть для планшета. Леха с Саней делали.
Участники совещания начали говорить все одновременно и уже ничего нельзя было разобрать. Ясно было, что идея отказаться от «своего» планшета всем очень понравилась, хотя
еще недавно казалась невозможной. Ингеборг Карлович тоже присутствовал на совещании,
но молчал. Он думал о том, как сделать нечто вроде электронной бумаги, фактически электронные обои, которые можно было бы использовать для визуализации картинки, например,
со смартфонов, а также для простых манипуляций. На таких обоях можно было бы размещать
выключатели как угодно, а еще можно было бы смотреть фильмы, рисовать схемы и много
всего другого. «Можно было бы менять обои каждый день» – подумал Ингеборг Карлович,
осмотрелся и незаметно вышел из переговорной комнаты. Его заявка была уже почти готова.
Шум не прекращался.
– Чтобы снизить риски, нужно разработать собственное приложение, – отрезал директор, – но, может быть, в будущем мы будем использовать чужое. Готовьте презентацию для
партнеров!
Моделе-ориентированное системное проектирование дает вам больше гибкости при внесении изменений в функционал или конструкцию, позволяет автоматизировать системный
анализ, упрощает коллективную работу над проектом, а использование определенной нотации строго ведет вас согласно методологии, снижая риск нелепых ошибок. Имея многоаспектную модель вы можете смотреть на нее в разных представлениях и, возможно, откроете для
себя много нового о своем продукте.
104
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Кода
Ночью в городе всегда весело. Таксисты сначала развозят подвыпивших людей по барам
и ресторанам, а потом по домам. Огни гуляют вдоль дорог, жужжат моторы, шумят веселые
компании. Город притягивает таинственной возможностью быть вместе с другими людьми,
порой совершенно не знакомыми, при этом без вопросов или каких-то правил.
– Без обязательств, – сказал Саня так громко, что ребята с другого конца барной стойки
перестали разговаривать, – я ей так и сказал!
– Ну ты дае-ешь! – рассмеялась шумная компания.
Прошло несколько месяцев после презентации концепции продукта, которую негласно
назвали «Умные розетки». Все шло очень хорошо, но работы стало на порядок больше, чем
раньше. Вы уже совсем перестали спать. Иннофонд выделил денег на электронные покрытия,
которые придумал Ингеборг Карлович. Вот он сидит на углу и опять о чем-то думает, не отпуская кружку пива.
– Первую половину жизни, пока здоровый и молодой, ищешь такое место, где нет никаких
обязательств, – продолжал Саня, – а потом обнаруживаешь, что здоровья уже нет, а вокруг
люди, которым ты ничем не обязан, и они тебе ничем не обязаны. И начинаешь судорожно
доказывать, как тебе все вокруг должны, но ничего уже не изменишь…
– Я, может, не такой старый, чтобы рассуждать над всей жизнью, но мне это знакомо, –
вступил в разговор Леха, незаметно попивающий зеленый чай – Когда делаешь продукт, надо
всегда думать, как его будут обслуживать и как его будут выводить из эксплуатации.
– Ле-еха, как это цинично, – растянул кто-то.
– Ну, почему сразу цинично? Чтобы продукт дольше работал и приносил хозяевам
деньги, а пользователям помогал решать их задачи, надо значительную часть времени потратить на проектирование интерфейсов, запасных частей, продумать обслуживание. Главное,
чтобы его можно было просто заменить, когда он устареет, потому что эксплуатация устаревшего продукта приносит сплошные проблемы как пользователю, так и создателю. Обычно
такие ситуации именно из-за отсутствия совместимости с другими устройствами. Помню,
на одной электростанции был компьютер 80-х годов с какой-то программой, которая всем
управляла… Ничего подобного уже не делали, не было запасных частей, поэтому все дико
боялись, что с этим компьютером что-то случится. Представляете, как это тормозило их дела?
– Но человек ведь имеет свои цели? – задумался Саня.
– Вот это хороший вопрос. Вот мы сделали умную розетку. Давайте представим, что у нее
есть свои цели, – разошелся Леха, – Ну, я понимаю, что нам это может показаться не столь
значимым, но… что она может хотеть, обладая полноценным интеллектом при своих ограниченных физических возможностях?
– Не так важно, что именно… – задумались вы, – Важно, как это связано с целями создателей и пользователей. Если розетка хочет передавать сигнал на большие расстояния или, просто, получает удовольствие от того, что пользователь остается довольным, то это одна ситуация.
А если розетка хочет больше тока через себя пропускать, то это может идти вразрез с самой
сутью умной розетки.
– Если мы хотим, чтобы устройства в будущем сами догадывались, что мы от них хотим,
то мы тем самым даем им возможность ошибаться. Чем отличается, в таком случае, ошибка
от проявления собственной воли?
Внезапно у вас зазвонил телефон. Все вздрогнули от неожиданности. Было уже около
2 часов ночи.
– Сигнал не передается! – сказали из трубки.
105
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
– Какой еще сигнал? – расстроенным голосом спросили вы. На том конце провода чтото стало шуршать.
– Команды управления не принимаются в двух розетках! – чуть не через слезы завопил
голос на другом конце линии.
– Мы же все проверяли сегодня? Ведь все работало?
Проблема подкралась незаметно. Завтра партнеры планировали проводить плановые
испытания пятидесяти умных розеток. Какие-либо несоответствия могли бы привести к очередному сдвигу сроков проекта. Поскольку все деньги этапа были уже потрачены, то сдвиг
сроков мог оставить кого-то без зарплаты на несколько месяцев.
– Я перед уходом решил еще раз запустить тесты… и вот.
Сил уже совсем не было. Громкая музыка отбивала всякое желание думать. Вы одним
взглядом дали всем понять, что произошло. Надо было ехать. Вы вызвали такси и вместе с группой подвыпивших коллег поехали в офис. Кто-то успел немного поспать по дороге. Кто-то все
время смотрел в окно. Все молчали.
В офисе вас ждал тестировщик Петя. Он так сильно задержался, потому что никак
не мог разгрести свою работу. Неизвестно, откуда ему пришла в голову мысль проверить
умные розетки, но, если ошибка действительно есть, у вас появились шансы спасти ситуацию.
До тестирования оставалось около 6 часов. Когда стали проверять приборы, оказалось, что
20 розеток, а не 2 розетки, иногда не реагируют на сигнал. Их разобрали, стали проверять контакты, наличие дефектов, но все было хорошо – вроде никакого брака. Вы прикинули, сколько
нужно времени, чтобы починить приборы, и сколько – чтобы собрать новые.
– Коллеги, у нас на складе есть комплектующие – давайте сделаем новые 20 розеток, –
уверенно предложили вы.
– Босс, мы же пьяные…
– Вот, Леха не пьяный – он будет за нами следить, – пошутил Саня и тут-же перестал
смеяться.
– Ладно, парни, у нас около 4 часов на работу. Давайте начинать. Все знают, где кофе.
Солнце еще не встало.
Это была длинная ночь, но к утру новые розетки были собраны и проверены. Тестирование прошло успешно, а вам еще предстояло понять, почему вышли из строя те розетки.
Очевидно, такое могло произойти и с новой партией. Вы каким-то чудом добрались до дома
к обеду и моментально уснули прямо в одежде.
106
В. Мизгулин. «Системный инженер. Как начать карьеру в новом технологическом укладе»
Послесловие
«Идет медведь по лесу, видит, машина горит. Сел в нее
и сгорел» (анекдот про управление рисками)
Закончив работу над этой книгой, я понял, что написал только лишь малую часть по сравнению со своим исходным замыслом. Остались еще вопросы управления изменениями, конфигурацией, верификации и валидации, имитационного моделирования, лидерства… да еще
очень много важных тем. Тем не менее, я решил опубликовать эту книгу в таком виде, потому
что даже эти 13 глав (а число 13 мне нравится давно) кажутся мне не очень-то сопоставимыми
с теми реалиями, которые мы наблюдаем вокруг. Я подумал, если эта книга вызовет некий
резонанс в инженерной среде, то я обязательно подумаю над продолжением.
Мне кажется, сегодня очень востребована компетенция разработки технических заданий. Этому почти никого не учат в вузах, а, учитывая ускоряющиеся темпы автоматизации
и роботизации, период устаревания технологий, именно постановка задач (в особенности роботам) станет ключевой компетенцией будущего.
В этой книге я вел с вами диалог с позиции консультанта. Вы выполняли проект, а я
помогал. Я много раз говорил, что тащить на себе все процессы жизненного цикла в одиночку –
плохая идея. Вы заметили, что в конце книги работа стала постепенно забирать все больше
времени от вашего сна. Метод системной инженерии (изложенный в этой книге или в другой)
будет эффективен, когда вы объясните его своим коллегам, поделитесь литературой и будете
работать над моделями коллективно.
И последнее. Вас могло смутить, что, в конечном счете, продуктом вашей деятельности
стала умная розетка. На самом деле, это не ирония. Многие эксперты считают, что системная инженерия хороша только в больших проектах. Я постарался доказать вам, что практики системной инженерии можно вводить в работу постепенно, получая достойные результаты даже в небольших компаниях и стартапах. Начните использовать хотя бы одну практику
системной инженерии там, где риск провала наиболее значителен:
– может не хватить денег или времени?
– продукт может оказаться никому не нужным?
– подрядчики не смогут договориться между собой?
– замысел может оказаться нереалистичным?
– технологии могут быть слишком «сырыми»?
– изменение конструкции может негативно повлиять на потребительские свойства?
Думаю, у каждого, кто занимается инженерной деятельностью, найдется хотя бы один
похожий вопрос.
107
