Как мы оптимизировали работу BI-аналитиков? Пошаговая инструкция

Привет! Меня зовут Наташа Базанова, я старший аналитик Selectel. В компании я работаю три года: за это время команда аналитиков сильно расширилась, число задач и их амбициозность выросли. Как и любая другая команда, мы столкнулись с проблемами, связанными с несовершенством бизнес-процессов. Расскажу, что мы предприняли, чтобы работать эффективнее и слаженнее.

Структура команды BI-аналитиков

Немного расскажу о своей команде и о том, как она выглядит сейчас. На данный момент в ней 10 человек, которые разделены на два отдела с разными задачами:

• Проектирование аналитических решений (4 человека). Команда занимается ad-hoc- аналитикой и сбором требований для разработки отчетности в BI. Также эти сотрудники впоследствии тестируют и поддерживают созданные отчеты. 
• BI-разработка (6 человек). Команда управляет BI-системой и непосредственно разрабатывает приложения в Qlik Sense. Также в нее входят два дата-инженера, которые администрируют хранилище баз данных и настраивают интеграции с различными источниками.

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

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

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

От многофункциональных сотрудников — к профильным

Как было

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

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

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

Решение

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

Так мы и пришли к разделению на два отдела. BI-разработка c сильными хард-скиллами, знанием языков программирования, умением строить и работать с моделями данных. И отдел проектирования аналитических решений с аналитиками-менеджерами (методологами) — с развитыми навыками в области коммуникаций, планирования, ведения понятной документации, Excel, SQL. Конечно, есть и общие знания, которые нас объединяют: математика, статистика, базовые подходы к визуализации данных.

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

Определяемся с зонами ответственности и визуализируем бизнес-процессы 

Как было

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

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

Решение

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

Благодаря визуализации сразу стало понятно, каких этапов в работе не хватает, где узкие места и противоречия в понимании процессов.

К каким выводам мы пришли после визуализации:

1. Не хватает планирования загрузки, задачи распределяются стихийно. Без этого этапа не получается адекватно прогнозировать сроки выполнения задачи, а значит, мы не можем назвать заказчику даже примерные сроки окончания проекта. О внедрении этого этапа я подробнее расскажу ниже.
2. Мы пропускали этап составления технической документации по отчетам. Без нее в будущем сильно повышался порог входа в задачу на доработку аналитических дашбордов, а это в работе аналитиков не редкость. В итоге этап документации добавили в конце каждого отдельного процесса по работе с данными. Документацию пишут и инженеры БД, которые собирают данные, и разработчик, построивший модель и создавший дашборд, и методолог, работающий с заказчиком.
3. Поняли, что чисто техническое код-ревью должно идти до этапа ревью. При обратном порядке в случае наличия правок тестировщику отчета придется дважды выполнять свою работу.

Четкость ведения задач обеспечивают чек-листы, которые фиксируют, что нужно проверить перед тем, как двинуть задачу дальше по процессу. Так, у нас есть чек-листы на разработку в DataWarehouse, на разработку приложения (дашборда) в Qlik и его ревью.

Вводим четкое планирование задач: снижаем уровень стихийности в работе 

Как было

Следующая проблема, которую мы решали, — это хаос при заведении задачи, их стихийное принятие в работу. Не всегда было понятно, какой задачей на текущий момент занимается конкретный член команды, есть ли проблемы в реализации, не меняются ли сроки исполнения. У этого было неприятное последствие в виде большого количества встреч для синхронизации. В неделю могло быть от 8 до 10 встреч, то есть минимум 32 встречи в месяц. При этом я говорю не о стендапах на 5-10 минут, а о весомых для рабочего дня отрезках времени — от получаса до двух часов.

Решение

Нам все еще не хватало прозрачности в работе, поэтому мы внесли изменения, которые позволили отслеживать статус задач без необходимости задавать вопросы и устраивать дополнительные встречи.

Докрутили наше рабочее пространство в Jira с учетом бизнес-процессов

Во-первых, перешли на двухнедельные спринты. Затем добавили недостающие этапы движения задачи — всего у нас получилось 7 этапов. Как многие знают, в Jira есть классические to do, in progress, waiting, done (или closed). Мы добавили три статуса, связанных с ревью, — code review, review, customer review.

Поясню, что это за ревью, на примере задачи.

Допустим, нам нужно построить дашборд по публикациям с Хабра. В рамках первого этапа собираем данные с площадки, а вторым этапом строим на них дашборд.

Если на первом этапе ошибка, во втором ничего не получится. Поэтому мы обязательно проверяем, что данные соответствуют интерфейсу (как на Хабре), что нет аномалий, что данных для построения дашборда достаточно. Такая проверка — это обычное ревью, которое выполняет методолог как человек, который собирал ТЗ, ставил задачи и понимает, к какому результату мы идем.

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

Обычное ревью методологом также есть на втором этапе. На нем он тестирует скорость работы дашборда, снова проверяет цифры и то, что дашборд отвечает на вопросы, поставленные в ТЗ…

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

