Была ли задача с просроченными сроками

# Управление просроченными сроками в работе

Да, это обычная ситуация в разработке, и она есть практически у каждого опытного разработчика. Важно не только её пережить, но и извлечь уроки.

Реальный пример из моего опыта

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

Что произошло

Вторник, за 3 дня до deadline: Мы обнаружили, что API платежного шлюза ведет себя иначе, чем описано в документации. Вместо synchronous ответа мы получали webhook callbacks с задержкой.

# Планировали так:
def process_payment(amount):
    response = payment_gateway.charge(amount)  # Предполагали synchronous
    return response.status  # Будет ready сразу

# Реальность:
def process_payment(amount):
    response = payment_gateway.charge(amount)  # Возвращает только ID
    # Статус придет через 5-30 секунд в webhook
    return response.id  # Нужно ждать асинхронного обновления

Как я это решал

День 1 (Среда): Оценка ситуации

• Понял полноту проблемы: нужна полная переработка logic
• Оценил: потребуется 3-4 дня работы для правильного решения
• Сроки: 3 дня до deadline

Варианты:

1. Попытаться "заткнуть" проблему quick fix (плохая идея)
2. Начать рефактор и признать, что deadline не успеем (честно)
3. Попросить помощь у команды

Выбрал вариант 3 + 2: Сообщил о проблеме сразу

# Отправил сообщение в Slack:
"""
Нашел критическую проблему в интеграции с платежным шлюзом.
Наша реализация неправильна — API асинхронный, а мы ожидали synchronous.

Проблема: нужна переработка payment processing logic
Оценка: 3-4 дня работы
Дедлайн: 3 дня

Опции:
1. Отложить release на неделю
2. Развернуть дополнительные ресурсы (я + 1 senior)
3. Выпустить без payment обработки (не подходит)

Я рекомендую опцию 1-2. Выпуск broken платежной системы хуже, чем задержка на неделю.
"""

День 1-2 (Среда-Четверг): Срочный рефактор

• Привлек senior коллегу
• Реализовали async payment processing с webhook handling
• Написали тесты с mock webhook callbacks

# Новое решение
from datetime import datetime
from enum import Enum

class PaymentStatus(str, Enum):
    PENDING = "pending"
    COMPLETED = "completed"
    FAILED = "failed"

class Payment(Base):
    __tablename__ = "payments"
    
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer)
    amount = Column(Decimal)
    gateway_transaction_id = Column(String, unique=True)
    status = Column(String, default=PaymentStatus.PENDING)
    created_at = Column(DateTime)
    updated_at = Column(DateTime)

def initiate_payment(amount: Decimal, user_id: int, db: Session) -> str:
    """Инициирует платеж и возвращает ID."""
    # Сразу сохраняем в БД
    payment = Payment(
        user_id=user_id,
        amount=amount,
        status=PaymentStatus.PENDING,
        created_at=datetime.now(UTC)
    )
    db.add(payment)
    db.commit()
    
    # Отправляем на платежный шлюз
    try:
        response = payment_gateway.charge(amount)
        payment.gateway_transaction_id = response.transaction_id
        db.commit()
        return payment.id
    except PaymentGatewayError as e:
        payment.status = PaymentStatus.FAILED
        db.commit()
        raise

def handle_payment_webhook(transaction_id: str, status: str, db: Session):
    """Обрабатывает webhook от платежного шлюза."""
    payment = db.query(Payment).filter(
        Payment.gateway_transaction_id == transaction_id
    ).first()
    
    if not payment:
        logger.error(f"Payment not found: {transaction_id}")
        return
    
    # Атомарное обновление статуса
    payment.status = status
    payment.updated_at = datetime.now(UTC)
    db.commit()
    
    if status == PaymentStatus.COMPLETED:
        # Отправляем confirmation письмо
        email_service.send_payment_confirmation(payment.user_id)
        # Активируем subscription
        subscription_service.activate(payment.user_id)

День 3 (Пятница): Финализация

