Ловушка «призрачных поручений» или как AI придумывает задачи

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

Но проблемы всплывают через несколько дней, когда никто и не ожидал:

1. Иллюзия договорённостей. Руководитель спрашивает с сотрудника задачу из таблицы, а тот искренне удивляется: на встрече он лишь вслух заметил, что «вопрос надо бы согласовать», но поручения на себя не брал.
2. Искажение рисков при сжатии. Осторожное сомнение коллеги («я бы не обещала, что это уберёт все задержки») при сокращении превращается в категоричный приговор («это не устранит задержки»).
3. Потеря контекста к следующей встрече. Через неделю команда собирается снова, но из гладкого AI-резюме невозможно понять, почему выбрали именно этот вариант, какие ограничения учитывали и что с тех пор изменилось. Приходится заново перекапывать почту, чаты и собственную память.

Главная идея сегодняшего выпуска: нейросеть выдаст неплохой черновик даже по запросу в одну строчку, но пригодным для принятия решений протокол делаете ВЫ. Чтобы документ реально работал, нужно сделать две вещи: до генерации объяснить модели - какое решение и кто будет принимать по этому тексту (и дать скрытый контекст, которого нет в разговоре), после генерации - сверить поручения и условия с исходной записью по таймкодам.

Нужен готовый шаблон прямо сейчас? Сразу переходите к разделу «Как применить метод одним запросом» - там собран финальный промпт для копирования.

Реальный эксперимент на учебном кейсе: развилка для руководителя Алексея

Чтобы показать, как именно AI помогает и где ошибается, разберём наглядную рабочую ситуацию (компания и люди вымышлены, а вот ответы нейросетей - полностью реальные).

Компания обслуживает сайты интернет-магазинов: клиенты присылают заявки на исправление ошибок или доработку страниц заказа и оплаты. В процессе обсуждения на очередной встрече 22 октября участвуют:

• Ольга Соколова (специалист поддержки) - принимает письма от клиентов и уточняет детали;
• Илья Орлов (аналитик) - переводит клиентские запросы в чёткие технические задания (ТЗ) для программистов;
• Марина Белова - руководит группой поддержки;
• Сергей Климов - администрирует внутреннюю систему учёта заявок.

В чём суть конфликта на встрече 22 октября: Илья предлагает пилот (в записи встречи его называют пробой): две недели он будет сам просматривать по 20 заявок на изменение формы заказа в день и сразу задавать вопросы клиентам, чтобы программист получал полное описание изменения. На это уйдёт по 2 часа ежедневно. Проблема в том, что на Илье уже висят два важных клиентских ТЗ со сроком сдачи 30 октября - новая форма заказа для мебельного магазина и страница оплаты для магазина спорттоваров.

Алексей Воронов, руководитель отдела сопровождения сайтов, который распределяет ресурсы между текучкой и обязательствами перед клиентами, эту встречу пропустил. Протокол нужен именно ему, чтобы принять конкретное управленческое решение: разрешить пилот сейчас (но строго без срыва сроков по двум октябрьским ТЗ) или отложить эксперимент до их сдачи.

(Полная расшифровка этого шестиминутного совещания приведена в конце статьи.)

Шаг 1. Простой запрос в одну строку: быстрая польза и ловушка «призрачных поручений» или как AI придумывает задачи

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

В качестве теста одну и ту же расшифровку текстом (без работы с файлами) передали двум инструментам с уровнем рассуждения high: Claude Code 2.1.309 (модель claude-fable-5‑1) и Codex CLI 0.163.0 (модель gpt-6-astra)/GPT.

Начали с самого простого промпта:

сделай мне протокол совещания по транскрипту

Уже с первой попытки Codex / GPT выдал вполне рабочую базу, вытащив ключевые факты для Алексея:

Более того, Codex аккуратно перечислил задачи Марины, Ольги и Ильи, а нераспределённые задачи (кто напишет итоговое письмо Алексею и кто проверит доступы к новым полям системы) оставил в «открытых вопросах».

А вот отчет второй модели (Claude) интересней и если бы мы его отправили Алексею, то возникла бы управленческая ошибка. Дело в том, что в таблице поручений, которую сформировала модель, появилась четвертая строка:

№	Задача	Ответственный	Срок
4	Согласовать оценку своей загрузки с руководителем аналитиков	Илья	срок не назван

А теперь давайте откроем исходную запись и посмотрим, что на самом деле сказал Илья:

[03:25] Илья: Я к концу 23 октября пришлю Ольге черновик карточки заявки: ссылка на страницу, что происходит сейчас и что клиент хочет получить. Оценку своей загрузки ещё надо согласовать с руководителем аналитиков.

Что произошло: Илья взял на себя только отправку черновика карточки. Про согласование загрузки он просто упомянул как про необходимое условие, а запросить у руководителя аналитиков время для Ильи через 25 секунд взялась Марина [03:50]. Claude же превратил реплику Ильи в его личное поручение (тогда как Codex оставил этот момент открытым вопросом). Прочитав такой протокол, Алексей ждал бы от Ильи шагов, о которых тот даже не подозревает.

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

Шаг 2. Задаём фокус адресата и добавляем «невидимый» контекст

Участники совещания живут внутри процесса: на созвоне никто не произносит вслух полные должности коллег, предысторию прошлых встреч или детали старых клиентских заказов. Но без этого протокол остаётся «слепым». Кроме того, руководителю нужна выжимка, а не "простынка" текста.

Поэтому на втором шаге мы дополняем наш запрос двумя блоками (сохраняя исходную расшифровку).

1. Разворачиваем документ лицом к тому, кто принимает решение

Добавляем в промпт указание на адресата и его целевое действие:

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

Смотрите, как сразу изменился первый же абзац в ответе Codex:

Алексею на решение: выделить Илье время на ограниченную пробу нового порядка приёма заявок без переноса двух технических заданий со сроком 30 октября либо отложить пробу до их сдачи. Разрешение на пробу пока не получено.

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

2. Вводим справочный контекст (и требуем отделять его от встречи)

На встрече прозвучала фраза «у тебя два технических задания к 30 октября». Но что это за задания? Горят ли по ним сроки уже сейчас? Имели ли участники право сами запустить пилот? В записи этого нет. Более того, в записи нет и описания деятельности самой организации, подразделения - что зачастую является серьезным дополнением, которое может сильно изменить итоговые тезисы. Итак, передаём эти знания модели отдельной инструкцией:

Используй дополнительный контекст ниже. Отделяй сведения контекста от сказанного на встрече.

Сам контекст не должен быть большим:

Компания обслуживает сайты интернет-магазинов. Отдел Алексея принимает заявки на исправление ошибок и изменение функций сайтов клиентов. Поддержка уточняет запрос клиента; аналитик превращает его в техническое задание, по которому программист меняет сайт.
Адресат: Алексей Воронов, руководитель отдела сопровождения сайтов клиентов. Распределяет людей между заявками и согласованными работами; выбирает, разрешить ли пробу с ранним подключением аналитика. Встречу пропустил.
Участники: Марина Белова — руководитель группы поддержки клиентов; Ольга Соколова — специалист этой группы, принимает и уточняет заявки клиентов; Илья Орлов — аналитик, составляет технические задания для программистов; Сергей Климов — администратор внутренней системы учёта заявок.
Два технических задания Ильи — описание новой формы заказа для магазина мебели и изменение страницы оплаты для магазина спортивных товаров. Оба обещаны клиентам на 30 октября. Просрочки конечного срока нет. На 22 октября свободное время Ильи для пробы не подтверждено.
Результат встречи нужен Алексею для выбора между пробой без переноса обещанных клиентам заданий и отсрочкой пробы. 19 октября договорились сначала подготовить варианты и оценить загрузку, затем получить решение Алексея. До этого встреча не имела полномочий запускать новый порядок.

В результате Codex аккуратно встроил эти данные, но снабдил их важной пометкой:

Дополнительный контекст, не итог встречи: на 22 октября свободное время Ильи не подтверждено. Два его задания — новая форма заказа для магазина мебели и изменение страницы оплаты для магазина спортивных товаров. Оба обещаны на 30 октября; просрочки конечного срока нет.

