В предверии тимлид-завтрака «Удаленная команда. Начало» мы поговорили с техническим директором компании wemake.services – Никитой Соболевым (sobolevn). Несмотря на то, что поиск разработчика, тем более опытного — страшный сон тимлида или менеджера проекта, немногие пока решаются перейти на работу с удаленщиками. Никита же несколько лет назад решил эту задачу кардинальным образом. Как? Давайте разбираться!



Дальше в интервью будут фигурировать двое: интервьюер (И.) и Никита Соболев (Н.)

О способах работы вообще и количестве точек контроля

И.: Практически все тимлиды и менеджеры разработки жалуются, что они никак не могут найти себе разработчика в офис. Особенно в регионы. Возьмем для примера Казань. Полгода не могут найти себе разработчика, но всё равно держатся за то, чтобы все сидели рядом с ними в кабинете. Кажется, это даёт иллюзорный контроль?

Н.: Именно — иллюзию контроля. Давай, наверное, начнём с определения удалённой работы. И здесь хочется не проводить сначала разницу между удалённой и не удалённой работой, а надо посмотреть на работу как таковую. На работе требуют разное. Есть работа, где ты просто приходишь, с 9:00 до 18:00 сидишь, что-то делаешь и в принципе – уже достаточно. Я называю этот подход «жопочасы» – вот ты пришёл и, соответственно, должен отсидеть. Всё. Больше никаких формальных требований нет. Особо хитрые работодатели могут придумать какой-нибудь нелепый KPI на минимизацию количества багов в проде. Или еще какой-нибудь бред. И тогда не менее хитрые программисты научатся его оптимизировать без полезной деятельности. И ничего не изменится.

А второй способ называется «за результат». Когда ты начинаешь проверять результат, тебе в принципе становится не важно, во сколько человек пришёл и во сколько он ушёл, и чего он делал. То есть если тебе важно, чтобы, в понедельник эта фича работала, и в понедельник она работает – в принципе, всё остальное тебя не интересует.

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

Н.: Совершенно верно, да. Результат – это не нечто большое. Результат – это что-то маленькое. Когда мы пытаемся достигнуть результата глобального, у нас появляются много маленьких промежуточных. И вот эти маленькие промежуточные результаты для нас тоже ценны и важны. И благодаря им мы видим понятный процесс, как человек идёт из точки А в точку Б, какие решения он принимает, какой код он пишет, какие фичи он видит дальше, в каком порядке он их делает. Мы получаем полную прозрачность. И нам в принципе становится не важно, где он находится, удалённо или не удалённо.

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

О людях, медитативном программировании и двух главных принципах удаленки

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

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

Маленькую понятную задачу я целиком доверяю человеку и говорю: «Вот тебе задача на час или на два. Ты можешь её делать, как считаешь нужным. Вот наши критерии завершённости, вот тебе инструменты». И, соответственно, эти два часа его вообще никто не трогает, он волен делать всё, что угодно. Через два часа он приносит и говорит: «Вот мой результат». Или говорит: «Такое сделать за два часа никак нельзя, и вот почему. Я придумал вот такое решение на будущее».

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

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

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

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

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

Моя единственная роль в этом всём – это просто контролировать направление, ну, и некую адекватность.

И.: Я поняла твою мысль, что общее видение – самое важное, чтобы человек верно понимал/выполнял задачи и видел свой вклад в проект. Но в твоей системе работы я вижу еще 2 принципа – это брать, во-первых, разработчиков исключительно высокого уровня, во-вторых, это очень хорошо написанная документация. Правильно?

H.: Совершенно верно. А теперь мы возвращаемся к удалённой работе. Почему мы, соответственно, выбрали этот вариант, а не вариант «офис». И ты сейчас точно подметила, что эти два пункта – являются ключевыми.

Первое – сильные разработчики. Где их найти? Сильные разработчики по всему миру распределены неравномерно. И есть точки, где сильных разработчиков больше и при этом стоят они дешевле. Зачем нам конкурировать, например, с московскими компаниями, кто может себе позволить платить много денег за сильного разработчика, когда наши ресурсы скромнее? Есть замечательный региональный рынок, рынок Азии или рынок Африки, или рынок других постсоветских стран. Там есть сильные разработчики, но они стоят в разы дешевле.

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

