Лого vc.ru

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

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

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

Поделиться

Когда мы создавали школу 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 по итогам переговоров.

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

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

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

>Достаточно в понедельник обозначать цели на неделю

а в пятницу их перенести на следующую неделю.
всегда ведь находятся оправдания.
да и не всегда легко реально определить сроки.

0

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

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

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

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

Хороший опыт, применяет ли agile в разработке или планируете?
Практиковали ежедневные митинги, беклог с задачами, какие возникают трудности?

0

Если мы делаем новую большую функциональность (которую разрабатывать, скажем, два месяца) и поделить никак не получается и выкинуть нечего — MVP в чистом виде, в этом случае делаем по waterfall, просто деля на небольшие задачки.

Если же есть MVP, то дальше запускаем agile, начиная процесс непрерывных улучшений.

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

А беклог по задачам, не связанным с разработкой, внутри компании, пользуетесь дополнительно таск-менеджером, каким-то или тоже в Jira?

0

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

0

Про code review и небольшие ежедневные летучки на 5-7 минут полностью согласен.

А вот подход «Нет отчета по итогам дня - рабочий день не учитывается при расчете зп.» всё же тут не работает. Ребята молодцы и хорошие, стараюсь просто разобраться почему не заполнили worklogs, может человек просто увлёкся задачей и забыл.

Вообще про логирование времени по задачам очень важно объяснить что это не инструмент контроля, а рассказать как это помогает компании — нам, например, очень важно знать сколько мы денег потратили на тот или иной проект (и JIRA умеет автоматически такие отчёты строить).

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

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

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

0

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

0

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

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

0

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

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

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

0

Здорово :)

Если вдруг будет бета, буду рад поучаствовать, если нет - буду ждать релиза)

Ну и тренажёр по грамматике тоже жду, конечно, если это будет так же удобно и полезно, как вышло с Words - будет очень здорово)

Договорились :-)

По поводу грамматики — обязательно будем делать, причём что-то уже появится до конца этого года. А так же по приложению Words реализовали далеко не всё из задуманного!

0

Спасибо)

А по аудированию/говорению планируются подобные вещи? Особенно последнее интересует)

0

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

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

0

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

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

−1

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

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

0

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

какие передовые? такая концепция самоорганизующихся команд существует уже лет 20, но построить такую команду ой как непросто

0

Да для всех. Если делаешь никому ненужную херню — мотивация падает. Когда видишь что результатом твоих трудов пользуются — работать сильно лучше.

точно. только ненадо путать bullshit с мотивацией

0

кстати вот счас еще заметил: вы мне, абсолютно незнакомому человеку, уже вешаете этот самый bullshit с первых строк... что же вы со знакомыми делаете...

0

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

так вы пиарщиком работали или HR?)

0

PR он не только внешний бывает

Пиарщиком. Кому, как не мне, было новости о компании мониторить?) А раз я их оперативно узнавала, то и делиться ими тоже удобнее было мне)

1

ну понятно-я и PR и HR и секретарь

−1

Каюсь, вы меня раскусили. На самом деле я там ещё и уборщицей подрабатывала.

1

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

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

0

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

0

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

0

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

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

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

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

0

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

0

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

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

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

0

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

Не надо про Slack, про него написано уже предостаточно, и все, кто хотел, давно на нем. А статья и правда хорошая!

Возможно, есть идеи? :-) Если со стороны видно, какие у нас есть сильные стороны о которых мало писали — с удовольствием расскажем!

0

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

0

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

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

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

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

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

0

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

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

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

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

0

Так 40 часов вы как контроллируете? Вроде сказали что учета нет...
Кто и как соотносит выполненную работу и трудоемкость? Тимлид может считать что фичу 10 часов делать, а прогер 20 часов в итоге потратит. Как это решается?

0

Так как же нет? Про лог времени писал несколько раз в комментах — это обязательно используем. У нас нет систем как с операторами, когда мы с 9 до 16 контрлируем каждый их шаг.

Для учета времени, что мы тратим используем плагин Tempo для JIRA.

0

Так, т.е. 40 часов должен отработать? В офисе это принципиально невозможно. Удаленно тоже никто за 40 часов не закрывает задач на 40 часов, реально на 30 часов или менее. Это и к вопросу зарплат - требуя 40 часов отработанные нужно платить как за 60 часов по-хорошему. Или получается все должны работать больше? Или в часы включается все обсуждения, и т.п.? Как тогда тимлид оценит насколько правильно потрачены часы?

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

0

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

0

про мойкруг удивлен, там попробуем тоже :)
а если не секрет - какие ЗП все-таки? Выше рынка крупных городов России за исключением Мск и СПб?

0

Увы, величину зарплат наших разработчиков не разглашаем :-)

0

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

0

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

Сейчас обсуждают
Ildar Karimov

money.yandex.ru/cards

«Яндекс.Деньги» остановили обслуживание выданных вместе с «Тинькофф банком» карт и перешли на собственный процессинг
0
Yuriy Belonozhkin

Предыдущее предложение смотрите - обслуживание перешло к платёжной системе. Карты брать, видимо, там же, где и тиньеоффские - заказывать в личном кабинете

«Яндекс.Деньги» остановили обслуживание выданных вместе с «Тинькофф банком» карт и перешли на собственный процессинг
0
Designoo

Ясно как день, что иксперта из ФРИИ шавухой подкупили

«Где Шаверма» — приложение для поиска ларьков с шавермой в дополненной реальности
0
Designoo

Какой бюджет интересно

Конструктор с нарезанными брендами: представители брендинговых агентств дали оценку логотипу ГК «Дикси»
0
Культурный Код

Ildar Karimov, спасибо. "«Яндекс.Деньги» начали выпуск новых пластиковых карт," можно понять, как нашли другого партнера.
А где эти карточки брать?

«Яндекс.Деньги» остановили обслуживание выданных вместе с «Тинькофф банком» карт и перешли на собственный процессинг
0
Показать еще