Как оценить реальную стоимость проекта?

Нужно просто всегда умножать на 2, как минимум. + добавлять несколько дней. Тогда приятно будет работать.

Стоимость чего-либо вообще не складывается от времени разработки, она зависит по большей части от того, сколько готов за неё заплатить клиент. Например, если для профессионала сделать что-либо будет 5 часов, а средняя цена одного часа на рынке 500 руб, это ещё не значит, что этому профи нужно будет заплатить 5*500 руб. Другой профи ту же работу может сделать за 50 минут, ему заплатить 500 руб? А если новичок будет делать её за 5 дней, неужели ему нужно будет заплатить 5*8*500 рублей? =))

Если у вас такая проблема, то попробуйте работать по модели фиксированной цены за фиксированный промежуток времени. По сути вы предлагаете заказчику работать по Scrum. Берете N тысяч рублей за каждые 2 недели рабочего времени, каждые 2 недели выкатываете ему рабочий функционал. Мы так и делаем, когда возникают сложности с окончательной оценкой большого проекта.

Выхода 3 на мой взгляд.

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

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

3) Работать итеративно выпуская короткие релизы с кусочками функциональности с оплатой за каждый релиз.
(Итеративность — это не обязательно эджайл).
Риски пролета будут зависить прежде всего от того, сумеете ли вы сформировать требования так, чтобы выпускать приложение такими релизами. Это как правило возможно, но получается не у всех.
Достоинства: риски провалится с пониманием требований сведены к минимуму, так как мы их формируем по мере работы, заказчик доволен видя постоянный прогресс, можно на основании предыдущих итераций корректировать дальнейшие прогнозы оставшевося времени.
Недостатки: требует серьезной обработки заказчика для работы в таком ключе, особенно для тех, у кого уже выделен бюджет на реализацию и на конкурсе.

Ну для начала вам стоит определиться со стеком технологий. То бишь как по мне каждый раз писась велосипед это тоже признак дурного тона. Надеюсь все же вы подразумевали разработку на каком-либо популярном фреймворке. Если так, то подберите расширения для него исходя из опыта (где что встречалось часто). Проект состоит из отдельных задачь, модулей, или частей. Называйте как хотите, оцениваются все же они а не весь проект целиком. По началу вы можете просто прикидывать, но думаю один два проекта у вас не выйдет вменяемой оценки. Это все же с опытом приходит. Запоминайте сколько у вас ушло времени на разработку отдельной части проекта.

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

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

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

Не знаю как там с CMS, но если писать с нуля то после 20го проекта начнете говорит оценку с погрещностью в 10-20%(конечно если заранее все описано в ТЗ и оно не изменяется).
Я обычно делаю так:
1) Разбиваю проект на разделы, которые уверен что сделаю без гугла и stackovewflow, прикидываю время нужное, уумножаю на 1.2
2) На оставшиеся нестандартные разделы прикидываю время и умножаю на 1.5
3) Если в проекте есть общение с другими сервисами или внешний истоник данных(загрузка прайса в БД, связь с 1С, парсинг данных откуда-то еще) — прикидываю время в иделале и умножаю на 5(иногда нужно бы и на 10)

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

Метод очень простой — сначала оцениваете трудозатраты, декомпозируя то, что нужно сделать максимально детально — например:

1. Project plan 2hrs
2. Software architecture 4hrs
3. Features:
— feature1 4hrs
— feature2 4-8hrs
4. Testing 0.3*overall effort
5. Bugfixing 2*testing
6. Deployment 4hrs

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

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

Мы декомпилируем проект на отдельные задачи и ведём статистику по этим задачам. Для рассчета себестоимости / времени используются эти данные с учетом специфики клиента (его опыт, аккуратность и знание в IT, желание завершить проект и т.д.).

А для определения стоимости продажи вам советов уже накидали: анализ конкурентов, продажа «выгоды» для клиента и т.д.