{"id":13836,"url":"\/distributions\/13836\/click?bit=1&hash=b61ea41d40ef5596d91409ad89303e69391b638d48696dedc08253272b41c2c3","title":"\u041a\u0430\u043a \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u043d\u0430 \u0441\u0432\u043e\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u0430\u043d\u0430\u043b\u043e\u0433\u0438 Google Workspace \u0438 Slack","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"728ad728-b270-5f6e-aa5a-d8a9339fb1b2","isPaidAndBannersEnabled":false}

Как эффективно работать с удаленными разработчиками — опыт Skyeng Статьи редакции

Директор по продукту онлайн-школы Skyeng Харитон Матвеев написал для vc.ru колонку о том, как организовать удаленную работу с разработчиками: плюсы, проблемы, особенности и рекомендации.

офис Skyeng в Москве

Когда мы создавали школу Skyeng, наши консультанты, известные московские тим-лиды, активно отговаривали нас от идеи выстраивать работу на удаленке. Рынок считает, что эффективно поставить процесс удаленной работы, особенно если речь идет о продуктовых компаниях, невозможно.

Эти рекомендации нас настораживали, но не заставили сбиться с пути. И сейчас мы можем утверждать, что наша школа своим существованием де-факто показывает, что удаленная разработка даже больших технологических решений вполне реальна. Сегодня мы расскажем об общих принципах ее организации.

Зачем нужна удаленка

Очевидное преимущество — экономия расходов на содержание офиса — не главное. Главное — это возможность выбора среди большего числа претендентов: закон больших чисел в действии. Когда мы работали в минском офисе, мы должны были искать разработчиков среди миллиона жителей города. В Москве у нас уже был выбор в десять раз больше. С удаленкой мы имеем поле в 200 миллионов человек — весь СНГ к нашим услугам. Таким образом, шанс найти идеального работника заметно повышается.

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

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

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

Особенности поиска сотрудников

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

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

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

Проблема коммуникации

В любой коллективной работе, что в офисе, что на удаленке, система коммуникаций между сотрудниками играет важнейшую роль. В более-менее значительном коллективе коммуникации съедают бóльшую часть фонда зарплаты.

Объясним на простом примере. Есть программист Вася, он ИП, пишет программы в одиночку. Производительность его труда мы примем за условную единицу. Бизнес у Васи идет в гору, он решает нанять второго программиста, теперь они работают вдвоем. Однако суммарная производительность их труда вовсе не превращается в двойку, она оказывается на уровне от 1,5 до 1,8 единиц производительности одинокого Васи. Все остальное время тратится на коммуникации между двумя программистами.

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

Люди тратят около 70% своего рабочего времени на общение и лишь 30% — собственно на производительную деятельность. И это вовсе не катастрофа — это нормальная работа, но соотношение наглядно показывает важность выстраивания эффективной системы коммуникации между сотрудниками. Потому что если коммуникации просядут всего на 10%, то производительность труда обрушится в полтора раза; напротив, незначительное повышение эффективности общения приведет к заметному ускорению работы.

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

Поэтому эффективная разработка — это в первую очередь эффективная система коммуникаций.

Что нужно сделать:

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

Каналы коммуникации

Мы выделяем три вида общения.

1. Документация

К документации относятся большие тексты в нашей базе знаний Confluence, а также тикеты, логи, дашборды в JIRA. Для документации характерны большие объемы информации и практически полное отсутствие интерактива.

Это своего рода театр одного актера: как правило, один человек наполняет канал данными, остальные участники читают (и своевременно получают уведомления об изменениях). В идеале коммуникации должны максимально мигрировать в документацию: чем полнее все описано в Confluence или в тикете JIRA, тем меньше времени будет тратиться на обсуждение деталей в чате.

2. Переписка и чаты

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

3. Голосовая и видеосвязь

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

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

Сила прерываний

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

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

  • Очевидно, что если надо что-то сделать «Срочно, прямо сейчас» (проще говоря, что-то пошло не так) — необходимо донести эту информацию мгновенно. Это прерывание с самым высоким приоритетом, и для него используется телефон.
  • Slack — прерывания со средним приоритетом. У нас скорость ответа на сообщения в Slack — один час. Это означает, что у адресата появилась нотификация о новой коммуникации, однако ему не нужно все срочно бросать и узнавать, что от него кто-то хочет — он может доделать то, чем сейчас занят, а затем посвятить несколько минут общению.
  • Электронная почта — еще более низкий приоритет, скорость ответа — сутки. Как правило, мы выделяем полчаса-час рабочего времени на ежедневный разбор почты, все остальное время она работает информационным буфером. К этому же приоритету относятся изменения в документации — сообщения об них также приходят на почту.

Мотивация

Если в оффлайне всяческие мотивационные мероприятия («тим-билдинги») зачастую представляют собой бессмысленные и унылые посиделки с единственной целью оправдать зарплату HR-директора, в удаленной работе они необходимы. Поскольку сотрудники физически находятся далеко друг от друга, нужно использовать дополнительные инструменты для поддержки их ощущения команды. Причем они тем важнее, чем лучше оптимизирована рабочая коммуникация (поскольку она не оставляет места для личного общения).

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

Однако мотивационные задачи значительно эффективнее решаются личным общением и Skype. Мы проводим встречи в московском офисе, регулярно организуем Skype-конференции с сотрудниками. Хотя подобные мероприятия имеют формальный информационный повод (обсуждаются рабочие вопросы), их основная цель — использование эмоций как инструмента для повышения эффективности работы. Похвалить, поругать, поставить в пример — все это работает значительно лучше, когда люди видят друг друга, пусть и на экране ноутбука.

Удаленка эффективнее офисной работы?Мы считаем, что да.

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

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

Еще одно очень важное преимущество работы в онлайне — неизбежное документирование всех коммуникаций. Если мы в Slack о чем-то договорились, нам достаточно «копи-пейстом» скопировать абзац текста в тикет JIRA. Если нам надо рассказать об этом кому-то еще — мы просто копируем текст и отправляем нужному адресату. Мы всегда уверены, что информация доходит быстро и без искажений, неизбежных при устных пересказах.

Если грамотно подобрать инструменты и настроить коммуникацию, она будет отнимать значительно меньше времени, чем при работе в офисе. А следовательно, вырастет эффективность и производительность труда.

Мы расскажем подробнее про использование таких инструментов, как Slack, JIRA и Confluence в удаленной работе в следующих статьях, а пока предлагаем небольшой (и довольно хаотичный) чек-лист вещей, на которые стоит обратить внимание, выстраивая коммуникации удаленной работы.

Чек-лист эффективной коммуникации

  • На удаленке люди друг друга не видят, это создает ощущение изоляции. Поэтому, как бы нелепо это ни выглядело, нужно, чтобы у всех в Slack, Jira и Confluence были аватарки. Они «очеловечивают» общение, делают его более личным. И еще мы активно поощряем использование «реакций» (что-то типа эмотиконов).
  • По той же причине во время звонков и конференций по Skype мы всегда используем камеры. Причем подходим к этому достаточно серьезно — например, следим за светом, чтобы лицо не оказывалось в тени.
  • Не забываем приветствовать в общем канале Slack всех новых сотрудников. Им приятно, а коллеги в курсе, кто это. И поздравляем с днем рождения — это лучше делать в Skype.
  • В удаленной разработке важна прозрачность — надо знать, кто чем занят: вчера, сегодня, завтра. Поэтому необходимо потратить время на настройку дашбордов в JIRA.
  • Важна грамотная организация и навигация по документам, иначе в них нет смысла. Например, конвенции для программистов должны быть внятно структурированы, чтобы новый сотрудник без труда нашел все, что ему нужно, а не читал все подряд.
  • В Slack у нас есть множество каналов, покрывающих разные области работы. Важно, чтобы сотрудники научились писать в нужные каналы — этот навык приходит не сразу. Он похож на раздельный сбор мусора — сперва непривычно и неудобно, но понемногу все привыкают.
  • Добавлять в каналы надо только нужных людей, а не всех, кому «интересно». Это избавляет от лишних прерываний.
  • Необходимо, чтобы сотрудники научились пользоваться инструментом «Наблюдатели» (Watchers). Каждый человек, создавая и редактируя документ, должен понимать, кому этот документ нужен. Если человек подписан на что-то, он получает уведомления об изменениях. Необходимо прививать эту культуру — чтобы нужные люди сами следили за нужными вещами, иначе они не знают, что где происходит, у них начинают различаться картины мира, начинаются проблемы, а решать недопонимание — очень и очень дорого.
  • Очень полезен инструмент упоминания кого-либо в сообщении (@), он присутствует во всех системах. У упомянутого сотрудника он повысит приоритет сообщения; он ответит в том канале, где он был упомянут, и все, кому нужно, увидят эту переписку. Если писать в личку — придется потом не забыть все скопировать.
  • Наконец, надо не забывать копировать переписку в тикет JIRA. Обсудили, нашли решение, копи-пейст, теперь в курсе все, кому это нужно. Никому не придется ничего дополнительно объяснять, никаких мискомуникаций не случится. То же касается и апдейтов документации в Confluence по итогам переговоров.
0
66 комментариев
Написать комментарий...
Slog.me

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

Ответить
Развернуть ветку
Khariton Matveev

У нас работает отлично. Разрешите дать некоторые советы по тем проблемам, о которых вы написали:

Невозможно контролировать результат и процесс

Результат конкретной фичи — пул реквест, другой разработчик или CTO смотрит код и его качество, менеджер открывает ветку с кодом на тестовой машине и смотрит, доволен ли он новой функцией.

Не ясны сроки

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

программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделано

Ну это говорит о плохом менеджементе, как мне кажется. Мы режем крупные задачи на подзадачи, оцениваем их, менеджер в реальном времени на дашборде в JIRA видит, какие задачи сделаны, а какие нет, разработчик логируя время актуализирует Remaining time (сколько осталось времени до конца) — таким образом менеджер всегда в курсе, на сколько сделана задача, увеличились ли сроки и если да, то почему.

Ответить
Развернуть ветку
3 комментария
Константин Нелюбин

Это вопрос периодичности и неизбежности контроля. Достаточно в понедельник обозначать цели на неделю, а потом контролировать их выполнение.
+ общая цель на месяц и 2 раза в месяц обязательный созвон для подведения итогов.
+ задачи в Jira - и у вас всё как на ладони.
Если выстроена нормальная мотивация, то и тянуть никто не будет.

Ответить
Развернуть ветку
1 комментарий
Игорь Елисеев

Коллеги, есть очень простое решение для контроля:
ежедневное код ревью (обязательные коммиты по итогам дня) и, главное - ежедневные письменные отчеты о проделанной работе в свободной форме (делал это, не получилось потому что вот такая проблема возникла, вот это пошло не так и т.д.).
Нет отчета по итогам дня - рабочий день не учитывается при расчете зп. Уже через неделю можно понять, кто эффективно работает, а кто время транжирит.

Ответить
Развернуть ветку
2 комментария
Максим Котов

чтобы не тянули до конца, нужно принимать работу ежедневно
по-другому никак, и это не зависит от удаленки / не удаленки

Ответить
Развернуть ветку
Андрей Панченко

Молодцы ребята, че уж там.

Ответить
Развернуть ветку
Khariton Matveev

Большое спасибо, мы стараемся :-)