И второй момент – документация. Хорошая документация может быть написана только тогда, когда она нужна. Потому что, если её пишут из-под палки и в неё не смотрят, не обновляют, она быстро становится плохой. Хорошая документация, например, в опенсорс-проектах как пишется? Она единственный источник того, как люди могут про этот опенсорс-проект узнать и воспользоваться. Если люди видят, что в документации что-то не работает, они создают задачку и говорят: «В твоей документации что-то не работает». Ты говоришь: «Ой, сейчас поправлю». Если человек сидит рядом, он просто тебя спросит: «А что делать-то надо в этой точке?». А ты вынужден ему отвечать. И в таком процессе документация хорошей не станет. Чтобы документация была хорошей, нужно, чтобы люди находились на расстоянии и не могли напрямую общаться.

О системе оплаты удаленщиков и командообразовании

И.: Забавно, получается, что людям, когда они находятся на расстоянии, получается проще включиться в проект, потому что они могут прочитать документацию, а в офисе приходится искать, кто начинал это писать, откуда этот кусок взялся и что это вообще значит?

Н.: Да, им становится проще, потому что весь процесс удаленной работы построен на том, что придут новые люди. Есть два рабочих варианта: автоматизация и документация. Многие вещи проще автоматизировать: например деплой. А как что-то работает – проще описать текстом или графиком.

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

И.: Какие страхи и предубеждения у тебя были при переходе на работу с распределенной командой? Или их не было?

Н.: Естественно, страхи были, и наши первые ребята, которых мы нанимали на удалёнку, работали по старой системе, то есть за зарплату. А когда ты платишь зарплату, тебе становится не всё равно. Потому что ты хочешь выжать максимум из того времени, которое человек тебе продал. У меня тогда было очень много сомнений и предубеждений. И вообще не было контроля. Скоро я понял, что в таком формате удалённая работа не работает.

В итоге, мы тот эксперимент свернули. А теперь у меня есть скорее предубеждение к офису.

Какой-то человек хочет, чтобы я находился где-то в конкретной точке на Земле, ограничивая мою свободу передвижения. А еще он хочет, чтобы я всё время тратил на него, ограничивая мою свободу деятельности. Странно, что многим людям такой вариант кажется нормальным.

Понятно, что обязательства есть всегда. Но в моем случае эти обязательства – они про результат. То есть в такой-то момент я должен сделать вот это. А в офисной работе у меня обязательства, что я хожу в офис каждый день. И уже сверху мне придумывают еще какие-то требования, которые я могу умело откладывать на потом.

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



И.: Как выглядит с твоей точки зрения правильно построенная удалённая работа? Вот есть некий разработчик, который готов работать на удалёнке, что происходит дальше?

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

И хорошая удаленная работа выглядит точно так же. С чего начинается любое общение в опенсорсе? Разработчик создаёт задачку, говорит: «У меня что-то не работает», либо «Я не понимаю документацию», либо «Я хочу новую фичу». Ты смотришь, что нужно сделать для того, чтобы его удовлетворить. Далее идёт обсуждение, какие-то уточняющие вопросы, возможно, эта задача бьётся на несколько задач. А потом присылается код, который закрывает эти небольшие части. Код проверяется тестами и линтерами, происходит ревью. И потом просто релизится новая версия. Собственно, все.

А весь искусственно созданный мир вокруг проектов, который есть сейчас из разряда «у нас 15 тимлидов, 6 проджект-менеджеров и два скрам-мастера», они нужны для того, чтобы выжимать больше из людей за те же деньги. Потому что проверить результат — никто не может при всей фикции важности и контроля. С ориентацией на результат все работает и без них.

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

Н.: Объясню, я сам не был в такой ситуации безопасного перехода. И не знаю компаний, которые бы постепенно перешли к такому варианту. У меня был очень травматичный опыт. У нас была большая денежная яма из-за того, что мы работали по-старому, и все как-то резко пошло плохо. Мне пришлось всех, кто у нас тот момент был, уволить и по сути начать заново. И этот момент, с одной стороны, был очень сложный, болезненный, а с другой стороны, очень простой, потому что мне не нужно было делать трансформацию по ходу. Я просто рубанул и начал заново.

