Проблема влазимопонимания между заказчиком и разработчиком: причины

Что лежит в основе проблем взаимопонимания между заказчиком и разработчиком?

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

1. Термины.

Хостинг, домен, модуль, CMS, расширенный поиск по каталогу с параметрами, продвижение, ТИЦ и т.д. Терминов в нашей сфере множество.

Бывает, разработчик говорит с использованием терминов или даже обыденных слов, которые заказчик просто не знает или понимает неправильно. Это относится не только к сфере разработок сайта, а в целом к жизни. Второй вариант – сам заказчик использует термин, чтобы объяснить что-то разработчику, но при этом обе стороны понимают этот термин по-разному.

Пример:

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

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

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

Также и со стороны заказчика: при разговоре вдруг может возникнуть секундная пауза – скорее всего это пропущенное и непонятое слово. Хорошо, когда заказчик знает, что такое хостинг. Хорошо, если он не знает, что это такое, но считает правильным уточнить. Но часто заказчик и не знает, и не уточняет.

Что в таких случаях делать?

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

Разговаривать с использованием терминов – проще и приятнее, но может возникнуть непонимание.

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

Также в ближайшем будущем мы сформируем список самых популярных терминов с объяснением их для заказчиков.

2. Различные взгляды на цели и методы реализации проекта

К нам обращается компания, торгующая компьютерами и комплектующими. Им нужен интернет-магазин. Какова цель существования интернет-магазина? Привести заинтересованного целевого пользователя на сайт, предоставить интересующий его товар и подробную информацию о нем, сконвертировать пользователя в покупателя посредством оформления заказа.

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

Вопрос: как это всё поможет продать единицу товара?

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

Иногда заказчик настолько четко для себя решил, что будет так и никак иначе, что «хоть ты с бубном перед ним пляши».

Тут возникает дилемма: можно создать то, что хочет заказчик или не создавать ничего.

В первом случае заказчик заплатит деньги и получит что-то, не приносящее пользу.

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

Очень не хочется вставать перед таким выбором.

3. Есть лицо (лица), ответственное за работу над проектом, и есть руководитель, принимающий проект.

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

Без комментариев.

Для себя мы решили этот вопрос следующим образом:

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

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

Но это мнение со стороны разработчика.

Что думают по этому поводу заказчики?

Какие еще проблемы взаимопонимания возникают у разработчиков?

Предлагаем высказываться в комментариях.

Вернуться назад