Фриланс

индекс
231,31

10 проблем при работе с заказчиками. Часть2.

1 часть - тут

Проблема 6. Клиент никогда не знает стоимость работ.

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

Методы решения:


1) просить показать техзадание и по нему(и только по нему!) называть стоимость работы, всегда будучи готовым пояснить из чего же эта цена сформирована (рейт, оценка по времени, оценка сложности и т.д.).
2) не работать с клиентами, которые не знают, сколько может стоить та или иная работа хотя бы приблизительно. Очень часто приходится стыкаться с тем, что клиент хочет создание CMS за 100у.е.
3) разбивать задание на несколько “подзаданий”, оценивая по очереди которые - в сумме можно сложить приблизительную цену проекта.


Проблема 7. Грамотность.

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

Методы решения:

1) Пересиливать себя и не обращать внимания на грамотность.
2) Не работать с таким заказчиком.


Проблема 8. Клиент всегда хочет больше, чем описано в ТЗ.

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

Методы решения:

1) За все, что не соответствует ТЗ - изначально оговаривать до старта работы - брать доплату. Но это более радикальный метод и врядли после этого проекта клиент задержится у Вас.
2) Если правки или дополнения мелкие - сделайте их бесплатно - клиент будет только рад таким подходом к делу - и еще не раз к Вам вернется, если Вы успешно закончите проект.
3) Если правки большие и существенные - оформлять как дополнительные затраты по ходу проекта и выставлять счет клиенту. И самое главное - не забыть подобные моменты изначально обговорить до старта разработки.


Проблема 9. Клиент слабо ориентируется в технических моментах.

В первую очередь клиента волнует успешное завершение проекта и получение того, что он заказывал. Однако под многими понятиями заказчик и исполнитель понимают немного разные вещи. На моей практике была ситуация, когда заказчик думал, что заказывая дизайн - в результате он получит сверстанный дизайн в формате html. Хотя это уже не дизайн - а верстка ( или HTML-коддинг ). Верстку я клиенту в итоге выполнил бесплатно - но для себя сделал вывод, что лучше заранее обговаривать все подробности.

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

Методы решения:


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


Проблема 10. Клиент считает, что он профи в этой области.

Это пожалуй самый сложный тип клиентов - очень часто на самом деле это не профи, а обычный “зазнайка”, который кандидата в мастера спорта выберет с закрытыми глазами, коня остановит на скаку и при этом не имеет достаточно теоретических и практических знаний, чтобы это осуществить.

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

Методы решения:


1) Пропускать мимо ушей разговоры о том, как “крут” клиент.
2) Не работать с таким типом клиентов.


Оригинал находится тут
+19
13 октября 2007, 02:58
34

комментарии (44)

+1
serverok #
Хорошая статья. У меня недавно был один из описанных случаев:
когда заказанная система была на 70% готова клиент захотел внести дополнения и переработки (некоторые были кардинльные). Решилось увеличением бюджета в 2 раза... Клиент с этим согласил после простого объяснения что нужно будет переделать и сделать на этом этапе проекта.
0
anycolor #
У меня такая же ситуация 2 месяца назад была :)
0
lumega #
если у вас возникают такие проблемы - ответ один - наймите хорошего менеджера
0
serverok #
если вы фрилансер, тогда Вы исполняете все обязанности в одном лице.
0
anycolor #
Это распространенное заблуждение. Менеджер не может быть фрилансером? И кто сказал, что фрилансер должен быть семиделкой?
0
MTonly #
Что такое «стыкались»?
0
anycolor #
"Стыкались" = "Имели с этим дело".

Надеюсь, что это не подколка была.
0
mx2000 #
видимо подразумевалось "сталкивались" ;-)
0
kvas #

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


Одному мне кажется что автору надо поискать бревно в своём глазу, или теперь правда принято вместо "сталкивались" писать "стыкались"?
0
anycolor #
Исправлено.

Всегда интересовал такой вопрос: зачем искать в тексте нелогичности, а не оценивать то, что написано? Орфографию - я еще понимаю, никому не приятно читать криво написанные тексты. А логичность слов то тут причем? Изменил слово - смысл стал другим?
0
MikeOzornin #
Да, так намного лучше.
Слова "стыкались" вообще не понял б.
+1
kvas #
Я просто слово "стыкаться" вообще никогда не видел, вот глаз и зацепился. А потом ещё пункт 7 програмотность... :)

