SamBadi
Константин Вальков

(21) Yashazz, Есть книга Роберта Кийосаки "Бедный папа, богатый папа". Советую почитать. Там на протяжении большого количества страниц расписывается одна мысль: "чтобы денег было больше: надо меньше тратить и больше зарабатывать". Были еще мысли про инвестиции, но они, по-моему, не очень пригодны для нашей страны. В своё время эта банальная книга с самоочевидными вещами мне помогла гораздо больше чем сложные книги. Надеюсь, что кому-то поможет и эта очевидная статья.

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

(16) starik-2005, звучит довольно заманчиво. Надо попробовать на практике.

(17) necropunk, + за внимательность. На сайте Кодерлайна (работаю там) немного модифицированную (разделенную по блокам) коллегами редакторами версию статьи выложили.

(13) starik-2005, и в очень больших компаниях на очень больших проектах ответственность за оценку задач ложится на конечного человека. В статье речь идет именно про оценку программиста, а не технического руководителя проекта, архитектора, ответственного за блок или иного ключевого лица на проекте.
Даже оцененные заказчиком, расписанные ответственным задачи или дают программисту на оценку, или программисту надо понять возьмется ли он делать за указанные часы или в указанные сроки (в конечном итоге те же часы для руководства). В такой ситуации, программист практически никогда не несёт рисков за неверную постановку, скорее всего ему закроют часы сверх оговоренного если он приведет хоть одну причину увеличения трудозатрат. Но, даже в такой ситуации возникают конфликты когда, например, руководитель разработки пытается надавить на разработчика и заставить его сделать что-то бесплатно (сверхурочно) или, что чаще в моей практике, разработчик безропотно соглашается, а потом постоянно, без аргументов, сдвигает сроки, что портит репутацию программиста.
Программисту, в конечном итоге, всегда надо ясно представлять себе что и как делать, уметь объяснить, что мешает ясной постановке, понимать, что прояснение постановки это тоже работа.

(3) starik-2005, Методика хорошая. Но оценка задачи не всегда быстрое дело и собрать "игроков за покерным столом" дело довольно хлопотное и последних надо как-то мотивировать.

(1) Petr54-ru, отчасти согласен, что от объема задачи напрямую зависит методика оценки.
Но какая-та градация у Вас выборочная, если придраться к вашей формулировке, то проект на неделю и на 5 лет находятся в одном "мире задач", а это не так.
Отвечаю на ваш вопрос: проблема в том, что тысяча книг написано, а коллеги разработчики, все равно избегают браться за задачу когда их просишь предварительно оценить, потому что, испытывают дискомфорт из-за возможности ошибиться. Пусть это будет тысяча первая статья, но если кому-то она поможет не отказаться от задачи и сделать её не себе в убыток, то цель достигнута.

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