Знакомая ситуация: команда обещает сдать проект через месяц, а по факту выходит два или три. Почему так происходит, даже если работают профи? Всё дело в трёх вещах: неопределённость, скрытая сложность и зависимости. Потому что оценивают идеальный сценарий. Никто не закладывает время на внезапные баги, правки заказчика или отпуск коллеги. Мы используем два понятия: буфер (запас времени) и фактор риска. Вывод: сроки сдвигаются не потому, что команда медленная, а потому что IT — это всегда немного неизвестность. В MIC мы закладываем этот запас сразу, чтобы управлять ожиданиями и сдавать проекты без стресса.
Знакомая ситуация: команда обещает сдать проект через месяц, а по факту выходит два или три. Почему так происходит, даже если работают профи?
Природа оценки сроков
Всё дело в трёх вещах: неопределённость, скрытая сложность и зависимости.
- Неопределённость. На старте мы редко знаем всё. Вдруг выясняется, что нужный сервис не поддерживает нужную функцию? По данным исследований, до 60% задач требуют уточнений уже в процессе.
- Скрытая сложность. То, что кажется кнопкой, на деле — интеграция с тремя системами, тестами и багфиксами.
- Зависимости. Ждём дизайн, доступы или ответ от другой команды. Один день простоя сдвигает весь график.
Почему ошибаются даже профи?
Потому что оценивают идеальный сценарий. Никто не закладывает время на внезапные баги, правки заказчика или отпуск коллеги.
Как делаем мы в MIC?
Мы используем два понятия: буфер (запас времени) и фактор риска.
- В каждую оценку мы закладываем запас на непредвиденные ситуации.
- Оценку делаем не одним числом, а диапазоном: «от и до».
- Честно говорим о рисках и зависимостях на старте.
Вывод: сроки сдвигаются не потому, что команда медленная, а потому что IT — это всегда немного неизвестность. В MIC мы закладываем этот запас сразу, чтобы управлять ожиданиями и сдавать проекты без стресса.