СМ-2024. Пост о невидимости системного мышления для окружающих

С трудом удается применять знания о выделении типов в работе на постоянной основе. Обычно разбор с типами начинается на моменте дребезга.

Например возникла проблема с разделением сущностей под названием “Замечание”, так как есть “замечание” как описание какой-либо нестыковки в проектном решении, а есть “замечание” как объект, который создают в среде общих данных. Проблема же заключается в том, что в одно замечание::(объект в СОД)::(запись в реестре) записывают несколько замечаний::описаний. Приходится по несколько раз проговаривать, что нужно разносить в отдельные записи, придумать понятную всем формулировку пока не смогла.

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

Приступив к заданию, ещё раз прошлась по объектам/сущностям, с которыми ведется работа, на фоне этого родилась табличка с шапкой “Описание системы” и “Метод описания”, но для коллег она будет обозначатся как “Документ” и “Стандарт/ГОСТ”.

  • Один из первых документов - отраслевое задание, которое по сути своей должно быть концепцией использования (но есть вопросы и к форме и к содержанию). Отраслевой заказчик (тот, кому нужно здание) должен определить для чего нужен объект капитального строительства (ОКС) и как он будет использоваться;
  • Дальше появляется техническое задание, которое я бы определила как концепцию системы, так как там уже происходит разбиение на части и описываются требования к техническим решениям;
  • Проектная документация::описание и цифровые информационные модели (ЦИМ)::описание уже отражают конкретные технические решения;
  • Ведомости объемов работ - описание, которое как минимум отражает количество необходимых материалов, оборудования для создания ОКС;
  • Смета::описание, где подробный расчет ресурсов переводится в стоимость возведения.

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

2 лайка

или не удовлетворить чьи-то интересы. Хотя, это, наверное, равносильно “не построить объект”

кстати, а можно техническое задание назвать описанием системы?

может попробовать им зайти с момента как эти записи используются? Показать, что если если несколько записей скомканы в одно то это тяжело использовать по тому-то и тому-то? Может тогда проникнутся? Обычно сложно воспринимать абстрактные: делай так потому-что.

А почему нет? С какой-то точки зрения описывается именно система.

Так тоже пыталась, но возможно слишком скомкано, подумаю как это развернуть. Спасибо )

1 лайк

Техническое задание – это “задание на работы”, там перечисляются работы создателя. То есть это описание создателя ))) Но там есть раздел с описанием создаваемой системы, причём там ещё и часть архитектуры обычно прописывается сразу, не только “чёрный ящик”. Очень гибридное описание, винегрет всего – но много чего нужного там нет. Это независимо от отрасли, везде так. ГОСТы на техзадания не системны.

1 лайк