Концепция Lost&Found

Lost&Found – платформа поиска потерянных вещей и домашних животных.

Бизнес-требования

1. Описание проблемы

Проблема

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

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

Сейчас поиск и возврат чаще всего происходят через набор несвязанных площадок: локальные чаты, сообщества, доски объявлений, сайты, а также отдельные бюро находок у организаций (транспорт, торговые центры, другие учреждения). Эти источники не объединены в единое пространство и редко предоставляют удобные инструменты для поиска по местоположению и времени, из-за чего пользователи тратят много времени на ручной просмотр ленты и повторяющиеся публикации в разных местах. Для животных дополнительно значимы скорость распространения информации и возможность привязывать наблюдения к местоположению, чтобы сузить зону поиска.

Отдельный важный аспект – безопасность. При публикации объявлений о находке люди не готовы указывать точное место хранения вещи или раскрывать личные контакты из-за риска передачи находки постороннему лицу. В результате информация часто публикуется неполно или не публикуется вовсе.

Потребности и боли

• Разрозненность информации. Объявления и сообщения находятся в разных каналах и не объединяются в один поиск.

• Низкая сопоставимость. Нет единого формата и структурных полей (где/когда/приметы), из-за чего совпадения приходится искать вручную.

• Слабая привязка к месту и времени. У людей не получается нормально искать в определенном радиусе и по интервалу времени, а без этого вероятность совпадений падает.

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

Текущие альтернативы

• Бюро находок транспорта и инфраструктуры: метро/московский транспорт, РЖД, аэропорты – у каждого свой сайт/канал и свои правила обращения.

• Сервисы по поиску животных: Pet911, mos.ru – помогают именно с животными.

• Группы “нашёл/потерял” в VK и Telegram – публикации в сообществах и чатах.

• Сайты объявлений – объявления о находках/пропажах как обычные публикации.

Почему текущие решения недостаточны

• Нет единой карты и нормальных фильтров: в большинстве решений нельзя удобно искать по району/радиусу и по времени.

• Сервисы организаций работают только в своих границах: бюро находок транспорта/аэропортов/ТЦ покрывают только свой объект и не объединяют данные между собой.

• Pet911 и mos.ru не закрывают вещи и документы: это отдельная ниша, которая не решает проблему потерянных предметов.

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

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

2. Целевая аудитория

Сегменты аудитории

1. Люди, потерявшие вещь или домашнее животное. Пользователи, которые размещают объявления о пропаже и ищут совпадения. Это ключевой сегмент для оценки ценности MVP: по нему измеряется, насколько быстро находятся релевантные объявления и как часто ситуации доходят до закрытия.

2. Люди, обнаружившие находку или заметившие животное. Пользователи, которые публикуют информацию о находке или наблюдении. Это второй ключевой сегмент MVP, именно он формирует вторую сторону, от которой зависит количество совпадений и скорость откликов.

3. Организации, работающие с находками (приюты, службы отлова, бюро находок при транспортных компаниях, торговых центрах и учреждениях). Могут использовать платформу для размещения информации о находках в рамках стандартного пользовательского функционала. В следующих версиях рассматриваются как сегмент для масштабирования и повышения доверия, будут отдельные сценарии для организаций и интеграции позволят увеличить объём официальных находок и ускорить возврат.

Потребности и ожидания

Потерявшие

Ожидают, что платформа позволит:

• разместить информацию о пропаже в понятной и структурированной форме;

• находить объявления о находках по месту и времени;

• получить отклик через систему без необходимости публиковать личный номер телефона в открытом доступе;

• понимать, находится ли объявление в активном статусе.

Нашедшие

Ожидают, что платформа позволит:

• опубликовать информацию о находке без необходимости размещать её в нескольких источниках;

• общаться с потенциальным владельцем через систему, не раскрывая личные контакты публично;

• передать находку человеку, который сможет подтвердить, что это его вещь;

• завершить публикацию после передачи находки.

