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

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

Системная инженерия — малоизвестное направление в инженерной среде — сулит знания о принципах функционирования сложных систем и умение их создавать. Что это такое, 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 объект: сущность, имеющая эмерджентное системное свойство, которое больше, чем сумма свойств его подсистем, и которая входит как часть в другие системы. Это определение того, с чем мы работаем, и оно — про мир, про жизнь, про реальность. Поэтому мы не секта.

По теме
Все материалы по теме

​Список книг по системной инженерии от Ивана Подобеда

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

«Индустрия превращается из спецназа в армию». 47-летний разработчик родом из Одессы — о «кольце инженера», менталитете белорусов, манипуляциях менеджеров и возрасте в ИТ
«Индустрия превращается из спецназа в армию». 47-летний разработчик родом из Одессы — о «кольце инженера», менталитете белорусов, манипуляциях менеджеров и возрасте в ИТ

«Индустрия превращается из спецназа в армию». 47-летний разработчик родом из Одессы — о «кольце инженера», менталитете белорусов, манипуляциях менеджеров и возрасте в ИТ

13 комментариев
Бесплатный тренинг для инженеров-программистов в Promwad (набор до 7 марта)
Бесплатный тренинг для инженеров-программистов в Promwad (набор до 7 марта)

Бесплатный тренинг для инженеров-программистов в Promwad (набор до 7 марта)

[Видео] Тестирование теплового поведения печатных плат
[Видео] Тестирование теплового поведения печатных плат

[Видео] Тестирование теплового поведения печатных плат

Lean в Дражне. Как белорусские инженеры работают по японским стандартам
Lean в Дражне. Как белорусские инженеры работают по японским стандартам

Lean в Дражне. Как белорусские инженеры работают по японским стандартам

12 комментариев

Обсуждение

3

>Минимальная позиция в ИТ-компании, на которой специалисту может быть полезна СИ, — это тимлид или архитектор.
Ерунда, умение оперировать иерархией систем полезна на любом уровне. Знания СИ применимы не только при проектировании, но и при анализе, а анализ нужен рабочим любой квалификации.

Утверждение про гибкую/водопадную разработку тоже стрёмное. Методика организации разработки — это компонент системы организации работ над проектом. Выбор методики зависит от других свойств системы и проекта. Утверждать что «мы не работаем по Х» для системного инженера очень странно.

>В Беларуси классических системных инженеров, таких, что учились бы по специальности СИ и использовали все практики СИ, нет.
Ну не знаю... У нас много где дают специальность инженер-системотехник. Системотехника, считай, советский аналог системной инженерии. На моём потоке (ИИТ ФИТиУ БГУИР), например, какое-то представление об этой дисциплине давали. Не очень качественно, разрозненно, но сказать что у нас совсем не учат системных инженеров у меня язык не повернулся бы.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

хороший коментарий - приятно видеть людей, знакомых с темой :)
- полезность СИ для всех уровней - не отрицаю, однако ставлю под сомнение способность и мотивацию применять ее на всех уровнях;
- я возможно попробовал бы утверждать, что мы таки работаем по "эджайлу" (тем более что манифест мы соблюдать стараемся по мере возможностей) - но тогда набегут истинный пророки правильного эджайла и меня клюнут неоднократно в разные места. Лучше я так.
- вот как появится специальность "системный инженер" - тогда да; тем более системотехника таки _очень_ отличается от того, что я считаю "правильной" СИ (нет, мы все равно не секта!). :)

1

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

p.s. я по диплому инежнер-системотехник, Системотеника — классный предмет в БГУИР был, но назвать себя системным инженером язык конечно не поворачивается )

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

посмотрел внимательнее - признаю свою ошибку, очень близко получается! надо будет поискать учебников, посмотреть насколько :) кстати прямо из вики пришел в https://web.archive.org/web/20140407114707/http://www.e-joe.ru/i-joe/i-joe_02/files/batovrin.pdf - судя по статье, таки не совсем совпадает :/

0

Лет 10 назад в букинистических магазинах Минска было много книг из 80-ых (и переводных и отечественных) по этой теме. Может и сейчас есть.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

вот кстати цитата из вышеупомянутой статьи (PDF), которая про несовпадение системотехники с СИ:
"Наш инженер-системотехник скорее был техническим специалистом, разбирающимся в инженерных проблемах создания и функционирования автоматизированных систем управления технологическими процессами и владеющим технологиями создания отдельных системных элементов. Такому положению способствовал целый ряд причин, среди которых немаловажной оказалась та, что при переводе на русский язык книги Г. Гуда и Р. Макола [1] в качестве эквивалента английского System Engineering был использован термин «системотехника», который довольно быстро стал пониматься как термин технический, применимый в сфере техники и технологий. Суть системной инженерии как междисциплинарного подхода и методики, о чем говорилось в предыдущем разделе, оказалась в значительной степени утраченной."

