Изменение требований проекта - если клиент заплатит [закрыто ]

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

Больше работы == больше денег.

Возможно, вы можете расширить объем своего счета-фактуры, вместо того, чтобы называть отдельные функции, вы просто упоминаете «работа над домашней страницей», «шаблон дизайна x», «создание 5 производных страниц из шаблона x» и тому подобное.

Боритесь за свои деньги, вы сделали то, что хотели.

Я бы наверняка взял с них плату.

Подумайте о том, чтобы пойти в кафе, заказать чашку кофе и булочку. Вы откусываете булочку, но решаете, что на самом деле уже достаточно наелись, так что вы просто хотите свой кофе ... Вы все еще платите за него или говорите им, что передумали?

Для каждого проекта вы должны написать объем, который клиент подписывается. Объем должен включать все включенные функции и общую стоимость проекта. Чем более детализирован прицел, тем меньше у вас шансов быть «облаженным».

Если у вас есть подписанная копия документа, вы в основном застрахованы, даже если дело дошло до суда.

Что касается представления обвинения клиенту, вы должны упомянуть, что много тяжелой работы было вложено в реализацию « jQuery slider », и, поскольку он был частью исходной области видимости, вы должны взимать плату за это.

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

Все зависит от того, как вы договаривались о первоначальном техническом задании. Была ли у вас почасовая оплата или вы согласились на фиксированную ставку "за страницу"? В итоге, вам лучше всего беспокоиться, во-первых, о выполнении требований заказчика, а во-вторых, о том, как вы облажались, не договорившись заранее, если вы потратили часы, которые не можете выставить в счет. Они не знают, занимает ли слайдер jQuery 5 минут или 5 часов; это ваш отдел.

В будущем вам следует договариваться об этом заранее в четких формулировках. Кроме того, попробуйте поработать над тем, чтобы дать клиенту раннее представление о том, что он получит, используя такой инструмент, как Balsamiq Mockups. Наличие общего видения того, что они получат, облегчит весь процесс и даст вам уверенность в том, что вы движетесь в правильном направлении, прежде чем вы отправитесь в интенсивный процесс кодирования.

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

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

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

Я вижу два возможных решения:

1) Плата за время с максимальным временем для данного набора функций, но затем с дополнительным количеством времени на каждую модификацию.

2) Перейти XP. Постоянно доставляйте обновления. Ежедневно обсуждайте с клиентом, позволяя ему выбрать наиболее важные функции на этот день. Программное обеспечение или сайт всегда должны быть стабильными «кандидатами на выпуск», но с ограниченным набором функций (тех, которые клиент считает наиболее важными). Используйте диаграмму выгорания, чтобы оценить ваше расчетное время прибытия. Заряжайте часы или дни в зависимости от их текущих требований и ежедневного обзора реализованных функций, функций, которые необходимо реализовать, и состояния вашей диаграммы выработки. Клиент может отказаться от работающего сайта в любой момент или дать вам деньги за еще одну неделю работы.

Каждый раз, когда возникает путаница, имеет смысл исправить только ту часть, которая вызвала путаницу. Продолжение одного и того же процесса и ожидание других результатов бесполезно.

Что касается этого времени - Если вы конкретно не укажете, как вы справляетесь с чем-то подобным в контракте, я бы съел это и включил в категорию «Расходы на образование».

Я беру плату за функцию / функциональность при создании сайта. Поэтому, если просто уберу ползунок, потеряю деньги и время.

Неверно.

Продайте это кому-нибудь другому. Списывайте со следующего клиента плату за функцию и не тратьте на нее время.

Когда вы продадите его второму клиенту, вы заработаете вдвое больше денег.

Когда вы продадите его третьему клиенту, вы заработаете втрое больше денег.

Перепродать. Не спорьте по этому поводу.