Также мы добавили несколько типов задач. Кроме epic (крупной задачи, включающей в себя несколько подзадач) и стандартной таски (task), у нас есть задачи с типом dev, bug, access. С типом dev создаются задачи для BI-разработчиков и инженеров БД. В bug, как можно понять из названия, мы добавляем задачи, связанные с поиском и исправлением ошибок в существующих отчетах. Задачи с типом access — это таски на выдачу доступов к BI-системе.

Типы мы добавили для того, чтобы у каждой задачи был свой процесс, релевантный только ей. К примеру, у задач с типом dev есть статус код-ревью, потому что они связаны с разработкой. У других типов (epic, task, access) этих статусов нет, поскольку в рамках этих задач не создается код. Задачи с типом bug — высокоприоритетные задачи, которые входят в спринт без планирования, их мы решаем в первую очередь. А у типа access есть уникальный этап согласования доступа у руководителя сотрудника, который запрашивает доступ к BI-системе.

Планируем и распределяем задачи на спринт

Перед началом каждого двухнедельного спринта собираемся на отдельную встречу по его планированию: с помощью специальной разметки задач (тег sprint или backlog) в Jira заранее составляем драфт спринта и оцениваем его. Также на встрече приоритезируем задачи и обсуждаем спорные моменты — например, если на одного разработчика выпадает две крупные доработки в разные дашборды. Нужно решить, что взять в первую очередь и нужно ли подключить к работе другого разработчика.

Помимо этого, добавили ведение ежедневных to-do-lists в Confluence — назвали его Scooby-to-Doo. Накануне или утром рабочего дня записываем, что планируем сделать за день (задачи и встречи), а в конце отмечаем, что в итоге удалось. Такая практика помогает фокусироваться на планах, а также хорошо заменяет устное дейли.

Внедрили story points для оценки объема задачи и загруженности на спринт

Оцениваем в них разработку отчета или дашборда.

В оценке мы используем числа Фибоначчи. Это хорошая методика, которая позволяет получить довольно реалистичную оценку того, что можно успеть сделать. Также она помогает оценивать задачи с высоким уровнем неопределенности, когда при постановке не до конца понятен полный объем работ и могут долетать доработки (актуальная для нашей команды история).

Спринт в департаменте длится 80 часов. У каждой команды свое число часов, доступное под решение задач: у BI-разработчиков — 60 часов, у методологов — 45 часов. Остальные часы тратятся на встречи, коммуникации в команде, переключение контекста, прояснение спорных моментов и т.д.

Основное правило по наполнению спринта — чтобы сумма баллов не превышала 13. В остальном конфигурация задач может быть разной: могут быть две задачи на 8 и 5 баллов. Или три задачи на 3 балла и две — на 2 балла.

Организовали отдельный Telegram-чат под багрепорты без флуда

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

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

Что мы получили в результате? 

• Все сотрудники знают, чем и в каком порядке они будут заниматься следующие две недели. Методологи, которые общаются с заказчиками, понимают, на какие результаты и в какие сроки им рассчитывать. 
• Мы стали прогнозировать результат для большинства задач — за исключением больших проектов с высоким уровнем неопределенности.
• Количество командных встреч по задачам сократилось до 3, максимум 4 в неделю, то есть в месяц выходит 11-12 встреч против 32 до оптимизации. 
• Все члены команды в курсе неполадок и их статуса.

Ведем базу знаний команды

Как было 

Команда BI-аналитиков выросла из двух человек. Как правило, в таких случаях «старички» становятся единственными носителями уникальных знаний о ранее выполненных проектах. Это плохо, потому что «новое поколение» не знает, почему аналитика реализована именно так, можно/нужно ли это редактировать и как развивать отчеты без опасений сломать что-нибудь важное. Поэтому важно фиксировать все знания в единой базе.

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

Решение

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

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

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

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

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

Почему изменения удались

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

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

Самый простой, на мой взгляд, путь к изменениям лежит через солидарность в команде. Важно, чтобы все участники сами их захотели. Для этого нужно систематически интересоваться ходом задач: выявлять проблемы и их источник, предлагать решения или искать их вместе. В нашей команде BI-аналитиков этот путь начался с ретроспективы, которая длилась 4 часа. На ней мы выделили проблемы и приоритезировали их с помощью голосования. Затем разбились на рабочие группы по интересам. Миссия каждой группы заключалась в том, чтобы придумать варианты решения проблемы, проработать их, представить команде и внедрить.

Большую часть проблем нам удалось решить:

• Значительно сократили объем легаси благодаря доступной, своевременной документации и мероприятиям по онбордингу.
• Пришли к оптимизации временных затрат на задачу через распределение зон ответственности.
• Сформулировали и автоматизировали бизнес-процессы в Jira, что позволило обеспечить прозрачность этапов работы над задачей и существенно сократить число бесполезных коммуникаций внутри команды.
• Определили базовые правила оценки задач — это позволило построить процесс планирования и приоритизации. В итоге это сказалось на взаимодействии с заказчиками — коллеги стали понимать, на что им рассчитывать и почему сроки именно такие.

Конечно, не все так оптимистично. Есть проблемы, которые мы продолжаем решать:

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