Приветствую, любители аналитики!
Расскажу-ка о таком неочевидном, но важном оргвопросе в работе любой обслуживающей команды, в т.ч. дата-аналитиков, как SLA.
Service Level Agreement — соглашение об уровне предоставления услуг, это документ, фиксирующий:
* перечень предоставляемых услуг;
* порядок работы с задачами и обращениями;
* сроки реагирования и решения;
* ответственность сторон;
* раскрытие процессов, влияющих на качество и скорость работы.
Это «правила игры» между аналитической командой и заказчиками, которые помогают:
1. Сформировать чёткие ожидания. Устраняет разночтения: все понимают, что, когда и в каком виде получит заказчик.
2. Приоритезировать задачи. Помогает распределять нагрузку и определять, чьи и какие дела делать первыми.
4. Управление ресурсами. Позволяет планировать загрузку аналитиков и избегать «пожаров».
5. Разрешение конфликтов. Служит базой для обсуждения спорных ситуаций.
Наш SLA включает в себя следующие разделы.
1. Описание отдела аналитики
* Терминология
* Команды отдела и роли сотрудников
* Назначение команд
2. Перечень услуг. У моей команды:
* Настройка отправки веб-событий
* Консультирование по указанным системам
* Разработка, поддержка и обновление витрин первично обработанных данных с реализованной бизнес-логикой, а также контроль качества этих данных.
* Разработка и поддержка витрин данных (SQL-запросов) для конечных отчетов
* Разработка и поддержка сервиса Self-Analytics
* Документирование
* Управление доступами
* Политики работы с данными (политика ведения метаданных, политика доступа и т.д.)
3. Порядок обработки обращений
* как подать обращение или поставить задачу;
* время реакции на обращение, т.е. когда мы должны увидеть обращение и что-то ответить;
* когда задача будет выполнена: скажем, быстрые задачи, требующие до 3 часов на решение - делаем сразу, остальные кладем в баклог;
* стадии выполнения задачи от принятия до закрытия;
* ответственность заказчика: если поставил мегасрочную (!) задачу и пропал, не отвечает на уточняющие вопросы - пусть пеняет на себя.
4. Спринты
Это о том, что у нас есть дежурство и дежурный, который принимает входящие, и спринтовая деятельность - когда берутся задачи из баклога и выполняются.
Здесь же описывается, как и когда происходит планирование спринта, какие есть правила приоритезации, чтобы заказчик мог хоть приблизительно представить, когда его задачу возьмут в работу.
5. Критичные данные
Здесь описывается, каким классам данных в нашем аналитическом хранилище уделяется повышенное внимание (данные о юзерах, их финансах, их аккаунтах и т.д.)
Это тоже способ приоритезации задач.
Таким образом, SLA — инструмент повышения прозрачности. Он помогает:
* аналитикам — защищать своё время и фокус;
* заказчикам — получать предсказуемый результат.
Можно его назвать "договором" между аналитиком и заказчиком. Заглядывают в него редко, но если возникли сомнения или взаимное непонимание, SLA поможет понять, как поступать.
Расскажу-ка о таком неочевидном, но важном оргвопросе в работе любой обслуживающей команды, в т.ч. дата-аналитиков, как SLA.
Service Level Agreement — соглашение об уровне предоставления услуг, это документ, фиксирующий:
* перечень предоставляемых услуг;
* порядок работы с задачами и обращениями;
* сроки реагирования и решения;
* ответственность сторон;
* раскрытие процессов, влияющих на качество и скорость работы.
Это «правила игры» между аналитической командой и заказчиками, которые помогают:
1. Сформировать чёткие ожидания. Устраняет разночтения: все понимают, что, когда и в каком виде получит заказчик.
2. Приоритезировать задачи. Помогает распределять нагрузку и определять, чьи и какие дела делать первыми.
4. Управление ресурсами. Позволяет планировать загрузку аналитиков и избегать «пожаров».
5. Разрешение конфликтов. Служит базой для обсуждения спорных ситуаций.
Наш SLA включает в себя следующие разделы.
1. Описание отдела аналитики
* Терминология
* Команды отдела и роли сотрудников
* Назначение команд
2. Перечень услуг. У моей команды:
* Настройка отправки веб-событий
* Консультирование по указанным системам
* Разработка, поддержка и обновление витрин первично обработанных данных с реализованной бизнес-логикой, а также контроль качества этих данных.
* Разработка и поддержка витрин данных (SQL-запросов) для конечных отчетов
* Разработка и поддержка сервиса Self-Analytics
* Документирование
* Управление доступами
* Политики работы с данными (политика ведения метаданных, политика доступа и т.д.)
3. Порядок обработки обращений
* как подать обращение или поставить задачу;
* время реакции на обращение, т.е. когда мы должны увидеть обращение и что-то ответить;
* когда задача будет выполнена: скажем, быстрые задачи, требующие до 3 часов на решение - делаем сразу, остальные кладем в баклог;
* стадии выполнения задачи от принятия до закрытия;
* ответственность заказчика: если поставил мегасрочную (!) задачу и пропал, не отвечает на уточняющие вопросы - пусть пеняет на себя.
4. Спринты
Это о том, что у нас есть дежурство и дежурный, который принимает входящие, и спринтовая деятельность - когда берутся задачи из баклога и выполняются.
Здесь же описывается, как и когда происходит планирование спринта, какие есть правила приоритезации, чтобы заказчик мог хоть приблизительно представить, когда его задачу возьмут в работу.
5. Критичные данные
Здесь описывается, каким классам данных в нашем аналитическом хранилище уделяется повышенное внимание (данные о юзерах, их финансах, их аккаунтах и т.д.)
Это тоже способ приоритезации задач.
Таким образом, SLA — инструмент повышения прозрачности. Он помогает:
* аналитикам — защищать своё время и фокус;
* заказчикам — получать предсказуемый результат.
Можно его назвать "договором" между аналитиком и заказчиком. Заглядывают в него редко, но если возникли сомнения или взаимное непонимание, SLA поможет понять, как поступать.