Организации (приюты, бюро находок)

Ожидают, что платформа позволит:

• размещать информацию о находках в стандартизированном формате;

• получать обращения от владельцев через систему;

• фиксировать факт передачи находки и закрывать объявление.

3. Стейкхолдеры

Ключевые стейкхолдеры

1. Заказчик или инициатор проекта Определяет цели продукта и финансирование.

2. Пользователи Формируют основной контент и определяют ценность системы.

3. Организации-партнёры (приюты, транспортные компании, ТЦ) Потенциальные источники официальной информации о находках и партнёры по интеграции. В MVP организации могут размещать объявления как обычные пользователи; отдельные кабинеты и интеграции предусмотрены в следующих версиях (см. раздел 8).

4. Команда разработки (аналитик, разработчики, дизайнер) Отвечает за реализацию и развитие продукта.

Роль стейкхолдеров

Таблица 3-1 – Приоритет стейкхолдеров

Стейкхолдер	Приоритет при конфликте требований	Что делает	Как влияет на систему и решения
Заказчик / Инициатор	1 (решающий голос)	Утверждает цели, бюджет, сроки, границы MVP.	Определяет KPI и приоритеты, принимает финальные решения.
Пользователи (потерявшие / нашедшие)	2 (ключевые для ценности)	Публикуют объявления, ищут, откликаются, общаются, закрывают объявления, дают обратную связь о продукте.	Формируют контент и объявления, влияют на метрики (активность, скорость отклика, доля закрытий) и на развитие через обратную связь.
Организации-партнёры (приюты, транспорт, ТЦ)	3 (усиливают доверие и масштаб)	В MVP размещают объявления вручную, как обычные пользователи, позже смогут через кабинеты или интеграции.	Повышают охват и доверие, дают официальные источники, их требования учитываются, но не должны расширять MVP за рамки согласованного.
Команда разработки (аналитик, разработчик, дизайнер)	4 (влияют через реализацию)	Проектируют, разрабатывают, тестируют, выпускают продукт.	Влияют на решения через оценки сроков, стоимости, рисков, технических ограничений и качества реализации.

4. Бизнес-цели и ключевые метрики

Основные бизнес-цели

Бизнес-цели проекта сформулированы с учётом принципов SMART и направлены на подтверждение ценности платформы для пользователей.

Цель 1. Запустить и закрепить активное использование платформы в Москве

В течение первых 6 месяцев после запуска получить не менее 500 активных объявлений в месяц по Москве. Москва выбрана как главный город, будет проще достичь активности и собрать обратную связь. Как влияет система: удобная форма публикации, карта, фильтры и поиск, которые помогают легко искать и повышают количество публикаций.

Цель 2. Достичь высокой доли успешных возвратов

Достичь доли закрытых объявлений (вещь возвращена / животное найдено) не менее 15% в течение первых 6 месяцев работы. Этот показатель покажет, что платформа не просто размещает объявления, а реально помогает пользователям в поиске.

Как влияет система: сопоставление по параметрам и поиск по карте повышают вероятность увидеть подходящее объявление.

Цель 3. Повысить скорость первого отклика через сопоставление и поиск

Обеспечить получение первого отклика не менее чем для 60% объявлений в течение 48 часов после публикации в течение первых 6 месяцев работы. Цель направлена на снижение времени поиска и повышение вероятности возврата.

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

Цель 4. Сделать создание объявления быстрым и простым

Обеспечить среднее время создания объявления не более 3 минут к моменту релиза MVP. Цель направлена на снижение барьера входа и повышение вовлечённости пользователей.

Как влияет система: структурированные поля, подсказки, автозаполнение/выбор точки на карте сокращают время ввода.

Ключевые метрики (KPIs)

Для оценки успешности продукта планируется использовать следующие показатели:

• количество зарегистрированных пользователей;

• количество активных объявлений в месяц;

• доля объявлений со статусом «закрыто»;

• среднее время до первого отклика;

• среднее время создания объявления.

