Пользователь
0,0
рейтинг
3 сентября 2013 в 18:39

Управление → 10 советов для заказчика во фрилансе

Работаю в IT уже более 12 лет. Думал, что без проблем справляюсь с менеджментом задач, которые отдаем во фриланс. Но последний случай буквально выбил меня из колеи: получил весьма дорогой и негативный опыт. До сих пор обдумываем с коллегами что было сделано верно, а что нет. Предлагаю вашему вниманию 10 выводов-советов, которые мы сделали для себя. Надеюсь, они будут полезны и вам. Если у вас есть что еще посоветовать, то welcome в комментарии.

Подробнее о нашем случае
Появилась надобность в копирайтере/контент-менеджере для приведения текстов в надлежащий вид и написания нескольких новых текстов. Другими словами, нужно было из сухих технических текстов сделать «продающие» и интересные. Бюджет сильно не ограничивали, чтобы получить действительно хорошее качество работы. Так же планировали с найденным копирайтором продолжить сотрудничество и после данного проекта, так как надобность в хороших текстах со знанием дела появляются у нас весьма часто.
Заявка была размещена на Фрилансим. Через некоторое время на проект откликнулся один человек, который очень рьяно взялся за работу, прислал подробную информацию о себе и тестовое задание. Это сильно отличалось от общей массы, где отклики выглядели как «Смотрите портфолио вот тут», «Возьмусь!», «Мои расценки:...» и т.п. Подход, с которым он подошел к делу, нас подкупил — и мы стали с ним работать. Человек показался весьма креативным, адекватным и достаточно надежным. Но…
Не буду здесь сильно вдаваться в детали: после каждого совета находится спойлер с деталями по нашему случаю.


1. Всегда фиксируйте «правила игры» в договоре


Отнеситесь к этому пункту со всей внимательностью! «Правила игры»/Договор — это не просто формальность. Не надо скачивать типичные договоры из интернета.
Договор должен быть выстрадан: это квинтэссенция того как именно вы хотите работать, по каким бизнес процессам и по каким правилам. Он должен включать в себя все ваши формальные договоренности с исполнителем: начиная от того где именно будет вестись список задач/замечаний и заканчивая наградами/штрафами за невыполнение в должный срок и должного качества задачи.
Не забудьте показать данный договор самому исполнителю: он обязательно что-то захочет добавить и поправить. Важно это сделать на первых этапах работы с исполнителем: если что-то в договоре вызывает большие споры, то от такого исполнителя лучше отказаться. Если он спорит сейчас, то что будет в реальной ситуации? Меняя договор под пожелания исполнителя, помните: проект ваш, платите за него тоже вы, а значит удобно работать должно быть, в первую очередь, именно вам!

Скрытый текст
Мы же не стали заключать никаких договоров. Были предложения с моей стороны как организовать работу, но они были отклонены и предложены свои варианты. Мне в начале показалось это лишь «капризами креативного человека» и я особо не придал этому внимания: соглашался со всем — лишь бы ему было удобнее работать. Даже сроки и стоимость исполнитель назвал сам. Когда проект перевалил через экватор начались первые курьезы: человек начинал спорить, говорить что такого не было (даже если присылались цитаты его же писем) и т.п. Ситуация особо накалилась когда дело дошло до денег: точнее проблем не было для первых двух траншей(из четырех). А затем… подробнее в пятом совете.


2. Пишите четкое ТЗ


Еще до публикации проекта напишите четкое ТЗ. Не надо в начале выбирать исполнителя, а потом под него писать ТЗ. Вы должны сами понимать что именно и как именно вы хотите. Если это сайт, то напишите требования к дизайну, к тексту, к структуре. Если это программа, то напишите для кого она предназначена, что именно она делает, как она выполняет то или иное действие и т.д. Если архитектор из вас «не очень», то так и пишите: «необходимо разработать структуру сайта» или «нужно придумать пользовательский интерфейс» и т.п. Вообще считаю, ТЗ для исполнителя во фрилансе это нечто между «требованиями» и «дизайном», если следовать методологии RUP.
Хочу обратить внимание, что ТЗ не должно меняться в своей главной части. В ходе проекта ТЗ может лишь уточняться. Если после общения с исполнителем, вы меняете главную часть ТЗ, то это повод задуматься, взять таймаут и если все-таки коррективы исполнителя разумны, то написать уже другое ТЗ! Не допускайте такого, что пришли с заданием на написание текстов, а в итоге вы делаете переделку всего сайта.

Скрытый текст
У нас было весьма короткое ТЗ: список статей на переделку и список статей, которые надо еще написать. Никаких требований к текстам, кроме того что они должны быть «продающими», у нас не было. Но это еще полбеды: исполнитель посмотрев наш текущий сайт на Wordpress предложил во что бы то ни стало переделать его на Drupal. Нам бы взять таймаут в тот момент, но так как аргументировал он это весьма здраво, как мне показалось на тот момент, решили согласиться с его предложением. От этого, конечно, подскочила стоимость работ, но она была принята без особых обсуждений. Размышления мои были просты: если человек на столько замотивирован проектом, если он ему так интересен, то в результате мы должны получить настоящую конфетку.
В итоге: проект из чисто контентного свалился в вечные и далеко не профессиональные «игры» с Drupal'ом. Почему именно игры? Когда человек понял «куда он попал» и что с возложенной на него самим же собой задачей он не справится, то он начал требовать по 100-200$ за такие задачи как «возможность редактировать метатеги для страниц», «возможность задать специфичный URL» и т.п.


