Сдвигались ли дедлайны на проекте

Управление дедлайнами в ML-проектах: личный опыт

Это вопрос о реальности работы в Data Science. Да, дедлайны сдвигались много раз, и это нормально. Расскажу, как я с этим работаю и что я из этого извлёк.

Истина о дедлайнах в ML

Когда я начинал карьеру, я наивно думал, что можно спланировать ML-проект как обычный разработку software'а. Это была ошибка. На моём первом проекте — прогнозирование оттока клиентов — был дедлайн в конце квартала. Что произошло:

План: 3 недели

• Неделя 1: Подготовка данных
• Неделя 2: Разработка моделей
• Неделя 3: Deploy

Реальность: 6 недель

• Неделя 1: Данные были грязнее, чем ожидалось (дублипикаты, пропуски в 40% записей)
• Неделя 2: Обнаружили, что целевая переменная определена неправильно (бизнес изменил определение дефолта)
• Неделя 3-4: Feature engineering требовал много исследований
• Неделя 5: Модели показывали AUC 0.65, нужна была отладка
• Неделя 6: Валидация и согласование с stakeholders

Дедлайн сдвинулся на 2 недели.

Почему дедлайны сдвигаются в ML

1. Качество данных (самая частая причина)

Данные редко соответствуют ожиданиям:

import pandas as pd
import numpy as np

# Реальный пример из проекта
df = pd.read_csv('production_data.csv')

print('ОЖИДАНИЯ:')
print('  Размер: 100K строк')
print('  Признаков: 30')
print('  Пропусков: <5%')
print('  Дубликатов: 0')

print('\nРЕАЛЬНОСТЬ:')
print(f'  Размер: {len(df)} строк')
print(f'  Признаков: {df.shape[1]}')
print(f'  Пропусков: {df.isna().sum().sum() / (len(df) * df.shape[1]) * 100:.1f}%')
print(f'  Дубликатов: {df.duplicated().sum()}')
print(f'  Типов данных: {df.dtypes.unique()}')

# Сюрпризы
if df.duplicated().sum() > 0:
    print(f'  → Неожиданные дубликаты!')
if df['target'].isna().sum() > 0.1 * len(df):
    print(f'  → Много пропусков в целевой переменной!')
if (df['date'] > pd.Timestamp.now()).any():
    print(f'  → Даты в будущем!')
if (df['amount'] < 0).any():
    print(f'  → Отрицательные суммы!')

Каждая проблема требует 1-2 дней для диагностики и исправления.

2. Изменение требований бизнеса

Очень частая ситуация:

Вторник 10:00 AM
Стейкхолдер: Нам нужно предсказать мод на следующий месяц

Вторник 3:00 PM
Стейкхолдер: Ой, нет, нам нужно на неделю

Среда 9:00 AM  
Стейкхолдер: Стоп, а может на день? Нам для реал-тайма нужно!

Пятница
Я: Переделал всё трижды, дедлайн сдвигается на неделю

Это добавляет 2-3 дня на каждое изменение.

3. Исследовательская природа ML

Ни я ни кто-то другой не может точно предсказать результат экспериментов:

# День 1: Попробовали базовую логистическую регрессию
model_lr = LogisticRegression()
model_lr.fit(X_train, y_train)
auc_lr = roc_auc_score(y_val, model_lr.predict_proba(X_val)[:, 1])
print(f'Логистическая регрессия: AUC = {auc_lr:.2f}')  # 0.68
# Недостаточно! Нужно 0.75+

# День 2: Random Forest
from sklearn.ensemble import RandomForestClassifier
rf = RandomForestClassifier(n_estimators=200)
rf.fit(X_train, y_train)
auc_rf = roc_auc_score(y_val, rf.predict_proba(X_val)[:, 1])
print(f'Random Forest: AUC = {auc_rf:.2f}')  # 0.72
# Лучше, но ещё недостаточно

# День 3: XGBoost
import xgboost as xgb
xgb_model = xgb.XGBClassifier(n_estimators=100, max_depth=5)
xgb_model.fit(X_train, y_train)
auc_xgb = roc_auc_score(y_val, xgb_model.predict_proba(X_val)[:, 1])
print(f'XGBoost: AUC = {auc_xgb:.2f}')  # 0.74
# Близко!

# День 4-5: Hyperparameter tuning
from sklearn.model_selection import GridSearchCV
param_grid = {'max_depth': [3, 5, 7], 'learning_rate': [0.01, 0.05, 0.1]}
# ... долгий GridSearchCV
# Итог: AUC = 0.76

# План был: День 1-2 на модель. Реальность: День 1-5

4. Переобучение, которое не видно до production

# На валидации выглядит отлично
auc_val = 0.85  # Wow!

# На тесте хуже
auc_test = 0.72

# На production данных ещё хуже
auc_prod = 0.58  # Дрифт!

