До недавнего времени я, как и многие, относился к искусственному интеллекту с определённым недоверием. Казалось, что это модная идея (или даже «игрушка»), а не рабочий инструмент. Но когда чётко обозначился тренд на внедрение ИИ в бизнес‑процессы, я тоже решил попробовать. В итоге я не только изменил своё мнение, но и создал ассистента, который помог освободить до 40% рабочего времени.
Три проекта, три судьбы документации
С 2024 года я работаю архитектором решений в НЛМК. За это время довелось поучаствовать в трёх проектах. В каждом из них у меня сложилась совершенно разная ситуация — как по этапу жизненного цикла, так и по состоянию проектной документации.
Первый проект я застал уже на этапе перехода в опытно‑промышленную эксплуатацию. К этому моменту проект прошёл через несколько волн изменений команды, архитекторов и аналитиков. В итоге накопилось множество статей, разрозненных файлов и комментариев в Confluence: разные форматы, стили изложения, противоречивые сведения и отсутствие единой структуры. Чтобы разобраться в этом «легаси», уходили часы.
На втором проекте мы начинали с нуля. Я попал на активную фазу внедрения и смог сразу влиять на структуру документации, её полноту, а также стилистическое и методологическое единство. Всё шло по шаблонам, а изменения, обсуждения и ключевые архитектурные решения фиксировались сразу.
Третий проект оказался на той же технологической базе, что и первый. Меня попросили провести аудит архитектуры перед вводом в промышленную эксплуатацию. И тут опыт, полученный на первых двух проектах — разбор хаоса больших исторических архивов и построение порядка в виде методично структурированной документации с нуля — пригодился как никогда.
Сравнив эти три ситуации, я на практике убедился: единый подход к документации решает очень многое. Чем раньше удаётся внедрить стандартизированную структуру документации и подходы к её обновлению, тем легче поддерживать качество, скорость и управляемость развития ИТ‑решения, а затем масштабировать систему и передавать её другим командам. Именно эта мысль и подтолкнула меня к поиску инструмента, который поможет справляться с этим быстрее.
Дальше я расскажу, как проходил процесс адаптации и внедрения ИИ‑инструментов в моей работе — на примере реальных задач: с какими сложностями столкнулся, каких результатов удалось добиться и какие новые возможности это открыло.
Первый опыт: от рутинных задач — к ускорению работы
На первом этапе я тестировал ИИ на простых задачах: создании небольших фрагментов кода, поиске информации по технологиям, анализе работы библиотек и компонентов. Результаты оказались более чем удовлетворительными — качество и скорость приятно удивили.
Постепенно я стал ожидать от ИИ большего. Анализируя свои ежедневные задачи как архитектора, я увидел, что значительная их часть требует существенных временных и интеллектуальных затрат. В первую очередь это касается выверки технических заданий (ТЗ) на соответствие функциональным требованиям, поиска и устранения противоречий, а также проверки логики построения и полноты документации.
Особенно трудоёмким этот процесс становится для объёмных документов: на их анализ вручную уходит много времени и требуется высокая концентрация. Раньше на проверку одного такого ТЗ объёмом 40–60 страниц я затрачивал 8–10 часов напряжённой работы, разбивая задачу на несколько подходов или дней. Это замедляло общий темп работы по проекту и увеличивало риски человеческих ошибок из‑за усталости или банального «замыливания взгляда».
С появлением ИИ ситуация кардинально изменилась. Теперь значительную часть рутинного сопоставления, поиска несоответствий, повторов, логических провисаний и пробелов я поручаю ассистенту. Он за несколько минут проводит первичный анализ, выделяет потенциально проблемные места и формулирует рекомендации. Мне остаётся сфокусироваться на действительно сложных экспертных вопросах.
В результате время на анализ и доработку одного ТЗ сократилось минимум на 40%. Если раньше полный цикл верификации и вычитки занимал до 10 часов, то с использованием ИИ я укладываюсь в 3–4 часа, включая финальную корректировку и ответы на дополнительные вопросы коллег.
Конкретный сценарий работы выглядит так:
Экспортирую нужный документ из Confluence и удаляю из него все конфиденциальные данные.
Загружаю подготовленный текст в запрос (промпт) и формулирую конкретное задание, например: «Ты архитектор, проанализируй документ на предмет неточностей и согласованности…».
В ответ получаю развёрнутый список замечаний: от повторяющихся фрагментов и незаполненных полей до несовпадений между ролями и функциями, а также выявленных терминологических неточностей.
Дальше работаю с ассистентом в интерактивном режиме: дополняю и уточняю запросы, пошагово вношу необходимые корректировки.
От простого диалога — к созданию ассистента для архитекторов
Однако стало понятно: «ручной» диалог с ИИ, несмотря на пользу, не решает всех задач. С развитием проектов требовались автоматизация под корпоративные стандарты, интеграция шаблонов и работа в общем проектном контексте.
В нашей компании есть Гильдия архитекторов — сообщество, которое собирает и поддерживает единые стандарты проектирования, шаблоны документации, подходы и лучшие практики. По сути, это коллективный разум всех архитекторов, упакованный в понятные правила. За годы работы гильдия накопила огромный опыт: требования к оформлению, контрольные перечни, типовые ошибки и примеры.
Я подумал: а что, если «скормить» этот опыт ИИ? Тогда появилась идея создать ассистента, который не просто проверяет документы, а делает это ровно так, как принято у нас в компании: знает шаблоны, помнит типичные «грабли» и даже помогает собирать исходные данные с помощью опросников.
Так родился ДокАрхитектор — ИИ‑ассистент для обеспечения качества, целостности и корпоративного стиля проектной документации. Системный подход к работе с ним позволяет существенно экономить время и минимизировать случайные ошибки на всех этапах подготовки документов.
При создании ассистента одним из ключевых этапов стала разработка и интеграция обширной базы знаний, включающей актуальные корпоративные стандарты и шаблоны, накопленные гильдией архитекторов. Для этого были собраны и структурированы требования к оформлению, наполнению и согласованию документации для каждого раздела архитектурных и проектных документов. В систему были загружены не только примеры и стандартизированные шаблоны, но и сопутствующие контрольные перечни, а также рекомендации по заполнению сложных или неоднозначных разделов.
Особое внимание уделялось детализации формулировок требований, типовым ошибкам, которые встречались на практике, и описаниям лучших практик из корпоративного опыта. Благодаря такой глубокой проработке ассистент способен не только сверять документ с утверждёнными шаблонами, но и гибко реагировать на запросы пользователя: подсказывать структуру нового раздела, формировать контекстные опросники для сбора информации и предлагать варианты доработок.
Полевые испытания ассистента ДокАрхитектор
В одном из новых проектов, на который меня подключили, ДокАрхитектор проявил себя с лучшей стороны. Мне нужно было провести ревизию архитектурных документов: проверка полноты артефактов и согласованности с корпоративными требованиями стала занимать гораздо меньше времени. Теперь вместо изучения десятков страниц мне требуется лишь пройтись по 10–15 отметкам, выделенным ИИ.
Запрос
Проанализируй полноту раздела 3.1.4 Ролевая модель системы. Сформируй список неточностей, неполноты документа.
Ответ
Проанализировав требования к разделу 3.1.4 Ролевая модель системы, он должен представлять собой матрицу доступа функций на пользовательские роли, причем перечень функций должен соответствовать таблице автоматизируемых функций / пользовательских историй (US) из раздела 3.1.2. Критерии полноты:
В наличии матрица доступа (таблица: роли vs функции/US)
В таблице перечислены все функции/US, которые реализуются системой
Прописаны все пользовательские роли (актуальные для системы)
Ясно, к каким ролям относятся какие права (какие функции/US каждой роли доступны)
Все доступы обоснованы; отсутствуют “пустые” роли или нерассмотренные права
При необходимости — краткое текстовое примечание по особенностям доступа (например: ограничения, специфичные условия)
Проведен анализ
Предварительный перечень возможных неточностей (если базироваться на типичных ошибках и требованиях):
1. Отсутствие матрицы “роли - функции”
В разделе может быть описан текстом, но не быть таблицы для визуального сопоставления, из-за чего затруднена проверка корректности доступа.
2. Неполный список ролей
Пропущены отдельные роли (например, интеграционные, технические, приглашенные пользователи).
3. Неполный список функций / пользовательских историй (US)
В список не включены все функции, реализуемые системой — нет соответствия с 3.1.2.
4. Не все роли имеют явно указанные права
Для некоторых ролей не указано, какими функциями они могут оперировать.
5. Неполные/неоднозначные описания прав
Например, указано "Доступ есть", но не конкретизировано, какие права реализованы.
6. Нет обоснования для зон доступа
Не ясно, почему та или иная роль получает определенный доступ (нет связи с бизнес-процессами/требованиями).
Отсутствие дополнительных примечаний/ограничений
Например, не указано, что определенные роли имеют доступ только в определенном режиме или только к части данных.
Запрос
какие требования к подразделу 3.1.4 Ролевая модель системы
Ответ
Вот стандартные требования к разделу 3.1.4 Ролевая модель системы в архитектурной документации:
3.1.4 Ролевая модель системы
Описание раздела:
В данном разделе должна быть представлена матрица доступа, отражающая права пользователей различных ролей в системе.
Требования к содержанию:
1. Матрица доступа
Оформить в виде таблицы, где:
В строках — перечень функций системы (соответствует функциям из раздела "Таблица автоматизируемых функций / пользовательских историй (US)", т.е. 3.1.2);
В столбцах — пользовательские роли (например: Оператор, Администратор, Руководитель, Пользователь и др.);
На пересечении — отметка (галочка, "Х", "Д", "есть"/"нет" и др.), показывающая наличие или отсутствие права у роли на выполнение функции.
2. Полнота и согласованность
Все функции/Use-case, автоматизируемые системой, должны быть отражены в матрице;
Названия ролей и функций должны быть согласованы с бизнес-заказчиком и другими разделами документа.
3. Расшифровка ролей
Дать краткое текстовое описание каждой роли: какие сотрудники или должностные обязанности подразумевает данная роль.
4. Уровни доступа
При необходимости, дополнительно указывать тип доступа (например: просмотр, редактирование, удаление, утверждение и т.д.) — либо матрица строится для каждого типа доступа, либо в одной матрице разными значками.
5. Взаимосвязь с другими разделами
Убедиться, что роли, отраженные в этой матрице, используются и в других местах документации (например, в сценариях использования, требованиях к безопасности и т.д.).
6. (Опционально) Пример:
Таблица в формате:
Функция | Оператор | Администратор | Руководитель |
Добавить заявку | X | X | |
Просмотр отчётов | X | X | X |
Модерация записей | X | ||
Удаление информации | X | X |
Итого:
Ролевая модель должна однозначно определять, кто и какие действия может выполнять в системе, и быть максимально прозрачной для согласования с заказчиком и при аудите.
Если нужно — могу подготовить шаблон матрицы для вашего случая!
Запрос
сформируй опросник для бизнеса для формирования раздела 3.1.4 Ролевая модель системы
Ответ
Вот подробный опросник для бизнеса для сбора информации по разделу 3.1.4 "Ролевая модель системы".
Ориентирован на структурированное заполнение и согласование с бизнес-заказчиком.
Опросник для раздела 3.1.4 — Ролевая модель системы
1. Список ролей
Перечислите все уникальные пользовательские роли, которые будут работать в системе. (Пример: Оператор, Администратор, Руководитель, Пользователь, Внешний контрагент, ...)
Ответ:
Роль 1:
Роль 2:
Роль 3:
...
2. Описание ролей
Для каждой роли:
Какие сотрудники, должности или подразделения её занимают?
Главные задачи и зона ответственности роли?
Ответ:
Роль 1: описание, какие сотрудники, задачa
Роль 2: ...
...
3. Полный перечень функций/действий
Перечислите все ключевые функции и действия, которые реализует система (или используйте перечень из user stories / автоматизируемых функций в 3.1.2).
(Пример: Создание заявки, Утверждение, Просмотр отчётов, Экспорт данных, Работа со справочниками и т.д.)
Ответ:
Функция 1:
Функция 2:
Функция 3:
...
4. Матрица доступа (кому какие функции нужны)
Для каждого элемента "роль–функция":
Нужно ли этой роли выполнять эту функцию?
Какой уровень доступа (создание, просмотр, редактирование, удаление, утверждение и др.)?
Ответ (таблицей):
Функция | Роль 1 (указать вид доступа) | Роль 2 | Роль 3 | ... |
Функция 1 | ||||
Функция 2 |
5. Есть ли дополнительные ограничения/особенности?
Есть ли особые правила:
Блокировки, квоты, взаимное исключение ролей, временные доступы, двойное согласование и др.?
Ответ:
Описание...
6. Необходимы ли новые роли в будущем?
Требуется ли предусмотреть "гибкие" или резервные роли на перспективу?
Ответ:
Да/Нет. Если да — перечень.
7. Импортируются ли роли из других систем (Active Directory, SAP и др.)?
Есть ли интеграция с существующими каталогами пользователей/ролей?
Как должны автоматически назначаться роли?
Ответ:
Описание...
8. Комментарии или пожелания бизнеса к управлению доступом
Есть ли специфические пожелания к утверждению, выдаче, отзыву, контролю действий по функциям?
Ответ:
Описание...
Если потребуется — могу оформить таблицу для удобного заполнения в Excel/Google Sheets!
Если какие-то вопросы стоит добавить под специфику вашего бизнеса — уточните детали, доработаю опросник.
ИИ не только быстро анализировал структуру документа (например, раздел «Ролевая модель системы»), но и указывал на необходимость обязательных элементов — таких как матрица доступа. Кроме того, ассистент формулировал вопросы для сбора информации у бизнес‑заказчика: готовил опросники для уточнения ролей, функций, уровней доступа, интеграции с другими системами. Также он показывал, как должен выглядеть раздел документации, чтобы он соответствовал корпоративным шаблонам и требованиям гильдии.
Сравнение с ручной работой
Этап | Без ИИ | С ИИ-ассистентом |
Проверка одного ТЗ | 8–16 часов | 2–4 часа |
Итераций согласования | 3–4 | 1–2 |
Типовые ошибки | Практически всегда | Почти нет |
Типовые задачи по проверке полноты документации хорошо автоматизируются, так как ассистент основывается на единых требованиях и шаблонах, учитывая проектный контекст.
Опыт внедрения ДокАрхитектора убедительно показал эффективность подобного инструмента в сфере архитектуры. Однако потенциал ассистента этим не ограничивается: методологии и стандарты, лежащие в его основе, универсальны и применимы для любых профессиональных сообществ компании. Это открывает возможности масштабирования подхода на другие гильдии — от аналитиков и тестировщиков до проектных менеджеров и специалистов по эксплуатации.
Что дальше?
На текущем этапе внедрение ИИ в процессы сопровождается рядом дополнительных действий. Для полноценной работы с ассистентом требуется вручную выгружать документы из корпоративных систем, тщательно очищать их от конфиденциальной или чувствительной информации, а по мере развития проекта — каждый раз загружать обновлённые версии документов для анализа. Такой подход снижает информационные риски, но временами замедляет и усложняет работу.
Вместе с тем развитие ИИ‑инфраструктуры внутри корпоративного контура открывает новые перспективы для автоматизации. Перенос ИИ‑системы на внутренние серверы компании обеспечит надёжное хранение данных и позволит сократить трудозатраты на очистку документов. Интеграция с Confluence и реализация механизма гибкого, постоянно обновляемого контекста по каждому проекту позволят построить более автоматизированную цепочку работы с документацией.
В результате пользователи смогут получать преимущества ИИ‑ассистентов напрямую в привычной рабочей среде, не беспокоясь о безопасности и не тратя время на рутинные операции по обработке данных.
Сейчас ДокАрхитектор — мой постоянный напарник. Проверка ТЗ, которая раньше занимала полдня и выматывала до состояния «замыленного глаза», теперь укладывается в пару часов. И унаследованные проекты с тоннами документации больше не пугают: ассистент быстро находит даже самые спрятанные противоречия, а мне остаётся спокойно навести порядок.