0

Думаю, и мотивация и способности не зависят от уровня человека в иерархиях, хотя и коррелируют с ним.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

Согласен, я именно о корреляции говорю :) о вероятности того, что СИ реально принесет пользу в сравнении с профильными курсами и тренингами. Иначе говоря, лучше доизучить ещё один язык программирования, или практики работы с большими данными, или ML - для начинающих и продолжающих специалистов это даст больше отдачи в карьере ;)

3

Какая-то сплошная демагогия на ровном месте, которая разводится для продажи тренингов (как и в упоминаемом agile). Проектирование решения снизу вверх, выбор ролей, проектирование архитектуры решения - ну это работа архитектора. Зачем приплетать ещё к этому какие-то абстрактные теории и филологические изыскания.

0

Да не. Норм все. Я сам к таким мыслям пришел, после проектирования примерно n+1 систем. Правда пока только в виде отдельных идей- в отличие от этого чувака не хватает у меня ума собрать все мыслишки вместе...

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
-3

кстати, совсем забыл написать в моей продажной статье - покупайте мой тренинг! вам он очень поможет!!! (хотя вряд ли) :)

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
-1

да, сарказм заходит не всегда ) исправляюсь, добавляя информативности к комментарию:
- в статье действительно нет рекламы моих тренингов (в том числе и потому, что я их не планирую проводить в ближайшее время);
- более того, в интервью я прямо говорю о нужности СИ: если можете работать без нее - _лучше_ работайте без нее, я даже больше отговариваю людей от ее использования, если что :)
- упрек в использовании "каких-то абстрактных теорий и филологических изысканий" неплох, но субьективен (прямо как сама СИ) :) многие думают по-другому, как, например IBM: https://www.ibm.com/internet-of-things/solutions/systems-engineering/model-based-systems-engineering ;)

4

>В психологию стейкхолдера — голова болит, проблемы в семье — мы не углубляемся.
А вот и зря. Иногда надо знать его психотип. Чтобы правильно преподнести ему "нет".

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

все верно, знать надо - это архиважно! вот только в дисциплину СИ это увы совсем не входит :) это больше про лидерство и менеджмент

0

Т.е. если хрупкая женщина- ПМ попросит вас объяснить какому-то упертому человеку, почему вы не хотите поменять архитектуру - вы ответите что в ваши обязанности это не входит, и вообще вы тут примуса починяете и не приставать к вам ? :)

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

а вот и замечательная возможность проиллюстрировать некоторые концепты СИ на примере предложенного сценария :)
вот смотрите - я, Иван П., исполняя роль архитектора, использую набор практик, включающих в себя СИ, технический дизайн, ТРИЗ, управление рисками и много всякого другого. И вот ко мне приходит "хрупкая женщина- ПМ", и предлагает мне объяснить "какому-то упертому человеку" всякое. Тут важно во-первых увидеть реального стейкхолдера - "какой-то упертый человек" может быть заказчиком, разработчиком, менеджером, аналитиком, тестировщиком, подрядчиком, ... много кем на самом деле. Затем под его роль определяется viewpoint (набор интересов к архитектуре) и готовиться view (информация, отвечающая на выявленные интересы стейкхолдера). И вот коммуникация view будет как раз проводиться с учетом психотипа.
Я кстати рекомендую https://www.discprofile.com/what-is-disc/overview/ , очень практичная штука. И кстати в обязанности Systems Engineer коммуникация очень входит - но вот в дисциплину СИ коммуникация по психотипам не входит совсем, а почему так получилось - подумайте сами :) если что, могу подсказать чуть позже

0

А знаете за что всяких там скрамоаджайл проповедников называют сектантами? Вот они тоже любят объяснять что A+B=C но A это не C, потому что тут есть Великий Замысел.
Не нужно быть на них похожими. Секты это не только деньги но и запудривание мозгов )

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

