Как ставить задачи разработчикам с помощью ИИ

Мы спросили сорок руководителей, какую рабочую задачу они хотели бы ускорить с помощью ИИ. Без вариантов ответа, без подсказок. Самый частый запрос – с большим отрывом – оказался не про красивые презентации и не про автоматизацию переписки. Снова и снова звучало одно и то же: помочь поставить задачу разработчикам.

Формулировки разные, боль одна. «Улучшить качество требований в постановках от аналитиков». «Ускорить составление ТЗ разработчикам». «Написать user stories по отрисованным аналитиком схемам». «Проверять описания задач перед передачей в разработку». «Составить тест-план по требованиям». «Стандартизировать постановки бизнес-аналитика». Менеджеры проектов, продакты, аналитики – все упёрлись в один и тот же барьер между «я понимаю, что нужно» и «команда поняла то же самое».

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

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

Почему ИИ действительно силён в постановке задач

Стоит разобрать механизм, иначе совет «используйте ИИ для ТЗ» останется лозунгом. Языковая модель хорошо делает одну вещь: берёт неструктурированный вход и приводит его к заданной форме. Три абзаца сырой мысли превращает в нумерованный список требований. Описание схемы – в набор user stories. Готовые требования – в тест-план с позитивными и негативными сценариями.

У менеджера или аналитика в голове обычно есть понимание, что нужно. Оно просто не оформлено: живёт в виде «ну, надо чтобы заявки важных типов как-то выделялись». Модель помогает выгрузить уже существующую мысль, разложить по полкам и проверить на полноту. ИИ закрывает трудоёмкую часть постановки – оформление, выравнивание формата, поиск пропущенных пунктов – а не творческую.

Вот тут начинается самое полезное. Большинство проблем с ТЗ в том, что в нём есть дыры, которых автор не заметил. Что происходит, если поле пустое? Кто видит эту кнопку, а кто нет? Что считать успешным результатом? Модель, которой запрещено додумывать, эти дыры подсвечивает. И часто список вопросов «а вы про это подумали?» полезнее самой структуры.

Есть и третья способность, менее очевидная – генерация граничных случаев. Спросите модель «какие сценарии ошибок и пустых состояний я мог пропустить в этой задаче», и она выдаст десяток вариантов, половина из которых к вашему случаю не относится, а вторая половина – именно то, что всплывёт в проде через месяц. Тестировщики называют это «негативными сценариями», и их пропуск – классическая причина переоткрытых задач.

Где ИИ подведёт, если ему довериться

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

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

Чтобы это не звучало абстрактно – вот что реально выдала модель на голую фразу «напиши ТЗ: нужен экспорт сделок в Excel», без единого ограничения. За один проход она дописала: лимит «50 000 или 100 000 строк», выгрузку «не дольше 10–20 секунд», хранение файла «24 часа в S3», около двадцати колонок (воронка, вероятность %, наблюдатели), REST-эндпоинты, имя файла с сегодняшней датой и даже выбор библиотеки. Выглядит как готовое ТЗ. Но ни одну из этих цифр и сущностей никто не задавал – модель их придумала, уверенно и правдоподобно. Команда возьмёт это как факт и завяжет спринт на ограничениях, которых бизнес не просил. Опасна именно уверенность тона: выдуманный пункт неотличим от настоящего. Подробнее про этот механизм – в разборе почему ИИ уверенно выдаёт правдоподобную чушь.

Рабочий принцип звучит иначе: ИИ структурирует то, что дал ему человек, и честно говорит, чего не хватает. Разница – в одном правиле промпта: запретить додумывать и дать модели легальный способ сказать «не знаю». Когда данных не хватает – не угадывай, а вынеси вопрос в отдельный список. Тогда на выходе вместо выдумки вы получаете перечень того, что надо уточнить у заказчика. Это самый ценный артефакт всего процесса.

Есть и вторая граница, не техническая, а организационная. Всё, что вы вставляете в публичную модель, уходит на чужие серверы. Реальные данные клиентов, внутреннюю логику, доступы, номера договоров в промпт класть не стоит – обобщите до уровня типа («заявка определённого типа», «поле с суммой»), а конкретику держите при себе. Если в компании есть свой контур с моделью или корпоративная подписка с гарантией неиспользования данных – проверьте условия прежде, чем грузить туда боевые требования.

Отсюда простое правило: часть задач лучше вообще не отдавать модели.

Где ИИ не помощник, а риск – делайте руками:

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

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

Рабочий процесс: от размытого запроса до тест-плана

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

Ядро процесса – два шага. Первый: размытый запрос превращается в структурированное ТЗ. На входе фраза заказчика или ваша заметка, на выходе – постановка с целью, требованиями, критериями приёмки и, главное, списком открытых вопросов. Второй: скептический ревью – ТЗ прогоняется через модель в роли въедливого техлида, который не хочет потратить спринт впустую. Её задача не залатать, а подсветить: двусмысленности, непроверяемые критерии, пропущенные сценарии.