• Почему это важно: если смешать внешнюю справку с репликами участников, через неделю никто не вспомнит, обсуждали ли мебельный магазин на самой встрече или это данные из трекера задач.
• Что делать вам: перед генерацией напишите 5‑7 строк контекста (роли людей, о каких проектах речь, статус сроков и откуда взята эта информация) и прямо попросите модель отделить эту справку от итогов разговора. Если каких-то вводных вы сами не знаете - попросите модель вынести их в вопросы для уточнения.

Шаг 3. Требуем таймкоды и защищаем смысл от искажений при сжатии

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

Прочитай запись целиком. Различай решения, подтверждённые поручения, предложения и мнения. Не назначай людей и сроки, которых нет в источнике. Учитывай поздние поправки. Для решений и поручений дай таймкод; неизвестное оставь вопросом. Сохрани причину выбора и отвергнутые варианты.

Что это дало в ответе Codex:

1. Чёткий статус задач. Модель добавила пометку: «Подтверждённые поручения. В записи подтверждено принятие обязательств, но не их выполнение», а сомнения Ольги назвала «оценкой риска».

2. Учёт поздних правок с таймкодами. В середине встречи [04:40] Марина предлагала начать пилот 26 октября. Но затем Сергей напомнил [05:05], что 26-го числа обновляется система, и Марина скорректировала позицию:

   [05:35] Марина: Тогда 26 октября убираем даже из предложения. Начало не раньше 28 октября, после подтверждения, что система работает и Илье выделено время. Если Алексей не согласует ресурс, пробу откладываем.

   Благодаря таймкоду [05:35] в протоколе сразу видно, откуда взялось 28 октября и почему это лишь самая ранняя возможная дата при выполнении условий: старт пока не утверждён.

Опасность резюмирования: как сжатие текста меняет смысл

Дальше мы попросили модель упаковать текст в удобный двухслойный формат (короткое резюме сверху + детали снизу) и ограничили объём:

Сделай два уровня чтения: в первых 150 словах выбор Алексея, причины, ограничения и ближайший подтверждённый шаг; далее поручения и открытые вопросы. Не более 550 слов целиком. Не теряй оснований и неподтверждённых условий ради краткости.

Структура стала отличной: в первые 150 слов вошли развилка для Алексея, условия и ближайший конкретный шаг (Марина до 17:00 22 октября запрашивает ресурс у руководителя аналитиков). Но ради экономии слов модель допустила два опасных смысловых сдвига.

Сдвиг №1: предостережение превратилось в приговор.

Как написал Codex после сжатия:

Мнение Ольги: два часа ежедневно могут задержать задания; раннее подключение аналитика не устранит все задержки, поскольку часть клиентов отвечает на следующий день [01:50].

Что реально сказала Ольга:

[01:50] Ольга: Но у тебя два технических задания для других клиентов к 30 октября. Два часа в день могут задержать их. И часть клиентов всё равно ответит только завтра. Я бы не обещала, что твоё подключение уберёт все задержки.

В чём разница: осторожный совет не давать лишних обещаний превратился в безапелляционное утверждение «не устранит».

Сдвиг №2: общий план приклеился к личному поручению.

Как написал Codex в таблице поручений:

Кто	Результат и срок	Таймкод
Ольга	Отобрать десять прошлых заявок на изменение формы заказа и отметить недостающие данные — 23 октября до 15:00; выяснить, какие вопросы поддержка может задавать сама	03:00

Что реально сказала Ольга:

[03:00] Ольга: Я к 15:00 23 октября отберу десять прошлых заявок на изменение формы заказа и отмечу, каких данных не хватало. Посмотрим, какие вопросы поддержка может задать сама.

В чём разница: Ольга обязалась к 15:00 только отобрать 10 прошлых заявок и отметить, чего в них не хватало. А «посмотрим, какие вопросы...» - это уже совместный следующий шаг команды без конкретного срока и единоличного исполнителя. Сжав текст, Codex повесил на Ольгу лишнюю аналитическую задачу.

