Постановка задач через ИИ — от голосовых к списку с дедлайнами

Задачи теряются не в трекере. Они теряются по дороге к нему.

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

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

Где именно рвётся цепочка

Постановка задачи — это не момент, а цепочка из четырёх звеньев: сказал → сформулировал → зафиксировал → проверил. Топовые статьи по запросу «постановка задач» разбирают второе звено: SMART, критерии, контекст. Это полезно, но у руководителя с тридцатью поручениями в неделю ломается не формулировка. Ломается перенос и проверка.

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

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

ИИ закрывает ровно эти два звена: он быстро превращает поток речи в структуру и быстро сравнивает список с датами. Он не выбирает исполнителя и не расставляет приоритеты — здесь он вам наврёт с уверенным лицом.

Шаг 1. Сделать вход машиночитаемым

Прежде чем что-то просить у модели, нужен текст. Источников три, и с каждым работают по-своему.

Голосовые и надиктовка. ChatGPT и Gemini принимают звук на вход — можно надиктовать поручения сразу после разговора, пока помните, или загрузить запись. В приложении Claude голосовой ввод и диктовка тоже есть, но аудиофайл туда не загрузить: запись планёрки придётся сначала расшифровать. В веб-чате DeepSeek, по моему опыту, загрузить аудио не получается — он берёт текстовые документы и изображения. Если вы диктуете один, этого достаточно. Если записана планёрка с пятью участниками, возникает вторая задача: понять, кто что сказал. Распознавание речи и разделение по говорящим — разные функции, и вторая есть далеко не везде, где есть первая. Проверьте на своём сервисе встреч, выгружает ли он реплики с пометками участников; если нет, привязывать поручения к людям придётся вручную.

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

Выгрузка из трекера. В Bitrix24 есть экспорт в Excel и CSV, в Notion — в CSV. В Trello экспорт доски в CSV доступен только на платных тарифах, на бесплатном отдаётся JSON — его придётся конвертировать. Один раз разберитесь, какие колонки вам нужны — название, исполнитель, срок, статус, дата последнего изменения — и сохраните этот набор. Дальше выгрузка занимает минуту.

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

Шаг 2. Промпт, который разбирает поток на карточки

Главная ошибка здесь — просить «выдели задачи». Модель выдаст пересказ с глаголами: «обсудить смету», «разобраться с подрядчиком». Это не задачи, это темы. Задача обязана содержать четыре вещи: действие, исполнителя, срок, признак приёмки. Промпт должен требовать все четыре и честно помечать, чего в исходнике не было.

Ты разбираешь рабочий разговор на задачи.

Вход — расшифровка встречи (ниже, после строки ТЕКСТ).

Выдели все поручения. Для каждого верни строку таблицы:
| Задача (глагол + объект + результат) | Исполнитель | Срок | Как поймём, что готово |

Правила:
1. Формулируй задачу от действия: «Собрать смету по объекту №3 и отправить
   на согласование», а не «смета по объекту».
2. Если исполнитель прямо не назван — пиши НЕ НАЗВАН. Не угадывай.
3. Если срок не назван — пиши НЕ НАЗВАН. «Срочно», «на неделе», «побыстрее»
   считай НЕ НАЗВАН и вынеси в отдельный список «Требуют уточнения срока».
4. Признак готовности бери из текста. Если его нет — предложи свой вариант
   и пометь звёздочкой.
5. Не объединяй разные поручения в одно. Не добавляй задачи, которых
   не было в тексте.

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

ТЕКСТ:
[вставить расшифровку]

Пункты 2 и 3 — самые важные. Без них модель дорисует исполнителя по смыслу («это же по объектам, значит прораб») и поставит срок «до конца недели», потому что так звучит естественно. Вы получите красивую таблицу с выдуманными обязательствами, и хуже этого только отсутствие таблицы.

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

Шаг 3. Проверка формулировки перед отправкой

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

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

Задача: [вставить]

Ответь тремя блоками:
1. Как я понял, что от меня требуется (перескажи своими словами).
2. Что можно понять двояко — перечисли все места, где я мог бы сделать
   не то, что имел в виду постановщик.
3. Какие три вопроса я задам, прежде чем начать.

Не предлагай улучшений. Только покажи, где формулировка допускает
разное прочтение.

Я прогоняю через него задачи, которые уходят наружу: подрядчикам, смежным отделам, новым сотрудникам. Реальный пример из отделки: задача звучала «согласовать материалы по квартире на Ленинском». Модель в блоке 2 выдала — неясно, согласовать с клиентом или с закупкой, неясно, все материалы или только чистовые, неясно, что считается согласованием: устное «ок» или подписанная ведомость. Все три вопроса потом действительно возникли бы, только через четыре дня и по телефону.

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

Шаг 4. Ежедневная сводка по просрочкам

Это второе сломанное звено — проверка. Работает так: утром выгружаете CSV из трекера, кладёте в чат, получаете список того, куда надо вмешаться. Файл можно загружать прямо в ChatGPT, Claude и Gemini, в том числе на бесплатных тарифах, — но действуют ограничения на число и размер файлов, у ChatGPT — ещё и суточные, так что ежедневная выгрузка должна быть компактной.

Вход — выгрузка задач из трекера (файл прикреплён).
Колонки: название, исполнитель, срок, статус, дата последнего изменения.
Сегодня — [дата].

Сделай сводку для руководителя, четыре блока:

1. ПРОСРОЧЕНО. Задачи, где срок прошёл, а статус не «Выполнено».
   Отсортируй по величине просрочки, укажи: задача — исполнитель —
   просрочка N дней.
2. ЗАВИСЛО. Задачи в работе, где последнее изменение было более 3 дней
   назад, срок ещё не прошёл. Укажи, сколько дней нет движения.
3. ГОРИТ ЗАВТРА. Срок наступает в ближайшие 2 дня, статус не «Выполнено».
4. ПЕРЕГРУЗ. Исполнители, у которых больше 5 задач со сроком
   на этой неделе.

Считай только по данным из файла. Если данных для блока нет —
напиши «пусто», не придумывай.
Общий объём — не больше 20 строк.

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

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

Одна оговорка, которая сбивает многих: голый чат без настроенных коннекторов в ваш трекер не ходит — сам он статус не изменит. У ChatGPT есть Tasks — запланированные задания с уведомлениями, а у ChatGPT и Claude есть коннекторы к Notion, Asana, Linear, Atlassian, которые читают и меняют задачи, но их настраивают отдельно. Пуш конкретному исполнителю в любом случае шлёт трекер. Пока коннекторов нет, выгрузку приносите вы или ассистент, действия по итогам сводки делаете тоже вы. Автоматическую передачу данных настраивают отдельно: через готовые коннекторы вроде Zapier и Make или встроенные автоматизации трекера это часы работы, через интеграцию по API — отдельный проект. Браться имеет смысл, когда ручной контур уже работает месяц и вы точно знаете, какие поля вам нужны.

Шаг 5. Недельный разбор — что срывается систематически

Ежедневная сводка показывает симптомы. Раз в неделю полезно посмотреть на причины: одни и те же люди, одни и те же типы задач, одни и те же этапы.

Вход — выгрузки задач за последние 4 недели (файлы прикреплены).

Найди закономерности в срывах сроков:
1. Какие типы задач срываются чаще остальных. Сгруппируй по смыслу
   названий, укажи долю просроченных в каждой группе.
2. У кого из исполнителей доля просрочек выше средней по компании.
   Приводи числа: столько-то из стольких-то.
3. На каком этапе задачи чаще всего замирают — по статусам
   и датам изменений.
4. Задачи, которые переносились более одного раза, — списком.

Только то, что следует из данных. Не объясняй причины,
не давай советов. Выводы делаю я.

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

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

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

Подрядчики и контрагенты — отдельный контур

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

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

Вход: текущий реестр задач по подрядчику (файл) и переписка
за последнюю неделю (текст ниже).

1. Обнови статусы задач из реестра по тому, что сказано в переписке.
   Если по задаче ничего не сказано — статус не меняй, пометь
   «нет ответа N дней».
2. Добавь новые обязательства, которые подрядчик взял на себя
   в переписке: что обещал, к какому сроку, дословная цитата обещания.
3. Отдельно: обязательства, которые подрядчик перенёс или смягчил
   формулировку. Покажи было → стало.
4. Отдельно: что мы обещали подрядчику и не сделали.

Не интерпретируй, опирайся на текст. Где формулировка расплывчата —
так и пиши: «формулировка не даёт точного срока».

Четвёртый пункт добавляйте обязательно. В половине разборов выясняется, что срыв у подрядчика висит на нашей стороне — не отдали доступ, не согласовали образец, не перевели аванс. Модель находит это по переписке за секунды, а человек обычно видит только чужие долги.

Третий пункт — про подмену обязательств. «Сделаем к пятнице» превращается в «постараемся на следующей неделе», и переход никто не фиксирует. Сопоставление «было → стало» по цитатам снимает этот спор заранее.

Что сюда не грузить

Рабочие переписки и планёрки — это персональные данные сотрудников, суммы договоров, иногда данные клиентов. В ChatGPT на личных тарифах использование ваших разговоров для обучения моделей включено по умолчанию и выключается вручную в настройках приватности. В Claude согласие предвыбрано: экран выбора показывают при регистрации и при смене политики. Зайдите в настройки до первого прогона, а не после; пока вы этого не сделали, считайте, что переписка может использоваться для обучения.

Дальше — простая гигиена. Фамилии клиентов меняйте на «Клиент А», суммы округляйте до порядка величины или заменяйте на «сумма по договору», адреса объектов сокращайте до условного номера. Для постановки задач содержание не пострадает: модели всё равно, «Ленинский, 45» или «объект №3», ей нужна связь задачи с объектом, а не адрес.

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

Где ИИ не поможет

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

Он не расставит приоритеты. Смотрите врезку выше — это решение руководителя, и оно опирается на информацию, которую вы не выгружали в чат.

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

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

И последнее: модель уверенно ошибается. Она может приписать поручение не тому человеку, придумать срок, склеить две задачи в одну. Поэтому в промптах стоят запреты на угадывание и пометки НЕ НАЗВАН, а первые недели две прогоны стоит сверять с исходником выборочно. Через пару недель вы будете знать, где именно ваша модель врёт, и проверять только эти места.

С чего начать на этой неделе

Не внедряйте всё сразу — развалится. Возьмите одно звено.

Запишите ближайшую планёрку. Прогоните расшифровку через промпт из шага 2. Сравните таблицу с тем, что вы сами помните о встрече, — обычно там находится два-три поручения, которые вы бы потеряли. Этого хватает, чтобы понять, нужно вам это или нет.

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