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

Question

[skvorets]

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


В чем вопрос.

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

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


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

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

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

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

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

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


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

Может какую-то литературу\статьи проштудировать посоветуете?

Answer 1

[Wott]

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

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

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

Comments

[skvorets]

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

Answer 2

[Пума Тайланд]

Разбиваете задачу на подзадачи, у каждой выставляете часы, часы умножаете на стоимость вашего часа, смету отправляете заказчику, цена адекватна и обоснована.
любые изменения влекут изменения в часах, если их нужно меньше продукт будет стоить дешевле, если больше то дороже, тоже все прозрачно и понятно заказчику.
ни один человек не написал как он будет писать хабр, выкладки по часам и подзадачам, так что всех кто там писал можно слить. аналог хабра поднять на лайвстрите два дня с допилкой, то есть 16 часов умноженных на 500 рублей 8 000 рублей, стоит аналог хабра на лайвстрите, можно разбить на подзадачи и более детальную смету по цене. Данное время взято из моего реального опыта.

Comments

[codecity]

>у каждой выставляете часы… цена адекватна и обоснована

Как вы определите насколько адекватно оценена подзадача? Конкретно 2 месяца для подзадачи «создать простейший wysiwyg html editor» — это много или мало?

>аналог хабра поднять на лайвстрите два дня с допилкой

Почему 2 дня? Разве не 30 минут? Скачал дистрибутив, установил на сервер — и готово.

А сколько стоит сделать на своем движке? Ведь LiveStreet требует «присутствие копирайта (ссылки) на главной странице». Плюс ко всему, не известно насколько хорошо этот LiveStreet масштабируется. Ну и, что очень важно, на Хабре есть защита от ДДОС-атак (а вы знаете сколько это стоит?).

[samizdam]

> Конкретно 2 месяца для подзадачи «создать простейший wysiwyg html editor» — это много или мало?

«создать простейший wysiwyg html editor» по-хорошему надо дробить ещё на под задачи. Вплоть до :
а). Реализовать основные функции
аа). copy/past/cut - 5 часов
аб). Выделение bold / italic - 2 часа
б). Сверстать toolbar с кнопками - 2 часа
в). Назначить функции на события кнопок - 2 часа
г). Покрытие кода модульными тестами - 4 часа
д). и т.д. и т.п.....
Пока каждый подпункт не будет кристально ясен и вполне точно оценен. Сумма будет ближе к истине и адекватней.

Answer 3

[Алексей Сундуков]

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

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

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

Comments

[skvorets]

Спасибо! Некоторое время начал вести принудительную статистику времени отдельно по задачам.
В этом плане очень удобна программа ToDoList от Absractspoon, которая не раз на Хабре упоминалась. Жаль они ее развитие подзабросили.

[sisn]

skvorets:
На самом деле про Пи не шутка.
Это вполне соответствуют опыту многих людей.
Читайте Мифический Человеко-Месяц Брукса.

Answer 4

[contestar]

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

Answer 5

[Alex May]

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

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

Как то так.

Answer 6

[codecity]

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

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

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

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

Comments

[codecity]

Уточню, что просил оценить в часах разработчика, получающего $2500 в месяц в Мск (вполне реальная зарплата для C# разработчика, не ведущего).

[skvorets]

Интеесно в этом плане взглянуть на ответы на вопрос Сколько стоит сделать Хабр? Итак, внимание, ответы были в диапазоне от $700 (давший этот ответ был слит:) до $150000.

Answer 7

[Михаил Лялин]

1) размытая задача = 100% проблемы
2) сроки при размытых задачах всегда «плывут»