В марте мы написали на Хабре, что хотим сделать платформу, где учёные смогут находить друг друга не «по знакомым», а по конкретным задачам. Тогда это была гипотеза и черновик MVP.
За эти два месяца мы прошли закрытый бета-тест, переделали ключевой экран приложения, поняли, что половину фич из первого плана делать не нужно — и недавно выложили Synaps в RuStore.
В этом посте — что из изначальной гипотезы выжило, а что пришлось переписать после первых живых пользователей.
Главный разворот: мы убрали профиль с главного экрана
В первой версии MVP всё начиналось как в любой соцсети: пользователь регистрируется, заполняет профиль, добавляет интересы, навыки, лабораторию, ORCID — и только потом ему показывают ленту запросов.
Логика казалась очевидной: чем подробнее профиль, тем точнее матчинг.
Но на бета-тесте мы быстро увидели картину, которой не ожидали:
люди заполняли профиль на 30-40% и бросали;
те, кто всё-таки доходил до ленты, не понимали, что с ней делать;
запросов в ленте было мало, потому что для создания запроса нас тоже сначала отправлял заполнить профиль.
Классическая проблема холодного старта, помноженная на то, что в академической среде люди особенно не любят «продавать себя». Заполнение списка компетенций для многих ощущается как написание резюме — а это всегда откладывается.
И тут мы поняли простую вещь: учёный приходит в приложение не показать себя, а закрыть конкретную задачу.
Нужна консультация по статистике на час.
Ищу соавтора с биоинформатикой для статьи.
Посмотрите, корректно ли я построил модель.
Это не «найти интересных людей по тегам» — это конкретный запрос с дедлайном.
Мы поменяли первый экран. Теперь регистрация — это две строки: имя и почта. Дальше пользователь сразу попадает в ленту запросов. Он может откликнуться на чужой или создать свой — и только в момент отклика/публикации заполняет минимальные поля, которые нужны именно для этой задачи. Профиль собирается постепенно, из реального взаимодействия, а не из формы регистрации.
Звучит как мелочь, но конверсия из «открыл приложение» в «совершил действие» выросла кратно.
Три кейса из беты, которые задали структуру продукта
Расскажу про сценарии, которые реально случились у первых пользователей — они и сформировали то, как сейчас устроены запросы.
Кейс 1. Аспирант + статистика. Запрос: «нужна консультация по выбору метода для анализа экспериментальных данных, формат — пара звонков, срок — неделя». Откликнулись три человека за два дня. Один — со смежного факультета, с которым аспирант никогда не пересекался. Задача закрылась за один созвон.
Что мы из этого вынесли: формат участия (консультация / часть работы / соавторство) и срок — это обязательные поля запроса, а не опциональные. Без них запрос либо игнорируют, либо откликаются не те люди.
Кейс 2. Студент + анализ данных. Студент с экономфака искал, кто поможет разобраться с предобработкой большого датасета. Откликнулся студент с ФКН — не как соавтор, а именно как «посмотрю код за вечер». В итоге — короткая микро-коллаборация, которая через старые каналы (чаты потока, знакомые) почти точно не случилась бы: они в разных корпусах, на разных факультетах, в разных Telegram-чатах.
Что вынесли: микро-формат («помощь на час-два») — это отдельный сценарий, не вырожденный случай соавторства. Мы вынесли его в интерфейсе отдельно.
Кейс 3. Исследователь + технический эксперт. Запрос на доработку метода обработки сигнала. Здесь интересно то, что первая формулировка запроса не сработала — она была слишком общей («нужна помощь с обработкой сигнала»), за три дня — ноль откликов. Мы попросили автора переписать: добавить, какой именно сигнал, какой метод сейчас используется, что не получается. После переписывания откликнулись двое за сутки.
Что вынесли: формулировка запроса — это отдельный продуктовый объект, который нужно проектировать так же тщательно, как онбординг. Сейчас у нас в форме создания запроса — подсказки и примеры по каждому полю, чтобы человек не писал в стиле «помогите, пожалуйста, со статьёй».
Что мы выкинули из первого плана
В мартовской статье мы расписывали довольно широкий MVP. Реальность срезала список примерно вдвое.
Что не делали (хотя планировали):
Сложные фильтры по дисциплинам. Звучало логично, но у учёных в реальности междисциплинарные интересы. Человек с биофака может закрыть запрос по статистике лучше, чем человек со статистики, который не знает специфики данных. Жёсткие фильтры отрезали бы релевантных людей. Сейчас работает поиск по навыкам + лента с подписками на темы.
Коллективные аккаунты лабораторий. Идея была дать лабам единый профиль. На деле — у лабы нет одного человека, который этим будет заниматься, аккаунт мёртвый с первого дня. Вместо этого сделали тег «лаборатория» у личного профиля.
Интеграцию с ORCID/Scholar на старте. Хотели подтягивать публикации автоматически. Поняли, что для запросов это не критично — людям важнее, что человек умеет делать сейчас, а не что у него опубликовано три года назад. Интеграцию отложили на будущие версии.
Что оставили и доделали:
лента запросов с фильтрами по навыкам и формату участия;
отклики и встроенный чат;
структурированная карточка запроса (тема, навыки, формат, срок);
подписки на темы, чтобы новые запросы приходили уведомлением.
Что дальше
Сейчас Synaps доступен в RuStore: ссылка на приложение.
Ближайшие планы:
расширяться за пределы ВШЭ;
добавить рекомендации запросов по навыкам (сейчас лента в основном хронологическая);
аккуратные интеграции с ORCID и Scholar — для тех, кому это важно.
Если у вас есть опыт похожих продуктов (нетворкинг внутри узких сообществ, матчинг по задачам, академические сервисы) — нам очень интересны ваши шишки и истории. Особенно про то, как вы решали холодный старт.
Telegram-канал, где пишем апдейты: @synaps_networking.
Спасибо, что дочитали. Минусы и критику — особенно по продуктовой части — встретим с благодарностью.