skvorets

>умножать начальный эстимейт на 2-2.5
Рекомендую «правило пи». Умножать на 3.14

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

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

При составлении финального бюджета не забудьте накинуть оверхеды. Например:
30% Тестирование
20% Анализ
10% Стабилизация
20% Планирование
Вообщем всё то, что может сдвинуть ваши сроки. И только эту конечную оценку и бюджет предъявляете заказчику.

Фишка в том, что даже ГОТОВЫЙ проект оценить не могут. Я приводил пример проекта google.com/codesearch#mORuzfPdTsg/trunk/&q=crowler%20lang:C%23 и просил разных программистов оценить его. Оценка получалась от $100 до $3000 (люди оценивали вполне серьезно).

Это о проекте, который уже готов (видим и размер, и качество выполнения, и сложность). А что можно говорить о проекте, который еще не готов?

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

Для меня это было открытием.

Мне кажется (да и по свому опыту скажу), что многи заказчики не всегда представляют, что и сколько стоит, а также каких временных и иных затрат воплощение «хотелок заказчика» требует.
Прекрасное предложение было выше — поговорите с заказчиком. Личный контакт и разговор позволяет не только грамотно поднять, например, цену, или сроки, но и является неким гарантом от того, что заказчик убежит к тому, кто намного дешевле.
Вы пишете:
— приблизительную (но далеко не всегда адекватную) стоимость проекта можно извлечь в ходе поиска схожих проектов на фрилансерских биржах;

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

Как то так.

1. поговорить не пробовали? спросить что конкретно заказчик имел в виду, как он себе это представляет и вообще детали раскрыть. Как правило одно, максимум двух, писем с вопросами хватает что бы получить достаточно информации для оценки стоимости работ.

Лично мне ответы сразу с ценой на заявку в пару фраз кажутся спамом.

2. Сроки плывут всегда. Нужно обладать недюжинным опытом и отменным профессионализмом что бы выполнить все как задумывалось.
Я помню восхищался преподом по общей биологии, который весь урок ярко, насыщенно рассказывал, устраивал мини тесты, успевал ответить на кучу вопросов и так далее, но всегда звонок звенел именно тогда когда наконец он смотрел на часы в конце урока. Так вот — в работе так не бывает.
Можно закончить раньше, можно напрячься и, за счет другого занятия, успеть вовремя, но всегда есть отклонения. Можно их скрывать оперируя крупными или размытыми сроками ( например «в течении недели»). Можно закладывать буфер на всякий случай. А можно сроками нормально управлять — общаться с заказчиком, сообщать ему планы, корректировать планы, если проявились проблемы или увеличилось количество работы, или наоборот удалось все сделать раньше. В обратную сторону заказчик может определить приоритеты важные для него, простимулировать, если надо быстрее или наоборот.

Кстати, если на сервере стоит CentOS, то рекомендую подключить вот эти репозитарии: centos.alt.ru/?p=120 (см. «Установка репозитория»)

потом надо сделать следующее:
1. yum update
2. yum install mysql mysql-server php php-common php-cli php-mysql php-fpm php-gd php-suhosin php-mhash php-mbstring nginx (+ добавить нужные пакеты)
3. настроить nginx, php-fpm и mysql

я так уже несколько вебсерверов поднял :-)