Люди не умеют оценивать
Posted: Октябрь 29, 2011Насчет неумения оценивать в абсолютных величинах, есть множество научных источников. С результатами самого веселого, из повстречавшихся мне, исследования, проведенным норвежским научно-исследовательским институтом Simula Research Lab хочу поделиться с вами тут.
Исследователи попросили несколько групп разработчиков дать оценку некоторых программистких задач, описанных в спецификации. В среднем, группы оценили работу в 100 часов (я пропорционально привел все данные в исследовании к круглым цифрам, чтобы было проще запоминать).
После чего, начались следующие эксперементы:
Увеличение количества страниц
В первоначальной спецификации был увеличен шрифт, увеличины страничные, межпараграфные и межстрочные отступы. В итоге та же самая спецификация получилась на большем количестве страниц, чем первоначальная (заметьте, содержание осталось прежним). «Новая» спецификация была выдана другим группам разработчиков с просьбой произвести оценку.
Результат: 150 часов, то есть в полтора раза больше, чем первоначальная.
Внесение дополнительной информации, не имеющей отношения к делу
Та же самая первоначальная спецификация была «разбавлена водой». В нее была внесена информация, не имеющая отношения к оцениваемым задачам (различные комментарии, типа: что такое веб-дизайн, что такое логин, что такое пароли пользователей и тп). Новая спецификация снова была выдана другим группам разработчиков с просьбой произвести оценку.
Результат: 200 часов. Уже вдвое больше, чем первоначальная.
А это можете не делать
Снова за основу взяли первоначальную спецификацию, приложили к ней дополнительные пару листочков с описанием еще одной фичи и сказали группам разработчиков: «Оцените, пожалуйста, спецификацию, и, кстати, можете просто забыть о последних двух листах, нам эта функция не нужна, не оценивайте ее. (То есть, по сути, снова попросили оценить только первоначальную спецификацию).
Результат: 200 часов. Снова вдвое больше, чем первоначальная.
Заякоревание
Напоследок исследователи решили протестировать эффект «заякоривания» разработчиков. За основу взяли спецификацию, которая была оценена несколькими группами разработчиков в среднем в 500 часов. После чего, эту спецификацию брал Product Owner, нес команде и просил оценить, вскользь упоминая, что, мол, другие люди (которые, конечно, могут ошибаться, именно поэтому я пришел к вам) оценили эту спецификацию в Х часов.
Заякоревание вверх
Сначала Product Owner говорил, что другие оценили это в 1000 часов (помним, на самом деле 500), после чего команда оценивала сама.
Результат: 600 часов. На 20% больше, чем на самом деле.
Заякоревание вниз
Потом, Product Owner говорил, что другие оценили это в 50 часов (помним, на самом деле по прежнему 500), после чего команда оценивала сама.
Результат: 100 часов. А это в 5 раз меньше, чем на самом деле.
После всего этого напрашивается простой вывод: «Люди не умеют оценивать».
У кого еще есть подобные веселые случаи, доказывающие, что люди не умеют оценивать? Делимся в комментариях.
[...] Дмитриев пишет в своем блоге о том что может оказать влияние на оценку [...]
Просто оценкой не разработчики должны заниматься
Очень хочу конструктивно с этим поспорить. А кто же еще может сделать оценку, кроме как те люди, которые непосредственно будут делать работу?
Так исследование же это и доказывает
Оценивали же как раз те, кто собирался делать 
. А если серьезно,
Т.е. оценка это статистика по аналогичным работам * на квалификацию.
то действительно… начинаешь задумываться… надо ли отдавать оценку на откуп «не профессиональной» оценке. На днях узнал, как оценка делалась в советский времена в одном институте, занимающемся приборостроением (оценка делалась на работы по разводке печатных плат): оценка делалась начальником на основе плотности монтажа * на квалификацию исполнителя. Делаешь раньше срока — оплачиваемый отгул, не укладываешься — лишают премии или еще что. Знающие люди говорят, что система работала отлично
Просто Murad похоже хотел сказать, что есть кто-то кто знает лучше
. В таком случае хочу спросить, может ли какой-нить эксперт по чтению книг, сказать мне, за сколько я прочитаю нового Гарри Поттера? Задумайтесь об этом…
Все таки разработка софта, это не приборостроение, и к сожалению, гораздо меньше проектов у нас, когда есть «аналогичные работы» с которыми мы можем что-то сравнить (если мы не друпал инсталлируем нашему 1000-ому клиенту). Скорее всего, никто не интегрировался до этого, с системами именно этого клиента, и прочие инновационные штучки, до нас тоже никто не делал.
По опыту могу сказать, что психологические эффекты, описанные в исследовании, оказывают сильное влияние, когда время на оценку 100- и 500-страничного документа примерно одинаковое. Если же на оценку 500-страничного «ТЗ» потратить в 5 раз больше, то и оценки будут адекватнее.
Опять-таки, психологическое влияние оценок других команд будет так же сильно, если собственная оценка во многом делалась на глазок, или что называется «пальцем в небо». Если оценка делалась на основе проработки и декомпозиции документа на конкретные и понятные задачи, оценки всегда более-менее точны. Или, по крайней мере, куда точнее данных на глазок. Бороться с психологическими эффектами можно осознанностью принимаемых решений.
Третье, что хотелось сказать: есть ещё психологическое влияние прошлого опыта работы над подобными проектами. Проблемы других проектов заставляют людей перестраховываться и увеличивать оценку.
Наконец, оценки данные по исходному ТЗ чуть менее, чем всегда будут пальцем в небо. Мы обычно делаем их на основе тщательного обсуждения с заказчиком и изучения предметной области и существующего «багажа» системы. При этом фактически рождается ещё один документ, хоть и не 100-страничный, а оригинальный может сократиться и до 20 листов.
Ещё что интересно, при таком подходе оценки, данные по краткому документу, оказываются точнее, чем если бы у нас было подробное описание всех вариантов использования и пользовательского интерфейса. Мне кажется, дело тут в том, что в больших и подробных документах за деревьями сложно разглядеть лес, и времени на оценку уходит больше.
Адекватная оценка — это уже этап разработки системы, она требует соответствующего времени и ресурсов.
А исследование само по себе интересное.
хочу уточнить, это не документы были 100 и 500 страничные, страниц было от 3 до 7, а 100 и 500 это было количество часов, в которое разработчики оценили работу.
Исследование как раз и делалось с декомпозицией и проработкой и все равно доказало что оценки — это гадание на кофейной гуще.
Тут вы совершенно правы, есть очень примечательный график, с кривой неопределенности оценки. Там как раз, это хорошо видно, чем больше вкладываемся в рассасывание деталей, тем больше «леса» мы строим и сами же в нем и запутываемся.
Если речь о разработке ПО, то у исполнителей должен быть архитектор и менеджер. Они разбивают задачу на подзадачи, описывают элементы системы, устанавливают требования к ним, определяют порядок разработки и распределеют разработчиков.
Но самое главное — именно эти люди накапливают опыт работы по ТЗ! Поэтому они и должны этим заниматься.
К сожалению 60 летний опыт разработки ПО показывает, что такой подход не работает. Ни архитектор, ни менеджер, не могут сказать кто и за сколько сможет сделать ту или иную задачу.
Если речь идет о аутсорсе, то определять с точностью до часа и не требуется. Менеджер балансирует между возможной себестоимостью работ и риском что заказчику покажется ценник слишком дорогим. Наиболее точную оценку дают действительно менеджер и архитектор исходя из опыта на предыдущих проектах. А насколько она окажется верной — можно узнать только попробовав.
Ведь успех проекта, это не только грамотная оценка, но и работа с командой и минимизация рисков. Одна и та же команда с одной и той же оценкой может как сдать проект раньше, так и спихнуть его много позже срока.
Спасибо за комментарий, Евгений.
Тут хочу с вами не согласится, наиболее точную оценку все-таки дают те, кто непосредственно будет эту работу выполнять.
А что касается опыта предыдущих проектов, если мы инсталлируем друпал 1000 раз подряд, то, да согласен, предыдущий опыт имеет смысл. Если же мы занимаемся инновациями, интегрируемся со сторонними системами, наш предыдущий опыт все равно не поможет нам произвести точные оценки.
Оценки должны основываться на прошлом опыте. Чтобы довать более менее адекватные оценки необходимо базироваться на базе знаний