Pull to refresh

Типичные ошибки «опытного заказчика» во фрилансе

Reading time 4 min
Views 128K
Я, как человек более 7 лет проработавший фрилансером, и выросший из фрилансера в небольшую IT компанию из 10 человек. Не мог пройти мимо весьма познавательной статьи: 10 советов для заказчика во фрилансе.

И с позволения, написал свой ответ, так сказать, Чемберлену. С точки зрения фрилансера.


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

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

Очень верно сказано про договор. Как правило, там содержатся либо откровенно глупые, либо откровенно кабальные условия. Типичные проблемы договоров от заказчика:

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

2а. сроки в договорах всего оговорены одним куском: 50 дней. Не больше, не меньше. А то, что у нас в середине два согласования эскиза, на которых минимум по неделе заказник будет думать, и играться с размерами шрифтов не учитывается. В результате, согласие на такой договор может обернуться тем, что заказчик нарочно задерживает фидбек, а штрафы капают исполнителю.

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

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

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

Да пункт описано идеально. Все бы так!

На практике я никогда не встречал за 7 лет, ни одного ТЗ от заказчика написанного так, чтобы это не допускало появления дополнительных «хотелок», которые мы не оценивали. Всегда много воды, мало конкретики. Куча не освещенных участков. Да еще выражения типа «личный кабинет пользователя, как на сайте www.mail.ru». Это как? И с личной почтой тоже? Если вы не такой – три раза пожму вам руку.

П.с. Обычно мы сами полностью с нуля, еще до начала работы пишем детальное ТЗ, по мотивам той писанины, что прислал заказчик. Это единственный кроме agile выход избежать лишней работы. Конечно, речь о проектах до 100 человеко- дней. Свыше – только agile.

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

Абсолютно пустой пункт. Даже вредный. Всякие коммуникации голосом – это всегда наполовину пустопорожний базар «ниочем». Тоже касается асек и скайпов. Только электронная почта.

Прямо в ТЗ спорные моменты отмечаются комментариями и вопросами и обсуждаются во вдумчивой переписке.

UPDATE: Под напором критики в комментариях, вынужден признать, что первичное устное обсуждение проекта НЕОБХОДИМО. А далее уже пишем ТЗ и по переписке согласовываем все неточности. И вот тут я буду стоять до конца: обсуждать каждый возникший вопрос устно, или по чатам — это преступление, убийство драгоценного времени своего и клиента.

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

Да! Жму руку.

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

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

Поэтому, идеальная схема работы, например по сайту: 30% аванс, 30% после принятия эскиза и 40% в самом конце.
Максимум 30% аванс, 70% в конце. Остальное, пардон, пахнет откровенным неуважением или даже кидаловом.

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

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

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

Три раза да. Я еще всегда люблю говорить: «нанимай долго, увольняй быстро».

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

А вот на этом, обычно отношения заканчиваются.

На этапе тендера делать что либо – это на 99% пустая затея. Никогда еще себя не оправдывало. Ни разу. Даже если выиграешь такой тендер, заказчик изначально начинает относиться к твоему труду без уважения, ведь ты же работал бесплатно. Никогда такие отношения не будут взаимовыгодными. Классическая игра в одни ворота, в которой никогда не следует принимать участие, только если с голоду не умираешь.

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

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

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

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

Торговаться, конечно, можно, но из практики, это сильно влияет на мотивацию. Выиграете 20%, получите кучу мелочей сделанных по принципу: «забастовка по-итальянски». Став заказчиком, я наоборот практикую небольшие премии за «в срок и качественно» сделанный проект. Работает хорошо.

Резюме.

Резюме простое. Следуя строго указанным правилам, вы найдете исполнительного дурачка. Хороший специалист, уважающий свой труд, с рядом озвученных условий не согласится.
Tags:
Hubs:
+115
Comments 108
Comments Comments 108

Articles