Обсуждение

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

1. Мне кажется, тут нужно отделить мух от котлет. Есть существующие карты: они не всегда устраивающим нас образом отражают систему, что особенно заметно, если система уникальна (например, для своих целей мы можем пожелать объединить политическую и физическую карту в одну). Но существующими картами можно воспользоваться для сокращения трудозатрат и, немного модифицировав, использовать для своих целей. Вот это и нужно разделить: уникальность карт для каждой уникальной системы, но при этом возможность использования уже существующих карт. Мне кажется, эти существующие карты и карты нашей системы могут соотноситься друг с другом, как модули и компоненты в вашей терминологии (если я не ошибаюсь). Конечно, все существующие карты необходимо иметь в виду инженерного проекта, также как и любые другие ресурсы и возможности. Но нужно помнить, что в этих существующих картах, которые отражают те или иные практики, наша система пока отсутствует. 2. Проекты, процессы, кейсы – это совершенно разные подходы, и системы для этих подходов, вообще говоря, могут различаться, особенно, если рассматривать систему, как 4D объект. В момент принятия решения (а это 3D срез 4D системы) работа токаря, вытачивающего деталь, конечно, может и не зависеть от того, решили ли мы смотреть на нее, как на процесс, или как на проект/кейс. Это происходит потому, что пока это отношение находится в нашей голове. Но через некоторое время (другой 3D-срез той же системы) различия могут появиться в качестве результата обработки детали, в эффективности такой обработки, и т.п. Различия могут появиться даже в момент принятия решения. Приведу другой пример. Допустим, у нас есть автомобиль с прицепом. Исходя из нашего стиля жизни, мы выбираем отношение к этому автомобилю: как к городскому автомобилю или как к грузовому автомобилю для дачи. Во втором случае прицеп является неотъемлемой частью системы, поскольку существенно увеличивает важный для нас параметр вместимости. В первом случае прицеп совершенно бесполезен и рассматривается, как отдельная система. Получается, наше отношение к системе способно менять ее физическую конфигурацию. Точно так же, при выборе отношения проект/процесс/кейс целевая система может меняться. Иногда до неузнаваемости.

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

1. Я говорю и о методах картирования тоже, они тоже для каждой системы уникальны. В большинстве случаев можно использовать стандартные методы, но нас ведь интересуют наиболее сложные и ответственные задачи? Представим, что для системы разрабатывается подсистема электроники, и что для системы принципиально важно исключить любую возможность, скажем, короткого замыкания, иначе можно даже и не начинать проект. Для такого случая инженер может разработать специальные схемы с нотациями, структура которых гарантирует практическое отсутствие возможностей короткого замыкания. Предметная область хорошо известна, но методику ее картирования для этого проекта приходится разрабатывать уникальную. В менее критических случаях это тоже проявляется, хоть и в меньшем масштабе. Вообще, чтобы использовать в проекте любую предметную область, ее нужно прикрутить к проекту с помощью определенных посылок, которые вытекают из содержания проекта. Эти посылки определяют саму возможность и порядок использования типовых методик проектирования, а если их использование невозможно, то порядок разработки методик специально для данного случая. С этой точки зрения абсолютно типовых методик не может быть в принципе. 2. По поводу карты и деятельности. Вы когда-то писали о том, что границы объекта определяются исходя из интересов стейкхолдеров (кажется, это было обсуждение понятия «коллектива» и его границ). Я тогда был горячо с вами согласен и сейчас спешу вам напомнить об этом положении применительно к токарю и его деятельности. Интересы стейхолдеров определяют границы этой деятельности. Эти же интересы (одновременно) определяют оптимальный для стейкхолдеров способ управления этой деятельностью – проект, процесс или кейс. Что тут впереди, а что позади, - это вопрос уже нашего удобства (мы рассматриваем систему токарь + стейкхолдеры со стороны). По расположению телеги мы быстро отыщем лошадь, а по расположению лошади – телегу. Спорить что должно быть первым, бессмысленно: можно выбирать любой из способов. Но результат анализа будет один и тот же - телега с лошадью.

Ну, метод описания либо определяете, либо берёте библиотечный -- просто он должен быть, и о нём нельзя забывать. Меня тут волнует, то, что не нужно изобретать метод описания, если речь идёт об описании работ -- как минимум, нужно знать про существовании стандартных: проектного, процессного, кейсового. И ещё помнить, что можно описывать не работы, а деятельность -- а это уже функциональный объект. И тоже это "помнить" -- это из знаний, а не изобретая велосипед каждый раз. Насчёт стейкхолдеров, так у вас всё время пропускается в рассуждениях "интересы", а это first class object. Там цепочка "стейкхолдер -- интерес -- метод описания -- описание". Метод описания (viewpoint) обрамляет (frame) интерес (concern) -- и в этом рассуждении мы ещё до собственно описания и не доходим, только разбираемся с тем, на какой вопрос отвечаем. Нюансов тьма, но я тут в комментах явно не смогу пересказать полный день тренинга. )))

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

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

Так ведь токарь может быть из другой системы - например, из Китая с доставкой по морю. Лучшего решения сразу добиться невозможно. Происходит постепенное улучшение прототипов. В машиностроении существуют сборочные чертежи, все детали из других проектов. Для проекта достаточно иметь матрицу из декартового произведения всех ограничений. Если конфликтов не обнаружено - проект работоспособен. А то, что что-либо можно улучшить - регистрируется в рационализаторской деятельности с проверкой практикой и тестированием на отсутствие возникновения конфликтов с предыдущими решениями. Именно решениями - результатами выбора.

Изображение — открыть источник Однако есть таки методы, приемы и техники. Исключительно по Геделю

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

Периодически занимаюсь тем-же. Интересно Ваше мнение о статье https://habrahabr.ru/post/259291/

Моё последнее открытие из серии "очевидного невероятного" — что большинство заказчиков не готовы читать одномерные проекции архитектур программных систем по модели 4+1, это удел избранных инженеров. Они предпочитают комплексные многоаспектные модели, когда на одной диаграмме даны и участники и деятельность и артефакты и части системы. Приходится с этим считаться.

Да, гибридные модели рулят -- в них есть надежда, что "всё учёл" ))) Ещё можно пожаловаться, что аспектное программирование "не взлетело", ибо там а) не было хороших средств для переплетения существенно разных аспектов, и б) после хорошего переплетения уже назад не расплетёшь -- отладка обычно была провалена. Но... других способов борьбы со сложностью как-то нетути. Абстрагирование обычно предметно, и этих "предметов" набирается пара дюжин влёгкую. Сейчас с этим месивом гибридности пытаются разобраться по линии выделения concern как 1st class object. Все современные стандарты это выпячивают. Сначала concerns, потом уже диаграммы (по понятным причинам, каждый раз менее и менее гибридные, по мере проникновения в массы идеи о concerns и обрамляющих их viewpoints).

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