В этой статье я расскажу о том, как мы в YouScan строим Data Science Squad, что означает принцип you build it, you run it, почему наш подход работает и как мы решаем проблемы, с которыми сталкиваемся на своем пути.
Сначала я расскажу о принципах нашей внутренней культуры — это поможет понять, как построить команду внутри компании. Один из основных принципов взаимодействия в YouScan — доверие друг к другу. А благодаря прозрачности внутренних бизнес-процессов наша работа всегда слаженная и предполагает вполне прогнозируемый результат. Право на ошибку позволяет постоянно совершенствоваться и добиваться поставленной цели. Мы считаем, что не зря собрались вместе, поэтому ценим командную работу и, конечно же, любим то, чем занимаемся. Эти принципы позволяют нам строить замечательные команды единомышленников.
Для того, чтобы достигать поставленных целей, в YouScan используется методика целей и ключевых результатов (Objectives and Key Results, OKR). Изобретателем методологии считается компания Intel — на тот момент (в 1970-х) во главе с Эндрю Гроувом. Считается, что благодаря этой методологии корпорация сохраняет лидерство на рынке компьютерных процессоров уже много десятилетий (подробнее — в книге). Еще одна известная компанией, которая использует такой же подход к постановке целей, — Google.
Нашим настольным руководством можно считать книгу Джона Дорра «Измеряйте самое важное». Основная идея методологии OKR в том, что цель указывает направление движения, а измеряется движение за счет ключевых результатов. Цели должны быть амбициозные, качественные и ограниченные во времени. Ключевые результаты должны быть измеримы, вести к выполнению цели, быть сложными, но возможными. Такая методология требует довольно много усилий и преданности этим идеям от всей компании, но за счет фокуса, согласованной командной работы и измеримого движения можно достичь невероятных результатов.
Нам нравятся подходы Spotify к построению инженерных команд. В частности, концепция сквадов (squads) — сфокусированных мини-команд, которые могут производить законченный результат — нам очень подходит и отлично согласовывается с планированием с помощью OKR.
Внутри команды разработки мы разделяем независимые направления для того, чтобы иметь максимальный фокус и управляемость, но при этом сохранять автономность и креативность в принятии решений.
Сейчас в разработке продукта участвуют четыре команды:
К такой структуре мы пришли постепенно, решая разные сложности, которые замечали внутри команды. Во-первых, количество людей росло, и для более эффективной работы и коммуникации необходимо было разделение. Во-вторых, выделяя сквады, мы действовали по принципу определения направлений, которые для нас важны стратегически. По ним мы хотим двигаться постоянно и независимо от обстоятельств.
Возьмем, к примеру, Platform Squad. Его задача — постоянно совершенствовать нашу инфраструктуру. Раньше это была одна из фоновых задач из разряда «ребята, у вас всех есть свои задачи, но не забывайте про логи, метрики, автоматизацию, безопасность». Можно, конечно, поставить цель каждой команде: скажем, тратить 20% времени на платформенные нужды. Но при такой постановке каждый раз будет возникать конкуренция с остальными задачами и нет гарантий, что найдется время на улучшение платформы. Кроме того, такой подход противоречит системности во всей компании, и в приоритет выходят скорее текущие горячие проблемы, чем стратегическая работа над платформой.
Или возьмем Data Squad. Его стратегическое направление — обеспечение широты, глубины и скорости сбора данных из сети. Его процесс отличается от других тем, что много задач может «прилететь» в любой момент из-за зависимости от внешних источников данных, которые находятся вне нашего контроля и могут изменяться. Например, после инцидента в Новой Зеландии со стрельбой, которая транслировалась онлайн, YouTube глобально ограничил поиск. На нас это тоже повлияло. Задачей Data Squad было понять, что произошло, что с этим сделать, как отреагировать. Такие вещи неконтролируемы…
Количество данных в социальных медиа с каждым годом увеличивается более чем в два раза. При подобном росте невозможно обработать такие массивы вручную даже для брендов с крупными бюджетами.
Наша задача — не только собрать данные из упоминаний об определенной теме в социальных медиа, но и проанализировать, какие выводы для бизнеса можно извлечь из этих данных. Например, показать, какие тренды были в обсуждениях, выделить важные, показать их путь в сети, определить позитив и негатив, распределить упоминания по площадкам, категоризировать сообщения по темам (спорт, наука, политика и пр.) и типам контента (личное мнение, реклама, спам), добавить «умные» уведомления о важных событиях.
И, конечно же, важное направление работы Data Science Squad — анализ визуальных инсайтов. Кроме того, все эти задачи нужно решать в реальном времени на всем потоке данных.
Стратегическая задача команды — предоставлять клиентам выводы на базе упоминаний, которые мы нашли в интернете, избавляя их от необходимости работать с каждым сообщением отдельно.
В организационные задачи входят:
Считается, что задачи команды 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, такая модель позволяет нам делать важные вещи быстро и развивать их, обладая всей информацией и знаниями, которые для этого необходимы.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…