Соблазн – взять результат первого шага и сразу отдать в работу. Но ценность именно в том, что второй шаг атакует первый: один проход даёт черновик, два прохода – черновик, переживший оппонирование. Это тот самый момент «перед публикацией», который один из руководителей описал как мечту. Ниже мы пройдём оба шага на сквозном примере.

Рядом с ядром есть отдельная ветка для аналитиков: если на входе не текст заказчика, а описание схемы или макета, первый шаг заменяется на генерацию user stories. Это альтернативный вход, а не продолжение ТЗ.

А из уже готового ТЗ вырастают два производных артефакта, каждый своим промптом, и порядок между ними не жёсткий – берите тот, что нужен сейчас:

• декомпозиция и грубая оценка – разбивка на задачи спринта с зависимостями и размером;
• тест-план – позитивные, негативные и граничные проверки, выведенные из критериев приёмки.

Контекст один раз: чтобы модель не выдумывала ваш домен

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

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

1
2
3
4
5
6

Контекст продукта (вставляю в начало диалога):
– Продукт: <что это, для кого>.
– Роли и права: <кто что видит и может>.
– Жёсткие ограничения: <регуляторные, технические, бизнесовые>.
– Термины: <ваш словарь: что значит «заявка», «согласование»...>.
– Известные грабли: <на чём ломались прошлые релизы>.

Этот блок закрывает ровно ту дыру, из-за которой ИИ опасен в постановке. С ним список открытых вопросов становится короче и точнее: модель перестаёт спрашивать очевидное и выдумывать ограничения, которые вы и так знаете.

Если вы работаете не в чате, а через агента в среде разработки – OpenCode или Claude Code – этот же блок удобно положить в файл AGENTS.md в корне проекта. Агент подхватывает его автоматически в начале каждой сессии, и контекст не нужно вставлять руками каждый раз. По сути AGENTS.md – это постоянная память о вашем домене, к которой агент обращается на любой задаче. Про то, из чего вообще складывается рабочий агент, есть отдельный разбор – «AI-агент – это не промпт».

Промпт 1: размытый запрос в ТЗ с критериями приёмки

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

Обратите внимание на пример внутри скобок – это слегка обобщённая реальная формулировка из ответов руководителей. Заказчик описал боль, а не решение: «заявки теряются из фокуса». Хорошая постановка начинается с того, чтобы вытащить эту боль в пункт «Цель», а не сразу прыгнуть к «выделить цветом». Модель с таким промптом как раз и помогает не перепутать симптом с задачей.

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

Промпт 2: ревью готового ТЗ глазами скептичного техлида

Второй проход важнее первого. Структуру модель собирает почти всегда нормально, а вот найти в ней дыры до того, как их найдёт команда в середине спринта, – это и есть экономия времени.

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

В примере выше дефекты зашиты намеренно: «Экспорт должен работать быстро» без цифры и «Файл содержит все нужные данные» без определения, какие данные нужны – это ровно те непроверяемые формулировки, ловить которые техлид и обязан. Запустите промпт и проверьте: модель назвала именно их? Если да – вы только что увидели на учебном примере, как процесс ловит расплывчатый критерий до того, как он съест спринт.

Как это выглядит вживую: от запроса до проверенного ТЗ

Чтобы промпты стали процессом, а не набором островов, пройдём ядро насквозь – от фразы заказчика до проверенного ТЗ. Берём ту же фразу из Промпта 1 про выделение важных заявок.

Все примеры ниже – не выдуманные «как могло бы быть», а реальные ответы модели (gpt-5.4-nano) на этих промптах, слегка сокращённые.

Шаг 1. Промпт 1 разворачивает фразу в черновик ТЗ

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

Требования: 1) выделять чаты заявок цветом по типу, чтобы отметить их как «важные».

Критерии приёмки: недостаточно данных для однозначного формулирования.

Открытые вопросы: что значит «по типу» и откуда берётся тип? кто ставит признак «важная» – правило или вручную? какой цвет и как он применяется (строка, фон, значок)? видно всем операторам или одному? как это сочетается с существующими статусами?

Главное: модель НЕ выдумала ни цвет, ни состав «важных» типов – всё, чего не было во фразе, ушло в открытые вопросы, а в критериях приёмки она честно написала «недостаточно данных». Это и есть результат запрета на додумывание.

Реальная развилка. Ту же фразу мы прогнали и через вторую модель (deepseek). Она повела себя иначе: сама дописала требование «тип зависит от статуса заявки» и сформулировала критерии приёмки, которых заказчик не давал. Один и тот же промпт, разные модели – и одна выдумывает там, где другая спрашивает. Вот почему запрет на додумывание в промпте обязателен, а результат всё равно надо перечитывать.

