| 1C |
| 1С v8 |
22.01.16
✎
13:30
| 1. Другой вариант | 67% (4) |
|
| 2. По фикспрайсу | 17% (1) |
|
| 3. По листу учета рабочего времени | 17% (1) |
|
1. Вводная часть.
Когда клиенты начинают поджиматься по деньгам, они часто спрашивают - а сколько будет стоить та или иная хотелка, перед тем как её заказывать. Понятно что если делал что-то похожее в типовых или пишешь с нуля, то можешь примерно оценить, +/-30%. А как быть, если работаешь с этим в сложной типовой конфе, содержащей тысячи строк, в первый раз?
2. Пример 1.
Понадобилось мне когда-то дорабатывать для клиента систему начисления и восстановления резервов по сомнительным долгам. У него в учетной политике задолженность признавалась просроченной в зависимости от сроков годности продукции, да еще и в зависимости от этих сроков расчет шел как по календарным, так и по рабочим дням. Провозился я с доработкой конфы, тестированием, проведением по регистрам существующих документов, неделю. Выставил клиенту часы, а он начал кривиться, что часов много. Хотя договаривались оплачивать по факту работы на его территории. Ну это неважно, при расчете фикспрайса я скорей всего занизил бы часы раза в 2, т.к. с одной стороны понадеялся бы на простоту задачи, а с другой стороны прогибал бы заказчик.
3. Пример 2.
Заказчику была нужна система ограничения доступа к документам для пользователей в зависимости от складов и чего-то еще, я уж не помню. И нужна была она ему давно и что-то никто ему не мог её толком сделать. Ну я оценил с запасом и сделал раза в 3 быстрее, оказалось чего-то там общий модуль поправить слегка, а дальше всё само подхватится механизмами конфы.
4. Вопрос:
Выходит, с фикспрайсом за доработки черных ящиков типовых конфигураций можно как пролететь, так и сработать со сверхприбылью. Имеет ли вообще смысл пытаться оценить реальную трудоемкость или лучше заряжать сразу по полной, сколько клиент готов оплатить? При этом есть риск что клиент отвалится, правда и по факту может выйти дофига что откажется подписывать. А как работаете вы?
Когда клиенты начинают поджиматься по деньгам, они часто спрашивают - а сколько будет стоить та или иная хотелка, перед тем как её заказывать. Понятно что если делал что-то похожее в типовых или пишешь с нуля, то можешь примерно оценить, +/-30%. А как быть, если работаешь с этим в сложной типовой конфе, содержащей тысячи строк, в первый раз?
2. Пример 1.
Понадобилось мне когда-то дорабатывать для клиента систему начисления и восстановления резервов по сомнительным долгам. У него в учетной политике задолженность признавалась просроченной в зависимости от сроков годности продукции, да еще и в зависимости от этих сроков расчет шел как по календарным, так и по рабочим дням. Провозился я с доработкой конфы, тестированием, проведением по регистрам существующих документов, неделю. Выставил клиенту часы, а он начал кривиться, что часов много. Хотя договаривались оплачивать по факту работы на его территории. Ну это неважно, при расчете фикспрайса я скорей всего занизил бы часы раза в 2, т.к. с одной стороны понадеялся бы на простоту задачи, а с другой стороны прогибал бы заказчик.
3. Пример 2.
Заказчику была нужна система ограничения доступа к документам для пользователей в зависимости от складов и чего-то еще, я уж не помню. И нужна была она ему давно и что-то никто ему не мог её толком сделать. Ну я оценил с запасом и сделал раза в 3 быстрее, оказалось чего-то там общий модуль поправить слегка, а дальше всё само подхватится механизмами конфы.
4. Вопрос:
Выходит, с фикспрайсом за доработки черных ящиков типовых конфигураций можно как пролететь, так и сработать со сверхприбылью. Имеет ли вообще смысл пытаться оценить реальную трудоемкость или лучше заряжать сразу по полной, сколько клиент готов оплатить? При этом есть риск что клиент отвалится, правда и по факту может выйти дофига что откажется подписывать. А как работаете вы?
22.01.16
✎
13:31
(0) вопрос обсужден 100500 раз
Другой вариант
22.01.16
✎
17:05
а ну да
Другой вариант
25.01.16
✎
15:33
При оценке сообщаю разброс от и до (в НЧ и/или деньгах)
Если оценка в таком формате слишком сложна для заказчика, то оставляю только "до" и озвучиваю это как конечную оценку
Если оценка в таком формате слишком сложна для заказчика, то оставляю только "до" и озвучиваю это как конечную оценку
Другой вариант
гуру
25.01.16
✎
15:50
(0) Практика показывает, что истина где-то посередине.
Простые задачи решаются по ЛУРВу. Это, когда абсолютно четко понятно что и как надо, и сколько это может занять времени.
Сложные задачи решаются по предварительной оценке.
Тут возможны варианты:
1. Оценка дала четкий объем трудозатрат. Тупо выставляем ценник.
2. Оценка не четкая. Закладываем риски. Предупреждаем клиента о примерной стоимости (вилке цен). В случае, если по дороге понимаем, что сильно ошиблись, то обязательно предупреждаем клиента о возникших трудностях и согласовываем изменение цены или закрываем проект.
В любом случае работа на сопровождении пляшет от часов.
Если речь идет о проектных работах (есть постановка, есть ТЗ хотя бы в кратком виде, есть планы и сроки выполнения), то тут отталкиваясь от плана выставляется и единый ценник. Все отклонения - либо отдельно согласованным ТЗ, либо риск исполнителя.
Простые задачи решаются по ЛУРВу. Это, когда абсолютно четко понятно что и как надо, и сколько это может занять времени.
Сложные задачи решаются по предварительной оценке.
Тут возможны варианты:
1. Оценка дала четкий объем трудозатрат. Тупо выставляем ценник.
2. Оценка не четкая. Закладываем риски. Предупреждаем клиента о примерной стоимости (вилке цен). В случае, если по дороге понимаем, что сильно ошиблись, то обязательно предупреждаем клиента о возникших трудностях и согласовываем изменение цены или закрываем проект.
В любом случае работа на сопровождении пляшет от часов.
Если речь идет о проектных работах (есть постановка, есть ТЗ хотя бы в кратком виде, есть планы и сроки выполнения), то тут отталкиваясь от плана выставляется и единый ценник. Все отклонения - либо отдельно согласованным ТЗ, либо риск исполнителя.
Другой вариант