После того, как выделены проектные роли и их интересы, потребуется приготовить для них множество различных описаний. В рамках практикума мне надо было рассмотреть хотя бы самые главные описания системы. Т.к. деятельностного кругозора в стройке у меня, повторюсь, не было, я не представлял, с какой стороны подступиться к задаче.
Помог простой шаг: я полез смотреть учебный план для строительных архитекторов, которые по определению должны решать 2 типа профессиональных задач: проводить предпроектный анализ и архитектурное проектирование (синтез). Выяснилось, что есть отдельная дисциплина "методология проектирования", стал гуглить дальше, вышел на кучу всяких стандартов по подготовке описаний, и даже описаний описаний (какие значки надо использовать в чертежах, которые готовят в качестве описаний). Рекомендую всем, кому хочется hard fun, заморочиться и попытаться разобраться в своей предметной области, что такое модель, что такое вид модели и что такое метод описания, и как в одном документе могут быть собраны воедино все главные описания: и функциональные, и компоновочные, и модульные. Я понял, что такое "читать чертёж"!
Стало понятно, что есть "рекомендуемый формат описаний", а есть "описание из жизни", и зачастую обеим сторонам в коммуникации достаточно простого варианта из жизни. Сравните эти 2 чертежа:
Когда восторженный неофит, такой как я, смотрит на идеальную картинку, рука тянется всё что есть в жизни - срочно переделать. Но тут надо вспомнить, что поменять практику описания - это отдельный проект организационного развития, который возможно потребует нехилых ресурсов и должен, как и любой другой системно осмысляемый проект, иметь сначала ответ на вопрос "зачем", какой проектной роли станет хорошо, если описания станут четче, прозрачнее, ближе к стандартам?
Самым замороченным для меня стал вопрос: если описание отвечает на тот или иной интерес проектной роли, то можно ли при этом понять из описания, отвечает ли система требованиям? Как вообще связаны понятия "интересы" и "требования к системе" между собой? Если вам оно тоже любопытно - надо на курс "Онтологики", самому без поллитры без тамошних вводных не разобраться. Короткий спойлер дан в курсе: "требования - это уже договорённые значения каких-то характеристик системы, предпочтения проектных ролей в них уже учтены. Требования описывают целевую систему, предпочтения же описывают хотелки отдельных ролей. Они про разные объекты: требования про систему, предпочтения <и интересы> про роли". Скажу честно, я эту фразу увидел и понял куда девать в голове только на повторном прочтении кусков учебника, когда курс и Практикум был завершен. Они не врут: после прохождения курса перечитать учебник заново - реально полезно!