Фриланс-бирж уже десятки. Зачем мы сделали ещё одну?

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

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

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

Портфолио, которое можно открыть

Обычное портфолио разработчика чаще всего состоит из нескольких карточек. В каждой есть название проекта, скриншот, короткое описание, использованные технологии и иногда ссылка на GitHub или сам сайт.

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

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

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

Заказчик может открыть сайт, пройти по нескольким страницам, посмотреть мобильную версию и самостоятельно оценить результат. Для разработки это кажется особенно логичным. Если результат работы существует в интернете и доступен публично, странно ограничиваться одной картинкой.

Конечно, это подходит не для всех проектов. Есть внутренние системы компаний, закрытые сервисы, работы под NDA, backend-разработка и проекты, которые уже перестали существовать. Поэтому обычные карточки никуда не исчезают. Живой проект просто становится дополнительным способом показать работу.

И почти сразу после реализации этой идеи появилась следующая проблема.

Как понять, что проект действительно связан с исполнителем

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

Поэтому мы решили добавить техническое подтверждение контроля над проектом.

Здесь важно сразу уточнить, что именно оно подтверждает. Такая проверка не означает, что человек самостоятельно написал весь код. Над продуктом могла работать большая команда, а исполнитель мог заниматься только frontend, backend, мобильным приложением или отдельным модулем.

Проверка отвечает на более узкий вопрос: есть ли у человека реальный доступ к проекту, который он показывает в портфолио.

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

Первый вариант через DNS. Нужно добавить TXT-запись с выданным кодом, после чего сервер сам проверяет DNS домена и ищет нужное значение.

Второй вариант через специальный файл на сайте. Его нужно разместить по адресу /.well-known/vibemarket-verification.txt, а внутрь положить код подтверждения. После этого сервер открывает файл и проверяет его содержимое.

Третий способ через meta-тег в HTML страницы. В код сайта добавляется тег с уникальным значением, после чего сервер открывает страницу и проверяет, присутствует ли нужный код.

Во всех трёх случаях просто указать чужой сайт недостаточно. Нужно иметь возможность изменить DNS, файлы проекта или HTML страницы.

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

С ботами используется другой способ

Для Telegram-ботов проверка через домен подходит не всегда, поэтому здесь используется Telegram API.

Пользователь указывает username бота и временно вводит токен из BotFather. Сервер отправляет запрос getMe напрямую в Telegram и получает информацию о боте, после чего сравнивает username из ответа с тем, который был указан в портфолио.

Если данные совпадают, бот получает статус подтверждённого.

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

Это казалось важным ограничением. Просить разработчика навсегда отдавать токен рабочего бота сторонней площадке было бы плохой идеей.

Для приложений пришлось сделать отдельную механику

С Android, iOS и Telegram Mini Apps всё немного сложнее. У них нельзя использовать обычную проверку домена или Bot API, поэтому здесь применяется одноразовый runtime-код.

Система создаёт специальный адрес подтверждения, который действует 15 минут. Разработчик добавляет POST-запрос на этот адрес в работающую Mini App или тестовую сборку приложения и запускает её.

Когда запрос приходит на сервер с действующим кодом, проверка считается пройденной. Для Android можно указать package name вроде com.company.app, для iOS используется Bundle ID или название проекта.

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

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

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

Следующая проблема начинается после публикации заказа

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

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

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

Поэтому кроме обычных откликов мы решили попробовать формат аукциона.

При создании заказа можно включить специальный режим и выбрать продолжительность торгов: 3, 6, 12, 24 часа или 3 дня. После публикации исполнители начинают отправлять предложения, в которых указывают цену, срок выполнения и сообщение заказчику.

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

Почему самая низкая ставка не всегда первая

Для каждого предложения рассчитывается VibeScore. В него входят стоимость относительно стартового бюджета, предложенный срок относительно дедлайна, репутация исполнителя, оценка скорости по прошлым работам, количество проектов в портфолио и данные подтверждённого GitHub-профиля.

Представим, что один разработчик предлагает выполнить проект за 500 TON за 20 дней, но его профиль почти пустой. Второй просит 600 TON, обещает закончить за 10 дней, имеет нормальную историю работ, портфолио и подтверждённый GitHub.

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

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

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

