"Логика, она знаешь, вся построена на удобстве. Никто не придумывает логику, которая неудобна для рассуждений, все хотят упростить рассуждения с помощью логики, а не усложнить. И базовая логика заложена в структуру таблиц - по строкам вещи, по столбцам их свойства. Если ты поместила категории одежды в столбец, то ты сделала вещь атрибутом другой вещи". "Ну да, для другой вещи это может быть атрибутом, хотя слово то же самое". "То есть фасон может быть вещью, объектом?" "Да нет, фасоны у одежды, это всегда атрибут, как и цвет".

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

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

"Подожди, папа. - Саша замедлила шаг. А у этих новых объектов - у фасона, ткани, есть категории? Ведь должны же быть, если они есть у одежды?" "Если есть необходимость, то да, только обычно говорят не о категориях, а о классах. Объекты группируются в классы. У платьев есть суперкласс одежда и подклассы - коктейльное, свадебное и т.д. У фасонов, наверное, нет суперкласса, зато точно есть подклассы, мы про них говорили. У ткани есть суперкласс - материал, ведь одежду делают не только из тканей, но и из кожи, например, и есть подклассы - льняные, хлопковые, синтетика". "И у каждого класса-суперкласса-подкласса есть свой набор атрибутов?" "Ну да, и тут главное как сделать такую структуру классов и атрибутов, чтобы они между собой не перемешивались, чтобы не получилось как у тебя, что одно и то же слово одновременно является классом объекта и его атрибутом. Этим занимаются онтологи, инженеры данных, они придумывают такие вот модели предметных областей, чтобы было удобно и точно описывать объекты этой предметной области".

"А ты онтолог?" "Не, когда мне нужна онтология, я всегда ищу готовую, их много разных лежит в Интернете, надо просто поискать. Каждый раз, когда я захожу на проект, я всегда изучаю типовые онтологии, ищу, например, banking ontology, aviation ontology или retail ontology. И сразу становится намного проще разговаривать с командой, потому что ты понимаешь, о каких вещах они говорят, что для них важно, о чем еще надо поговорить". "А я всегда удивлялась, как это ты можешь советовать что-то людям, если ты по этой теме ни дня не работал". "Ну, некоторые мыслительные приемы и ходы довольно универсальны. Скажем так, что в 80% случаев мой подход работает, но в 20% я ничем помочь не могу. Но 80% - это неплохой результат, не правда ли?" "100% лучше". "100% лучше. Согласился Борис. Эй, куда Женя убежала?" И они побежали искать младшую.

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

Метаданные показывают как связаны между собой эти данные в головах людей. И для этого нам нужно все больше знаков.

Эти знаки на метауровне, в свою очередь тоже имеют связи, которые тоже можно пометить метаметазнаками.

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

http://www.jfsowa.com/ontology/ontometa.htm

Интерактивная карта
https://www.art-sciencefactory.com/complexity-map_feb09.html

Доверие и его воплощения на цифровых рынках (Роман Химич, Егор Чурилов)

Подкаст:
"Почему современный инфобез не поддерживает цифровую трансформацию и каким он должен стать, чтобы решать проблемы реального мира?"
послушать подкаст

Подробная статья:
скачать статью

Минимально жизнеспособный желтый. Когда маркетинг тупит с неймингом

Минимально жизнеспособный желтый, минимально жизнеспособная любовь, минимально жизнеспособный принцип Гейзенберга.
Что не так с этими терминами? К абстракциям неудобно применять понятие жизнеспособности. Можно, конечно, сказать, что идея нежизнеспособна или подход неприменим к данной ситуации, но смысл такого выражения все равно будет далек от точного смысла концепции MVP.

Про концепцию minimal viable practice.

Уроки Академии Хана позволяют вспомнить правильные знания, которые у нас уже были, но в то же время укрепляют имеющиеся у нас неверные представления

Этот механизм работает так:

1. Студенты думают, что они уже знают про вещи, которые объясняет ролик (а, опять про эту штуку! 90% закрывает видео после первых 15 секунд)

2. Они не обращают особого внимания на объяснения и ход мыслей (ну да, ну да, я все это уже слышал сто раз)

3. Они не понимают, чем объяснение отличается от их представлений о предмете (здесь чувак налажал с объяснениями, все не так, но в целом норм)

4. Они не выучивают ничего нового (если не закрыл видео после первых 15 секунд, то "ничего нового, я все это уже знал")

5. Они укрепляются в своих неверных представлениях (я все это уже знаю, я крут)