3. Всегда проговаривайте ТЗ


Если вы гений и у вас идеальный слог, то это вовсе не означает, что ТЗ будет понято именно так как вы этого хотите. Даже если исполнитель говорит, что «все понятно» — все равно потратьте пол часа и голосом(!) проговорите все важные пункты ТЗ. Как правило, именно в диалоге всплывают все подводные камни и скользкие места. Ваша задача: убедиться, что исполнитель понимает за что именно он берет деньги.
Внимание! Все ваши устные договоренности обязательно фиксируйте: технические в самом ТЗ, а по самому процессу работы в «договоре».

Скрытый текст
Было полное ощущение, что человек за расписанными исходными задачами понял всю проблему целиком: необходим рефакторинг сайта. Как результат, доверились, не проговорив исходные задачи, а их то никто не отменял: статьи сами себя не перепишут и новые не нарисуются. Ближе к концу исполнитель начал разводить руками: «да это было в ТЗ, но я же сделал вот это» и т.п.


4. Обязательно ведите совместный список текущих задач


Работая с фрилансером, вы, по сути, работаете над единым проектом. Исполнитель должен четко представлять что в итоге должно получиться и каким именно путем мы туда придем. Для этого всегда ведите совместный список задач. И, учтите, что задачи там могут быть не только для фрилансера, но и для вас! Например: «прислать мнение по предоставленному дизайну» или «выслать имеющий контент» и т.д.
Более того, если исполнитель отказывается от ведения подобного списка: настоятельно требуйте этого.

Скрытый текст
В нашем случае исполнитель утверждал, что он все помнит и сам ведет необходимый список. Как оказалось, человек мало того что не вел подобного списка и банально их не помнил, так и при попытке начать его вести показал свою не способность работать с ним. Как? Очень просто! Начал писать в комментариях огромные 3-х томные сочинения/комментарии вместо банального обсуждения в скайпе, подменять состав задач и т.п.
К слову это все делалось в excel, так как ни google docs, ни asana.com ему не удобны из-за «обилия JavaScript'ов». Представляете себе каково это вести список задач в экселе с человеком, который не знает основ документооборота?


5. Оплачивайте по факту


Не платите авансом исполнителю, если вы с ним никогда до этого не работали. Даже если вам человек понравился и вы в нем уверены, то вы еще не видели умеет ли человек доводить проект до конца. Как известно, 20% действий дают 80% результата. А проект это не 20%, не 50%, а все 100% (ну… иногда и все 149%)! Вот и получается, что исполнитель за 20% времени делает 80% результата: требует свои 80% оплаты и вы оплачиваете. А в результате хвост в 20%, который требует уже 80% времени он ни за что не хочет делать. Доводить проект до конца надо уметь! Цените тех, кто это умеет.

Скрытый текст
Сделав за 20% времени 80% видимого результата человек запросил соответствующую оплату. На оставшихся 20% функционала начал очень сильно буксовать, а ведь именно эти «мелочи» и приводят к конечному результату. Всеми правдами и неправдами исполнитель умудрился на этом этапе выманить из меня 100% оплаты и еще 20% бонус сверху.
Заплатив 120% от той суммы, которую он же в начале назвал добавив, что «гарантированно не больше», я решил погрузиться в детали. И тут у меня волосы встали дыбом: мало того, что основные пункты из первоначального ТЗ не сделаны, так еще и содержание в 90% текста банально скопировано с предыдущего сайта.


Советы выше касаются самого этапа разработки. Но как же обезопасить себя в будущем? Вот некоторые рекомендации по выбору самого исполнителя.

6. Не пренебрегайте рецензиями от предыдущих заказчиков


Более того: если есть возможность, то свяжитесь с 2-3 лично и поговорите насчет данного исполнителя. Как правило, в рецензиях ставят 10 из 10 с отличным отзывом, а про себя ставят галочку «больше с ним не работаю!». И лишь в беседе предыдущий заказчик может раскрыться и высказать всё, что у него накопилось.

Скрытый текст
Так как заказ на поиск оставляли на Фрилансим (уж понравилась мне эта система своей простотой в отличие от freelancer.com и прочих систем с которыми работали), то рецензий как таковых не было. Также и в голову не пришло спросить контакты у самого кандидата. А зря, очень зря… Думаю с таким подходом к делу он уже успел «наследить».


7. Подробно изучите профиль на предмет несостыковок


Кесарю — кесарево, а Богу — божье. Гуманитарный по складу человек не может грамотно выполнять технические вещи. И наоборот: технарь не может написать хорошие тексты. И это касается всего: если человек 10 лет проработал дизайнером, то маловероятно, что он вам подойдет как разработчик для backend'а; если человек делает акцент на знании PL/SQL, Hadoop и т.д., то дизайнер он, скорее всего, никакой; если php кодер с 15 летним стажем делает ставку на проект по написанию промотекстов, то не берите его! Бывают исключения, но зачем вам риски?

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


8. Не останавливайтесь на первом «хорошем» варианте — рассмотрите несколько


Даже если кто-то из кандидатов на ваш проект вам сильно понравился, то все равно обязательно переговорите с несколькими фаворитами! К сожалению, никто не может похвастаться, что никогда не ошибался в людях и отлично видит всех на сквозь. Попробуйте присмотреться к нескольким: возможно у кого-то портфолио похуже, но человек вам более комфортен для работы в команде; так же за невзрачным портфолио/резюме может скрываться действительно профи своего дела!

