«Проще сказать людям: “Я не буду вас контролировать вообще, работайте как хотите”»

В 6nomads мы помогаем ИТ-талантам устраиваться на удалённую работу в лучшие компании в России и за рубежом, подбираем интересные для их профессионального роста проекты. Запустили цикл интервью с руководителями компаний о найме и управлении распределёнными командами, за которыми, мы уверены, будущее.

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

Два других интервью:

• с HR-директором Aviasales Полиной Гаврой;
• с сооснователем «Хантфлоу» Михаилом Танским.
  

На этот раз мы поговорили с техническим директором блокчейн-платформы Moeco Алексом Корольковым о его принципах найма удалённых сотрудников, об управлении распределёнными командами, принудительном отпуске как крайней мере и том, почему расслабленный удалённый разработчик в гамаке — это прекрасно.

В 6nomads мы пытаемся определить что-то вроде портрета успешного удалённого сотрудника, чтобы их было проще находить, отбирать и нанимать. Как бы ты определил таких специалистов? Что их отличает?

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

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

То есть в условиях удалённой работы угрозой является скорее переработка, чем недоработка?

Если человек недорабатывает, не справляется, ты его увольняешь — тут всё просто.

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

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

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

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

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

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

Раз мы коснулись навыка письма. Столкнулись с двумя точками зрения на коммуникацию в распределённых командах. Одни считают критически важным умение писать не только потому, что это базовый навык, говорящий о структурности, последовательности, но и потому что почти вся коммуникация письменная и важно уметь понятно излагать свою точку зрения. Другие же считают, что чатики и переписки — только «клей», а вопросы решать и обсуждать работу нужно исключительно голосом. Что думаешь ты?

Обсуждать голосом вместо переписки в чате? Я стараюсь избегать общения голосом на спорные темы.

Думаю, это сильно зависит от людей. С моими сотрудниками голосом не очень выходит. Лекции им читать так можно, а вот спорить — лучше в чате. Если мы недопоняли друг друга и поругались в чате, то можно созвониться и тут же всё выяснить. А вот если мы поругались голосом, то там уже чат не поможет.

Можно ли сказать, что для удалённой работы нужно созреть, пообтесаться офисом, достичь профессиональной зрелости? Из твоего опыта можно сделать вывод, что успешные удалённые разработчики — это, допустим, ребята старше 30 лет. Нужно искать именно таких?

Высококвалифицированные сотрудники по определению старше, но сейчас в команде есть два разработчика — 24 и 25 лет. Нет, ограничивать поиск возрастными рамками — это абсолютный бред. Если интроверт любит свою работу, он может в 15 лет писать здравый код и прекрасно работать удалённо.

То есть возраст не связан с ответственностью? Не гарантирует её?

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

И опыт удалённой работы тоже не определяющий фактор. В команде есть человек, для которого Moeco — первое место работы, и он отлично тащит. Мы его наняли, потому что ему была интересна «железная» часть, по софту у него был только околоинститутский, опенсорсный опыт. И оказалось, что работает он в полный рост, а удалёнка ему очень подходит.

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

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

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

Есть ещё лайфхаки по правильному погружению в работу?

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

По итогу онбординга практикуете что-то вроде аттестации? Тестируете, разобрался сотрудник в процессах или нет?

Наша платформа большая и очень кросс-дисциплинарная. Мне нравится, когда люди растут и растут сами. Если дать им много информации, то собрать единую картинку — это работа, причём такая, которую мы все делаем редко. Потому если проводить по итогу онбординга тест, то заведомо ясно, что будут ошибки, а значит, у кандидата останется негативное послевкусие.

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

Многие в разговоре с нами упоминали, что soft skills на удалёнке ещё важнее, чем в офисе. Согласен?

Soft skills — самое важное. Проверить, может человек прогать или нет, — несложно. Если специалист чего-то не знает, не понимает, то сложным навыкам можно обучить, объяснить, почему надо делать так, а не иначе. С soft skills так не работает.

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

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

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

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

Тогда, может, у тебя есть некий чек-лист для собеседования, который помогает выяснять пригодность для удалёнки, не ошибаться, не нанимать «не тех»?

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

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

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

В таком случае дальше разговор вы не продолжаете?

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

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

Разумеется. Это единственный метрический KPI работы программиста. Остальных специалистов можно измерить как-то ещё.

