На практическом мини-курсе для руководителей ИТ-проектов участники проверили сценарий подготовки паспорта проекта с помощью нейросетей. Они использовали DeepSeek и GigaChat для генерации документов, а Perplexity — как инструмент поиска и проверки информации. Разбор процесса показал: ИИ способен за несколько минут подготовить аккуратный черновик, но скорость создает ложное ощущение готовности. Модель может придумать убедительную проблему, добавить неподтвержденные выгоды или потерять важное ограничение.
Паспорт проекта — это документ, фиксирующий исходные договоренности, на основании которых руководитель управляет проектом. В нем должны быть определены проблема и актуальность, цель и ожидаемый результат, содержание и границы работ, сроки и этапы, бюджет и ресурсы, заказчик, спонсор, команда, критерии успеха, ограничения, допущения и риски. Особое внимание уделяется тройному ограничению: содержанию, срокам и бюджету. Если требования расширяются, а срок и бюджет остаются прежними, изменение нужно зафиксировать и повторно согласовать, иначе документ перестает отражать реальное состояние проекта.
Рабочая схема состоит из семи шагов. Первый — определить структуру документа: руководитель решает, какие разделы обязательны именно для его проекта. Запрос «составь паспорт проекта» слишком общий: модель сама выберет структуру и может пропустить важные элементы. ИИ хорошо заполняет заданный каркас, но не должен определять управленческий стандарт вместо человека.
Перед работой с нейросетью нужно определить структуру документа, иначе модель сама выберет каркас и может упустить важные разделы.
Второй шаг — собрать и обезличить исходные данные. В контекст включаются цель, ожидаемый результат, сроки, бюджет, роли участников, известные ограничения и требования. Чем меньше фактов получает модель, тем больше пробелов она заполняет правдоподобными догадками. При работе с публичными сервисами имена сотрудников заменяются ролями: «аналитик», «архитектор», «разработчик», «руководитель проекта». Нельзя загружать персональные данные, договоры, коммерческие предложения, исходный код и другие конфиденциальные материалы без согласования с ИБ и юристами. Если данные невозможно безопасно обезличить, задачу следует выполнять в локально развернутой модели внутри корпоративного контура.
Третий шаг — передать модели роль, факты и формат результата. Рабочий запрос состоит из трех частей: роль модели, исходные данные и ожидаемая структура документа. Например: «Выступи как руководитель ИТ-проектов. Подготовь черновик паспорта проекта [название]. Цель: [цель]. Сроки: [дата или период]. Бюджет: [сумма]. Заинтересованные стороны: [роли]. Команда: [роли]. Отрази проблему, цель, задачи, границы проекта, участников, сроки, итоговый продукт, критерии успеха, ограничения, допущения и риски. Не добавляй факты, которых нет во входных данных. Неясные места вынеси в отдельный список вопросов». Фраза о роли сама по себе не делает запрос качественным — основной результат дают конкретные вводные, заданные разделы и прямой запрет на домысливание.
Четвертый шаг — сначала найти пробелы. Если исходных данных мало, не стоит сразу заказывать готовый документ. Полезнее попросить модель выступить в роли рецензента: «Изучи описание проекта и перечисли вопросы, на которые нужно ответить перед подготовкой паспорта. Не придумывай недостающую информацию. Отдельно проверь цель, сроки, бюджет, критерии успеха, ограничения и допущения». После этого руководитель собирает недостающие сведения у заказчика, команды или спонсора. Это не лишняя работа: лучше обнаружить неопределенность до старта, чем спорить о ней в середине проекта. При этом модель не гарантирует полноту проверки: если руководитель сам не знает, что должно быть в паспорте, он может не заметить пропущенный раздел.
Пятый шаг — сравнить ответы нескольких моделей. Одинаковый запрос можно отправить в две нейросети. Сравнивать лучше не документы целиком, а отдельные элементы: насколько точно сформулирована цель, подтверждается ли описание проблемы, понятны ли критерии успеха, не потерялись ли ограничения и допущения, какие формулировки опираются на исходные данные. Заранее назначать «лучшую» модель бессмысленно: качество зависит от конкретной задачи и контекста. Практический подход — взять сильные части разных вариантов и собрать единый черновик.
Шестой шаг — проверить каждое утверждение. На практических заданиях одна модель добавила неподтвержденные выгоды, другая — проблему, которой не было во вводных. Обе версии выглядели профессионально и логично. Поэтому каждый раздел нужно сверить с первичными источниками: согласованы ли цель и критерии успеха, подтверждены ли проблема и ожидаемые выгоды, не появились ли новые даты, суммы и показатели, сохранены ли ограничения, не выдано ли предположение за факт.
Седьмой шаг — собрать итоговый документ. ИИ снимает проблему пустого листа, помогает структурировать сведения и находить слабые места. Управленческие решения и ответственность за них остаются у руководителя проекта. Схема универсальна и не привязана к конкретному сервису: подойдет и для DeepSeek, и для GigaChat, и для других нейросетей.
