Статья по мотивам ролика Игоря Рогачёва на канале "СтроИИка Рогачёва". Предлагаю пошуметь...
В конце прошлого года была принята «Дорожная карта поэтапного перехода в строительстве на российское программное обеспечение для информационного моделирования объектов». Об этом и снят ролик, об этом и мне захотелось написать обзорную статью.
📎 Вот ссылка на YouTube
🎞 Дорога в никуда. Переход на отечественные САПР в строительстве. (https://youtu.be/1kX8P6Ig-b0?si=0-tfXJERo9HRemMe)
📎 аудиоверсия приложена здесь же (https://t.me/IIstroika/9)
📎 краткий пересказ от ИИ для тех, кому лень слушать развернутый комментарий (https://t.me/IIstroika/10)
Лебедь, рак да щука
Вначале, посмотрев ролик, я относительно спокойно отнеслась. Ну, ещё одно постановление сверху, ещё один запрет. Ну ютубом-то до сих пользуемся и ничего, быть может, и остальное скорее всего будет формальностью? Может не стоит так раздувать?
Но тут мне попадается новость про семир от Мосстройинформа под названием "Применение IFC на этапе АГР". Ну в целом, не новость, давно уже ходит такой слушок. А потом вникаю в детали презентации и количество вопросов улетает в космос:
чертежи в формате BCF, плагины на Revit и Archicad, почти готовый ПЗУ на этапе АГР....
В контексте ролика меня уже триггернуло от упоминания зарубежного софта ("Revit и Archicad"). А что касается отечественного? На презентация я не присутствовала, но из слайдов есть четкое понимание, что под наш софт решения нет.
И что получается. Одни собираются навязать работу исключительно в отечественном ПО, а другие - навязать BIM, настоящий, жесткий, и в тоже время как будто методологически невозможный при работе в отечественном софте.
Быть может, я не разобралась и рублю с плеча, но если вы были на встрече или в курсе повестки АГР, готова услышать доводы, что эти требования реализуемы при работе в любом софте, я лишь порадуюсь и выдохну.
Стоит раздувать, поднимать вопросы и искать пути решения вместе. Вот кстати вчера вышло видео-обращение к неравнодушным. Лайк, репост:
Интересно, чем закончится.
Так что же не так в этой дорожной карте?
Деконструкция «Дорожной карты»
Ключевым элементом стратегии этой ДК выступает пункт №9, предполагающий введение ответственности за использование нелицензионного ПО даже при отсутствии заявления от правообладателя. Это превращает Минстрой и профильные ведомства в органы контроля, чья цель — не развитие продукта, а принудительная ликвидация «пиратства». В такой системе отчетности реальные проблемы проектировщиков игнорируются ради достижения KPI по «проценту импортозамещения».
И в целом понятно, почему именно сейчас, но в глубине души этот вопрос не даёт покоя, ведь попытка форсировать переход через штрафы и проверки ведет к деградации проектных институтов. Проектировщики, чья маржинальность и так находится на пределе, не готовы к такому переходу за своё счёт.
Поэтому для малого и среднего бизнеса административное давление становится экзистенциальной угрозой. Если покупка отечественного ПО воспринимается как «налог на лояльность», а не как инвестиция в производительность, доверие между инженером и государством будет окончательно разрушено.
А что поможет реализовать эту дорожную карту?
Jobs To Be Done (JTBD)
Продуктовая стратегия разработки продукта
В контексте обсуждения перехода на отечественные САПР, концепция JTBD (мне, как продакт-менеджеру, конечно же резануло слух) упоминается автором как фундаментальный принцип, который должен лежать в основе разработки программного обеспечения, но который сейчас игнорируется в пользу административного давления.
Работа, которая должна быть выполнена. Если просто объяснять методологию, то продукт будет удовлетворять пользователей, если его "работа"/"job" из статуса "надо сделать"/"to do" перейдет в "выполнено"/"done". Переводя на нашу ситуацию:
• Решение «боли» проектировщика: многие отечественные продукты страдают от того, что они не решают конкретные задачи («работу») инженера и не облегчают его «боль». Согласно логике JTBD, проектировщик «нанимает» программу для выполнения определенной работы; если программа с ней не справляется, он будет искать любые способы (включая использование западного ПО), чтобы закрыть эту потребность.
• Мотивация вместо принуждения: если ПО действительно решает задачи проектировщика (выполняет его «jobs»), его будут покупать добровольно, даже за собственные средства. Текущая же «дорожная карта» перехода на отечественный софт опирается на «кнут» — штрафы и проверки, а не на создание продукта, который инженеры захотят «нанять» сами.
Радует, что такие продукты уже есть на нашем рынке
Проектировщик покупает не «российский аналог Revit», а возможность выпустить чертеж или модель быстрее и с меньшим количеством ошибок. Отечественное ПО должно закрывать «боли» проектировщика без использования «костылей».
• Критерий эффективности софта: Проблема перехода заключается в том, что у продвинутых пользователей есть сложнейший набор функционала в западном ПО, к которому они привыкли. Отечественные решения часто не обладают таким набором инструментов, из-за чего «работа» (job) не может быть выполнена также эффективно.
• Предложение автора видео по развитию: государство должно оценивать эффективность разработчиков САПР не по формальным признакам, а по тому, насколько их продукт закрывает реальные потребности пользователей. Он предлагает создать портал, где проектировщики могли бы сами формулировать задачи (те самые Jobs to be Done), которые разработчики должны реализовать, чтобы получить господдержку.
Таким образом, JTBD здесь — это альтернатива бюрократическому подходу. Вместо того чтобы заставлять инженеров переходить на российское ПО силой, нужно сделать так, чтобы это ПО лучше конкурентов выполняло их повседневные рабочие задачи. Нельзя возразить!
Сравнительный анализ: Продукт vs Решение
Ниже представлено сопоставление текущего административного подхода и стратегии, ориентированной на пользователя.
Переход к JTBD изменит саму логику формирования государственных реестров. Они должны стать не перечнем доступных лицензий, а навигатором эффективности, где софт оценивается по способности решать прикладные
инженерные кейсы.
Теория ясна, но а как это реализовать на практике?
Механизм прямой связи: Проектировщик — Разработчик
Существующий разрыв между кодом и чертежом обусловлен закрытостью институтов управления. Рабочие группы при Минстрое — это «замкнутый круг» из чиновников, представителей вендоров и ИТ-департаментов Москвы (ДИТ, Мосстройинформ). В этой цепочке отсутствует ключевое звено — «чистый» проектировщик-практик.
«Госуслуги для САПР» и системы управления идеями
Необходимо создание единой платформы (аналог Idea Management Systems), где проектировщики смогут открыто предлагать функции, а сообщество — голосовать за них. Опыт западных бенчмарков (например, порталы идей Autodesk) показывает, что это кратчайший путь к созданию востребованного продукта.
Рейтинговая система и условия господдержки
Объем государственных субсидий для вендоров должен быть напрямую привязан к их рейтингу удовлетворенности на портале. Если разработчик игнорирует запросы сообщества по исправлению системных ошибок, его право на преференции и включение в стратегические программы должно быть аннулировано. Это заставит вендоров конкурировать за пользователя, а не за близость к бюджетному распределению.
Это исключит ситуацию, когда «стратегические решения разработчиков не совпадают с ожиданиями рынка». Пользователь из объекта регулирования превращается в активного заказчика инноваций.
Согласны, звучит здраво и логично. Но а если ближе к делу: раз, два, три - с чего начать, как именно помочь проектировщикам?
Устранение разрыва между нормами и функционалом ПО
Сегодня существует критический разрыв между требованиями государства (ГИС ОГД, классификаторы КСИ) и возможностями САПР. Проектировщики вынуждены вручную вводить данные в XML-схемы Главгосэкспертизы.
Автоматизация нормативного соответствия
Разработчики обязаны интегрировать КСИ и XML-структуры непосредственно в программную среду «из коробки»., если хотят, чтобы эти требования были реализованы. Прохождение экспертизы должно быть не отдельным кругом бюрократического ада, а автоматическим результатом работы в правильно настроенном САПР.
Библиотека государственных референс-моделей
Для снижения порога входа государство должно инициировать создание эталонных проектов (детские сады, школы, мосты(не обделяем и ЛО) в отечественном ПО. Проектировщик должен получать не пустую программу, а базу знаний: «как заармировать балку по СП внутри этого интерфейса». Обучение должно быть встроено в функционал, а не продаваться как отдельная услуга.
Когда программа сама «знает», как соответствовать нормам ГИС ОГД, проектировщик выберет ее добровольно. Это превратит отечественные САПР из обременения в инструмент защиты от ошибок и ускорения экспертизы.
Даже если отечественный продукт будет решать задачи пользователей максимально эффективно, достаточно ли этого, чтобы отказаться от зарубежных практик?
Стратегия «Полезной конкуренции» и технологический тонус
Полная изоляция отечественного рынка — путь к неизбежной стагнации. Без сопоставления с лучшими мировыми образцами UI/UX и расчетных алгоритмов российские продукты перестанут развиваться.
Допустимость «серой зоны» для бенчмаркинга
Необходимо сохранить легальные возможности для анализа западного ПО. Отечественные вендоры должны иметь доступ к передовым технологиям для «подглядывания» лучших практик. Запрет на использование западных инструментов лишает нас ориентиров для развития.
Экспорт как единственный критерий качества
Истинным показателем успеха технологического суверенитета является конкурентоспособность продукта на внешних рынках (БРИКС и др.). Если российский САПР невозможно продать за пределами страны без административного давления, значит, он нежизнеспособен в долгосрочной перспективе.
Сохранение «полезной технологической конкуренции» обеспечит жизнеспособность российской инженерной школы. Только рыночная эволюция, подкрепленная грамотной господдержкой, позволит создать продукты, которые инженеры захотят покупать добровольно.
Резюме и призыв к действию
Для спасения процесса цифровизации строительной отрасли необходимо немедленно пересмотреть государственную политику в следующих направлениях:
- Исключить презумпцию виновности инженера: Отказаться от приоритета карательных мер (пункт №9 дорожной карты) в пользу стимулирования эффективности.
- Демократизировать управление: Включить практикующих проектировщиков в экспертные советы Минстроя, потеснив лобби вендоров.
- Синхронизировать данные: Обеспечить бесшовную интеграцию XML-схем и КСИ в программную среду САПР.
- Внедрить портал народных идей: Сделать объем госсубсидий зависимым от реального рейтинга удовлетворенности пользователей.
- Ориентироваться на экспорт: Считать технологическое превосходство на мировом уровне важной целью, а не «затыкание дыр» внутри страны.
Приоритет нужд инженера и маржинальность проектного процесса должны стоять выше бюрократической отчетности. Государство должно создавать условия для рождения продукта, который проектировщик наймет сам, а не под угрозами. Только так мы получим живую, развивающуюся отрасль, а не 98% красивой отчетности на фоне технологической деградации.