Разработка парсера начинается не с выбора библиотеки и не со списка страниц. Сначала нужен проверяемый договор о том, какое решение поддержат данные, что именно наблюдать, как принять результат и кто будет разбирать изменения после запуска.
Ниже — ровно одиннадцать вопросов для такого ТЗ. Каждая карточка содержит практический смысл, ожидаемую вводную, доказательство приёмки, ответственные роли и нерешённый риск.
Краткая навигация:
- бизнес-решение
- источники и доступ
- сущности и поля
- условия наблюдения
- сопоставление
- частота и история
- принятый результат
- ошибки и изменения
- структура передачи
- поддержка
- тестовая выборка
1. Какое бизнес-решение должны поддерживать данные?
- Зачем: сбор нельзя принимать только по числу заполненных строк; требуется разрешённая задача и понятный пользователь результата.
- Что передать: название решения, роль пользователя, допустимое действие и требуемый выходной файл или набор полей.
- Чем подтвердить: карточкой требования, где зафиксированы решение, пользователь, граница действия и наблюдаемый результат.
- Кто отвечает: бизнес-владелец со стороны заказчика и владелец передачи данных со стороны исполнения.
- Что ещё не решено: слишком широкую формулировку нужно сузить до проверяемого использования; данные сами по себе не обещают бизнес-результат.
2. Какие источники и состояния доступа входят в задачу?
- Зачем: название класса источника не подтверждает доступность конкретной страницы, поля или согласованного состояния доступа.
- Что передать: выбранные классы и названия источников, наблюдаемое состояние доступа, роль владельца условий и контрольные примеры.
- Чем подтвердить: результатом ограниченной выборки с источником, датой, состоянием и ссылкой на доказательство.
- Кто отвечает: владелец источника или условий со стороны заказчика и технический владелец проверки.
- Что ещё не решено: источник может оказаться недоступным или не показывать требуемое поле; это остаётся риском, а не обещанием поддержки.
Выбор технологии — соседняя задача. После фиксации источника можно отдельно выбрать между API, веб-сбором и файлом.
3. Какие сущности и точные поля нужны?
- Зачем: слова «товар» и «цена» недостаточны для схемы, если не определены карточка, продавец, источник, регион и момент наблюдения.
- Что передать: версионированный словарь сущностей и полей с типом, обязательностью, условием заполнения и состоянием отсутствия.
- Чем подтвердить: тестовой строкой, которая сохраняет согласованные типы и явные пустые значения.
- Кто отвечает: владелец данных и владелец схемы.
- Что ещё не решено: условное поле может не присутствовать в выбранном источнике и не должно быть выдумано.
Для задачи мониторинга цен структура исходных данных разбирается отдельно в материале спецификация мониторинга цен конкурентов. Здесь важен общий контракт сущностей, а не продуктовая инструкция.
4. Какие регионы, продавцы и условия наблюдения важны?
- Зачем: значения из разных регионов, карточек, продавцов или ценовых условий нельзя незаметно смешивать.
- Что передать: регион, отображаемого продавца или карточку, тип опубликованного значения, промоусловие и правило времени проверки.
- Чем подтвердить: строкой наблюдения, где каждый согласованный контекст записан вместе с доказательством.
- Кто отвечает: владелец коммерческого контекста и оператор источника.
- Что ещё не решено: часть контекста может не раскрываться источником; такое состояние фиксируется явно.
5. Как сопоставлять товары и спорные записи?
- Зачем: аналог, вариант и точное совпадение поддерживают разные выводы; неоднозначность нельзя скрывать.
- Что передать: ключ сопоставления, правила для точного совпадения, варианта и аналога, а также обработку неоднозначных и несопоставленных записей.
- Чем подтвердить: набором разобранных примеров, включая два правдоподобных кандидата без принудительного выбора.
- Кто отвечает: владелец каталога и проверяющий сопоставление.
- Что ещё не решено: недостающий различающий атрибут остаётся открытым риском до решения владельца каталога.
Учебный пример. Для вымышленного товара остаются два кандидата. Статус записи — ambiguous_match, следующее действие — запросить различающий атрибут.
6. Какая частота и история действительно нужны?
- Зачем: неопределённое «регулярно» не задаёт ни окно наблюдения, ни историю, ни ответственность.
- Что передать: проектный ритм или окно, границу истории, часовой пояс, поле времени проверки и владельца решения.
- Чем подтвердить: версией расписания и тестовым наблюдением с явным временем проверки.
- Кто отвечает: операционный владелец и владелец расписания.
- Что ещё не решено: требуемый ритм может не совпасть с подтверждённой возможностью выбранного источника; универсального SLA нет.
7. Что считается принятым результатом?
- Зачем: приёмка должна быть наблюдаемой и не превращать пропуски в корректные значения.
- Что передать: обязательные поля, проверки типов, границу сопоставления, допустимые состояния отсутствия и правило доказательства.
- Чем подтвердить: матрицей приёмки и тестовыми строками для готового результата и исключений.
- Кто отвечает: владелец приёмки и проверяющий качество.
- Что ещё не решено: граница готовых данных требует одобрения владельца и не выводится из одного успешного примера.
Учебный пример. У одной строки условное поле не опубликовано. Значение остаётся пустым со статусом not_available; оно не заменяется нулём.
8. Что делать с ошибками и изменениями источника?
- Зачем: без класса, владельца и следующего действия исключение легко потерять или ошибочно принять за готовую строку.
- Что передать: классы исключений, ответственные роли, действия, условия следующей проверки и основания для повторной валидации.
- Чем подтвердить: записью журнала с объяснением, действием, владельцем и проверяемым условием возврата.
- Кто отвечает: владелец источника и оператор источника.
- Что ещё не решено: результат повторной проверки и срок восстановления не предполагаются заранее.
Учебный пример. Если вымышленная карточка недоступна, наблюдаемые поля остаются пустыми, открывается исключение, а повторная проверка выполняется только по согласованному проектному правилу.
9. Куда и в какой структуре передавать данные?
- Зачем: одинаковые названия колонок не гарантируют одинаковые типы, состояния пустых значений и совместимость версий.
- Что передать: один согласованный Excel или CSV, версию схемы, типы колонок и правила для пустых значений.
- Чем подтвердить: тестовым файлом, который открывается и сохраняет утверждённые типы и явные пустые значения.
- Кто отвечает: владелец интеграции и владелец схемы.
- Что ещё не решено: API, SFTP, хранилище или другая интеграция требуют отдельной границы.
Учебный пример. В одной строке тип колонки изменился относительно утверждённой схемы. Передача блокируется до новой версии, одобрения владельца схемы и повторной проверки затронутых строк.
10. Кто отвечает за поддержку и изменения после запуска?
- Зачем: запуск без владельцев переносит нерешённые обязанности в эксплуатацию.
- Что передать: ролевую матрицу для доступа, поддержки источников, каталога и сопоставления, схемы, расписания, исключений, секретов, интеграции, изменений и коммуникации.
- Чем подтвердить: решением по каждой обязанности: внутренний владелец, управляемая ответственность, совместная граница или остановка до уточнения.
- Кто отвечает: владелец продукта и владелец передачи.
- Что ещё не решено: любая строка без владельца остаётся блокирующим разрывом.
Для выявления таких разрывов составьте ролевую матрицу: по каждой обязанности укажите владельца и границу ответственности.
11. Что должна доказать тестовая выборка?
- Зачем: пилот должен завершаться решением, а не только демонстрацией нескольких заполненных строк.
- Что передать: проверенные источники, товары, поля и условия, подтверждённые и недоступные случаи, исключения, открытые риски и тестовый выходной файл.
- Чем подтвердить: записью с решением
go,reviseилиstopи ссылками на доказательства. - Кто отвечает: спонсор проекта и владелец приёмки.
- Что ещё не решено: открытые риски могут потребовать изменения границы и повторной проверки только затронутых требований.
Учебный пример. Пилот заканчивается решением revise: схема требует одобрения, а владелец расписания ещё не определён. Запись не задаёт универсального размера выборки, процента приёмки или срока запуска.
Использование ответов
Сведите карточки в одну версию ТЗ. Если источник, поле, сопоставление, владелец или доказательство остаются неизвестными, сохраните этот статус, а не маскируйте его общей формулировкой. Выборка должна проверить спорные места и привести к явному решению о следующем шаге.
Проверить ТЗ на небольшой выборке — передайте источники, поля, контрольные примеры и ожидаемую структуру. Такая проверка уточняет границу задачи, но не обещает поддержку любого источника или заранее заданный результат.
Применить к вашей задаче
Нужны регулярные данные, а не разовая выгрузка?
Покажите список товаров и источников. Проверим доступность данных и предложим структуру первого теста.