По сути у меня замечаний нет. Фрилансингом я правда почти не занимался, но из опыта нефрилансинга тоже есть подобные наблюдения. Причём часто клиент так ведёт себя по незнанию, а не из-за злого умысла (просто он сам толком не знает чего он хочет, так как не специалист в информационных системах), так что ваш довольно конструктивный подход по-моему верный.
0
mx2000 #
Господа, вы перетираете следствия проблемы, которая была успешно решена 7 лет назад. Проблема осталась в головах людей; в неверном представлении о том, что такое разработка программного обеспечения на самом деле.

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

Вообщем, перечитайте Кента Бека, пропагандируйте agile software development и будет вам счастье ;-)
0
beskov #
agile-agile'ом, но основная часть заказов на фрилансе - это дизайн, вёрстка и модульное программирование/настройка CMS, а не комплексная разработка софта.

для 200-баксовой задачи делать клиенту на 8 часов предварительный треннинг/консалтинг по agile нецелесообразно, тем более что многие дизайнеры правомерно даже не знают, что это такое и как его применять
0
mx2000 #
Практика показывает, что даже 200-баксовая задача может вырасти до неимоверных размеров. Вопрос в том, будете ли вы на протяжении 2 месяцев корячиться за 200 баксов. Трейнинг клиента - инвестиции в будущее сотрудничество.
0
beskov #
Хорошо, расскажите о том, как построить работу по созданию дизайна на agile-принципах.
0
mx2000 #
Не являясь дизайнером, осмелюсь предположить, что дизайн заказывается на основании некой работающей системы (будь то сайт, портал, блог - не суть), которая есть у клиента в распоряжении.

Основные моменты, которые я бы выделил:
1. Дизайнер является последней (пред-)инстанцией, следовательно всегда можно пощупать и обсудить, что именно нужно дизайнить.
2. Дизайнить можно итерационно, например, логотип -> шапка, футер -> шрифты -> цвета -> картинки -> нюансировка.
3. Дизайнить нужно не статику, а динамику. Не поверхность листа А4, а сущности системы.
4. совместная интерактивная работа дизайнера и заказчика: гораздо быстрее, легче и продуктивнее работа будет протекать, если заказчик присядет рядом на стульчик и вместе с дизайнером найдет оптимальный вариант.

P.S. Не путать freelance с outsourcing services.
0
simeona #
Очень редко приходится встречать клиента, который понимает, сколько стоит реально то, что требуется сделать - большая часть клиентов имеют некий бюджет и пожелания того, что нужно сделать в итоге.

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

Примерно то же самое и нужно делать фрилансерам.
0
anycolor #
Однако, если бы было только так, что клиент не знает, из чего состоит бюджет работы. Больше проблема, когда этот же клиент начинает ерепениться и доказывать, что он лучше знает, и что "его программист сделает дешевле, только он сейчас занят".
0
khim #
Самое обидное что при этом он, как правило, прав. Ибо при не слишком больших заказах (а большие фрилансерам обычно не дают) обычно существенная часть времени и сил уходит на выяснение деталей, которые штатный сотруднику уже знает. Как какой-то менеджер американской фирмы, rоторая активно использует оутсорсинг мне сказал: индус в Индии потратит на работу вдвое больше времени, чем мой сотрудник, но его час работы обходится мне втрое дешевле так что игра стоит свеч...

Если клиент этой базовой вещи не понимает - то с ним о дальнейшем говорить бесполезно...
0
mx2000 #
На самом деле фрилансер тоже не знает, сколько реально стоит то, что нужно сделать.
0
simeona #
На основании предыдущего опыта необходимо оценить сколько времени займет работа, прибавить риск-тайм (скажем,20%) и назвать сумму которую стоит это потраченное время.
Другое дело, если опыта пока маловато, тогда приходится брать сумму из головы, что уменьшает уверенность в своей правоте.
0
mx2000 #
Эм... Неверно, потому что прикидывая объем девелопер изначально предполагает минимально необходимую реализацию. Заказчик - наоборот - старается выжать максимум из поставленной задачи.

