Как дать клиенту желаемый результат? Процесс разработки сайта

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

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

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

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

Несколько пунктов, как делать так, чтобы в результате клиент получил то, что хочет. Эти советы больше всего подойдут веб-разработчикам.

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

Часто бывает так, что одни задачи для клиента имеют более высокий приоритет, чем другие. Уточните это заранее. Более приоритетные задачи нужно сделать сначала. А менее приоритетные, возможно, со временем потеряют актуальность. Самое главное — дать возможность клиенту быстро увидеть полную картину.

На сайте могут быть очень много пользовательских сценариев. Для начала нужно разрабатывать самые распространенные сценарии, чтобы сайт начал хоть как-то функционировать. Когда сайт уже начинает функционировать, хоть и не совсем идеально, у клиента появляется какое-то представление, что в итоге должно получаться. Отталкиваясь от этой картины, он может при необходимости внести корректировки в ТЗ. Я считаю, что в самом начале разработки не очень эффективно быть перфекционистом. Иначе, на одном модуле сайта можно застрять очень долго.

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

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

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

Но, если вы веб-программист, который ещё занимается дизайном, этот пункт вас не касается.

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

Идеальный макет сайта должен содержать следующие пункты:

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

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

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

Мои контакты:

Сайт — code-guru.ru

Сообщество ВК — vk.com/code_guru