Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Хорошая статья. У меня недавно был один из описанных случаев:
когда заказанная система была на 70% готова клиент захотел внести дополнения и переработки (некоторые были кардинльные). Решилось увеличением бюджета в 2 раза... Клиент с этим согласил после простого объяснения что нужно будет переделать и сделать на этом этапе проекта.
когда заказанная система была на 70% готова клиент захотел внести дополнения и переработки (некоторые были кардинльные). Решилось увеличением бюджета в 2 раза... Клиент с этим согласил после простого объяснения что нужно будет переделать и сделать на этом этапе проекта.
Что такое «стыкались»?
"Стыкались" = "Имели с этим дело".
Надеюсь, что это не подколка была.
Надеюсь, что это не подколка была.
Лично мне очень не приятно общаться и сотрудничать с заказчиком, который пару слов не может грамотно написать.
Одному мне кажется что автору надо поискать бревно в своём глазу, или теперь правда принято вместо "сталкивались" писать "стыкались"?
Исправлено.
Всегда интересовал такой вопрос: зачем искать в тексте нелогичности, а не оценивать то, что написано? Орфографию - я еще понимаю, никому не приятно читать криво написанные тексты. А логичность слов то тут причем? Изменил слово - смысл стал другим?
Всегда интересовал такой вопрос: зачем искать в тексте нелогичности, а не оценивать то, что написано? Орфографию - я еще понимаю, никому не приятно читать криво написанные тексты. А логичность слов то тут причем? Изменил слово - смысл стал другим?
Да, так намного лучше.
Слова "стыкались" вообще не понял б.
Слова "стыкались" вообще не понял б.
Я просто слово "стыкаться" вообще никогда не видел, вот глаз и зацепился. А потом ещё пункт 7 програмотность... :)
По сути у меня замечаний нет. Фрилансингом я правда почти не занимался, но из опыта нефрилансинга тоже есть подобные наблюдения. Причём часто клиент так ведёт себя по незнанию, а не из-за злого умысла (просто он сам толком не знает чего он хочет, так как не специалист в информационных системах), так что ваш довольно конструктивный подход по-моему верный.
По сути у меня замечаний нет. Фрилансингом я правда почти не занимался, но из опыта нефрилансинга тоже есть подобные наблюдения. Причём часто клиент так ведёт себя по незнанию, а не из-за злого умысла (просто он сам толком не знает чего он хочет, так как не специалист в информационных системах), так что ваш довольно конструктивный подход по-моему верный.
Господа, вы перетираете следствия проблемы, которая была успешно решена 7 лет назад. Проблема осталась в головах людей; в неверном представлении о том, что такое разработка программного обеспечения на самом деле.
В первом разговоре с клиентом следует говорить не столько о проекте, сколько о методологии, разложить по полочкам риски проекта и показать как методология разработки помогает уменьшить или исключить тот или иной риск. Из-за неразруленых рисков вытекает недоверие, неуверенность, сокрытие деталей о проекте клиентом, со всеми вытекающими.
Вообщем, перечитайте Кента Бека, пропагандируйте agile software development и будет вам счастье ;-)
В первом разговоре с клиентом следует говорить не столько о проекте, сколько о методологии, разложить по полочкам риски проекта и показать как методология разработки помогает уменьшить или исключить тот или иной риск. Из-за неразруленых рисков вытекает недоверие, неуверенность, сокрытие деталей о проекте клиентом, со всеми вытекающими.
Вообщем, перечитайте Кента Бека, пропагандируйте agile software development и будет вам счастье ;-)
agile-agile'ом, но основная часть заказов на фрилансе - это дизайн, вёрстка и модульное программирование/настройка CMS, а не комплексная разработка софта.
для 200-баксовой задачи делать клиенту на 8 часов предварительный треннинг/консалтинг по agile нецелесообразно, тем более что многие дизайнеры правомерно даже не знают, что это такое и как его применять
для 200-баксовой задачи делать клиенту на 8 часов предварительный треннинг/консалтинг по agile нецелесообразно, тем более что многие дизайнеры правомерно даже не знают, что это такое и как его применять
Практика показывает, что даже 200-баксовая задача может вырасти до неимоверных размеров. Вопрос в том, будете ли вы на протяжении 2 месяцев корячиться за 200 баксов. Трейнинг клиента - инвестиции в будущее сотрудничество.
Хорошо, расскажите о том, как построить работу по созданию дизайна на agile-принципах.
Не являясь дизайнером, осмелюсь предположить, что дизайн заказывается на основании некой работающей системы (будь то сайт, портал, блог - не суть), которая есть у клиента в распоряжении.
Основные моменты, которые я бы выделил:
1. Дизайнер является последней (пред-)инстанцией, следовательно всегда можно пощупать и обсудить, что именно нужно дизайнить.
2. Дизайнить можно итерационно, например, логотип -> шапка, футер -> шрифты -> цвета -> картинки -> нюансировка.
3. Дизайнить нужно не статику, а динамику. Не поверхность листа А4, а сущности системы.
4. совместная интерактивная работа дизайнера и заказчика: гораздо быстрее, легче и продуктивнее работа будет протекать, если заказчик присядет рядом на стульчик и вместе с дизайнером найдет оптимальный вариант.
P.S. Не путать freelance с outsourcing services.
Основные моменты, которые я бы выделил:
1. Дизайнер является последней (пред-)инстанцией, следовательно всегда можно пощупать и обсудить, что именно нужно дизайнить.
2. Дизайнить можно итерационно, например, логотип -> шапка, футер -> шрифты -> цвета -> картинки -> нюансировка.
3. Дизайнить нужно не статику, а динамику. Не поверхность листа А4, а сущности системы.
4. совместная интерактивная работа дизайнера и заказчика: гораздо быстрее, легче и продуктивнее работа будет протекать, если заказчик присядет рядом на стульчик и вместе с дизайнером найдет оптимальный вариант.
P.S. Не путать freelance с outsourcing services.
Очень редко приходится встречать клиента, который понимает, сколько стоит реально то, что требуется сделать - большая часть клиентов имеют некий бюджет и пожелания того, что нужно сделать в итоге.
На самом деле, когда вы первый раз приходите заказывать, скажем, пластиковые окна, у вас тоже нет ни малейшего представления о том, сколько реально стоит то, что потребуется сделать. Наверняка, у вас тоже есть некий бюджет. И уж совсем точно у вас есть понимание того, что нужно сделать в итоге.
Однако, вам сразу же объясняют и стоимость и то, из чего она складывается.
Примерно то же самое и нужно делать фрилансерам.
Однако, если бы было только так, что клиент не знает, из чего состоит бюджет работы. Больше проблема, когда этот же клиент начинает ерепениться и доказывать, что он лучше знает, и что "его программист сделает дешевле, только он сейчас занят".
Самое обидное что при этом он, как правило, прав. Ибо при не слишком больших заказах (а большие фрилансерам обычно не дают) обычно существенная часть времени и сил уходит на выяснение деталей, которые штатный сотруднику уже знает. Как какой-то менеджер американской фирмы, rоторая активно использует оутсорсинг мне сказал: индус в Индии потратит на работу вдвое больше времени, чем мой сотрудник, но его час работы обходится мне втрое дешевле так что игра стоит свеч...
Если клиент этой базовой вещи не понимает - то с ним о дальнейшем говорить бесполезно...
Если клиент этой базовой вещи не понимает - то с ним о дальнейшем говорить бесполезно...
На самом деле фрилансер тоже не знает, сколько реально стоит то, что нужно сделать.
На основании предыдущего опыта необходимо оценить сколько времени займет работа, прибавить риск-тайм (скажем,20%) и назвать сумму которую стоит это потраченное время.
Другое дело, если опыта пока маловато, тогда приходится брать сумму из головы, что уменьшает уверенность в своей правоте.
Другое дело, если опыта пока маловато, тогда приходится брать сумму из головы, что уменьшает уверенность в своей правоте.
Эм... Неверно, потому что прикидывая объем девелопер изначально предполагает минимально необходимую реализацию. Заказчик - наоборот - старается выжать максимум из поставленной задачи.
Вы никогда не сталкивались с фразой "ну это же стандартная фича" или "ну это же очевидно", "это предполагалось"?
Банальный пример: нужно совместить логин для форума phpBB с некой кастомной системой, например xcart. Ваш вариант оценки трудозатрат и стоимости такой задачи?
Вы никогда не сталкивались с фразой "ну это же стандартная фича" или "ну это же очевидно", "это предполагалось"?
Банальный пример: нужно совместить логин для форума phpBB с некой кастомной системой, например xcart. Ваш вариант оценки трудозатрат и стоимости такой задачи?
Спасибо за вопрос, но я не веб-девелопер. Я говорил о способе, каким должна формироваться цена. Конечно, заказчик будет говорить, что "это стандартная фича", "почему на это требуется столько времени". Однако, дизайнер (да и вообще любой исполнитель) на основании собственного опыта должен настоять на своей оценке.
Поэтому я и говорю, что при недостатке опыта очень легко ошибитья и согласиться разработать "стандартную фичу" за 1 день.:)
Поэтому я и говорю, что при недостатке опыта очень легко ошибитья и согласиться разработать "стандартную фичу" за 1 день.:)
Очень порадовало решение многих проблем:
1. Забить
2. Не работать
1. Забить
2. Не работать
Все "решения" проблем, которые тут приводятся, по большей части подходят только для опытных фрилансеров.
Фрилансеры с небольшим опытом и портфолио, без отзывов, которые только начинают свою карьеру на рынке free-lance не смогут диктовать работодателю свои условия.
Поэтому они частенько работают без предоплаты на свой страх и риск.
На нашем проекте фри-ланс.ру реализован сервис "Сделка без риска". Который помогает не остаться без денег фрилансеру или без сделанной работы работодателю.
Фрилансеры с небольшим опытом и портфолио, без отзывов, которые только начинают свою карьеру на рынке free-lance не смогут диктовать работодателю свои условия.
Поэтому они частенько работают без предоплаты на свой страх и риск.
На нашем проекте фри-ланс.ру реализован сервис "Сделка без риска". Который помогает не остаться без денег фрилансеру или без сделанной работы работодателю.
Интересно, а что делать, если заказчик сам не знает толком, что ему надо и не может этого объяснить? Однозначно отказываться от проекта? Наверное да, т.к. всё равно ничего хорошего из этого не выйдет. Или всё-таки попытаться сделать проект и предложить заказчику уже готовое решение с риском потери денег?
Пытаться составить ТЗ с клиентом, с условием оплаты клиентом составления ТЗ. Если клиенту такое не подходит - лучше разойтись, либо работать на свой страх и риск (могут не заплатить, может закончится ничем проект).
Меня смущает момент оплаты клиентом составления ТЗ. ТЗ для клиента не является ценностью, соответственно, платить за ТЗ - бред.
Как же так? А как без ТЗ делать проект?:)
Клиент должен оплачивать ТЗ только в случае продолжения проекта "после ТЗ".
Почему же? Никогда не видели, чтобы клиенты заказывали ТЗ в одном месте, а реализацию в другом? Примеров - море.
Наблюдал неоднократно, только обычно все дискуссии сводились к тому, что предоставленное клиентом ТЗ не является полноценным и мы настаивали на создании нового ТЗ. Это так же как с кодом — как ни крути, а рано или поздно придется переписывать.
Вы знакомы с термином "Not Invented Here" ?
Вы про "изобретение колеса"? Каким боком это относится к теме дискуссии в разрезе ТЗ? :-)
К тому, что Вы как раз и настаиваете на изобретении колеса. Представляете, если бы допустим каждая компания, что использует в своем производстве детали сторонних разработчиков вдруг начала говорить, что им лучше с нуля эти детали у себя произвести, ведь мол "они предоставляют не полноценные детали"?
Зачем тогда пишется столько Open Source и т.д.?
Зачем тогда пишется столько Open Source и т.д.?
Изобретение колеса - это плохо?
Слишком часто за 2 части встречается "не работать с таким клиентом". Так может проще вовсе не работать фрилансером тогда? )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 проблем при работе с заказчиками. Часть2.