Есть ли задачи, по которым отказываешься давать оценку?

Задачи, по которым отказываюсь давать оценку

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

1. Задачи с нечёткими требованиями

Когда отказываю:

• Нет понимания бизнес-целей
• Требования противоречивы или неполные
• Не определены критерии успеха
• Неясна область влияния (scope creep риск)

Пример:

Проблемное требование:
"Сделай систему быстрее. До завтра!"

Правильное требование:
"Ускори загрузку страницы профиля пользователя с 3 сек до 1 сек. 
Дедлайн: 5 рабочих дней.
Критерии: 95-перцентиль latency < 1 сек, Lighthouse score > 80"

Мой подход:

def ask_for_clarification(requirement):
    """
    Перед оценкой убеждаюсь, что все ясно
    """
    clarifications = {
        'what': 'Что конкретно нужно сделать?',
        'why': 'Зачем это нужно?',
        'when': 'Когда это нужно?',
        'scope': 'Какие компоненты затрагиваются?',
        'success': 'Как измерить успех?',
        'constraints': 'Какие ограничения?'
    }
    
    for key, question in clarifications.items():
        if requirement.get(key) is None:
            raise EstimationImpossibleError(question)

requirement = {
    'what': 'Оптимизировать загрузку',
    'why': None,  # Вот здесь красный флаг!
    'when': 'As soon as possible',  # Не конкретно
}

try:
    ask_for_clarification(requirement)
except EstimationImpossibleError as e:
    print(f"Отказываюсь давать оценку: {e}")

2. Задачи без доступа к информации

Когда отказываю:

• Нет доступа к legacy code
• Не могу запустить локально
• Нет доступа к production данным/логам
• Не понимаю текущую архитектуру

Пример:

"Сделай интеграцию с API X-компании"
Вопросы:
- Какая документация API? (может быть не полная)
- Есть ли sandbox для тестирования?
- Какие rate limits?
- Какие обработки ошибок нужны?
- Какой формат ответов?

Без ответов — риск очень высок, не могу оценить

3. Задачи с неизвестными зависимостями

Когда отказываю:

• Зависит от других команд
• Требует работ в других системах
• Синхронизация с external API
• Зависит от решения другого разработчика

Пример:

# Это невозможно оценить
class PaymentProcessor:
    def process(self, payment):
        # Зависит от:
        # 1. Платёжной системы (которая может быть недоступна)
        # 2. Anti-fraud сервиса (не знаю latency)
        # 3. Email сервиса (может быть медленный)
        
        fraud_check = await fraud_service.check(payment)  # ??
        payment_result = await payment_gateway.charge(payment)  # ??
        await email_service.send(payment_result)  # ??
        
        return payment_result

Мой подход:

В этом случае говорю Product Owner:

"Я могу оценить только нашу часть (обработка логики) = 2 дня.
Остальное зависит от других:
- Fraud Service (ответственны они, спросить их)
- Payment Gateway (интеграция, 1 день если API stable)
- Email Service (обычно быстро, 4 часа)

Тоталь: 2 + 1 + 0.5 = 3.5 дня, но с рисками"

4. Задачи с высокой технической неопределённостью

Когда отказываю:

• Нужно research
• Не знаю, сработает ли подход
• Требует экспериментирования
• Технология новая

Пример:

Проблемное требование:
"Внедри машинное обучение для рекомендаций пользователей. Сроки?"

Что я отвечу:
"Не могу дать точную оценку, т.к. это research задача.
Вариант 1: Spike (1-3 дня) → затем новая оценка
Вариант 2: Time-boxed (дам оценку через 3 дня, если успею)
Вариант 3: Agile с incremental delivery"

Подход с spike'ом:

def handle_high_uncertainty():
    """
    Когда много неопределённости:
    """
    spike_tasks = [
        "Исследовать возможные подходы",
        "Создать POC",
        "Оценить производительность",
        "Определить risks"
    ]
    
    spike_estimate = "3 дня"
    
    then_detailed_estimate = "После spike можем дать точную оценку"
    
    return f"{spike_estimate} на research → затем оценка"

5. Задачи "это же 2 часа" (но они не 2 часа)

Когда отказываю:

• Manager говорит «это легко» (но он не кодил)
• Есть скрытая сложность
• Требует работы с legacy code
• Требует координации с другими

Реальный пример:

Manager: "Это же просто, добавь поле в БД. 30 минут?"

Что на самом деле:
1. Добавить поле в модель (5 мин)
2. Написать миграцию (10 мин)
3. Обновить сериализаторы (15 мин)
4. Обновить фронтенд (30 мин)
5. Написать тесты (30 мин)
6. Код review (15-60 мин)
7. Миграция на production (15 мин)
8. Мониторинг (10 мин)

Тоталь: 2-3 часа, не 30 минут

Мой ответ: "Не 30 минут, вот почему..." + детальная оценка

6. Задачи, требующие "работать в выходные"

Когда отказываю:

• Deadline физически невозможен
• Требует crunch работы
• Нужно жертвовать качеством

Пример:

def realistic_estimate(task, deadline_days):
    """
    Говорю правду, даже если не нравится
    """
    real_days_needed = 5  # По оценкам
    
    if deadline_days < real_days_needed:
        print(f"Физически невозможно: нужно {real_days_needed}, есть {deadline_days}")
        print("Варианты:")
        print("1. Расширить deadline")
        print("2. Сократить scope")
        print("3. Добавить людей (может помочь)")
        print("4. Снизить качество (я не согласен)")
        
        raise EstimationUnfeasibleError("Cannot deliver with this deadline")

7. Задачи на технологии, которых я не знаю

Когда отказываю:

• Я не специалист в этой области
• Нужно время на обучение
• Есть более подходящий человек

Пример:

"Сделай iOS приложение на Swift"

Мой ответ:
"Я Python разработчик, не специалист iOS.
Варианты:
1. Нанять iOS разработчика (рекомендую)
2. Я могу учиться 2 недели, но не гарантирую качество
3. Использовать React Native / Flutter (кросс-платформа)"

8. Как я правильно отказываю

Правильный способ:

def decline_estimation(task, reason):
    """
    Профессионально объяснить, почему не могу оценить
    """
    response = f"""
    Я не могу дать точную оценку по причине:
    {reason}
    
    Что нужно сделать:
    {get_requirements_for_estimation(task)}
    
    Когда я смогу оценить:
    {timeline_to_clarify()}
    
    Альтернатива:
    {suggest_alternative_approach(task)}
    """
    return response

Неправильный способ:

# НИКОГДА не говорю:
print("Это невозможно")  # Слишком резко
print("Это очень сложно")  # Неконструктивно
print("Я не знаю")  # Не показывает решение
print("Давай угадаем")  # Непрофессионально

9. Когда я ДА говорю

Я дам оценку, когда:

• Требования ясны и конкретны
• Понимаю архитектуру
• Есть все нужные tools и доступ
• Известны все зависимости
• Реалистичный timeline
• Оценка включает буффер на риски

Итоговый принцип

Отказать в оценке — это не слабость, а профессиональная ответственность. Неправильная оценка стоит дороже, чем время на clarifications.

# Моя философия оценок
if wrong_estimate:
    cost = team_hours + missed_deadline + frustrated_stakeholders
    return cost > time_to_clarify()
    # True: лучше потребовать ясность