Как мы учились работать с фрилансерами

Как мы учились работать с фрилансерами

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

Самое начало

Через 2 месяца после появления идеи базовые ТЗ были написаны, и нам предстояло реализовать несколько крупных блоков: десктопное приложение, сайт и общий дизайн. Соответственно, три проекта были размещены на фрилансе. Предложения поступали по всем проектам, но цены разнились от несколько сот долларов до нескольких десятков тысяч. Мы рассчитывали потратить не более 1-2 тысячи долларов за все, поэтому дорогие предложения даже не изучали.

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

Все сделают без нас

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

Сроки «слегка» отодвигаются

Сроки были сорваны конкретно. К моменту, когда мы планировали иметь альфу, у нас не было ничего, включая девелоперов. Единственное, что у нас было — это понимание того, что менеджерами, кроме нас, никто выступить не сможет. Это была первая шишка, которая стоила нам 3 месяцев.

Как мы выбирали людей

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

Обычно это происходило так: на связь выходит какой-то исполнитель, говорит, что понял ТЗ и готов работать. Мы отсылаем, что у нас есть, и ждем результатов. Через неделю спрашиваем состояние дел и узнаем, что работа ведется, но показать пока возможности нет. Ждем еще неделю, пишем снова.
Тут обычно происходило невероятное: у девелоперов горят компы, летят диски, они попадают в больницы, теряются телефоны, косячит провайдер и т.д. Поначалу я искренне в это верил и даже переживал за них, особенно, когда мне рассказывали истории об автомобильных авариях и сотрясениях, несовместимых с кодингом. Только через 5-6 таких “аварий” я понял, что все это липа, и хотя бы перестал нервничать и ожидать результатов после “выхода из больницы”.

Примерно в таком режиме у нас прошло все лето 2009 года, когда один нерадивый фрилансер сменялся другим. С нами «поработало» около 20-30 человек! По закону больших чисел, за 3-4 месяца мы все-таки как-то продвинулись: через полгода приложение имело внешнюю оболочку и умело связываться с сервером, обеспечивая какой-то минимальный жизненный цикл задания: размещение, чат, подтверждение. То есть программа что-то умела делать, но даже альфой ее назвать было нельзя.
История, как из этого сырого материала у нас вылезла первая версия будет рассказана отдельно, потому что до ума мы уже доводили ее сами.

Как быть с предоплатой

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

Ошибки кратко:

— надежда, что кто-то все сделает без твоего контроля
— отсутствие отбора/тестирования кандидатов
— отсутствие дедлайнов
— доверчивость к различным “авариям”

Как мы набираем сейчас

Цена

Цена должна устраивать обе стороны с самого начала. Нормальной работы не получится, если вы готовы платить 15 д/ч, а девелопер хочет 20д/ч. Даже если вы сторгуетесь, ничего хорошего все равно не вырастет. Один будет считать, что ему недоплачивают, а другой — что переплачивает. Оптимальная цена определяется только опытным путем и приходит с пониманием того, какого уровня специалисты вам нужны.

Резюме

Мы всегда требуем резюме на этапе отбора, чтобы просто получить краткую справку о человеке и не тратить на это время разговора. При этом особенных требований к резюме нет, нужна простая справочная информация. У вас могут быть некоторые критерии по опыту, по часовому поясу… Эти критерии легко проверяются именно на этапе просмотра резюме.

Устная беседа

Как мы учились работать с фрилансерами
(Прошел интервью по скайпу — Штаны надевать не пришлось)

После просмотра резюме и обсуждения цены я перехожу к устной беседе. Задача этого этапа — проверить адекватность и понять, насколько тебе приятно общаться с человеком. Тут же обсуждаются административные вопросы, связанные с рабочим расписанием, способом оплаты…

Тестирование

Если беседа прошла успешно, мы переходим к этапу тестирования. На этом этапе участвует технический специалист, который дает задачу в Google docs и просит ее решить в прямом эфире. Задачи даются достаточно простые, потому что ясно, что стресса и так хватает.
Когда я искал менеджера, я составил некоторые схожие с реальной работой задачи и просил прислать решения.
Это супер-обязательный этап, без него никуда.

Тестовый период

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

Odesk

Сейчас мы работаем только через Odesk и там же ищем сотрудников. Работа через клиент Odesk явно обговаривается в самом начале диалога.
Если кто не знает, клиент Odesk позволяет отслеживать работу сотрудника. Каждные 10 минут он спрашивает, чем ты занимаешься, и делает скриншоты. Если ты занят личными делами, можешь отказаться делать скришот, но тогда эти 10 минут не будут учтены как рабочие.
Это устраняет главную, на мой взгляд проблему фриланса: работник думает, что работает много, а получает мало, а заказчик — наоборот. Odesk четко показывает объем выполненной работы. Плюс Odesk делает денежные переводы исполнителю каждую неделю, что минимизирует риски для работников.

Не нравится — не стоит начинать

Со временем я понял, что если что-то в сотруднике не нравится, не стоит с ним начинать работать. Что-то вроде внутреннего чутья, когда ты чувствуешь, что что-то есть, но четко сформулировать это не можешь. Раньше я не обращал на это внимания, и все выливалось в потери времени. Сейчас, если у меня есть есть какие-то подозрения, я не начинаю сотрудничество. С сотрудниками общаешься довольно много и нужно быть уверенным, что общение будет приятным.

Только полный рабочий день

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

PS

Этим постом мы продолжаем серию публикаций, где хотим поделиться опытом, накопленным при создании и работе над проектом WORKZILLA.RU. Предыдущие статьи:
Как придумать идею для своего проекта
Как мы хостинг выбирали

Мы не претендуем на всезнайство и вселенскую гениальность, а хотим рассказать о своих ошибках и находках — кому-то они могут быть полезны.

Примерный список будущих нетехнических статей:
— Запуск первой версии
— Поиск первых пользователей
— С какими трудностями мы столкнулись
— Удаленная работа команды

Примерный список будущих технических статей:
— Подготовка к массовой рекламной компании с JMeter
— DR — как мы решаем проблему форс-мажора.
— Подробнее о бекапах
— Мониторинг сервиса с Munin, Nagios и прочее
— Проблема выбора надежного SMTP сервера

Автор: petrzilla

Источник

Оставить комментарий