• Почему это важно: в этом примере при сокращении пропали оговорки: «я бы не обещала» стало «не устранит», а «посмотрим» превратилось в личное поручение. Поэтому после сжатия проверяйте силу выводов и состав поручений.
• Что делать вам: обязательно требуйте таймкоды в промпте - именно они позволяют быстро найти нужные места записи и поймать подобные перегибы после сокращения текста.

Шаг 4. Финальная сверка: исправляем сдвиги и получаем эталонный протокол

Когда черновик готов, пройдитесь по таймкодам в расшифровке и проверьте четыре вещи: что именно сказано, кто лично принял задачу, какой назван срок и не отменили ли это решение в конце разговора.

Если смысловых искажений много или они ломают логику документа, отправьте модели корректирующий промпт (приложив запись, справку и предыдущий ответ). В нашем случае мы указали Codex на обе неточности с Ольгой:

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

Codex исправил обе ошибки: вернул точную формулировку («не рекомендует обещать устранение всех задержек»), а разбор вопросов поддержки убрал из личных задач Ольги в раздел «Предложения».

Важное правило: на повторный запрос модель возвращает документ целиком, поэтому его нужно снова просмотреть глазами. А вот мелкие локальные шероховатости (1‑2 фразы) гораздо быстрее и надёжнее поправить руками. Например, при финальной ручной вычитке мы заменили в резюме «обработку 20 заявок в день» на «просмотр 20 заявок на изменение формы заказа» [01:15], вернули пометку «не итог встречи» к справке, указали неподтверждённость времени Ильи на 22 октября и явно зафиксировали отказ Сергея брать на себя обучение и координацию [04:10].

Ниже приведён полный документ, который после небольших косметических правок (не забывайте, что итоговый вариант документа готовите вы) можно смело класть на стол руководителю.

Полный протокол (образец)

Протокол встречи 22 октября 2026 года

Адресат: Алексей Воронов, руководитель отдела сопровождения сайтов клиентов.

Резюме

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

Повод - повторные уточнения по 12 из 46 заявок за прошлую неделю. Илья предлагает сразу уточнять запросы клиентов, чтобы программисты получали полное описание изменений. Ольга предупреждает о риске задержать другие работы и не рекомендует обещать устранение всех задержек.

Предлагаемые условия: две недели, просмотр 20 заявок на изменение формы заказа в день, два часа Ильи ежедневно. Ресурс и запуск не согласованы. Начало возможно не раньше 28 октября, после подтверждения работоспособности системы, выделения времени Илье и решения Алексея. Без согласования ресурса пробу откладывают.

Ближайший подтверждённый шаг по итогам встречи: Марина Белова до 17:00 22 октября запросит у руководителя аналитиков возможность выделить время Илье без переноса заданий.

Участники и справочный контекст

Участники: Марина Белова - руководитель группы поддержки; Ольга Соколова - специалист поддержки; Илья Орлов - аналитик, составляющий технические задания программистам; Сергей Климов - администратор внутренней системы учёта заявок. Алексей отсутствовал.

Справочный контекст, не итог встречи: два задания Ильи - новая форма заказа для мебельного магазина и изменение страницы оплаты для магазина спортивных товаров. Оба обещаны к 30 октября; на дату встречи просрочки нет. Свободное время Ильи на 22 октября не подтверждено. По договорённости от 19 октября сначала готовят варианты и оценивают загрузку, затем получают решение Алексея.

Основания

• Сейчас поддержка принимает письма клиентов и передаёт заявки Илье для описания изменений программистам [00:00].
• Из 46 заявок по 12 потребовались повторные уточнения: например, ссылка на страницу или ожидаемая работа кнопки заказа. Семь клиентов ответили в тот же день, пять - на следующий. Это не потерянные заявки и не 12 одинаковых ошибок [00:40].
• По оценке Ольги, два часа ежедневно могут задержать подготовку двух технических заданий. Она предостерегает от обещания убрать все задержки: скорость ответа клиентов также влияет на обработку заявки [01:50].
• На 26 октября запланировано обновление системы; доступ к новым полям можно проверить после него. Поэтому 26 октября исключили из предложения, а 28 октября обозначили как самую раннюю возможную дату, без назначения старта [05:05; 05:35].

