В этой статье я расскажу о том, как мы в YouScan строим Data Science Squad, что означает принцип you build it, you run it, почему наш подход работает и как мы решаем проблемы, с которыми сталкиваемся на своем пути.
Наша внутренняя культура
Сначала я расскажу о принципах нашей внутренней культуры — это поможет понять, как построить команду внутри компании. Один из основных принципов взаимодействия в YouScan — доверие друг к другу. А благодаря прозрачности внутренних бизнес-процессов наша работа всегда слаженная и предполагает вполне прогнозируемый результат. Право на ошибку позволяет постоянно совершенствоваться и добиваться поставленной цели. Мы считаем, что не зря собрались вместе, поэтому ценим командную работу и, конечно же, любим то, чем занимаемся. Эти принципы позволяют нам строить замечательные команды единомышленников.
Цели и ключевые результаты (OKR)
Для того, чтобы достигать поставленных целей, в YouScan используется методика целей и ключевых результатов (Objectives and Key Results, OKR). Изобретателем методологии считается компания Intel — на тот момент (в 1970-х) во главе с Эндрю Гроувом. Считается, что благодаря этой методологии корпорация сохраняет лидерство на рынке компьютерных процессоров уже много десятилетий (подробнее — в книге). Еще одна известная компанией, которая использует такой же подход к постановке целей, — Google.
Нашим настольным руководством можно считать книгу Джона Дорра «Измеряйте самое важное». Основная идея методологии OKR в том, что цель указывает направление движения, а измеряется движение за счет ключевых результатов. Цели должны быть амбициозные, качественные и ограниченные во времени. Ключевые результаты должны быть измеримы, вести к выполнению цели, быть сложными, но возможными. Такая методология требует довольно много усилий и преданности этим идеям от всей компании, но за счет фокуса, согласованной командной работы и измеримого движения можно достичь невероятных результатов.
Концепция построения команд
Нам нравятся подходы Spotify к построению инженерных команд. В частности, концепция сквадов (squads) — сфокусированных мини-команд, которые могут производить законченный результат — нам очень подходит и отлично согласовывается с планированием с помощью OKR.
Внутри команды разработки мы разделяем независимые направления для того, чтобы иметь максимальный фокус и управляемость, но при этом сохранять автономность и креативность в принятии решений.
Сейчас в разработке продукта участвуют четыре команды:
- Product Squad — команда, которая расширяет пользовательские возможности продукта;
- Data Squad — собирает данные;
- Data Science Squad — отвечает за «умные» возможности продукта на основе искусственного интеллекта и машинного обучения;
- Platform Squad — строит инструменты для автоматизации и вырабатывает лучшие практики для управления инфраструктурой, а также обучает этому другие команды.
К такой структуре мы пришли постепенно, решая разные сложности, которые замечали внутри команды. Во-первых, количество людей росло, и для более эффективной работы и коммуникации необходимо было разделение. Во-вторых, выделяя сквады, мы действовали по принципу определения направлений, которые для нас важны стратегически. По ним мы хотим двигаться постоянно и независимо от обстоятельств.
Возьмем, к примеру, Platform Squad. Его задача — постоянно совершенствовать нашу инфраструктуру. Раньше это была одна из фоновых задач из разряда «ребята, у вас всех есть свои задачи, но не забывайте про логи, метрики, автоматизацию, безопасность». Можно, конечно, поставить цель каждой команде: скажем, тратить 20% времени на платформенные нужды. Но при такой постановке каждый раз будет возникать конкуренция с остальными задачами и нет гарантий, что найдется время на улучшение платформы. Кроме того, такой подход противоречит системности во всей компании, и в приоритет выходят скорее текущие горячие проблемы, чем стратегическая работа над платформой.
Или возьмем Data Squad. Его стратегическое направление — обеспечение широты, глубины и скорости сбора данных из сети. Его процесс отличается от других тем, что много задач может «прилететь» в любой момент из-за зависимости от внешних источников данных, которые находятся вне нашего контроля и могут изменяться. Например, после инцидента в Новой Зеландии со стрельбой, которая транслировалась онлайн, YouTube глобально ограничил поиск. На нас это тоже повлияло. Задачей Data Squad было понять, что произошло, что с этим сделать, как отреагировать. Такие вещи неконтролируемы…
Почему у нас выделенная команда Data Science
Количество данных в социальных медиа с каждым годом увеличивается более чем в два раза. При подобном росте невозможно обработать такие массивы вручную даже для брендов с крупными бюджетами.
Наша задача — не только собрать данные из упоминаний об определенной теме в социальных медиа, но и проанализировать, какие выводы для бизнеса можно извлечь из этих данных. Например, показать, какие тренды были в обсуждениях, выделить важные, показать их путь в сети, определить позитив и негатив, распределить упоминания по площадкам, категоризировать сообщения по темам (спорт, наука, политика и пр.) и типам контента (личное мнение, реклама, спам), добавить «умные» уведомления о важных событиях.
И, конечно же, важное направление работы Data Science Squad — анализ визуальных инсайтов. Кроме того, все эти задачи нужно решать в реальном времени на всем потоке данных.
Стратегическая задача команды — предоставлять клиентам выводы на базе упоминаний, которые мы нашли в интернете, избавляя их от необходимости работать с каждым сообщением отдельно.
В организационные задачи входят:
- изучение рынка и предложение идей по улучшению продукта;
- обучение и тренировка моделей;
- анализ данных;
- поиск нетривиальных путей решений.
Принципы работы команды Data Science
Считается, что задачи команды Data Science ограничены построением моделей машинного обучения, а вопросы эксплуатации или интеграции в продукт не требуют ее вмешательства. Иногда даже извлечение данных, необходимых для решения конкретной прикладной задачи, выделяют в отдельное направление.
Считаем, что такой подход для нас неоправдан: мы хотим получать прототипы решений как можно быстрее и сразу валидировать их. Кроме того, мы считаем, что наша команда достаточно компетентна, чтобы продвигать свое видение, как те или иные возможности должны интегрироваться в продукт.
Каждая команда, в том числе Data Science, руководствуется принципом you build it, you run it — то есть команда сама отвечает за CI/CD, версионирование моделей и разметки, на базе которых они построены. Также она отвечает за метрики, логи, нотификации при авариях, масштабирование в зависимости от нагрузки.
Поскольку затраты на фичи Data Science могут быть очень существенными, мы постоянно анализируем расходы, и в зависимости от этого принимаем решение о тех или иных конкретных реализациях. Обычно команда поставляет API и свое видение, как это должно быть интегрировано в продукт. Тут продуктовая команда (Product Squad) выступает скорее исполнителем, чем владельцем фичи от команды Data Science.
Сейчас это уже довольно распространенная практика, но все же стоит ее упомянуть — речь об интерпретируемости ответов от моделей. Таким образом можно найти абсолютно неожиданные проблемы в тренировке моделей, которые не проявляются на валидации.
Внимание команды не пропадает после того, как в продукт добавлена новая функциональность. Потому что поддержкой уже внедренных вещей также занимается команда Data Science. Часто таким образом мы находим не только проблемы, но и идеи, как дальше развивать продукт.
Резюмируя задачи, с которыми сталкивается команда Data Science, мы получаем следующую картинку:
Но несмотря на то, что задач тут сильно больше, чем принято ставить перед командой Data Science, такая модель позволяет нам делать важные вещи быстро и развивать их, обладая всей информацией и знаниями, которые для этого необходимы.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: