Category: дизайн

Category was added automatically. Read all entries about "дизайн".

2019

Системноинженерные ветры: погоды стоят предсказАнные

INCOSE INSIGHT в выпуске 3 тома 21 (октябрь 2018) вдруг обратился к теме системного мышления в системной инженерии и изменениям в системной инженерии. Конечно, вопрос назрел. Я писал про коннективистскую проблематизацию системного подхода в марте 2016, https://ailev.livejournal.com/1252230.html. Проблемы с системным подходом есть, но:
-- в это выпуске INCOSE INSIGHT они признаются, но не решаются (и это, как мне кажется, отражает текущую ситуацию в INCOSE в целом). Но делается правильный вывод, что если системный подход меняется, то и системная инженерия тоже должна поменяться. А посколько системная инженерия по факту сильно меняется, то это означает, что "что-то уже происходит" -- главным образом с моделеориентированностью. Но на ста страницах текста не говорится, что именно происходит.
-- предлагаются в количестве разные классификационные схемы (типа захмановских банальных "что когда где почему") для того, что и так уже есть в современном системном подходе, и эти схемы берутся по линии философских абстрактных рассуждений линии системологии (systemology, как вместо текущего systems theory предложил переводить в 1973 году Russ Ackoff с немецкого берталанфиевское systemlehre из 40х годов прошлого века -- при этом сам фон Берталанфи перевёл в 50х как раз systems theory), а не из инженерии. Вот эти замены терминов вроде как и должны отражать "прогресс", увы.

Писали в этот INCOSE INSIGHT в основном люди, консервирующие системное знание полувековой давности в разных Systems Societies/Associations (много их), а также немного INCOSE Fellows, но они обращались не столько к инженерному актуальному опыту, сколько к рассуждениям по поводу предыдущего инженерного опыта. Уровень абстракции вырос (классификации известного!), но связь с жизнью (практиками, где эти предлагаемые классификации можно было бы использовать как аттракторы внимания) упала.

Но какой-то прогресс в понимании всё-таки отражён, главным образом в тексте про новое определение системной инженерии. Сегодня существует множество определений системной инженерии, и вот одно из них (попавшее в INCOSE Handbook) и пытаются поправить INCOSE Fellows. Вот их два текущих варианта (оба из одной статьи -- один из начала, "вот мы тут предложили новый вариант" и второй из "summary and conclusions", которые на сегодня является "самым современным" (и имеет статус "для дискуссий"), я так и не разобрался из текста, какой же из них предложен, но они разные, изменения выделены:
Systems engineering is a transdisciplinary approach and means, based on systems principles and concepts, to enable the realization of successful whole-system solutions.

It focuses on: establishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle; establishing an appropriate lifecycle model and process approach considering the levels of complexity, uncertainty and change; documenting and modelling requirements for each phase of the endeavor, then proceeding with design synthesis and system validation; while considering the complete problem and all necessary enabling systems and services.

Systems engineering provides guidance and leadership to integrate all the disciplines and specialty groups into a team effort forming an appropriately structured development process that proceeds from concept to production to operation, evolution, and eventual disposal.

Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality solution that meets the needs of users and other stakeholders and is ft for the intended purpose in real-world operation.
* * *
Systems engineering is a transdisciplinary approach and means, based on systems principles and concepts, to enable the successful realization, use, and retiral of engineered systems.
It focuses on
establishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality early in the development cycle;
establishing an appropriate lifecycle model and process approach considering the levels of complexity, uncertainty and change;
■ documenting and modeling requirements and solution architecture for each phase of the endeavour; and
■ proceeding with design synthesis and system validation while considering the complete problem and all necessary enabling systems and services.

Systems engineering provides facilitation, guidance and leadership to integrate all the disciplines and specialty groups into a team effort forming an appropriately structured development process that proceeds from concept to production to operation, evolution, and eventual disposal.

Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality solution that meets the needs of users and other stakeholders and is fit for the intended purpose in real-world operation and avoids or minimizes adverse unintended consequences.
Все эти изменения сделаны, чтобы отразить факт перехода системной инженерии
-- от создания present paradigm целевых систем of robust, dependable, mainly technological, “deterministic systems” к созданию future paradigm of resilient, adaptive “evolutionary systems” and systems-of-systems, encompassing products, services and enterprises, integrating technological, social and environmental elements
-- от present paradigm обеспечивающих систем implicitly, a command and control view of how systems engingeering works к future paradigm explicitly, a collaborative view of how systems engineering works.

В Сети есть текст, который разъясняет многое из этих предложений (от большинства же авторов): https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_Venture.

Для меня это всё -- махать белым платочком уже давно ушедшему поезду. Даже этот крутой переход от "междисциплинарности" к "трансдисциплинарности" (признание системной инженерии "кругозорной дисциплиной", находящейся на другом уровне абстракции по от отношению к другим инженерным дисциплинам) -- это всё отражение давно осознанного, это не "будущее", это признание настоящего. Есть уже и новый учебник "трансдисциплинарной системной инженерии" -- https://www.amazon.com/Transdisciplinary-Systems-Engineering-Convergence-Hyper-Connected/dp/3319621831 (вышел год назад, в октябре 2017), и оценки читателей там все -- must read. Конечно!

Переход от system к solution (чтобы включить и сервисы тоже, а не только системы) -- ну, просто взяли уже давно прижившийся в IT термин. То, что делается акцент на real world operation -- это то, что нужно дойти до реализации системы в 4D и её стадии эксплуатации, банальность. То, что нужно смотреть за границы "типового жизненного цикла", так что operation его не заканчивает, а дальше идёт evolution перед выводом из эксплуатации -- это тоже давно понятно, у меня это во всех курсах говорится. Что системная инженерия существенно занимается архитектурой обеспечивающей системы, а не только архитектурой целевой системы, так это тоже давно понятно (то, что в ISO 15288 пришлось вместо подобного полноценного взгляда сдать позиции набежавшим из ISO 9000 процессникам, заставило уйти Harold "Bud" Lawson с позиции выпускающего редактора -- по идеологическим разногласиям, более десятка лет назад).

Весь этот свежий выпуск INCOSE INSIGHT говорит, что какой-то рок-н-ролл из INCOSE ушёл, реальное развитие системного мышления и системной инженерии живёт не столько в классической "самолётной" системной инженерии (именно она сейчас процветает в INCOSE), сколько в каком-нибудь автомобилестроении с driverless технологическим стеком. Вот туда нужно смотреть, там отслеживать новинки в дисциплине. Слова там будут ровно те же самые (модели, жизненный цикл, системы), но коннективистская жизнь заставляет отходить от текущих полувоенных стандартов системной инженерии -- и нужно тщательно самим отслеживать, что там происходит, не ждать, пока тамошние лидеры постареют, превратятся за свои заслуги в INCOSE Fellow и напишут свои воспоминания в форме "нового определения системной инженерии".

Но я рад: этот выпуск INCOSE INSIGHT показывает, что мы тут никуда не опоздали, ни от чего не отстали. Все погоды стоят предсказАнные.

DISCLAIMER. Я сам до сих пор директор по исследованиям Русского отделения INCOSE, и этот текст отражает мою личную точку зрения, а не точку зрения Русского отделения, и уж тем более не INCOSE в целом.
2019

Доклад "Визуальное мышление"

Я выступил с почти трёхчасовым докладом "Визуальное мышление" в лаборатории визуального мышления 24 мая 2018 (https://www.facebook.com/events/183898065564572/). Предварительные тезисы доклада я подготовил тут: https://ailev.livejournal.com/1418832.html, но в докладе я затрагивал больше тем.

Вот слайды (https://www.slideshare.net/ailev/ss-99175083, а те, кто внутри совка, могут взять их тут: https://yadi.sk/i/8Z6iYtOq3WcJCN):


Вот видео (https://vimeo.com/272129795):


Первый же вопрос, который был задан -- а как я вообще определяю мышление. Я ответил, что в целях данного доклада меня интересуют его очевидные проявления: когда удаётся с первого раза запустить орбитер на Марс, как это сделали индийские инженеры несколько лет назад, или когда кто-то получает Нобелевскую премию за результаты своего мышления. А когда речь идёт о детском саду и задачах типа "сколько будет 2*2", то это мышление не интересует -- такое мышление поддержать можно и картинками, люди ведь там ещё и читать не умеют толком, их мышление от животного ещё недалеко ушло!

И дальше я весь доклад разворачивал тезис, что чем более развито мышление в какой-то предметной области, тем больше вероятность обнаружить в ней не идеографические (https://ru.wikipedia.org/wiki/Идеограмма) средства его поддержки, а тексты самой разной структуры (в том числе организованные в таблицы и даже более сложные формы, но тексты). Грубо говоря, мышление в промышленных (а не попсовых развлекательных) масштабах поддерживается текстами, а не визуальными полотнами. Все эти design thinking, скрайбинг и прочее -- развлекательные мероприятия, эйфория и действенный эффект от которых исчезает на второй день после их проведения. Они поддерживают мотивацию, интерес, что угодно, кроме мышления. А мышление? Мышление проходит при помощи абсолютно альтернативных средств, и в конечном итоге мы имеем поддержку мышления текстами разной степени формальности. Это очень жёсткий тезис, всегда можно найти ему какой-то пример-другой в опровержение, но парочка примеров ничего тут не меняют (я отдельно рассказал о байесовских оценках всех гипотез). Реальные инженеры работают абсолютно не так, как рассказывают адепты design thinking. Они работают с формальными языками по большей части, а не с картинками. Картинки-эскизы у них бывают, конечно (словами сложные формы в 3D трудно изображать, хотя когда речь идёт о моделях САПР они опять-таки хранятся и обрабатываются в последовательностях символов, а не собственно картинками).

Когда можно увидеть в предметной области много картинок? Когда она очень и очень молода и мышления много не получается -- сначала всегда иероглифы, как в Египте. А потом появляются формальные текстовые языки, и мышление поддерживается ими уже в достаточной мере, размеры проектов существенно растут. Прорывы в цивилизации базируются на текстовых представлениях, а не на визуальных. На визуальных представлениях базируются не интеллектуальные, а эмоциональные прорывы -- не рацио, а эээ... "духоподъемность"? Боевой танец зикр и сессия скрайбинга для меня одной природы: чтобы потом выйти на мышление, нужно остыть и взять совсем-совсем другие инструменты.

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

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

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

У меня всё это и множество других затронутых тем довольно подробно было расписано в разных текстах последнего десятка лет, но доклад проходил по самым разным местам в этих текстах, собирая их содержание -- и это длилось два часа сорок минут. Может быть, когда-нибудь этот доклад прочтёт искусственный интеллект и сделает из него конспект, который можно будет быстро прочесть. А пока есть один только способ ознакомиться с содержанием: смотреть видео и смотреть слайды. Это медленно, это IMHO не слишком поддерживает мышление, зато очень, очень визуально -- многие будут довольны.

Уже в кулуарах меня спросили, почему я не поминал Дракон? Потому как а) визуальный, это анахронизм, б) нерасширяемый (я поминал про внутренние DSL как мейнстрим), в) императивный в наш век мультипарадигмальности. Этого достаточно, чтобы не поминать Дракон. Ему место в музее, как старинной прялке. Рассказывать детям, как кучеряво мыслили люди в двадцатом веке. А сейчас уже 18% от 21 века прошло.

Пара реплик в обсуждениях и фотки: https://www.facebook.com/sun.oxana/posts/1972918972720366, https://www.facebook.com/photo.php?fbid=2141480432535729&set=a.810993412251111.1073741829.100000213806603&type=3
UPDATE: ещё обсуждение https://www.facebook.com/ailevenchuk/posts/10213024327936939
2019

Что самое трудное в системном мышлении

Вот пример ответа на анкетку для выпускников "системного менеджмента и стратегирования":

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

До сих пор сложно составлять функциональную холархию (с модульной просто). Не понимаю как оценить функциональную холархию - функциональная ли она, правильная ли она, полезная ли она.

Что было самым контринтуитивным и удивляет до сих пор?
Взгляд на деятельность как на практику. Описание практики как дисциплина + технология.

Вроде бы часто приходилась слышать слова «best practices», обсуждать методологию работы, но то что из практик удобно составлять архитектуру предприятия - до сих пор удивляет.

Удивляет то, что стало понятно как между собой связанны продукт, архитектура предприятия, стратегия.
Например, вопрос «как развивать сотрудников» резко перешёл в понятные - спланируй развитие продукта - определи практики - назначь практики на роли, роли на должности.

Успели ли применить что-то из тренинга в своей работе?
1. Системную холархию. Нашёл пропущенный уровень и продвигаю идею о том, что нужно проводить дополнительную приемку. Лучше понял границы своей ответственности.

2. Описал свою должность на языке archimate - стало понятно за какие практики я отвечаю, какие практики можно было бы ещё добавить.

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

Планы есть в issue tracker’е.

Изменилось ли у вас мышление в результате курса? В чем именно?
1. Изменилось состояние, появилось спокойствие и уверенность. Связываю это с тем, что более-менее разобрался с холархией и местом своей системы в ней.

2. В общении стал постоянно думать о том, какой интерес скрывается за фразой и какой, соответственно, стейкхолдер.

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

4. Понял какой я стейкхолдер, придерживаюсь роли.

Тут сразу видно, что собственно "менеджерская" часть по факту стала упражнением в системном мышлении, просто архитектура тут стала не просто архитектурой целевой системы, но к ней добавилась (не вместо неё!) ещё и архитектура предприятия. И акцент на практики, чего не удаётся обычно добиться в ходе курса просто системного мышления. И появилась важная заметка, что планы не в голове, а в issue tracker -- это уже большое дело!

Дальше с этим можно работать на предмет instructional design, но нужно разделение труда: исследования (нарыть новые факты -- я использовал для этих фактов инженерные стандарты), культуртрегерство (вытащить кусок, который потом нужно транслировать дальше, для использования в других проектах -- это и будут уже знания, а не факты, вот этим я занимался), и затем упаковка знаний в виде учебного курса (instructional design). У меня лично культуртрегерство, а instructional design я делал ровно настолько, насколько без него было невозможно показать формат выходного продукта -- курса мышления.

Очень надеюсь, что самые разные люди займутся теперь instructional design для системного мышления. И список "самых сложных мест курса" после этого поменяется. Вот, например, я писал про функциональные против конструктивных элементов тут, на примере ножниц: https://ailev.livejournal.com/1361765.html. Но наверняка это можно изложить и проще, и таким способом, чтобы потом можно было более легко переносить это объяснение на ситуации собственных проектов. Вот спецы по instructional design пусть этим и займутся.
2019

Купить нельзя, изготовить

Сегодня на NVIDIA GTC'18 я побывал на презентациях по будущему AI-проектированию от Autodesk и Dassault Systemes/Exalead. Эти проектирования оказались абсолютно разными, общие там были разве что клятвы в любви к NVIDIA -- ибо GPU сегодня это обеспечивающая технология (enabling technology) для грядущих чудес.

Autodesk (отнюдь не первый раз его представители рассказывают об искусственном интеллекте, на GTC'17 я тоже имел удовольствие их слушать) считает, что фишка не в проектировании, а фишка в том, чтобы в конечном итоге сделать (make). И далее слова design for manufacturability не звучат, но разговор только об этом. Нужно взять намерение проектировщика (designer's intent) и затем просто найти нужное решение в пространстве возможных решений -- с учётом всех требований и ограничений. Например, нужно опросить всех сотрудников об их предпочтениях по офисному пространству, и затем просто синтезировать/породить/generate офис, в котором каждому указать на то место, которое более-менее соответствует его предпочтению. Одному нравится сидеть спиной ко всем, другому лицом ко всем, третьему в тёмном углу, четвёртому повыше. Вот дать каждому то, что он хочет: это ж типичная оптимизационная задача. Люди из Autodesk Research взяли и сделали это. А ещё они перетолковали знаменитые "форма следует функции" и "функция следует форме" в "форма следует силе" -- форма должна порождать малое количество материала, для этого нужно просто сделать прочностной расчёт и породить самую лёгкую и простую в изготовлении конструкцию, удовлетворяющую прочностному расчёту. А ещё? Текущие их интересы в переносе стиля: сочетаемость деталей они научились выявлять, но вот теперь хотят делать детали красивыми, просто перенося стиль красивого дизайна на порождённую "по силе" не слишком стильную форму. Одним словом: generative design. Что будет после CAD? Я всегда хихикал, говоря, что САПР -- это Автоматизация Проверки, а не Проектирования. Будет порождение, generative:

autodesk_gtc18_afterBIM

А в строительстве? А то же самое, порождение/generative:

Autodesk_GTC18_afterBIM2

Впрочем, это не сильно отличается от того, что я уже много лет говорю (вот я в 2009 году говорил, https://ailev.livejournal.com/728605.html -- разве что тогда я считал, как все, что правила порождения нужно запрограммировать, а не выучить. Сегодня жизнь изменилась: порождение осталось, а правила его выучиваются на базе прежних работ по проектированию.

Презентация Dassault Systemes/Exalead отличалась существенно. Потому как если в Autodesk от поиска переходили к порождению, то тут переходили от поиска к нахождению. В чём разница? Между search и find разница была определена как в одном случае итеративная процедура, когда вы с помощью компьютера что-то ищете, а в другом случае бот улавливает как-то ваше проектное намерение и находит то, что нужно. Где находит, в пространстве решений? Нет, на рынке. Рынок (marketplace), понятно, уже сделан и фишка в том, что для 3D-деталей можно находить похожие по форме и дальше просто покупать. Ах, ещё и помочь заказать и проследить за логистикой. И проследить, чтобы не было при покупке большого разнообразия. Если что-то можно найти и купить, то ни в коем случае этого нельзя делать!
Exalead_GTC18_buy

А спроектировать и изготовить? Ни в коем случае: это дорого, долго, нужно покупать максимум. Слава GPU, теперь можно реализовать эту мечту и наладить категоризацию, автоматическое именование деталей, отождествление похожих деталей просто по их форме, каталогизацию (в том числе для рынков деталей). Время проектирования сокращаем вдесятеро, все детали уже кто-то делал, их просто нужно найти и заказать -- дальше работает автоматизация сегодняшнего производственного уклада.

Важное дело. Автоматизация гужевого транспорта путём предложения отрасли робота-податчика сена, подковного робота, робота-вместо-кучера. Если вовремя подсуетиться и сделать таких роботов, то им гарантирован большой сбыт. Поставщику поискового движка Exalead в составе тяжёлого (пожалуй, самого навороченного на сегодня) инженерного софта этот подход должен очень нравиться, что мы и видим. Да, это ниша. Она ещё долго просуществует. Робот-румба для уборки конского навоза -- очень хорошая идея в лошадные времена.

Но в этом-то и фишка, что вместо десяти сегодняшних убогих металлоёмких деталей в сборе сегодня можно изготовить одну деталь -- где форма будет следовать силе, где надёжность больше, а стоимость в конечном итоге просто за счёт отсутствия логистики десяти различных компонент к месту сборки, сборки и контроля качества сборки. Меняется сам подход к проектированию и изготовлению. Найти-купить в конечном итоге может оказаться дороже, чем изготовить. Проектирование само по себе настолько быстро съёживается, что сам Автодеск себя пытается переделать в компанию-мейкера и для отладки проектов уже открыл пару публичных мастерских (design and build spaces).

Вот этот тренд от "найти и купить, ручной и головной труд дорог и долог" к "спроектировать и изготовить самому, это нетрудно при должной автоматизации" сейчас повсеместен.

Когда я учился на химика в конце 70-х, все химики сокрушались: найти нужный "синтез" (кухонный рецепт, как сварить какое-то нужное тебе вещество) занимало столько же примерно времени и было настолько же нудным и трудоёмким, сколько разработать свой метод синтеза. Потом появились компьютеры, и "искать синтез" стало быстро. "Найти и купить" стало ведущей парадигмой, слегка отягощаемой случаями, когда найденный синтез не удавалось повторить или ничего не находилось, потому как нужно было сварить действительно что-то новое, рецепта которого просто ещё не существовало. Вот, сегодня (29 марта 2018) опубликована работа, в которой проблема решена: глубокие нейронные сетки были натренированы на все опубликованные реакции органической химии, а затем слепым двойным методом определили, что качество этих "синтезов" такое же, как у людей. Ещё одно проектирование, теперь уже химического синтеза, стало порождающим -- https://www.nature.com/articles/nature25978 (статью можно взять в https://vk.com/wall-44016343_19264).

Это не значит, что в фразе "купить нельзя изготовить" запятую нужно прямо вот сейчас ставить как "купить нельзя, изготовить". Вот прямо сейчас это все не Autodesk, а Autodesk Research. Не химический завод, а Nature. Сейчас на земном шаре "купить, нельзя изготовить". Но идея принтера-самобранки, который напечатает тебе нужное вещество, почку, гамбургер и старинный манускрипт, неотличимый от натурального, живёт. Сегодняшний момент просто подсказывает, что у этого принтера будут ещё и мозги, которые сначала породят-спроектируют запрашиваемое. Порождающее проектирование, порождающее производство. В 2009 году, когда я делал доклад про будущее инженерии (ибо manufacturing это уже не только design, разговор шёл про полный жизненный цикл), уже был generative manufacturing. Но это казалось далёким будущим. Далёким по времени. А сейчас из России это просто далёкое по расстоянию будущее, но уже не по времени.

Situational methods engineering, скорее всего, постигнет такая же судьба. Практики/методы будут порождаться (проектирование практики -- generative design), и вовсе необязательно, что речь пойдёт о фрагментах практики из какого-то каталога. И постановка результирующей сборной практики (уже не собранной из кусочков, а более-менее связной) для компании из людей и вполне вменяемой (и даже разговаривающей, почему бы и нет) нежити будет существенно отличаться от сегодняшней -- generative organizational change, примерный аналог порождающего изготовления. Стратегирование и оргизменения тоже будут склеиваться, и тоже будут поддержаны софтом. Сначала в лабораториях. Потом в немногих компаниях early adopters. А потом мир опять изменится -- и мало кому будет понятно, что происходит. Но с предприятиями, в отличие от железок, софта и зданий-сооружений в этом плане придётся подождать ещё несколько лет. Ибо предприятие на принтере не напечатаешь, метод изготовления предприятий -- лидерство (подробней вам об этом расскажут тут: http://system-school.ru/event/kurs-osnov-sistemnogo-liderstva-2018-04-07/).

Вообще, на GTC'18 промышленности и стройки было уже довольно много -- прямо в выставочном зале стоял экскаватор Komatsu (у него были глазки, которые помогали ему ориентироваться на стройплощадке), всяческие системы мониторинга использования строительной тяжёлой техники и т.д.. Недреманное око пришло на производство и стройку, непрерывно отслеживает план и факт. Но было бы что отслеживать. Основной упор на то, что проект и план должны порождаться не людьми. Люди должны только выразить намерение и задать ограничения. И это "видение сказочников от IT" уже не полная фантастика. В кулуарах люди из Autodesk рассказывали, что в этой всей деятельности им больше всего нравится наблюдать лица инженеров, которые получали "из машины" неожиданные проектные решения -- такие, какие самим бы инженерам в голову не пришли. Это истории уже сегодняшнего дня, не завтрашнего. Завтра просто это перестанет быть предметом обсуждения, это будет просто быт -- и эмоций от "компьютерного творчества" уже не будет. Будут эмоции, когда компьютер будет выдавать решения, которые люди и сами могли бы выдать: зачем им тогда компьютер, если они и без него могут такое придумать?
2019

Пост-объект-ориентированная Julia

Крис Партридж говорил, что современных программистов легче убить, чем переучить в другие парадигмы -- например, в них в ВУЗе намертво вколочен аристотелевский онтологический подход с объектами и атрибутами, а факт-ориентированность для них интеллектуально недоступна. Julia тоже плохо понимается современными ООП-программистами, ибо она не объект-ориентирована: в ней используется multiple dispatch. Я тут подобрал несколько ссылок, где можно почитать подробней о пост-объект-ориентированном стиле программирования в Julia:

-- две большие фичи Julia: multiple dispatch (который вместо ООП) и средства интроспекции -- http://ailev.livejournal.com/1218155.html (и там довольно много дополнительных ссылок на разъяснения).
-- The Design Impact of Multiple Dispatch As the core paradigm of Julia (Stefan Karpinski): http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22 -- базовый пример.
-- Type-Dispatch Design: Post Object-Oriented Programming for Julia (Сhristopher Rackauckas): http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/
-- Modular Algorithms for Scientific Computing in Julia (Christopher Rackauckas): http://www.stochasticlifestyle.com/modular-algorithms-scientific-computing-julia/
-- 7 Julia Gotchas and How to Handle Them (Christopher Rackauckas): http://www.stochasticlifestyle.com/7-julia-gotchas-handle/ (о 7 типовых ошибках, которые делают начинающие работать на Julia)
-- DSL в Julia http://ailev.livejournal.com/1366789.html (и там ссылка на общий паттерн метапрограммирования для DSL в https://julialang.org/blog/2017/08/dsl).

За всё нужно платить. Julia -- более трудный в изучении язык, чем Python, R или Matlab. И материалов для изучения особенностей Julia пока не так много. Хотя на Julia можно достичь бОльшего, чем на Python, R или Matlab, платить за это нужно дополнительным временем обучения, дополнительной ломкой мозга. Это скрипка Энгельбарта (http://ailev.livejournal.com/1158826.html), да ещё и специально заточенная на вычислительную математику.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211017119477982
2019

AMA со мной в CreativeRussia

Опубликовано видео AMA (формат ask me anything) со мной в CreativeRussia, стримилось это live через Hangout на несколько десятков человек 27 апреля 2016г. (https://youtu.be/ey4RNOQEOuk):

Спрашивали о всяком разном, но главным образом про машиноинтеллектуальное творчество. Оно и понятно, Creative Russia ведь как раз сообщество "криэйторов" ("вся соль дизайна, технологий, медиа и стартапов" -- http://creativerussia.co/), а у кого что болит, тот о том и говорит.

Я уж старался "криэйторам" всё "на пальцах" объяснять, даже темп речи у меня медленней обычного получился. Это вполне поправимо: плеер youtube позволяет смотреть это и с удвоенной скоростью.
2019

Нужны ли виртуальные персональные и групповые ассистенты? Не факт!

Вот обратите внимание, как непросто подбирать задачи для Cortana, Google Now, Siri. Для поиска задачек к M городят целый огород с настоящими людьми.

Казалось бы, что на этот интерфейс "помощника" любые утилитки-аппы сядут! Ан нет, аппы продолжают юзаться отдельно, а все эти "умные интерфейсы" продолжают бытовать с вмонтированными в них возможностями отдельно.

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

Ассистент должен сам уметь делать что-то гениальное, а не просто разговаривать. Если есть аппка, то проще этой аппкой воспользоваться самому на голосовом интерфейсе, безо всякого посредника. Аппы сами будут разговаривать, аки люди-эксперты. Секретари для общения с ними могут оказаться не нужны. Посадить пяток аппов, и беседовать с ними. А персональный ассистент? Что он сам должен мочь? "Позови мне Васю и Петю?" Так в виртуальном мире можно просто сказать "ОК, Вася и Петя" вместо "ОК, Гугль, позови Васю и Петю" -- всего-то делов.

К коллективным ассистентам это тоже относится. Или они фасилитаторы/модераторы/менеджеры (то есть приложения, которые что-то умеют, т.е. не "ассистенты-разнорабочие"), или их быстренько дисинтемедиируют. Всё как с людьми.

Платформы, которые дадут вашему гениальному приложению разговаривать без посредников, уже есть:
-- https://api.ai/ (эта платформа и персональных ассистентов поддержит, это же тоже "приложение", например https://assistant.ai/),
-- https://mindmeld.com/
-- Alexa Voice Service, https://developer.amazon.com/public/solutions/alexa/alexa-voice-service
-- https://www.houndify.com/
-- http://viv.ai/ -- viv radically simplifies the world by providing an intelligent interface to everithing
-- ...тысячи их, дальше просто лень смотреть.

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

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206694169046923
2019

Системный моделер из стены и липучек

User story mapping -- http://jpattonassociates.com/user-story-mapping/. Основная заявленная идея тут упорядочить пользовательские задачи (activities) во времени, из историй сделать эпопею. Если внимательно приглядеться, то время оказывается логическим -- привет, вид жизненного цикла (то бишь практики) по горизонтали с разбивкой на эпические/тематические подпрактики по вертикали.

Тем самым user story mapping оказывается про принципиальную схему взаимодействия пользователя с системой, функциональный анализ -- "как оно работает, как получается польза". Поэтому user story map так сильно отличается от product backlog, который появляется исключительно в попытке модульного синтеза -- "как это реализовать, из каких кусков сделано".

Поразглядывайте примеры для user story map в google image. Очень поучительно.

И сразу становится понятным, почему user story mapping хорошо сочетается с domain-driven design (DDD) -- http://blog.eriksen.com.br/en/mapping-domain-knowledge.

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

Одно системное мышление, тысяча применений.

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

Вот что пишет автор подхода user story map (http://jpattonassociates.com/the-new-backlog/): "I hate that word “epic.” I haven’t written Beowulf here. There’s no hero with a magic weapon slaying a monster. It’s just my user “managing email” – a relatively basic thing from my user’s perspective. At least the terms “activity” and “user task” give me some idea of what kinds of stories they are. That said, I’m not fond of the term “user story” either, but I’ve come to accept it. It beats the crap out of requirement.

Куда ведёт в этой цитате ссылочка со слова requirements? К его же статье Requirements considered harmful, где от слова requirements с его кажущейся неизменяемостью и окончательностью он уходит к слову decision, что можно было бы изменять и объяснять. Но кончается всё опять-таки не словом desicion, а теми самыми "нарративами" и "эпопеями" (epic) в user stories -- описаниями. Требования всего-то описания системы как чёрного ящика, со стороны её работы в составе использующей системы. И, конечно, описания могут меняться по мере продвижения в понимании, почему бы и нет.

То есть борьба у современных аджилистов IMHO идёт с ветряными мельницами, а не "бюрократической инженерией", но при этом медленно-медленно всё таки они ползут в сторону принятия системного мышления -- а хоть и устраивая системный моделер из стенки и липучек. Но мне кажется, один раз разницу между модульными и компонентными описаниями объяснить проще, чем мучительно переизобретать её снова и снова (например, противопоставляя product backlog и narrative -- хотя да, требуется дополнительный мыслительный шаг, модуль в product backlog это не просто новый файл или обособленный фрагмент кода, но распределённость в мышлении о модуле дела не меняет. Это именно "из чего сделано").

UPDATE: пара интересных реплик на этот пост появилась в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206161610733298
2019

Критика меня-редукциониста

С удивлением наткнулся на критику 2011 года меня, как редукциониста, в INCOSE INSIGHT (http://www.sercuarc-new.org/wp-content/uploads/2014/02/32_Squires_Managing-the-Body-of-Knowledge.pdf -- Bill Mullins, Systems Engineering and Rationalism: what Alchemy will Remain) -- обвиняют при этом не только меня, но и всё Русское отделение INCOSE. Основывается это обвинение на моей заметке в том же INCOSE INSIGHT 2010 года, где я рассказывал о RuSEC 2010 и заявлял о той программе исследований, по которой мы потихонечку сегодня идём (в открытом доступе черновик критикуемого текста тут: http://levenchuk.com/2010/09/26/rusec-2010-results/).

Критику особенно не понравилось про engineering of systems engineering: "My itch first came when I saw that the author had designated as one of his focus areas the “Demystification of ‘systems engineering art’: Systems engineering knowledge discovery vs. knowledge design (in other words, the engineering of systems engineering)”". Далее он творчески путает редукционизм и логицизм (его рассуждение простое: "интеллектуальный витализм оставляет что-то за пределами логического выражения, поэтому выкидывать это невыразимое и неизвестное -- это редукционизм!), поминает Карла Юнга (который психолог!) и заканчивает необходимостью признать существование в инженерии некоторого количества алхимии, ибо сложность всегда будет побеждать.

Я даже не знаю, с чем тут спорить. Ну да, я логицист (http://ailev.livejournal.com/1059168.html, http://ailev.livejournal.com/1079851.html и т.д.). Ну да, "всего не предусмотришь" -- и как это противоречит логицизму? Ну да, физические теории неточно описывают мир, "оставляя место алхимии" -- но разве это уменьшает нужду в разработке этих теорий? Чем в этом плане отличается системная инженерия (кроме того, что физику нельзя "инженерить", а системную инженерию -- вполне можно)? Да, в системной инженерии мы потихонечку убираем алхимию, заменяя её чем-то более внятным -- в том числе тем, что можно передать компьютерам. Дело идёт плохо, ограничения вполне понятны, но это ведь и есть борьба со сложностью? Отдать сложность на откуп "гениальным алхимическим мозгам" -- это красиво и романтично, но ведь не помогает?

Вообще, со сложностью бороться нужно, начиная с самых верхних ступенек лестницы мета-мета-...-мета-моделирования инженерных систем. То же понятие "система" нельзя ввести сразу на метауровне. Предпосылки для его корректного введения нужно обеспечивать и на мета-мета-уровне, и на мета-мета-мета-уровне. Но я бы предпочёл разговаривать не просто "философствуя" и привлекая психологов (а хоть и Юнга) к разговору, а разговаривать "философско-логически" -- привлекая всяких Витгенштейнов, Льюисов, Крипке и прочих философских логиков.

Так что ссылчку на критику запомним, но отвечать ничего не будем.
2019

Наш адаптер ISO 15926 в приложениях AUCOTEC

Мы (TechInvestLab) сделали адаптер ISO 15926 к process control приложениям AUCOTEC -- это крупный поставщик САПР/PDM для работы с PID, PFD, electric control systems design (https://www.aucotec.com). Вот как он работает(http://youtu.be/tAloOS4wJY4):

Кому лень смотреть: в приложении появляется кнопочка экспорта/импорта в формате ISO 15926, всё чинно-культурно -- работает и на экспорт из приложения, и на импорт в него. Использована версия .15926 Editor 1.5beta3 (свободно лежит тут, вместе с кодами примеров разных адаптеров: http://techinvestlab.ru/dot15926Editor).

Можно считать, что создание семантических адаптеров по стандарту ISO 15926 к инженерному софту перестало быть rocket science и стало обычной производственной рутиной. Фишка там была не в стандарте, а в инструментах. Сделали нормальный инструмент (на паттернах -- all object information models for the adapter are described by template signature patterns, and the mappings are also defined in terms of these patterns), и дело сразу пошло.