Ок, понял, исправляюсь :) на самом деле цель запудрить не стоит, поэтому смело отвечаю на свой же вопрос "почему работа с психотипами не является частью СИ". Ответ: ровно потому же, почему умение ориентироваться в городе не входит в курсы вождения автомобиля :) хотя возражение вроде бы тоже - как можно водить машину, не ориентируясь в городе? Но тем не менее, на курсах вождения не учат этому совсем.
Разгадка проста - есть куча способов ориентироваться: по навигатору, по карте , по памяти, наугад наконец; каждый выбирает сам.
Так и в СИ: коммуникация может быть и по психотипам, и по возрасту, и по особенностям национального менталитета. Но в СИ это не входит ;)

2

>Если мы строим АЭС, то хотим сделать это не с пятого раза, а с первого.
Золотые слова. С языка сорвали.

1

Иван, спасибо за интересную информацию! Посмотрел, что можно почитать по теме. Рекомендуют NASA System Engineering Handbook (первую ревизию) https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook.pdf
Какие ещё книги можете порекомендовать чтобы ознакомиться с темой?

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
0

Под статьей если что целый блок с книгами ;) а начинал бы я однозначно с "Системного мышления" Анатолия Левенчука (см первая книга из моего списка)

-1

Смешно :))) И как бы NASA и новомодные штучки с красивыми названиями использует, а по факту, не может даже человека обратно на луну свозить, и приходится отдавать космические заказы компании Макса, что использует технологии СССР.

1

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

2

Системный подход применялся еще в советское время, в частности при моем обучении использовалась методика моделирования проекта в "голове" с быстрой возможностью отрисовать (руками) любую детализацию из проекта объяснив ее техническое назначение в проекте, задачу и как она должна быть спроектирована чтобы в минимальный срок заменена\модернизирована и расчет потерь в случае ее выхода из строя. Сам проект - построение оптической линзы управления сигналом барражирования боеголовки баллистической ракеты в зоне действия ПВО (трубки траекторий). В итоге ты был вынужден был думать как инженеры всего проекта в целом, потому что твой конечный модуль в случае поломки сводил задачу к формулировке не выполнено. Сама задача больше относилась к разряду шаманизма между оптикой и механикой так, что после моего отчисления из "космонавтов" в "морпехи" я экстерном за три месяца сдал экзамены за весь курс обучения (не совпали часы и не хотел учиться еще два лишних года) и среди своих сокурсников получил почетное прозвище "космодесантника". Спас именно подход к дисциплинам как взаимосвязанным системам и механизмам их зависимостей. Так что с автором согласен полностью. Уже после выхода на пенсию это помогло строить карьеру, от восприятия как "дедушки Советской Армии и Военно-морского Флота" до стейкхолдера и аналитика\разработчика комплексных проектов безопасности (IT сети+физика+ ПО+диспетчеризация процессов на уровне автоматики). При этом я не программист в чистом виде от слова совсем. Я до сих пор храню в голове свои самые крупные проекты с детализацией до номенклатуры (точно толко количество портов в лючках не скажу, не заморачивался). Мне до сих пор звонят инженеры эксплуатирующие системы и спрашивают а где проходит, или на чем собрано и т.д. Но в нашей стране очень сложно искать работу такого рода потому, что бизнес требует быстрых результатов в угоду рынка (ребята часто прикалываются что я ухожу в себя и не слышу их и шумят не тормози). Хотя технари наоборот любят когда их слушают и пытаются понять как их "совершенные" системы вписывают в проект не издеваясь на идеями.

0

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

-1

А часам вашае захапленьне не кібярнетыкай завецца на Захадзе?

-4

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

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

У Nasa сейчас полная деградация, вы скажите что они такого сделали за последние 20 лет,НИЧЕГО, они якобы даже на Луну(если не врут) опять слетать не могут.

Очередня сказка ,от смузихлебов про гений якобы Макса, он ничего не придумал, все его наработку ,это скупленные наработки других гениев.

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

2

Ну во первых то что они не выполнили вами придуманные задачи еще не значит что ничего не добились. Возможно что вы либо не в курсе выполненных миссий либо не в состоянии понять их ценность. Зачем им летать на Луну? Сможете обосновать? Как раз деградацией было бы лететь туда чтобы похоронить кучу денег.
Во вторых главная заслуга Маска в том, что он сумел удешевить доставку грузов на орбиту. Ну это так вам для справки. А уж купил он или сам придумал - значения не имеет. Раз люди продали ему - значит сами сделать это не могли. Или не захотели. Лишь бы не украл.

0

Суворов, как системный инженер русской армии. Метод строевая подготовка. Сталин системный инженер бюрократического государства. Метод репрессии.
Ньютон директор английского монетного двора системный инженер денежного оборота.
Метод чеканка монет. Внедрение универсальной стоимости.
Системный инженер может быть только главным начальником.