Словарь аналитика

Ниже я привёл все самые основные термины аналитиков данных. Советую прочитать это всё, НО не в коем разе не делайте это за один пресест!!!
Иначе напрочь отобьёте себе желаение проходить курс. Этот словарь в первую очередь сделан с расчётом, что его человек будет читать последовательно и постепенно ❛ᴗ❛

Агрегация данных (Aggregation) - это объединение и сведение данных в более крупные группы для анализа. Например, если у нас есть таблица со всеми заказами по одному за раз, то можно агрегировать эти данные и получить сумму продаж по дням, по неделям или по городам. Агрегация нужна, чтобы из большого количества мелких записей получить понятную сводную картину.

Актор (Actor) - это действующее лицо, которое взаимодействует с системой для достижения своей цели. Актором может быть человек, например пользователь сайта, менеджер или администратор, а также другая система, если она обменивается данными с нашей. В диаграммах Use Case актор показывает, кто именно запускает сценарий использования.

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

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

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

API (Application Programming Interface) - это способ, с помощью которого одна система может обращаться к другой. Если говорить проще, API - это набор правил, по которым программы обмениваются данными и командами. Например, сайт может через API получать список товаров, отправлять заказ или запрашивать информацию о пользователе. Для аналитика API важен, потому что через него часто интегрируют системы, получают данные и описывают взаимодействие между сервисами.

Артефакт требований - это любой результат работы аналитика или команды, который помогает понять систему, её поведение, ограничения и цели. К артефактам относят текстовые требования, схемы, диаграммы, таблицы, user story, use case, спецификации, модели данных и другие материалы. Проще говоря, это всё, что фиксирует знание о системе в явном виде.

Аутентификация (Authentication) - это процесс проверки, действительно ли пользователь является тем, за кого себя выдаёт. Например, когда человек вводит логин и пароль, система проверяет его данные и понимает, можно ли ему доверять. Аутентификация отвечает на вопрос: "Кто ты?" Это важная часть безопасности любой системы.

Авторизация (Authorization) - это проверка прав пользователя после того, как его уже распознали. Если аутентификация отвечает на вопрос "Кто ты?", то авторизация отвечает на вопрос "Что тебе можно делать?" Например, обычный пользователь может видеть только свои данные, а администратор - управлять другими пользователями.

Acceptance Criteria (Критерии приемки) - это набор условий, по которым команда и заказчик понимают, что задача выполнена правильно. Критерии приемки обычно пишутся для user story или функции и помогают проверить, что результат соответствует ожиданиям. Они нужны для снижения двусмысленности и споров в духе "я думал, что это должно работать иначе".

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

Backend - это серверная часть системы, которая скрыта от глаз пользователя, но выполняет основную обработку данных и бизнес-логику. Именно backend хранит информацию, принимает запросы, вызывает другие сервисы, рассчитывает результаты и отправляет ответы. Если frontend - это то, что человек видит, то backend - это то, что "работает под капотом".

База данных (Database, DB) - это место, где система хранит информацию в структурированном виде. В базе данных могут храниться пользователи, заказы, платежи, товары, логи и многое другое. Для аналитика важно понимать, как устроена база данных, потому что именно оттуда обычно берутся данные для анализа, отчётности и интеграций.

Баг (Bug) - это ошибка в системе, из-за которой она работает не так, как ожидалось. Баги могут быть мелкими, например опечатка в интерфейсе, а могут быть критичными, например неправильный расчёт денег или падение системы. Для аналитика баг важен не только как дефект, но и как повод проверить, правильно ли были сформулированы требования и ожидаемое поведение.

Бизнес - это сторона, которая определяет, зачем создаётся продукт, какую проблему он решает и какую ценность должен приносить. Когда говорят "бизнес хочет", обычно имеют в виду не абстрактную компанию, а цели, интересы и ограничения организации. Аналитику важно понимать бизнес, потому что без этого даже идеально написанные функции могут оказаться бесполезными.

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

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

Бизнес-требования (Business Requirements, BR) - это требования, которые описывают цели бизнеса, потребности организации и ценность, которую должна принести система. Они отвечают на вопрос: "Зачем вообще создаётся этот продукт или функция?" Бизнес-требования не описывают конкретные кнопки или таблицы - они задают направление и смысл всей разработки.

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

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

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

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

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

Гипотеза - это предположение, которое ещё не доказано, но которое хочется проверить на практике. В аналитике гипотеза помогает формулировать идеи вроде "если изменить экран оплаты, конверсия вырастет". После этого гипотеза проверяется с помощью данных, эксперимента или анализа поведения пользователей.

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

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

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

Dashboard (Дашборд) - это экран или набор экранов с ключевыми показателями, графиками и таблицами, которые помогают быстро оценить ситуацию. Дашборд нужен для мониторинга и принятия решений. Хороший дашборд не перегружен деталями и отвечает на конкретные вопросы пользователя.

Data Warehouse (Хранилище данных) - это специальное хранилище, куда собирают данные из разных систем для аналитики и отчётности. В отличие от обычной операционной базы данных, хранилище данных обычно оптимизировано под чтение, агрегации и анализ больших массивов информации. Для аналитика это часто главный источник данных.

Definition of Done - это набор правил, по которым команда определяет, что задача действительно завершена. Не "почти готово", не "код написан", а именно завершена. Например, задача считается done, если код написан, протестирован, выкачен и принят. Это помогает синхронизировать ожидания внутри команды.

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

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

Диаграмма - это графическое представление информации, структуры или процесса. Диаграммы помогают быстрее понять отношения между объектами, последовательность действий или общую картину системы. Аналитики используют разные диаграммы: Use Case, ERD, BPMN, Sequence и другие.

Диаграмма последовательности (Sequence Diagram) - это схема, которая показывает, в каком порядке объекты обмениваются сообщениями друг с другом во времени. Она полезна, когда нужно понять сценарий взаимодействия между системами, сервисами или компонентами шаг за шагом. Особенно полезна при описании интеграций и сложной логики.

Домен / Предметная область - это часть реального мира, которую мы изучаем и описываем в системе. Например, банковский домен, логистический домен, e-commerce, медицина. Аналитику важно понимать домен, потому что без этого нельзя качественно описать требования, сущности и бизнес-правила.

ERD (Entity Relationship Diagram) - это диаграмма, которая показывает сущности, их атрибуты и связи между ними. Проще говоря, ERD помогает увидеть, какие объекты есть в системе и как они связаны. Это важный инструмент для проектирования базы данных и понимания структуры данных.

Entity (Сущность) - это значимый объект предметной области, о котором система хранит данные. Например, пользователь, заказ, платёж, товар - всё это сущности. У сущности обычно есть свойства и связи с другими сущностями.

Endpoint - это конкретная точка API, по которой можно обратиться к системе для выполнения действия или получения данных. Например, /users, /orders/123, /payments/create. Аналитику полезно понимать endpoints, когда он описывает интеграции и контракты API.

ETL (Extract, Transform, Load) - это процесс, при котором данные извлекаются из источников, преобразуются в нужный вид и загружаются в целевую систему, например в хранилище данных. ETL нужен, чтобы собрать разрозненные данные, очистить их и подготовить для анализа. В аналитике данных это одна из базовых тем.

Feature (Фича) - это конкретная возможность продукта, которую видит или использует пользователь. Например, поиск товаров, фильтрация, вход через Google, экспорт отчёта. Фича обычно рождается из требований и должна приносить ценность пользователю или бизнесу.

Flow (Поток) - это последовательность действий, которая описывает движение пользователя, данных или процесса от одного шага к другому. Потоки часто рассматривают в use case, воронках, процессах и пользовательских сценариях. Аналитику важно понимать потоки, чтобы находить узкие места и формулировать улучшения.

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

Frontend - это клиентская часть системы, с которой непосредственно взаимодействует пользователь. Это интерфейс, кнопки, формы, таблицы, графики, экраны и всё, что человек видит на сайте или в приложении. Для аналитика frontend важен как место реализации пользовательских требований.

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

Функциональные требования (Functional Requirements, ФТ) - это требования, которые описывают, что именно система должна делать. Они говорят о функциях, действиях, реакциях и поведении системы. Например: "Система должна позволять пользователю зарегистрироваться". ФТ отвечают на вопрос: "Что делает система?"

Gap (Пробел, разрыв) - это разница между текущим состоянием и желаемым. В анализе разрывов аналитик сравнивает, как работает система сейчас, и как она должна работать в будущем. Это помогает понять, какие изменения нужны.

HTTP - это протокол, по которому клиент и сервер обмениваются запросами и ответами в вебе. Когда браузер открывает страницу, а приложение отправляет запрос на сервер - обычно это HTTP. Аналитику не нужно знать все детали протокола, но полезно понимать его логику: запрос, ответ, метод, код статуса.

