Проектная документация редко становится предметом гордости команды. Обычно это сотни артефактов, разрозненные системы, ручная синхронизация и ощущение, что половина работы уходит не на разработку, а на обслуживание процесса. Мы попробовали изменить эту логику: не отказаться от привычных инструментов, а собрать вокруг них единый контур проектирования. Рассказываем, что из этого получилось.
Привет, Хабр! Мы — Анастасия Назарец, Артем Вожаков и Антон Филин из отраслевого центра компетенций IBS в машиностроении. В этой статье расскажем, почему решили сделать собственную систему проектирования прикладных решений при живой «1С:СППР» и как новая комплексная система реализации проектов улучшила не только нашу жизнь, но и жизнь заказчиков.
С чего все началось
На проектах комплексной автоматизации с бюджетом свыше 30 миллионов рублей мы традиционно ведем структурированную информацию в связке Confluence+Jira. Пока работа идет внутри команды, такой подход удобен. Но сложности начинаются ближе к завершению проекта, когда нужно передать заказчику накопленную базу знаний и проектную документацию. Проблемы возникают, даже если заказчик сам использует Confluence, чего уж говорить про компании с альтернативными системами. Перенос информации быстро превращается в отдельный проект.
В определенный момент мы добавили в этот контур российскую систему проектирования прикладных решений «1С:СППР». Но и этого оказалось недостаточно. В типовых конфигурациях 1С нет стандартизированного механизма проектирования объектов метаданных. Из-за этого проектные решения в Confluence существуют отдельно от реальной структуры метаданных. Хотя СППР содержит инструменты для работы со структурой объектов и сравнения изменений, сценария полноценной совместной работы Confluence и СППР на практике мы тогда не нашли.
В результате из проекта в проект повторялась одна и та же история: мы вручную заполняли таблицы описания изменений конфигурации, собирали документы, а после завершения проекта все это фактически отправлялось на полку без повторного использования на других проектах.
Стало понятно, что нужен другой подход. Нам было необходимо:
снизить трудоемкость проектирования и разработки в комплексных проектах 1С;
создать системное решение для совместной с заказчиком работы по проектированию и разработке решения;
обеспечить передачу структурированных данных проекта по результату его выполнения;
стандартизировать проектирование объектов метаданных.
Перед командой поставили конкретные задачи:
доработать СППР под новые объекты проектирования: функциональные области, бизнес-процессы, объекты данных, связи между ними;
реализовать полноценную интеграцию СППР и Confluence в отношении ключевых объектов проектирования;
подготовить целевую конфигурацию системы, включающую наиболее подходящие расширения для СППР, с учетом методологии IBS;
разработать обучающий курс и комплект документации.
Проектом занималась команда из пяти человек: директор проекта, три архитектора и разработчик.
Ключевые особенности разработанного решения
логика группировки объектов соответствует методологии IBS: Confluence+Jira+СППР;
универсальный механизм статусов — аналог Handy Status для проектных сущностей в Confluence;
версионирование объектов на базе механизма 1С «История данных» и отчеты по сравнению версий;
механизм быстрого создания связей и трассировки объектов по аналогии с Jira/Confluence;
интеграция с Confluence: генерация XML для спецификации на разработку и проектных решений по корпоративному шаблону нажатием одной кнопки, загрузка данных и связей Requirement Yogi;
интеграция с Jira в части загрузки задач разработки по эпикам;
механизм проектирования профилей доступа;
визуальное проектирование интеграций: мэппинг атрибутов объектов метаданных, произвольные сообщения в форматах XML/JSON;
механизм проектирования изменений объектов метаданных и интеграционных потоков через запросы на изменения (request for change, RFC);
поддержка расширений в части проектирования и работы с метаданными;
контроль жизненного цикла изменений от требований заказчика до исправлений в конфигурации;
интеграция с «1С:Документооборот»: хранение и согласование проектных документов, согласование техпроектов;
универсальный обмен данных через Excel при помощи модуля миграции.
Как все устроено
Логическая модель данных (схема связей артефактов проекта)
Отказываться от Jira и Confluence мы не собирались. Нужно было придумать, как разумно использовать три системы сразу, не дублировать работу и не сойти с ума.
Получилась следующая функциональная архитектура:
По наполненности и возможностям анализа СППР в итоге приблизилась к Confluence. Исключение осталось одно — полноценная работа с Word-документами.
С помощью механизма обратной интеграции XML-код можно сгенерировать в СППР и одним действием перенести в Confluence.
Архитектура интеграций
На современных проектах ограничения по информационной безопасности становятся все жестче. Возможность работать с заказчиком в общем контуре есть далеко не всегда.
Поэтому базовый сценарий выглядит так: СППР разворачивается на нашей стороне и подключается к Jira и Confluence. Для передачи изменений используется регулярная выгрузка данных в шаблон миграции и последующая загрузка в СППР заказчика.
Основные объекты системы
Объект | Описание |
Функциональные области | Используется для деления объектов, документов и прочего по функциональным областям, для которых назначаются отдельные руководители рабочих групп. |
Этапы проектов | Устанавливаются этапы проекта в соответствии с условиями договора. Дополнительные соглашения, расширяющие объем работ по договору, могут вводиться позже, как дополнительные этапы договора. |
Типы проектных документов | Вводятся типы отчетных и внутренних документов, разработка которых предусмотрена в рамках проекта. |
Требования (идеи) | Любые виды требований в рамках выполнения проекта вводятся в справочник, предусмотрена возможность классифицировать требования по источнику возникновения, обеспечивать связи между элементами. |
Проектный документ | Предназначен для хранения, согласования и анализа связей проектной документации. |
Процессы | Предназначен для хранения древовидной структуры бизнес-процессов заказчика, на нижнем уровне находятся процессы, для которых будут разрабатываться схемы процессов (BPMN, EPC и т. п.). |
Шаги процесса | Действия и функции, которые отражаются на схемах процессов, всегда подчинены процессу. |
Профили пользователей | Содержит список бизнес-ролей, участвующих в выполнении бизнес-процессов. |
Объекты данных | Содержит список объектов логической структуры, указываемых во входах и выходах процессов, шагов процессов. |
Интеграции | Содержит список интеграционных потоков с внешними и внутренними по отношению к проекту системами. |
Функции | Содержит список автоматизированных функций, использующихся пользователями при выполнении процессов. |
Технический проект | Содержит список разработок, предусмотренных в рамках проекта. |
Объекты метаданных | Содержит текущую структуру метаданных, загруженных из конфигурации. |
Конфигурации | Вспомогательный справочник системы, содержащий список всех конфигураций 1С и прочих внешних и внутренних систем, участвующих в интеграционных потоках, реализуемых в рамках проекта. |
Конфигурации проекта | Содержит список конфигураций 1С и расширений 1С. |
Запросы на изменения | Специализированный объект, использующийся для проектирования доработок конфигураций 1С, написания проектных решений и проектирования интеграций. |
Задачи разработки | Содержит список задач разработки, в рамках которых дорабатываются конфигурации контура проекта. |
Как это выглядит на практике
Интерфейс СППР — подсистема «Проектирование» под методологию IBS
Важно уточнить, что мы используем СППР не совсем по ее прямому назначению. 1С создавали этот программный продукт для проектирования конфигураций. Мы же реализуем в ней коммерческие проекты, где конфигураций может быть много, а процессы могут перетекать из одной конфигурации в другую. Логику работы системы пришлось адаптировать.
Работа с объектами
На примере одного из требований:
Требования можно классифицировать по тематике, источникам и важности. Мы также добавили поля для детального описания требования, фиксации разрывов и способа реализации.
Два механизма оказались особенно полезными:
— «Связи» — универсальный механизм связывания объектов, который можно настроить под себя.
— «Статус» — гибкая модель контроля состояния, которая позволяет отслеживать десятки параллельных процессов согласования и реализации.
Концептуальная схема связей и статусов:
Для интеграции с Confluence дополнительно появился реквизит «Код миграции», чтобы больше не заниматься ручным сопоставлением объектов.
Описание объектов метаданных
Загрузка описания метаданных осуществляется через типовую обработку «Загрузка метаданных». Основной справочник — «Объекты метаданных», а также подчиненные ему «Реквизиты, формы, команды».
Проектирование изменений
Когда появляется понимание целевых доработок, начинается детальная проработка изменений. Процесс выглядит так:
Создаем технический проект — агрегирующую сущность для бизнес-задачи. По сути, аналог эпика в Jira.
Формируем запросы на изменения в разрезе объектов метаданных и интеграционных потоков.
Связываем их с требованиями, объектами данных и другими аналитиками.
Проводим согласование и включаем запросы на изменения в технический проект.
Концептуальная схема изменения метаданных:
Документ «Запросы на изменения» можно создать в системе с нуля, быстро заполнить с помощью редактора метаданных и автоматически сгенерировать на его основе текст спецификации на разработку по нашему внутреннему стандарту.
Раньше каждый объект метаданных означал ручное заполнение таблиц, проверку данных, создание задачи в Jira и подготовку текста СНР. Теперь система сама генерирует XML для вставки в Confluence, проверяет стандарты наименования объектов и реквизитов и автоматически формирует структуру документов. По сути, мы убрали значительную часть механической работы.
Миграция данных и массовые корректировки
Загрузка данных из Confluence и Jira
Согласование в «1С:Документооборот»
Отчеты и трассировки
Мы подготовили набор универсальных и преднастроенных отчетов. Вот пример отчета с анализом функционально-технических требований:
Там, где раньше загрузка проектной базы на тысячи документов в Confluence занимала минуты или часы, теперь результаты отображаются практически мгновенно.
А где же ИИ?
Прямой интеграции СППР с GPT-моделями пока нет. Но ИИ уже можно использовать как вспомогательный инструмент.
Например, на одном из проектов нужно было спроектировать интеграцию 1С и SAP. Мы сформировали описание интеграционного потока в DeepSeek, загрузили результат в СППР и получили готовый каркас схемы, который осталось только уточнить и согласовать.
После этого одним действием перенесли данные в Confluence:
Так в несколько кликов мы получили результат примерно двух месяцев работы технического писателя — от генерации схемы сообщения до конечной документации пользователя.
Эффекты от использования
активное вовлечение заказчика в процессы проектирования за счет создания аналитических инструментов проектирования в его среде и, как следствие, значительное увеличение скорости приемки отчетных документов проекта;
сокращение трудозатрат на написание проектных решений до 40%;
сокращение трудозатрат на написание спецификаций на разработку до 25%;
исключение человеческого фактора и ошибок в документации при написании проектных документов, содержащих описание метаданных;
автоматический контроль соответствия проектной и фактической структуры метаданных.
Чтобы достичь этих эффектов, важно заранее проговорить с заказчиком ряд условий:
Формирование команды проекта на стороне заказчика с выделением архитектора системы, владельцев и кураторов процессов со стороны ИТ по каждой функциональной области.
Обучение команды заказчика типовым решениям 1С до начала реализации проекта.
Обучение команды заказчика работе в СППР IBS.
Организация на стороне заказчика базы «1С:Документооборот 3.0» для согласования проектной документации, бесшовно интегрированной с СППР.
Подготовка заказчиком изолированной инфраструктуры среды моделирования до начала реализации проекта с обеспечением возможности передачи и получения данных из внешних систем в ресурсы среды моделирования.
Подготовка, согласование и выполнение заказчиком строгого регламента согласования проектной документации, определяющего длительность и состав этапов согласования.
Вовлечение команды заказчика в процессы согласования проектной документации по мере готовности отдельных блоков.
Что дальше
В бэклоге уже лежат:
поддержка BPMN;
развитие механизма запросов на изменения;
средства визуализации;
развитие инструментов управления разработкой.
Если интересно посмотреть отдельные механизмы подробнее, задавайте вопросы в комментариях или пишите сразу в телеграм Артему или Анастасии.