5. Описание продукта

5.1 Общая концепция

Lost&Found - это веб-платформа для размещения и поиска объявлений о потерянных вещах и домашних животных. Платформа объединяет пользователей, столкнувшихся с потерей, и тех, кто обнаружил находку, в едином сервисе с возможностью сопоставления объявлений по описанию, категории, времени и геолокации.

Lost&Found ценен тем, что решает четыре ключевые проблемы: убирает разрозненность каналов, приводит объявления к одному формату, позволяет искать по месту и времени, и даёт безопасный способ связаться и проверить владельца перед передачей.

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

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

5.2 Ключевые функции

1. Размещение объявлений о потере и находке

• выбор категории (вещи, документы, животные и др.);

• заполнение ключевых характеристик(цвет, бренд, приметы и т.д.);

• указание времени и места (с отображением на карте);

• загрузка фотографий с учётом ограничений для некоторых категорий (документы, ключи и т.д.) .

2. Карта объявлений

• отображение потерянных и найденных объектов на карте;

• фильтрация по категории, радиусу, времени публикации;

• переход к карточке объявления с возможностью отклика.

3. Автоматическое сопоставление объявлений

Система рассчитывает совпадения на основе:

• географической близости;

• временного интервала между потерей и находкой;

• совпадения категории;

• совпадения ключевых характеристик (цвет, модель, порода, приметы и др.).

При достижении порога система отображает возможные совпадения в интерфейсе.

4. Механизм проверки владельца (owner-check)

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

Как устроено:

1. Нашедший при отклике выбирает 2–3 контрольных вопроса из шаблонов или пишет свой вопрос.

2. Потерявший отвечает внутри платформы.

3. После ответов у нашедшего появляется кнопка:

   • Подтвердить владельца / Не подтверждать.

4. Пока владелец не подтверждён:

   • чат ограниченный (без телефона/ссылок/адреса хранения),

   • в карточке находки не показывается точное место хранения (если оно было указано нашедшим).

5. Безопасное взаимодействие

• общение внутри платформы без раскрытия личных контактов;

• ограничение передачи персональных данных на этапе до подтверждения;

• возможность подачи жалобы.

6. Риски

6.1. Продуктовые риски

1) Недостаточное количество объявлений

Риск: при низком количестве активных объявлений снижается вероятность совпадений и ценность сервиса. Минимизация:

• Запуск в одном регионе (Москва) и локальное продвижение;

• Упрощённая форма публикации и понятные поля;

• Поиск и фильтры, чтобы пользователи быстро находили подходящее объявление.

Реакция (если риск произошёл):

• Уточнить категории/поля формы, чтобы повысить качество объявлений;

• Ввести подсказки при создании;

• Подключить ручные партнёрские размещения.

2) Отсутствие устойчивой активности

Риск: пользователи заходят один раз, база не обновляется, объявления застаиваются. Минимизация:

• Показ совпадений в интерфейсе по объявлению;

• Понятные статусы и закрытие объявлений;

• Минимум шагов до публикации.

Реакция (если риск произошёл):

• Добавить редактирование объявления (актуализация);

• Добавить напоминания о статусе/актуальности;

• Пересмотреть правила жизненного цикла объявлений (архивирование/продление).

6.2. Риски доверия и безопасности

3) Низкий уровень доверия / риск мошенничества

Риск: пользователи не публикуют данные или боятся откликаться из-за риска передачи находки не владельцу. Минимизация:

• Общение внутри платформы без обязательной публикации контактов;

• Owner-check через контрольные вопросы;

• Лимиты на публикации и отклики;

• Жалоба на объявление/пользователя;

• Базовые антиспам-меры при подозрительной активности.

Реакция (если риск произошёл):

• Быстрое скрытие/блокировка объявления по жалобам;

• Ограничение функциональности подозрительным аккаунтам (временный бан).

6.3. Технические риски

4) Некорректная работа сопоставления

