Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Мои заметки по Бекасово-2013

Я провёл три дня в Бекасово на четвертой рабочей встрече Русского отделения INCOSE по проблемам системной инженерии (minutes тут: http://incose-ru.livejournal.com/42182.html).

Вот несколько моих впечатлений:

1. Разговаривать на темы системной инженерии в кругу "своих" (которые знакомы с OMG Essence, ISO 42010, ArchiMate 2.0, и т.д.) и с новичками приходится очень-очень по-разному. Один новичок своими вопросами быстро превращает обсуждение "проблем системной инженерии" в неинтересный тьюториал, и этот тьюториал не имеет шансов быстро закончиться, ибо разъяснять приходится не один и не два термина, а ой-ой-ой сколько. Сообщество неизмеримо выросло, семьдесят четыре заседания (http://incose-ru.livejournal.com/) дали свои плоды.

Производственники, кому системная инженерия и современный инженерный менеджмент как раз и могли бы пригодиться, без предварительных длительных (несколько дней) тьюториалов ничего понять не могут (да и особо не хотят: зачем им что-то новое изучать в таких количествах?!). А кто "разобрался и прорвался" -- для тех появился огромный барьер в разговорах с нынешними производственниками: на каждую простую для них мысль из одной фразы требуется добавлять пару-тройку часов объяснений и обоснований.

2. Много инженеров в России придерживаются идей российского чучхе, и гордятся особостью наших ГОСТов и несовместимостью национальной инженерной школы с современной мировой практикой и работой в международных командах. Я сам считаю, что инженерная автаркия до добра не доведёт: во времена, когда каждый пяток лет меняются инженерные практики, сохранение пережитков прошлого как в "обязательных стандартах" (ага, "горячий лёд"), так и в подготовке инженеров -- это попытки протекционизма чистой воды, и должны быть удавлены хотя бы за это.

3. Такое впечатление, что перевод management на "логистика" был бы много более правилен. Вместо "управление требованиями" -- логистика требований, вместо "инженерный менеджмент" -- инженерная логистика, вместо "управления проектами" -- "логистика проектов". Хотя, конечно, это не "классическая логистика" (планирование, реализация и контроль эффективности потока и хранения материально-технических ресурсов и производственных запасов), но путаницы могло бы быть в разы меньше как по отстройке от замешивания инженерии (например, включения выявления и согласования требований в логистику требований), так и по отстройке от классического менеджмента в его MBA-варианте.

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

4. Гиперкниготексты -- http://ailev.livejournal.com/103692.html (2003 год, десять лет развития информационных технологий. И что изменилось?). Visual novels -- http://ailev.livejournal.com/999669.html. scorm-пакеты -- в http://ailev.livejournal.com/1067676.html (мастер метод менеджмент) и http://ailev.livejournal.com/1068481.html (картинки с текстами vs. текстов с картинками). Основная идея тут в том, что разделяем учебник-объяснялку и практические работы. Учебник-объяснялка именно объяснялка, а не чистый гипертекст-справочник. И кто не имеет денег/возможностей пройти курс с тьютором, тот пользуется только им. Главная фишка тут в том, что стоимость и время подготовки такого "наглядного онлайн учебника" с простой инфографикой или даже схемами-диаграммами из какого-то моделера в разы и разы меньше всяких "тренажёрных" вариантов. А "тренажёрность" дают затем тьюторы. Конечно, это хуже всяких "учебных миров" и "виртуальных обучающих сред", но мы ищем оптимум -- с учётом затрат денег, нервов и времени на создание курса. При грамотной варке супа из топора допотопных поколений LMS (используемых просто как учебник) и живого тьюторства с упором на разбирательство со студенческими проектами всё вполне может получиться.

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

Ещё одно интересное наблюдение: после краткого курса "введение в системную инженерию" можно было бы создать краткие курсы "инженерия требований", "инженерия системной архитектуры". Таким образом было бы легче постепенно подползти к полноценному курсу, эквивалентному магистерской подготовке по системной инженерии. Конечно, при этом возникает задача управления конфигурацией "курса курсов" (учебной программы по системной инженерии): согласованность использованной системы понятий, опоры на те или иные стандарты и формализмы (OMG Essence, ArchiMate и т.д.).

Ну, и всё то же самое относится к инженерному менеджменту (ага, инженерной логистике).

5. Лидерство есть не только у менеджеров (которым оно нужно для того, чтобы живых людей убалтывать на занятие ими мест на конвейере -- неважно, идут ли по этому конвейеру обрабатываемые и собираемые в единое целое механические детальки, или обрабатываемые и собираемые в единое целое 3D, прочностные, тепловые и прочие инженерные модельки). Лидерство есть и у системных инженеров -- чтобы убеждать (убалтывать: неполиткорректно, но сразу понятно) инженеров по специальностям следовать принятым решениям в части требований и архитектуры.

6. Наука -- это про поиск новых методов описания, viewpoints (http://ailev.livejournal.com/942353.html, июль 2011):
определение науки, которое дал Алан Кей (я его перескажу тут немного вольно, посолив и поперчив по своему вкусу): наука занимается поиском наиболее компактных методов описаний мира, пригодных для деятельности. Методы описания (viewpoints) по определению связаны с языком (формальным), поэтому наука у Кея практически перекрывается с математикой. Я бы флегматично заметил, что собственно языковой частью больше занимается философская логика, а не математика -- но по поводу этого высказывания может традиционно начаться холивар между логиками и математиками (математики при этом будут побеждать как минимум в силу своей многочисленности по сравнению с логиками), но это отвлечёт от основного посыла Кея: наука изобретает методы сверхкраткого описания сверхсложных феноменов.

Ряд ссылок на работы по компактификации знания я собирал в http://ailev.livejournal.com/872954.html
Это "изобретательство теорий" нужно чётко отделять от инженерного изобретательства: все эти НИОКР ведь главным образом направлены не на получение верной теории, а на получение "работающего прототипа". Изобретатели и учёные путаются даже в мультфильмах: безумные учёные в лабораториях из мультиков не столько придумывают тексты на формальных языках, строго и понятно описывающие большие куски действительности (типа как уравнения Максвелла описывают много чего про электромагнитные поля), сколько придумывают разные "полезные устройства" -- по факту они инженеры-изобретатели, а называются "учёными" просто потому что творят что-то новое. Деление на "фундаментальную" и "прикладную" науку (появившееся в силу необходимости обосновывать финансирование -- то есть это деление имеет отношение к политэкономии, а не к собственно содержанию деятельности) искусственно. Новые viewpoints проявляются в создании новых систем, а затем конкуренция заставляет эти новые viewpoints быстро распространяться. Так что в 42010 их главное достижение (что view и viewpoints различаются -- это первый стандарт, в котором это зафиксировано) как раз про связь инженерии и науки. Учёные разрабатывают viewpoints, инженеры их используют для сочинения view несуществующих ещё целевых систем (engineering) или получения view для уже существующих (re-engineering). Ну, а дальше разные нюансы по уровням описаний (описания, описывающие описания; методы, описывающие методы; впрочем, современная наука этими луковичными слоями описаний уже настолько далеко отошла от непосредственного восприятия реальности, а хоть и через приборы, что я бы не заморачивался пока особо с рассуждениями по поводу этих нюансов).

7. OMG Essence распространяется как пожар, несмотря на то, что он прошёл Архитектурный комитет OMG только 22 марта 2013 года и ещё не стал стандартом. Всё чаще и чаще я слышу предложения разворачивать какой-то проект в соответствии с требованиями этого стандарта (т.е. начинать отвечать на контрольные вопросы тамошних альф), или описывать разные проекты с использованием тамошнего языка и начального набора сущностей. Собственно, из наиболее часто цитируемых стандартов я бы назвал OMG Essence, ArchiMate и ISO 42010. Далее с большим отрывом идёт ISO 15926 (ибо он описывает то, что уже глубоко под капотом инженерного софта).

8. Изо всех докладчиков этой встречи я бы особо выделил А.Иванова: он и про гиперграфы как формализм для ISO 15926 рассказывал, и чудеса по освоению студентами ArchiMate демонстрировал, и подходы системной инженерии к SmartGrid демонстрировал -- не говоря уж о занятиях агентскими архитектурами. Круто, очень круто. Kudos.

9. Инженерный конвейер, который за счёт ухода от уникальности (но не закрывая возможностей mass customization) каждого проекта позволяет снизить стоимость и ускорить производство интеллектуальной продукции в разы и разы -- это очень правильная идея. Конечно, от мануфактуры по выпуску булавок с её 18 операциями до фордовского-тейлорского конвейера прошло немало времени. Но и до хирургического конвейера (http://worldcrunch.com/culture-society/in-india-henry-ford-039-s-assembly-line-inspires-the-high-tech-hospital-of-the-future/c3s5573/#.UUrCIcrrNIH) тоже много времени прошло. Конечно, в знаниевых технологиях workflow -- это лишь символический конвейер, а в системах adaptive case management и жесткого workflow нет. Тем интересней такие "невидимые конвейеры" делать -- знаниевая логистика (ага, knowledge management, помним про пункт 3). Недаром мы описания типовых жизненных циклов инженеринговых фирм лет пять назад называли описаниями "типовых инженерных конвейеров". Может быть, нужно опять вернуться к этой метафоре. Ну, и знаменитый тойотовский рубильник: ежели кто из (в нашем случае -- знаниевых) работников обнаружил, что конвейер гонит брак, он обязан этот конвейер остановить.

При этом П.Щедровицкий правильно подчеркнул: требования к компетентности работников на конвейере существенно снижены по сравнению с "доконвейерным" производством. Но вот те инженеры и логистики, которые отлаживают конвейер, а также те стратеги, которые его разворачивают, должны понимать и про целевую систему, и про конвейерное производство всё-всё-всё. При таком способе организации инженерного труда лимитирует не сложность целевых систем, а сложность конвейера (системы деятельности) для их разработки и производства.
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 19 comments