Инкремент - это готовый кусок продукта, который получился после очередного этапа работы, например после спринта. Инкремент не обязательно должен быть большим, но он должен добавлять ценность и приближать продукт к конечной цели. В Scrum это важное понятие.

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

Интеграция - это соединение двух или более систем для обмена данными или совместной работы. Например, интернет-магазин может быть интегрирован с платёжной системой, CRM, службой доставки и аналитической платформой. Аналитику важно описывать интеграции точно, чтобы не было путаницы в форматах и сценариях взаимодействия.

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

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

JSON - это популярный текстовый формат обмена данными между системами. Он легко читается человеком и удобно обрабатывается программами. JSON часто используется в API, потому что позволяет структурированно передавать объекты, списки, числа, строки и вложенные данные.

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

KPI (Key Performance Indicator) - это ключевой показатель эффективности, по которому оценивают успех процесса, команды, продукта или бизнеса. KPI должен быть измеримым и связанным с целью. Например, выручка, конверсия, время ответа поддержки, процент ошибок. Аналитику важно не просто считать KPI, а понимать, зачем именно он нужен.

Lead Time - это время от момента появления задачи или запроса до полного завершения результата. Например, пользователь отправил заявку сегодня, а обработали её через три дня - это и есть lead time. Этот показатель помогает понять, насколько быстро система или команда доводит входящий запрос до конца.

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

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

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

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

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

Нефункциональные требования (Non-Functional Requirements, НФТ) - это требования, которые описывают не функции системы, а её качества и ограничения. Они отвечают на вопрос: "Как должна работать система?" Сюда относятся производительность, безопасность, надёжность, доступность, масштабируемость, удобство использования и многое другое.

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

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

OpenAPI / Swagger - это формат и набор инструментов для описания API в стандартном виде. Такое описание помогает разработчикам, аналитикам и тестировщикам понимать, какие методы есть у API, какие параметры принимаются, какие ответы возвращаются и какие ошибки возможны. Это очень полезно для документации интеграций.

ORM (Object-Relational Mapping) - это технология, которая помогает работать с базой данных через объекты языка программирования, а не только через SQL. Для аналитика это не базовая тема, но полезно понимать, почему иногда реальные таблицы и код не совпадают "один в один" по структуре.

Primary Key (Первичный ключ) - это поле, которое однозначно идентифицирует запись в таблице. Например, user_id может быть первичным ключом в таблице пользователей. Первичный ключ нужен, чтобы каждая запись была уникальной и на неё можно было ссылаться из других таблиц.

Pipeline - это последовательность этапов обработки данных или выполнения задач, где результат одного шага становится входом для следующего. В аналитике pipeline может означать поток загрузки данных, обработки, агрегации и публикации отчётов. Хорошо настроенный pipeline делает работу воспроизводимой и устойчивой.

Postcondition (Постусловие) - это состояние системы после успешного завершения сценария. В use case и требованиях постусловие помогает понять, какой именно результат должен быть достигнут. Например, после успешной оплаты заказ получает статус "оплачен".

Precondition (Предусловие) - это условие, которое должно быть выполнено до начала сценария или действия. Например, пользователь должен быть авторизован, чтобы оформить заказ. Предусловия помогают не путать нормальный сценарий с ситуацией, когда изначально не выполнены базовые условия.

Предметная область - это тот кусок реального мира, который описывает система. Если система для банка - предметная область связана с платежами, счетами, переводами, договорами, картами. Если для интернет-магазина - с товарами, заказами, корзиной и доставкой. Без понимания предметной области аналитик будет описывать систему поверхностно.

Product Owner - это роль в Scrum, которая отвечает за ценность продукта, приоритеты задач и связь с бизнесом. Product Owner решает, что важно делать сейчас, а что позже. Для аналитика это часто один из ключевых участников коммуникации по требованиям.

Производительность - это характеристика системы, показывающая, насколько быстро и эффективно она выполняет свою работу. Обычно речь идёт о времени ответа, количестве обрабатываемых операций, нагрузке и устойчивости под трафиком. Производительность относится к НФТ и часто критична для реальных систем.

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

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

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

Пользовательские требования (User Requirements) - это требования, которые описывают ожидания и потребности пользователя с точки зрения его задач. Они ближе к реальному использованию системы, чем бизнес-требования, но ещё не такие технические, как функциональные требования. Часто именно из пользовательских требований рождаются user story и use case.

