Разработчик не трекает время в Jira

Объяснение важности трекинга

Первый разговор с Оливером должен быть не наказывающим, а мотивирующим. Его позиция логична для работника, который не видит непосредственной выгоды. Задача — показать выгоду ему и команде.

Аргументы для Оливера

Для разработчика (личная выгода):

1. Объективная оценка производительности

   • Данные трекинга — это ваша защита. Когда начальник спросит "Почему задача затянулась?", у вас есть факты, а не предположения
   • Демонстрирует реальные достижения на review и при повышении

2. Контроль собственного времени

   • Аналитика показывает, на что уходит время. Может быть, половину дня вы теряете на отвлечения?
   • Если видишь, что 3 часа в день уходит на meetings, можно договориться о фокус-тайме

3. Карьерный рост

   • Данные о выполнении задач — основа для промоушена и переговоров о зарплате
   • Можно показать: "Я закрыл 15 стори за спринт вместо 10 в среднем по команде"

4. Снижение микроменеджмента

   • Если PO не видит, что разработчик работает, начинает всё чаще спрашивать статус
   • Регулярные логи — сигнал, что всё под контролем

Для менеджера и команды (бизнес-выгода):

1. Прогнозирование сроков

   • Без трекинга невозможно точно оценить velocity и сказать клиенту "Готово 15 сентября"
   • Данные истории спринтов — основа для планирования

2. Выявление bottleneck'ов

   • Если на задачу ушло 3 дня вместо оцененных 1 дня, надо понять, почему
   • Это не критика разработчика, а улучшение процесса

3. Справедливое распределение нагрузки

   • Видно, что Оливер перегружен (20 часов в неделю на задачи, остальное — отвлечения)
   • Можно перераспределить или найти блокеры

4. Выгоды для команды

   • Есть люди, которые долго копают в ненужных деталях. Данные это показывают
   • Лучшие практики: видно, что опытный разработчик делает задачу в 2 раза быстрее. Чем он отличается?

5. Финансовая отчётность перед клиентом

   • T&M модель: нужны факты о потраченном времени для выставления счёта
   • Fixed price: данные помогают улучшить profitability

Как объяснить Оливеру (approach)

Важно: Не начинай с требований. Начни с диалога.

Оливер, я заметил, что ты не трекишь время в Jira. Я понимаю, что это кажется излишним — ты и так знаешь, что работаешь. Но мне нужна твоя помощь. Без этих данных я не могу правильно планировать следующий спринт и показать клиенту прогресс.

Посмотри: если задача оценена в 1 день, а ушло 3 дня — это не критика тебя, это сигнал, что либо оценка была неправильная, либо что-то блокирует. Может быть, нужна помощь?

Даже 5 минут в день на трекинг экономит мне часы на попытки воссоздать, что было сделано. И это инвестиция в твой карьеру — данные помогают доказать твою ценность.

Если он продолжит игнорировать

Этап 1: Договорённость (день 1-2)

• Объясни на 1-1, как выше
• Скажи, что трекинг — не опция, это требование роли
• Предложи помощь: "Покажу, как быстро логировать время"
• Установи срок: "Начиная со следующего спринта, все обязаны трекить"

Этап 2: Мониторинг (спринт 1-2)

• Следи за логами на дейли
• Если не трекит — упомяни в начале дейли (мягко, перед командой): "Оливер, не вижу логов за вчера"
• Добавь в Definition of Done: "Невозможно закрыть task без логов времени"

Этап 3: Формальное письмо (если продолжает)

• Если спустя 2 спринта не трекит — отправь письмо
• Укажи: Это требование должностной инструкции, нарушение discipline
• Намекни на последствия: "Это будет учтено при оценке производительности"

Этап 4: Кадровые меры

• Если проблема сохраняется — это проблема attitude и compliance
• Разговор с HR о том, что разработчик не выполняет требования
• В экстремальном случае (месяц игнорирования) — это grund для performance improvement plan

Альтернативный вариант

Если Оливер потенциально ценный специалист, и проблема действительно в недопонимании (не в бунте), можно:

• Сделать трекинг проще: например, логировать время раз в день (не после каждой задачи)
• Автоматизировать часть через интеграцию Jira с git commits
• Позволить трекировать блоки по 30 мин (не детальный разлом)

Но структура требования должна остаться: если это standard практика в компании, исключения создают прецеденты.