«Многие называют нас сектой, но денег мы туда не несём». Иван Подобед — о системной инженерии

Системная инженерия — малоизвестное направление в инженерной среде — сулит знания о принципах функционирования сложных систем и умение их создавать. Что это такое, dev.by попросил объяснить Ивана Подобеда, бывшего Director Technology Solutions в EPAM, сегодня Technical Fellow в Awem. Он называет себя архитектором всяких систем и большим энтузиастом системной инженерии.

«Всё труднее было находить гениев, способных уместить в голове атомную станцию»

— Где-то в 50-е годы сообщество инженеров США стало понимать, что системы становятся всё сложнее и всё труднее найти гениев, способных в одной голове уместить атомную станцию или космический корабль. Вот тогда они решили собраться и сформулировать принципы и подходы к работе с такими штуками, которые в голове не помещаются. Так стали появляться первые инженерные стандарты — сначала национальные, потом международные, и вокруг них образовалась большая инженерная тусовка National engineering group, превратившаяся со временем в INCOSE (International Council on Systems Engineering) — Международный совет по системной инженерии.

Практически всё в мире — это системы. Нас окружают технические, программные, аппаратные системы, есть также организационные системы, бизнес-системы и пр. Системная инженерия (СИ) — это подход к созданию и эксплуатации сложных систем. Это способность в любой системе увидеть её особые свойства и применить к ней инженерные знания. Многие инженеры интуитивно так и делают, но в СИ это происходит осознанно.

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

Мы под системным мышлением понимаем мыслительные приёмы при работе с системами. Его главный принцип — все мыслительные приёмы направлены на получение пользы. Никаких абстрактных мыслей об абстрактных системах мы не принимаем — только конкретные системы, которые имеют отражение в реальном мире и реальном времени.

С системным мышлением схожи кибернетика, системная динамика, СМД-методология (СМД- система мыследеятельности) Георгия Щедровицкого, теория неравновесных систем. Советский системный анализ — тоже в этом ряду. Но он, мягко говоря, устарел и на практике инженерным требованиям не отвечает.

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

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

Зная принципы кибернетики и системного мышления, проще осваивать практические навыки — программирование, анализ, управление проектами. Получается такая колонна, но она больше похожа на перевёрнутую пирамиду: снизу — небольшое количество навыков, а чем выше поднимаешься к практикам, тем больше разнообразия. В том же программировании — много парадигм и языков.

СИ в этой пирамиде — где-то рядом с кибернетикой, под ежедневными практиками написания кода. Мы спокойно можем писать на Java, не зная СИ. Но если мы хотим писать огромные проекты — правильно, структурно, в больших командах — то чем более инженерно мы подходим к написанию кода, тем лучше он масштабируется.

«Самоучки вынуждены проходить этот путь через боль и грабли»

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

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

Учат писать хороший код. В лучшем случае — научат писать код с набором паттернов, но общим принципам создания сложных систем, в которых не всё пишется на Java (а многое вообще не пишется), никто не научит, и многие архитекторы, тимлиды, СТО-самоучки вынуждены будут пройти этот путь самостоятельно, через боль и грабли.

СИ — дисциплина не для всех. Без веских причин, ради любопытства, изучать её не стоит. Тем специалистам, кто может расти в своей области без СИ, лучше обойтись без неё.

Но если человек уже изучил все необходимые ему по работе технологии и практики и хочет развиваться дальше, но достигает уровня, когда отдача от новых умений и книг небольшая — вот в этот момент можно попробовать СИ. Она дает совершенно новый, контринтуитивный взгляд на то, что уже было изучено и понято.

Под интуицией понимается возможность мозга делать быстрые выводы. Быстрое, интуитивное мышление — это способность сделать быстрые, неэнергозатратные выводы из вещей, которые очевидны. Вот этот стол — из дерева, вероятно, он крепкий. Есть готовый набор принципов, которые помогают человеку исторически добиваться успеха, не напрягая мозг. Мозг привык двигаться по рельсам, и если ему добавить трудностей, он будет сопротивляться. Это сопротивление и есть то, что мы называем контринтуитивностью.

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

Чему учат на тренингах по системной инженерии? Например, тому, как сложные системы по кусочкам засовывать в голову, не теряя общей картины. О системах можно думать в трёх временах. Первое — время эксплуатации системы. Мысль улетает в будущее: из этого времени мы добываем весь системный контекст, всех, кто будет получать пользу или привлекаться к эксплуатации системы. Второе — время разработки, или дизайн-тайм, когда мы реализуем системные модули и при этом соотносим структурные единицы с функциональными. Третье — время планирования жизненного цикла системы, когда мы думаем о том, какие практики и технологии будем применять во время её создания. Это время дизайна процессов, через которые пройдёт поток работ из второго времени. Такое деление упрощает работу: мы стараемся не смешивать дизайн жизненного цикла, дизайн и синтез системы, а также время эксплуатации.

«Системная инженерия субъективна, и это пугает технарей страшно»

Разделение системы на функциональные и структурные единицы — ещё один мощный принцип системного мышления. Проиллюстрирую на примере ножниц. Ножницы — это система, которая состоит из двух функциональных элементов — лезвий (они режут) и колец (ими мы держим и приводим в действие лезвия). Структурно же ножницы состоят из трёх частей: двух элементов «лезвие+кольцо» и гвоздика. Уже на этом простом примере видно несовпадение функциональной и структурной архитектур, что говорить о сложных системах! Вытащить функциональную декомпозицию более сложных систем в сознание не так просто, особенно для технарей. Это упражнение мозг делать категорически не хочет, но если его приучить, то на многие вещи в процессе работы начинаешь смотреть по-другому. Причём это касается не только технических и программных, но и организационных систем.

Вот ещё пример несовпадения функции и конструкци. В команде функциональные объекты — это роли сотрудников. Допустим, роли тимлида, PM, QA, бизнес-аналитика. При этом несколько ролей, например, QA и бизнес-аналитика, могут выполняться одним человеком. То есть функционально объектов два, а структурно — один. В более сложных системах несовпадение функционального и структурного деления выражено куда ярче, чем в ножницах, и из-за этого совершаются многие типичные ошибки. Чтобы система работала, надо понимать, как она устроена функционально и структурно.

INCOSE определяет СИ как междисциплинарный подход к созданию успешных систем. И тут возникает понятие успешности, которое у каждого своё: у менеджеров — своё, у бизнеса — своё. У системных инженеров успешное решение — то, которое отвечает нуждам всех стейкхолдеров.

Стейкхолдеры в данном контексте — это все, на кого система влияет и те, кто влияет на систему. Это и потребители, и та команда, которая обслуживает систему на этапе эксплуатации, и, конечно, владельцы бизнеса. Хорошо бы в числе стейкхолдеров учесть ещё и «Гринпис». Ведь если бизнес заработал много денег, но убил окружающую среду, то это псевдоуспешная система. Если разматывать эту цепочку дальше, то придёшь к выводу, что СИ субъективна и полностью основана на нуждах стейкхолдеров.

И это пугает технарей страшно. Успешность системы зависит не от того, хорошо ли ты написал код, не от того, правильно ли выстроил структуру системы. Если стейкхолдер сказал, что функция выполняется отвратительно, значит, система неуспешна.

В психологию стейкхолдера — голова болит, проблемы в семье — мы не углубляемся. Мы разделяем человека на функцию и конструкцию. Называя человека стейкхолдером, мы подчеркиваем его роль. Допустим, вы написали прекрасный код, который выдаёт весь бюджет на экран. Но прочитать информацию наш стейкхолдер не может, так как он китаец, а бюджет — на английском. Не учли языковой нюанс — и всё, стейкхолдер недоволен, система неуспешна. СИ призвана учесть все нюансы.

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

«В agile количество попыток не ограничено, у нас попытка — только одна»

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

Но и ватерфолом нас нельзя назвать, правильнее сказать, что у нас — V-модель. Сначала от уровня всей системы мы спускаемся вглубь (словно по одной стороне буквы V) — моделируем, анализируем, декомпозируем, доходя наконец до нижней точки с маленькими подсистемками. После этого по другой стороне V мы поднимаемся вверх, собирая маленькие модули в более крупные, пока не соберём всю систему. И на каждом уровне мы думаем о качестве. Наверху мы думаем о том, как будем принимать систему, на средних архитектурных уровнях — как будем проводить интеграционные и имитационные тесты, на нижних уровнях думаем про модульные тесты, юнит-тесты, API — тесты. За это нас очень любят тестировщики.

СИ появилась, чтобы избежать классических проблем сложных agile-систем. В agile количество попыток, как известно, не ограничено: пробуем, пока не получится. В классической СИ попытка только одна. Если мы строим АЭС, то хотим сделать это не с пятого раза, а с первого. То же самое с запуском ракеты на Марс. Но я бы не разграничивал жёстко сферы применения: мол, СИ — для атомных станций и ракет, а на agile мы «фигульки» проектируем. На самом деле, важно определить баланс между «правильно с первого раза» и «правильно с 15-го раза».

Можно решить, что нас устроит «правильно с третьего раза», и тогда на этапе прототипа можно разок что-то переделать. Таким образом можно соблюдать равновесие между стоимостью, сроками и точностью разработки.

К тому же agile и СИ вполне дружат на уровне маленьких циклов и итераций. Мы очень любим Kanban, потому что он совпадает с концептом жизненного цикла системы: продвижение работ по Kanban — это, по сути, продвижение функций системы по V-модели, добавление ей ценностей, так что на выходе из Kanban мы, как правило, получаем готовую систему.

«Королёвых — единицы, но масштабируемые практики СИ позволяют „производить“ их конвейерным образом»

Меня спрашивают, как человечество жило без СИ и создавало сложнейшие шедевры — пирамиды, соборы, города? Я отвечаю, что всегда есть гении, которые способны уместить в голове грандиозные вещи и которым не нужна СИ. Такие гении есть и сейчас, но их единицы и их нельзя масштабировать. А масштабируемые практики СИ позволяют таких гениев «производить» конвейерным образом. Потому что каждый усидчивый человек с нормальными когнитивными способностями может овладеть практиками СИ.

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

Все космические программы, и NASA, и Илона Маска, прикрыты системными инженерами, и это позволяет им делать вещи, которые раньше давались только гениям. Много системных инженеров работает в Airbus (вся верхушка европейского отделения INCOSE — это инженеры Airbus), в NVIDIA и IBM. Инженеров достаточно, но стены не увешаны постерами с их изображениями — это ведь инженеры, а не поп-звезды. Да, Илон Маск неплохо смотрится в журналах, а инженеры хорошо смотрятся на своих закрытых конференциях и в монографиях.

В Беларуси классических системных инженеров, таких, что учились бы по специальности СИ и использовали все практики СИ, нет. Почему их нет в крупных аутсорс-компаниях? Потому что создание системы требует глубокого погружения в контекст её эксплуатации, работы со стейкхолдерам, бизнесом. На внутренних проектах это возможно. Но с заказчиками компания работает лишь как исполнитель: бизнес-операции и продуктовые стратегии клиента ей не всегда доступны. Да, случаются партнёрские проекты, но эти точечные исключения лишь подтверждают правило.

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

Нет, системный инженер — это не господь бог, который всё видит и понимает. Понимать всё — опасно и вредно: голова взорвётся. Системный инженер осознаёт основные принципы работы системы и двигает её к успеху, при этом ему не надо глубоко копать код или бизнес-домен. Детали мы отдаём специалистам, оставляя себе общую картину.

Многие называют системную инженерию сектой. У нас есть набор своих терминов, принципов, мы можем взять любую штуку, назвать её на непонятном языке и вместе посмеяться. Из-за этого мы похожи на секту, но деньги мы туда не несём. Также мы понимаем, что наша «истина» нужна не каждому, поэтому, неся свет системной инженерии, стараемся не ослеплять каждого встречного. Я — энтузиаст, поэтому не могу совсем не ослеплять, но я себя сдерживаю.

Я к слову «секта» отношусь с юмором. Но недавно встретил группу белорусских математиков, которые пытаются решить все проблемы мира с помощью нескольких формул. И вот на их примере я понял, как далеко может завести фанатизм. Это действительно опасно, если забыть про остальной мир.

Но, к счастью, мы не математики, а инженеры, мы жёстко привязаны к миру. Реальность во времени и в пространстве — это то, от чего ведёт отсчёт вся системность. Система — это функциональный 4 D объект: сущность, имеющая эмерджентное системное свойство, которое больше, чем сумма свойств его подсистем, и которая входит как часть в другие системы. Это определение того, с чем мы работаем, и оно — про мир, про жизнь, про реальность. Поэтому мы не секта.

Место солидарности беларусского ИТ-комьюнити

Далучайся!