Ответить
Развернуть ветку
slugge
у нас есть канал Inspiration, в котором мы рассказываем сотрудникам о наших успеха

корпоративный bullshit перевели теперь на прямую трансляцию. что дальше-сразу в уши начнут лить через скайп?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
9 комментариев
Khariton Matveev

Мне очень жаль, если вы работаете в компании, куда вы приходите на работу ради денег. Мы делаем очень крутые продукты, меняем рынок образования и радуемся нашим общим успехам. Ребята из команды разработки всегда супер рады интересным публикациям о нас, когда СМИ публично хвалят продукт, или именитые клиенты оставляют классные отзывы )

Ответить
Развернуть ветку
6 комментариев
Иван Трифонов

Skyeng очень круты, до повышения цен учился там и бед не знал)

Сейчас занимаюсь самостоятельно, благо есть куча решений и методик..

Ответить
Развернуть ветку
Khariton Matveev

Спасибо большое за добрые слова :-) Мы планируем запустить к концу года групповые занятия в мини-группах (до 3-4 человек) — хочется сделать их намного эффективнее обычных оффлайн-групп, поэтому разработка нового продукта занимает очень много времени. Но мы надеемся, что уже скоро сможем предложить продукт, доступный большей аудитории!

Ответить
Развернуть ветку
4 комментария
Ivan Zamesin

Хорошая статья, возьму как за методичку. Как раз нужно вырасти в несколько раз :)

Ответить
Развернуть ветку
Khariton Matveev

Спасибо, Вань! :-)

Ответить
Развернуть ветку
Анатоли Маслоу

Наконец примеры положительные, это хорошо.
А можно подробнее по разработчикам - у всех зарплаты разные? Мотивация в деньгах есть отдельная, kpi?
Время присутствия фиксировано? По Москве?

Ответить
Развернуть ветку
Khariton Matveev

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

Однако мы уже давно поняли, что дорогой опытный разработчик может делать в разы больше пользы (особенно в работе над сложными проектами, где всё плохо параллелиться), чем 2 или 3 разработчика ниже уровнем — сейчас в команде оставили только профессионалов.

Мотивации и KPI есть только перед руководителем разработки, для самих разработчиков пока ничего такого не делали, однако для ребят мы транслируем важные сроки — и это часто мотивирует, команда сплочаетс в энтузиазме заделиверить продкт в определенные рамки по времени или бюджету.

Что касается времени пресутствия, у нас есть 4 часа в день (с 12 до 17 с обеденным перерывом), когда мы ожидаем что все на месте — в остальное время каждый решает сам, когда ему удобнее работать. Это особенно актуально, так как есть ребята из совсем разных часовых поясов.

