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

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

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

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

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

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

Вроде бы часто приходилась слышать слова «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

lytdybr

Сдали сегодня очередное высевание технологических цветов в каменистую почву: управление конфигурацией, архитектура с использованием Modelica, намётки по generative design и развитию операционного менеджмента в сторону issue tracking/case management. Подождём теперь года три, посмотрим, что взойдёт. По нынешним временам нет уверенности не только в судьбе цветов, но и самой каменистой почвы.

У ещё одного клиента в пятницу вели проектную сессию. За день только-только успеваешь разобраться с вопросом "какая у нас система". До вида жизненного цикла, требований, архитектуры и всего прочего за день обычно не успеваешь добраться. Только разбиение (холархия с выходом на целевую систему в операционном окружении) и различение целевой системы и обеспечивающей системы. Если разбираться дальше, то одного дня абсолютно недостаточно, проверено многократно. Собственно, это и есть системная инженерия. Никто не обещает, что это быстро. Но потратить день-два-три на то, чтобы команда проекта делала одну и ту же систему, а не каждый свою -- это может сэкономить потом месяцы и месяцы застревания в ситуации "система готова на 95%". Для меня эта проектная сессия отличалась немного от аналогичных у других клиентов: ключевые сотрудники прочли полкнижки по системноинженерному мышлению, и я существенно опирался на этот материал. Мне очень понравилось, материал книжки позволяет двигаться с обсуждением много быстрее -- у меня ведь многолетний опыт ситуаций, когда команде проекта за день так и не удаётся разобраться с целевой системой. Жесткое следование предлагаемым в книжке паттернам системноинженерного мышления убирает буксование. Вот типовые ошибки:
-- система определяется по конструкции. Переход к определению по функции заставляет по-другому взглянуть на границы системы, стейкхолдеров
-- систем слишком много: тут и "новый рынок", и "продуктная линия" и "заказ XYZ", и "прототип чтобы научиться"
-- целевая система определяется не по стадии эксплуатации, конец жизненного цикла отбрасывается
-- указывается не на целевую систему, а на обеспечивающую
-- указывается не на целевую систему, а на описание системы
-- полная путаница, когда присутствует ещё и сервис
-- полная путаница, когда в работах есть исследования

Сделали сегодня очередной такт обсуждений по SysMoLan. Я хочу, чтобы это был язык системного моделирования, а не системного программирования. То есть операции программирования пусть там неудобно пишутся (программисты потерпят), а вот инженеры должны системы видеть, как на родном их языке (зачастую матерном, а не программирования). Не "программный код, а в скобочках описывающие систему данные", а "описывающие систему данные, а в скобочках программный код". Язык программирования/язык запросов/язык мэппинга там будет, причём расширяемый, куда ж без него. Но в основе языка должно лежать удобство работы с system designators (по ISO 81346, который про инженерные обозначения и структуру систем), а идентификаторы языка (для переменных, свойств, операторов, функций и т.д.) пусть будут отдельно. Чтобы было понятно: десигнатор по ISO 81346 выглядит примерно как =D12=W1=40, и там встречаются ещё минус, плюс, решётка, амперсенд и прочие приятные символы. И я хочу, чтобы эти десигнаторы не нужно было брать в кавычки или скобки, они должны писаться непосредственно, as is. А в скобки или кавычки можно брать всё остальное, если очень нужно. Я помню, как нехорошо стыкуется реальный мир и мир программирования: когда Винды не понимали русскоязычных имён файлов, всем было регулярно очень плохо. Тут именно такой случай, программисты должны подстроиться под инженеров. Это не "имена", это именно system designators (системные обозначения). Вокруг них всё и будет плясать.

