В апреле мы провели митап для бизнес-аналитиков: три доклада, три спикера и три интересных темы. А теперь рассказываем (и показываем) в деталях, о чём шла речь.
В red_mad_robot мы создаём прорывные продукты для бизнеса и помогаем запускаться стартапам, находим точки роста в существующих продуктах, придумываем стратегии развития и помогаем их реализовывать. У нас есть три подхода к проектам:
Работаем по традиционной сервисной модели, где доставляем заранее определённый скоуп-проект клиенту.
В качестве фичер-команды, когда подключаемся на существующий проект и отвечаем за определённые его части.
По модели BOT с нуля выстраиваем цифровой бизнес и передаём его клиенту.
Сегодня — о двух первых случаях. Аналитика в сервисной компании и инхаус отличаются.
Аналитик в сервисной компании, скорее всего, уже видел похожие проекты, поэтому погружён в контекст и обладает экспертизой в этой области. С другой стороны, инхаус-аналитик очень погружён в существующие системы компании клиента, ориентируется во внутренних взаимосвязях и может рассказать о том, к каким людям в компании и по каким вопросам нужно обращаться.
В классический сервисной модели целеполагание — создать определённые фичи в определённый срок, тогда как для инхаус-аналитика целью может быть достижение конкретных метрик в рамках квартала или года. Важно понимать, что общая цель — сделать крутой продукт, и можно в этом друг другу помогать, в том числе достигая личных целей.
Коммуникация
Часто работа аналитика заключается в том, чтобы задавать правильные вопросы нужным людям, в том числе таким же аналитикам. Поэтому очень важно понимать их мотивацию и строить общение таким образом, чтобы все вовлечённые в процесс инхаус-аналитики чувствовали себя хорошо, делились экспертизой и помогали выстраивать коммуникацию с нужными людьми.
А ещё важно синхронизироваться. Когда в проекте есть смежные команды, учитывайте их при планировании бэклога и уделяйте время обсуждению общих задач. Это помогает избежать пересечений.
Документация
В каждой компании есть свои стандарты ведения документации. Но это не статичная вещь — полезно их пересматривать в процессе и делиться друг с другом наработками.
Обсуждать стандарты. На старте проекта важно сразу договориться об основных вещах, потому что вопросов масса и их нужно сразу решить: где мы ведём документацию (наш Confluence или клиента); если у клиента, то где именно мы там «живём»; какие есть принципы и стандарты документации; пишут ли аналитики спецификации на API и т. д.
Не бояться изменений. Не существует идеального формата документации. В red_mad_robot есть свой шаблон — мы работаем по нему и умеем при необходимости внедрять его в команду клиента. А ещё берём в работу лучшие практики у клиентской команды.
Не держать в голове. Придерживайтесь договорённостей по структуре и формату документации. Ключевой момент для сервисной компании — закрытие проекта и полная его передача в инхаус. Как правило, у этого есть чёткий дедлайн, но иногда закрывать приходится буквально за неделю. Поддерживайте порядок в документах на протяжении всего проекта — и сэкономите себе много времени и нервов.
Организация работы
Наши аналитики глубоко вовлечены в управление бэклогом и настройку совместной работы с клиентом. Поэтому важно уделять внимание и такой, казалось бы, «менеджерской» части.
Распределять ответственность. На старте проекта важно обговорить, кто за что отвечает, и донести это до всех участников процесса, особенно если в проект вовлечена инхаус-команда. Мы составляем матрицу RACI, где выделяем конкретные задачи и ответственных за них. Например, инхаус-аналитик будет отвечать за сбор информации о технических ограничениях, а наш аналитик — с их учётом проектировать процесс.
Обкатывать всё на первых фичах. При совместной работе, особенно в начале, всегда случаются неожиданности и даже конфликты. Поэтому для долгой и продуктивной работы лучше сразу набить все шишки и наступить на все грабли: а для этого на первых этапах брать в работу такие фичи, на которых можно найти как можно больше подводных камней. Не слишком большие, чтобы сделать быстро, но и не слишком маленькие, чтобы охватывать все практики.
Минимизировать зависимости. Когда в продукте есть смежные команды, которые работают над пересекающимися частями функциональности, стоит выявлять зависимости и максимально разделять этот скоуп, чтобы это не продлевало критический путь проекта.
Вкратце: шесть принципов работы
Определяем ответственность в разрезе фич и обязанностей.
Делим скоуп, чтобы минимизировать зависимости между командами.
Устанавливаем стандарты работы с документацией.
Синхронизируемся со смежными командами.
Предлагаем улучшения по процессам и шаблонам, проявляем гибкость.
Помним о закрытии проекта и держим документацию актуальной.
О том, что ещё важно в работе сервисных и инхаус-аналитиков, — в презентации и видео выступления.
Что аналитики делают на проектах Data Science
Наши проекты находятся на стыке физического мира и ИТ-технологий. Аналитики помогают объединить два этих мира и сделать их понятными друг для друга.
Задачи аналитика преимущественно стандартные, но есть и свои особенности.
Анализ предметной области. Даже внутри одной сферы промышленности предприятия могут работать по разным процессам, поэтому нужно их понимать. Для этого аналитик изучает процесс производства, анализирует документацию клиента (регламенты, технологические инструкции), ищет лучшие практики, генерирует гипотезы и формирует базу знаний.
Работа с требованиями. Проводит брифы с клиентами и пользователями, формирует функциональные и нефункциональные требования, правила и ограничения, описывает пользовательские сценарии, ставит задачи для разработки.
Описание процессов. Верхнеуровнево описывает технологические процессы клиента и каждый раз составляет схему процессов конкретного клиента. Важно отметить узкие места, где будут реализовываться решения, а также их особенности и всевозможные риски.
Формирование проектной документации. Требования к составлению документов в промышленности бывают достаточно сложными, и их всегда нужно учитывать. Аналитик помогает клиенту формировать технические задания на решения, разрабатывает методики расчёта технологического и экономического эффектов, пишет отчёты и инструкции для пользователей.
И ещё кое-что. Не на всех проектах, но периодически попадают в скоуп — помощь в проектировании решений, участие в тестировании, работа с оборудованием, защита результатов и разметка датасета.
Специальные навыки
Для работы на проектах Data Science в промышленности нужны и дополнительные знания:
опыт работы на DS/ML-проектах,
навыки системного анализа,
предметная область,
готовность к командировкам.
Наши клиенты находятся на всей территории России, поэтому часто приходится выезжать на места. За последние пару лет аналитики посетили больше 20 предприятий за 50+ командировок и суммарно провели в поездках больше 200 дней. Побывали за полярным кругом, спускались на сотни метров под землю в шахты, работали на карьерах в самосвалах и экскаваторах. Командировки позволяют вживую познакомиться с процессами клиента, узнать особенности работы оборудования и, конечно, пообщаться с пользователями. А часто это нетривиальная задача.
С какими особенностями клиентов сталкиваемся
К любому клиенту нужно находить подход, но в промышленности есть свои специфические особенности.
Не готовы идти в проект без подтверждения эффектов от внедрения. Промышленники всегда стараются внедрять новые решения только на основе расчёта технического и экономического эффекта, понимая, когда это окупится. Поэтому мы в том числе плотно взаимодействуем с технологами и экономистами, помогаем в разработке методик расчётов этих эффектов и ищем рычаги, с помощью которых они могут быть достигнуты.
Признают экспертность. Иногда у клиентов предвзятое отношение к ИТ-специалистам, поэтому важно общаться с ними на одном языке. А для этого нужно подробно изучать предметную область и регламенты.
Не все пользователи «на ты» с компьютером и понимают специфику работы ML-моделей. Часто конечными пользователями наших продуктов могут быть сотрудники, которые отлично знают, как управлять сложным оборудованием в своём рабочем процессе, но к цифровым технологиям относятся с опаской. Поэтому важно хорошо понимать алгоритмы, которые лежат в основе решения, и уметь рассказать об этом простым языком.
Не все готовы делиться своими болями. Не всегда онлайн-интервью способно подсветить настоящие проблемы. И тогда командировки необходимы: ты приезжаешь на место, несколько смен наблюдаешь, как работают люди, какие журналы заполняют. А потом разговариваешь лично — и это даёт лучшие результаты.
Конечные пользователи часто с трудом принимают изменения. Важно уметь объяснить, что решения не грозят увольнениями или увеличением обязанностей, а наоборот — упростят и облегчат работу.
Как выглядят командировки аналитиков и чего ещё ждать от клиентов в промышленности, — в презентации и видео выступления.
Основа нашей работы — бизнес-анализ, но есть возможность развиваться в различных направлениях, например в анализе данных. Цель одна и та же — извлекать ценную информацию из данных, чтобы поддерживать бизнес-решения и оптимизировать процессы. Но в основе работы дата-аналитика лежат другие инструменты и задачи. Нагляднее всего их видно на том, на что направлен фокус каждого из них:
Бизнес-аналитик обычно работает с анализом бизнес-процессов, выявлением потребностей бизнеса и требованиями.
Дата-аналитик взаимодействует с большими объёмами данных, выявляет в них паттерны и тренды, формулирует и проверяет гипотезы.
Как мы к этому пришли
К дата-аналитике мы пришли с появлением предиктивных моделей, цель которых — прогнозировать события или переменные на основе исторических данных. Чтобы создать модель, их нужно проанализировать и предобработать.
Первоначально этим занимались специалисты Data Science, но, оптимизируя процессы, мы решили попробовать подход, когда все задачи по анализу данных будут закреплены за отдельным специалистом. Так появились дата-аналитики. Но проектов, где нужен анализ данных и предиктивная аналитика, оказалось не так много, чтобы мы могли их полноценно загрузить. Поэтому решили вернуться к предыдущей концепции, когда анализом данных занимается DS.
В таких проектах бизнес-аналитик сначала изучает предметную область, помогает сформулировать потребности и задачи клиента к анализу данных, передаёт это DS — и тот выполняет свою часть. На практике стало понятно, что BA нужно хорошо ориентироваться в переданных данных, а это тоже предполагает анализ.
Поэтому мы решили попробовать подход, когда задачи по анализу данных разделены между BA и DS. Для этого потребовалось обучить бизнес-аналитиков. Вместе с DS мы придумали, как будет выглядеть разделение по задачам, какие навыки нам нужны, — и они нас обучили.
Задачи по анализу данных
Теперь разделение по задачам выглядит так:
Описательный анализ данных (BA + DS). Изучаем размер набора данных, имеющихся переменных, уникальных значений, наличие пропущенных значений, основных статистических характеристик данных: среднее значение, медиана, стандартное отклонение.
Предобработка и очистка данных (BA + DS). Заполняем пустые значения, находим и очищаем выбросы, приводим переменные в разных наборах данных к одному виду. Соединяем данные из разных файлов в один набор и запрашиваем дополнительные.
Исследовательский анализ данных (BA + DS). Выявляем паттерны, тренды и аномалии в данных. Ищем взаимосвязи между переменными и изучаем распределения данных. Определяем ключевые факторы, влияющие на целевую переменную, формулируем и проверяем гипотезы.
Классификация и кластеризация (BA + DS). Классифицируем объекты на основе их характеристик — например, разделяем покупателей на сегменты. Кластеризируем данные, чтобы выявить группы схожих объектов.
Визуализация данных и подготовка отчёта (BA + DS). Визуализируем данные с помощью графиков, диаграмм и тепловых карт для лучшего понимания распределения данных. Готовим отчёты с описанием всех проведённых шагов по анализу данных и делаем заключение о возможности построения предиктивной модели.
Прогностический анализ данных (DS). Строим предиктивные модели для прогнозирования будущих событий на основе изученных данных. Оцениваем качество моделей и выбор наиболее подходящей для конкретной задачи.
Бонус от Лизы — чек-лист «Что нужно знать для анализа данных».
О том, как удалось разработать систему прогнозирования самовозгорания угля при хранении на открытом складе, — в презентации и видео выступления.
Делимся железной экспертизой от практик в нашем телеграм-канале red_mad_product. А полезные видео складываем на YouTube-канале. Присоединяйся!