Почему программисты занижают временные оценки
В современном мире время - это самый дорогой и востребованный ресурс. Все хотят знать срок выполнения, все хотят, чтобы этот срок был как можно меньше, а результат как можно лучше. Сфера заказной разработки программного обеспечения не является исключением.
Известная шутка «Спроси срок у программист, а затем умножь его на Пи» на самом имеет под собой ряд нешуточных причин. В этой статье мы попробуем разобраться, почему разработчики занижают оценку и как им помочь достигнуть реалистичности временных расчетов.
Сколько часов вам потребуется на чтение книги объемом 300 страниц? 3-4 часа? Да, если в это время вам не позвонит девушка, вы не захотите перекусить, ваш сосед не решит заняться ремонтом. Как много «если» возникает на пути выполнения такой простой задачи, как чтение книги. Задачи программистов, в свою очередь, требуют полного погружения и любой отвлекающий фактор заставляет снова и снова тратить время на то, чтобы вернуться мыслями в мир абстрактных сущностей. Итак, первая причина заниженных временных оценок: людям свойственно оперировать «идеальными часами».
Вернёмся к чтению книги. Вот прошёл 1 час и вам захотелось спать. Возможно, вчера вы отмечали день рождения или у вас упало давление. Но факт остается фактом, ваша производительность упала и скорость чтения вместе с ней. Реальность нас не щадит и мы физически не можем обладать отличным самочувствием и настроением в режиме 24/7. В этом кроется вторая причина занижения временных оценок: мы исходим из идеальной производительности.
Сложно представить, что кто-то будет планировать свое время следующим образом: «Итак, у меня есть задача. При ее выполнении я сделаю одну большую ошибку и две маленьких. Потом я исправлю большую ошибку и отдам задача на проверку. После проверки будут найдены две маленькие ошибки и я их тоже исправлю.» Тем не менее, к сожалению, ситуация возврата результатов на багфикс после тестирования отнюдь не редка. Третья причина некорректных временных оценок: мы ожидаем получить идеальный результат без необходимости исправлений и доработок.
Разумеется, в упомянутых выше причинах мы исходим из того, что сами задачи составлены идеально, в них отсутствует «ветвление» (когда одна задача внезапно распадается на несколько связанных), а условия прописаны четко и однозначно. В противном случае следует учитывать еще и временные затраты на уточнение и формализацию самой задачи.
Как видно из нашего примера с чтением книги, занижение временных оценок не является прерогативой одних лишь программистов - это общечеловеческая черта. Грамотный менеджер проекта будет учитывать наши психологические особенности и соответствующим образом корректировать оценку.