Риск: большое число ложных совпадений снижает доверие к системе. Минимизация:

• В MVP использовать ограниченный набор параметров;

• Минимизировать через обязательные поля (место/время/категория/приметы).

Реакция (если риск произошёл):

• Новая настройка порога совпадений и весов параметров;

• Добавление простого механизма обратной связи (совпадение не подходит) для улучшения качества.

5) Производительность при росте базы

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

• Индексация данных, ограничения на выдачу;

• Кластеризация точек на карте.

Реакция (если риск произошёл):

• Оптимизация запросов и кеширование популярных выборок.

• Временно уменьшить число объявлений в выдаче и на карте.

• Упростить отображение карты (меньше деталей) до устранения причины.

6) Зависимость от API Яндекс.Карт

Риск: лимиты/изменение условий/рост стоимости или недоступность API, влияние на карту и выбор точки. Минимизация:

• Не пытаться показывать на карте сразу всю Москву, отображать объявления только в выбранном районе/радиусе и ограничивать количество точек на экране.

• Проверять работу карты автоматически, если карта не загрузилась, фиксировать ошибку и быстро видеть это в статистике/логах.

Реакция (если риск произошёл):

• Режим работы без карты: ввод адреса/района текстом;

• Переключение на альтернативный провайдер карт при необходимости.

Границы и ограничения

7. Основные функции продукта

7.1 Входит в MVP

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

Таблица 7-1 – Обоснование функций MVP

Функция MVP	Какая боль закрывается	Ожидаемый эффект	Оценка важности
Размещение объявлений «Потерял/Нашёл» в структурированной форме.	Нет единого формата, низкая сопоставимость объявлений.	Создаёт обязательные поля (категория, место, время, приметы), без которых невозможны корректный поиск и сопоставление. Повышает качество данных.	Критично для MVP – без структуры невозможны поиск и сопоставление.
Карта и выбор точки при создании объявления.	Слабая привязка к месту, сложно искать в нужном районе/радиусе	Обеспечивает точную геопривязку, делает возможным поиск рядом и повышает вероятность совпадения.	Критично для MVP – закрывает одну из ключевых болей (место).
Фильтры и поиск (тип, категория, время, район/радиус, текст по описанию)	Разрозненность и ручной поиск по лентам	Сокращает время поиска и снижает ручной просмотр объявлений.	Критично для MVP – без фильтров сервис превращается в ленту.
Сопоставление объявлений по параметрам (место/время/категория/приметы) в интерфейсе	Низкая сопоставимость, совпадения приходится искать вручную	Автоматически предлагает совпадения, ускоряет контакт сторон и влияет на долю закрытий.	Критично для MVP – ядро ценности платформы.
Встроенное взаимодействие (чат внутри платформы)	Пользователи не хотят публиковать контакты, сложно быстро связаться	Убирает барьер публикации, повышает отклики и снижает отказ от использования.	Высокая важность – сильно влияет на активность и доверие.
Owner-check (контрольные вопросы перед передачей)	Риски при передаче, страх отдать не тому	Снижает риск ошибочной передачи, повышает доверие и готовность закрывать сделки через платформу.	Высокая важность – влияет на доверие и закрытия.
Статусы «активно/закрыто»	Непонятно, актуально ли объявление	Поддерживает актуальность базы и позволяет считать долю успешных возвратов.	Поддерживающая функция – усиливает управляемость и аналитику.

Ограничения MVP:

• география: только Москва;

• поиск совпадений: по параметрам (категория/место/время/приметы), без анализа фото;

• взаимодействие: только внутри платформы, без обязательной передачи контактов;

• статусы: “активно/закрыто”.

7.2 Не входит в MVP

В MVP не входят:

• работа за пределами Москвы;

• сопоставление по фотографии (ИИ);

• отдельный функционал/кабинеты для организаций;

• интеграции с организациями и их базами (импорт/синхронизация/API);

• уведомления о возможных совпадениях.

8. Версии продукта и план развития

