IniCode

Как составить ТЗ на парсер: гайд для заказчика

9 мин чтенияРазработка парсеров

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

Зачем вообще ТЗ, если «просто собрать цены»

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

Хорошая новость: ТЗ на парсер — это одна-две страницы. Плохая: эти страницы придётся написать вам, потому что только вы знаете, какие данные и зачем нужны бизнесу. Разработчик поможет с техническими развилками, но цель и состав данных — ваша зона.

Семь блоков хорошего ТЗ

1. Цель: зачем вам эти данные

Одно предложение, которое сэкономит больше всего денег: «мониторим цены конкурентов, чтобы держать свои в рынке», «собираем базу объявлений для оценки спроса», «следим за отзывами на наши товары». Зная цель, инженер предложит, что собирать, а что — лишнее. Без цели вам напарсят «всё» — заплатите за данные, которые никто не откроет.

2. Источники: откуда собирать

Конкретные адреса, а не «с маркетплейсов». Для каждого источника:

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

Важный момент: у некоторых площадок есть официальные API — если задача решается через них, это стабильнее и дешевле в поддержке. Хороший подрядчик проверит это первым делом; упомяните в ТЗ, есть ли у вас доступы (например, API личного кабинета поставщика на маркетплейсе).

3. Поля: что именно собирать

Таблица «поле — пример значения — обязательность». Например: название товара, цена, старая цена, наличие, рейтинг, количество отзывов, продавец, ссылка, артикул. Чем точнее список, тем точнее смета. Отдельно пометьте:

  • поля, которые появляются не всегда (скидочная цена);
  • поля, требующие вычислений (цена за единицу веса);
  • «хотелки на потом» — их лучше знать заранее из-за архитектуры.

4. Частота и объём

Разовая выгрузка, ежедневный сбор в 6 утра или мониторинг каждые 15 минут — три разных проекта. Пишите: сколько страниц/товаров (порядок: сотни, тысячи, сотни тысяч), как часто обновлять, нужна ли история изменений (динамика цены по дням — частая и ценная опция).

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

5. Формат выгрузки: куда складывать

Варианты по возрастанию сложности: файл CSV/Excel по запросу → автообновляемая Google-таблица → база данных → API для ваших систем → готовый дашборд. Большинству достаточно Google-таблицы: она бесплатна, привычна и подключается к BI. Если данные должны попадать в вашу CRM или систему автоматизации — напишите, в какую и есть ли у неё API.

6. Правовые рамки

Пункт, который отличает взрослое ТЗ. Зафиксируйте:

  • собираем только публичные данные (без авторизации и обхода платного доступа);
  • персональные данные не собираем — имена, телефоны, адреса физлиц под 152-ФЗ, и «спарсить контакты» — это не к добросовестным подрядчикам;
  • нагрузка на источник — щадящая (разумные интервалы запросов, ночные окна).

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

7. Поддержка: что делать, когда источник изменится

Не «если», а «когда»: сайты обновляют вёрстку, включают защиту, переезжают. В ТЗ должен быть ответ:

  • как парсер сообщает о проблеме (алерт в Telegram лучше, чем тишина и пустая таблица);
  • кто и в какой срок чинит (входит в поддержку / оплачивается по часам);
  • есть ли мониторинг качества данных (упало количество товаров вдвое — сигнал, даже если формально «всё работает»).

Развилки, о которых спросит (хороший) подрядчик

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

Дедупликация и нормализация. Один товар в трёх категориях — одна запись или три? «1 499 ₽», «1499 руб.» и «1.499,00» — привести к числу? Мелочи, из которых состоит качество данных.

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

Что считать успехом. Пропишите приёмку: «95%+ товаров категории собираются ежедневно, расхождение цен с ручной проверкой — не более 1%». Без критериев приёмка превращается в спор о вкусах.

Красные флаги при выборе исполнителя

  • Оценка «за час сделаю» без вопросов про объём и защиту источника.
  • Нежелание обсуждать правовые рамки.
  • Парсер «в чёрном ящике»: без кода, документации и передачи вам — завтра этот человек пропадёт, и вы останетесь с пустой таблицей (проверено десятками обращений на реанимацию проектов).
  • Обещание «обойдём любую защиту» — уверенное вторжение в серую зону, где рискуете вы, а не исполнитель.

Шаблон ТЗ — копируйте и заполняйте

1. Цель: [зачем данные бизнесу, одним предложением]
2. Источники: [ссылки на разделы; нужен ли обход карточек]
3. Поля: [таблица: поле — пример — обязательность]
4. Объём: [~сколько записей за проход]
5. Частота: [разово / ежедневно в HH:MM / каждые N минут]
6. История: [нужна динамика изменений? да/нет]
7. Выгрузка: [CSV / Google Sheets / БД / API / дашборд]
8. Правовое: только публичные данные, без ПДн,
   щадящая нагрузка на источник
9. Алерты: [куда сообщать о сбоях — Telegram/email]
10. Поддержка: [ожидания по срокам починки при изменении источника]
11. Приёмка: [критерии полноты и точности данных]

Десять минут на заполнение — и вместо «ну, от 20 до 200 тысяч, надо смотреть» вы получите нормальную смету. По нашей практике, точную оценку по такому ТЗ можно дать за считаные часы: типовой парсер одного источника стартует от 3 дней работы, система с несколькими источниками, историей и дашбордом — от пары недель.

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

Можно без ТЗ, просто на созвоне рассказать? Можно — мы сами так собираем половину вводных. Но письменная фиксация появится всё равно: без неё смету не зафиксировать. Разница в том, потратите вы десять минут до оценки или день переписки после.

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

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

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

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

Нужно ли где-то регистрировать сбор данных? Для публичных коммерческих данных без ПДн — нет. Но если данные соприкасаются с персональными (например, отзывы с именами) — это уже зона 152-ФЗ, и постановку стоит скорректировать: как правило, имена просто не нужны для бизнес-задачи, и мы их не собираем.

Готовое ТЗ — пришлите нам: за 24 часа вернём фикс-смету со стоимостью, сроком и планом. ТЗ нет — приходите с целью и ссылкой на источник, остальное соберём вместе на брифе, бесплатно.

Посчитаем вашу задачу — бесплатно и за 24 часа

Опишите проект своими словами — пришлём фикс-смету: точную стоимость, срок и план работ. Смета не растёт после старта.