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

Статья понравилась, так как разложила все по полочкам.
Теперь проще будет объяснять клиентам, что при кажущейся стандартности задачи, есть свои нюансы. Большинство не понимают это. Так как думают, что работа вся шаблонная и делают ее роботы.

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

Совершенно другой вопрос заключается в том, что необходимо сделать для того, чтобы сократить пропасть между оценкой сроков линейным программистом и реальным сроком исполнения задачи? Мы, полагаясь на собственный опыт, могли бы рекомендовать следующие действия:

1. Просветительская работа с программистами — люди должны понимать, почему компании важна честная и объективная оценка сроков. Кроме этого, они должны знать о «подводных камнях», описанных в этой статье. Для того, чтобы уметь оценивать сроки, важно знать, как это делать — и эту статью можно использовать как краткое руководство.
2. Выделение отдельного времени для изучения всего проекта и отдельной задачи.
    
3. Обязательная фрагментация сложных задач — отказ от этого этапа, по нашему мнению, является одной из критических составляющих некорректной оценки сроков.
    
4. Отказ от оценки задач с большим числом неопределенных факторов. Иными словами, если не до конца понятно, что нужно сделать, значит время для оценки сроков еще не наступило. Перед оценкой сроков жизненно важно предельно конкретизировать постановку задачи.
    
5. Критическое отношение к прогнозируемым срокам со стороны руководителя проекта (умножайте хотя бы на 1.5 ... а лучше — на 2 :-)
    
6. Если речь идет об оценке сроков по всему проекту (бывает и такая необходимость), пятый пункт мы реализуем, как включение поправочной строки «риски», которая, как правило, включает как раз поправочный коэффициент по всему объему задач — можно и так поступать, чтобы не заниматься микро-менеджментом с каждой задачей.

Почему взяли именно программисты?

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

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

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

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

Практикуемая мера, когда руководитель специально занижает рассчитанные программистом сроки, крайне негативно будет влиять на производительность программиста. Под таким давлением программисты будут работать не лучше, а просто быстрее — а это будет прямо влиять на качество продукта и, конечно же, на собственное удовлетворение программиста от выполненной работы. Да и заблуждение о том, что заниженные сроки являются «интересной» задачей для программиста, тоже имеют место быть.

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

Любой программист вам скажет о необходимости «слиться» с задачей. Программист берёт задачу и тратит некоторое время на осознание и построение «виртуальной модели» в своей голове. Затем начинается процесс реализации этой модели, которая видоизменяется в процессе реализации. Время на осознание и построение модели зависит от сложности и стандартности задачи для разработчика.

Есть одно уязвимое место — необходимость неразрывности этого процесса другими задачами. Как только программист прерывается на другую задачу — существует риск разрушения «виртуальной модели». Например «Коля, срочно, на пять минут, исправь тут по-быстромууууу!» может отложить реализацию текущей задачи не только на время исправления, но и на время, необходимое для возвращения к основной задаче.

Решить эту проблему могут не только поправочные коэффициенты, но и наличие строгого процесса, а также менеджер ресурсов, планирующий людей на работы.

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

Для того, чтобы вводить точную поправку на названный программистом срок, менеджер может использовать планирование с учётом прежних результатов — Evidence Based Scheduling. Смысл EBS состоит в том, чтобы по каждому программисту накапливать данные оценок сроков и отклонений этих оценок от реальных сроков и по методу Монте-Карло строить прогноз.

Вы скажете: «Да в этом ничего нового нет, мы давно используем подобный подход», — и будете правы. Отчасти. Но многие менеджеры допускают одну большую ошибку. При планировании с учетом прежних результатов, надо учитывать не чистое время, затраченное на решение задачи, а всё время, прошедшее с момента принятия задачи в работу до её завершения. Именно учет всего времени дает прогноз, на который можно опираться, так как учитывает негативные факторы, обычно влияющие на выполнение задачи.

Если вдаваться в детали, то про EBS можно написать отдельную статью. Подробный разбор на английском есть в материале «Evidence Based Scheduling».

В статье в принципе все описано правильно и достаточно подробно.

Правильная оценка зависит, прежде всего, от того, насколько подробно предоставлены исходные данные: сложно оценивать реализацию абстрактной системы в вакууме. Адекватное описание, грамотно подготовленное аналитиком или project-менеджером, — это один из залогов успешной оценки.

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

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

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

Ошибаются в оценке сроков не программисты, а люди любых профессий, опыт работы которых в компании меньше 4-5-ти лет. На программистов это тоже распространяется, потому что их средний опыт работы меньше, часто 1-3 года. Не ошибаются люди, опыт которых лет 10 и выше, причем опыт не по профессии, а опыт именно в этой компании или именно в этом бизнесе, ибо они на подкорке предвидят все нюансы, которые могут возникнуть. Парадокс в том, что даже если человек с опытом работы от 10 лет никогда не был программистом, он все равно не ошибается в оценке сроков по программированию :-). В частности в нашей компании никакие разработчики не привлекаются к оценке сроков, это делают люди с опытом около 12-ти лет. И они никогда не ошибаются :-).