Предложения

Илья предлагает две недели самостоятельно просматривать по 20 входящих заявок на изменение формы заказа ежедневно и сразу задавать клиентам вопросы, затрачивая два часа в день. Эти параметры не утверждены. Весь поток клиентских писем аналитику пока не передают.

После подготовки примеров предполагается обсудить, какие вопросы поддержка может задавать самостоятельно. Сергей предложил показать, как отмечать тип доработки в системе, но обучение всех сотрудников и координацию пробы на себя не взял [04:10].

Подтверждённые поручения

В записи подтверждено принятие поручений, но не их выполнение.

Примеры и черновик карточки готовят независимо от решения о запуске.

Открытые вопросы

• Какую загрузку Ильи согласует руководитель аналитиков и какое решение примет Алексей?
• Кто и когда проверит доступ к новым полям и подтвердит работоспособность системы?
• Кто и к какому сроку отправит Алексею итоговое письмо?
• Кто будет координировать пробу и обучать сотрудников? Сергей этих обязательств и проверки доступа не принял.

Как применить метод одним запросом (готовый шаблон)

В реальной работе вам не нужно проходить четыре отдельных шага - все эти требования можно сразу объединить в один стартовый промпт.

Единый запрос для копирования

Подготовь протокол по расшифровке ниже.

Адресат: [имя и понятная роль]. Ему нужно [принять какое решение или подготовить какое действие]. Начни с его выбора, оснований и ограничений.

Дополнительный контекст: [справочник участников с ролями, документы и их назначение, существенные сроки и предыстория; укажи источник этих сведений]. Отделяй этот контекст от сказанного на встрече. Если сведений нет, запиши вопрос для уточнения.

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

Сделай два уровня: резюме с выбором адресата, причинами, условиями и ближайшим подтверждённым шагом; затем подробности, поручения и открытые вопросы. Ориентир для резюме - до 150 слов, для всего документа - до 550 слов. Ссылки на реплики оставь в подробностях. Если существенные основания и условия не помещаются, сохрани их, даже если документ станет длиннее.

Расшифровка:
[вставьте полный текст или укажите приложенный файл]

Совет по настройке: лимиты в 150 и 550 слов - ориентир для короткой встречи; меняйте их под масштаб вашей задачи. Чтобы сверка работала, в расшифровке должны быть таймкоды и имена говорящих. Если таймкодов в вашем транскрипте нет, попросите нейросеть указывать имя спикера и первые слова цитаты.

Что делать перед следующей встречей: продолжаем с нужной точки

Главная ценность качественного протокола раскрывается перед следующим совещанием. Если вы сохранили в папке встречи проверенный протокол и исходную запись, вам остаётся лишь добавить туда короткий файл с фактами о том, что реально произошло за неделю (какие решения приняты, кто что прислал, какие сроки сдвинули - с указанием источников).

Передайте этот комплект нейросети со следующим промптом:

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

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

В нашем примере с отделом Алексея к новой встрече стоит проверить три блока вопросов:

• Проверка условий запуска: выделил ли руководитель аналитиков 2 часа в день для Ильи без ущерба для двух ТЗ к 30 октября? Обновилась ли система 26 октября и работает ли она?
• Статус поручений: написала ли Марина руководителю аналитиков (и какой пришёл ответ - это проверяется отдельно от факта отправки письма)? Отобрала ли Ольга 10 заявок? Прислал ли Илья черновик карточки?
• Незакрытые вопросы: какое решение принял Алексей? Назначены ли ответственные за проверку доступов к полям карточки и за координацию пилота (ведь Сергей от этого отказался)?

Чек-лист: 5 шагов для идеального протокола

Сохраните эту памятку, чтобы проверять себя при подготовке документов с AI:

