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

Question

[Дмитрий Петрик]

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

Уверен, много народу уже сталкивалось с этим. Кто какие критерии оценки выработал для себя? Как оцениваете стоимость работ? Как правильно оценить стоимость разрабатываемого сайта на готовом движке или веб-приложения которое надо писать с нуля?

Comments

[Виталий Желтяков]

Уточните, что Вы хотите оценивать? (написание кода, подготовку контента, закрепление прав, регистрацию домена и пр.)

[Дмитрий Петрик]

Уточнение! Все начали писать про оценку по времени. Со временем проблем нет. Есть проблемы с оценкой по деньгам. Я так понял нужно разбивать работу на этапы и каждый этап помножать на коэффициент от 1.2 и выше.

Вот еще момент. Когда я отдаю часть работы на аутсорс. Как там быть? Понятно, что с заказчика хочется стрясти побольше, а исполнителю заплатить поменьше. Кто тут какими пропорциями пользуется?

Answer 1

[Eugene]

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

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

Answer 2

[Alexander]

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

Comments

[Дмитрий Петрик]

Меня бы, как заказчика мучил такой вопрос: «как мне понять, что вы намеренно не тянете время разработки чтобы побольше с меня денег содрать? То, что можно, на мой взгляд, сделать за 2 недели, вы делаете уже 6 недель». Что бы Вы на это ответили?

[Alexander]

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

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

Answer 3

[pletinsky]

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

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

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

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

Answer 4

[Сергей Протько]

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

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

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

Answer 5

[Hungry_Hunter]

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

Comments

[Дмитрий Петрик]

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

[Eugene]

Любая работа должна оплачиваться. И время на разработку ТЗ тоже нужно обговаривать.

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

[Hungry_Hunter]

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

Да, ТЗ не должно делать бесплатно. Обычно его стоимость примерно составляет 30% от стоимости проекта.

[Eugene]

Угу.

Нужно распросить у заказчика все подробности, замучить его уточняющими вопросами.

А вот на это может уйти огромная куча времени. По сути, это время должно оплачиваться почасово. Это, по сути, не просто обсуждение, а ещё и мозговая работа, творческий процесс — преобразование требований заказчика в язык какого-либо работника (дизайнер, программист, верстальщик). По идее, ТЗ обычно составляет менеджер проекта, который досконально владеет языком всех исполнителей + умеет общаться с клиентом.

[alt-j]

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

[tmikwid]

Werdna — не нужно обманывать заказчика. В тот момент, когда вы с ним перейдете на T&M — а разве не это идеальный вариант для каждого разработчика — он не будет понимать — либо вы не пишете ТЗ, либо эта же самая задача у другого программиста занимает в полтора раза меньше эффортов, потому что вы ТЗ размазываете по работам. Необходимо объяснять заказчику, что без ТЗ невозможна разработка. И доказывать это всеми возможными способами. Если заказчик туп и упрям, и вы исчерпали все аргументы — откажитесь от него. Не все программисты и заказчики созданы друг для друга.

[alt-j]

Если просить у заказчика деньги за ТЗ, он убежит от вас. Человек никогда не поймет почему ему надо платить деньги за формализацию его гениальной идеи без единого намека на ее реализацию.

[tmikwid]

Werdna — просто вы не умеете объяснять зачем нужно ТЗ

[alt-j]

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

[tmikwid]

Werdna лучше от заказчика ничего не прятать и быть максимально прозрачным. И на самом деле, лучше объяснить зачем нужно ТЗ, чем прятать его от заказчика

Answer 6

[Skull]

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

Answer 7

[Leanno]

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

Answer 8

[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

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

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

Answer 9

[Gena84]

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

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