Шаг 2. Вы закрываете открытые вопросы

Часть знаете сами, часть уносите заказчику. Допустим: пометку ставит оператор вручную; она снимается автоматически после ответа клиента, но оператор может снять её и раньше; видна только этому оператору; «важная» – новый флаг поверх статусов; помечать можно несколько; «выделять» = цветная плашка плюс закрепление важных выше непомеченных, но общий порядок остальных заявок при этом не перестраивается; помеченные видны сразу при открытии списка; а в экспорт списка пометка не попадает. Возвращаете ответы той же сессии: «вот ответы, перепиши ТЗ с их учётом».

Шаг 3. Промпт 2 атакует переписанный ТЗ

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

Шаг 4. Финальный ТЗ

Вы дописываете ответы на вопросы техлида – и модель собирает финальную версию: превращает ответы в проверяемые критерии и оставляет в открытых вопросах то, что всё ещё не решено (палитра, scope «закрепления», пик нагрузки). Эту версию уже можно копировать и передавать дальше – в декомпозицию и тест-план:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Цель: в общем списке чатов оператора заявки важного типа заметны сразу и не теряются из‑за подъёма карточек от ботов.
Требования:
1. «Важная» – отдельный флаг поверх статусов (не заменяет их); ставит и снимает его оператор вручную, помечать можно несколько заявок.
2. Помеченная заявка выделяется цветной плашкой и закрепляется выше непомеченных.
3. Пометка снимается автоматически после ответа клиента, если оператор не снял её раньше.
4. Закрепление важных не меняет общий механизм подъёма и сортировки остальных заявок.
5. Пометку видит только тот оператор, который её поставил.
6. При экспорте списка пометка в выгрузку не попадает.
Критерии приёмки:
– при заявке без пометки, когда оператор помечает её важной, то строка выделяется цветной плашкой и закрепляется выше непомеченных;
– при помеченной заявке, в которой ещё не было ответа клиента, когда клиент отвечает, то пометка снимается автоматически и выделение исчезает;
– при помеченной заявке, когда оператор снимает пометку вручную, то выделение исчезает и заявка возвращается в обычный порядок;
– при заявке, помеченной другим оператором, когда список открывает текущий оператор, то этого выделения он не видит;
– при экспорте списка, когда формируется выгрузка, то пометка «важная» в неё не включается.
Что не входит: автопростановка пометки по правилам; выбор и настройка цвета плашки оператором.
Открытые вопросы: палитра и тема (светлая/тёмная, контраст); scope «закрепления выше» (в пределах текущей страницы или всей выдачи); пиковый размер списка и SLA на отрисовку.

Разница между «отдал черновик в спринт» и «отдал то, что уже проверено» – и есть весь смысл процесса.

Промпт 3: user stories по описанию схемы аналитика

Отдельный запрос из ответов звучал так: «написание user stories по отрисованным аналитиком схемам». Современные модели уже умеют читать картинку – макет или схему можно приложить файлом, и модель разберёт развилки сама. Но описание схемы словами работает не хуже и держит вас в управлении: вы проговариваете логику, которую и так держите в голове, и сразу видите, где модель могла понять иначе. А если макет лежит в закрытой системе или содержит чувствительные данные, словесное описание ещё и безопаснее.

Тот же принцип, что и в первых двух: модель структурирует ваш вход и честно отделяет то, что вы сказали, от того, чего не хватает. А тест-план – отдельный частый запрос из ответов руководителей, и он заслуживает не одной фразы: ему посвящён отдельный промпт ниже.

Промпт 4: декомпозиция и черновая оценка

Структурированное ТЗ – это ещё не план работ. Большую постановку нужно разбить на куски, которые команда возьмёт в спринт, прикинуть порядок и увидеть риски. Это та часть, где менеджеры тонут вручную, а модель хорошо собирает первый черновик – при условии, что оценку вы воспринимаете как гипотезу для разговора с командой, а не как обязательство.

Замените шкалу размеров в промпте на принятую в вашей команде перед запуском – иначе модель будет мерить чужой линейкой.

Привязка к команде здесь критична: без неё «L» ничего не значит, это просто буква. Договоритесь о шкале один раз, держите её в блоке контекста – и прикидка станет пригодной для планирования. Но даже с привязкой оценка остаётся грубой и обманчиво уверенной на вид: это вход в разговор с командой, а не замена ему. Зато перечень «забытых» технических задач – миграции, права, логи – часто ловит именно то, что потом всплывает как «мы не заложили это в спринт».

На финальном ТЗ из примера выше модель разбила работу так (фрагмент реального ответа): «Отображение флага в строке чата – M, зависит от контракта API»; «Автоснятие по событию ответа клиента – L, риск: единого события „ответ клиента“ может не быть»; и отдельным списком – забытые технические задачи: миграции (флаг, владелец, срок жизни), права доступа, логирование, обработка ошибок. Самый крупный риск она пометила сама.

