Бизнес Flashcards
Как получаете тех задание? #Иннотех
o Обычно техзадание формируется аналитиками или заказчиком.
o Может быть документ (ТЗ, BRD) или Jira-эпик с описанием требований.
o Важна обратная связь: уточнение деталей, согласование форматов данных, сроков.
Есть ли проверка data quality или проверка на отклонения в данных? #Иннотех
o Да, DQ-контролли (валидаторы, SQL-чеки, проверки схемы).
o Сравнение с эталонными наборами данных или допустимыми диапазонами.
o Автоматические проверки и мониторинг метрик (количество строк, дубликаты, аномалии).
Если выявились ошибки в витрине данных и заказчик недоволен — что делать? #t1
o Анализировать причину (источник данных, ETL-процедуры, логика агрегаций).
o Оперативно исправить ошибку и перезагрузить данные.
o Внедрить дополнительные проверки (DQ, тесты) для предотвращения повторений.
С какими-нибудь системами трекинга задач работал? #ЛигаЦифровогоИнтернета
o Jira, Trello, Redmine, YouTrack, Asana, Monday.
o Обычный процесс: постановка задачи, спринты, эстимейты, контроль статуса.
Как работаете с legacy? #Teza hedge fund
o Пошаговый рефакторинг или миграция на более современные платформы.
o Обратная инженерия (reverse engineering) для понимания текущей логики.
o Постепенный перевод функциональности, тестирование на каждом этапе.
Через какие этапы проходит бизнес-задача? #альфа
Постановка цели и гипотезы: что именно хотим достичь, какие KPI важны.
Сбор требований: какие метрики нужны (P&L, конверсия, время до сделки и т.д.), какие источники данных есть и какова частота обновления.
Сбор и проверка данных: выгрузка, очистка, проверка качества, согласование с бизнесом, корректны ли данные.
Анализ и расчёт: агрегируем, считаем метрики, строим модели или отчёты, формируем гипотезы.
Валидация / интерпретация: сопоставляем результаты с реальностью, логикой бизнеса, возможно, делаем ручные «спот-проверки».
Внедрение и мониторинг: создаём витрину/отчёт, делаем дашборд, контролируем регулярность, отслеживаем динамику KPI.
Допустим, запустился новый проект (новый продукт). Нужно собрать P&L, time to DIL, time to money, конверсию. Но исторического эталона данных нет. Как проверить, что расчёты корректны? #альфа
- P&L (Profit & Loss): сопоставить доходы/расходы с бухгалтерскими проводками, управленческой отчётностью.
- Time to DIL / time to money: чётко определить бизнес-события, между которыми меряем интервал (например, от момента заявки до сделки, или от сделки до фактической «выдачи денег»).
- Конверсия: определить воронку (из скольких потенциальных клиентов какой % дошёл до конечного шага).
- Без эталона:
1. Перекрёстная проверка: сверить результаты с независимыми источниками (CRM, бухгалтерские системы).
2. Логический «Sanity check»: реально ли эти метрики выглядят правдоподобными?
3. Ручная выборка: проверить несколько ID клиентов, чтобы убедиться, что все даты и суммы подсчитаны верно.
Сравнить с ожиданиями продукта: если сильно расходится, возможно, неправильно поняты бизнес-процессы
У нас есть выгрузка на 10 тысяч строк. Какие проверки делать — бизнесовые и технические? #альфа
Технические проверки:
o Типы данных (даты, числа, строки).
o Пропуски (NULL) в критических полях.
o Наличие дублей (по ключам).
o Аномалии (слишком большие или отрицательные значения там, где быть не должно).
Бизнес-проверки:
o Соответствие объёма строк приблизительно ожидаемому количеству (сверка с «крупной» статистикой).
o Логика дат (дата выдачи не должна быть раньше даты заявки).
o Проверка сумм по нескольким случайным кейсам вручную (согласованы ли цифры?).
o Сопоставление итоговых агрегатов с уже известными цифрами (например, из другого отчёта или CRM).
