Смотрите, по сути проблемы мы уже не расходимся — вы её сейчас описали даже жёстче, чем я в статье. Вопрос остался один: с чего начинать. Вы говорите — со стандартизации, типовых маршрутов, интеграции ПО. Всё так, работает. И роли с ответственностью в зрелых методологиях тоже прописаны. Но живут эти роли, пока идёт проект. А статья про то, что дальше: у кого остаётся логика решений, когда работы закончены и люди разошлись.
И здесь расскажу случай из практики, без имён. Нас пригласили на поддержку проекта после того, как с него в один момент ушёл крупный зарубежный подрядчик — из тех самых, с эталонными процессами, работавший на стеке Hexagon. Нам передали всё: среду, модели, документацию, базы. Формально комплект полный. Но часть решений читалась только по результату: сделано так, а почему — из переданного не восстановить; например, какие-то атрибуты появлялись в спецификациях после постобработок, которые никто уже не мог объяснить. Пример тем и показателен: зрелые процессы и хороший стек сами по себе не гарантируют, что логика решений переживёт уход команды.
А то, чего вы не находите в статье — как стандартизировать процессы, как строить интеграцию, какими инструментами, — это методика внедрения. В статью про то, кто должен владеть инженерной памятью, она не помещается по жанру, потому её там и нет
В вашем примере, по сути, две разные беды, и обе по теме статьи.
Первая — подмена дефайн перед компиляцией и костыли без пояснений: почему сделали именно так, уже не видно. Это ровно про потерю логики решения.
Вторая — умершая среда: исходники есть, но собрать их уже не на чем. На первый взгляд это выглядит как возражение: какой смысл хранить файлы, если среда всё равно устареет? Но для меня это скорее аргумент в пользу инженерной памяти.
Файлы могут лежать на сервере десятилетиями сами по себе. Среда так не живёт: её нужно сопровождать, переносить на новые инструменты, фиксировать библиотеки, параметры сборки и критичные настройки. Судя по описанию, никто вовремя не пересадил код и окружение в живую среду — поэтому вместо сопровождения началась археология, которая иногда обходится дороже, чем разработка заново.
В статье я как раз об этом пишу: инженерная память — это не папка на сервере, а живой контур с владельцем, который ведёт и данные, и среду через смену инструментов и команд. Спасибо за пример — считайте, что дописали к статье ещё один кейс.
Всё, что вы описываете — задание ГИПа, разрешение, доступ к новой ревизии на основании ранее выпущенной — начинает работать после того, как документация выпущена и утверждена, а участок модели заблокирован. Этот порядок я не трогаю, он нужен. Но статья про другой отрезок — до первого утверждённого выпуска. Проектировщик ведёт модель в своём рабочем контуре — задания, статусы, проверки там есть, но для Разрешения в классическом смысле ещё нет выпущенной ревизии, к которой его можно привязать. А главные решения принимаются именно здесь: чем наполняются данные, как увязываются атрибуты и связи, почему модель дошла до выпуска именно такой. И оговорюсь про термины: речь у нас о промышленных капитальных объектах — заводах, установках. Грубо говоря, рабочий контур там — программы, в которых создаётся модель, плюс СОД, а выпуск и согласования — в документообороте. И какой инструмент ни возьми, версии отвечают на вопрос "что было", а не "почему так сделали".
Так что говорим мы про разные отрезки жизни проекта: вы — про то, что после утверждённого выпуска, я — про то, что до него. Оба отрезка нужно держать под контролем, просто инструменты у них разные.
Вот теперь мы добрались до сути расхождения, и это хорошо.
С регистрацией изменений по 21.101 никто не спорит — механизм рабочий, и там, где он честно ведётся, история выпущенной документации прослеживается. Но весь этот аппарат включается, когда изменение уже дошло до бумаги: поправили чертёж, переписали абзац в пояснительной записке, передвинули позицию на схеме — и всё это оформили. Статья же про то, что происходит раньше, до всякой регистрации: сегодня первоисточник — информационная модель, и чертёж, и схема, и записка выпускаются из неё как производные. И вопрос не в том, как зарегистрировать изменение листа, а в том, под чьим контролем сами данные модели — атрибуты, связи, версии — и откуда они вообще берутся. По сути, регистрация работает уже со следствием. Статья — про причину.
Так что ГОСТ мы с вами читаем одинаково, расходимся только в том, к какому слою его прикладывать. Спасибо за обстоятельный разбор
Спасибо, что прочитали так внимательно. Колючесть — это нормально, предметный спор полезнее вежливых кивков.
Про стандарты спорить не буду, потому что не с чем: ГОСТы, ISO 19650 и 15926, TQ/TD — это то, чем мы работаем каждый день, никакого открытия тут нет. Статья про другой слой: не чем заменить стандарты, а куда девается понимание, почему сделано именно так, когда проект сдан, команда разошлась, а объект ещё живёт. Грубо говоря, ПДД у всех одни, а ездят все по-разному — и разбираться приходится именно с ездой.
Про масштаб потерь по отрасли во многом соглашусь, но это тема для отдельного большого текста, а не для ветки комментариев. Ещё раз спасибо за время.
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
Смотрите, по сути проблемы мы уже не расходимся — вы её сейчас описали даже жёстче, чем я в статье. Вопрос остался один: с чего начинать. Вы говорите — со стандартизации, типовых маршрутов, интеграции ПО. Всё так, работает. И роли с ответственностью в зрелых методологиях тоже прописаны. Но живут эти роли, пока идёт проект. А статья про то, что дальше: у кого остаётся логика решений, когда работы закончены и люди разошлись.
И здесь расскажу случай из практики, без имён. Нас пригласили на поддержку проекта после того, как с него в один момент ушёл крупный зарубежный подрядчик — из тех самых, с эталонными процессами, работавший на стеке Hexagon. Нам передали всё: среду, модели, документацию, базы. Формально комплект полный. Но часть решений читалась только по результату: сделано так, а почему — из переданного не восстановить; например, какие-то атрибуты появлялись в спецификациях после постобработок, которые никто уже не мог объяснить. Пример тем и показателен: зрелые процессы и хороший стек сами по себе не гарантируют, что логика решений переживёт уход команды.
А то, чего вы не находите в статье — как стандартизировать процессы, как строить интеграцию, какими инструментами, — это методика внедрения. В статью про то, кто должен владеть инженерной памятью, она не помещается по жанру, потому её там и нет
В вашем примере, по сути, две разные беды, и обе по теме статьи.
Первая — подмена дефайн перед компиляцией и костыли без пояснений: почему сделали именно так, уже не видно. Это ровно про потерю логики решения.
Вторая — умершая среда: исходники есть, но собрать их уже не на чем. На первый взгляд это выглядит как возражение: какой смысл хранить файлы, если среда всё равно устареет? Но для меня это скорее аргумент в пользу инженерной памяти.
Файлы могут лежать на сервере десятилетиями сами по себе. Среда так не живёт: её нужно сопровождать, переносить на новые инструменты, фиксировать библиотеки, параметры сборки и критичные настройки. Судя по описанию, никто вовремя не пересадил код и окружение в живую среду — поэтому вместо сопровождения началась археология, которая иногда обходится дороже, чем разработка заново.
В статье я как раз об этом пишу: инженерная память — это не папка на сервере, а живой контур с владельцем, который ведёт и данные, и среду через смену инструментов и команд. Спасибо за пример — считайте, что дописали к статье ещё один кейс.
Всё, что вы описываете — задание ГИПа, разрешение, доступ к новой ревизии на основании ранее выпущенной — начинает работать после того, как документация выпущена и утверждена, а участок модели заблокирован. Этот порядок я не трогаю, он нужен. Но статья про другой отрезок — до первого утверждённого выпуска. Проектировщик ведёт модель в своём рабочем контуре — задания, статусы, проверки там есть, но для Разрешения в классическом смысле ещё нет выпущенной ревизии, к которой его можно привязать. А главные решения принимаются именно здесь: чем наполняются данные, как увязываются атрибуты и связи, почему модель дошла до выпуска именно такой. И оговорюсь про термины: речь у нас о промышленных капитальных объектах — заводах, установках. Грубо говоря, рабочий контур там — программы, в которых создаётся модель, плюс СОД, а выпуск и согласования — в документообороте. И какой инструмент ни возьми, версии отвечают на вопрос "что было", а не "почему так сделали".
Так что говорим мы про разные отрезки жизни проекта: вы — про то, что после утверждённого выпуска, я — про то, что до него. Оба отрезка нужно держать под контролем, просто инструменты у них разные.
Вот теперь мы добрались до сути расхождения, и это хорошо.
С регистрацией изменений по 21.101 никто не спорит — механизм рабочий, и там, где он честно ведётся, история выпущенной документации прослеживается. Но весь этот аппарат включается, когда изменение уже дошло до бумаги: поправили чертёж, переписали абзац в пояснительной записке, передвинули позицию на схеме — и всё это оформили. Статья же про то, что происходит раньше, до всякой регистрации: сегодня первоисточник — информационная модель, и чертёж, и схема, и записка выпускаются из неё как производные. И вопрос не в том, как зарегистрировать изменение листа, а в том, под чьим контролем сами данные модели — атрибуты, связи, версии — и откуда они вообще берутся. По сути, регистрация работает уже со следствием. Статья — про причину.
Так что ГОСТ мы с вами читаем одинаково, расходимся только в том, к какому слою его прикладывать. Спасибо за обстоятельный разбор
Спасибо, что прочитали так внимательно. Колючесть — это нормально, предметный спор полезнее вежливых кивков.
Про стандарты спорить не буду, потому что не с чем: ГОСТы, ISO 19650 и 15926, TQ/TD — это то, чем мы работаем каждый день, никакого открытия тут нет. Статья про другой слой: не чем заменить стандарты, а куда девается понимание, почему сделано именно так, когда проект сдан, команда разошлась, а объект ещё живёт. Грубо говоря, ПДД у всех одни, а ездят все по-разному — и разбираться приходится именно с ездой.
Про масштаб потерь по отрасли во многом соглашусь, но это тема для отдельного большого текста, а не для ветки комментариев. Ещё раз спасибо за время.
Подрядчик делает работу. Заказчик должен уметь её принять — это разные вещи. Если внутри нет людей, способных прочитать документацию и понять, что именно передано, заказчик не контролирует проект, а просто доверяет на слово. Если этого внутреннего контура нет, получается обратная история: заказчик платит не только за работу, но и незаметно покупает зависимость. Завтра захочет сменить подрядчика — а не сможет, потому что никто, кроме той команды, не понимает, как всё устроено.
(del)