Requirement (Требование) - это формализованное описание того, что должно быть реализовано или каким условиям должна соответствовать система. Хорошее требование должно быть понятным, проверяемым и не допускать двусмысленности. Требования - это основа всей разработки.

REST - это стиль построения API, при котором ресурсы системы доступны через стандартные HTTP-методы, такие как GET, POST, PUT, DELETE. REST помогает сделать интерфейс между системами более понятным и единообразным. Для аналитика это важно при описании внешних интерфейсов и контрактов API.

Ресурс - это сущность, с которой работает API или система. Например, пользователь, заказ, товар, комментарий. В REST API часто говорят, что система предоставляет доступ к ресурсам и операциям над ними.

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

Role (Роль) - это набор обязанностей, прав или функций, связанных с определённым участником процесса или системы. Роль помогает описывать действия и доступ не на уровне конкретного человека, а на уровне его функции. Например, "администратор", "менеджер", "клиент".

Scrum - это фреймворк из семейства Agile, в котором работа идёт короткими итерациями - спринтами. В Scrum есть роли, ритуалы, backlog, инкременты и понятный цикл работы. Scrum помогает команде двигаться короткими шагами и регулярно показывать результат.

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

Sequence Diagram - это диаграмма, показывающая, кто, кому и в каком порядке отправляет сообщения во времени. Особенно полезна для интеграций, распределённых систем и сложных сценариев. Она помогает увидеть логику взаимодействия в динамике.

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

SLA (Service Level Agreement) - это соглашение об уровне сервиса, в котором фиксируются обещания по качеству обслуживания. Например, процент доступности, максимальное время реакции, скорость обработки инцидентов. SLA важен, когда система оказывает услугу пользователям или бизнесу и нужно закрепить ожидания.

SLO (Service Level Objective) - это целевой показатель качества сервиса внутри системы или команды. Например, система должна быть доступна 99.9% времени. SLO похож на SLA, но чаще используется как внутренняя техническая цель.

SQL (Structured Query Language) - это язык запросов к реляционным базам данных. С помощью SQL можно выбирать, фильтровать, объединять, изменять и агрегировать данные. Для аналитика SQL - один из самых базовых и нужных инструментов.

SRS (Software Requirements Specification) - это документ, в котором требования к программному обеспечению собраны, структурированы и описаны достаточно подробно для дальнейшей разработки, тестирования и сопровождения. Это не просто "какой-то файл с требованиями", а важный артефакт, который помогает всем участникам проекта говорить на одном языке.

Stakeholder (Стейкхолдер, заинтересованная сторона) - это человек, группа людей или организация, которые влияют на систему, зависят от неё или имеют к ней интерес. Стейкхолдерами могут быть заказчики, пользователи, руководители, технические специалисты, регуляторы. Аналитику важно выявлять стейкхолдеров, потому что у каждого из них свои ожидания и интересы.

Story Points - это относительная оценка сложности user story или задачи. Story points показывают не точное время, а общий объём усилий, неопределённости и сложности. В Scrum story points часто используют для планирования и оценки velocity.

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

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

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

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

Техническое задание (ТЗ) - это документ, в котором описано, что именно нужно сделать, при каких условиях и с какими ограничениями. В разных компаниях ТЗ может быть более или менее формальным, но по сути это один из видов спецификации требований. Часто ТЗ и SRS близки по смыслу.

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

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

Use Case Scenario - это текстовое или табличное описание шагов внутри конкретного варианта использования. Если диаграмма показывает общую связь актора и цели, то сценарий показывает конкретную последовательность действий и реакций системы. Это очень полезно для детального описания пользовательских требований.

User Story - это короткая форма записи требования с точки зрения пользователя. Обычно используется шаблон: "Как [роль], я хочу [действие], чтобы [ценность]". User story помогает держать фокус не на технической реализации, а на реальной пользе для человека или бизнеса.

UML (Unified Modeling Language) - это стандартный язык моделирования, который используют для описания системы с помощью диаграмм. UML помогает визуализировать структуру, поведение и взаимодействия в системе. В аналитике чаще всего вспоминают Use Case Diagram, Sequence Diagram, Activity Diagram и Class Diagram.