Решение:

Видео с объяснениями должно указывать студентам на неверность концепций.

Пример такого ролика.

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

Соломенный учитель

Любой человек с практическими знаниями по тому, что такое (настоящая) математика (1) и как работает мозг (2), понимает, что для практического изучения математики необходимо как совершенство во владении базовым аппаратом так и концептуальное понимание математических нотаций, на базе которых этот аппарат построен.

В практическом плане это означает, что вам надо:

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

И это то, что делает хороший учитель математики.

Заметка целиком.

Онтология

Современное определение по Lowe - 1995
“набор объектов, существование которых признается определенной теорией либо школой мышления”

Если перевести это в термины софта, то
“определенной теорией либо школой мышления” = существует в приложении и данных приложения.

И тогда
онтология софта = “набор объектов”, на которые ссылаются данные такого приложения.

Управление продуктом: команда, методы, практики
(вер.01 29.12.19). Пакет 1.

Зачем это все?

Я помню, как мне в руки попал первый iPhone. Единственное, что я сразу понял - это как с него звонить и писать СМС. Все остальное было загадкой - приложения, карты, видеозвонки, календарь, синхронизация с компьютером. Я даже не мог послушать с него музыку, потому что в iPhone нет папок и файлов, и я не знал, а как еще можно скопировать музыку с компа на телефон. Это была такая необычная вещь, что про нее пришлось много что учить и узнавать нового.

А ведь кто-то эту необычную штуку придумал и сделал. "Как они такое выдумали и сделали?" - крутился в моей голове вопрос.

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

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

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

Я объединил эти три знания и понял, как инженеры думают о продуктах.

В наш мир приходит все больше необычных вещей, а использование многих существующих постоянно переосмысливается. Вещи становятся все более сложными, и даже для того, чтобы перевести ERP, CRM или WMS/TMS из опытной эксплуатации в серийную, надо как следует постараться и подумать. Полностью полагаться на то, что за заказчика все сделает разработчик продукта уже нельзя. Любой менеджер сейчас должен уметь думать о продукте и ставить задачу на его доработку, даже если это не входит в описание должностных обязанностей. Мышление руководителей должно приблизиться к мышлению инженеров и программистов. И тогда для них наступит освобождение от парадигмы "я придумываю, как зарабатывать деньги, дело разработчиков - исполнять замысел". Бизнес-замысел должен подстраиваться под технические возможности, но при этом не должна наступать диктатура исполнителя.
С другой стороны, и у самих проектировщиков и программистов наступили времена, когда нельзя просто взять и реализовать полученное на старте техническое задание. Во время разработки проектных решений надо закладывать возможность их последующего изменения, надо понимать, у кого что спросить и что необходимо уточнить перед тем, как начать работу, чтобы не сделать ненужную доработку или функцию. И мышление современного программиста или проектировщика должно стать ближе к мышлению руководителей, в их голове должно появиться четкое денежное и социальное измерение работы. И тогда для многих из них, которые застряли в парадигме "я реализую ровно то, что написано в постановке задачи и не понимаю, чем заказчик недоволен" наступит долгожданное освобождение от диктатуры заказчика.
И для тех и для других решение лежит в одной плоскости - надо уметь четко структурировать объекты в реальном мире, подбирать под них работоспособные концепции, строить на базе этих концепций понятийный аппарат, строить на базе понятийного аппарата логику достижения цели и получения нужного результата, подбирать метод организации работ под конкретные условия, в которых работает команда, вовремя вовлекать нужных людей и давать им ровно ту информацию, которая нужна для принятия нужных решений. Словом, все то, что обычно называют "здравый смысл" и "умение включать голову", но я разобрал эти общие рекомендации на сотню конкретных отрабатываемых навыков, которые совместно составляют более-менее современный корпус системноинженерных знаний.

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

В своей работе я использую идеи из следующих источников:
Системное мышление 2019. А. Левенчук,
Системный инженер: Как начать карьеру в новом технологическом укладе. В. Мизгулин,
Курс по онтологике. П.Медведева,
Блог http://anticomplexity.org/ Е. Чурилов
Блог http://howtoknowhow.ru/ М. Ковина-Горелик
Стандарт Semantics of Business Vocabulary and Rules, OMG
Chris Argyris Organizational Traps: Leadership, Culture, Organizational Design

Читать введение и первый блок

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

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

Рассуждения и выводы в системном подходе всегда иерархичны и их можно структурировать по пирамиде Минто.

https://sdu2020.blogspot.com/2020/01/01-070120-2.html

