Чем будешь руководствоваться при выборе сложной задачи?

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

Критерий 1: Влияние на бизнес (Impact)

Первый вопрос: как эта задача влияет на бизнес-метрики?

• Увеличивает ли выручку напрямую или косвенно?
• Снижает ли техдолг, который замедляет разработку?
• Улучшает ли надежность критичных систем?

// Пример: оптимизация поиска юзеров в БД
// Задача сложная, но если это 80% времени API -> высокий импакт
const searchUsers = async (query) => {
  // Было: O(n) scan всей таблицы
  // Будет: indexed full-text search за O(log n)
  return db.query("SELECT * FROM users WHERE ...");
};

Сложная задача оптимизации может сэкономить часы для всех пользователей.

Критерий 2: Риск и неопределённость

Два типа сложности:

• Техническая сложность — я могу разобраться, но потребует времени (лучше выбирать такие)
• Неопределённость — никто не знает, как правильно решить (требует исследования, спайков)

Я выбираю задачи с высокой технической сложностью, но низкой неопределённостью. Если оба показателя высокие, сначала делаю spike — исследовательский прототип:

// Spike: проверка, возможна ли интеграция с новой БД
const testNewDatabase = async () => {
  // Быстрый прототип без полной реализации
  const conn = await newDB.connect();
  const perf = await measureQueryPerformance();
  return perf; // Результат: решилась ли неопределённость?
};

Критерий 3: Зависимости и блокирующие факторы

Зависит ли задача от других?

• Если это критичная часть для других разработчиков → приоритет выше
• Если я её решу, разблокирую 3 других задачи → высокий приоритет
• Если от неё никто не зависит → низкий приоритет

Пример приоритизации:
1. Задача A (сложная, но блокирует Б, В, Г) → первая
2. Задача B (средняя сложность, решает ошибку в проде) → вторая
3. Задача C (очень сложная, но рефакторинг) → третья (если есть время)

Критерий 4: Время на выполнение vs Срок

Реальный вопрос: могу ли я написать чистый код за отведённое время?

Я не беру задачу, которую по оценкам нужно 10 дней, когда есть 3 дня. Лучше взять более простую, но качественно её реализовать. Потом вернусь к сложной, когда будет время.

// Реальный пример: миграция БД на новую версию
// Оценка: 5 дней для качественной работы
// Доступно: 3 дня
// Решение: разбиваю на фазы, делаю первую часть за 3 дня,
// остальное - следующей спринт
const migrateDatabase = async () => {
  // Phase 1: подготовка и тестирование (3 дня)
  // Phase 2: миграция на проде (5 дней)
  // Phase 3: оптимизация (2 дня)
};

Критерий 5: Возможность обучения (Learning)

Я выбираю задачи, которые:

• Учат новой технологии или паттерну
• Расширяют мое понимание системы
• Полезны для карьерного роста

Даже если сложная задача не критична для бизнеса, если она научит меня чему-то ценному → беру.

Практический алгоритм выбора

// Матрица для принятия решения
const shouldTakeComplexTask = (task) => {
  const score = 
    task.businessImpact * 0.4 +        // 40% влияние на бизнес
    task.technicalChallengeLevel * 0.2 + // 20% техническая сложность
    (task.unblocksDependencies > 0 ? 30 : 0) + // 30% если разблокирует других
    task.learningValue * 0.1;           // 10% обучение
  
  return score > 65 && task.timeEstimate <= task.timeAvailable;
};

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