Тонкости оценки стоимости работы?

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


В чем вопрос.

Как научиться адекватно оценивать стоимость и, соответственно, время реализации проекта?

Поделитесь пожалуйста опытом. Какие принципы вы выработали лично для себя?


Вот что я пока собрал и чему пытаюсь следовать:

— приблизительную (но далеко не всегда адекватную) стоимость проекта можно извлечь в ходе поиска схожих проектов на фрилансерских биржах;

— запрос любых изменений заказчиком обязательно влечет за собой обязательное изменение ТЗ и, соответственно, пересчет сроков и стоимости проекта;

— в планировании времени стоит помнить, что непосредственно программинг может занимать ~30% процентов времени. Остальное — проектирование, тестирование и коммуникация с клиентом;

— закладывать в план время с учетом возникновения рисков («пожар, эпидемия, космоса черные дыры»:)

— лично для меня пока — при отсутствии четкого ТЗ необходимо умножать начальный эстимейт на 2-2.5 (из анализа сроков пост-фактум) Т.е. начальное предположение отличается от реальности вдвое.


Что бы вы еще добавили?

Может какую-то литературу\статьи проштудировать посоветуете?
  • Вопрос задан
  • 5161 просмотр
Пригласить эксперта
Ответы на вопрос 7
Wott
@Wott
1. поговорить не пробовали? спросить что конкретно заказчик имел в виду, как он себе это представляет и вообще детали раскрыть. Как правило одно, максимум двух, писем с вопросами хватает что бы получить достаточно информации для оценки стоимости работ.

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

2. Сроки плывут всегда. Нужно обладать недюжинным опытом и отменным профессионализмом что бы выполнить все как задумывалось.
Я помню восхищался преподом по общей биологии, который весь урок ярко, насыщенно рассказывал, устраивал мини тесты, успевал ответить на кучу вопросов и так далее, но всегда звонок звенел именно тогда когда наконец он смотрел на часы в конце урока. Так вот — в работе так не бывает.
Можно закончить раньше, можно напрячься и, за счет другого занятия, успеть вовремя, но всегда есть отклонения. Можно их скрывать оперируя крупными или размытыми сроками ( например «в течении недели»). Можно закладывать буфер на всякий случай. А можно сроками нормально управлять — общаться с заказчиком, сообщать ему планы, корректировать планы, если проявились проблемы или увеличилось количество работы, или наоборот удалось все сделать раньше. В обратную сторону заказчик может определить приоритеты важные для него, простимулировать, если надо быстрее или наоборот.
Ответ написан
opium
@opium
Просто люблю качественно работать
Разбиваете задачу на подзадачи, у каждой выставляете часы, часы умножаете на стоимость вашего часа, смету отправляете заказчику, цена адекватна и обоснована.
любые изменения влекут изменения в часах, если их нужно меньше продукт будет стоить дешевле, если больше то дороже, тоже все прозрачно и понятно заказчику.
ни один человек не написал как он будет писать хабр, выкладки по часам и подзадачам, так что всех кто там писал можно слить. аналог хабра поднять на лайвстрите два дня с допилкой, то есть 16 часов умноженных на 500 рублей 8 000 рублей, стоит аналог хабра на лайвстрите, можно разбить на подзадачи и более детальную смету по цене. Данное время взято из моего реального опыта.
Ответ написан
alekciy
@alekciy
Вёбных дел мастер
>умножать начальный эстимейт на 2-2.5
Рекомендую «правило пи». Умножать на 3.14

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

Более точного метода чем сбор статистики лично я не знаю. А это приходится делать в таком виде, потому что теже задачи другим разработчиком был бы оценены в другое время и потратил бы он время на их реализацию другое. Поэтому сейчас только через личную статистику, имхо.
Ответ написан
contestar
@contestar
При составлении финального бюджета не забудьте накинуть оверхеды. Например:
30% Тестирование
20% Анализ
10% Стабилизация
20% Планирование
Вообщем всё то, что может сдвинуть ваши сроки. И только эту конечную оценку и бюджет предъявляете заказчику.
Ответ написан
Комментировать
alexmay
@alexmay
Мне кажется (да и по свому опыту скажу), что многи заказчики не всегда представляют, что и сколько стоит, а также каких временных и иных затрат воплощение «хотелок заказчика» требует.
Прекрасное предложение было выше — поговорите с заказчиком. Личный контакт и разговор позволяет не только грамотно поднять, например, цену, или сроки, но и является неким гарантом от того, что заказчик убежит к тому, кто намного дешевле.
Вы пишете:
— приблизительную (но далеко не всегда адекватную) стоимость проекта можно извлечь в ходе поиска схожих проектов на фрилансерских биржах;

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

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

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

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

Для меня это было открытием.
Ответ написан
1) размытая задача = 100% проблемы
2) сроки при размытых задачах всегда «плывут»
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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