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

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

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

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

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

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

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

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

    Для меня это было открытием.
    Ответ написан
    2 комментария
  • Тонкости оценки стоимости работы?

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

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

    Как то так.
    Ответ написан
    Комментировать
  • Тонкости оценки стоимости работы?

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

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

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

    ozware
    @ozware
    Кстати, если на сервере стоит CentOS, то рекомендую подключить вот эти репозитарии: centos.alt.ru/?p=120 (см. «Установка репозитория»)

    потом надо сделать следующее:
    1. yum update
    2. yum install mysql mysql-server php php-common php-cli php-mysql php-fpm php-gd php-suhosin php-mhash php-mbstring nginx (+ добавить нужные пакеты)
    3. настроить nginx, php-fpm и mysql

    я так уже несколько вебсерверов поднял :-)
    Ответ написан
    Комментировать