8.1 Приоритизация (MoSCoW)

Приоритизация функций выполнена по MoSCoW. На её основе сформирован план развития продукта по версиям.

Рисунок 8-1 — Приоритизация функций по MoSCoW

Для формирования реалистичного плана развития функции дополнительно оценены по сложности реализации.

Таблица 8-1 – Оценка сложности и приоритезации функций

Функция	MoSCoW (для MVP)	Сложность разработки	Версия реализации
Структурированные объявления (категория, описание/приметы, место, дата/время, фото)	MUST	Средняя	V1
Лента объявлений и карточка	MUST	Низкая–средняя	V1
Карта и выбор точки	MUST	Средняя	V1
Поиск и фильтрация	MUST	Средняя	V1
Сопоставление по параметрам	MUST	Средняя	V1
Взаимодействие внутри платформы (чат)	MUST	Средняя	V1
Owner-check	MUST	Низкая–средняя	V1
Статусы «активно/закрыто»	MUST	Низкая	V1
Редактирование объявлений	SHOULD	Низкая–средняя	V2
Минимальная защита от спама	SHOULD	Средняя	V2
Улучшение текстового сопоставления	SHOULD	Средняя	V2
Уведомления о совпадениях	SHOULD	Средняя	V2
Черновики	COULD	Низкая	V3
Избранное	COULD	Низкая	V3
Дополнительные настройки профиля	COULD	Низкая	V3
Роли/кабинеты организаций	WILL NOT	Высокая	V3
Интеграции с организациями	WILL NOT	Высокая	V3
Масштабирование за пределы Москвы	WILL NOT	Высокая	V3
Сопоставление по фото (ИИ)	WILL NOT	Высокая	V3

8.2. План развития по версиям

Таблица 8-2 — План развития по версиям продукта

Версия	География	Цель версии	Состав функциональности	Сроки и этапы реализации
V1 (MVP)	Москва	Проверка ценности сервиса и запуск полного пользовательского цикла	Объявления, лента и карточка, карта, фильтры, сопоставление по параметрам, чат, owner-check, статусы.	4–6 недель.
Этап 1: форма объявления + лента + карточка.
Этап 2: карта и фильтрация.
Этап 3: сопоставление.
Этап 4: чат и owner-check.
Этап 5: тестирование и пилотный запуск.
V2	Москва	Повышение эффективности поиска и качества данных	Редактирование объявлений, антиспам, улучшение текстового сопоставления, уведомления.	6–8 недель.
Этап 1: редактирование и актуализация.
Этап 2: антиспам.
Этап 3: улучшение сопоставления.
Этап 4: уведомления и стабилизация.
V3	Москва и регионы	Расширение охвата и подключение партнёров	Черновики, избранное, настройки профиля, роли организаций, интеграции, расширение географии, ИИ (приоритетно после интеграций).	3–6 месяцев.
Этап 1: черновики, избранное, настройки.
Этап 2: кабинеты для организаций без интеграций.
Этап 3: интеграции с организациями.
Этап 4: добавление регионов.
Этап 5: ИИ-сопоставление.

9. Ограничения

9.1. Бюджет

Бюджет MVP сформирован на основе:

• состава команды,

• длительности разработки (4–6 недель),

• отсутствия интеграций и ИИ,

• использования внешнего картографического API.

1. Разработка MVP

Таблица 9-1 — Состав команды и оценка затрат

Роль	Формат участия	Оценка длительности	Оценка затрат
Backend-разработчик	Полная занятость	1–1,5 месяца	120–250 тыс. ₽
Frontend-разработчик	Полная занятость	1–1,5 месяца	120–250 тыс. ₽
Системный аналитик	Частичная занятость	0,5 месяца	40–80 тыс. ₽
UI/UX-дизайн (опционально)	Проектная работа	1–2 недели	30–80 тыс. ₽

Итоговая оценка разработки:

