Что делаешь в случае когда разработчик берет задачу не его уровня

Управление когда разработчик берёт задачу не его уровня

Этот сценарий часто встречается в разработке и требует грамотного подхода как со стороны разработчика, так и со стороны руководителя или коллег. Решение зависит от конкретной ситуации и целей.

1. Диагностика ситуации

Сначала нужно определить, что произошло:

Вариант 1: Junior берёт Senior задачу

• Слишком сложная архитектура
• Требует глубокого знания системы
• Высокий риск некачественной реализации
• Может заблокировать других разработчиков

Вариант 2: Senior берёт Junior задачу

• Недоиспользование потенциала
• Низкая эффективность работы
• Замедление развития Junior разработчиков
• Неоптимальное распределение нагрузки

Вариант 3: Middle берёт задачу на грани его возможностей

• Возможность роста и обучения
• Требуется mentoring и support

2. Как понять, что разработчик не тянет задачу

Когда задача слишком сложная:
- Разработчик не знает с чего начать
- Не может разбить на подзадачи
- Просит слишком много помощи на ранних этапах
-估ок выходит низкого качества
- Много ревизий в code review
- Расходует время на "лишние" подходы

3. Действия при неправильном распределении

Шаг 1: Ранний разговор (в первый день работы над задачей)

Если разработчик понимает, что задача сложная:

Разработчик: "Я начал на задачу X, но это выглядит сложнее чем я ожидал"
Руководитель: "Окей, давай разберёмся. На каком этапе ты застрял?"

→ Определить точную проблему
→ Решить прямо сейчас или переделить задачу

Шаг 2: Декомпозиция задачи

Разбить сложную задачу на части:

Оригинальная задача (Senior level):
"Реализовать распределённую систему кеширования с учётом консистентности"

Переделить на подзадачи:
1. (Junior) Создать базовую структуру классов
2. (Middle) Реализовать простой in-memory cache
3. (Senior) Реализовать синхронизацию между узлами
4. (Middle) Написать тесты

Лиды распределяют части разным разработчикам

Шаг 3: Назначить сеньора как ментора

Если Junior берёт задачу выше его уровня:

Руководитель Middle разработчику:
"Эту задачу возьмёт Иван (Junior), но это будет его first challenging task.
Можешь ли ты быть ему mentor? Примерно 2-3 часа в неделю на reviews и пояснения"

Процесс:
- Code review с подробными комментариями
- Pair programming для сложных частей
- Объяснение архитектурных решений
- Направление в нужное русло

Шаг 4: Переоценить сроки

Исходный план: задача на 2 дня (для Senior)
Реальность: задача на 4-5 дней (для Junior с mentoring)

Действие: обновить в Jira/Asana сроки
Причина: Junior развивается, команда экономит на переделках позже

Шаг 5: Постоянный контроль прогресса

Этап 1 (день 1): Junior делает базовую структуру
  → Code review от Senior
  → Feedback и исправления

Этап 2 (день 2): Реализация основной логики
  → Daily standup с акцентом на эту задачу
  → Пара programming если зас

Этап 3 (день 3-4): Тестирование и финализация
  → Code review
  → Deployment

4. Как себя должен вести разработчик

Если взял задачу выше своего уровня:

✅ ПРАВИЛЬНО:
1. Честно сказать руководителю/лиду в день 1
   "Я начал на задачу и понял что это сложнее чем я думал"
2. Попросить помощь
   "Можешь ли помочь с архитектурой?"
3. Предложить решение
   "Может быть разбить на части и взять одну?"
4. Продолжать работать, но с support
5. Учиться у старших разработчиков
6. После завершения — рефлексия
   "Что я выучил? Что было сложно?"

❌ НЕПРАВИЛЬНО:
1. Молчать несколько дней, потом сказать "я не успел"
2. Сделать низкокачественный code и сдать
3. Ждать что кто-то за тебя сделает
4. Не признавать что ты не справляешься
5. Винить архитектуру/requirements в своих трудностях

5. Как себя должен вести руководитель/лид

Если Junior берёт сложную задачу (и это нормально):

✅ ПРАВИЛЬНО:
1. Заранее распланировать mentoring
   "Это task с целью развития, сроки могут быть дольше"
2. Проводить регулярные check-ins
   "Как дела? Где ты застрял?"
3. Давать конструктивный feedback
   "Хороший подход к X, но попробуй переписать Y так..."
4. Не критиковать за slow progress
   "Ты на правильном пути, это нормально что медленнее"
5. Отмечать прогресс и улучшения
   "Смотри как далеко ты зашёл!"
6. Переделить если реально не тянет
   "Давай возьму вторую половину, а ты закончишь первую"

❌ НЕПРАВИЛЬНО:
1. Дать сложную задачу и забыть про разработчика
2. Критиковать за slow progress без помощи
3. Ожидать senior quality от junior developer
4. Не помочь когда Junior просит
5. Обвинять разработчика в low productivity

6. Критерии готовности к сложной задаче

Junior → Middle задача:
✓ Уже решал похожие задачи
✓ Знает основные паттерны
✓ Есть senior mentor для поддержки
✓ Сроки не жёсткие (есть буфер)
✓ Risk не катастрофический

Middle → Senior задача:
✓ Есть опыт с архитектурой
✓ Может делегировать подзадачи
✓ Есть senior для консультаций
✓ Может нести ответственность за качество

Senior → Junior задача:
✗ Неиспользованный потенциал
✗ Скучно и неэффективно
✗ Junior разработчик мог бы расти
→ НУЖНО ПЕРЕДЕЛИТЬ

7. Примеры разговоров

Разговор 1: Junior признаёт что зас

Junior: "Я принял задачу про кеширование, но я не понимаю
        как работает распределённая инвалидация.
        Я потратил 2 часа и всё ещё в начале."

Сенир: "Окей, это нормально. Это сложная задача.
        Давай разбёрся. У нас есть 3 варианта:
        1. Я помогу тебе через это пройти (потребует времени)
        2. Возьму основную логику, ты дополнишь
        3. Отдам тебе более простую задачу для обучения
        Что ты предпочитаешь?"

Junior: "Вариант 1 звучит хорошо, я хочу учиться."

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

Разговор 2: Руководитель видит проблему

Руководитель: "Я заметил что Иван работает над X неделю,
              и обычно это занимает 2-3 дня. Что происходит?"

Сеньир (mentor): "Да, задача оказалась сложнее для его уровня.
                 Я помогаю, но нужно дать ему больше времени
                 и поддержки."

Руководитель: "Окей. Давайте разберём:
              1. Нужны ли ещё ресурсы (может быть 2 человека)?
              2. Можем ли сдвинуть deadline?
              3. Нужен ли более опытный mentor?"

Ключевые выводы

1. Ранее выявление — как только ясно что не тянет, нужно действовать
2. Honesty — разработчик должен честно сказать если зас
3. Mentoring — опытный разработчик должен помогать
4. Реалистичные сроки — сложные задачи требуют больше времени
5. Постоянный контроль — не ждать до конца спринта
6. Гибкость — быть готовым переделить/перераспределить
7. Развитие — это возможность growth для junior разработчика

Основной принцип: помогать разработчику расти, но не за счёт качества проекта и сроков.