Прочитать первую часть
Проблема 6. Клиент никогда не знает стоимость работ.
Очень редко приходится встречать клиента, который понимает, сколько стоит реально то, что требуется сделать - большая часть клиентов имеют некий бюджет и пожелания того, что нужно сделать в итоге. Обычно ни о техзаданиях, ни о рейтах (оценка часа работы в денежном эквиваленте) - они ничего не слышали или слышали, но не стыкались.
Методы решения:
1) просить показать техзадание и по нему(и только по нему!) называть стоимость работы, всегда будучи готовым пояснить из чего же эта цена сформирована (рейт, оценка по времени, оценка сложности и т.д.).
2) не работать с клиентами, которые не знают, сколько может стоить та или иная работа хотя бы приблизительно. Очень часто приходится стыкаться с тем, что клиент хочет создание CMS за 100у.е.
3) разбивать задание на несколько “подзаданий”, оценивая по очереди которые - в сумме можно сложить приблизительную цену проекта.
Проблема 7. Грамотность.
Лично мне очень не приятно общаться и сотрудничать с заказчиком, который пару слов не может грамотно написать.
Методы решения:
1) Пересиливать себя и не обращать внимания на грамотность.
2) Не работать с таким заказчиком.
Проблема 8. Клиент всегда хочет больше, чем описано в ТЗ.
Во время работы над проектом - большинство клиентов вносят многие поправки в то, что нужно сделать. Иногда существенные, иногда не очень. На моей практике был случай, когда сделав 2-ой релиз системы из 3 через полгода после начала работы над проектом - клиент прислал много уточнений и дополнений таких, что зацепили большую часть ядра - в результате чего систему пришлось переделывать почти с нуля. Клиент хороший и давний - поэтому все решилось просто увеличением сроков и дополнительными вливаниями в бюджет проекта.
Методы решения:
1) За все, что не соответствует ТЗ - изначально оговаривать до старта работы - брать доплату. Но это более радикальный метод и врядли после этого проекта клиент задержится у Вас.
2) Если правки или дополнения мелкие - сделайте их бесплатно - клиент будет только рад таким подходом к делу - и еще не раз к Вам вернется, если Вы успешно закончите проект.
3) Если правки большие и существенные - оформлять как дополнительные затраты по ходу проекта и выставлять счет клиенту. И самое главное - не забыть подобные моменты изначально обговорить до старта разработки.
Проблема 9. Клиент слабо ориентируется в технических моментах.
В первую очередь клиента волнует успешное завершение проекта и получение того, что он заказывал. Однако под многими понятиями заказчик и исполнитель понимают немного разные вещи. На моей практике была ситуация, когда заказчик думал, что заказывая дизайн - в результате он получит сверстанный дизайн в формате html. Хотя это уже не дизайн - а верстка ( или HTML-коддинг ). Верстку я клиенту в итоге выполнил бесплатно - но для себя сделал вывод, что лучше заранее обговаривать все подробности.
И такие моменты случаются довольно часто. Поэтому теперь каждый раз, когда заказывают дизайн - я поясняю клиенту, что такое “дизайн” и что же клиент получит в результате. Это намного лучше, чем сделать работу и выяснить, что клиент хотел получить что-то другое.
Методы решения:
1) Быть немного дотошным - выяснять все подробности о работе и пояснять, что же клиент получит в результате Вашей работы.
Проблема 10. Клиент считает, что он профи в этой области.
Это пожалуй самый сложный тип клиентов - очень часто на самом деле это не профи, а обычный “зазнайка”, который кандидата в мастера спорта выберет с закрытыми глазами, коня остановит на скаку и при этом не имеет достаточно теоретических и практических знаний, чтобы это осуществить.
Настоящий профессионал - никогда не будет говорить, что он профи. Он будет это доказывать своими делами, а не словами.
Методы решения:
1) Пропускать мимо ушей разговоры о том, как “крут” клиент.
2) Не работать с таким типом клиентов.