• Когда разработчики документации считают, что их целевая система – документация. Нет, их целевая система – воплощение системы, без воплощения системы не стоит и заводиться с её описанием, документированием этого описания. Без намерения сделать систему речь идёт о «художественных описаниях», в них могут быть любые ошибки.
• Разработчики исходного кода программ (это тоже описание воплощения системы) тоже считают, что их обязанности заканчиваются тогда, когда они сделали документацию (исходный код с любым количеством ошибок) в систему хранения версии (носитель – внешняя память компьютера хранения версии). Нет, и нет: их целевая система – работающая программа, а не исходный код на любых его носителях.
• Менеджер, разработавший план мероприятий (описание системы работ, существующее в виде документации системы в программе проектного управления), воплощением системы для него будет система работ, а не этот план (а целевой системой, скорее всего – та система, которая получается в ходе этих работ).
• … и таких ошибок «описания вместо созидания» множество, на них нужно всегда обращать внимание.
Результат работы проектировщика атомной электростанции – в конечном итоге воплощение атомной электростанции, а не бумажная документация на её строительство или даже информационная модель атомной станции в компьютере. Результат работы хореографа – это в конечном итоге сам танец (исполняемый в конкретное время в конкретном физическом месте во вселенной), а не описание танца, или даже документ о танце как листочек бумаги с описанием танца. И это несмотря на то, что проектировщик сам не строит атомные электростанции, а только их описывает, а «хореограф» в его изначальном значении тоже «описатель» танца (от др.-греч. – хороводная пляска, хоровод + – записывать, писать. Первоначальное значение хореографии – это отнюдь не сочинение и постановка танцев, а именно искусство записи танца).
Люди ходят не по карте, а по территории. Карта – это только описание территории, которое может быть представлено в разных документах (электронных или бумажных, или пластиковых), и это верно для всех описаний/документов, не только для географических карт.
Карта коктейлей – это не коктейли, её не пьют. Карта находится в мире информации, даже если на ней изображены картинки настоящих коктейлей. Информация не занимает пространства-времени, она абстрактный объект, а не конкретный, даже если её нельзя представить без носителя. Карта не занимает пространства-времени. По ней нельзя «постучать», на неё нельзя «показать пальцем», как нельзя постучать по «числу 300», но можно постучать только по «изображению числа 300» на каком-то носителе.
Если же говорят, что карта занимает место/объём в пространство-времени, то речь идёт не о самой карте как информационном, абстрактном объекте, а о материальном носителе карты – бумаге и краске. Но нарисованные на карте объекты не существуют, стучать и показывать пальцем можно только на участки бумаги (или участки экрана, если это экран, или участки магнитной памяти, если это магнитная память), а не на изображённые на карте объекты.
Карта-на-носителе документирует какие-то воплощения систем (или другие описания, которые в конечном итоге всё одно должны будут дотянуться как-то логически до физического мира – иначе нельзя будет проверить их нефантазийность).
Карта коктейлей в данном случае – не система, а только документация системы «ассортимент ресторана» (system description/documentation), а информация на ней – описание системы (system definition).
А вот сами коктейли, документируемые картой/описываемые информацией на карте – это системы (воплощения системы: продукты, изделия, предприятия, люди), они занимают место в пространстве-времени, по ним можно постучать, на них можно показать пальцем, их даже можно выпить. Картинки коктейля не выпьешь. Информационная модель атомной станции электричества не вырабатывает. Описание танца не вызывает тех же эмоций, что сам танец.
Описания
Но зачем нам нужны описания, если их нельзя использовать?! Они нам нужны для мышления, которое используется для переноса опыта из одного проекта по созданию систем в другие проекты.
Мышление происходит не для отдельных систем, а сразу для множеств систем. Разработка (замысливание, проектирование) всегда ведётся не для конкретных экземпляров систем, а «в общем случае», то есть для множества подобных систем.
Множество (как математический объект, другие имена для множества – это класс, тип, вид) абстрактно. В математике множество из одного объекта не эквивалентно этому одному объекту: свойства множества отличаются от свойств самого объекта в этом множестве.