Как вы предварительно оцениваете сроки?

Question

[vis0r]

Очень часто бывают клиенты которые приходят за доработками уже существующего проекта, или за исправлением косяков. Самая распространенная ситуация в решении таких задач это когда время потраченное на предварительное исследование фактически становится временем на само решение задачи. То есть заранее оценить даже приблизительно сколько времени потребуется нельзя (обязательно всплывут какие то подводные камни потому что проект чужой и что там наговнокодировано внутри ещё придётся разобраться).

При этом типичный российский заказчик подобных работ хочет точно знать бюджет, делает удивлённую физиономию когда слышит о discovery и ничего слышать не хочет про оплату за фактически потраченное время аргументируя это формулировками вроде «вот ты решишь проблему и скажешь мне -давай 100500килоденег».

Расскажите, а как вы действуете в подобных ситуациях? Как рассчитываете время и бюджет?

Comments

[Zhainar]

аргументируйте почему нужно предварительные анализ и почему это лучше, чем сразу прыгнуть на исправление косяков.

[vis0r]

Zhainar:
> почему нужно предварительные анализ
Потому что все сайты разные. Невозможно заранее предугадать на что я напорюсь там внутри. Очень часто бывают ситуации когда одну и ту же задачу можно решить 10-ю разными способами.
> сразу прыгнуть на исправление косяков
а ещё бывают задачи которые решаются не за час-два, а за несколько дней например. И как без анализа рассчитать стоимость и время?

Answer 1

[Yv]

1. Оценивать из опыта в нормо-часах
2. Закладывать риски от 10% до 30%. Соответственно, риски тем меньше, чем лучше вы знаете заказчика и его проект.

Comments

[VDoskuSvoi]

Какие 10%. Не стесняйся.
В ИТ риски - 3 раза. Читай Брукс "Мифический человеко-месяц". Мой опыт говорит о том, что он прав.

Answer 2

[Nokhchi Borz]

Нужно оценивать саму задачу, на сколько она сложна и сколько стоит выполнение такой задачи, а то сколько ты времени потратишь это уже не проблемы заказчика, как пример нужно сделать сайт, новичок 2 недели, средний программер неделя и это не означает что новичок должен больше просить так как он делал дольше. Как то так) Сроки это я так, чисто теоретически.

Comments

[Sanes]

А если не сделать, а переделать или починить?

[Nokhchi Borz]

Sanes: Например я даю определенный срок так званной гарантии если клиент не желает мне доверить обслуживание сайта, бесплатной гарантии. Все зависит от проекта, нельзя точно определить и сказать.

[vis0r]

Chee Borz: Не, ну если ты лепишь пельмени, то ты заранее конечно можешь просчитать сколько стоит один пельмень или их пачка. Они все одинаковые.

Я вот почему то не хочу писать ещё раз исходные данные которые указаны в вопросе...

Answer 3

[w1ld]

Первое, в такой ситуации это нужно описать ее заказчику. Правдиво сообщить, что оценить верно невозможно по каким-то причинам. Затем попробовать приблизительно оценить сколько займет само исследование на основе вашего опыта. Исследование должно дать шаги, которые приведут к решению. Всю задачу оценить можно только разбив на шаги и затем каждый шаг уже оценивать. Как вы разобъете и как потом оцените -- это зависит от вашего опыта. Продвинутые люди (McConnell, "Software Estimation...") говорят о вычислении времени на основе истории, а не на угадывании. Угадывание не надежно. Позволять угадывать можно давать только тем, кто будет делать шаги те. Как-то так, если кратко.

У МакКоннелла есть кое-что интересное об оценках времени. Он там пишет о том, как вы общаетесь с заказчиком; что именно обещаете; что заказчик просит; что собирать, чтобы потом оценивать верно и другое.

Ну еще можно почитать у Эндрю Ханта и Дэвида Томаса в "Программисте-прагматтике". Там уже к Agile они склоняются всё. У них об итерациях уже идет речь.

Answer 4

[VDoskuSvoi]

Оцениваешь время. С опытом твоя оценка все точнее. Умножаешь на 3. Обязательно. Это еще в прошлом веке объяснил проджект-менеджер, делавший операционную систему. Почитай, книжкам маленькая. Не пожалеешь. Брукс "Мифический человеко-месяц".

При этом типичный российский заказчик подобных работ хочет точно знать бюджет

Ты как заказчик, поступал бы также. Это свойство всех заказчиков. Хоть канадцев, хоть французов. Не проблема. И вообще заказчик не должен внимать в такие детали, не царское это дело. Не озвучивай твои затраты на чисто работу. Включай туда все накладные расходы. Не забывай оценку завышать. В 3 раза. Фактически это не обман. Любая оценка все равно слишком оптимистична. И завышение в 3 раза превращает ее в нормальную. Читай по этому поводу книжку Брукса.

ничего слышать не хочет про оплату за фактически потраченное время аргументируя это формулировками вроде «вот ты решишь проблему и скажешь мне -давай 100500килоденег».

Существуют различные виды организации работ и оплаты. Те, с кем я работаю давно, уже знакомы с моими расценками и не боятся. Применяю с ними оплату "по факту реально выполненных работ" постоянно. Заранее согласовываем только самые большие суммы. Ну а если заказчик хочет жесткого бюджета, то обязательно ограничивай его в объемах работ. Это можно сделать просто: система не будет уметь 1), 2), 3) таких-то вещей. Или детально прописывай, что значит "работа завершена".

Comments

[vis0r]

Спасибо за книгу, почитаю

Ну а если заказчик хочет жесткого бюджета, то обязательно ограничивай его в объемах работ. Это можно сделать просто: система не будет уметь 1), 2), 3) таких-то вещей. Или детально прописывай, что значит "работа завершена".

Возможно ты не совсем понял задачу. Я объяснял, что задачи у меня в основном — разбираться в чужих граблях и велосипедах. То есть чаще всего заранее вообще не известно какова сложность выполнения задачи, а исследование занимает половину, если не больше от общего времени на решение. И например если делать исследование каждому встречному-поперечному, то очень велик риск остаться вообще без заказа, так как приходится обосновывать цену результатами исследования (время потраченное на само исследование я конечно же включаю в стоимость). Получается что заказчик в итоге понимает в чём проблема, но уходит её исправлять к ближайшему Олексею из UA. Потому что дешевле.

Так же, реально несколько раз сталкивался с ситуацией, когда заказчик выбирал среди нескольких исполнителей которые называли какую-то вообще невероятно низкую стоимость, а на поверке оказывалось что эти исполнители даже ни на грамм не вникали в поставленную задачу и пути решения, наобум называя цену. Ну и конечно же благополучно сливались в процессе выполнения когда понимали что не вывозят.

Вообще, вот эта ситуация схожа с такой штукой как «кинуть на ТЗ». Я с таким тоже сталкивался, по этому тех задание делаю только за деньги, и никаких «в счёт будущей оплаты». Но если необходимость ТЗ ещё более менее можно обосновать даже для дядиПети из Нижнего Мухосранска, то исследование типичный русский заказчик не воспринимает как работу вовсе.

На западе кстати распространена такая вещь как Discovery (исследование) и подписание отдельного договора на него как на дополнительную услугу. Но только не в этой стране.