При этом самое дешёвое предложение тоже не скрывается. Оно выводится отдельно, даже если не попало в первую тройку.

Дешёвая ставка показывается вместе с контекстом

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

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

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

Если ставка составляет меньше 40% исходного бюджета, заказчик получает предупреждение о том, что исполнитель мог неверно оценить объём задачи.

Это не запрещает выбрать его победителем. Система просто показывает дополнительный контекст.

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

Ставку можно менять во время торгов

Исполнитель не привязан к своему первому предложению до конца аукциона.

Если он сначала предложил выполнить работу за 700 TON за 14 дней, а позже решил изменить условия на 650 TON и 12 дней, старая ставка автоматически отзывается и заменяется новой.

За счёт этого один исполнитель не может занять несколько позиций в рейтинге своими собственными предложениями.

Ещё одна отдельная механика связана с последними минутами аукциона.

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

Если новое предложение появляется, когда до завершения аукциона осталось меньше пяти минут, таймер продлевается ещё на пять минут от момента этой ставки.

Например, если до окончания оставалось две минуты и кто-то изменил предложение, торги не завершатся через эти две минуты. У остальных участников снова будет время отреагировать.

Исполнитель тоже видит положение своей ставки

Рейтинг работает не только для заказчика.

Когда исполнитель вводит цену и предполагаемый срок, система может рассчитать его ожидаемый VibeScore и примерное место относительно других участников.

Также можно получить ориентировочную подсказку, какие условия помогут приблизиться к лидирующим позициям.

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

Это одна из причин, почему нам не хотелось делать классический аукцион на понижение. Иначе вся механика быстро превратилась бы в последовательность 1000, 900, 800, 700, пока кто-то не согласится работать дешевле всех.

Здесь у исполнителя остаются другие способы сделать предложение привлекательнее.

Победителя может выбрать заказчик или алгоритм

VibeScore не обязательно принимает решение за человека.

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

Например, исполнитель с третьего места уже делал почти идентичный проект. Или его сообщение показалось заказчику намного более осмысленным. Или он предложил технический подход, который лучше подходит под задачу.

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

Есть и автоматический режим. Заказчик может заранее включить автоматический выбор, и после окончания торгов система примет предложение с наибольшим VibeScore.

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

Если предложений вообще не было, аукцион закрывается без победителя.

Таким образом алгоритм можно использовать как подсказку или полностью доверить ему выбор. Это решается ещё на этапе публикации заказа.

Почему аукционы не заменили обычные отклики

Потому что такой формат подходит далеко не для каждой задачи.

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

Поэтому обычные отклики остаются.

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

Нам не хотелось заставлять все типы проектов проходить через одну и ту же механику.

В итоге все три функции оказались об одном и том же

Сначала живое портфолио, подтверждение проектов и аукцион выглядели как отдельные идеи.

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

Одного рейтинга здесь недостаточно. Красивые скриншоты тоже ничего не гарантируют. Минимальная цена не означает лучший результат. Количество отзывов не всегда отражает реальный профессиональный опыт.

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

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

После этого решение всё равно остаётся за человеком.

Пока это всё ещё гипотезы

Любая функция кажется полезной, пока её проектируешь.

Живое портфолио выглядит очевидным улучшением, пока не выясняется, что половина разработчиков не может показать проекты из-за NDA. Подтверждение кажется важным, пока кому-то не становится лень добавлять DNS-запись ради одной отметки. Аукцион интересно выглядит в интерфейсе, но вполне может оказаться удобным только для определённого типа задач.

Поэтому мы не считаем эти механики доказанно лучшими.

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

Сейчас всё это уже работает в VibeMarket, и следующий этап намного интереснее самой разработки. Нужно понять, чем пользователи действительно будут пользоваться, а что в итоге придётся переделывать или вообще убрать.

Если вам приходилось нанимать фрилансеров или искать заказы на биржах, интересно узнать: что на самом деле помогает вам доверять человеку по ту сторону экрана? Портфолио, отзывы, подтверждённые проекты, цена, рейтинг, личное общение или что-то другое?