Как не попасть в ловушку при разработке сайта
Когда речь заходит о документации и формальных вопросах всегда появляется больше работы и запары, но поверьте, в этом случае это стоит того!
Очень много фрилансеров и небольших агентств попадают в такую ловушку (даже рабство) как “А поменяйте вот тут цвет”, “Посмотрела у моего конкурента вот так сделано, меняйте”, по другому это ловушка бесконечный правок.
Откуда ноги растут?
Надо понять, что правки, разногласия в мнениях во время творческой работы и работы в сфере дизайна — это неизбежно. Создание сайта, это всегда что-то новое, индивидуальное под клиента. У всех свое видение того, как должно это выглядеть, но если не сделать определенные действия перед началом разработки сайта, то можно увязнуть в эти правки на совсем, и тогда простой лендиг, который вы собирались закончить на неделю и получить деньги, превращается в вялотекущую историю на месяц…
Есть две главные причины по которым это происходит, по опыту коллег и нашему опыту, это пустое неполное ТЗ и отсутствие четких этапов разработки и их согласования. По порядку:
ТЗ - ЭТО ОСНОВА
Без тз результат хз, если вы составили ТЗ так, что клиент прописал в нем только общую информацию, по типу: “Ну функциональность, добавить соцсети, такие вот цвета и бла бла”, То ПРАВКИ БУДУТ и много.
Еще хуже, если подобное ТЗ вам отправил клиент. Техническое задание — это то, на что мы опираемся при создании сайта, и что будет считаться нашей конечной работой. А когда этого нет, то мы никак не можем определить: какой этап является правкой, доп работой, а что все еще является созданием сайта?
Тз должно содержать каждый этап, блок потенциального сайта, множество пунктов, которые будет заполнять клиент. Если клиент сам отправляет тз и оно, мягко говоря, не очень, то требуйте заполнить свое. Иначе никак. Само по себе, это облегчит вашу работу и к тому же, вы сможете точно понять конец работы над проектом, и когда начинается этап правок.
Если вы не поняли какой-то вопрос по пункту или нужно что-то дополнительно узнать, то пишите и созванивайтесь об этом с клиентом ДО разработки.
Отсутствие четких этапов
Неважно, речь идет о лендинге на тильде или о целом сайте на коде, вам нужно разделить работу на этапы: прототипирование, макет, дизайн, верстка и т.д. Когда вы молча начинаете работу, четко это не согласовав, а потом, в конце сайт вываливается клиенту на голову, у него будет шок и конечно же много правок!!! Так как вы не согласовали каждый этап работы, вам придется получать критику и правки по КАЖДОМУ ЭТАПУ.
Именно поэтому нужно согласовывать все отдельно. Сначала макет, вы обсудили, показали прототип сайта, и больше вы к этому не возвращаетесь, если вдруг в голову клиента резко взбредет изменить фундамент проекта, это уже будет платно.
Затем переходите на следующие этапы. Пока не получите точный ответ да или нет на этап, к следующему не переходите. Соблюдая только это просто правило, процент правок сократиться вдвое. Особенно жизни необходимо это при разработке большого сайта на коде. Представьте ваше лицо, когда в конце проекта вам клиент говорит поменять макет сайта…
Юридическая часть
С этой стороны себя тоже необходимо защитить, ведь если клиент начнет предъявлять что-то, только ваш договор спасет вас.
В нем четко должны быть прописаны этапы работы, следование тз, и количество правок страниц.
Сколько правок будет нормой?
Бывает по разному, если поставить слишком мало бесплатных правок это может ухудшить ваши долгосрочные отношения с клиентом, с другой стороны слишком большее количество повесит клиента на вашу шею. На этапе макета, можно поставить до 20 правок и 3 интераций. На следующих этапов максимум 10 правок или 1 интерации. Кол-во правок может быть у всех разное, иногда даже можно делать больше правок бесплатно, чтобы повысить вашу лояльность и репутацию вашего бренда.
Что такое вообще 1 правка и 1 интерация?
1 правка – правка одного элемента, включает, но не ограничивается: изменение цвета, размера шрифта, медиа элемента и иное.
1 интерация – предоставление исправленного макета с 10 внесенными правками.
Всё это должно быть прописано в договоре.
Не соглашайтесь на все правки
Также частой ошибкой может быть внесение всего, что сказал вставить клиент. Помните, клиент не дизайнер, не программист, он может иметь свое понимание и представление о конечном продукте, но часто идеи клиента могут быть совсем плачевными. Здесь то вам и нужно включаться, грамотно объяснять почему это не лучшая идея, приводить доказательства, убеждать.
Заключение
Правки — это неизбежно, дизайн это субъективная вещь, у каждого свое “правильное” видение, однако необходимо прийти к чему то общему, и не соглашаться с каждой идеей клиента, так как зачастую они могут ухудшить работу.