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

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

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

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

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

Ключевые моменты с интервью:

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

2. Точечная работа. Иногда над проектом нужно работать точечно. Например, над каким-то конкретным шагом и вычислениями. И приходится либо опять же дублировать весь проект целиком и бояться, что кто-то внесет ненужные тебе изменения, либо прибегать к разным “костылям” – от скриншотов до обсуждения всех деталей по переписке.

3. Цели совместной работы могут быть разные: иногда это простая необходимость скинуть результат работы на ревью менеджеру. И снова хочется, чтобы это было быстро и без лишних заморочек. А еще чтобы в твоем проекте случайно не отредактировали то, что не нужно.

4. Безопасность данных. Некоторые проекты содержат конфиденциальные результаты, и учёным нужно контролировать, кто именно может их просматривать или редактировать. Пересылка по почте или мессенджерам вызывала тревогу.

5. Прозрачность прогресса. У менеджеров и руководителей лабораторий не было единой картины: кто что сделал и на какой стадии проект. Приходилось долго собирать информацию через чаты и звонки.

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

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

1. Управление доступами и безопасность

• Возможность пригласить пользователя в проект через email или по имени.
• Роли и права: «чтение» и «редактирование»
• Возможность быстро отозвать доступ
• Сохранение доступа к некоторым элементам отозванных проектов

2. Избежание хаоса и актуальность

• Автоматическое обновление для всех участников при изменениях.
• Уведомления об изменениях в проекте (например, «Новый отчёт добавлен») или новых добавленных проектах

3. Точечная работа

• Возможность делиться отдельным объектом (отчётом, шагом эксперимента, результатом вычислений).

4. Доступ к проектам и навигация

• Страница «Shared with me» — список всех проектов и отчётов, которыми поделились с пользователем.
• Поиск и фильтрация по типу, владельцу, названию.

Отрисовала экраны со всем функционалом, показала на демо команде и понесла на тестирование тем же людям, с которыми проводила интервью.

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

Initial adoption: 85% пользователей попробовали функционал хотя бы один раз.

Repeat adoption / Retention (за ~1 месяц): 90% пользователей использовали функционал повторно.

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

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