Ответить
Развернуть ветку
Александр Калин

Будто про людей из другой вселенной читаю. Кодил как-то на удаленке. КПД в среднем на 30% ниже.

Ответить
Развернуть ветку
Khariton Matveev

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

Ответить
Развернуть ветку
1 комментарий
Андрей Корхов

Удаленные сотрудники у вас числятся официально в штате сразу? Или оформляете через какое-то проверенное время? Или не офрмляете или ИП им?

Ответить
Развернуть ветку
Alex Laryanovskiy

У нас есть испытательный срок. Поскольку не все сотрудники живут в России, то они находятся в штате не российской компании.

Ответить
Развернуть ветку
Khariton Matveev

Да, как правильно ответил Саша — после испытательного срока мы подписываем договор и NDA с головной компанией по британскому праву.

Ответить
Развернуть ветку
Alexander Erin

Спасибо!
Отличная статья! Хочется продолжения!

Ответить
Развернуть ветку
Khariton Matveev

Спасибо большое! Тут коллеги писали и просили подробнее рассказать как мы используем Slack, с какими-то деталями и хитростями внутренней кухни — думаю, это из этого может получиться что-то интересное и полезное :-)

Ответить
Развернуть ветку
2 комментария
Константин Нелюбин

А чем именно Slack лучше, чем Скайп? Не пользовался, но у меня ровно такие же потребности. Что он позволяет делать?

Ответить
Развернуть ветку
Valentin Dombrovsky

На эту тему полно статей, в том числе на vc.ru.
Вот, например: https://vc.ru/p/meduza-slack

Ответить
Развернуть ветку
Khariton Matveev

Про это могу написать отдельную статью. За что я больше всего люблю — это бесконечные интеграции (по сути, всё изо всех систем стекается в Slack, от фидбека пользователей до Alert систем мониторинга серверов). Ну и второе — крутейшие нотификации, я могу настроить для мобильного приложения, например, чтобы ко мне приходили 2 канала все сообщения, а вот с этих трёх — только те сообщения, где меня упомянули.

Ответить
Развернуть ветку
Александр Несмеянов

Современные методологии (аджайл, скрам, XP) постулируют get team together. Никакими *generic skype* не заменить чувство локтя.
Даже видеоконференция не дает обратной связи-не понятно смотрит ли человек на тебя или почитывает vc. Кроме того, очень часто видеоконференция-бОльший стресс, чем личное общение, даже для интровертов.
Я не верю в распределенные команды.

Ответить
Развернуть ветку
Khariton Matveev

Понимаю вас, я сам в начале то же самое говорил нашему директору ) Что разработка может быть только в одной комнате.

Однако мы попробовали — и не пожалели. Конечно, правильно её построить и организовать сложнее, и людей нужно подбирать к этому предрасположенных и процессы грамотно ставить и мотивационные инструменты в оффлайн плохо переносятся. Однако же мне кажется, наш опыт говорит о том, что у нас не плохо это получилось.

Ответить
Развернуть ветку
Анатоли Маслоу

А как вводятся новые разработчики? Руководитель следит за кодом нового человека?
Раз время работы не контролируется - ставятся сроки на задачи? Что если не выполнил или причины сомнительные? Как оценивается срок на реализацию? Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?

Ответить
Развернуть ветку
Khariton Matveev
А как вводятся новые разработчики?

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

Раз время работы не контролируется - ставятся сроки на задачи?

Мы не контроллируем, утром или вечером ты работаешь. Но мы контроллируем, что в неделю человек отработал +- 40 часов, а так же какие задачи он закрыл — и соотносим сложность задачи и итоговый код (который прикрепляется к тикету в JIRA автоматически) с сложностью задачи.

Как оценивается срок на реализацию?

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

Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?

Ничего страшного — ошибся ведь из-за чего-то, что что-то не учёл. Теперь он стал мудрнее и знает о новой веще и в будущем сможет лучше сделать оценку )

Ответить
Развернуть ветку
3 комментария
Oleg Abrazhaev

Где вы публикуете актуальные вакансии? На сайте не нашел раздела.

Ответить
Развернуть ветку
Khariton Matveev

Самый большой отклик на moikrug, иногда приходят интересные ребята с hh. Был положительный опыт использования сервиса AmazingHiring :-). А так же пиарим — распространяем в Facebook и часто наши вакансии берут на VC.

Ответить
Развернуть ветку
2 комментария
Ivan

А если программист и верстальщик фрилансеры? У которых по 3-4 клиента. Был ли у кого опыт создания хорошего проекта с фрилансерами? Или лучше смотреть в сторону штатного удаленного сотрудника?

Ответить
Развернуть ветку
Читать все 66 комментариев
null