Почему программисты ошибаются в оценке сроков?

Всем известно, что сроки, названные программистами, нужно умножать на два. Ушлые проджект-менеджеры еще добавляют — "и брать значение следующего порядка". Т.е. при оценке программистом требующегося времени в один час в план пишем два дня. Но для заказчиков (как внешних, так и внутренних) такая ситуация выглядит, как минимум, странной — получается, что наши почти гениальные разработчики, способные решать сложнейшие задачи, не в состоянии сложить два и два и составить даже простой план. Как же такое получается? Давайте разберемся, почему программисты ошибаются в оценке сроков.

1. Время чистое и время грязное

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

2. Производительность

Отдельным пунктом идет вопрос производительности. При оценке программисты обычно исходят из классного самочувствия, высокой работоспособности и не делают скидок на неожиданное "что-то сегодня калган не варит" и "да, понедельник день тяжелый...". Но из реальности эти явления никуда не деваются, и ВНЕЗАПНО на типовую задачу уходит в два раза больше времени, чем обычно.

3. Исследования

Это, наверное, самое страшное для сроков дело. Выглядит оно так: программист оценивает задачу в три часа, напряженно работает и заканчивает только через восемь. На вопрос: "Почему?!" - объясняет, что в процессе возникло альтернативное и очень многообещающее решение, и на его рассмотрение ушла куча времени. Но, к сожалению, это решение не подошло, в итоге делать пришлось так, как планировалось изначально.

Что тут можно сказать? Исследование вариантов — не только зло, но и добро. Несмотря на всю непредсказуемость этого процесса, он может давать очень интересные и даже прорывные решения. Но может и не давать, конечно.

Частным случаем исследования является "курение мануалов". Выделяем это в самостоятельный пункт, так как при изучении документации разработчик часто открывает для себя много нового и интересного; неожиданно выясняется, что последние обновления позволяют делать так, как раньше делать было нельзя, поэтому по-хорошему стоит все вообще переписать заново. И, в особо тяжелых случаях, процесс переписывания заново начинается без предварительного согласования, со всеми вытекающими.

4. Сложные системы

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




5. Исправление ошибок

Заказчик обычно полагает, что хороший программист — это программист, который не делает ошибок. Со своей стороны и программисты часто не планируют времени на исправление ошибок, ведь это же автоматом означало бы и "планирование ошибок". А кто ж заранее планирует, что он будет косячить?

Однако пока код пишут люди, ошибки неизбежны. От простых опечаток, до сложных случаев неполной совместимости новых решений со старыми. И чем сложнее система, тем изощреннее могут быть возникающие ошибки. А значит, и время на их исправление вполне может превышать время, потраченное на собственно разработку.

6. Составные и нетиповые задачи

Планировать время на выполнение составных или нетиповых задач достаточно просто. Можно называть любой срок и точно знать, что он наверняка будет ошибочен, в ту или иную сторону.

С нетиповыми задачами все понятно: если подобная задача еще не выполнялась, и с какой стороны к ней подойти — пока неясно, то программистская оценка будет зависеть только от его уровня самоуверенности. Считающий себя гением скажет, что сделает за пару дней (в его представлении это предельный срок для самых сложных задач), человек неуверенный на ту же задачу попросит недельки три, "чтоб с запасом". При этом без предварительного детального изучения оба не планируют, а гадают, и реальный срок может оказаться абсолютно любым.

Более-менее точная оценка может быть дана после предварительного исследования задачи, которое само по себе требует времени. Т.е. при возникновении задач новых, "не имеющих аналогов", нужно не требовать от программиста быстрой и точной оценки сроков, а ставить предварительную задачу "провести оценку".

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

Более-менее приблизить оценку составной задачи к реальности можно, только если оценить отдельно каждую из подзадач, а итоговое время рассчитывать уже как их сумму, с соответствующими "добавками" как на каждую задачу, так и на их итоговое сопряжение.

7. Оценка под давлением

Наш список причин некорректной оценки времени будет неполным без упоминания такого замечательного явления, как "Клиентское давление". Это ситуация, когда заказчик (внутренний или внешний) так или иначе влияет на оценку. Например, дает понять, что хочет услышать оптимистичное "Завтра будет готово!" ну или что-то типа этого.

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

Итого. Резюмируем

Первое: программистская оценка без применения специальных "поправочных коэффициентов" действительно может оказаться очень неточной.

Второе: в этом нет злого умысла или свидетельств "тайм-неполноценности" — обычные особенности человеческой психологии, а программисты все-таки тоже люди.

Третье: таки да, к первоначальной программистской оценке времени нужно относиться сдержанно, не считая ее высеченным в граните обязательством. Эту оценку можно внести в план, чтобы получить повод потом покапать программисту на мозги (если вас интересуют такие развлечения), но на самом деле ориентироваться на больший срок.