Скрытый текст
Практически всегда придерживаюсь этого правила, но в этот раз что-то сработало не так: исполнитель был выбран практически сразу после первого общения, хотя было еще чуть более 10 откликов.


9. Устройте «тест-драйв»!


Всегда хочется посмотреть на человека в деле прежде чем начать реально работать. У вас есть два варианта:
  1. Укажите тестовое задание прямо в самой заявке на фриланс сайте. Плюс в том, что вы действительно можете посмотреть как думает и как действует человек в ваших условиях. Но есть и минус: действительно профи своего дела скорее всего не будут заморачиваться вашим заданием — у них и без этого найдется клиент. Придумывая тестовое задание выбирайте золотую середину: оно должно быть достаточно сложным, чтобы поднапрячь кандидата и заставить его думать «на вашем поле», но и должно быть достаточно простым, чтобы люди смогли решиться «инвестировать» свое время в данный проект еще на этапе подбора исполнителя.
  2. Никто вам не мешает устроить тест-драйв уже после того как вы выбрали исполнителя. Устройте ему испытательный срок: дайте реальную рабочую задачу, договоритесь об её отдельной оплате и посмотрите как человек работает, как выясняет детали, как взаимодействует с вами и т.д. Если всё устраивает — двигайтесь дальше!

Скрытый текст
Было тестовое задание — с ним исполнитель справился на ура, а так же в ходе самого проекта был эпизод, когда надо было срочно сделать одну статью: было сделано быстро и качественно. Для меня остается загадкой, почему до последнего в 90% текстах был явный копипаст исходного сайта.


10. Торгуйтесь с кандидатами!


Я за то, чтобы труд был всегда достойно оплачен. Но смысл торговаться не в том, чтобы сбить цену, а в том, чтобы вы оба с кандидатом понимали за что именно и как именно будет взиматься оплата. Если человек не может обосновать внятно запрошенную сумму, то, скорее всего, он не понимает что именно ему предстоит сделать и сколько он на это может потратить времени. Поверьте, если кто-то явно демпингует, то это либо явный новичок, либо профи, который знает как именно оптимизировать процесс чтобы себестоимость была для него минимальной: и торговля вам поможет понять структуру стоимости работ. А это, согласитесь, поможет вам и не только для данного проекта.
Скрытый текст
Как я писал выше: я абсолютно не торговался. Исполнитель сам предоставил высокоуровневую разбивку работ и стоимость.


Уважаемые фрилансеры и заказчики: с чем согласны, а с чем нет? Что могли бы добавить и что поправить?

Результат и вывод по нашему случаю
Когда человек получил 120% первоначального бюджета, он начал вести себя совсем неадекватно. Из моего любимого: "… у вас всё в порядке в мыслительном плане...?", «вы абсолютный профан в веб-разработке и управления веб-проектами» и т.п. (Свой опыт в этом деле я описал выше.) Естественно, исполнитель был послан. Спасибо Фрилансим за то, что все-таки вошли в положение и заблокировали товарища до выяснения обстоятельств: со своей стороны я предоставил необходимое. Надеюсь, что сам виновник торжества появится в этом топике и сможет пояснить свою «позицию». Я хочу верить, что люди по определению хорошие и случаются лишь «обстоятельства».

Да — мы совершили много ошибок в этом проекте, потеряли немаленькие деньги, но обрели опыт! Кому-то советы покажутся банальными и очевидными: но это не гарантирует, что вы не наступите на те же грабли! Будьте бдительны.
DbLogs @DbLogs
карма
23,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (58)

  • +14
    Как исполнитель, всегда работал без договоров и с оплатой по факту, хотя это и опаснее, но зато вызывало больше доверия у заказчиков, а кидал было видно уже после первых пяти минут обсуждения. За всё время работы кинули всего один раз, и то, кидалу удалось убедить (пусть и не совсем законными методами) оплатить заказ. За большие заказы, но без конкретного ТЗ брался только однажды, после чего зарёкся. Уж слишком много «хотелок» появляется в процессе работы. Заказчиков изучал не только по отзывам на бирже, но и искал о них информацию на других сайтах, использования в качестве поисковых запросов контактные данные.
    • –1
      Как-то фиксировали договоренности по проекту? Если да, то как? Я понимаю, что технические в ТЗ, но что насчет «процессуальных»? Возможно соглашусь, что слово «договор» в контексте данной статьи слишком «резкое» и стоит как-то переформулировать.
      • +1
        Что понимается под процессуальными? Ответственность сторон? Некоторые заказчики добавляли в ТЗ подобные пункты, например "-1% стоимости за каждый день просрочки", но зачастую все интересующие вопросы разрешались просто диалогом и закреплялись только в логах переписки, иногда выносились в ТЗ. Сроки и стоимость проекта очень редко значились в ТЗ, почти всегда они обсуждались при переписке и дальше неё не выносились. Кстати, юридически договор ведь может быть в устной форме, вот только не знаю, относился ли это к электронной переписке.

        Забыл сказать о голосовом общении (совет №3). Я довольно плохо воспринимаю информацию на слух, в том смысле, что могу услышать какой то непонятный момент, задуматься над ним, и пропустить какую-нибудь важную информацию. Поэтому я старался по максимум избегать голосовых диалогов (а тем более договорённостей), и даже если такие случались, всегда просил отразить всё сказанное в ТЗ.
        • 0
          Насчет голосового общения: полностью с вами согласен, что необходимо фиксировать устные договоренности затем в виде текста: meeting notes.

  • +9
    написаны 10 советов заказчику как снять с себя любую ответственность при работе с фрилансером
    ну и пара вопросов по советам:
    1) как технически заключать бумажный договор с фрилансером, чтобы это было просто, быстро и удобно?
    2) какие преимущества дает договор в нашем «правовом» государстве? ну выиграли вы суд через год, еще полгода исполняли его, затратив кучу ресурсов и времени — в чем профит?
    3) зачем вы пишите ТЗ, которые разные люди могут понимать по-разному?
    4) вы сами часто работаете по факту в качестве исполнителя?
    • +1
      1) Мы все часто забываем про суть «договора»: для нас это стало просто некой бумажкой используемой юрлицами. Но ведь смысл в другом: на бумаге зафиксировать все основные договоренности о том как вы будете работать. Это может быть пол страницы А4, а может и 8 листом. Главное чтобы все понимали правила игры.
      2) См. п. 1. Идеи идти в суд у нас никогда не возникало. Любой деловой человек должен банально следовать договоренностям, а чтобы их как-то сформулировать и нужен формальный договор.
      3) Вы писали ТЗ, которое всеми понимается одинаково? Как вы это проверяете?:) Голосом?;) Язык наш неоднозначен и даже UML диаграммы могут быть двояко поняты. Если все-таки умеете писать однозначные ТЗ — то научите меня этому, пожалуйста.
      4) Работал раньше — лет пять назад. Встречал и кидал и щедрых заказчиков — много повидал, так что представляю ситуацию и с другой стороны баррикад;)
      • +2
        1-2) какие задачи тогда решает ваш «договор»? при грамотном исполнителе он оказывается ненужным (есть ТЗ), при кидале он не поможет
        3) про ТЗ не скажу за всех, но лично в моей практике все как-то проще и однозначней. возможно дело в специфике моей деятельности. объяснять что-то обычно не требуется
        4) сужу по себе, но я считаю, что без предоплаты работают только самые неквалифицированные и криворукие исполнители (опять же, возможно так только в моей сфере), у которых все равно нет никаких альтернатив по клиентам. а при работе с такими все ваши 9 оставшихся советов оказываются бесполезными
        • 0
          1-2) Задача «договора» обозначить правила игры. Когда и за что оплачивается, каковы сроки и условия их соблюдения, как и где ведется разработка/деплоймент. Если подобные «правила» ведутся где-то, то как данный «договор» называете?
          3) А что за специфика деятельности? С исполнителями получается общаетесь только текстом?
          4) Согласен. Но здесь дело в доверии. Если это серьезный исполнитель, то он умеет работать, понимает как обходить скользкие моменты, как управлять объемом работ и т.д. И если вы понимаете «серьезность исполнителя» то запросто: хоть полная предоплата:) Можно сказать, что в моем случае именно так и получилось: просмотрев профиль человека, пообщавшись в почте посчитал, что это серьезный исполнитель знающий свое дело.
  • +5
    > Меняя договор под пожелания исполнителя, помните: проект ваш, платите за него тоже вы, а значит удобно работать должно быть, в первую очередь, именно вам!

    Ну-ну.
    • 0
      А что, по вашему, не верно в данном утверждении? Если исполнитель не готов работать по вашим правилам и вы с этим не happy, то может найти другого исполнителя? А если такого не находится, то это уже повод пересмотреть свой взгляд на мир: может быть слишком много хотите.
      • +3
        С этим комментарием я согласен, а с формулировкой в тексте поста — нет. Если заказчик выдвигает мне удобные для себя условия, и неудобные для меня, то я найду другого заказчика. Я не хочу быть unhappy с заказчиком, который априори возомнил себя вершиной пищевой цепочки.
        • +1
          Согласен. Должна быть win-win ситуация. В моем же случае я всячески шел на встречу исполнителю — лишь бы получить хороший результат. А в результате…
  • +5
    Подрабатываю на фрилансе, наверное, года 3. В основном заработать на интернет и телефон ну и что бы как-то разрядить рабочие будни. Т.е. пару тысяч в месяц. Т.е. мелкие задачи типа парсеров, правок и т.п. Но бывало и что то крупное.

    Так вот всегда работаю с оплатой по факту, иначе лично у меня теряется интерес к работе, напрочь.

    Кинули всего 2 раза, оба раза по 500 рублей.
    Первый раз, 16-17 летний парень из Эстонии, которому надо было поставить на хостинг одну браузерную он-лайн игру.
    Второй раз, человек из eventclick.ru, если верить их портфолио не шарашкина контора.
    Если в первом случае было даже не обидно, то во втором случае я желаю им что бы их тоже кто кинул :)

    Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день. Вот реально, если вы идёте на фриланс и ищите себе исполнителя, может быть вы сначала определитесь чего вы конкретно хотите?
    • +1
      Тоже работал раньше так, потом перешёл на 50% предоплаты. Хорошо показывает, готов ли человек сотрудничать или он чисто мозги пополоскать решил.

      > Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день.

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

      > Т.е. мелкие задачи типа парсеров, правок и т.п.
      Это неблагодарная работа, я считаю. Подчищать баги за другими.

      Если походить отвественно к выбору заданий и отсеивать большую часть заказчиков, то доход будет тот же самый или больше и времени свободного больше будет и нервов целых тоже.
      • 0
        Таких зачастую видно сразу и можно вежливо посылать их. Если вам выносят мозги на весь день, тем более за 500 рублей, значит вы что-то неправильно делаете. Повысьте планку минимальной цены за заказ, количество неадекватов убавится.

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

        Это неблагодарная работа, я считаю. Подчищать баги за другими.

        Мне это нравится, я работаю 3 года один, а работая с чужими самописами, можно чего-нибудь интересное узнать.
        Например, вот такую форму записи, в принципе банально и понятно, до сам бы я не додумался наверное до такого, что бы в 1 строчку и красиво:

        $id = max(0, isset($_POST['id']) ? (int)$_POST['id'] : 0);

        А от написания парсеров я тащусь, это можно сказать, моё хобби небольшое.

    • 0
      Ну и цены, таксист в москве за полчаса берет 500р.
      • 0
        Ну, я сам из Питера. У меня сейчас цена, которую я считаю для себя комфортной — 500 рублей в час. Но не всегда получается такие заказы находить. Уж слишком большая конкуренция из СНГ и регионов. Либо просто такая у меня ниша на фрилансе.
        • 0
          А что за ниша? Вы упомянули парсеры. Мне кажется, в сложном парсинге веб сайтов мало конкуренции, не все осиливают.
          • 0
            500 рублей в час, в принципе, норм. Просто вы написали выше «а задачку в 500 рублей могут вынести мозг на весь день». День и час это разные вещи.
            • 0
              Вот пример, что описал выше, eventclick который. Там задача была спарсить товары с сайта кондиционеров с картинками — наименований не много, в районе одной тысячи(или пару сотен, уже не помню, но не суть).
              Задача, в среднем, как понимаете, плёвая — час работы с общением, если клиент нормальный.
              Вылилось это в квест игру на 4 часа.
              Общение велось сначала на Фрилансиме, через комментарии к заказу( хотя свои контакты я всегда всем оставляю в первом же отклике). Я быстренько сделал работу, захожу ответить, а заказ выдаёт 403 ошибку(или что то похожее) — заказчик снял заказ с сайта. Я пишу в саппорт Фрилансима, объясняю суть проблемы. Они вошли в моё положение и выслали мне email с которого был зарегистрирован аккаунт заказчика(огромное им спасибо, кстати, и оперативно и помогли решить проблему).

              Дальнейшее общение уже было по этому email. В конечном итоге, я выслал результат после пары мелких замечаний, после чего заказчик хотел что бы я ещё кое-что подправил, я отказал, мотивировав это словами. «заплатите за это, а там за отдельные деньги проговорим доп. работы». Заказчик спросил кошелёк и исчез :)
              • +1
                Выберите узкий профиль по которму вы специлизируетесь, работайте в этом направлении, не ограничивайте себя только фриланс-сайтами. Ищите заказчиков и на других площадках. Сделайте себе сайт с описанием ваших услуг. Постепенно заказчики начнут к вам сами обращаться. Если хватататься за всё подряд, толку не будет.
                • 0
                  Да я не жалуюсь — уже есть круг людей у которых периодически беру заказы, просто для меня фриланс — это не полноценный вид заработка. Да и новые заказчики — это новые идеи, мысли, задачи.
          • 0
            Сложный парсинг это какой? Яндекс.Маркет, avito, auto.ru или что?

            Я обычно всегда откликаюсь на мелкие правки в php самописах, парсеры и т.п. Вот тут, по опыту, если ответил не в течении пару часов после размещения заказа, шанс что тебе хотя бы Заказчик ответил — мал. Конкуренция огромная — видимо ни я один тащусь от написания парсеров :)
            • 0
              Сложный парсинг — парсинг любого сайта с большим количеством страниц, либо объектов с большим количеством свойств, либо сайта со сложной структурой. Например, кинопоиск, амазон или те сайты, что вы озвучили.

              По парсингу со временем у меня сложились правила по которым я отсеиваю заказы:
              * я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты
              * я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент

              Эти два пункта позволяют сильно сэкономить время и нервы. Ну и ещё я не тусуюсь на сайты типа фрилансим, заказчики сами обращаются, а я уже выбираю, с кем мне интересно работать.
              • 0
                Ну кол-во страниц всё же, по моему мнению, почти не влияет на сложность парсинга. А вот свойства и сложная структура и самое интересное — защита — это да согласен. Но таких задач я не видел в свободном доступе. Только по знакомству перепала задачка Яндекс.Маркет парсить, вот это интересно было.

                * я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты

                Тут я вас понимаю, да и хороший код отдавать за 500 рублей временами обидно.

                * я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент

                В этом я с вами солидарен!
                • 0
                  Количество страниц влияет самым прямым образом. Спарсить сайт на 50к страниц и на 500к это разные задачи, и тем более на несколько миллионов страниц и больше.

                  Чем больше страниц, тем:
                  * дольше длится парсинг
                  * находится больше специальных случаев, которые вы не предусмотрели
                  * больше шансов схватить какой-нибудь бан
                  * нужно больше cpu/IOPS/ram чтобы обрабатывать и хранить данные
                  * в случае ошибки, которые случаются часто, повторно обрабатывать большее количество страниц
  • +2
    > Не платите авансом исполнителю, если вы с ним никогда до этого не работали.

    Не работайте с заказчиком без предоплаты, если вы с ним никогда не работали.

    > Торгуйтесь с кандидатами!

    Понимать, что и почему сколько стоит — без проблем. А вот если начинаются предложения вида «давайте за эту задачу не 5000 рублей, а 4500», то заказчик всеми правдами и неправдами отправляется лесом. Проблем потом не оберешься.
    • 0
      Если можете обосновать почему 5000, то супер, а если это просто «ровная красивая сумма» и видно что вы не представляете что за ней скрываете, то уже в лет такого исполнителя:)
      • 0
        Если клиент начинает торговаться, то я тоже стараюсь от него избавиться, т.к. все эти торги — это время, которое можно потратить с гораздо большей пользой, чем драка из-за 500-1000 рублей.
  • +2
    5. Оплачивайте по факту


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

    А самое главное общайтесь с человеком по скайпу голосом, так можно оценить человека, а не надежные личности часто отсеиваются на предложение побеседовать голосом.
    • 0
      Полностью согласен! Если заказчик новый — с ним ещё не было опыта работы, пусть у него будут даже афигительный рейтинг и отзывы, я как исполнитель стараюсь брать хотя бы минимальную предоплату — заказчики тоже могут кинуть. А так заказчик после предоплаты становится очень внимательным и очень доходчиво объясняет чего хочет :) А ещё большие проекты, делим на части, и после завершения оплачивается сделанная часть.

    • 0
      Не 5, а 50. Если ему не нравится, есть и другие заказчики более сговорчивые.
    • 0
      Если задачка небольшая, то можно и не брать предоплату. Не заплатит, невелика потеря.
      • 0
        Что значит не большая потеря? Скажем для меня даже потраченный час большая потеря, если там минут 10 то возможно и не так жалко. Хотя если задача интересная и результат потом можно будет использовать еще как-то или где-то, то можно и сделать исключение.
  • +3
    №10. Торгуйтесь с кандидатами!
    Очень ИМХО, но — никогда не торгуюсь. У меня обычно есть два варианта.
    Либо заказчик называет цифру которую он готов платить и я соглашаюсь, или нет.
    Либо я называю свою цену — после этого заказчик говорит согласен он работать, или нет.

    Если со стороны заказчика начинается торг — я обычно отказываюсь от такого проекта.

    Да еще один момент. Сразу оговаривается то, что в случае дополнительных работ (например в ТЗ что-то не указали, или имели ввиду одно, а написали другое, и т.п.) они оцениваются отдельно. А в случае возникновения багов, или недоработок — исправления вносятся за мой счет.

    Это еще раз повторюсь жуткое ИМХО, но как показала практика — очень способствует правильной фильтрации проектов и благополучному сотрудничеству в дальнейшем.
    • +4
      Напомнило мне короткий диалог с одним из зарубежных заказчиков на крупный проект.

      — Как насчет 25% скидки? Мы считаем, что она обоснована, так как проект крупный и тебе привалит куча бабла
      — Отличная идея! И у меня есть контр-предложение: я делаю функционала меньше на 30%, потому что, считаю, что вы им никогда не воспользуетесь.

      Как только я вижу людей, которые пришли покупать Феррари по цене старых Жигулей — бегу сразу. Вменяемые говорят просто: «Дорого, я пошел в другое место!» или «Начинаем работать!».

      Насчет ТЗ у меня все просто: нет ТЗ — работаем на почасовой ставке. «Сделать как там» я не понимаю, поэтому все равно почасовка. «Сделай мне Фейсбук, там работы на неделю, знаю», выкатываю расчеты на миллиарды долларов с обоснованием почему так. Товарищей, которые говорят, «Хорошо, почасовка, только ты закончишь это за неделю» вношу в личный черный список.
  • +3
    вы абсолютный профан в веб-разработке и управления веб-проектами


    Поскольку мне повезло лично работать с DbLogs в одном проекте, могу заверить, что он исключительно грамотный и опытный профессионал. В том числе и в озвученных вопросах.
  • +2
    Многих описанных автором статьи проблем можно было избежать, если бы использовался не традиционный «водопад» с написанием подробнейшего ТЗ до начала разработки, а что-то более гибкое (Agile).

    Я бы предложил скрам-процесс, так как в нем есть итерации. Итак, создаётся список задач (бэклог, backlog), который сортируется по важности — важное сверху. Для этого можно использовать разные инструменты начиная с канбан-досок типа trello.com и заканчивая Jira + GreenHopper. Каждая задача должна иметь критерии готовности. Если все критерии выполняются, то задача считается выполненной. Исполнитель даёт оценку (это может быть время или деньги) каждой задаче. Если он не может оценить — значит задача не ясна (нужно встретится и обсудить), либо слишком большая, — разбивать на части.

    Спринты. Я бы предложил использовать одно-недельные спринты, чтобы сохранить динамику. В конце спринта — демо, где разработчик показывает что сделано, а заказчик принимает. Показывается только то, что работает на 100%. Если не работает или на демо вылезли ошибки — на переделку.
    Оплачиваются только принятые заказчиком задачи. Оплата сразу после демо. Таким образом, для испольнителя — отработал спринт, сдал работу, получил оплату.

    Заказчик во время спринта готовит задачи для следующего спринта, то есть на 1 неделю вперёд. Часть незавершённых задач переедет в след. принт или будет отложена, если это не важные задачи. Помните, что нужно начинать с важного, — таким образом можно избежать того, что вы потратите 80% бюджета на 20% видимой работы.

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

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

    По-поводу метатегов и URL в Drupal по $200, то вас просто хотели обмануть. Это решается установкой бесплатных модулей. Даже настраивать ничего не нужно. Советую вникать в предметную область, иначе всегда будете переплачивать. Никто не запрещает задать вопросы на drupal.ru или drupal.ua.
    • –1
      Владислав, все верно пишите. Но есть определенные проблемы:
      1) Исполнитель должен согласиться на работу по agile. Не все знают и умеют работать по agile.
      2) Сразу подразумевается почасовая оплата, а не фиксед. Не всегда это приемлемо.
      3) Agile и почасовая оплата требует доверия: если исполнитель говорит, что сделает это за час, то вы ему должны верить.
      Все данные пункты у меня не работали… Ну вот как можно поверить, что развернуть дамп на сервере стоит 2 часа рабочего времени(я сам разворачивал его дампы за 10 мин максимум)?:) А ведь были именно такие утверждения.
      • +2
        Agile != почасовая оплата. Мало того, почасовая оплата не имеет вообще никакого отношения к Agile, хотя многие считают, что если у них почасовка, то это аджайл — увы это не так. У вас agile-процесс, если выполняются 4 условия, которые описаны в Agile-манифесте (http://agilemanifesto.org/iso/ru/). Обратите внимание, там нет ни слова про скрам, про канбан, про инструменты, про почасовую оплату!

        Исполнитель действительно должен согласиться работать по такой схеме. Но мне кажется, что закачик имеет право именно диктовать условия, поэтому не стоит себя ограничивать. Вы же не требуете от него пройти курсы скрам-мастеров за 1000 долларов?! От исполнителя требуется сдавать работу в конце спринта и согласиться на то, что оплачено будет только то, что сделано и работает на 100%.

        Да! Важный момент — он исполнителя требуется выполнять работу в порядке приоритетов выставленных заказчиком — это ключевой момент, который защищает заказчика от выполнения простой и незначительной работы в начале и сложного в конце. Откладывание сложного на конец проекта грозит срывом сроков и исполнитель может просто свалить, чтобы не возиться со сложным. Поэтому начинать нужно с самых главных «килллер»-фич проекта, а менее важное откладывать на конец. Таким образом, учитывая, что проекты почти всегда завершаются не вовремя, то к запланированному вами сроку у вас будет 1-2-3 важных фичи проекта и можно будет уже стартовать, походу доделывая второстепенные детали. Помните, что лучше раньше выйти на рынок с сырым продуктом, чем вылизать весь код, дизайн, архитектуру и опоздать с выходом.

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

        Чтобы понять как это делается нужно помнить, что у любой задачи есть 4 параметра:
        1. Срок (время) — оценку даёт исполнитель и затем обсуждает с заказчиком. Торг уместен!..
        2. Объем работы (мы фиксируем объем работы, давая четкие критерии готовности задачи).
        3. Стоимость (деньги) — часто зависит от времени, но не обязательно — могут быть задачи с фиксированной ценой. Исполнитель может давать оценку задачи и в деньгах, что тоже позже обсуждается с заказчиком.
        4. Качество. Тут все очень сложно, но в agile подразумевается наивысшее качество и поэтому обычно даже не обсуждается. То есть, если нужно покрытие проекта тестами (а эта фича не имеет никакой бизнес-стоимости в глазах заказчика), то это делается по-умолчанию. Кроме того, никто не запрещает зафиксировать требования к качеству в критериях готовности.

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

        По поводу дампов — это технические задачи и вам, как заказчику не нужно их оплачивать и даже их обсуждать. Вам нужно платить за бизнес-фичи. Как только эта работа перестанет отдельно оплачиваться, — исполнитель найдёт способ сделать это быстрее. У меня дампы на 1.5 гига действительно разворачиваются минут 30.
        • +2
          А вы не могли бы описать ваше понимание дампов, заранее спасибо.
        • –1
          Со всем согласен, но опять есть «но»:) Вы сами пишете, что оценивается каждая задача в отдельности. И это не так уж важно: оценивается в часах (а потом конвертируется в деньги), либо сразу в деньгах. Но для мелких и средних задач (до 100 m/d) хочется видеть стоимость сразу: не занимаясь декомпозицией на подзадачи. Да и как показала практика: путем дробления задачи можно устремить стоимость проекта далеко к небесам.
          • +2
            Ну так дробите без фанатизма. По тем же дампам из вашего примера — это вообще не задача, вернее часть другой задачи но никак не самостоятельная (если это не база процессинга на терабайты данных с кучей нюансов).
            Понятно что можно написать задачи:
            1) Захожу на сервер по ssh — 20 центов
            2) Заворачиваю базу в дамп — 1$ (1цент — таблица)
            3) Переношу дамп на новый сервер…

            но это согласитесь дебилизм.

            Задача должна обладать S.M.A.R.T. критериями, тогда и раздувать не выйдет.
            • +1
              Согласен с RicoX. Про S.M.A.R.T. забыл упомянуть. Задача должна быть самостоятельной фичей проекта, которая имеет для заказчика какую-то бизнес-ценность. Например, рефакторинг кода такой ценности не имеет, а значит о быть отдельной задачей не должен. Но иногда это может быть часть реализации новой фичи или улучшения, потому что иначе реализовать не получится — старый код ограничивает. В этом случае рефакторинг должен учесть разрабочик, когда оценивает задачу — это его ответственность, но лучше это проговорить в самом начале, потому что для многих это будет неочевидно.

              У меня дамп — это дамп базы данных, который я беру с продакшена для разработки, чтобы всегда работать с данными максимально близкими к боевым. Там очень-очень много контента, около 650 таблиц, вес примерно 1.5 гига. Часть контента я удаляю, чтобы уменьшить размер — вот этот процесс и занимает около 30 минут. А импорт подготовленного дампа — пара минут, наверное, — не засекал, потому что это делает скрипт пока я задание читаю…
  • +1
    Работаю в IT уже более 12 лет.

    Кем Вы работаете?
    • +1
      В карьере ничего удивительного: разработчик, тимлид, архитектор решения, проектный менеджер:) Последние 2 роли совмещаю и по сей день — хотя иногда приходится и покодить основательно.
  • +2
    По большинству пунктов соглашусь, кроме пожалуй 10.
    Когда со мной, как с исполнителем начинают торговаться, я сразу прикидываю какую часть из своей работы мне придется выкинуть, чтоб мне заказ оставался интересным, потом понимаю что если выкинуть нужную часть, у проекта будут проблемы в дальнейшем и отказываюсь. По опыту самые «геморройные» проекты были те, где заказчики активно торговались, зарекся по таким работать. Назначая цену на fixed price, я, как исполнитель, в уме прикидываю сколько часов я на это потрачу +20% времени на нестыковки типа: забыли пароль от сервера, а админ помер. Снижать цену — это снижать свой рейт, а зачем если хватает тех, кто работает по такому, как я назвал.
    По 5 пункту вопрос спорный, от продолжительности проекта зависит, если на пару дней, то можно и по факту сдачи оплату брать, а если на пару месяцев фултайма, тут только дробить на отдельные части и по ним производить расчет. В любом случае нужны четкие критерии сдачи-принятия работы или ее части.
    • 0
      Насчет 10 пункта, пожалуй, соглашусь. Попробую переформулировать в самой статье, но суть 10 пункта в том, чтобы обе стороны понимали структуру того что надо сделать и саму структуру оплаты.
      Кстати, интересный момент: в мое случае под конец уже сам исполнитель начал торговаться «вот это +100$», и т.п. (Причем за вещи, которые обговаривались в самом начале). Но суть не совсем в этом, а в том, что я понял, что если раньше я прикидывал бонус исполнителю, если все будет хорошо и т.п., а его «торгашество» обозлило меня и тут уже я сам пошел на принцип. Так что согласен: «торговаться» подчас не стоит.
      Касательно пятого пункта: сам исполнитель сказал, что через 3 недели будет все готово — прошло уже 3 месяца. Транши в начале платил исправно каждую неделю.
      • +1
        В этом случае политика исполнителя скорее была направлена не на то чтоб сделать проект, а на то чтоб поругаться с вами и уйти обиженным, хлопнув дверью и просто не доделывать тот фронт работ, что он взвалил на себя. При таком перерасходе времени видно что исполнитель не компетентен в той работе, за которую взялся, при оценке небольшого проекта можно ошибиться в 2 раза (хотя на сроке 3 недели это должен быть конкретный форс-мажор), но не более того. Однозначно нужно прощаться.
      • 0
        Да, как заказчик, торгующегося исполнителя тоже шлю лесом.
  • 0
    С большим удовольствием прочел вашу статью. Когда стал писать комментарий, понял, что он вырастает в отдельный пост.
    Довел до ума и разместил вот тут: habrahabr.ru/post/192502/. Буду рад если удостоите вниманием.

  • +2
    Хорошие советы, если бы не пункт 10. Т.е. вы хотите себя максимально обезопасить и это нормально. Но работать с вами становится сложнее и дороже. Поэтому если вы готовы за проект заплатить 2-3 стандартные суммы, то нет проблем. А если вы хотите навесить все свои пункты за обычную оплату, а потом еще и поторговаться, то… хороших специалистов вы не привлечете — у них и так работы много. А найдете скорее всего голодного студент а готового на все лишь бы получить проект, но проблем в итоге вы получите еще больше.
    • –1
      Обоснуйте, пожалуйста, почему «сложнее и дороже»? Разве четкость в ТЗ и четкость во взаимоотношениях приводит к этой сложности и дороговизне? Имхо, в среднем, как раз экономит, так как позволяет спорные ситуации решать очень быстро.
      • +1
        Чёткость, да. Но как вы и сами написали, даже самое чёткое ТЗ может быть понято как угодно. Значит, у вас будет обсуждение каждого пункта каждой задачи в проекте. Причём не только перед выполнением, но и в процессе, и даже по окончании.

        Проект или задача стоит X денег и требует Y часов времени.

        Обсуждение ТЗ с исполнителем это тоже время и работа над проектом, переписка, скайп, общение по телефону — это всё, по хорошему, тоже должно оплачиваться, то есть в калькуляции должна быть строка типа «Обсуждение и уточнение задачи», если её там нет, то либо исполнитель уже заложил это в рейт (x2, x3, т.к. обсуждение может быть очень долгим), либо будет настаивать на пересмотре стоимости.

        Ещё проще: За ваши деньги — любой каприз, но каждый дополнительный каприз или хотелка это дополнительные деньги.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        1) Найти компетентного специалиста в нужной области знаний на разовый проект.
        2) Найти нужного спеца в регионы, не все заказчики в столицах.
        3) Быстро найти исполнителя.
  • 0
    В подавляющем большинстве случаев моральную ответственность за проект несет именно заказчик. Он должен проявлять дотошность в выборе исполнителя. Это ЕГО проект и он кровно в нем заинтересован! И никто более. Для исполнителя, в случае его чистоплотности — это всегда будет только работой и не более того, а риски — как временные так и финансовые несет заказчик. Вернуть потом затраченные финансы с исполнителя крайне проблематично.

    Тут про подобное, но в другом разрезе событий http://habrahabr.ru/post/179731/

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