Человеческая жизнь ограничена. И люди могут достичь конечное количество целей. Может быть с этим связано то, что мы хотим знать когда та или иная работа закончится.

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

В программировании оценить сроки очень сложно. Есть несколько причин затягивания сроков:

  • Добавление требований в процессе разработки
  • Появление новых знаний о предмете
  • Интеграция с другими сервисами

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

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

Третий пункт также упирается в недостаточность знаний о предмете. По-моему, так называемый “кровавый энтерпрайз” кровавый, потому что требует взаимодействия со многими внешними системами, с плохой документацией и кучей багов. Когда пишется ПО для взаимодействия со внешней системой, для это внешней системы строится модель. Эта модель может очень сильно отличаться от реальности и это приводит к необходимости сильно переделывать программу.

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