Анатолий Левенчук - Системная инженерия – 2022

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

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

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

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

В давней (это статья 2009 года. Помним, что первый iPhone появился в 2007 году. В инженерии 2009 год – это очень давно! Всё в инженерии происходит быстро, и не только в железной инженерии) статье «Наука и искусство системной инженерии» 35 35 http://www.worldscinet.com/srf/03/0302/free-access/S1793966609000080.pdf , отражающей опыт космической системной инженерии NASA, приводится сравнение системного инженера со специально обученным и талантливым дирижёром симфонического оркестра, который творит Симфонию. Системный инженер, как дирижёр, налаживает работу «симфонического оркестра» из многих инженеров-разработчиков, и даже часто не отдельных людей-разработчиков, а целых команд разработчиков. Это одновременно и правда, и неправда. Правда в том, что системные инженеры – это технические лидеры. Неправда в том, что системный инженер – это один человек, «рулящий» огромными коллективами других инженеров.

Как в инженерии произошло разделение на инженеров по специальности (механиков, электриков, программистов, теплотехников и т.д.), как в западной медицине произошло разделение врачей по разным врачебным специальностям, и врачи редко работают поодиночке, так подобное углубление 36 36 Обычно deep, «глубина» в речи означает рост числа уровней какой-то иерархии. Скажем deep learning – это многоуровневое обучение, то есть обучение нейронных сетей с числом скрытых уровней/слоёв больше одного. В углублении разделения труда речь идёт об увеличении числа уровней иерархии по отношению специализации (род-вид) между практиками. разделения трудауже произошло и в самой системной инженерии киберфизических систем, и во многих других областях более высоких системных уровней, в которых слово «инженерия» не употребляется. Системных инженеров разной специализации может быть в одном проекте целая команда, которая делится, как мы помним и по видам подсистем (у самолётов это могут быть двигателисты, у организации – бухгалтеры. То, что подсистема в одной системе, на другом уровне имеет свою целостность и будет требовать архитектурной проработки и какой-то организации введения в эксплуатацию), и по практикам (прежде всего это деление на разработчиков, включая занимающихся функциональностью системы в целом, архитекторов, отвечающих за архитектурные характеристики, девопсов, отвечающих за минимизацию времени ввода в эксплуатацию каждого инкремента системы, который сделали разработчики).

Вспомните ситуацию начала времён WWW, когда появилась и начала бурно развиваться профессия веб-мастера в середине 90х прошлого века. Трудно уже вспомнить, но всего двадцать лет назад был один человек, который занимался для вебсайтов всем: программировал движок, разрабатывал арт-дизайн, пришивал его к движку, наполнял вебсайт материалом, продвигал его в Сети и т. д. Один человек, который совмещал в себе всё разнообразие прикладной инженерии для сайтостроения. Сейчас «вебмастера» уже нет, а есть отдельно программисты CMS (content management system) или программисты бэк-энда, дизайнеры, верстальщики (которых уже так не называют, это программисты фронт-энда), тимлиды и DevOps, редакторы (в вариантах editor и content manager, причём второго уже и редактором не называют, а раньше называли), администраторы, модераторы, специалисты по пользовательским интерфейсам и по пользовательскому опыту (раньше их не различали, теперь даже пишут UI/UX), SEO (search engine optimization) и после этого появившиеся спецы по SMM (social media marketing), и это еще не полный список (вы заметили, что в этом списке не хватает архитектора? Он обязательно должен быть!).

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

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

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