Проблемы системной инженерии в "Искусстве и науке системной инженерии"
Статья ("манускрипт", как его назвал Мартон Форкош) "Наука и искусство системной инженерии" отражает опыт системной инженерии в NASA -- http://www.worldscinet.com/srf/03/0302/free-access/S1793966609000080.pdf. Крайне рекомендую этот текст к прочтению.
Это весьма специфический опыт, в котором есть огромные достижения -- пешие прогулки по Луне, марсоходы, космический телескоп и многое другое. С другой стороны, это огромный опыт прошлого, когда люди думали практически без компьютеров, а компьютеры пришли так быстро, что новый опыт размышления с компьютерами почти еще неизвестен: в космической отрасли нет конкурентного давления, заставляющего снижать стоимость и сокращать сроки разработки. Интернет-бизнесмены, которые сейчас строят и запускают частные космические корабли, делают это за стоимость в разы меньшую, и их вариант системной инженерии мне представляется не менее интересным, чем пионерский опыт NASA. Генералы всегда готовятся к прошедшей войне, инженеры всегда готовятся к прошедшим проектам. Поэтому я богатейший опыт NASA воспринимаю с благоговением, но без благоговения (с восхищением, но без восхищения). И мой разбор манускрипта является критическим -- с учетом дисклеймера про все мое уважение к этому тексту, при всей важности и правильности в этой статье сказанного.
В самом начале статьи приводится сравнение системного инженера с дирижером -- симфонический оркестр, который творит Симфонию под управлением специально обученного и талантливого дирижера. Системный инженер, как дирижер, налаживает работу "симфонического оркестра" из многих инженеров-по-специальности. Меня это сравнение настораживает -- и не только потому, что моя любимая в юности книжка называлась "Оркестр играет без дирижера" (http://urss.ru/cgi-bin/db.pl?lang=Ru&blang=ru&page=Book&id=45524&list=42). Казалось бы, я и сам говорил, что музыкальная метафора в системной инженерии очень продуктивна (http://ailev.livejournal.com/754105.html). Но музыка музыке рознь! Метафора симфонического оркестра соответствует административной модели управления, "писанной музыке", и чуть ли не "руководству". В то же время, сама музыка по факту пошла другими путями:
-- в симфонической музыке за счет компьютерного умощнения композитора оказались выкинутыми и дирижер, и его оркестр, а "симфонические" фонограммы к современным фильмам готовятся самим композитором буквально в одиночку -- но на компьютере;
-- в музыкальной мейнстримной культуре преобладает джаз, подразумевающий совсем другие принципы творчества: импровизация плюс взаимоподстраивание (рок -- это тот же джаз, никакого "дирижера", и очень редко какие-то ноты);
-- симфонические оркестры остались как очень дорогое средство антикварного хранения традиции, и от них никакого развития музыки не ожидается. Развитие музыки и музицирования идет, идет бурно, но в совершенно других формах.
Если посмотреть на то, что происходит в бизнесе и разработке, то тренд к "джазовой" организации деятельности несомненен. Все движение agile -- это именно в ту сторону, и все остальные примеры инноваций (например, переход от акцента на administration/management к leadership) именно в эту сторону. Метафора, при которой все главные решения принимаются одним лицом, которое всеми "дирижирует" мне кажется опасной и не соответствующей духу времени. Я понимаю "системноинженерный шовинизм" людей из NASA, когда "системный инженер -- самый главный", но мне кажется много более продуктивной идея о том, что системная инженерия не "наш рулевой", а общеинженерное знаниевое ядро -- и поэтому системные инженеры специализируются до архитекторов, аналитиков требований и прочих людей, которым приходится разбираться с системой в целом. Но эти люди не командуют остальными инженерами (как по факту командует дирижер музыкантами оркестра, сам ни на чем не играя), а организуют их взаимодействие, выполняя свой кусок работы. Нужна другая метафора, джазовая -- хотя она может оставаться и музыкальной. Так, в джазе есть звукооператор (producer, хотя это слово в России значит совсем другое) -- он из записанных разными музыкантами отдельных треков делает окончательную запись. Но он не предписывает, какую музыку играть музыкантам. Или руководитель джазового ансамбля, который выбирает, какую мелодию будут играть -- но он не командует, кому когда и что играть, и не выдает точные ноты. Или совсем другая метафора, игровая -- тренер футбольной команды, основная работа которого проходит не во время игры (заставляет коллектив игроков освоить лучшие практики футбола), а перед ней.
Но это не основной тезис статьи. Основной тезис в том, что системный инженер является техническим лидером (архитектором, аналитиком требований, проектировщиком) проекта, справляющийся с "технической сложностью" -- и это искусство. Музыкальный слух, чувство прекрасного, эмоциональность и выразительность.
С другой стороны, системный инженер является "менеджером системы" (по факту главным бюрократом) проекта, помогающим совладать с его сложностью "в размере и числе людей" -- и это "наука". Хранить ноты, наказывать за отступление от нот, соблюдать ритуалы, обеспечивать наличие музыкантов для всех партий, убеждаться в адекватности звукозаписи.
По версии NASA фишка в том, что у системного инженера должны быть обе эти квалификации -- с приматом получения правильного проекта ("Systems engineering is first and foremost about getting the right design" и это 10% всех усилий, с оговоркой "Neither the world’s greatest design, poorly implemented - nor a poor design, brilliantly implemented - is worth having" и 90% на управление сложностью реализации).
Основная беда системной инженерии, по версии авторов статьи в том, что в конце 80-х "бюрократическая сторона" управления сложностью возобладала над "хардкорной" технической культурой, "наука победила искусство" -- и это привело только к плохому. Но там, где люди только "творили" и не занимались "инженерной бюрократией" дела шли не лучше. Только сочетание технического экселленса и внимания к процессу дают надлежащие результаты.
Отсюда в NASA делается вывод о содержании системной инженерии как дисциплины и необходимых личных качествах системного инженера. И вот с этим анализом я не согласен.
Вспомните ситуацию начала времен WWW, когда появилась и начала бурно развиваться веб-мастеринг и профессия веб-мастера. Трудно уже вспомнить, но всего десять лет назад был один человек, который занимался для вебсайтов всем: программировал движок, разрабатывал арт-дизайн, пришивал его к движку, наполнял вебсайт материалом, продвигал его в Сети и т.д. Один человек, который совмещал в себе всё разнообразие specialty engineering для сайтостроения. Сейчас "вебмастера" уже нет, а есть отдельно программисты CMS, дизайнеры, верстальщики, редакторы (в вариантах editor и content manager), администраторы, модераторы, "информационные архитекторы" (не могу удержаться, чтобы не писать их в кавычках), SEO и это еще не полный список. При развитии профессии она дробится на различные профессиональные позиции. Один человек, даже если он гений, не в состоянии удержать целостность: целостность удерживается в современном мире только командно. Есть ли "системный инженер" в сайтостроительстве? Может быть, а может и не быть. Есть ли "системная инженерия"? Безусловно, есть -- и работа с требованиями, и создание сайтовой архитектуры, и стыковка всего этого с работами многих specialty engineers. Фишка в том, что не все работы "системных инженеров" выполняются одним человеком. В системной инженерии тоже есть специализации.
Подсказку дает Дональд Файерсмит, когда сравнивает системную инженерию с "западной медициной" (в холистической восточной медицине совсем другая история) -- западная врачебная профессия одна, но в ней есть разные специализации дантиста, гинеколога, рентгенолога, проктолога. Хотя они оба врачи, но тренинг у них разный. В системной инженерии, например, профессии инженера требований и инженера системной архитектуры (aka аналитика требований и системного архитектора) требуют принципиально разной человеческой ориентации и тренинга:
-- специалист по требованиям прежде всего должен быть тренирован на работу с людьми, проведение переговоров, интервьюирование, улаживание конфликтов, учет интересов и т.д.
-- специалист по архитектуре прежде всего должен быть тренирован на удержание в голове технической конструкции и связи конструкции и функции (каковая связь обычно обеспечивается моделированием).
Идеально, конечно, было бы иметь яйцеголового нерда-архитектора, который весьма искусен в политической борьбе и человеческом общении, требуемых при работе с заинтересованными сторонами, но вероятность получения такого человека мала. Скорее всего, профессиональная позиция "системного инженера", как и "западного врача" может удерживаться только командной работой специалистов. Это, правда, не мешает мыслить медицину и системную инженерию как отдельные целостные дисциплины -- понимая, что "врач" и "системный инженер" подразумевают что-то общее для всех врачей и всех системных инженеров, что позволяет каждому из них держать целое всех специальностей. Как миниум, все врачи и системные инженеры имеют протоколы (aka стандарты взаимодействия) для работы со смежниками врачами и (системными) инженерами.
Эта же дискуссия сейчас проходит в менеджменте: хотелось бы иметь менеджера, который и в финансах, и в работе с людьми, и в предпринимательстве, и в технической сути бизнеса понимает одновременно -- но это невозможно, и поэтому в фирмах существуют команды менеджеров, управляющие компанией коллективно, а не единолично. С другой стороны, каждый менеджер (операционный-CEO, финансовый-CFO, стратег-president и т.д.) имеет обычно понимание, как устроено целое фирмы, и какая роль в этом целом у него. Это общеменеджерское знание.
Эту же мысль проводят всевозможные "психологические" школы "мыслительных стилей" -- Адизеса, Белбина, Голубковой и т.д.. Если не вдаваться в конкретную классификацию, то общая мысль ясна: люди имеют разные способности, и "идеальную личность" из противоречивых умений лучше замещать правильно подобранным коллективом.
Мне кажется, что это одна из проблем системной инженерии (наряду с SoS, моделе-ориентированностью и т.д.): как разложена системная инженерия по команде системных инженеров, или (ужас-ужас-ужас) "проблема специализаций в системной инженерии". Трудно обсуждать этот вопрос, если "системный инженер -- это тот, кто объединяет работы specialty engineers", но это и есть "проблема" как зафиксированное в явном виде противоречие (одновременная декларация единства и междисциплинарности позиции системного инженера и разнообразие специализаций и частных дисциплин системной инженерии). Это нужно обсуждать, этому нужно уделять особое внимание.
Принципы системной инженерии, описанные в статье (apply equal sweat, maintain healthy tension, manage margin, look for gaps and overlaps, create a robust design, study unintended consequences), нужно понять как раз в этом "расщеплении" экспертизы -- как добиться выполнения этих принципов в командной работе команды системных инженеров разных специализаций с разбросанными по разным фирмам "просто инженерами" разных специализаций (которые и командой-то себя не чувствуют), вот в чем вопрос!
Еще один вопрос -- это вопрос про "искусство" технического мастерства, которое по версии авторов статьи получается "только в ходе работы". Конечно, это правда: чтобы научиться, нужен опыт деятельности в том, чему учишься. Но я против того, чтобы называть это "искусством" и декларировать невозможность научения. Например, некоторое время назад в ОО не было дизайн-паттернов, и ОО-программирование было совсем-совсем искусством. Сейчас этим паттернам можно учить, они выделены и их каждый раз не нужно придумывать "из опыта". Ссылки на музыкантов нерелевантны даже сегодняшнему моменту: компьютерные программы все успешнее и успешнее осваивают то, что составляет этот "неуловимый стиль", отличающий мастеров музыки друг от друга. Компьютеры уже более-менее успешно играют на пианино классическую музыку (http://www.renconmusic.org/), а вполне успешное моделирование знаменитых буги-вуги пианистов прошлого мне еще десяток лет назад показывали исследователи из Music Labs. "Искусство системного архитектора" нельзя воспринимать как что-то, не поддающееся моделированию и последующему научению по выявленной модели. Да, сегодня это представляется искусством, но нельзя это постулировать как данность! Наоборот, нужно всячески призывать демистифицировать "искусство" и превратить это в такую же "науку", каковой люди из NASA считают управление конфигурацией, управление требованиями и прочие составляющие "системного управления" (systems management -- системное управление по аналогии с системной инженерией, как можно было бы это перевести. Хотя традиции перевода этих частных "управлений" другие, и можно перевести в том числе как "управление системами" аналогично "управлению конфигурацией, требованиями, проектами". Системноинженерный шовинизм, как и в случае "управления проектами vs проектного управления" должен бы привести к выпячиванию перевода "системное управление" по сравнению с более приземленным "управлением системами").
Моделирование творческой деятельности является сложной, но не неразрешимой задачей. Эту задачу традиционно ставит (и регулярно решает) нейролингвистическое программирование -- недаром НЛП определяет себя как "дисциплина моделирования человеческого экселленса". Нужно не снимать шляпу перед искусством выдающихся технических лидеров, а моделировать их умение, и затем учить выдающихся технических лидеров на конвейере. Опыт показывает, что при наличии адекватной модели деятельности обучение этой деятельности занимает в 5 раз меньше времени, нежели без такой модели (например, обучений тайцзицюань по "традиционным методикам" до какого-то уровня мастерства впятеро дольше, нежели по модели http://www.dongyue.ru/Library/Lmain.html). Заклинания про "искусство технического лидерства" и "обучение на опыте" правильны на текущий момент, но вредны в долгосрочном плане. В программной статье нужна более рациональная и конструктивная постановка вопроса, нежели сведение технического лидерства к "искусству" и "таланту".
Обучение системных инженеров в NASA -- это очень интересный опыт. Интересно, что technical leadership из начала статьи становится двумя разными предметами: technical breadth and acumen и leadership, а systems management становится тоже двумя "управлениями" systems and process management. Но понять, как же учат системных инженеров в NASA (кроме того, что их предпочитают учить вначале техническим дисциплинам, а потом -- процессным дисциплинам и менеджменту, и делают это "без отрыва от производства") из текста нельзя. Понять, как им удается при системе менторства менять поколения технологий, нельзя. Помните -- "парадигмы умирают только вместе с их носителями"? Если старую парадигму транслировать на новичков, то как в NASA удается преодолеть технологическую и процессную инерцию? Как готовить будущих системных инженеров к будущей войне, а не опять к прошедшей? Это не нашло отражение в статье, но было бы крайне любопытно. Впрочем, это я уже повторяюсь.
ДИСКЛЕЙМЕР: я не берусь тут критиковать NASA и системных инженеров NASA по принципиальным моментам системной инженерии. Статья хорошая и правильная. В конце концов, это в NASA умудряются сделать работающий на Марсе марсоход, а я такого делать не умею. Им поэтому виднее, как такое делать, и как этому учить молодежь. Но чтение такого важного текста вызывает у меня вопросы, и я (каюсь, в немного брюзгливой и резкой форме) эти вопросы тут и написал. На эти вопросы у меня нет ответов, а только интуиция, где эти ответы можно искать. Так что воспринимайте манускрипт отдельно, а мои вопросы отдельно -- так будет правильней. Это не критика, это попытка использовать хороший текст для формулирования "об него" проблем системной инженерии:
-- системный инженер как дирижер vs системный инженер как "базовая квалификация и набор протоколов" любого инженера.
-- совмещение "технического творчества" и "инженерного бюрократизма" в одной и той же дисциплине. Может, это разные дисциплины?!
-- системноинженерные специализации и "мыслительные стили" (команда системных инженеров)
-- моделирование "искусства", демистификация мастерства.
-- обучение системных инженеров новым технологиям и процессам ("невоспроизведение старого опыта" в образовании).
Это весьма специфический опыт, в котором есть огромные достижения -- пешие прогулки по Луне, марсоходы, космический телескоп и многое другое. С другой стороны, это огромный опыт прошлого, когда люди думали практически без компьютеров, а компьютеры пришли так быстро, что новый опыт размышления с компьютерами почти еще неизвестен: в космической отрасли нет конкурентного давления, заставляющего снижать стоимость и сокращать сроки разработки. Интернет-бизнесмены, которые сейчас строят и запускают частные космические корабли, делают это за стоимость в разы меньшую, и их вариант системной инженерии мне представляется не менее интересным, чем пионерский опыт NASA. Генералы всегда готовятся к прошедшей войне, инженеры всегда готовятся к прошедшим проектам. Поэтому я богатейший опыт NASA воспринимаю с благоговением, но без благоговения (с восхищением, но без восхищения). И мой разбор манускрипта является критическим -- с учетом дисклеймера про все мое уважение к этому тексту, при всей важности и правильности в этой статье сказанного.
В самом начале статьи приводится сравнение системного инженера с дирижером -- симфонический оркестр, который творит Симфонию под управлением специально обученного и талантливого дирижера. Системный инженер, как дирижер, налаживает работу "симфонического оркестра" из многих инженеров-по-специальности. Меня это сравнение настораживает -- и не только потому, что моя любимая в юности книжка называлась "Оркестр играет без дирижера" (http://urss.ru/cgi-bin/db.pl?lang=Ru&blang=ru&page=Book&id=45524&list=42). Казалось бы, я и сам говорил, что музыкальная метафора в системной инженерии очень продуктивна (http://ailev.livejournal.com/754105.html). Но музыка музыке рознь! Метафора симфонического оркестра соответствует административной модели управления, "писанной музыке", и чуть ли не "руководству". В то же время, сама музыка по факту пошла другими путями:
-- в симфонической музыке за счет компьютерного умощнения композитора оказались выкинутыми и дирижер, и его оркестр, а "симфонические" фонограммы к современным фильмам готовятся самим композитором буквально в одиночку -- но на компьютере;
-- в музыкальной мейнстримной культуре преобладает джаз, подразумевающий совсем другие принципы творчества: импровизация плюс взаимоподстраивание (рок -- это тот же джаз, никакого "дирижера", и очень редко какие-то ноты);
-- симфонические оркестры остались как очень дорогое средство антикварного хранения традиции, и от них никакого развития музыки не ожидается. Развитие музыки и музицирования идет, идет бурно, но в совершенно других формах.
Если посмотреть на то, что происходит в бизнесе и разработке, то тренд к "джазовой" организации деятельности несомненен. Все движение agile -- это именно в ту сторону, и все остальные примеры инноваций (например, переход от акцента на administration/management к leadership) именно в эту сторону. Метафора, при которой все главные решения принимаются одним лицом, которое всеми "дирижирует" мне кажется опасной и не соответствующей духу времени. Я понимаю "системноинженерный шовинизм" людей из NASA, когда "системный инженер -- самый главный", но мне кажется много более продуктивной идея о том, что системная инженерия не "наш рулевой", а общеинженерное знаниевое ядро -- и поэтому системные инженеры специализируются до архитекторов, аналитиков требований и прочих людей, которым приходится разбираться с системой в целом. Но эти люди не командуют остальными инженерами (как по факту командует дирижер музыкантами оркестра, сам ни на чем не играя), а организуют их взаимодействие, выполняя свой кусок работы. Нужна другая метафора, джазовая -- хотя она может оставаться и музыкальной. Так, в джазе есть звукооператор (producer, хотя это слово в России значит совсем другое) -- он из записанных разными музыкантами отдельных треков делает окончательную запись. Но он не предписывает, какую музыку играть музыкантам. Или руководитель джазового ансамбля, который выбирает, какую мелодию будут играть -- но он не командует, кому когда и что играть, и не выдает точные ноты. Или совсем другая метафора, игровая -- тренер футбольной команды, основная работа которого проходит не во время игры (заставляет коллектив игроков освоить лучшие практики футбола), а перед ней.
Но это не основной тезис статьи. Основной тезис в том, что системный инженер является техническим лидером (архитектором, аналитиком требований, проектировщиком) проекта, справляющийся с "технической сложностью" -- и это искусство. Музыкальный слух, чувство прекрасного, эмоциональность и выразительность.
С другой стороны, системный инженер является "менеджером системы" (по факту главным бюрократом) проекта, помогающим совладать с его сложностью "в размере и числе людей" -- и это "наука". Хранить ноты, наказывать за отступление от нот, соблюдать ритуалы, обеспечивать наличие музыкантов для всех партий, убеждаться в адекватности звукозаписи.
По версии NASA фишка в том, что у системного инженера должны быть обе эти квалификации -- с приматом получения правильного проекта ("Systems engineering is first and foremost about getting the right design" и это 10% всех усилий, с оговоркой "Neither the world’s greatest design, poorly implemented - nor a poor design, brilliantly implemented - is worth having" и 90% на управление сложностью реализации).
Основная беда системной инженерии, по версии авторов статьи в том, что в конце 80-х "бюрократическая сторона" управления сложностью возобладала над "хардкорной" технической культурой, "наука победила искусство" -- и это привело только к плохому. Но там, где люди только "творили" и не занимались "инженерной бюрократией" дела шли не лучше. Только сочетание технического экселленса и внимания к процессу дают надлежащие результаты.
Отсюда в NASA делается вывод о содержании системной инженерии как дисциплины и необходимых личных качествах системного инженера. И вот с этим анализом я не согласен.
Вспомните ситуацию начала времен WWW, когда появилась и начала бурно развиваться веб-мастеринг и профессия веб-мастера. Трудно уже вспомнить, но всего десять лет назад был один человек, который занимался для вебсайтов всем: программировал движок, разрабатывал арт-дизайн, пришивал его к движку, наполнял вебсайт материалом, продвигал его в Сети и т.д. Один человек, который совмещал в себе всё разнообразие specialty engineering для сайтостроения. Сейчас "вебмастера" уже нет, а есть отдельно программисты CMS, дизайнеры, верстальщики, редакторы (в вариантах editor и content manager), администраторы, модераторы, "информационные архитекторы" (не могу удержаться, чтобы не писать их в кавычках), SEO и это еще не полный список. При развитии профессии она дробится на различные профессиональные позиции. Один человек, даже если он гений, не в состоянии удержать целостность: целостность удерживается в современном мире только командно. Есть ли "системный инженер" в сайтостроительстве? Может быть, а может и не быть. Есть ли "системная инженерия"? Безусловно, есть -- и работа с требованиями, и создание сайтовой архитектуры, и стыковка всего этого с работами многих specialty engineers. Фишка в том, что не все работы "системных инженеров" выполняются одним человеком. В системной инженерии тоже есть специализации.
Подсказку дает Дональд Файерсмит, когда сравнивает системную инженерию с "западной медициной" (в холистической восточной медицине совсем другая история) -- западная врачебная профессия одна, но в ней есть разные специализации дантиста, гинеколога, рентгенолога, проктолога. Хотя они оба врачи, но тренинг у них разный. В системной инженерии, например, профессии инженера требований и инженера системной архитектуры (aka аналитика требований и системного архитектора) требуют принципиально разной человеческой ориентации и тренинга:
-- специалист по требованиям прежде всего должен быть тренирован на работу с людьми, проведение переговоров, интервьюирование, улаживание конфликтов, учет интересов и т.д.
-- специалист по архитектуре прежде всего должен быть тренирован на удержание в голове технической конструкции и связи конструкции и функции (каковая связь обычно обеспечивается моделированием).
Идеально, конечно, было бы иметь яйцеголового нерда-архитектора, который весьма искусен в политической борьбе и человеческом общении, требуемых при работе с заинтересованными сторонами, но вероятность получения такого человека мала. Скорее всего, профессиональная позиция "системного инженера", как и "западного врача" может удерживаться только командной работой специалистов. Это, правда, не мешает мыслить медицину и системную инженерию как отдельные целостные дисциплины -- понимая, что "врач" и "системный инженер" подразумевают что-то общее для всех врачей и всех системных инженеров, что позволяет каждому из них держать целое всех специальностей. Как миниум, все врачи и системные инженеры имеют протоколы (aka стандарты взаимодействия) для работы со смежниками врачами и (системными) инженерами.
Эта же дискуссия сейчас проходит в менеджменте: хотелось бы иметь менеджера, который и в финансах, и в работе с людьми, и в предпринимательстве, и в технической сути бизнеса понимает одновременно -- но это невозможно, и поэтому в фирмах существуют команды менеджеров, управляющие компанией коллективно, а не единолично. С другой стороны, каждый менеджер (операционный-CEO, финансовый-CFO, стратег-president и т.д.) имеет обычно понимание, как устроено целое фирмы, и какая роль в этом целом у него. Это общеменеджерское знание.
Эту же мысль проводят всевозможные "психологические" школы "мыслительных стилей" -- Адизеса, Белбина, Голубковой и т.д.. Если не вдаваться в конкретную классификацию, то общая мысль ясна: люди имеют разные способности, и "идеальную личность" из противоречивых умений лучше замещать правильно подобранным коллективом.
Мне кажется, что это одна из проблем системной инженерии (наряду с SoS, моделе-ориентированностью и т.д.): как разложена системная инженерия по команде системных инженеров, или (ужас-ужас-ужас) "проблема специализаций в системной инженерии". Трудно обсуждать этот вопрос, если "системный инженер -- это тот, кто объединяет работы specialty engineers", но это и есть "проблема" как зафиксированное в явном виде противоречие (одновременная декларация единства и междисциплинарности позиции системного инженера и разнообразие специализаций и частных дисциплин системной инженерии). Это нужно обсуждать, этому нужно уделять особое внимание.
Принципы системной инженерии, описанные в статье (apply equal sweat, maintain healthy tension, manage margin, look for gaps and overlaps, create a robust design, study unintended consequences), нужно понять как раз в этом "расщеплении" экспертизы -- как добиться выполнения этих принципов в командной работе команды системных инженеров разных специализаций с разбросанными по разным фирмам "просто инженерами" разных специализаций (которые и командой-то себя не чувствуют), вот в чем вопрос!
Еще один вопрос -- это вопрос про "искусство" технического мастерства, которое по версии авторов статьи получается "только в ходе работы". Конечно, это правда: чтобы научиться, нужен опыт деятельности в том, чему учишься. Но я против того, чтобы называть это "искусством" и декларировать невозможность научения. Например, некоторое время назад в ОО не было дизайн-паттернов, и ОО-программирование было совсем-совсем искусством. Сейчас этим паттернам можно учить, они выделены и их каждый раз не нужно придумывать "из опыта". Ссылки на музыкантов нерелевантны даже сегодняшнему моменту: компьютерные программы все успешнее и успешнее осваивают то, что составляет этот "неуловимый стиль", отличающий мастеров музыки друг от друга. Компьютеры уже более-менее успешно играют на пианино классическую музыку (http://www.renconmusic.org/), а вполне успешное моделирование знаменитых буги-вуги пианистов прошлого мне еще десяток лет назад показывали исследователи из Music Labs. "Искусство системного архитектора" нельзя воспринимать как что-то, не поддающееся моделированию и последующему научению по выявленной модели. Да, сегодня это представляется искусством, но нельзя это постулировать как данность! Наоборот, нужно всячески призывать демистифицировать "искусство" и превратить это в такую же "науку", каковой люди из NASA считают управление конфигурацией, управление требованиями и прочие составляющие "системного управления" (systems management -- системное управление по аналогии с системной инженерией, как можно было бы это перевести. Хотя традиции перевода этих частных "управлений" другие, и можно перевести в том числе как "управление системами" аналогично "управлению конфигурацией, требованиями, проектами". Системноинженерный шовинизм, как и в случае "управления проектами vs проектного управления" должен бы привести к выпячиванию перевода "системное управление" по сравнению с более приземленным "управлением системами").
Моделирование творческой деятельности является сложной, но не неразрешимой задачей. Эту задачу традиционно ставит (и регулярно решает) нейролингвистическое программирование -- недаром НЛП определяет себя как "дисциплина моделирования человеческого экселленса". Нужно не снимать шляпу перед искусством выдающихся технических лидеров, а моделировать их умение, и затем учить выдающихся технических лидеров на конвейере. Опыт показывает, что при наличии адекватной модели деятельности обучение этой деятельности занимает в 5 раз меньше времени, нежели без такой модели (например, обучений тайцзицюань по "традиционным методикам" до какого-то уровня мастерства впятеро дольше, нежели по модели http://www.dongyue.ru/Library/Lmain.html). Заклинания про "искусство технического лидерства" и "обучение на опыте" правильны на текущий момент, но вредны в долгосрочном плане. В программной статье нужна более рациональная и конструктивная постановка вопроса, нежели сведение технического лидерства к "искусству" и "таланту".
Обучение системных инженеров в NASA -- это очень интересный опыт. Интересно, что technical leadership из начала статьи становится двумя разными предметами: technical breadth and acumen и leadership, а systems management становится тоже двумя "управлениями" systems and process management. Но понять, как же учат системных инженеров в NASA (кроме того, что их предпочитают учить вначале техническим дисциплинам, а потом -- процессным дисциплинам и менеджменту, и делают это "без отрыва от производства") из текста нельзя. Понять, как им удается при системе менторства менять поколения технологий, нельзя. Помните -- "парадигмы умирают только вместе с их носителями"? Если старую парадигму транслировать на новичков, то как в NASA удается преодолеть технологическую и процессную инерцию? Как готовить будущих системных инженеров к будущей войне, а не опять к прошедшей? Это не нашло отражение в статье, но было бы крайне любопытно. Впрочем, это я уже повторяюсь.
ДИСКЛЕЙМЕР: я не берусь тут критиковать NASA и системных инженеров NASA по принципиальным моментам системной инженерии. Статья хорошая и правильная. В конце концов, это в NASA умудряются сделать работающий на Марсе марсоход, а я такого делать не умею. Им поэтому виднее, как такое делать, и как этому учить молодежь. Но чтение такого важного текста вызывает у меня вопросы, и я (каюсь, в немного брюзгливой и резкой форме) эти вопросы тут и написал. На эти вопросы у меня нет ответов, а только интуиция, где эти ответы можно искать. Так что воспринимайте манускрипт отдельно, а мои вопросы отдельно -- так будет правильней. Это не критика, это попытка использовать хороший текст для формулирования "об него" проблем системной инженерии:
-- системный инженер как дирижер vs системный инженер как "базовая квалификация и набор протоколов" любого инженера.
-- совмещение "технического творчества" и "инженерного бюрократизма" в одной и той же дисциплине. Может, это разные дисциплины?!
-- системноинженерные специализации и "мыслительные стили" (команда системных инженеров)
-- моделирование "искусства", демистификация мастерства.
-- обучение системных инженеров новым технологиям и процессам ("невоспроизведение старого опыта" в образовании).