Обычный вопрос на форуме Sitepoint по бизнесу и праву: « Я выполнил то, что обещал, но мой клиент продолжает просить небольших настроек, поддержки и советов. Как определить, когда проект закончен, и как мне сообщить об этом моему клиенту? »
Большинство веб-разработчиков испытали «бесконечный проект» и могут сочувствовать разработчику в этом затруднительном положении. Нелегко сбалансировать отличный сервис с необходимостью установить некоторые границы и ограничения в отношении того, что вы готовы сделать для своего клиента, и это особенно сложно, когда вы только начинаете и вам нужно 100% удержание клиентов!
Хорошей новостью является то, что существует простой и простой способ предотвратить эту проблему: документ о принятии пользователя.
Признание пользователя — это то, на что это похоже — подтверждение от вашего клиента, что вы выполнили свою часть сделки (как указано в первоначальном контракте) и проект может завершиться. Согласие пользователя является обычным явлением в индустрии программного обеспечения и обычно состоит из документа одобрения пользователя (UA), который клиент подписывает и возвращает после завершения работы.
к их удовлетворению. В дополнение к определенной правовой структуре и подотчетности, связанной с завершением проекта, документ UA также служит кристально ясным сообщением для клиента, через которое вы пришли в конце сделки. Это также заставляет клиента явно принять работу, что заставит его дважды подумать о том, чтобы просить о постоянных бесплатных изменениях. Документ UA также служит четкой отправной точкой для гарантийного периода или начала следующего этапа.
Эффективный документ UA может быть длиной всего в одну страницу и иметь один абзац, содержащий такой язык, как,
«Нижеподписавшиеся соглашаются, что ABC WebDev, Inc. выполнила требования
изложенные в соглашении, подписанном 1 января 2006 года, и о том, что проект завершен ».
Вы можете расширить документ UA, чтобы объяснить размер оплаты (или другие условия) для текущей работы или продолжительность гарантийного периода, который в идеале начнется с момента подписания документа UA. Любые другие моменты, которые вы хотите прояснить, также должны быть включены в документ UA.
Чтобы документ UA действовал, необходимо учитывать следующие элементы:
- Клиент должен понимать, что означает документ UA. Концепция UA должна быть включена в ваш первоначальный контракт, и клиент должен знать, как она вписывается в общий поток проекта. Дайте понять, что когда вы закончите работу, вы отправите документ UA для подписи.
- У клиента должна быть некоторая мотивация для подписания документа и некоторая ясность в отношении того, что произойдет, если они этого не сделают. Хорошим способом решения этой проблемы является добавление языка к первоначальному контракту и документу UA, который определяет справедливые условия для завершения проекта, такие как:
1. Начиная со дня получения клиентом документа UA, у него есть 30 дней, чтобы сообщить о любых функциональных пробелах или других недостатках в доставленном продукте (вещи, которые вы обещали сделать, но не сделали). Дайте понять, что вы исправите любые такие недостатки как можно быстрее, бесплатно.
2. Гарантийный срок xxx дней начнется после подписания документа UA. Ошибки (но не существенные изменения, которые отличаются от первоначального соглашения!) Будут исправлены бесплатно в течение этого времени.
3. Если документ UA не будет подписан в течение 30 дней, договор автоматически прекратит свое действие и действие гарантии будет прекращено. Любые улучшения, ошибки или изменения, обнаруженные после завершения проекта или после истечения гарантийного срока, повлекут за собой новый счет.
Используя приведенные выше простые условия, средний клиент захочет подписать документ, чтобы гарантировать, что он не аннулирует гарантийный срок. Вы получаете выгоду от наличия четко подписанного документа UA, потому что вам не нужно беспокоиться о бесконечных запросах на изменение — если клиент запрашивает изменения после UA, он поймет, что с них будет взиматься плата.
Очевидно, что каждому разработчику необходимо настроить концепцию UA в соответствии с потребностями своего индивидуального проекта. В некоторых случаях разработчик не может предоставить готовый веб-сайт, пока не подписан документ UA. В других ситуациях подписанный документ UA должен сопровождаться полной оплатой. Независимо от того, как вы применяете концепцию UA, вы окажете большую пользу как себе, так и своему клиенту, имея официальную подписанную документацию в конце проекта, а не только в начале!