Конструктор исследовательских сервисов Сбера
Как мы создавали R&D платформу для Фонда «Вклад в будущее»
в сфере образования и какие мотивационные фишки применяли
для того, чтобы такая грандиозная идея превратилась
в работоспособный сервис

research.vbudushee.ru
Клиент и задача
Благотворительный фонд «Вклад в будущее» — создает возможности для самореализации и адаптации людей в условиях быстро меняющегося мира. Фонд воплощает в жизнь проекты, которые дают людям со всех уголков нашей страны равные возможности. К примеру, финансовая грамотность для детей и подростков, поддержка учителей и педагогов дополнительного образования, развитие цифровых навыков, социализация и адаптация «особых» детей.


На данный момент, фонд занимается поддержкой проектов и программ в 85 регионах РФ, где более 23 тысяч педагогов и 6 миллионов детей приняли в них участие.

БФ «Вклад в будущее» является частью экосистемы Сбера. Фонд фокусируется на развитии личностного потенциала и проводит множество исследований в этой области — нашей задачей стало создание R&D-платформы для проведения и повышения качества таких исследований.
Поставленная задача и наш подход к реализации
Сложная логика сервиса + семантический анализ текстов!
Тут самый сок
И другие фишки эффективности
Деньги за сторипоинты (SP)
Часть 2 — огромный функционал конструктора и аналитика
Жизнь проекта после завершения разработки
Ключевые тезисы после рефлексии
Цели проекта
Цель — создать исследовательскую платформу. Это был тот случай, когда у коллег из Фонда была наработана колоссальная экспертиза в области исследований и разработка платформы не является проверкой гипотезы, а является логичной необходимостью для развития. Что подразумевает внедрение внушительного функционала сразу, а не маленького MVP. Что и стало нашей задачей — превратить идеи в полноценную многофункциональную R&D-платформу.

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

Важной составляющей стратегии разработки стали гибкие методологии — разработка велась по SCRUM с нашими авторскими доработками процессов. Про них мы тоже расскажем дальше, особенно интересно про подходы к мотивации команды и фокусировании на SP (стори поинтах).
Работа над проектом
Работа началась с масштабного этапа предпроектной аналитики. Здесь себя отлично показал наш фреймворк предпроектной аналитики (его даже пришлось расширить на этом проекте), который включает в себя:

  • интервьюирование стейкхолдеров;
  • бэклог проекта;
  • визуальный роадмап проекта;
  • контроль бюджета проекта;
  • описание инфраструктуры разработки;
  • архитектура сервиса;
  • описание бизнес-процессов;
  • концепция структуры БД;
  • ролевая политика;
  • карта экранов интерфейса;
  • описание математических логик;
  • модель данных API;
  • программа и методика испытаний;
  • и написание частного технического задания (описание постановки задач).
После детального изучения и проработки концепции системы, мы приступили к формированию дизайн-концепции. Здесь было важно сделать упор на подачу информации: сервис довольно сложный, но всё должно быть интуитивно понятно для ЦА. При этом сохранить визуальный стиль приятным и лёгким.
Концепция

После детального изучения и проработки концепции системы, мы приступили к формированию дизайн-концепции. Здесь было важно сделать упор на подачу информации: сервис довольно сложный, но всё должно быть интуитивно понятно для ЦА. При этом сохранить визуальный стиль приятным и лёгким.
Концепция отталкивалась от первых экранов, которые видит пользователь. Необходимо донести информацию о предназначении сервиса и простым языком объяснить его функциональные возможности. Не пугать сразу всем тем жирным функционалом, который скрывается внутри сервиса.
Регистрация

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

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

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

Всё достаточно просто: указал название, описание и даты, прикрепил материалы, указал почты участников, нажал кнопку — приглашения ушли.
Модерация мероприятий

Мероприятия могут быть как закрытые (по приглашениям), так и публичные. Для этого мы разработали интерфейсы для модерации. Созданные публичные мероприятия публикуются после проверки и одобрения сотрудником фонда.
Семантический анализ документов

Здесь начинается самое интересное — про машинную обработку больших научно-исследовательских документов. Это тот функционал, который призван экономить кучу времени сотрудникам фонда на том, что:

  • участники сами размечают свои документы;
  • система автоматически дает оценку — насколько документ соответствует той или иной направленности;
  • происходит автоматический отсев нерелевантных документов (а кол-во документов, с которыми работали сотрудники — измеряется тысячами!);
  • ведется учет всех документов в единой системе;
  • эксперты могут дать более детальную обратную связь и оценку по релевантным научным исследованиям с помощью удобного интерфейса.
Задача оценки релевантности документов довольно сложная и реализована на стыке технологий (Python, с возможностью дальнейшего обучения нейросети) и большой исследовательской экспертизы фонда. В основу взят масштабный тезаурус связанных смыслов и методики и видение Фонда по оценке соответствия ему текстов.
Ну а теперь немного нагляднее как это все выглядит и работает.
Разметка документов

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

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

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

И сотруднику Фонда остается проверить только материалы, успешно пройденные проверку. Чтобы отправить самые релевантные и корректные конечному эксперту в данной области.
Процессы работы команды
Это не конец кейса, но здесь мы решили сделать отступление про важную составляющую проекта — процессы его разработки. Именно эта конфигурация и такие подходы позволили нам реализовать этот сложный сервис. Который по-настоящему стал изобретательской задачей и для заказчика, и для команды.
Например, создание B2B торговой площадки — задача гораздо более простая в понимании логики работы сервиса. А здесь — реализация сложной уникальной идеи да еще и в такой сфере как «soft skills», у которой не самые широкие возможности по оцифровке.