Почему управление рисками оказалось в такой плачевной ситуации?

Бритва Хэнлона говорит нам, что не надо приписывать злому умыслу то, что можно объяснить глупостью. Я дополню эту мудрость: "Не надо приписывать злому умыслу или глупости то, что можно объяснить умеренно рациональным поведением людей, которые пытаются получить предлагаемые им вознаграждения в системах со сложными взаимодействиями". Люди, которые действуют без централизованной координации в своих интересах, могут создать ситуацию, которая со стороны будет выглядеть в точности как заговор или преступная неосмотрительность.
... [полный текст по ссылке]
По моему мнению, шкала применимости методологий по управлению рисками выглядит так:
1. Лучшие методологии. Компания создает численные модели для проведения имитационного моделирования. Входные данные для таких моделей проверяются с помощью подтвержденных статистических методов, когда обосновано, проводятся опытные измерения, анализируется уровень риска и прибыльность портфеля. Аналитики всегда скептично настроены по отношению к моделям, сверяют их с реальностью, продолжают улучшать модели рисков объективными показателями. По всей компании проводятся регулярные систематичные усилия по выявлению рисков.
2. Лучше среднего. Строятся численные модели оценки рисков с использованием по крайней мере каких-то компонентов метода с доказанной эффективностью. Управление рисками покрывает все больше рисков.
3. Точка отсчета. Оценка рисков и определение стратегий реагирования производится на основании интуиции руководства. Никаких усилий по внедрению формальной системы управления рисками не производится.
4. Ниже среднего (почти бесполезно). Используются подробные балльные модели оценки рисков либо численные методы применяются неправильно, но руководство не полагается на результаты таких численных оценок рисков. По результатам не особо хуже варианта 3, за исключением того, что на все это тратятся ресурсы.
5. Худший вариант. Используются неэффективные методы, которые только добавляют ошибки, но руководство полагается на результаты этих оценок. Возможно, на управление рисками тратится куча сил, но нет никаких доказательств того, что полученные результаты лучше интуитивных догадок. Сложные методы хуже, чем отсутствие метода или использование неэффективного метода. Они приводят к тому, что принимаются ошибочные решения, которые в ином случае вообще бы не были приняты.

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

The Failure of Risk Management: Why It’s Broken and How to Fix It Douglas W. Hubbard

Пути и варианты в пространстве выборов проекта

В английском языке для обозначения решения используются два разных слова - decision и solution. Например, руководитель проекта - это decision maker, тот, кто принимает управленческие решения, а руководитель отдела разработки, который ведет работы по подсистеме - это solution architect, тот кто принимает технические, проектные решения. Если уходить от составных терминов "управленческие решения" и "проектные решения" и пытаться сказать проще, то наиболее близким по смыслу будут слова "пути" и "варианты" соответственно.
Какие есть пути достижения цели? Другими словами, какие цепочки действий надо выполнить и какие ресурсы и средства нужны, чтобы их выполнить и прийти туда, куда надо?
Какие есть варианты? Куда мы придем конкретно? Другими словами, какие есть варианты итогового результата? Какая проблема и как конкретно будет решена? Какие варианты организационно-технических решений существуют для данной ситуации?
Первый набор вопросов задается руководителями и ответы на них ищутся в дисциплине проектного управления (P3M, portfolio, program and systems management). Второй набор вопросов задается системным инженерам и ответы на них ищутся в дисциплине системной инженерии (MBSE, model-based systems engineering).

Пути определяет руководитель проекта, а варианты - системный инженер.

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

Продолжение в блоге.

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

Трагедия первого рационального агента

Есть реальный мир и есть его концептуализация. Если взять классический цикл plan-do-check-act, то:
- планируем мы в уме, на бумаге, не в реальности. Мы концептуализируем целевую ситуацию и пути достижения - составляем списки дел, планируем встречи в календаре, ведем трекер;
- затем переходим в реальный мир, делаем, что можно сделать. При этом клиент не приехал на встречу, зато прислал гневное письмо, Маша опять заболела, в шквале писем потерялось важное и начальник собрал экстренное совещание на два с лишним часа для разбора последствий;
- сверяемся с моделью. Открываем список дел, календарь, понимаем, что есть серьезные расхождения.

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

Но в действительности мы видим, что act не происходит почти никогда. Чаще мы видим react. Вместо business actor, рационального агента, субъекта, мы работаем с business reactor, объектом, с которым внешние обстоятельства делают что хотят. Которого несет поток _обстоятельств_неодолимой_силы_.

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

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

В этом и состоит трагедия первого рационального агента.

Композитор, который не хотел, чтобы его музыку слушали

Идея фоновой музыки для человечества в целом оказалась более сложной, чем теория относительности.
Больше 50 лет люди безуспешно пытались научиться слушать фоновую музыку, ее изобретатель, Эрик Сати, спился от горя (но попутно помог вырасти ДеБюсси), а мы и сейчас слушаем его произведения.

Ровно сто лет назад в парижском театре в антракте заиграл эмбиент. Инструменты были необычные - кларнет, тромбон и рояль. Публика, которая до этого прогуливалась по вестибюлю, тут же бросилась занимать сидячие места и тщательно вслушиваться в тихую однообразную, "скучную", как выразился сам Сати, мелодию. Он кричал, упрашивал гостей: "Да разговаривайте же, гуляйте! Не слушайте!", все было зря, они слушали и молчали. Вечер был испорчен. Сати был в ярости, ведь в афише гостям четко объяснялось, что "внимания этой музыке надо придавать не больше, чем люстрам, которые освещают холл". Но объяснить эти революционную идею было невозможно, люди привыкли слушать музыку, и не могли относится к ней как к фону.

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

Эти моменты надо учитывать при развитии продукта, если вы хотите, чтобы "он менял мир". Эрик Сати делал все, что делают современные стартапы - менял продукт, функциональность, сегменты, постоянно проводил демо-дни, продвигал-продвигал-продвигал, но успеха не добился. В тех сегментах, куда он заходил, не было практики использования музыки как фона. А как внедрять новые практики, в то время еще не знали, пропаганда и реклама только-только появлялись.

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

Getting things done in greenfield is no more an option for EA

Сложно рекапить последнее выступление Марка Ланкхорста (видео, слайды), потому что идейно мы с ним очень близки, а BizzDesign дает реально лучший инструментарий для применения практики архитектуры предприятия. Поэтому я помещу тезисы его выступления в контекст и разверну один аспект, который он только слегка засветил на вебинаре.

Это выступление было в стиле data fusion, объединение различных источников в связный рассказ.

Источники идей, которые засек я:

Chess And The Art Of Enterprise Architecture, Blame the Mathematicians! by Gerben Wierda
What color is your backlog by Philippe Kruchten
The architect elevator by Gregor Hohpe
Software Architecture Guide by Martin Fowler

...

Чисто практически это означает, например:
- итерации архитектуры с учетом в Jira. В каждой задаче можно создать ветку архитектуры проекта, в которую входит как системная архитектура, так и корпоративная архитектура. Именно возможность менять архитектуру через трекер и есть эти самые маленькие итерации, которые показывал на слайдах Марк;
- последовательности собраний. Ветки должны попадать в meeting sequence, как минимум арх.совет (пн.), change approval board (вт.), project status review (ср.), результат докладываться спонсору/директору проекта;
- жизненный цикл объектов и отношений. Если мы говорим про постоянное обучение, то как отражать в модели это постепенно возникающее понимание? Как отделить догадку от сформулированной и подтвержденной гипотезы, как указать на микротеорию? У объектов и отношений должны быть соответствующие атрибуты - "внесен со слов стейкхолдера", "проверен по литературе (сопоставлен с дисциплиной)", "операционализирован", "подтвержден(-а"", "опровергнут(-а)". У объектов и отношений должен быть владелец, автор, кто носит полные знания об этом куске модели реальности, у кого можно спросить, что же имеется в виду.

Выводы:

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

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

https://sdu2020.blogspot.com/2020/03/getting-things-done-in-greenfield-is-no.html

Студенты регулярно путают состав и структуру системы. Давайте приведу простую иллюстрацию.

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

Структура не равна составу.

Управление составом изделия - это PDM, product data management.
Состав - это компоненты. Управление составом - это планирование и контроль перечня компонентов и указанием какой компонент входит в какую сборку.

Управление структурой изделия - это MBSA, model-based systems architecture.
Структура - это связи между компонентами. Управление структурой изделия - это планирование и контроль проектных решений, которые позволяют реализовывать требования к изделию.

Составом ПО не управляют, это бессмысленно. У ПО есть конфигурация. Управление конфигурацией - это CM, configuration management.

У изделий тоже есть конфигурация и она не равна составу и структуре. Но в паре предложений о ней не расскажешь.

Как создать модель рабочей практики в формате научной статьи?

