Data Analyst / Аналитик данных
Назад

Пример регламента · Data Analyst / Аналитик данных

Регламент работы аналитика данных

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

Паспорт регламента

Код
EXAMPLE-REG-DATA-ANALYST
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
Руководитель аналитики данных
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

Цель регламента

Помогать команде принимать решения на проверенных данных, явно показывая определения метрик, качество источников, неопределенность и ограничения анализа.

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • Доступ к персональным данным для анализа должен соответствовать исходной или совместимой цели и полномочиям; новый аналитический интерес сам по себе не создает правового основания.
  • Обезличивание считается достаточным только когда принадлежность данных человеку невозможно определить без дополнительной информации; простая замена имени на ID обычно является псевдонимизацией.

Что проверить до начала работы

  • Названы заказчик результата, владелец решения, исполнители, согласующие лица и канал эскалации.
  • Зафиксированы цель, ожидаемый результат, границы задачи, срок, приоритет, зависимости и критерии приемки.
  • Определена классификация информации: публичная, внутренняя, конфиденциальная, коммерческая тайна или персональные данные.
  • Подтверждено, что специалист имеет необходимые доступы и полномочия, а лишние права не выдаются.
  • Понятно, где хранится актуальная версия результата и какие записи подтверждают выполненную работу.
  • Analytics brief содержит цель, решение, владельца, состав и происхождение данных, правовое основание, период, сегменты, получателей и срок хранения результата.
  • Проверено, разрешены ли объединение источников, построение профиля, экспорт и передача результата выбранной аудитории.

Зона ответственности

  • Продуктовая и бизнес-аналитика, SQL-исследования, отчетность, дашборды, эксперименты, сегментация, прогнозные и диагностические расчеты.
  • Аналитик отвечает за корректность метода и прозрачность вывода, но решение и допустимый риск остаются у владельца бизнес-контекста.

Обязанности специалиста

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

Рабочий порядок

  1. Согласовать вопрос, получателя, решение, метрику успеха и срок актуальности.
  2. Описать источники, гранулярность, период, сегменты, фильтры и критерии качества.
  3. Подготовить воспроизводимый датасет и провести sanity checks.
  4. Выбрать метод анализа, проверить устойчивость и оценить неопределенность.
  5. Сформулировать вывод, ограничения и рекомендуемое действие.
  6. Для регулярного результата назначить владельца, расписание, мониторинг и change log.

Контрольные вопросы специалиста

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

  1. Какое решение поддерживает анализ и соответствует ли оно цели сбора данных?
  2. Нужны ли row-level данные или достаточно агрегатов и выборки?
  3. Можно ли исключить прямые и косвенные идентификаторы до получения доступа?
  4. Не позволяет ли комбинация редких сегментов повторно идентифицировать человека?
  5. Есть ли специальные категории данных или данные несовершеннолетних?
  6. Кто увидит отчет, сможет выгрузить детализацию и сопоставить ее с другими источниками?
  7. Как обрабатываются запросы на исправление или удаление исходных данных в витринах и отчетах?
  8. Не подменяет ли модель вероятностный вывод фактом и не создает ли дискриминационный эффект?
  9. Когда должны быть удалены временный датасет, notebook export и локальные файлы?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Применять column/row-level access, маскирование, минимальный размер сегмента и запрет детализации там, где высок риск повторной идентификации.
  • SQL, notebooks и BI extracts не должны содержать секреты; временные таблицы и локальные экспорты удаляются после завершения анализа.

Обязательные артефакты

  • Analytics Brief
  • Metric Dictionary
  • SQL или аналитический notebook
  • Data Quality Report
  • Decision Report или dashboard
  • Analytics Product Passport

Критерии качества

  • Числа воспроизводятся из зафиксированных источников и версии кода.
  • Метрики имеют определение, владельца, гранулярность и правила фильтрации.
  • Вывод отвечает на согласованный вопрос и не сильнее доступных доказательств.
  • В отчете видны ограничения, диапазон неопределенности и следующее действие.

Контрольные точки

  • До анализа подтверждены вопрос, решение, период, сегменты и критерий достаточного ответа.
  • До публикации пройдены проверки качества, здравого смысла и peer review критичного расчета.
  • Перед запуском dashboard подтверждены владелец метрики, SLA обновления и поведение при неполных данных.
  • После изменения источника или формулы выполнены impact analysis, пересчет истории и уведомление потребителей.

Антипаттерны

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

Рабочий ритм и периодический контроль

  • По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
  • Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
  • Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
  • После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
  • Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
  • Ежемесячно для регулярных продуктов: проверять владельца, цели использования, права, freshness, качество, малые сегменты, exports и retention.

Метрики контроля

Доля воспроизводимых расчетовПокрытие метрик владельцами и определениямиData freshness SLAКоличество расхождений метрикВремя от вопроса до решенияИспользование аналитических продуктов

Коммуникации и эскалация

  • Риск неверных или неполных данных сообщается до презентации вывода.
  • Изменение определения метрики заранее согласуется с владельцами и фиксируется в changelog.
  • Критичный анализ проходит peer review, а спорные допущения выносятся в явный decision log.

Матрица обязательной эскалации

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

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • Анализ завершен после peer review, проверки качества и ограничений, фиксации метода и версии, безопасной публикации результата и удаления временных данных.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Хранить analytics brief, data lineage, metric contract, versioned SQL/notebook, quality report, access list и решение; персональные выгрузки не прикладывать к презентациям.

Нормативная основа и официальные материалы

Перед применением требований проверяйте актуальную редакцию документа и внутренние назначения ответственных лиц.