1. Задайте адресата и цель: прямо напишите в промпте, для кого готовится документ и какое решение этот человек должен принять.
2. Дайте внешний контекст: приложите краткую справку (роли участников, суть упоминаемых проектов, жёсткие внешние дедлайны) и потребуйте отделить её от итогов самой встречи.
3. Потребуйте таймкоды и разделение статусов: попросите модель отличать твёрдые решения от мнений и предложений, учитывать поправки в конце разговора и ставить ссылки на время реплик.
4. Сверьте черновик с записью: проверьте по таймкодам, не приписал ли AI кому-то «призрачных» задач и не исказил ли осторожные формулировки при сжатии текста.
5. Используйте протокол для подготовки следующей встречи: добавьте к нему подтверждённые изменения за неделю и попросите AI составить список вопросов, не считая задачи выполненными только из-за наступившего срока.

Скачать чек-лист в PDF

Приложение. Расшифровка учебной встречи

УЧЕБНЫЙ ПРИМЕР: компания и все люди вымышлены.
22 октября 2026 года. Компания обслуживает сайты интернет-магазинов: исправляет ошибки и добавляет функции по запросам клиентов. На встрече обсуждают обработку заявок клиентов на изменение форм заказа и оплаты на их сайтах.

[00:00] Марина: Наши специалисты поддержки принимают заявки клиентов по электронной почте. Потом передают их Илье, чтобы он описал программистам, что нужно изменить. Сейчас обсуждаем, стоит ли Илье подключаться к заявкам сразу. Алексей, руководитель нашего отдела сопровождения сайтов, отсутствует. Он распределяет время сотрудников и должен решить, разрешать ли пробу нового порядка.
[00:40] Ольга: За прошлую неделю пришло 46 заявок. По 12 мы повторно писали клиентам: где-то не было ссылки на страницу с ошибкой, где-то не было понятно, как должна работать кнопка заказа. Семь клиентов ответили в тот же день, пять на следующий. Это не потерянные заявки и не 12 одинаковых ошибок.
[01:15] Илья: Предлагаю две недели сам смотреть входящие заявки на изменение формы заказа. По 20 заявкам в день, два часа моего времени ежедневно. Буду сразу задавать клиенту вопросы, чтобы программист получил полное описание изменения.
[01:50] Ольга: Но у тебя два технических задания для других клиентов к 30 октября. Два часа в день могут задержать их. И часть клиентов всё равно ответит только завтра. Я бы не обещала, что твоё подключение уберёт все задержки.
[02:25] Марина: Выбор для Алексея такой: выделить Илье время на небольшую пробу без переноса этих двух заданий или вернуться к пробе после их сдачи. Весь поток писем клиентов аналитику пока не передаём. Две недели, 20 заявок и два часа — предлагаемые условия, не утверждённые.
[03:00] Ольга: Я к 15:00 23 октября отберу десять прошлых заявок на изменение формы заказа и отмечу, каких данных не хватало. Посмотрим, какие вопросы поддержка может задать сама.
[03:25] Илья: Я к концу 23 октября пришлю Ольге черновик карточки заявки: ссылка на страницу, что происходит сейчас и что клиент хочет получить. Оценку своей загрузки ещё надо согласовать с руководителем аналитиков.
[03:50] Марина: Я сегодня до 17:00 запрошу у руководителя аналитиков, можно ли выделить тебе время без переноса двух технических заданий.
[04:10] Сергей: Я могу показать, как в нашей системе заявок отмечать тип доработки. Но обучение всех сотрудников и координацию пробы на себя не беру. Отдельную задачу с датой мне сейчас не записывайте.
[04:40] Марина: В предложении Алексею укажем возможный старт 26 октября. Пока только предлагаем, ждём его решения. Кто отправит ему итоговое письмо и к какому сроку, сейчас не назначаем.
[05:05] Сергей: 26 октября сервисная система заявок будет обновляться. Доступ к новым полям карточки смогу проверить только после обновления. Саму проверку доступов сейчас на себя не беру, владельца надо назначить.
[05:35] Марина: Тогда 26 октября убираем даже из предложения. Начало не раньше 28 октября, после подтверждения, что система работает и Илье выделено время. Если Алексей не согласует ресурс, пробу откладываем. Сбор примеров и черновик карточки всё равно делаем к 23 октября. Отправитель письма и ответственный за проверку доступа остаются не назначены.