Вы никогда не сталкивались с фразой "ну это же стандартная фича" или "ну это же очевидно", "это предполагалось"?

Банальный пример: нужно совместить логин для форума phpBB с некой кастомной системой, например xcart. Ваш вариант оценки трудозатрат и стоимости такой задачи?
0
simeona #
Спасибо за вопрос, но я не веб-девелопер. Я говорил о способе, каким должна формироваться цена. Конечно, заказчик будет говорить, что "это стандартная фича", "почему на это требуется столько времени". Однако, дизайнер (да и вообще любой исполнитель) на основании собственного опыта должен настоять на своей оценке.
Поэтому я и говорю, что при недостатке опыта очень легко ошибитья и согласиться разработать "стандартную фичу" за 1 день.:)
0
Yukka #
Очень порадовало решение многих проблем:
1. Забить
2. Не работать
0
anycolor #
Я проповедую политику - если не нравится то, что нужно делать - не делай. Так жить интереснее и не возникает расстройств по поводу, что начинается казаться, что делаешь что-то не то..
0
Yukka #
Да, я полностью поддерживаю. Хотя в современных условиях сложновато.
0
demon_guru #
Все "решения" проблем, которые тут приводятся, по большей части подходят только для опытных фрилансеров.
Фрилансеры с небольшим опытом и портфолио, без отзывов, которые только начинают свою карьеру на рынке free-lance не смогут диктовать работодателю свои условия.
Поэтому они частенько работают без предоплаты на свой страх и риск.

На нашем проекте фри-ланс.ру реализован сервис "Сделка без риска". Который помогает не остаться без денег фрилансеру или без сделанной работы работодателю.
0
anycolor #
Да, к сожалению, для неопытных фрилансеров - советы может и не подойдут, но нужно в себе воспитывать такой подход к решению вопросов, иначе позже - будет сложнее.
0
marabou #
Интересно, а что делать, если заказчик сам не знает толком, что ему надо и не может этого объяснить? Однозначно отказываться от проекта? Наверное да, т.к. всё равно ничего хорошего из этого не выйдет. Или всё-таки попытаться сделать проект и предложить заказчику уже готовое решение с риском потери денег?
0
anycolor #
Пытаться составить ТЗ с клиентом, с условием оплаты клиентом составления ТЗ. Если клиенту такое не подходит - лучше разойтись, либо работать на свой страх и риск (могут не заплатить, может закончится ничем проект).
0
mx2000 #
Меня смущает момент оплаты клиентом составления ТЗ. ТЗ для клиента не является ценностью, соответственно, платить за ТЗ - бред.
0
anycolor #
Как же так? А как без ТЗ делать проект?:)
0
mx2000 #
Клиент должен оплачивать ТЗ только в случае продолжения проекта "после ТЗ".
0
anycolor #
Почему же? Никогда не видели, чтобы клиенты заказывали ТЗ в одном месте, а реализацию в другом? Примеров - море.
0
mx2000 #
Наблюдал неоднократно, только обычно все дискуссии сводились к тому, что предоставленное клиентом ТЗ не является полноценным и мы настаивали на создании нового ТЗ. Это так же как с кодом — как ни крути, а рано или поздно придется переписывать.
0
anycolor #
Вы знакомы с термином "Not Invented Here" ?
0
mx2000 #
Вы про "изобретение колеса"? Каким боком это относится к теме дискуссии в разрезе ТЗ? :-)
0
anycolor #
К тому, что Вы как раз и настаиваете на изобретении колеса. Представляете, если бы допустим каждая компания, что использует в своем производстве детали сторонних разработчиков вдруг начала говорить, что им лучше с нуля эти детали у себя произвести, ведь мол "они предоставляют не полноценные детали"?

Зачем тогда пишется столько Open Source и т.д.?
0
mx2000 #
Изобретение колеса - это плохо?
0
anycolor #
Это не плохо. Это трата времени и очень часто - не логичная.
0
count #
Слишком часто за 2 части встречается "не работать с таким клиентом". Так может проще вовсе не работать фрилансером тогда? )
+1
anycolor #
Возможно для Вас это и выход. Мой опыт фрилансера говорит обратное - лучше не тратить время на нерадивых клиентов - будет больше времени на толковых.
0
redhummer #
Разделяю

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