# Причина: данные в production отличаются от train/val
# Нужно переделать feature engineering
# Ещё 3-5 дней работы

Как я управляю дедлайнами

1. Буфер на неопределенность (30-50%)

Оценка алгоритма: 2 недели
↓
План с буфером: 2 * 1.3 = 2.6 недель (~18 дней)
↓
Дедлайн берем: 20 дней

Это позволяет впитать непредвиденные проблемы без переделок

2. Итеративный подход вместо водопада

ВЕДОПАД (плохо):
Неделя 1: Данные → Неделя 2: Модель → Неделя 3: Валидация → Deploy
Если что-то сломалось на неделе 2, всё падает

ИТЕРАТИВНО (хорошо):
Итерация 1 (5 дней): Baseline + простая модель
  ↓ Review с бизнесом
Итерация 2 (5 дней): Advanced models + hyperparameter tuning  
  ↓ Review
Итерация 3 (5 дней): Deploy ready version
  ↓ Готово!

Всё можно показывать раньше, быстрее получить feedback

3. Risk Assessment от начала

risks = [
    ('Качество данных', 'HIGH', 'Нужен аудит данных на неделю 1'),
    ('Feature engineering', 'MEDIUM', 'Если скучные признаки, нужно больше времени'),
    ('Требования бизнеса', 'HIGH', 'Stakeholders часто меняют ум'),
    ('Performance целей', 'MEDIUM', 'Может быть сложнее достичь AUC 0.75'),
    ('Переобучение', 'MEDIUM', 'Риск дрифта на production'),
]

for risk, severity, mitigation in risks:
    if severity == 'HIGH':
        print(f'{risk}: добавить 3-5 дней буфера')
    elif severity == 'MEDIUM':
        print(f'{risk}: добавить 1-2 дня буфера')

4. Коммуникация ранних результатов

Не жду конца, чтобы показать результаты:

• День 2: Показать baseline результаты
• День 5: Показать best model, обсудить достижимые метрики
• День 8: Показать production-ready версию

Это позволяет скорректировать ожидания раньше.

Реальные примеры сдвигов дедлайна

Проект 1: Fraud Detection для платёжной системы

Оригинальный дедлайн: 4 недели
Сдвиги:
  + 1 неделя: Данные очищены медленнее, чем ожидалось
  + 3 дня: Требование изменилось (нужна интерпретируемость)
  + 2 дня: Hyperparameter tuning требовал больше времени
  
Итоговый срок: 5.5 недель
Выучился: всегда добавляй 50% буфера для финансовых проектов

Проект 2: Рекомендательная система

Оригинальный дедлайн: 6 недель
Сдвиги:
  - 1 неделя: Feature engineering оказалась проще
  + 2 дня: A/B тестирование требовалось
  + 1 день: Багфиксы после первого deploy
  
Итоговый срок: 6.5 недель
Выучился: A/B testing нужно планировать в сроки!

Проект 3: Прогнозирование спроса

Оригинальный дедлайн: 3 недели
Сдвиги:
  + 2 недели: Данные содержали выбросы (праздники, спецпредложения)
  + 1 неделя: Seasonal patterns требовали специального подхода
  + 3 дня: Бизнес хотел разные модели для разных типов товаров
  
Итоговый срок: 6 недель (В 2 раза дольше!)
Выучился: time series требует больше исследований

Переговоры о дедлайнах

Когда ясно, что не успеем:

# НЕПРАВИЛЬНО
Бегу к менеджеру в последний день: "Не успеем! Дайте ещё неделю!"

# ПРАВИЛЬНО
На 5 день видно, что есть проблема
Практикую два сценария:

Сценарий A (идеальный): Доставим с AUC 0.75+ в срок (+5 дней)
Сценарий B (реалистичный): Доставим с AUC 0.70 в срок (+2 дня)
Сценарий C (минимум): Доставим с AUC 0.65 в срок (в срок)

Предлагаю бизнесу выбрать. Обычно выбирают А или В.

Советы на основе опыта

1. Всегда добавляй 30-50% буфера к первоначальной оценке
2. Оценивай данные на неделе 1 — это главный риск
3. Показывай результаты еженедельно — быстрее получишь feedback
4. Используй MVP подход — доставь работающую модель, потом улучшай
5. Задокументируй риски — легче объяснить сдвиги
6. Договорись о метриках успеха на старте, а не в конце
7. Тести на реальных данных как можно раньше
8. Будь честен с бизнесом о том, что возможно за оставшееся время

Вывод

Дедлайны в ML практически всегда сдвигаются — это нормально. Ключ к успеху:

• Реалистичные оценки с буфером
• Ранняя коммуникация о рисках
• Итеративный подход, а не водопад
• Честность с stakeholders

Мои проекты теперь заканчиваются в срок чаще, потому что я лучше планирую и управляю ожиданиями.