Я вел своих детей в детский сад и школу, и младшая спросила меня - а почему когда мы идем, то фонари двигаются на нас, а Луна улетает от нас, двигается туда же, куда и мы? Я немного подумал, и понял, почему так кажется. Дело в том, что люди воспринимают скорость как изменение угла и размера, а тут ни угол ни размер не меняется, и значит, далекие объекты кажутся нам неподвижными, или, если мы идем или едем, "двигаются" вместе с нами. В тот момент я понял, что машинально сделал то же самое, что делаю по работе - я смоделировал рабочую практику, в данном случае практику измерения расстояний. Я взял набор базовых фактов, про то, что фонари двигаются на нас и увеличиваются, а Луна двигается с нами и не меняет размер. Я взял концептуальную схему из трех понятий - угловая скорость, угловой размер, скорость наблюдателя, которая объясняет базовые факты и может достоверно их предсказать (когда мы пошли задом, Луна стала на нас надвигаться, а фонари поползли назад и уменьшились).
[текст целиком]
Шаги создания метамодели практики:

Проблема 1. "3 километра терминов и определений". Решение - структурирование области обсуждения (domain partitioning and contexts definition). В хранилище проекта должна появиться папка "Область обсуждения".
Проблема 2. "А что такое вещь?". Работы как вещи, процессы и проекты как типы работ. Решение - определение состояний вещей, выделение стадии использования. Необходимо пересмотреть описания процессов и планы проектов.
Проблема 3. "Как объединить каталоги?". Решение - PBS, WBS, SBS и другие разбиения. Универсальных решений нет, но подход единый.
Проблема 4. Измерение неизмеримого. "Что измеряет панель Google Analytics?".

Решение - концептуализация предметной области как заказчика так и разработчика плюс операционализация концептов.

Создание и применение (мета)модели практики для выявления и прохождения развилок проекта (project and design trade-offs). Научные статьи как метод рефлексии над ходом проекта и принятыми решениями.

Рубрика "К 40 годам до меня дошло"

Роли менеджера, преподавателя и родителя очень схожи в одном моменте. 90% работы заключается в постоянном повторении прописных истин и выслушивании ответного "да знаю я, знаю!"
Но знать и делать - очень разные вещи.

Различаются же эти роли тоже в одном, но крайне важном моменте. Объяснения для детей можно подбирать до тех пор, пока они не поймут, хоть 200 раз разными словами на разных примерах объясняй. Это от ютюбера они отпишутся, а от тебя нет. С коллегами сложнее, но тоже есть от 20 до 50 попыток. А с клиентом есть одна, ну пусть две попытки донести мысль. И что бы ты ни рассказал взрослому человеку, сто баллов, что он это уже хотя бы краем уха слышал либо загуглил сразу после первого упоминания. Что-то новое и актуальное ты вряд ли сможешь донести. Различие между преподом и клиентом в умении применить знания к ситуации, в умении сделать. Именно это и продает препод - типа научу делать как я. И показывает пируэт. А дальше должен за одну попытку объяснить как он научит этот пируэт делать.

Но вначале он должен придумать такой пируэт, который будет понятен клиенту да еще и будет иметь для него ценность. Потому что большинство полезных советов упрется в очевидные "мойте руки перед едой". И люди бы помыли, но они уже сидят за столом, уже принесли еду, она остывает, а умывальник находится в 20 метрах да и руки чистые, поэтому понимая правильность этого принципа в целом, конкретно сейчас мы это проигнорируем и поедим так. Аналогично можно не сыграть пару нот в известной мелодии, потому что ее и так все знают, а в оркестре кто эти пару пропущенных нот услышит; не сделаем пару регрессионных тестов; не оформим принятые на последнем собрании решения протоколом; напишем корявое письмо заказчику. И вот уже, по меткому выражению окружного прокурора из Billions: "Не успеешь оглянуться, и весь город погряз в собачьем дерьме". Понимание большинства сводится к: "Я знаю кунг-фу, каратэ и много других страшных слов". И пируэт почти всегда заключается в повторении преподавателем одной и той же фразы: "Здесь Родос, здесь и прыгай". В том смысле, если ты, ребенок, коллега или клиент, это на самом деле знаешь, примени это свое знание прямо к текущей ситуации и расскажи нам о своих ощущениях. Ну что, а теперь поговорим всерьез?

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

А самой частая мысль, которая приходила мне в голову в последние пару лет, была: "Если вы такие умные, что же вы строем не ходите?" И чаще всего этот вопрос я задавал себе.

Dislike, unshare, unsubscribe. С днем рожденья меня.