Рассчитали стоимость, а теперь клиент хочет повременить. Кто как отвечает?

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

Полностью согласен !.. хотя проблемы у самописа есть, если руки у программеров кривоваты))

Когда после 1 февраля он тебе напишет. Напиши в его стиле так... "Вы знаете сейчас у меня работа по очень дорогим проектам (можешь даже бюджеты какие написать 4000$ например) вы пожалуйста подготовче полное ТЗ и у меня после 21 (ну к примеру) будет свободное окно для работы с вами"

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

И это очень правильно. Наблюдала работу таких заказчиков изнутри около 3-х месяцев. Как правило, в таких конторах до фига ЛПР и управленцы элементарно не могут договориться между собой, перебрасывая ответственность и задачи друг на друга. В итоге работа с ними - это еще тот ад.

Выход один: сразу четко оговаривать условия сотрудничества и правок. Если клиент хочет работать - он доверяет вам как профессионалу. Если начинает ходить туда-сюда, а потом еще канючить, как ему напортачили и теперь вся надежда на вас))...

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

это нереально. Много лет назад решили написать ТЗ на сайт, где постарались учесть всё. В итоге 106 страниц получилось и всё равно по ходу работы были неоговоренные моменты.

Всё реально, если поставить такую задачу и настойчиво ей следовать :p.

Если у Вас "всё равно по ходу работы были неоговоренные моменты" - значит, настойчивости в следовании принципу документирования всех условий не было достаточно.

В местах с нормальной дисциплиной работы возникновение любого момента, изначально не оговоренного, приводит к внесению правок или принятию дополнений к ТЗ.

Постепенно склоняюсь тому, чтобы делать поэтапные короткие ТЗ на 3-4 страницы.

Такой вот scrum в планировании работы.

.

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

В больших проектах и с большими конторами я как раз и работаю (на основной своей работе - но именно про неё я речь и вёл).

Так что - мимо :p.

Да, большинство деталей может вскрываться в процессе создания.

Это нормально.

Но это не значит, что их разобрать в принципе нельзя. Их разобрать можно. И нужно.

Вот когда они вскрываются - тогда они разбираются и документируются.

А что - кто-то требует следовать раннему представлению? 😕

Настойчивость, о которой я говорил, относится к необходимости документирования всех условий.

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

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