• Развернул на staging
• Протестировал с реальным платежным шлюзом
• Найдены edge cases (timeout обработки, duplicate webhooks)

# Защита от duplicate webhooks
def handle_payment_webhook(transaction_id: str, status: str, db: Session):
    with db.begin_nested():
        # Используем SELECT FOR UPDATE для блокировки
        payment = db.query(Payment).filter(
            Payment.gateway_transaction_id == transaction_id
        ).with_for_update().first()
        
        if not payment:
            logger.error(f"Payment not found: {transaction_id}")
            raise PaymentNotFoundError(transaction_id)
        
        # Проверяем, не обновлили ли уже
        if payment.status != PaymentStatus.PENDING:
            logger.info(f"Payment already updated: {transaction_id}")
            return  # Идемпотентная операция
        
        payment.status = status
        db.commit()

День 4: Отложенный deadline

• Выпустили в production
• Разослал team retrospective

Ключевые уроки

1. Честность над оптимизмом

Мог бы я попытаться выпустить за 3 дня quick fix? Технически да, но:

• Система обработки платежей слишком критична
• Quick fix привел бы к потере денег клиентов
• Reputation damage намного хуже, чем задержка

# Не делай так в критических системах!
def process_payment_quick_fix(amount):
    transaction_id = payment_gateway.charge(amount).id
    # Надеемся, что платеж пройдет
    return {"status": "pending", "transaction_id": transaction_id}
    # Проблема: у нас нет tracking если платеж упадет

2. Раннее сообщение о проблемах

Если я сообщу о проблеме за день до deadline — это хуже, чем за 3 дня.

• День 1: Есть время на решение
• День 3: Нет времени, нужно срочно привлекать людей
• Ночь перед deadline: Полная катастрофа

3. Оценка vs реальность

Мой вывод: Всегда добавляй буфер для unknown unknowns

# Так оценивали мы изначально:
# - API интеграция: 2 дня
# - Тестирование: 1 день
# Total: 3 дня

# Так нужно оценивать для критических систем:
# - API интеграция: 2 дня
# - Тестирование: 1 день
# - Интеграция с реальным API: +1 день
# - Edge cases (webhook retries, timeout): +1 день
# - Production issues: +1 день резерва
# Total: 6 дней

4. Качество > Speed

Выпуск broken платежной системы:

• Потеря доверия клиентов
• Возможность потери денег
• Срочное патчирование в production
• 3x больше работы в итоге

Отложить deadline на неделю:

• Качественная система
• Спокойный release
• Меньше проблем в production

5. Процесс должен это предусмотреть

Этой ошибки можно было избежать:

# Лучший подход: прототип на реальном API ДО планирования спринта

# Week -1 (spike): Проверяем реальное поведение
response = payment_gateway.test_charge(10)  # Реальный тестовый платеж
print(response.status)  # Ожидаем: "pending", получаем: "pending"
# Проверяем webhook
webhook_timeout = 30  # Реальная задержка

# На основе этого оцениваем sprint
# Добавляем async processing, webhook handling в estimate

Как я это презентовал на интервью

"Когда я обнаружил проблему, мой первый инстинкт был паника.
Но я понял, что honesty и быстрое сообщение критичнее, чем hero story.

В результате:
1. Сообщил проблему сразу
2. Предложил варианты решения с trade-offs
3. Привлек помощь
4. Решили проблему правильно, пусть позже deadline

The lesson: В критических системах качество > speed.
Lучше потерять неделю deadline, чем потерять клиентов."

Общие рекомендации для просроченных сроков

1. Сообщи сразу — не жди последней минуты
2. Будь конкретен: Что случилось, какой impact, какие варианты
3. Предложи решения: Не просто плохие новости, но варианты
4. Возьми ответственность: Не ищи козла отпущения
5. Извлеки уроки: Что можно улучшить в процессе
6. Документируй: Чтобы команда избежала этого в будущем

В итоге просроченные сроки — это нормально для сложных проектов. Главное — как ты это обрабатываешь.