Всем известно, что сроки, названные программистами, нужно умножать на два. Ушлые проджект-менеджеры ещё добавляют — «и брать значение следующего порядка». Т.е. при оценке программистом требующегося времени в один час, в план пишем два дня. Но для заказчиков (как внешних, так и внутренних) такая ситуация выглядит, как минимум, странной — получается, что наши почти гениальные разработчики, способные решать сложнейшие задачи, не в состоянии сложить два и два, и составить даже простого плана. Как же такое получается? Давайте разберёмся, почему программисты ошибаются в оценке сроков.
Время чистое и время грязное
Когда программист оценивает задачу, он обычно мыслит категориями «чистого» времени. «Можно сделать, если заниматься этим пять часов подряд, без перекуров и перерыва на обед». В реальности «чистого» времени почти никогда не бывает (люди должны переключаться, питаться, ходить в туалет и пр.), а если программист работает в коллективе, то не бывает вообще никогда. При этом объём «грязи» может достигать совершенно невообразимых размеров, если коллектив дружный, а программист участвует в нескольких задачах одновременно. Тогда перерывы на «быстрое общение у кофемашины» органично переплетаются с отвлечениями на внезапные «Коля, срочно, на пять минут, исправь тут по-быстромууууу!», и время идёт, а основная задача все не закрывается.
Производительность
Отдельным пунктом идёт вопрос производительности. При оценке программисты обычно исходят из классного самочувствия, высокой работоспособности, и не делают скидок на неожиданное «что-то сегодня калган не варит» и «да, понедельник день тяжёлый...». Но из реальности эти явления никуда не деваются, и ВНЕЗАПНО на типовую задачу уходит в два раза больше времени, чем обычно.
Исследования
Это, наверное, самое страшное для сроков дело. Выглядит оно так: программист оценивает задачу в три часа, напряжённо работает и заканчивает только через восемь. На вопрос «Почему?!» объясняет, что в процессе возникло альтернативное и очень многообещающее решение, и на его рассмотрение ушла куча времени. Но, к сожалению, это решение не подошло, в итоге делать пришлось так, как планировалось изначально.
Что тут можно сказать? Исследование вариантов — не только зло, но и добро. Несмотря на всю непредсказуемость этого процесса, он может давать очень интересные, и даже прорывные решения. Но может и не давать, конечно.
Частным случаем исследования является «курение мануалов». Выделяем это в самостоятельный пункт, так как при изучении документации разработчик часто открывает для себя много нового и интересного; неожиданно выясняется, что последние обновления позволяют делать так, как раньше делать было нельзя, поэтому по-хорошему стоит всё вообще переписать заново. И, в особо тяжёлых случаях, процесс переписывания заново начинается без предварительного согласования, со всеми вытекающими.
Сложные системы
Обязательно стоит упомянуть специфику планирования работ в сложных системах. Тут оценка часто расходится с реальностью именно из-за сложных взаимосвязей элементов системы. Например, ставится простая задача — изменить порядок сортировки элементов в определённом разделе. В системе есть для этого штатный инструмент, и программист оценивает работу как очень простую. Всех делов — приоритеты расставить, на пять минут работы. Но, войдя в раздел, он обнаруживает, что все элементы там связаны с другими разделами и порядок их сортировки определяется не их приоритетами, а большим количеством свойств в других разделах. И чтобы решить эту «простую» задачу, нужно переписать половину логики системы.
Исправление ошибок
Заказчик обычно полагает, что хороший программист — это программист, который не делает ошибок. Со своей стороны и программисты часто не планируют времени на исправление ошибок, ведь это же автоматом означало бы и «планирование ошибок». А кто ж заранее планирует, что он будет косячить?
Однако пока код пишут люди, ошибки неизбежны. От простых опечаток, до сложных случаев неполной совместимости новых решений со старыми. И чем сложнее система, тем изощрённее могут быть возникающие ошибки. А значит и время на их исправление вполне может превышать время, потраченное на, собственно, разработку.
Составные и нетиповые задачи
Планировать время на выполнение составных или нетиповых задач достаточно просто. Можно называть любой срок и точно знать, что он наверняка будет ошибочен, в ту или иную сторону.
С нетиповыми задачами всё понятно: если подобная задача ещё не выполнялась, и с какой стороны к ней подойти — пока неясно, то программистская оценка будет зависеть только от его уровня самоуверенности. Считающий себя гением скажет, что сделает за пару дней (в его представлении это предельный срок для самых сложных задач), человек неуверенный на ту же задачу попросит недельки три, «чтоб с запасом». При этом без предварительного детального изучения оба не планируют, а гадают, и реальный срок может оказаться абсолютно любым.
Более-менее точная оценка может быть дана после предварительного исследования задачи, которое само по себе требует времени. Т.е. при возникновении задач новых, «не имеющих аналогов», нужно не требовать от программиста быстрой и точной оценки сроков, а ставить предварительную задачу «провести оценку».
Составные задачи (состоящие из некоторого числа связанных подзадач) тоже часто путают программистов — с каждой из подзадач могут быть связаны любые варианты потери времени из приведённых выше (или все сразу), поэтому в сумме расхождение реального срока с прогнозом может достигать космических масштабов.
Более-менее приблизить оценку составной задачи к реальности можно, только если оценить отдельно каждую из подзадач, а итоговое время рассчитывать уже как их сумму, с соответствующими «добавками» как на каждую задачу, так и на их итоговое сопряжение.
Оценка под давлением
Наш список причин некорректной оценки времени будет неполным без упоминания такого замечательного явления как «Клиентское давление». Это ситуация, когда заказчик (внутренний или внешний) так или иначе влияет на оценку. Например, даёт понять, что хочет услышать оптимистичное «Завтра будет готово!», ну или что-то типа этого.
В этой ситуации у программиста бывает два варианта действий. Первый — проявлять упорство и отстаивать более адекватную оценку. Второй — сознательно назвать срок меньше требующегося, рассудив, что проще потом объяснить, почему не успеваешь, чем сейчас долго бодаться, расстраивая клиента и заставляя его усомниться в профессионализме исполнителя. То есть, в этом случае неверная оценка даётся не из-за ошибки, а сознательно, под влиянием клиентских ожиданий.
Итого
Резюмируем.
Первое: программистская оценка без применения специальных «поправочных коэффициентов» действительно может оказаться очень неточной.
Второе: в этом нет злого умысла или свидетельств «тайм-неполноценности» — обычные особенности человеческой психологии, а программисты, всё-таки, тоже люди.
Третье: таки да, к первоначальной программистской оценке времени нужно относиться сдержанно, не считая её высеченным в граните обязательством. Эту оценку можно внести в план, чтобы получить повод потом покапать программисту на мозги (если вас интересуют такие развлечения), но на самом деле ориентироваться на больший срок.