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

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

Самое начало

Через 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 сервера