Комментарии 32
Огромное спасибо за статью. В избранное. Попытаюсь воспользоваться в следующий раз (-:
Если будут проблемы - отпишусь сюда (-:
Если будут проблемы - отпишусь сюда (-:
как ни рассчитывай - всё равно не угадаешь…
Что то уж больно по срокам большая растяжка получается со всеми этими 30%... как минумум по этой статье получается накидка процентов в 60!
Есть такое понятие - load factor. Это волшебная цифирь, которую получаешь, после того, как делишь реальные получившиеся сроки на прогнозировавшиеся. Так вот очень хорошо, если load factor равен 2. Мне встречались люди и с 4.
То есть вы хотите сказать, что прогнозируемое время в два раза меньше потраченого это хорошо?
Или тут закралась ошибка?
Или тут закралась ошибка?
в два раза меньше это лучше, чем в четыре раза. :)
Никакой ошибки. Хорошо, если в два раза. Но бывает и в четыре - об этом надо помнить. Оскорбляться можно сколь угодно долго, пока речь идёт об эстимейтах, которые даете Вы. Но однажды наступает ситуация, когда эстимейты дают Вам и тут остаётся только молиться, чтобы было хотя бы 2.
Я хочу сказать, что это обычное дело.
В законах Мерфи сказано:"Прикиньте время на проект, умножте на 2 и замените единицами более высокого порядка"
И вот в этой шутке как раз очень небольшая доля шутки :(
В законах Мерфи сказано:"Прикиньте время на проект, умножте на 2 и замените единицами более высокого порядка"
И вот в этой шутке как раз очень небольшая доля шутки :(
если программист назвал срок, умнож его на 4 и переведи в следующую еденицу измерения
Древняя и проверенная мудрость:
Время x1 = сферический конь в вакууме.
Время х2 = оптимистичный прогноз.
Время х3 = скорее, так и будет.
Время x1 = сферический конь в вакууме.
Время х2 = оптимистичный прогноз.
Время х3 = скорее, так и будет.
Хорошая статья
По этому поводу хорошо писал Стив Макконнелл в "Сколько стоит программный проект". Суть та же, но много дополнительной полезной информации.
Неплохо, но как то уж слишком "пальце в небо". Чтобы добиться хоть какой-то точности в оценке проектов (не важно по каким параметрвам - стоимость, время, размер, функциональность...) нужно читать много умных книжек по estimations (например, очень советую Стив Макконнелл "Сколько стоит программный проект") и ПРАКТИКОВАТЬ! Те постоянно упражняться в оценке, с каждым разом высчитывая все более близкий результат.
" 1. Насколько хорошо Вы знаете клиента? Всегда ли он придерживается условий, определенных изначально перед стартом проекта или постоянно добавляет пункты во время работы
Если в п1 ответ «добавляет», то к общей стоимости добавьте 30%-50% стоимости проекта, в зависимости от интенсивности добавления."
Не согласен. Если клиент в процессе работы добавляет новые условия, нужно сообщать клиенту, что дополнительные пожелания будут реализованы за отдельную плату после выполнения основных уже оговоренных условий. Если изменения кардинальные, нужно делать пересмотр цены вместе с заказчиком.
Если в п1 ответ «добавляет», то к общей стоимости добавьте 30%-50% стоимости проекта, в зависимости от интенсивности добавления."
Не согласен. Если клиент в процессе работы добавляет новые условия, нужно сообщать клиенту, что дополнительные пожелания будут реализованы за отдельную плату после выполнения основных уже оговоренных условий. Если изменения кардинальные, нужно делать пересмотр цены вместе с заказчиком.
Не соглашусь с вами. Добавлять стоимость на непредвиденное надо заранее. Все дело в том, что люди не любят платить дополнительно. Каждая новое, хоть минимальное, ваше требование новых денежных вложений болью отзывается в клиенте. Из собственной практики, лишь 1 из 7-8 клиентов "правильный" и понимает, что все эти "минимальные улучшения" - это тоже время, и в сумме существенное.
Лучше по окончании работ - скажите клиенту, что объем работ оказался меньше, и поэтому вы делаете ему скидку.
Лучше по окончании работ - скажите клиенту, что объем работ оказался меньше, и поэтому вы делаете ему скидку.
Речь о новых условиях. Если же разговор идет о мелких правках, которые дополнительно увеличивают время выполнения проекта на 1-2 часа (точная цифра, конечно, варьируется от проекта к проекту), то они с лихвой покрываются теми 30% из пункта «на всякий случай».
В общем да, и тут есть некая тонкая грань - между небольшой правкой и новыми условиями. Дело в том, что если проект достаточно протяженный - например, три месяца, то реквестов на "небольшие поправки" может стать много. А если их много - это уже как новая фича. Готов ли человек будет оплатить это в конце? С другой стороны, если мы с самого начала идем на "небольшие бесплатные" уступки, это позволит человеку и в дальнейшем воспринимать их как бесплатные, прося еще и еще. Как тут быть - вопрос без рецептов, имхо.
То что введены понятия рисков - это уже хорошо. Как-то раз начали большой проект в крупной организации, сдача первого этапа через год, всё нормально. По прошествии трёх месяцев как гром среди ясного неба - один из ответственных членов Правления Заказщика, дабы не ударить в нашу грязь своим лицом, озвучил Руководству, что система уже стоит на фронте и процесс тестирования пошёл...
С матом и прибаутками последующие три месяца я руководил форсированной экстремальной разработкой Системы. Что-то даже получилось. Это что-то было названо Прототипом и успешно было поставлено Заказщику.
Спич был про такой момент, как периодическую коррекцию учета рисков.
С матом и прибаутками последующие три месяца я руководил форсированной экстремальной разработкой Системы. Что-то даже получилось. Это что-то было названо Прототипом и успешно было поставлено Заказщику.
Спич был про такой момент, как периодическую коррекцию учета рисков.
Хорошая статья. Еще можно добавить постоянные расходы: телефон, интернет, амортизацию оборудования (компьютер, факс). Расходы на бухгалтерскую поддержку. Хотя бы грубо прикинуть, сколько в месяц тратится денег на это. Ну и потом соотнести со временем исполнения заказа.
сроки умножаем на Пи и оцениваем это время почасово ))
примерно так и есть
только я обычно оцениваю в часах, стараясь учесть все неприятные факторы
а затем просто умножаю на два и получаю более-менее реальную оценку в рабочих часах, из неё вывожу стоимость
реальный срок исполнения зависит от обстоятельств, но в общем это 4-8 рабочих часов в сутки (сюда закладываются потери на обучение, перебои в работе и пр.)
пример:
есть достаточно понятная задача, но без детального ТЗ.
задача займёт 10-15 часов рабочего времени в зависимости от деталей.
нет ТЗ (заказчик сам виноват) - берём по максимуму, умножаем на два
30 часов
пусть стоимость часа равна 500 руб.
тогда стоимость всего заказа будет 15 000 руб.
срок исполнения (детального ТЗ нет, придётся согласовывать с заказчиком, плюс есть пара скользких моментов - понадобится изучить документацию) = 30 часов делим на 6 часов в день, получаем 5 рабочих дней = календарная неделя
мой ответ заказчику: я сделаю это за 15 тыс. за одну неделю.
Эту схему я применяю, когда просят быстро оценить порядок стоимости выполнения задачи. А когда можно подумать/поторговаться, то алгоритм приближается к описанному автором :))
Успехов!
только я обычно оцениваю в часах, стараясь учесть все неприятные факторы
а затем просто умножаю на два и получаю более-менее реальную оценку в рабочих часах, из неё вывожу стоимость
реальный срок исполнения зависит от обстоятельств, но в общем это 4-8 рабочих часов в сутки (сюда закладываются потери на обучение, перебои в работе и пр.)
пример:
есть достаточно понятная задача, но без детального ТЗ.
задача займёт 10-15 часов рабочего времени в зависимости от деталей.
нет ТЗ (заказчик сам виноват) - берём по максимуму, умножаем на два
30 часов
пусть стоимость часа равна 500 руб.
тогда стоимость всего заказа будет 15 000 руб.
срок исполнения (детального ТЗ нет, придётся согласовывать с заказчиком, плюс есть пара скользких моментов - понадобится изучить документацию) = 30 часов делим на 6 часов в день, получаем 5 рабочих дней = календарная неделя
мой ответ заказчику: я сделаю это за 15 тыс. за одну неделю.
Эту схему я применяю, когда просят быстро оценить порядок стоимости выполнения задачи. А когда можно подумать/поторговаться, то алгоритм приближается к описанному автором :))
Успехов!
Хорошая, правильная статья - относительно сроков.
Относительно стоимости - на самом деле, есть и другой подход к ее вычислению. А именно: Ваша работа стоит не столько, сколько вы потратили на нее сил, а столько, сколько за эту работу готов заплатить клиент.
Но это очень сложно - мыслить такими категориями.
Относительно стоимости - на самом деле, есть и другой подход к ее вычислению. А именно: Ваша работа стоит не столько, сколько вы потратили на нее сил, а столько, сколько за эту работу готов заплатить клиент.
Но это очень сложно - мыслить такими категориями.
Хоть бы кто-то поставил себя на место заказчика ;)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как удачно расчитать цену и время проектов во фрилансе