Декомпозиция и оценка сроков – это уже не про постановку одной задачи, а про управление проектом целиком. Именно с этого начинается специализация «Проектное управление».

Промпт 5: тест-план из критериев приёмки

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

Заметьте привязку каждой проверки к критерию приёмки – это способ увидеть дыры с другой стороны. Если для критерия не нашлось проверки или, наоборот, проверка не сводится ни к одному критерию, значит, ТЗ неполное. Тест-план так работает как ещё один проход ревью, только под другим углом.

На том же ТЗ модель собрала проверки и привязала каждую к критерию приёмки (фрагмент): позитивные – «поставил пометку -> плашка и закрепление, КА1»; негативные – «другой оператор не видит чужую пометку, КА4», «экспорт без пометки, КА5»; граничные – «5–10 тысяч чатов, часть помечена -> без деградации». А непроверяемое честно вынесла в «надо уточнить»: точная механика «закрепления», палитра, порог нагрузки.

Кстати, похожий подход работает и в смежных задачах. Если вы ускоряете разбор клиентских обращений или готовите конкурентный анализ – принцип «структурируй вход, выноси пробелы в вопросы» работает одинаково.

Чек-лист готовности постановки

Прежде чем отдавать ТЗ в работу, прогоните его по короткому списку – это «definition of ready» в облегчённом виде. Постановка готова, если:

• цель описывает проблему пользователя, а не решение;
• каждый критерий приёмки можно однозначно проверить (есть предусловие, действие, результат);
• открытые вопросы закрыты или явно зафиксированы как риск;
• учтены нефункциональные требования: скорость, доступы, безопасность;
• явно сказано, что НЕ входит в задачу;
• крупные куски разбиты так, что каждый можно закончить и проверить отдельно.

Это «вход». На «выходе» работает зеркальный список – definition of done, то есть что вообще значит «задача готова». Его тоже стоит зафиксировать один раз для команды, а не сочинять под каждую задачу: код прошёл ревью, автотесты на критерии приёмки зелёные, проверены негативные и граничные сценарии из тест-плана, обновлена документация, задача показана на демо. Значительная часть «возвращённых» задач – это не дыра в постановке, а отсутствие общего понимания, когда работу можно считать законченной.

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

• Что здесь модель видеть не могла? Любая цифра, срок, имя роли или ограничение, которых не было в вашем входе, – кандидат на выдумку.
• Какой пункт я не могу проверить сам за минуту? Именно его надо унести к заказчику или в код, а не принимать на веру.
• Где звучит слишком гладко? Уверенная формулировка без единого «нужно уточнить» – повод насторожиться, а не обрадоваться.

Если хотите понять, помогает ли вам ИИ на самом деле, следите за двумя цифрами до и после: сколько раз задачу возвращают на уточнение после передачи в разработку и сколько задач переоткрывают из-за пропущенного сценария. Падают оба числа – процесс работает, а не просто ощущается продуктивным.

Что отличает случайную удачу от стабильного результата

Эти промпты можно скопировать и получить пользу сразу. Но между «один раз сработало» и «работает стабильно» есть навык, который не появляется сам от факта установки приложения.

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

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

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

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

Главное про постановку задач

Постановка задач разработчикам оказалась запросом номер один у реальных руководителей – и это здравый выбор. Языковые модели действительно сильны там, где надо взять неоформленную мысль и привести к структуре: ТЗ, user stories, критерии приёмки, тест-планы. Аудитория интуитивно нащупала задачу, на которой ИИ ускоряет работу надёжнее всего.

Граница успеха проходит по одному правилу: модель структурирует ваш вход, но не должна додумывать. Запретите выдумку, дайте легальное «не знаю» – и список открытых вопросов станет ценнее самого ТЗ. Два прохода вместо одного – собрать и атаковать – закрывают ту самую боль про качество требований перед передачей в разработку.

Промпт можно скопировать за минуту, а вот калибровку доверия – нет. Где дать контекст, что проверять обязательно, где честно остановиться и спросить человека вместо модели. Это навык, и он отделяет менеджера, который один раз получил красивое ТЗ, от менеджера, у которого ИИ стабильно ускоряет постановку каждую неделю. Вопрос к вам – какая ваша регулярная задача первой пойдёт через этот процесс?

Другие части серии

Часть 1

Чего менеджеры хотят от ИИ: данные 40 реальных ответов

Часть 3

Автоматизация отчётов и статусов с ИИ: рабочий цикл

Часть 4

Анализ конкурентов с ИИ: где модель выдумывает факты

Часть 5

AI для входящих запросов клиентов: −50% времени ответа

Часть 6

Агентский ресёрч конкурентов: цикл с поиском и проверкой