Как мы справились с этой задачей, рассказываем дальше.
Фреймворк предпроектной аналитики

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

  • интервьюирование стейкхолдеров;
  • бэклог проекта;
  • визуальный роадмап проекта;
  • контроль бюджета проекта;
  • описание инфраструктуры разработки;
  • архитектура сервиса;
  • описание бизнес-процессов;
  • концепция структуры БД;
  • ролевая политика;
  • карта экранов интерфейса;
  • описание математической логики;
  • модель данных API;
  • программа и методика испытаний;
  • и написание частного технического задания (описание постановки задач).

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

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

Мы запустили первый спринт, как только был готов и согласован стартовый пакет документации. С этого момента команда готова начать реализацию по гибкой методологии. Здесь и в большинстве проектов мы применяем фреймворк SCRUM.
В качестве таск-менеджера мы используем Jira или Яндекс.Трекер как в данном проекте. Какой бы ни был таск-менеджер — глобально он настраивается всегда одинаково согласно нашему регламенту. Под каждый проект таск-менеджер подготавливает и в дальнейшем поддерживает выделенный инженер процессов.

В таск-менеджере выстроены следующие процессы:

  • управление бэклогом (он постоянно пополняется и приоритезируется);
  • спринты (каждые 2 недели закрывается спринт и открывается новый, это обязательная процедура);
  • оценка фичей (мы используем «planning poker»);
  • тестирование фичей;
  • согласование и демо итогов спринта.

Благодаря оцифровке всех фичей в сторипоинтах (а это достаточно точная оценка в сравнении с часами, которые легко превращаются из 8 часов в 32) мы всегда видим реальный прогресс проекта (оцифрованный в % показатель выполнения выбранного на проект скоупа). Например, можно сказать, что:

  • Бэклог вырос с 658 до 970 sp;
  • Реализовано 458 из 780 sp (скоуп включенный в текущий проект);
  • Прогресс 59%;
  • Скорость команды 72 sp за спринт;
  • Остается 4-5 спринтов, дата завершения 10 – 24 октября, например.

Очень рекомендуем этот подход — снимает эмоциональное напряжение, тревогу, дарит спокойствие и фокус на актуальных вещах!

Интеграция процессов в Telegram-чат

Телеграм-бот по проекту — это как открытая кухня в ресторане. Там кипит движуха как на маленьком заводе. Мы создаем под каждый проект такой командный чат, он интегрирован с таск-трекером, в него приходят уведомления о смене статусов задач, о релизах, он отмечает ответственных за согласование, когда фича готова целиком и тд. В общем — он помогает оперативно коммуницировать всей команде проекта, фокусироваться на актуальных вещах и поддерживает проектный драйв!
Мотивация команды

Мотивированная команда — очень важная составляющая успеха проекта. Как сказал один IT-директор из нашего клиента — «Если я вижу, что команде не интересно, я понимаю, что у меня проект под рисками». И это действительно так, люди не роботы и эффективны тогда, когда им нравится делать то, что они делают и когда они видят регулярный результат.

Мы хотели, чтобы команда была еще больше сфокусирована на правильном результате — на готовых рабочих фичах. И внедрили премиальные фонды для команд проектов, которые накапливаются за спринт — сколько команда закрыла SP (не ниже планки), столько и падает в фонд, который делится поровну на всю команду в момент закрытия спринта. Получилась самая быстрая обратная связь от работы каждого специалиста — а это залог здоровой геймификации! В общем чате команду отмечаем за хороший результат и ребята в пятницу вечером получают свою премию.

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

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

Создается отчет по единому шаблону, который можно дополнять под каждое новое исследование. Якорной частью каждого опроса является стандартная методика. Из боковой панели можно выбрать нужную методику и перетащить ее в один клик в область конструктора (drag’n’drop) — в форму автоматически вставляется набор стандартных вопросов согласно выбранной методике.

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

Сохраненный и запущенный опрос превращается в удобную наглядную пошаговую форму.
Отчет по исследованиям

По каждому такой проводимому исследованию уже в процессе можно посмотреть вот такой отчет:
Сравнение исследований

Результаты нескольких исследований-опросов можно сравнить по общим критериям:
Дополнительные элементы (заглушки, поп-апы, ошибки)

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

Попапов очень много, все они были добавлены благодаря проработке пользовательских сценариев и UX-тестирования, без которого создать сервис подобного масштаба просто невозможно.
Факапы
В середине проекта появилось требование и необходимость внедрить IT-стандарты Сбера по организации инфраструктуры разработки и по управлению проектами. Честно будет признаться, что наш процесс соответствовал далеко не всем принятым в банке стандартам и ГОСТам.

И можно было бы сказать, что такие излишние требования и бюрократизация были не нужны для качественной реализации проекта, но! — мы взяли несколько очень крутых практик в свой арсенал и решили применять их во всех проектах. Ну и в целом привели процессы в соответствии с требованиями Сбера, хотя это было не так просто.
Результаты
Удалось разработать и запустить сложный исследовательский сервис с нуля — от идеи на бумаге до полной работоспособности. Кроме того накопили ощутимый бэклог на развитие проекта.
Извлеченные уроки
Урок №1

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

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