В обучении языкам нашёл какое-то подтверждение моего любимого способа обучения как последовательности "относительно лёгких упражнений", тренирующих какие-то паттерны работы мозга (сегодня можно уже сказать, тренирующие нейронную сетку мозга, pun intended): для многих учащихся не работает эффект "погружения в проекты", и "объяснения материалы". Нет, работает тупое многочасовое прохождение относительно лёгких языковых упражнений, после которых владение языком переходит на уровень автоматизма (это я опять ссылаюсь на статью http://www.govtilr.org/Publications/TESOL03ReadingFull.htm). Простейшее из таких упражнений -- всем известные "карточки" для запоминания переводов слов и фраз при изучении иностранных языков. Для работы с этими карточками-запоминалками есть чудесная программа Anki (http://ankisrs.net/), которая использует Supermemo алгоритм, учитывающий характеристики людской забывчивости свежевыученного. Пример обсуждения эффективности подобных программ: http://polydog.org/index.php?threads/anki-vs-gold-lists-vs-iversen-style-wordlists.238/ (но самое большое число обсуждений того, как учить язык идёт тут: http://how-to-learn-any-language.com/forum/, к этому в паре есть и вики: http://learnanylanguage.wikia.com/wiki/Learn_Any_Language).

Интересное начинается тогда, когда нужно не столько запомнить значения слов (в обоих направлениях, вестимо), сколько натренировать мозг на синтаксические паттерны. Ибо обучать грамматике, объясняя паттерны, бесполезно -- не будет автоматизма. Фишка тут в том, как придумывать соответствующие наборы упражений. Вот пример идей в этом направлении: http://direct.fluent-forever.com/how-to-learn-german-grammar-with-anki/. Я вот думаю, нельзя ли учить таким образом языкам моделирования (паттернам моделирования). Там ведь фишка тоже в прогружении синтаксиса и семантики куда-то глубоко в недра мозга, на уровень интуиции и автоматизма. Напомню, что для программирования что-то подобное уже есть (опять приведу в пример автоматизированный курс Кириенко из 365 упражнений курса алгоритмики для Питона, в нём разве формата карточек нет: http://informatics.mccme.ru/course/view.php?id=156).

Вчера же я определял своё владение английским по европейской шкале CEF (http://www.examenglish.com/leveltest/index.php), а сегодня перепроверил. У меня дребезг между B2 и C1 по грамматике (я всё время путаюсь с http://en.wikipedia.org/wiki/James_while_John_had_had_had_had_had_had_had_had_had_had_had_a_better_effect_on_the_teacher), а по слушанию твёрдо С1. До С2 мне ещё лететь и лететь, чего уж там -- но C2 это уже практически native.

И тут меня развезло. Загрузил учебник, лингафонные материалы и Anki на телефон -- и занялся немецким (вместо совершенствования английского). Интересно, насколько меня хватит? Как я понимаю из интернетов, уровни А1 и А2 (то есть "турист") проходятся чуть ли не за пару-тройку месяцев.

Пару лет я был в оргкомитете Ontology Summit и тем самым попадал в соавторы Коммюнике, которое публикуется в Journal of Applied Ontology (http://www.iospress.nl/journal/applied-ontology/). То есть у меня по онтологии уже пара академических публикаций, кто б мог подумать? Но в этом журнале impact factor ниже плинтуса (в 2012 был 1.08, это очень мало. Например, для западного PhD требуется три публикации не на родном языке в журналах с IF>3).
2019

Картинки с текстами vs. тексты с картинками

Что-то щёлкнуло у меня в мозгу, и я таки начал читать мангу. Раньше никогда не получалось: этот жанр был для меня недоступен, я никак не понимал, как можно сравнивать черно-белые картинки с пометками типа "бац" и "жамк" с полноценным текстом или полноценным аниме. Раз в год я делал попытку -- и через двадцать страниц все эти попытки заканчивались, ибо бросал в недоумении. Но в этом году у меня получилось! Я прочёл несколько полномасштабных (размер в 3тыс. страниц картинок -- это не такая уж редкость) манг -- и оказалось, что "послевкусие" от них у меня примерно такое же, как от аниме (и совсем не такое, как от книг). Да, несмотря на отсутствие в манге цвета, звука и движения.

А ещё я бродил по книжному магазину, и пытался понять, что бы такое дать почитать дитятке из генетики-микробиологии. И нашёл серию "наглядная медицина". На каждом развороте довольно сложная схема, и много-много поясняющего эту схему текста мелким шрифтом. Нет, это не похоже на книжку с картинками. Это похоже на картинки с текстом! Более того, этих "наглядных" учебников стало существенно больше, чем десяток-другой лет назад.

Что касается картинок в моей собственной работе, так я от практики прошлых лет "никаких слайдов, всё рисуем фломастером на флипчарте по ходу дела" в этом году по факту вернулся к использованию слайдов (хотя и в минимальном количестве: при неспешном рассказе проходится 30 слайдов в день, многократно повторённый опыт). Не все картинки, удобные для рассказа, удаётся быстро нарисовать фломастером. Некоторые картинки лучше бы готовить заранее. Когда-то мне сказали эвристику: в хорошей презентации среднее время работы над одним слайдом -- два часа. Много раз убеждался, что это правильная оценка.

Про инфографику я подробно писать не буду, там тоже картинки с вкраплениями текста.

LMS (learning management systems) в плане создания контента выродились в слайдовые презентации на стероидах -- учитывая тот факт, что звук и видеоролики в эти слайдовые презентации тоже вставляются элементарно (http://ru.wikipedia.org/wiki/SCORM).

Active essay (www.vpri.org/pdf/tr2009002_active_essays.pdf) сегодня в точных науках делаются довольно легко -- во многих вычислительных системах реализованы notebooks, позволяющие перемежать текст, картинки, фрагменты исполнимого компьютерного кода и области вывода результатов выполнения этих фрагментов кода. Эту идею легко можно распространить и дальше: на все эти "сложные тренажёры" и "моделеры предметных областей".

Да, это всё очень разные жанры донесения содержания:
-- книжка с картинками (текст с картинками)
-- комикс/манга (картинки с текстом)
-- инфографика (сложные картинки с поясняющим текстом)
-- классический "слайдомент" из powerpoint (к которому не предполагается устного выступления)
-- SCORM-пакет в LMS
-- видео (то же аниме, но можно равным образом представить "учебный кинофильм". Меньше всего имею тут ввиду видео говорящей головы лектора -- но и это важно, ибо наблюдение за невербальными акцентами, которые делает лектор, крайне полезно)
-- active essays

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

Что даёт графика в приложении к тексту? Если это художественный текст, то компактную передачу эмоций и дополнительную красоту ("беллетристический аспект"). Если научный -- "беллетрестический аспект", aka "дизайн" в его художественном смысле слова. И уж через этот "дизайн" и об эмоциях в сухом материале тоже можно думать. Также графика может быть ключом к резкому снижению образовательного ценза для восприятия сложного материала: графика задействует иные зоны мозга, нежели требующиеся при чисто текстовой работе с одной стороны, но она может задавать нотацию, в терминах которой легко объяснять сложные явления (струнные диаграммы, фейнмановские диаграммы и т.д.). "Один раз увидеть, чем сто раз прочесть" -- как то так.

У самого меня с картинками отношения сложные. С одной стороны, у меня в аттестате восьмого класса все пятёрки, кроме тройки за рисование (не потому, что плохо рисовал, а потому что всегда забывал принести цветные карандаши), с другой стороны -- по черчению у меня была пятёрка-автомат (ибо я сумел договориться с учителем в первую же неделю принести для какой-то сложной детали два чертежа: в изометрической и диаметрической проекциях -- на спор. Чертежи я принёс, и учитель честно выполнил своё обещание не трогать меня до конца года). А потом всю жизнь я просто никогда не рисовал, ну просто нулевая практика. Я даже писал не ручкой или карандашом, а цокал на клавиатуре.

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

Тут всё очень и очень неоднозначно. Так, я не верю в графические языки для разработки: большие системы нельзя написать на графических языках, для этого пригодны только текстовые языки. Графические языки нужны только для того, чтобы вынести какую-то проблемную диаграммку на суд не слишком разбирающихся в текстовой нотации экспертов, которые будут обсуждать какой-то крошечный аспект проблемы. Но данный пост не про графические языки, он про картинки -- схемы ad hoc, из головы. Он больше про то, что-то сложное рассказывать людям хорошо бы как в манге (см., например, http://www.mangapark.com/manga/molester-man -- обратите внимание, сколько там текста!), а не как в романе Л.Н.Толстого "Война и мир" (можете даже взять иллюстрированное издание). Да, это шапкозакидательное заявление, и можно спорить: тратить ли пару часов на придумывание правильной картинки-схемы, или на полировку текста. Мне почему-то кажется, что создание правильной картинки-схемы в плане отношения затрат времени к количеству переданных из головы авторов в головы читателей ("рассматривателей", ага) знаний более продуктивно. Так, я мог бы долго полировать предыдущую фразу. А мог бы нарисовать картинку (статичную. Вря ли тут бы помог мультик, вряд ли было бы уместно активное эссе).

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

В общем, я как-то этими картинками озаботился. Интересно, сколько лет я буду озабоченным, и через сколько лет выходящее из под моего эээ... пера будет выглядеть (в прямом смысле этого слова) по-другому, чем этот "многабукофф" пост, который вы сейчас читаете.
2019

Справочные, конфигурационные, трансакционные данные

Похоже, что деления на два типа данных (справочные и проектные как в смысле design так и в смысле project) недостаточно. Более осмысленное деление такое:
-- справочные данные: картина мира, как он устроен везде -- учебники, классификаторы, справочники, стандарты, законы, upper и middle ontology и т.д.. В общем, НСИ в ассортименте, правила и ограничения живут тут. Знайте, в каком мире живёте, здесь вам не тут.
-- конфигурационные данные: функциональное и конструктивное знание о целевой и обеспечивающих системах (это и есть design и организационная часть от project -- то бишь organizational design). Инженер, знай свою систему-железку. Менеджер, знай свою систему-организацию. Знайте, с чем работаете.
-- трансакционные данные: данные об изменениях (временные ряды в ходе operations, первичка для внесения изменений в конфигурацию design, в том числе обеспечивающие системы и системы в операционном окружении). Это, по большому счёту, информация разных сообщений.

Скажем, у меня счёт депозита у провайдера в рублях, на счету 100 рублей. Справочные данные -- про то, какой счёт, про то, что на счету рубли. Состояние счёта -- конфигурационные данные. Конфигурация счёта сейчас -- 100руб. А рядом горка сведений по приходам и расходам за последний месяц. Это трансакционные данные, они были важны только для того, чтобы зафиксировать изменяющие конфигурацию трансакции. Ну, и (как всегда) что для одного трансакция (а хоть и длиной в год), для другого -- вполне себе конфигурация. ISO 15926 и его 4D экстенсионализм в помощь для решения этой проблемы.

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

Я косвенно проверил это. Примерно год назад я спросил в ACDM (http://acdm.org, Association for Configuration and Data Management), есть ли там ещё члены из России, кроме меня. Мне ответили, что я первый. То есть управление конфигурацией на плечах каких-то наших кулибиных где-то как-то выезжает (иначе вообще бы всё загнулось), но как дисциплина и профессия не живёт, да и слова такого нету.

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

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

Мораль этого моего поста такая: онтологии (в том числе и технологии semantic web) позволяют, конечно, существенно снять важность различения справочных, конфигурационных и трансакционных данных -- но только в отношении их однообразного представления. А вот практики работы со всеми этими данными на предприятии разные, и типология "справочные -- конфигурационные -- трансакционные" отражает именно эти практики. Поэтому "инженерия справочных данных" устроена одним образом, управление конфигурацией -- другим образом, а обработка трансакций -- третьим. Разные практики, разные слова, разные данные. Одно представление данных.

UPDATE: программистам просьба расслабиться. Я тут про нефтеперерабатывающие заводы и атомные станции, а не про управление конфигурацией в программной инженерией. Есть многое на свете, друг Горацио, что и не снилось нашим программистам. Большинство российских программистов про управление конфигурацией откуда-то знают (хотя не всегда успешно этой конфигурацией управляют). Но вот что касается российского "реального сектора" (конфигурации железа и бетона), то именно там проблемы.