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

Решение

1. Определение корневой причины

Личное интервью с Патриком (1-на-1)

Это важно сделать в конфиденциальной, поддерживающей атмосфере, а не в режиме "допроса". Вопросы:

Про навыки и знания

• Чувствует ли себя готовым к задачам, которые получает?
• Есть ли недостаток в знаниях языка/фреймворка/domain знаниях?
• Просит ли он помощь когда застревает, или пытается разбираться сам?
• Сколько времени обычно уходит на исследование / понимание требований?

Про условия работы

• Хватает ли ему времени на обучение (не только на задачи)?
• Достаточно ли поддержки от team lead / senior разработчика?
• Есть ли отвлекающие факторы дома / в офисе?
• Работает ли он в оптимальное время дня или есть проблемы с концентрацией?

Про психологию

• Чувствует ли давление из-за того что не укладывается?
• Переживает ли, что его недооценивают или что он "медлен"?
• Может ли быть перфекционизм: пишет идеальный код вместо функционального?
• Есть ли личные проблемы, влияющие на продуктивность?

Про эстимейты

• Понимает ли он, как правильно оценивать задачи?
• Может ли быть недооценка сложности (не видит подводные камни)?
• Знает ли он, что оценка это прогноз, а не обещание?

Наблюдение по коду и процессу

• Посмотреть его код: много ли переделок, есть ли технический долг?
• Есть ли множество code review итераций?
• Может ли быть, что он пишет код, который потом нужно переделывать?
• Сколько времени уходит на тестирование и фиксинг багов?

Анализ данных

• Посмотреть историю спринтов: в какие дни задачи растут, в какие выполняются?
• Может быть, к концу спринта появляются неожиданные проблемы?
• Есть ли зависимости от других разработчиков, которые замедляют его?

2. Меры для исправления ситуации

Вариант A: Проблема в оценке (наиболее частый случай для джуниоров)

Действия:

• Обучить Патрика правильно оценивать задачи
  • Вводный коэффициент: он оценивает на 8 часов? Применим multiplier 1.5-2x
  • Добавить буфер за неизвестное: если задача новая, добавить 30-50% времени
  • Включить в оценку code review и доработки
• На спринте: более частые check-ins (не один раз в неделю, а несколько раз)
• Breaking down: помочь break down большие задачи на части
• Pair programming: джуниор работает в паре со senior на первых задачах нового типа

Ожидаемый результат: более реалистичные оценки, менее шокирующие результаты

Вариант B: Проблема в навыках / знаниях

Действия:

• Структурированный план обучения на 2-3 месяца
  • Определить gaps: в каких технологиях/процессах отстает
  • Выделить 20-30% времени спринта на обучение (не на задачи)
  • Рекомендовать курсы, видео, документацию, book club
• Ментор: назначить senior разработчика менторов на постоянной основе
  • 1-2 часа в неделю dedicated time для обучения
  • Code review с подробными комментариями (не просто approve/reject)
  • Pair programming на сложных задачах
• Снизить сложность задач на время: давать simpler stories пока не вырастет

Ожидаемый результат: через 2-3 месяца навыки улучшатся, скорость вырастет

Вариант C: Проблема в условиях работы или психологии

Действия:

• Уменьшить давление: объяснить, что это нормально для джуниора
• Дать поддержку: четко сказать, что он не один, команда помогает
• Обсудить личные факторы: есть ли стресс, усталость, personal issues?
  • Если есть: предложить гибкий график, дни отдыха, EAP (Employee Assistance Program) если есть
• Переформатировать feedback: вместо "ты медлен", говорить "давай найдем способ помочь тебе расти"

Ожидаемый результат: психологический комфорт, снижение тревожности, рост продуктивности

Вариант D: Проблема в процессе / зависимостях

Действия:

• Убрать блокеры: есть ли он ждет review других, API от других сервисов, decisions?
• Оптимизировать code review: может быть, review слишком долгий? нужно ускорить?
• Зависимости: есть ли задачи, которые зависят друг от друга неправильно?
• Инструменты: может быть, нужны better dev tools, IDE, local setup?

Ожидаемый результат: убрать bottlenecks, ускорить доставку

Комбинированный подход (рекомендуется)

• Неделя 1: 1-на-1 с Патриком, слушание, понимание
• Неделя 2: переосмотр последних задач, анализ где именно время уходит
• Неделя 3-4: запуск выбранных мер (обучение? pair programming? переоценка?)
• Неделя 5-8: мониторинг, regular check-ins, adjustment плана
• Неделя 9-12: оценка результатов, adjust если нужно

3. Работа с командой для снятия напряжения

Общение с командой (team meeting)

Позиционирование

• НЕ критиковать Патрика перед командой
• Позиционировать это как: "Мы помогаем Патрику расти, это нормальная часть его развития"
• Подчеркнуть: его медленность это его проблема с оценкой или навыками, а не лень или небрежность

Регулирование работы

• Пересмотреть зависимости: возможно, другие ждут его работы? Переделить распределение задач
• Если другие "доделывают": запретить это (!) полностью
  • Вместо этого: code review, обучение, но не переделка его работы
  • Если работа не качественна: это обсуждается с Патриком и PM, не с другими разработчиками
• Баланс нагрузки: может быть, на других разработчиков слишком много упало?

Psych support

• Напомнить команде: "Мы растим людей, это часть нашей культуры"
• Привести примеры: "Я сам когда-то был джуниором и также медлил"
• Культура обучения: "Если вы видите, что кто-то не знает что-то, помогите ему узнать, не делайте вместо него"
• Публичное признание: если Патрик улучшится, отметить в team meeting

Структурное решение

• Пересмотреть спринт планирование: может быть, джуниорам выделять меньше story points?
• Создать система buddy: более опытный разработчик отвечает за "health" джуниора
• Regular retro: спрашивать команду "как мы помогаем друг другу?" "есть ли трение?"

Если ничего не помогает

• После 3-4 месяцев: если улучшения нет и это критично для проекта
• Обсудить с Патриком: может быть, он не подходит для этой роли?
• Рассмотреть: перевести в другую команду? QA? devops? product?
• Или: если зарплата низкая, может быть, повышение/бонус будет мотивировать?
• Худший вариант: увольнение, но это последний шаг после честного разговора и попыток помочь

Ключевые принципы

• Предположение о добрых намерениях: Патрик старается, но что-то мешает ему
• Поддержка, не наказание: это мотивирует, а не демотивирует
• Быстрые wins: дать ему ощущение прогресса, даже если он маленький
• Прозрачность: четко обозначить expectations, metrics, timeline для улучшения
• Культура: "Мы помогаем друг другу расти" становится норм, не исключением

Проблема Патрика это не его беда, это система должна его поддерживать. Если система не работает, это проблема процесса и управления, а не Патрика.