Почему разработчики ПО часто ошибаются при оценке сроков
Производить оценку времени всегда сложно. Даже в повседневной жизни у большинства людей это получается не очень хорошо. Например, сколько раз на вопрос «Ты скоро закончишь?» Вы отвечали – через 5 минут? И ведь мы все искренне верим, что действительно управимся в эти 5 минут. И почти никогда в них не укладываемся. Те же «5 минут» могут в итоге занять полчаса и даже больше.
И все же по сравнению с усилиями по оценке времени разработки программного обеспечения наши повседневные «еще 5 минут» - это достаточно точные сроки, увеличивающиеся в шесть раз или около того. Для разработки ПО вполне распространено изменение запланированных сроков в целых сто раз. Далеко не один разработчик может рассказать историю, когда предварительно оцененный в час работы проект занимал до двух недель.
Но почему при оценке разработки программного обеспечения, как правило, ошибаются так сильно?
Вот четыре основные причины, которые нам удалось выяснить.
Причина первая: Неизвестные неизвестные
Эта фраза была впервые произнесена бывшим министром обороны США Дональдом Рамсфелдом и в основном относится к тем вещам, о которых мы даже не знаем, что мы их не знаем.
Вы не знаете, что вы не знаете
Безусловно, это самая главная причина, почему разработчики программного обеспечения часто промахиваются при предоставлении оценки сроков. Бывает и так, что это становится основной причиной, почему мы ошибаемся даже при оценке времени, чтобы добраться до дома – мы не знаем, на что на придется отвлечься по пути.
Разработка программного обеспечения имеет много неизвестных. Некоторые из неизвестных нам известны (как бы смешно это ни звучало).
Когда мы впервые начинаем проект, у нас может возникнуть хорошая идея - хранить всю информацию в базе данных, но мы еще не знаем, как мы это сделаем. То есть известное неизвестно. Мы знаем, что мы не знаем что-то, что мы в конце концов должны знать.
Оценивая известное неизвестное довольно сложно, но мы можем проделать определенную работу по оценке, если мы способны сравнить его с чем-то подобным, что мы уже делали раньше.
Мы точно не знаем, сколько потребуется времени, чтобы написать этот конкретный пост в блоге, но мы знаем, сколько времени мы потратили на написание аналогичного поста похожего объема.
Но что на самом деле страшно, так это те неизвестные, о которых мы даже не знаем.
Эти неизвестные неизвестные могут подкрасться неожиданно, потому что мы даже не знаем, что они существуют, они по определению для нас непостижимы. Одно дело знать, что у нас есть пробел где-то, который мы должны заполнить, и совсем другое - иметь столкнуться с завязанными глазами с неожиданной проблемой и только тогда узнать о ее существовании.
Постоянно в разработке программного обеспечения нам приходится сталкиваться с этими неизвестными неизвестными. И хорошего способа оценить их просто не существует. Лучшее, что мы можем сделать в этих случаях - дать себе побольше времени разобраться.
Причина 2: Длительные периоды времени
Причины ошибок кроются еще дальше (как будто неизвестных неизвестных было недостаточно).
Большинство оценок по разработке программного обеспечения включают довольно длительные периоды времени. Ситуация несколько изменилась с началом использования практики Agile, но нас до сих пор часто просят оценить количество часов работы при реализации проекта продолжительностью в неделю и больше. (Плюс, давайте не забывать о тех коварных менеджерах проектов, которые пытаются перекинуть Agile проекты в Microsoft Project и сказать: «Да, я знаю, что это Agile и все такое, но я просто пытаюсь получить примерное представление о том, когда мы полностью все закончим.»)
Довольно легко оценить короткие периоды времени. Большинство из нас может довольно точно предсказать, как долго мы будем чистить зубы, писать письмо или ужинать.
Длительное время точно оценить гораздо сложнее. Оценивая, сколько времени займет у вас задача вычистить гараж, написать книгу, или даже просто пойти в магазин за едой, Вы столкнетесь с гораздо более сложной задачей.
Чем больший период времени Вы пытаетесь оценить, тем вероятнее, что небольшие просчеты и последствия известных неизвестных сделают первоначальную оценку совершенно неточной.
По собственному опыту мы обнаружили, что при оценке всего, что займет больше двух часов, начинаются несоответствия ранее запланированных сроков.
В качестве упражнения попробуйте оценить задачи разной продолжительности.
Как много времени займет у Вас:
- сделать 10 отжиманий?
- сделать чашку кофе?
- сходить в мини-маркет и купить что-нибудь?
- написать письмо длиной в одну страницу?
- прочитать 300 страниц романа?
- поменять масло в Вашем автомобиле?
Обратите внимание, как вещи, которые можно легко сделать в рамках получаса - их очень легко оценить с высокой степенью достоверности, но как только Вы выходите за рамки этого времени, оценка становится гораздо сложнее.
Большую часть времени, когда мы делаем оценки по разработке программного обеспечения, мы не пытаемся оценить непродолжительные периоды, например, сколько времени потребуется на проведение определенного тестирования, вместо этого мы, как правило, оцениваем более длительные промежутки, такие как, например, сколько времени займет завершить разработку.
Причина 3: Самоуверенность
Мы довольно самонадеянны, когда дело доходит до оценки. Разработчики программного обеспечения часто убеждены в собственной способности точно предсказать, как много времени займет что-либо. Часто, если задача, к которой мы собираемся приступить, выглядит понятно, мы чувствуем себя уверенно и можем быть довольно агрессивными с нашими оценками, иногда доходя до абсурда.
- О! Вы не уверены? Конечно, я могу переписать приложение за полчаса!
- Как много времени займет добавить эту функцию?
- О, это? Это легко. Я сделаню в течение нескольких часов. Будет готово завтра утром.
- Вы уверены? А как насчет тестирования? Что делать, если что-то будет работать не так?
- Не волнуйтесь, это легко. Проблем вообще не должно быть. Мне просто нужно сделать несколько кнопок на странице и подключить код бэкенда.
Но, что происходит, когда Вы на самом деле садитесь и попытаетесь реализовать функцию? Ну, во-первых, вы узнаете, что это было совсем не так просто, как Вы думали. Вы забыли рассмотреть некоторые из возможных вариантов, которые требуют дополнительной работы.
Довольно скоро вы обнаружите, что уже почти всю ночь работаете только над тем, чтобы просто подготовить почву, чтобы на самом деле начать работать над проблемой. Часы превращаются в дни, дни в недели и через месяц, Вы, наконец, получаете некоторый рабочий код.
Конечно, это может быть преувеличением, но излишняя самоуверенность может стать большой проблемой в разработке программного обеспечения, особенно, когда дело доходит до оценки сроков.
Причина 4: Недостаточная уверенность
Точного слова, которое обозначало бы недостаточную уверенность в результате, мы не нашли. Предполагаем, что это потому, что кто-то не был достаточно уверен, чтобы привести его в словаре.
Но, так же как самоуверенность может привести к недооценке разработки программного обеспечения, недостаточная уверенность способна привести к тому, что тот же разработчик программного обеспечения переоценит другую задачу, которая может быть гораздо проще.
Не знаем, как Вы, но мы порой все оказывались в ситуации недостаточной уверенности в том, сколько времени займет тот или иной процесс. Каждый человек способен превратить простую задачу в огромную гору, которая кажется почти непреодолимой, если недостает уверенности в собственных силах.
Мы склонны смотреть на вещи, которые мы никогда не делали раньше, как на что-то более сложное, чем оно есть на самом деле, а то, что мы делали раньше, расцениваем как что-то простое. В этом вся человеческая природа.
Как бы это ни было удивительно, недостаток уверенности может быть столь же смертельным при оценке сроков. Когда мы не уверены, мы, скорее всего, добавим большое количество «дополнительного времени» к нашим оценкам. Это может показаться не таким уж плохим вариантом, но в таком случае работа есть способ заполнения времени, отведенного для нее. (Это явление известно как закон Паркинсона.)
Таким образом, даже при том, что, когда мы находимся в сомнениях, оценки оказываются достаточно точными, на выполнение работы мы тратим в два раза больше времени, то есть весь период отведенный на ее выполнение.