Как подготовить передачу дел с помощью ИИ

Как подготовить передачу дел с помощью ИИ: модель собирает черновик документа из ваших рабочих заметок, вы сверяете каждое поле с исходником и фиксируете приёмку получателем. Ниже — назначение такого документа, порядок сбора данных, готовый промпт, учебный заполненный пример, разбор ошибок и ручная проверка.

Назначение итогового документа и его границы

Документ передачи описывает одну конкретную текущую работу: состояние, точные источники, следующее действие, права доступа, открытые вопросы и условие приёмки. Онбординг вообще и пересылка паролей в эту задачу не входят. Издание Nakhweh в своём руководстве по передаче волонтёрского проекта пишет, что папки с файлами мало: следующий человек должен знать, какую версию использовать, что осталось нерешённым и кто принимает следующее решение. Там же отмечено, что короткая передача делает эти границы видимыми и не превращает уходящего в постоянную поддержку.

Издание Smartsheet в подборке шаблонов передачи проекта перечисляет поля, которые закрывают такую же рамку: общая информация о проекте, обзор, объём работ, график, затраты, выгоды, заказчики, риски, ограничения и допущения. Для передачи от одной команды к другой там же предлагается форма приёмочной подписи заказчика с полями сводки, договорных данных, графика, итоговых затрат, источников финансирования и финальных результатов. Эти перечни задают верхнюю границу: всё, что выходит за текущую работу, остаётся в других документах.

Практический вывод для читателя: перед сборкой назовите работу одним предложением и проверьте, что каждый пункт черновика относится к ней. Пункт про общие процессы команды или про отпуск коллеги в документ не попадает. Если работа ещё определяется, Nakhweh советует сначала зафиксировать согласованный результат, а уже потом собирать передачу: получателю нужно сравнить запрошенное с фактически готовым.

Границы удобно держать в трёх строках шапки: название работы, версия заметки и дата актуальности. Nakhweh прямо предлагает начинать с этих трёх элементов и добавлять одно предложение с согласованным результатом. Дальше каждый результат получает одну из трёх простых меток: готов к проверке, принят, не завершён. Метка «принят» означает, что получатель явно согласился взять результат на себя; отправка письма или загрузка файла такого согласия не создают.

Сбор и проверка исходных данных

Сначала составьте список источников для передачи. Выпишите точные имена файлов, листов, таблиц и шаблонов, из которых берутся данные, и рядом укажите, что именно из каждого берётся. Учебный пример ниже использует таблицу «Брони 2026», лист «Ноябрь» и шаблон «Отчёт мастерской v3» — это условные названия для тренировки.

Дальше разделите данные на три группы. Первая — состояние: что сверено и на какую дату. Вторая — незакрытое: что ждёт внешнего события. Третья — неизвестное: данные, которых у вас нет и которые нельзя додумать. Издание ClickUp в статье о шаблонах передачи знаний называет среди обязательных элементов шаблона участников передачи, категории информации, ссылки на документы и критерии успеха с способом их измерения. Там же предлагается вести шаблон на совместной платформе, где несколько человек обновляют и видят изменения в реальном времени.

Проверка исходных данных идёт по трём вопросам к каждому пункту. Откуда взято значение: имя файла и лист. На какую дату оно верно. Кто подтверждает, что оно верно. Если хотя бы один из этих вопросов остаётся без ответа, перенесите пункт в раздел открытых вопросов.

Отдельно проверьте доступы. Nakhweh советует записывать, где хранится результат, что он содержит и какие у него известные ограничения, давать ссылку на поддерживаемую копию и указывать роль, которая может выдать ограниченный доступ по утверждённому процессу. Пароли, списки участников и чувствительные заметки в общую передачу не вставляются. Это правило удобно проверить механически: поищите в черновике строки с паролем, токеном и персональными списками.

Таблица ниже показывает, как раскладывать собранное до генерации черновика.

Готовый заполненный учебный артефакт

Ниже — учебная передача еженедельного отчёта мастерской. Названия файлов условные, даты взяты для тренировки, документ показывает структуру и уровень детализации.

Передача: еженедельный отчёт мастерской
Версия заметки: 1
Информация актуальна на: 11 ноября

Согласованный результат: получатель собирает и публикует еженедельный отчёт мастерской по бронированиям.

Источники:
- таблица «Брони 2026», лист «Ноябрь»
- шаблон «Отчёт мастерской v3»

Готово: срез за 1–7 ноября сверен.

Не готово: срез 8–14 ноября ждёт закрытия недели.
Триггер: закрытие недели в таблице.

Следующее действие: 15 ноября проверить отменённые брони и обновить лист.

Доступ: получатель запрашивает чтение таблицы и редактирование шаблона у владельца. Пароли в документ не попадают.

Открыто: кто утверждает отменённые брони? Ответственный не назначен, нужно решение организатора.

Приёмка: получатель открывает оба файла, называет следующее действие и повторяет сборку на учебном срезе.

Статус передачи: ещё не принята.

Разбор примера по элементам. Шапка даёт версию и дату, чтобы получатель понимал свежесть данных. Блок источников называет точные файлы и листы, поэтому проверка идёт по конкретному месту. Раздел «Готово» содержит одно проверенное утверждение с диапазоном дат. Раздел «Не готово» отделяет незакрытую неделю и называет триггер, по которому работа продолжится. Следующее действие имеет дату и конкретную операцию. Доступ описан через роль владельца, пароли вынесены за рамки. Открытый вопрос сформулирован как решение, которое нужно принять, и не подписан чужим именем. Приёмка перечисляет наблюдаемые действия получателя. Статус в конце честно фиксирует, что передача не завершена.

Такой же каркас применим к другой работе: замените название, источники, диапазоны дат и следующее действие. Структура полей остаётся, меняется содержимое.

Копируемый промпт с указанными входами

Промпт ниже собирает черновик из ваших заметок. Вставьте его в чат модели и заполните квадратные скобки своими данными.

Составь документ передачи работы из моих заметок.

Входные данные:
- работа: [название работы одним предложением]
- согласованный результат: [что должно быть сделано]
- источники: [точные имена файлов, листов, таблиц, шаблонов]
- готово: [что сверено и на какую дату]
- не готово: [что ждёт внешнего события и какого]
- следующее действие: [дата и конкретная операция]
- доступ: [какая роль выдаёт права и как их запрашивают]
- открытые вопросы: [что не решено и кто принимает решение]
- приёмка: [какие действия получателя подтвердят передачу]

Требования к документу:
1. Начни с названия работы, версии заметки и даты актуальности.
2. Дай каждому результату одну метку: готов к проверке, принят, не завершён.
3. Для каждого открытого пункта укажи следующее действие, ответственного и дату проверки.
4. Отдели решение от задачи и покажи зависимость между ними.
5. Не отмечай задачу завершённой без основания.
6. Не вставляй пароли, токены и персональные списки.
7. Пометь места, где данных не хватает, отдельным списком.
8. Закончи условием приёмки и текущим статусом передачи.

Что менять под себя: название работы, согласованный результат, имена источников, диапазоны дат, следующее действие, роли доступа и условие приёмки. Требования к документу можно дополнять, если у вашей работы есть свои обязательные поля.

Вариации той же задачи для других случаев:

• передача роли: замените источники на список регулярных задач и точек принятия решений;
• передача клиентского проекта: добавьте поле с контактным лицом и договорными данными;
• передача дежурства: добавьте расписание и порядок эскалации;
• передача архива: добавьте правило именования и срок хранения;
• передача подрядчику: добавьте перечень принятых работ и порядок приёмки.

Отрицательный пример и неизвестные данные

Отрицательный пример начинается с фразы «всё готово, можно подхватить». Такая формулировка скрывает незакрытую неделю и непроверенный доступ. Получатель читает её как разрешение действовать и не проверяет, какие данные устарели.

Разберём, что именно ломается. Первое: пропадает дата актуальности, поэтому непонятно, на какой момент верны цифры. Второе: незавершённая работа выглядит завершённой, и её никто не продолжит. Третье: доступ описан словами «доступ есть», и получатель не знает, к кому идти за правами. Четвёртое: открытый вопрос исчезает, решение по нему не принимается. Пятое: условие приёмки отсутствует, поэтому передача не имеет момента завершения.

Неизвестные данные оформляются отдельным списком. Nakhweh предлагает для открытого пункта три обязательных элемента: конкретное следующее действие, согласованный ответственный и дату проверки, а фразу «кто-то должен заняться» считает неполной. Если ответственность никто не взял, там же рекомендуется написать, что пункт не назначен и нужно решение организатора. Имя человека в такой пункт не подставляется без его согласия.

Отдельная частая ошибка — смешивать решение и задачу. Nakhweh приводит пример: решение о том, печатать ли ярлыки, и задача подготовить утверждённый файл ярлыков — разные пункты, причём задача зависит от решения. Зависимость указывается прямо, чтобы следующий человек не принял нерешённый выбор за разрешение действовать.

Ещё одна ошибка — придумывать данные для заполнения пустого поля. Если срез за период не сверен, в документе стоит «не готово» и триггер, по которому срез закроется. Выдуманное значение выглядит аккуратнее и приводит к неверному отчёту.

Ручная проверка результата по исходнику

Проверка идёт построчно по исходным файлам. Откройте таблицу и лист, названные в документе, и сверьте каждое утверждение раздела «Готово». Диапазон дат должен совпадать с фактически сверенным. Числа в отчёте должны совпадать с числами в источнике.

Дальше проверьте ссылки и версии. Издание ClickUp в статье о шаблонах передачи проекта отмечает, что лучшие документы передачи краткие, точные и совместные, а все заметки описывают детали проекта и предотвращают путаницу между сторонами и дублирование работы. Там же сказано, что риск дублирующихся задач возникает при передаче между людьми и подразделениями, а дублирующая нагрузка выгоды не приносит. Проверка на дублирование — часть ручного этапа: пройдите по списку задач и убедитесь, что одна работа не назначена двум исполнителям.

Третий шаг — тест доступа. Получатель запрашивает права у названной роли и подтверждает, что чтение таблицы и редактирование шаблона выданы. Пароли в документе не проверяются, потому что их там быть не должно.

Четвёртый шаг — тест приёмки. Получатель открывает оба файла, называет следующее действие и повторяет сборку на учебном срезе. Если сборка расходится с ожидаемой, документ возвращается на доработку с указанием конкретного места.

Таблица ниже помогает распределить проверки.

Сохранение и согласование результата

Сохранение начинается с выбора места. Издание ClickUp в статье о шаблонах передачи знаний предлагает вести шаблон на совместной платформе, где несколько участников обновляют документ и видят изменения в реальном времени, и выделять отдельный раздел со ссылками на документы, руководства и внешние ресурсы. Там же среди критериев успешной передачи названы своевременность, понимание получателем и минимум ошибок после передачи, а измеряться они могут опросами, проверками знаний и показателями проекта.

Согласование фиксирует момент завершения. Nakhweh прямо указывает: метка «принят» означает явное согласие получателя взять результат на себя, а письмо или загруженный файл такого согласия не создают. Поэтому в документе остаётся строка статуса, и она меняется только после подтверждения получателем.

Издание Smartsheet в подборке шаблонов закрытия проекта добавляет к этому рекомендации и подписи об утверждении внизу документа. Для передачи текущей работы достаточно строки статуса и условия приёмки, а полный отчёт о закрытии проекта остаётся отдельным документом.

Если учебный артефакт нужно сохранить как PDF, порядок такой: вставьте текст в текстовый редактор, задайте заголовок первого уровня для названия работы, сохраните файл, затем выберите экспорт в PDF и проверьте, что таблицы и списки не разъехались. Имя файла берите по названию работы и версии заметки.

Частые вопросы

Куда девать пароли при передаче дел?
Пароли в документ передачи не попадают. Nakhweh советует указывать роль, которая может выдать ограниченный доступ по утверждённому процессу, и давать ссылку на поддерживаемую копию файла. Получатель запрашивает права сам.

Что делать, если часть данных неизвестна?
Неизвестные данные идут в отдельный список открытых вопросов. Для каждого пункта нужны конкретное следующее действие, согласованный ответственный и дата проверки. Если ответственного нет, так и пишется, с пометкой о нужном решении.

Чем подтверждается приёмка передачи?
Получатель открывает названные файлы, называет следующее действие и повторяет сборку на учебном срезе. Метка «принят» появляется после явного согласия получателя взять результат на себя. Отправка письма или загрузка файла согласия не создают.

Как проверить черновик, собранный моделью?
Сверьте диапазоны дат и числа с исходным листом, проверьте ссылки на поддерживаемые копии и уберите дубли задач. Затем пройдите тест доступа и тест приёмки. Места, где данных не хватает, верните в список открытых вопросов.

Что делать с незавершённой работой?
Незавершённая работа остаётся в документе с меткой «не завершён» и триггером, по которому она продолжится. Рядом указывается следующее действие с датой. Фраза о полной готовности скрывает такую работу и приводит к неверному отчёту.