Usability (Юзабилити, удобство использования) - это характеристика того, насколько интерфейс понятен, удобен и прост для пользователя. Система может быть функционально правильной, но неудобной - и тогда люди будут ошибаться, раздражаться или уходить. Юзабилити относится к нефункциональным требованиям.

Validation (Валидация) - это проверка того, что система решает нужную задачу и действительно нужна пользователю или бизнесу. Если верификация отвечает на вопрос "правильно ли мы сделали?", то валидация отвечает на вопрос "то ли мы вообще сделали?" Это очень важное различие для аналитика.

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

WIP (Work In Progress) - это количество задач, которые одновременно находятся в работе. В Kanban WIP часто специально ограничивают, чтобы команда не брала на себя слишком много и быстрее доводила начатое до конца. Это помогает сделать поток работы более устойчивым.

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

Workflow state / Статус - это текущее состояние задачи, объекта или процесса в workflow. Например, "новая", "в работе", "на проверке", "закрыта". Статусы помогают видеть, где сейчас находится объект и что с ним происходит.

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

CRUD - это четыре базовые операции над данными: Create, Read, Update, Delete - создание, чтение, изменение и удаление. Эти операции лежат в основе большинства систем, где есть работа с сущностями. Понимание CRUD помогает проще описывать API, функции и сценарии системы.

Create - операция создания новой записи или сущности в системе. Например, создать пользователя, заказ, комментарий или заявку.

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

Update - операция изменения уже существующих данных. Например, обновить адрес доставки, изменить статус заказа или отредактировать профиль.

Delete - операция удаления данных из системы. Иногда под удалением понимается физическое удаление, а иногда - логическое, когда запись остаётся в базе, но помечается как удалённая.

Класс (Class) - это понятие из объектно-ориентированного моделирования и программирования, которое описывает шаблон для объектов. Аналитику это полезно понимать, если он работает с UML или общается с разработчиками про внутреннюю модель системы.

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

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

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

Корневая причина - это настоящая причина проблемы, а не её внешнее проявление. Например, если отчёт считает неверно, это может быть не потому, что "формула плохая", а потому что входные данные дублируются. Аналитику важно искать именно корневую причину, а не лечить только симптомы.

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

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

Модуль - это логически выделенная часть системы, которая отвечает за отдельный кусок функциональности. Например, модуль оплат, модуль пользователей, модуль уведомлений. Модульность помогает делать систему понятнее и удобнее в развитии.

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

Основной сценарий - это вариант развития событий в use case, при котором всё идёт по плану и пользователь достигает своей цели без ошибок и отклонений. Это так называемый happy path. Основной сценарий обычно описывается первым.

Альтернативный сценарий - это вариант развития use case, при котором происходят отклонения от основного пути: ошибка, отказ, дополнительная проверка, исключение. Альтернативные сценарии показывают, как система ведёт себя не в идеальном, а в реальном мире.

Построение гипотез - это формулирование предположений о том, как система, поведение пользователя или бизнес-показатели могут измениться при определённых действиях. Аналитик строит гипотезы, чтобы потом проверить их через данные и не действовать наугад.

Реляционная база данных - это база данных, где информация хранится в таблицах, связанных между собой ключами. Это самый распространённый тип баз данных в бизнес-системах. SQL обычно применяется именно к реляционным БД.

Столбец / Колонка (Column) - это атрибут таблицы, то есть поле, которое хранит однотипное значение для всех строк. Например, name, email, created_at, status.

Строка / Запись (Row) - это одна конкретная запись в таблице. Например, один пользователь, один заказ, один платёж. Каждая строка содержит значения по всем колонкам таблицы.

Уровень доступа - это набор прав, который определяет, что именно пользователь может делать в системе. Например, только смотреть, редактировать, создавать или удалять. Это часть авторизации и важный элемент требований к безопасности.

Узкое место (Bottleneck) - это участок процесса или системы, который ограничивает общую скорость работы. Например, медленный этап согласования или перегруженный сервис. Аналитик ищет узкие места, чтобы понимать, где именно теряется эффективность.

Хранилище данных - это место, где данные собираются и организуются для анализа, отчётности и долгосрочного хранения. В отличие от обычной оперативной базы, хранилище данных больше заточено под аналитические запросы.

Ценность (Value) - это польза, которую получает пользователь, бизнес или система от функции, изменения или решения. Без ценности задача может быть технически интересной, но бесполезной. Для аналитика умение видеть ценность - один из главных навыков.

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