Сценарий	Бюджет
Минимальный (без отдельного дизайнера)	250–350 тыс. ₽
Расширенный (с отдельным дизайном)	450–600 тыс. ₽

Почему разброс:

• уровень ставок специалистов,

• наличие отдельного дизайна,

• сложность реализации карты и сопоставления.

2. Инфраструктура

Таблица 9-2 — Ежемесячные эксплуатационные расходы

Статья	Оценка расходов
Облачный сервер	6–15 тыс. ₽
База данных	3–8 тыс. ₽
Хранение фотографий	1–3 тыс. ₽
Домен и SSL	до 3 тыс. ₽ в год

Итого: 10–30 тыс. ₽ в месяц.

3. Картографический сервис

Используется API Яндекс.Карт.

Таблица 9-3 — Оценка затрат на карту

Сценарий нагрузки	Оценка затрат
Пилот (до 1000 активных объявлений)	В рамках бесплатных лимитов
Рост нагрузки	5–15 тыс. ₽ в месяц

4. Внедрение

В MVP отсутствуют интеграции с внешними системами.

Внедрение включает:

• развёртывание инфраструктуры;

• публикацию сервиса;

• настройку домена;

• подготовку пользовательского соглашения и политики конфиденциальности.

Ответственные:

• Backend-разработчик – развёртывание;

• Аналитик – документация и правила.

Дополнительный бюджет на внедрение не закладывается.

5. Поддержка после запуска

Таблица 9-4 – Поддержка

Направление	Ответственный	Задачи	Формат участия
Техническая поддержка	Backend-разработчик	Исправление ошибок, обновления, контроль стабильности сервера	0,2–0,5 ставки
Контент-модерация	Назначенный модератор	Проверка жалоб, удаление нарушающих правил объявлений	Частичная занятость
Юридическая и регламентная поддержка	Аналитик / внешний консультант	Актуализация пользовательского соглашения и правил публикации	По необходимости

6. Маркетинг

На этапе MVP отдельный маркетинговый бюджет не закладывается. Привлечение аудитории планируется через:

• тематические сообщества,

• локальные каналы,

• партнёрские размещения.

При масштабировании может потребоваться выделение отдельного бюджета на продвижение.

9.2. Сроки

MVP реализуется за 5–6 недель так как:

• отсутствуют интеграции;

• нет ИИ-анализа изображений;

• география ограничена Москвой;

• сопоставление реализуется по параметрам, без ML.

Этапы реализации

Таблица 9-5 – План работ

Этап	Содержание	Срок
1	Уточнение требований, схема данных, API, прототипы	1 неделя
2	Реализация объявлений, ленты, карточки	2 недели
3	Интеграция карты и фильтрации	1 неделя
4	Сопоставление, чат, owner-check	1 неделя
5	Тестирование, исправления, подготовка пилота	1 неделя

Разработка ведётся итеративно: после каждого этапа доступна рабочая версия с расширенным функционалом.

9.3. Ресурсы

Команда MVP

• Backend-разработчик

• Frontend-разработчик

• Системный аналитик

• UI/UX-дизайнер (при необходимости)

Дополнительные ресурсы

После запуска потребуются:

• техническая поддержка (backend);

• модерация контента;

• юридическая подготовка пользовательского соглашения и политики конфиденциальности.

Юридические документы могут быть подготовлены аналитиком на основе типовых шаблонов и при необходимости проверены внешним консультантом.

9.4. Технические и продуктовые ограничения

• MVP ограничен географией: публикация и поиск объявлений доступны только в пределах Москвы.

• Сопоставление объявлений выполняется по параметрам (категория, место, время, приметы/описание); анализ фото в MVP не используется.

• Интеграция с картой реализуется через API Яндекс.Карт. и зависит от его доступности и лимитов.

• В MVP нет отдельных ролей/кабинетов для организаций и нет интеграций с их базами.

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

• Для категорий "документы" и "ключи" в MVP вводятся ограничения на фото (запрет публикации полных данных/серии и номера) и удаление по жалобе.