Сроки по задачам могут меняться по разным причинам: - **Изменение требований** — заказчик или стейкхолдеры вносят правки в ТЗ, что влечёт переоценку сроков. - **Технические сложности** — при реализации обнаруживаются непредвиденные проблемы (например, интеграция с legacy-системой). - **Ресурсы** — уход/болезнь ключевого разработчика, задержка с ревью или тестированием. - **Приоритезация** — сдвиг сроков из-за срочных багфиксов или изменений в roadmap. **Пример:** Задача: «Реализовать авторизацию через OAuth 2.0». Оценка — 5 дней. На 3-й день выяснилось, что API провайдера требует кастомной обработки токенов (+2 дня). **Как минимизировать риски:** - Заложить буфер в оценку (например, +20% времени). - Декомпозировать задачи и регулярно синхронизироваться с командой. - Использовать гибкие методологии (Scrum/Kanban) для адаптации к изменениям.