16 сентября 2010 г.



Оценка задач: причины неудачных оценок

Оценка трудозатрат на выполнение задачи является неотъемлемой частью профессиональных будней разработчика ПО. Мы занимаемся этим постоянно, даже в течении работы над уже поставленной и оцененной задачей («Кажется, успею реализовать этот класс до обеда...а после займусь подготовкой тестов»). Казалось бы, что постоянно оценивая задачи на разных уровнях, опытные разработчики должны щелкать это как орешки. Но все мы знаем, что это далеко не так и что даже самые опытные из нас могут промахнуться. Почему так происходит?






Во-первых, потому что промахнуться с оценкой в мире разработки ПО крайне легко. Как писал Фредерик Брукс в своей бессмертной работе, программисты работают с чистой мыслью, т.е. вещью весьма эфемерной и податливой. Можно считать что у нас нет материальных ограничений, которые присутствуют в традиционном производстве и налагают определенные условия на способы (а иногда и на сроки) решения задач. Образ будущей реализации программного модуля формируется у нас в мышлении и до тех пор, пока мы не напишем некоторое количество кода, живет только там. Мысленно с этим образом можно проделывать что-угодно, причем очень легко. Вот это постоянное чувство легкости в формировании образа задачи и заставляет нас иногда переносить эту легкость в область непосредственного решения и реализации. И, конечно же, давать слишком оптимистичные оценки.


Во-вторых, потому что очень часто (если не большую часть времени) мы вынуждены оценивать задачи в условиях высокой неопределенности. Думаю, что всем знакома ситуация, когда более-менее детальная спецификация от заказчика появится только через неделю, а оценить задачу нужно уже сейчас. Бизнес становится все более требовательным не только к качеству выполнения работ, но и к скорости реакции компании-подрядчика на свои запросы. Часто ситуация складывается так, что бизнес еще не до конца понимает свои потребности, но видит некий ориентир, к которому хотел бы двигаться. Имея этот ориентир бизнес хочет знать сколько нужно будет затратить ресурсов для достижения своей цели. Естественно, это может привести к тому, что оценка будет делаться, опираясь на данные «взятые с потолка». И в результате ничего хорошего не выйдет - сроки будут сорваны, бюджет раздут, клиенты останутся недовольны.

В-третьих, с оценкой легко ошибиться, потому что мир вокруг нас чертовски изменчив. То, что сегодня кажется удачной инновационной идеей, завтра может быть никому не нужно. Не потому, что не удовлетворяет критериям полезности, а потому, что время уже ушло. Получив спецификацию требований заказчика, оценив и начав работу мы рискуем очутиться в очень неприятной ситуации. Изменения в требованиях будут накапливаться как снежный ком и в результате приведут к коллапсу, когда все что было сделано придется выбросить, а сделанные оценки и близко не будут соответствовать действительности. Кроме того, придется сделать все заново и за оставшееся время. Конечно, тут я немного утрирую, но это только для того, чтобы передать мысль о том, что бизнес изменяется вместе с изменчивым миром, где потеря времени обязательно обернется потерей денег. 

В-четвертых, наша излишняя ориентированность на технику, мешает нам учитывать человеческий фактор при оценке задач. А ведь на самом-то деле ничто не мешает вашему лучшему разработчику заболеть, сыграть свадьбу или вообще поменять работу. Кроме того, людям свойственно ошибаться (да-да, и в оценках тоже), поэтому что-то может быть реализовано не так, как задумывалось. Придется переделывать. Что-то может быть реализовано правильно с точки зрения требований, но содержать огромное число ошибок, не дающих нормально работать. Придется исправлять. Что-то может быть вообще не реализовано, потому что кто-то где-то не так понял. Придется доделывать. Конечно же, все это увеличит трудозатраты и они могут значительно отличаться от первоначальной оценки. Результат этого понятен.

В-пятых, часто оценку трудоемкости разработки ПО делают не те люди! Ваш босс пообещал заказчикам решить их проблемы в рекордно короткие сроки (таки, что ни одна компания конкурент не возьмется за это). Ребята из отдела маркетинга решили, что этот продукт должен (и может) быть готов к выставке, или к Новому году, или к 31-му августа. В результате сроки спускаются сверху. Естественно, они не имеют никакой поддержки и понимания со стороны разработчиков. И, скорее всего, такие сроки будут сорваны, а трудозатраты значительно превысят ожидания.


Кроме перечисленных, конечно же, есть и другие причины (подробнее можно почитать по ссылкам внизу). Однако на мой взгляд эти пять причин влияют на процесс оценки трудозатрат наиболее сильно. О том, как с ними справляться, обязательно поговорим в следующий раз. Удачных оценок!

Полезные ссылки:





Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий