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

Занимаюсь разработкой сайтов. Всяких разных. Начиная от блогов, заканчивая корпоративными порталами. Приходилось и разрабатывать приложения «с нуля», без всяких движков и т.п. И постоянно возникает вопрос, как не прогадать со стоимостью сайта?
Пока что цифру беру с потолка опираясь на эфимерный объем работы который сложился у меня в голове после после озвучивания всех пожеланий заказчика. И как показала практика такой метод оценки совершенно неприемлем. Частенько «влетал» с оценкой. Оказывалось, что объем работ на самом деле был несоизмеримо больше чем то, что я себе представлял. А говорить заказчику, что я просчитался в оценке и цена возрастает в 2-3 раза, на мой взгляд, признак дурного тона.

Уверен, много народу уже сталкивалось с этим. Кто какие критерии оценки выработал для себя? Как оцениваете стоимость работ? Как правильно оценить стоимость разрабатываемого сайта на готовом движке или веб-приложения которое надо писать с нуля?
  • Вопрос задан
  • 9711 просмотров
Пригласить эксперта
Ответы на вопрос 9
Methos
@Methos
Нужно просто всегда умножать на 2, как минимум. + добавлять несколько дней. Тогда приятно будет работать.

Стоимость чего-либо вообще не складывается от времени разработки, она зависит по большей части от того, сколько готов за неё заплатить клиент. Например, если для профессионала сделать что-либо будет 5 часов, а средняя цена одного часа на рынке 500 руб, это ещё не значит, что этому профи нужно будет заплатить 5*500 руб. Другой профи ту же работу может сделать за 50 минут, ему заплатить 500 руб? А если новичок будет делать её за 5 дней, неужели ему нужно будет заплатить 5*8*500 рублей? =))
Ответ написан
Alexx_ps
@Alexx_ps
Если у вас такая проблема, то попробуйте работать по модели фиксированной цены за фиксированный промежуток времени. По сути вы предлагаете заказчику работать по Scrum. Берете N тысяч рублей за каждые 2 недели рабочего времени, каждые 2 недели выкатываете ему рабочий функционал. Мы так и делаем, когда возникают сложности с окончательной оценкой большого проекта.
Ответ написан
pletinsky
@pletinsky
Выхода 3 на мой взгляд.

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

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

3) Работать итеративно выпуская короткие релизы с кусочками функциональности с оплатой за каждый релиз.
(Итеративность — это не обязательно эджайл).
Риски пролета будут зависить прежде всего от того, сумеете ли вы сформировать требования так, чтобы выпускать приложение такими релизами. Это как правило возможно, но получается не у всех.
Достоинства: риски провалится с пониманием требований сведены к минимуму, так как мы их формируем по мере работы, заказчик доволен видя постоянный прогресс, можно на основании предыдущих итераций корректировать дальнейшие прогнозы оставшевося времени.
Недостатки: требует серьезной обработки заказчика для работы в таком ключе, особенно для тех, у кого уже выделен бюджет на реализацию и на конкурсе.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Ну для начала вам стоит определиться со стеком технологий. То бишь как по мне каждый раз писась велосипед это тоже признак дурного тона. Надеюсь все же вы подразумевали разработку на каком-либо популярном фреймворке. Если так, то подберите расширения для него исходя из опыта (где что встречалось часто). Проект состоит из отдельных задачь, модулей, или частей. Называйте как хотите, оцениваются все же они а не весь проект целиком. По началу вы можете просто прикидывать, но думаю один два проекта у вас не выйдет вменяемой оценки. Это все же с опытом приходит. Запоминайте сколько у вас ушло времени на разработку отдельной части проекта.

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

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

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

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

Некоторые — добавляют три колонки с оценкой трудозатрат — Оптимистичные, Реалистичные и Пессимистичные.
Ну и много других хитростей существует.
Ответ написан
@Gena84
Мы декомпилируем проект на отдельные задачи и ведём статистику по этим задачам. Для рассчета себестоимости / времени используются эти данные с учетом специфики клиента (его опыт, аккуратность и знание в IT, желание завершить проект и т.д.).

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы