Опубликовано: 16.10.2026 | Источник: CNews (новости)

Маркетплейс услуг для «серебряного поколения» в ВКР: архитектура, метрики и доступность

В конце марта 2026 года «Авито Услуги» опубликовали данные о заметном росте числа исполнителей старше 55 лет: люди серебряного возраста всё активнее превращают бытовые и профессиональные навыки — ремонт, репетиторство, шитьё, уход, консультирование — в источник дохода. Для выпускника ИТ-направления это не абстрактная социология, а готовое техническое задание: платформа должна уметь ранжировать исполнителей, проверять документы, считать доверие, подсказывать цену и при этом оставаться удобной для человека, который не привык к сложным интерфейсам. Ниже — как превратить этот сюжет в защищаемую ВКР с измеримым результатом, а не в пересказ новости.

Три темы ВКР, которые вырастают из новости

Тема 1. Сервис подбора исполнителей услуг для пользователей 55+ с рекомендательным модулем

• Актуальность: рынок услуг смещается в сторону старших исполнителей, а существующие алгоритмы ранжирования обучены на «молодой» аудитории и не учитывают иные паттерны поведения (редкие, но длинные сессии, звонок вместо чата, доверие к отзывам, а не к рейтингу звёздами).
• Цель: разработать прототип сервиса подбора услуг с гибридной рекомендательной системой и оценить прирост конверсии в заказ.
• Задачи: анализ предметной области и аналогов; проектирование модели данных; реализация гибридного ранжирования (коллаборативная фильтрация + контентные признаки); нагрузочное тестирование и A/B-сравнение с базовым ранжированием по дате.
• Структура: Глава 1 — анализ рынка услуг и обзор алгоритмов рекомендаций; Глава 2 — проектирование архитектуры и API; Глава 3 — реализация, эксперимент, расчёт экономического эффекта.

Тема 2. Микросервисная платформа маркетплейса услуг с модулем верификации исполнителей

• Актуальность: рост числа самозанятых исполнителей обостряет проблему доверия и фрода: поддельные портфолио, обход платформы, накрутка отзывов. Это классическая задача проектирования сервисов безопасности.
• Цель: спроектировать и реализовать модуль верификации (документы + телефон + история заказов) с интеграцией через OAuth 2.0/OIDC.
• Задачи: обоснование декомпозиции на сервисы; схема взаимодействия через брокер сообщений; реализация скоринга доверия; тестирование отказоустойчивости.
• Структура: Глава 1 — теория доверия и антифрода на платформах; Глава 2 — архитектура (C4-диаграммы, схемы последовательностей); Глава 3 — тестирование, RTO/RPO, экономика внедрения.

Тема 3. Оценка качества ранжирования и доступности интерфейса сервиса услуг по ISO/IEC 25010

• Актуальность: аудитория 55+ предъявляет жёсткие требования к доступности (WCAG 2.2) и к предсказуемости интерфейса, а бизнесу нужны метрики, а не «нравится/не нравится».
• Цель: построить методику оценки сервиса по группам характеристик ISO/IEC 25010 и проверить её на реальном прототипе.
• Задачи: выбор метрик; сбор данных (логи + юзабилити-тест с респондентами 55+); расчёт NDCG@10, CTR, времени до первого заказа; формулировка рекомендаций.
• Структура: Глава 1 — стандарты качества ПО и доступности; Глава 2 — методика и инструментарий сбора метрик; Глава 3 — эксперимент, статистика, выводы.

Аналитическая глава: как обосновать выбор, а не перечислить технологии

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

Обязательно фиксируйте функциональные и нефункциональные требования — удобно опереться на ГОСТ 34.602-89 при оформлении ТЗ и на ISO/IEC 25010 при выборе атрибутов качества: производительность, безопасность, удобство использования, сопровождаемость.

Проектная часть: от диаграмм до работающего кода

Декомпозиция и контракты

Для платформы услуг разумно выделить сервисы: каталог (поиск и фильтры), профили (верификация), заказы (жизненный цикл сделки), рейтинг (отзывы и скоринг), уведомления, аналитика. Взаимодействие — синхронное по REST для чтения и асинхронное через очередь для событий «заказ создан», «отзыв добавлен». Схемы — по ГОСТ 19.701-90, а описание архитектуры покажите в C4 (контекст → контейнеры → компоненты).

Пример: подбор исполнителей с учётом района и текстового запроса

-- PostgreSQL: pg_trgm + PostGIS, гибридный фильтр «текст + радиус»
SELECT p.id, p.display_name,
       similarity(p.skills_text, :query) AS text_score,
       (p.avg_rating * 0.4 + p.completed_orders_norm * 0.3
        + similarity(p.skills_text, :query) * 0.3) AS rank_score
FROM performers p
WHERE ST_DWithin(p.location, ST_MakePoint(:lon, :lat)::geography, :radius_m)
  AND p.verified = TRUE
ORDER BY rank_score DESC
LIMIT :top_n;

Такой запрос легко защитить: он показывает и работу с геоданными, и нормализацию признаков, и прозрачную формулу ранжирования, которую потом можно сравнить с ML-моделью. Не забудьте про пагинацию и кэш ответов — для аудитории 55+ важна стабильность выдачи между сессиями.

Доступность как проектное требование

• Минимальный размер интерактивных элементов и контраст по WCAG 2.2 (уровень AA).
• Один сценарий — один экран: длинные формы дробим, подсказки пишем простыми формулировками.
• Дублирование каналов: чат + звонок, потому что часть исполнителей предпочитает голосовую связь.

Тестирование, метрики и эксплуатация

Здесь ВКР выигрывает или проигрывает. Нагрузочное тестирование (k6, Locust или Яндекс.Танк) даёт вам числа для третьей главы, а OpenTelemetry — трассировки и метрики для обоснования узких мест. Разворачивайте стенд в Kubernetes, чтобы говорить о горизонтальном масштабировании не абстрактно, а с графиками.

Отдельно опишите CI/CD-пайплайн: линтеры, юнит- и интеграционные тесты, сборка образа, миграции БД под флагом, канареечный деплой. Это дешёвый способ показать инженерную зрелость — и один из самых частых вопросов на защите.

Чему вы научитесь на такой теме

• Переводить рыночный тренд в требования, а требования — в архитектурные решения.
• Обосновывать стек критериями и таблицами сравнения, а не личными предпочтениями.
• Строить и интерпретировать метрики качества: от NDCG@10 до RTO/RPO.
• Оформлять документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90 без переписывания учебника.

Частые вопросы студентов

Насколько сложно реализовать такой сервис в одиночку за семестр?

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

Обязательно ли писать работающий код?

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

Где брать тестовые данные, если реальных заказов нет?

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

Как оформлять UML-диаграммы, чтобы их приняли?

Стройте нотацию корректно (PlantUML или draw.io), подписывайте каждый элемент, давайте пояснение к диаграмме в тексте. Диаграмма без описания в ВКР считается иллюстрацией, а не результатом проектирования.

Источник: «Авито Услуги»: как «серебряное поколение» монетизирует свои навыки (опубликовано 2026-03-30)