И.: Многие управленцы считают, что команда их главная ценность. А ты всех уволил. И сейчас ты считаешь своих ребят, которые у тебя работают в разных точках мира, командой?

Н.: Конечно, нет. Я вообще против использования слова «команда» не по делу. Я считаю, что команда – это действительно что-то уникальное. Всё, что есть сейчас, традиционно на рынке – это коллектив, в лучшем случае. А в нашем случае это даже не коллектив, это просто набор людей, которые вместе делают один проект и зарабатывают деньги. Они не то, что не команда, они даже не знакомы. В основном сейчас слово “команда” используется как еще одна манипуляция людьми.

И.: Интересно. По ощущениям, половина статей и выступлений об управлении распределенной командой о том, как сплотить эту команду, когда она в разных часовых поясах, говорит на разных языках, и как сделать эффективным взаимодействие. А для тебя этой проблемы вообще не стоит?

Н.: Не стоит. Более того, я против того, чтобы людей насильно сплачивали. Я считаю, что очень многие люди переходят границы. Есть граница работы, а есть граница личной жизни. И вот по работе я готов общаться с разными людьми. Потому что это работа, я не всегда выбираю с кем общаться. Надо – значит надо. А вот когда мне начинают насильно пихать в нос людей, с которыми я не хочу общаться вне работы, типа «иди сплачивайся с ними». С чего вдруг-то? У меня есть свои собственные друзья, у меня есть своя собственная семья, зачем я буду тратить время на непонятно кого, когда я могу пообщаться с важными для меня людьми? Для меня такое абсолютно непонятно.

«Нет», «может быть» и «да» — где искать разработчиков

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

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

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

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

И.: Тебе не кажется, что на самом деле система, которую ты предлагаешь, решает одну из основных проблем разработчиков, которые говорят, что они действительно пишут код 15 минут в день? А в остальное проводят на митингах и выгорают, выгорают, выгорают…

Н.: Конечно, я же её под себя делал! А я больше всего люблю писать код. Было странно, если бы я сделал систему, в которой я бы не мог писать код.

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

Н.: Могут, но не все. Только те, кто много и качественно работает. Они могут зарабатывать очень много. Верхней границы нет и быть не может. А некоторые люди вообще ничего заработать у нас не смогли.

А еще у нас немножко другие ценники. Они выше рыночных по России в несколько раз. Важно понимать, что мы продаем не те же самые часы. Обычный час работы – это ничто. Ты сидишь, час смотришь YouTube, и тебе за это платят. Некоторые компании хотят тебе аж зонд вставить, чтобы смотреть, чем ты там занимаешься. Следовательно цена такого низко-производительного часа – тоже низкая. У нас час работы – это фиксированная стоимость задачи.

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

Получается три группы: группа «нет» (это американцы и европейцы), группа «может быть» (это наши, Украина, Белоруссия) и группа «да» (это Африка, Азия и т. д.). Здесь вопрос конкретно моей реализации: за сколько я могу продать эту идею клиентам, и сколько они готовы платить. Опять же, мы работаем только с российскими клиентами. Если бы мы вышли активно на европейский или американский рынок, они бы платили больше, и эта проблема бы частично решилась. Но пока так.

И.: Ты почти весь глобус описал! Насколько расширяется выбор кандидатов с выходом на международный рынок?

Н.: Очень сильно расширяется. Мы пока еще не успели поработать активно с Южной Америкой. А там, вроде, тоже очень много хороших разработчиков.

И.: Скажи, а как ты ищешь разработчиков?

Н.: Никак. Они сами приходят. Им интересно попробовать.

P.S. Принципы работы Никиты могут вызвать и вызывают спорные мнения, но система показывает себя эффективной. Есть ли у вас альтернативный успешный опыт организации работы распределенной команды? Пишите в комментарии!

А те, кто 2 октября 2019 будет в Казани, приходите на тимлид-завтрак, где можно будет обсудить данную статью: выразить все свое негодование или одобрение подходу Никиты, а также послушать 3 других истории про работу с удаленкой и аутсорсерами.