AI
ИИ в управлении проектами
Обучение ИИ для проектного офиса девелоперской компании строится на реальных задачах: выделить поручения из протокола совещания, составить черновик письма подрядчику, свести статусы в таблицу. Главное в этой учёбе - не скорость результата, а умение заметить ошибку модели до того, как результат уйдёт руководителю.
По данным RICS (Royal Institution of Chartered Surveyors), в первом квартале 2025 года Global Construction Monitor получил более 2200 ответов специалистов, 48% из которых пришли из Великобритании. Раздел 3.4 Artificial Intelligence in Construction Report перечисляет три барьера для внедрения ИИ: нехватку квалифицированных сотрудников назвали 46% опрошенных, трудности с интеграцией ИИ в существующие системы - 37%, проблемы с качеством данных - 30%. Это восприятие участников опроса, не показатели рынка Узбекистана. Практический вывод из данных один: навыки, интеграция систем и качество данных - три разные задачи, которые решаются отдельно. Обучение команды решает навыки, но не заменяет интеграцию систем и не обещает экономию.
Как выделить поручения из протокола совещания
После совещания у сотрудника на руках запись: кто что сказал, где согласовали, где поспорили, кто пообещал, кто не ответил. Из этой записи нужно получить три вещи: список задач с исполнителями и сроками, черновик письма и статус для руководителя.
Сотрудник передаёт текст протокола ИИ вместе с запросом:
«Из протокола совещания [название, дата] выпиши каждое принятое решение. Для каждого укажи: текст решения, явно назначенного исполнителя, срок или "не указан", нерешённые вопросы. Не добавляй решения, которые не были явно утверждены. Сохрани цитату из записи.»
Это шаблон для работы, а не пример готового результата. Сотрудник читает ответ модели как черновик, который нужно сверить с исходным протоколом по каждой строке.
При сверке важно помнить: если в записи человек сказал «посмотрим, возможно, к пятнице» - это не срок. Если исполнитель не назван явно, сотрудник не подставляет имя из контекста. Он помечает строку «исполнитель не указан» и уточняет у руководителя. Если кто-то высказал мнение, но решение не было явно утверждено - это не поручение. Сотрудник сохраняет цитату с указанием места в записи и передаёт руководителю с пометкой «решение не принято».
Модель иногда допускает два типа ошибок. Первый - пропуски: поручение не включено, потому что формулировка в протоколе была неочевидной. Второй - добавленные обязательства: вежливое «буду рад помочь» модель иногда превращает в задачу с исполнителем. Заметив сомнительную строку, сотрудник возвращается к протоколу, перечитывает её и, если неясно, не решает сам - передаёт руководителю.
Учебные задачи намеренно усложняют: до конца дня могут уточнить ещё два вопроса, один пункт переименуют, срок по другому сдвинется. Эти условия выбраны специально, чтобы сотрудник не привыкал к идеальному протоколу.
Цель на этом шаге: сотрудник учится распознавать типичные пропуски и подстановки модели. Это проверяемый навык, который подтверждается на новых задачах с изменёнными условиями.
Как заметить ошибки модели в учебном примере
Рассмотрим, как работает сверка на конкретном протоколе. Три строки учебного материала:
P1: «Координатор подготовит список открытых вопросов; срок не назначен».
P2: «Руководитель поручил отправить подрядчику запрос подтверждения срока после проверки содержания».
P3: «Участник предложил закрыть вопрос, руководитель решение отложил».
К протоколу есть приложение - отдельный раздел с требованиями к переписке. Ниже две учебные редакции.
Редакция 1. Пункт A2: при запросе подтверждения срока по поручению P2 приложить ссылку на исходное письмо.
Редакция 2. Пункт A5: при запросе подтверждения срока по поручению P2 приложить ссылку на исходное письмо и подтверждение согласования от контрагента.
Номера P1, P2, P3 протокола не меняются. Перенумерация внутри приложения - от A2 к A5 - отражает структуру документа, а не приоритет поручения. Условия применения нового требования устанавливает специалист.
Сотрудник передаёт ИИ протокол, обе показанные редакции приложения A2 и A5 с запросом: «Выпиши каждое поручение. Для каждого укажи: текст, исполнителя, срок или "не указан". Отметь нерешённые вопросы отдельно. Не добавляй решения, которые не были явно утверждены. Отдельно выпиши изменения приложения между редакциями.»
Ниже - специально составленный ошибочный ответ для учебного разбора.
«1. Координатор подготовит список открытых вопросов до пятницы. 2. Отправить подрядчику запрос подтверждения срока. 3. Закрыть вопрос по предложению участника. 4. Приложить подтверждение согласования ко всем письмам подрядчику.»
В каждой строке ошибка.
По P1. В протоколе написано «срок не назначен». Модель добавила «до пятницы». Правильный исход: поручение с пометкой «срок не указан». Отсутствие срока не превращается в дедлайн.
По P2. В протоколе есть условие: «после проверки содержания». Модель его убрала. Правильный исход: поручение с условием - сначала содержательная проверка, потом письмо. Исполнитель в строке не назван - сотрудник фиксирует «не указан» и уточняет у руководителя.
По P3. Руководитель решение отложил. Модель превратила предложение участника в поручение «закрыть вопрос». Правильный исход: нерешённый вопрос с цитатами обеих сторон. Сотрудник не выбирает, чья позиция верна - он сохраняет обе цитаты и передаёт руководителю.
По пункту 4. Требование из нового приложения модель применила ко всем письмам подрядчику. Правильный исход: уполномоченный специалист проверяет, как изменение влияет на действующие поручения. Прежние поручения не аннулируются автоматически.
Список после сверки:
- Координатор подготовит список открытых вопросов. Срок не указан. Источник: P1.
- Отправить подрядчику запрос подтверждения срока. Условие: после проверки содержания. Исполнитель не указан. Источник: P2.
- Нерешённый вопрос: участник предложил закрыть вопрос, руководитель решение отложил. Источник: P3.
- Изменённое приложение: добавлено требование прикладывать подтверждение согласования. Влияние на действующие поручения проверяет специалист.
Готовый черновик письма руководителю проекта:
«Из протокола совещания выделены два подтверждённых поручения и один нерешённый вопрос.
Поручение 1: координатор готовит список открытых вопросов, срок не назначен.
Поручение 2: направить подрядчику запрос подтверждения срока. Условие из протокола: после проверки содержания. Исполнитель не назначен, прошу уточнить.
Нерешённый вопрос: участник предложил закрыть вопрос по P3, руководитель решение отложил. Обе позиции сохранены в протоколе.
Отдельно: новая версия приложения добавляет требование прикладывать подтверждение согласования. Прошу направить на проверку влияния специалисту по документации. Прежние поручения по письмам подрядчику пока действуют.»
Черновик не содержит обещаний подрядчику и не выдумывает обязательств. Он фиксирует состояние дел и просит решения по открытым вопросам.
Как составить письмо подрядчику с помощью ИИ
Подтверждённые поручения из списка переносятся в черновик письма. Сотрудник различает три типа формулировок: вопрос (нужен ответ), требование (подрядчик обязан сделать) и обещание компании (мы сделаем или согласуем). ИИ может их перепутать: смягчить обязательное требование, перефразировав его как пожелание, или превратить предложение в обязательство, если в исходном тексте была неопределённость. Может перепутать адресата: письмо, предназначенное прорабу, уйдёт директору подрядной организации.
Типичный пример: в протоколе написано «подрядчик подтверждает срок», а модель пишет «подрядчик может подтвердить срок». Одно слово - и обязательство стало пожеланием. Сотрудник замечает это при сверке с исходным текстом.
Сотрудник проверяет даты, условия и адресата. Черновик передаётся профильному специалисту и руководителю проекта. Содержание письма, его жёсткость и юридическую точность определяют они, не сотрудник. Порядок согласования, допуск к отправке и полномочия устанавливает организация. Задача сотрудника - механическая часть: перенос из протокола, форматирование, проверка соответствия тексту.
В учебном примере письмо не отправляется: в протоколе не указан предмет работы подрядчика. Это блокирующее условие. Если предмет будет установлен и содержание проверено, гипотетический текст запроса мог бы быть таким:
«Прошу подтвердить срок выполнения [предмет работы, указать после проверки содержания]. Запрос отправлен после проверки содержания.»
Это черновик для обсуждения, не отправленное письмо. Срок и день недели не указаны, потому что их нет в протоколе.
Что нужно подготовить перед первой учебной задачей
Перед практикой нужны два условия. Первое - одобренный компанией сервис, использование которого разрешено политиками. Второе - документы, которые можно передать модели.
Документ готов к работе, если выполнены три условия: версия понятна (сотрудник видит дату и редакцию), текст распознан корректно (имена и числа читаются без искажений), использование разрешено внутренними правилами компании. Обезличивание данных не даёт автоматического разрешения на передачу документа модели, но и не является универсальным запретом. Вопрос допустимости нужно решить до начала работы, а не после. Если распознавание плохое - сначала починить текст или взять другой материал.
Первую задачу выбирают по трём признакам: она повторяется часто, нужные файлы доступны, результат легко проверить. Список поручений из еженедельного протокола - хороший кандидат. Сравнение редакций с юридической экспертизой - нет, его откладывают. Числовых порогов нет, решение принимает руководитель проектного офиса.
Как сравнивать редакции документов и вести историю изменений
Для сравнения двух редакций сотрудник передаёт ИИ оба файла и просит перечислить все отличия: добавленные, удалённые и изменённые абзацы, перемещённые пункты, обновлённые ссылки на приложения. Полный разбор охватывает определения, приложения и ссылки, а не только основной текст.
После этого сотрудник сверяет изменения приложения с действующими поручениями. Перенос абзаца из раздела в раздел - это не новое требование. Но если изменилось приложение, от которого зависят поручения, сотрудник замечает это и передаёт специалисту. Специалист определяет, применимо ли изменение к конкретному поручению; прежние поручения сохраняют статус до его решения.
Учебный разбор. Сотрудник видит, что пункт о порядке приёмки перенесён из третьего раздела приложения в пятый. Это структурное изменение: две версии приложения сравнивают отдельно. В новой редакции добавлен критерий подтверждения согласования. Изменённые виды работ требуют проверки оснований специалистом: он определяет, влияет ли новый пункт на действующие поручения по приёмке. Прежние поручения сохраняют статус до его решения.
Ещё один пример: приложение, где перечислены допустимые материалы, сократилось в новой редакции. Поручения по закупке, которые опирались на старый список, требуют проверки. Изменение требований - сигнал специалисту проверить основание и применимость, а не автоматическая отмена поручений. Сотрудник не принимает содержательное решение за специалиста.
Для каждого поручения сотрудник отдельно записывает два поля. Первое - источник поручения: протокол, пункт, дата. Второе - основание работы: документ, редакция, пункт. Это два разных поля, и они не совпадают автоматически.
Каждое решение по изменению сохраняется: что изменилось, решение специалиста, подтверждающее лицо, дата, ссылка на прежнюю и новую редакцию. Последующее изменение не затирает предыдущее.
Шаблон сводки статусов:
| Позиция | Действие и исполнитель | Дата / срок | Источник поручения | Основание работы / версия | Статус |
|---|---|---|---|---|---|
| P1 | Координатор готовит список открытых вопросов; завершение не подтверждено | Не назначен | Протокол v1, P1 | Протокол v1, без даты | Не подтверждено |
| P2 | Исполнитель не указан; после проверки содержания отправить запрос подрядчику | Не назначен (условие - проверка, не календарная дата) | Протокол v1, P2 | Протокол v1, без даты | Не подтверждено |
| P3 | Вопрос не закрыт; руководитель решение отложил | Не назначен | Протокол v1, P3 | Протокол v1, без даты | Не подтверждено |
| Приложение | Добавлено требование прикладывать подтверждение согласования; влияние на P1-P3 не определено | Не назначен | Новое приложение | Новая версия, идентификатор не указан | Не подтверждено; требуется проверка уполномоченным специалистом |
«Готово» от исполнителя и ссылка на файл не означают, что работа принята. Для закрытия поручения нужны проверяющий, дата, версия документа-основания и явное подтверждение. ИИ собирает подтверждённые статусы и показывает, где данных нет. Пустые ячейки в таблице честнее, чем догадки.
Как организовать обучение и проверить навык
Обучение ИИ для проектного офиса строится в четыре шага.
- Общий разбор: тренер проходит задачу на экране, коллеги обсуждают типичные ошибки.
- Самостоятельная работа на реальной задаче: кто берёт протокол, кто письмо, кто сравнение редакций.
- Взаимная проверка: сотрудник А читает результат сотрудника Б и ищет пропуски.
- Новая задача без подсказки: каждый приносит конкретный результат - список поручений, черновик письма, сравнение редакций, сводку статусов.
Результат оценивается не на скорость, а на то, замечены ли ошибки модели.
Три роли в проверке различаются по предмету. Сотрудник ищет механические пропуски: не указан исполнитель, перепутана дата, добавлено обязательство. Руководитель решает по существу: принято ли это решение, достаточно ли оснований. Уполномоченный специалист проверяет соответствие требованиям проекта и нормативным документам.
Четыре типичные учебные проверки: поручение без срока, спорное решение двух участников, перенесённый пункт с изменившимся приложением, файл, который исполнитель сдал, но никто не принял. По каждому проверяется, что сотрудник делает и почему. Цели проверки навыка: сотрудник замечает типичные пропуски модели, различает предложение и решение, не подменяет сдачу результата принятием.
Польза считается по всему циклу: подготовка файлов, работа с ИИ, исправление ошибок, проверка результата. Сравнение с ручной работой ведётся при равном качестве - это показывает, где экономится время, а где добавляется контроль.
Если протокол короткий, структура задачи ясная и ошибок при ручной обработке почти нет - ИИ не нужен. Письмо из трёх предложений не требует модели. Если объём большой, документов много и при ручной работе регулярно теряются пункты - стоит рассмотреть отдельный проект по автоматизации. Это отдельное исследование, не доказательство окупаемости. Решение принимает руководитель, изучив возможности обмена данными, доступы и порядок проверки.
Частые вопросы
Что делать, если в протоколе спорное решение?
Если два человека высказались по-разному и решение не было явно утверждено - это не поручение. Сотрудник сохраняет цитаты обеих позиций с указанием места в записи и передаёт руководителю с пометкой «решение не принято». Участие в обсуждении не даёт права самостоятельно закрывать вопрос. Уполномоченный руководитель принимает решение с полным контекстом: что обсуждалось, кто предлагал, какие последствия. Пока решение не принято, вопрос остаётся открытым.
Какие документы подходят для первой задачи по обучению ИИ?
Протоколы совещаний, которые уже обработаны и не содержат коммерческой тайны. Файлы, использование которых прямо разрешено политикой компании. Если документ помечен как ограниченный, он не передаётся модели. Обезличивание само по себе не снимает ограничение и не является универсальным разрешением - вопрос допустимости решается до начала работы, не после. Для первой задачи лучше брать рутинный документ с чётким проверяемым результатом: еженедельный протокол подходит лучше, чем юридическое соглашение.
Как проверить, что сотрудник освоил навык работы с ИИ?
Навык проверяется на новой задаче с изменёнными условиями - не той, на которой обучали. Сотрудник приносит конкретный результат: список поручений, черновик письма, сравнение редакций. Результат оценивается по тому, замечены ли ошибки модели: пропущенные поручения, подставленные сроки, добавленные обязательства. Проверка не считается проведённой, пока результат не сверен с исходным материалом. Навык подтверждён, когда сотрудник замечает типичные пропуски, различает предложение и решение и не подменяет сдачу результата принятием.
Можно ли отправлять письмо подрядчику без согласования?
Нет. Черновик письма передаётся профильному специалисту и руководителю проекта - они решают содержание и форму. Содержание письма, его жёсткость и юридическую точность определяет не сотрудник. Порядок согласования и допуск к отправке устанавливает организация. Задача сотрудника - механическая часть: перенос из протокола, форматирование, проверка соответствия тексту. Отправка писем и запись в системы не входят в этот учебный метод.
Когда обучение ИИ в проектном офисе не нужно?
Если протокол короткий, структура задачи ясная и ошибок при ручной обработке почти нет - ИИ не нужен. Письмо из трёх предложений не требует модели. Если объём большой, документов много и при ручной работе регулярно теряются пункты - стоит рассмотреть автоматизацию. Это отдельное исследование, не доказательство окупаемости. Решение принимает руководитель, изучив возможности обмена данными, доступы и порядок проверки.
Как сравнивать версии документа с помощью ИИ?
Сотрудник берёт две редакции одного документа и просит модель перечислить все отличия: добавленные, удалённые и изменённые абзацы, перемещённые пункты, обновлённые ссылки на приложения. Затем проверяет, как изменения влияют на действующие поручения. Перенос абзаца из раздела в раздел не равен новому требованию. Если изменилось приложение, от которого зависят поручения, сотрудник помечает это и передаёт специалисту. Специалист определяет влияние и решает, что делать с действующими поручениями.
Что значит «история изменений» в работе проектного офиса?
Каждое решение по поручению сохраняется вместе с датой подтверждения: что изменилось, решение специалиста, подтверждающее лицо, ссылка на прежнюю и новую редакцию документа. Следующее изменение не затирает предыдущее - оба остаются в записи. Сотрудник фиксирует, что изменилось, кто принял решение и когда подтвердил.
Заключение
Обучение ИИ для проектного офиса работает, когда строится на реальных рабочих задачах - не на демонстрациях и теории. Сотрудник учится не пользоваться интерфейсом, а проверять результат модели до того, как тот уйдёт руководителю. Этот навык конкретный и проверяемый: он подтверждается на новой задаче с изменёнными условиями.
Обучение ИИ для команд девелоперских компаний: услуга, письмо, Telegram.