Разница между джуниором, мидлом и синьором в следующем: джуниор не знает ответов на вопросы, что и как мы делаем. Мидл знает, как делать, но не знает, что. А синьор знает, что мы делаем и как.

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

А как в вашей команде происходит планирование спринта, приоритизация задач?

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

Груминги у нас проходят по вторникам и четвергам. Тогда обсуждаются все задачи, которые нужно сделать. Никакие другие задачи кроме прошедших через груминг делать нельзя. На груминге задача разжёвывается и получает эстимейт. Задачу без эстимейта делать бессмысленно, потому что в этом случае мы не можем дать ответы на вопросы «что?» и «как?». Иногда мы грумим не по расписанию, если так хотим.

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

А как вы технически организуете груминги?

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

Ты проводишь регулярные индивидуальные созвоны?

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

Это та встреча, на которой мне могут сказать: «Саша, ты херово себя повёл вот на том митинге — перебил человека. Не делай так, пожалуйста». Или про кого-то, что он нехорошо себя ведёт. При всех это говорить нельзя ни в коем случае, а вот на таком созвоне можно и нужно. Обязательно стоит отмечать и обратные ситуации, как кто-то здорово затащил по задачам, например.

Ещё все, не сговариваясь, а как-то само собой, дают фидбек по новичкам. Я эти мнения аккумулирую и на таком же face-to-face даю новому сотруднику. В период онбординга созвоны провожу чаще — раз в неделю, чтобы чувствовать настроение человека.

Но это всё же рабочие моменты. Некоторые технические директоры в интервью рассказывали нам, что face-to-face — это разговор строго о внерабочем, чтобы поддерживать сплочённость команды, знать, что происходит в жизни каждого. Потому на таких созвонах скорее обсуждаются здоровье собаки и рассада тещи. Вы такое не практикуете?

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

Те, кто до сих пор путают фрилансеров и удалёнщиков и мало представляют, как работают распределенные команды, формализуют свой страх перед таким форматом следующим вопросом: что я буду делать, если разработчик пропадёт со всех радаров, сроки будут гореть, а всё рушиться? Что бы ты им ответил?

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

Вот только контроль не масштабируется, и менеджер может контролировать пять-семь человек, а как только в команде становится десять — трое ни черта не делают, потому что контроль на них слабо распространяется.

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

То есть отчасти успех управления распределённой командой заключается и в решимости увольнять хоть на пятый день?

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

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

Понятно. Значит специалисты могут перегореть, могут не тянуть темп команды, не справляться, но добровольно уходящих, должно быть, немного? Удалёнщикам текучка несвойственна, в отличие от, скажем, программистов в Москве со средним «сроком жизни» в полтора года на одном проекте.

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

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

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

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

Отсутствие текучки не связано ещё и с тем, что много удалённых разработчиков из регионов?

Да, это тоже. Наверное, мы платим больше, чем они могли бы заработать в своём городе.

Но вы не преследуете цель сэкономить на удалённых сотрудниках из регионов?

Нет, держать людей ниже их планки — это очень плохая затея, особенно из-за того, что они работают удалённо.

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

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

Это всё очень индивидуально. Я вот не могу писать код в дневное время, не получается. Лучший свой код я написал с 11 вечера до 5 утра. При этом во что я одет — не имеет никакого значения.

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

В команде есть сотрудник из Батуми, всякий раз, когда у нас видеозвонок, я вижу его на балконе в гамаке с сигаретой в руке и ноутбуком на коленках. Человек никогда не напрягается, при этом у него настолько ровное деливери, что не бывает дней, когда бы он не смог выполнить задачу. То есть деливерит немного, но постоянно — мне такое нравится.

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

А что касается одежды… Ну я замечал, что работать голым как-то странно.

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

Что приходится общаться с людьми гораздо больше, чем в офисе. Если в офисе я могу с людьми не сближаться, то на удалёнке это просто невозможно. Мы обсуждаем новости, подходы к математическим проблемам, я ребят развлекаю задачками Эйнштейна. Для меня стало открытием то, что на удалёнке «приходится» дружить.

Закончи фразу: не пытайтесь браться за руководство распределённой командой, если…

Если вы контрол-фрик.

Особенно важное для удалённого сотрудника качество —

Дисциплина.

Почему в России так непопулярна удалёнка?

Потому что Россия — это милитаристская страна контрол-фриков. У нас любят, чтобы все ходили строем с 9 до 18 часов.

Регистрируйтесь на платформе и читайте больше материалов в нашем блоге.