что такое распределенная команда
Распределенная команда: удачные примеры удаленной работы
Согласно отчету Stack Overflow, треть разработчиков считает, что распределенная команда — один из основных факторов привлекательности компаний. Причем 43% респондентов работают из дому как минимум один раз в месяц, и только 12% опрошенных — полностью удаленно.
Офисных работников активно заменяет удаленная (remote team) команда — новая реальность, к которой многие компании относятся с опаской и недоверием. Стоит ли? Давайте разберемся.
Что такое распределенная команда?
Отлично выполненная задача на удаленке — показатель качества и самоорганизованности исполнителя. Всё больше компаний стараются отказаться от организации офисных процессов в пользу распределенной команды.
Распределенная команда представляет собой группу людей, которые находятся в разных географических точках и сотрудничают удаленно. Больше не нужно тратить время на пропускную систему, совещания и бюрократию! Распределенная команда ориентирована не на процесс, а на результат.
Системы для управления распределенной командой
Зачастую начинающие менеджеры боятся, когда в их команде появляются сотрудники из других локаций. Ведь здесь появляется масса опасений по типу «а вдруг производительность упадет, не будет контроля или мотивации». На помощь в данной ситуации приходят различные workspace системы для управления проектами.
Всемирно известные онлайн-системы:
Онлайн-системы, распространенные в странах постсоветского пространства:
Успешные примеры распределенных команд
Нередко мы сталкиваемся с тем, что многие руководители отрицают эффективность удаленной работы. Но, живя в 21 веке, неужели программисты не могут писать код в двух разных городах? Конечно, могут. И даже лучше, чем сидя в одном офисе рядом с друг другом.
Вот несколько удачных примеров распределенных команд:
Этот список можно также дополнить организациями с громким именем такими, как InVision, Evernote, Virgin Group, Zapier, 1password, Ghost и Basecamp.
Для какого бизнеса подходит?
Удаленные работники позволяют компании сэкономить на аренде офисного помещения и создании условий для работы. Достаточно будет офиса для руководителя и представителей компании. Бумага, канцелярия, кофе, чай и еще много статей расходов можно сократить благодаря созданию распределенной команды.
Больше всего она подходит под две бизнес-модели:
Сегодня это наиболее простые для запуска бизнес-модели. При создании сервисного бизнеса сложность заключается в систематизации и масштабировании. Зачастую агентство или сервисный бизнес сильно привязаны к руководителю. Сложность E-Commerce бизнеса заключается в необходимости инвестиций при запуске новых продуктов и постоянном увеличении продаж и оборота.
Возможно, кто-то до сих пор считает, что распределенная команда — это плохо, а люди — не роботы и не компьютеры. Но если бизнес связан с интернетом, социальными сетями и информационными технологиями, то не стоит ограничиваться географией и стенами офисного помещения. А Вы как считаете, что лучше: офисный стол со стулом и долго думающий компьютер или диван, теплый чай и ноутбук на коленях? Ждем ответы в комментариях!
Распределенная команда разработки: плюсы и минусы
Руководитель Winfox Рустам Мухамедьянов о том, какие возможности дает распределенная команда, каким отделам по-прежнему удобнее работать в офисе и почему заказчиков уже не смущают разработчики на удаленке.
Мы стартовали как обычная студия разработки: у нас был офис, куда все сотрудники каждый день приезжали на работу. Но вскоре мы поняли, что не можем конкурировать за разработчиков с крупными компаниями: банками с их собственными отделами разработки, продуктовыми компаниями вроде Яндекса и Мэил.Ру.
То есть мы не могли нанять разработчиков на полный день и предложить им такую же высокую зарплату, как лидеры рынка. Но вместе с тем нам хотелось привлекать в команду квалифицированных специалистов, которые многое могут и умеют — чтобы брать и выполнять более крупные и сложные проекты.
Так мы начали искать разработчиков на удаленке. И поняли, что такой подход позволяет нам не терять в эффективности и оптимизировать затраты. Плюс мы с техническим директором Winfox Сашей Хрущевым, с которым вместе основали студию, — сами адепты удаленной работы. Мы за то, чтобы человек работал там, где ему удобно. Главное, чтобы он закрывал свою зону ответственности и показывал результат.
На удаленке гораздо сложнее имитировать кипучую жизнедеятельность, чем в офисе. Или ты или показываешь результат, или нет — команда это сразу видит.
Офис студии по-прежнему в Москве, а в команде появились крутые специалисты со всего мира. Многие из них никогда бы не согласились работать в офисе, так что часто удаленка — единственно возможный вариант заполучить опытных специалистов в команду.
Вскоре мы выстроили бизнес-процессы так, чтобы удаленка не мешала качественно выполнять задачи и сдавать проекты в срок. Ведь сотрудники на удаленке работают по определенным регламентам, они оформлены в штат. Это ежедневная сосредоточенная работа, а не смузи на пляже с ноутбуком, как на картинках к статьям из серии «5 преимуществ работы фрилансером».
Раньше было четкое разделение: специалисты из Москвы стоят дороже, разработчики из регионов — дешевле. Московские студии выбирали удаленку, чтобы нанять более-менее толковых специалистов, но платить им меньше, чем людям из столицы с таким же опытом.
Сейчас это не работает. Открытые границы, отсутствие проблем с изучением языков и свобода перемещения, доступная нам до недавнего времени, позволили людям понять, что они могут назначать себе цену вне зависимости от местоположения. Важны только знания и умения, а не то, где ты живешь.
Удаленка — больше не способ найти дешевую рабочую силу. Это способ конкурировать с другими городами, регионами, странами. Да вобщем-то, со всем миром.
У нас появился крупный проект с Java-стеком разработки, для которого понадобились крутые Java-разработчики. Мы искали таких специалистов в Москве: назначали собеседования, общались, но все упиралось в то, что подходящие кандидаты просили от 200 тысяч рублей в месяц.
И тогда мы расширили зону поиска, нашли не менее опытных специалистов, которые живут и работают в других городах России. Благодаря этому мы удержали заказчика, с которым работаем и по сей день. Этот проект показал, что мы как студия можем расти благодаря распределенной команде.
Дефицит кадров в корпоративной разработке на Java и в целом очень высок. Лидеры рынка «Сбертех», дочерняя айти-компания «Сбербанка», забирают себе лучших из лучших и предлагают им очень хорошие деньги. Из-за этого всем остальным сложно заполучить в команду толковых программистов.
Специфика работы позволяет разработчикам нормально работать на удаленке. Когда программист берется за задачу, он глубоко в нее погружается и очень не любит, когда его кто-то отвлекает. Ведь чтобы вернуться к работе, программисту надо заново настроиться и сконцентрироваться, а на это уходит время. Так что удаленка здесь для сотрудников удобнее.
Когда все сидят в офисе, менеджеры часто дергают разработчиков по любому поводу. Это плохая практика — эффективность работы программистов снижается. На удаленке такой проблемы нет.
Для нормальной работы удаленной команды очень важна постановка задач. У нас все задачи и коммуникации ведутся в трекере. Когда нет возможности пообщаться лично и рассказать все про задачу, на ее описание уходит больше времени: надо прикрепить скриншоты, документы, ссылки, гайды и так далее.
Зато это учит точнее формулировать свои мысли и выражать их так, чтобы у исполнителя не осталось никаких вопросов. Ведь любые дополнительные вопросы — это дополнительно потраченное время, а это делает процесс менее эффективным.
Мы стали много времени уделять постановке задач. Например, задачи прилетают к разработчикам и тестировщикам полностью описанными, с развернутыми комментариями. Такие задачи легко проверять, а значит, удобнее править баги и показывать заказчикам отличный результат.
Кроме очевидных плюсов переход на удаленку принес и сложности. Главная из них — это привычка работать в одном помещении. Люди привыкли собираться вместе, обсуждать проекты и текущие задачи, находить оптимальные способы их решения. Психологически все это удобнее делать, сидя рядом друг с другом. Плюс живое общение помогает быстрее учиться у коллег чему-то новому.
Мы поняли, что пришло время изменить себя и подход к работе. Теперь надо развиваться самостоятельно, читать много специальной литературы и слушать вебинары, а не ждать совета от того, кто сидит за соседним столом.
Чтобы новые принципы прижились, понадобилось время. Поначалу было сложно, потом стало легче, и мы полностью убедились, что удаленка гораздо эффективнее привычной работы в офисе.
Так как разработчики не сидят рядом, делиться знаниями и опытом получается не так быстро, как раньше. Корпоративная культура распространяется медленнее. Поэтому мы нашли компромисс: нанимаем на удаленку сеньоров, то есть специалистов с большим опытом, которые досконально знают свое дело. А в офис сажаем джуниоров — тех, кто только начинает заниматься разработкой. Под присмотром тимлидов они учатся быстрее.
Джунов лучше сажать в офис, потому что в атмосфере командной работы и под присмотров опытных коллег они быстрее учатся и перенимают корпоративную культуру. Чтобы из джуниора вырос хороший специалист, молодому разработчику нужно уделять много внимания.
Технический директор и некоторые руководители отделов работают в офисе — так удобнее контролировать работу команды. Также в офисе остались некоторые продажники, маркетологи, проектные менеджеры — те, кто активно общается с заказчиками. Многие заказчики находятся в Москве и часто к нам приезжают, чтобы обсудить важные рабочие вопросы. Все это удобнее делать при личном общении, когда можно пожать руки и посмотреть собеседнику в глаза.
Остальные сотрудники отделов менеджмента и маркетинга работают на удаленке, как и большая часть команды. Мы идем на это, если удаленный формат не мешает сотруднику качественно выполнять задачи.
У нас нет отделов, которые полностью сидят в офисе или на удаленке. Мы за гибкость, поэтому пробуем разные сочетания и оставляем то, которое в данный момент максимально эффективно.
Если до пандемии и карантина некоторые заказчики с недоверием относились к студии с распределенной командой, то сейчас все изменилось. Заказчики на личном опыте убедились, что работать удаленно удобно — это не мешает выполнять текущие задачи, проводить совещания.
Стало намного проще объяснять заказчикам, что мы работаем удаленно. В этом больше нет ничего непонятного и пугающего — из-за коронавируса на удаленку перешли все, кто мог это сделать.
Учась в университете, я прочитал книгу “Rework. Бизнес без предрассудков” — и загорелся идеей построить компанию, в которой сотрудники работают удаленно.
Круто, когда человек свободен в выборе места для жизни и работы. Он может работать оттуда, где ему сейчас хорошо. Может путешествовать по миру, узнавать новое и набираться опыта. И при этом приносить пользу, работать и реализовывать себя. Именно такую философию я проповедую. И удаленка в этом нам очень помогает.
А как вы относитесь к удаленке? Делитесь мнением в комментариях, давайте обсуждать?
Как работает ИТ на удаленке: советы по управлению распределенными командами
Считается, что ИТ-компании в России не пострадали от кризиса пандемии. Они одними из немногих смогли оперативно перенести свои бизнес-процессы «на дом». Как эффективно организовать удаленную работу с распределенными командами делится опытом Николай Сокорнов, директор департамента разработки ПО компании «Рексофт».
Сегодня в разработке программного обеспечения распределенная или гибридная команда – это норма. В «Рексофт» (да и любом другом разработчике) порядка 75% команд работают именно по такому принципу. У нас офисы расположены в пяти городах: Санкт-Петербурге, Воронеже, Ростове-на-Дону, Москве, Стокгольме. Также мы привлекаем отдельных разработчиков из других городов, например, Твери. Кроме того, к работе над проектами часто присоединяются из различных точек мира сотрудники заказчиков, курирующие задачи. У нас стандартная ситуация, когда руководитель проекта находится в Москве, а разработчики в Санкт-Петербурге и Воронеже. И даже если они находятся в офисах «Рексофт», по факту – это дистанционная работа.
Существует нехватка квалифицированных кадров. Компаниям, занимающимся разработкой, это проблема не оставляет выбора. Главное, чтобы были хорошие специалисты, а где они находятся — уже вторичный вопрос. Обратного пути нет. В ближайшем будущем все команды будут распределенными.
Основной принцип в управлении распределенными или гибридными командами состоит в том, что процесс построен так, как будто вся команда работает удаленно. Не надо принимать во внимание, что кто-то из коллег сидит рядом в офисе. Руководитель должен воспринимать всех участников процесса как членов распределенной команды. Для всех участников проекта должны быть введены единые объективные критерии работы.
Что я имею ввиду. У руководителя всегда есть соблазн кого-то посадить рядом с собой, чтобы постоянно контролировать, или поручить наиболее важные задачи сотрудникам рядом, чтобы всегда иметь возможность лично обсудить ситуацию на проекте, а, например, задачи по выявлению проблем в коде отдать удаленным коллегам. Такой подход ведет к развалу команды.
Кроме того, одно из главных искушений для тех, кто работает в офисе – это собраться за кофе и быстро что-то обсудить. Естественно, те, кто работает удаленно, из этого обсуждения выпадают. Поэтому работа в гибридной команде требует более четкого соблюдения всех процедур, документирования всех этапов и решений в системах и почте. Это позволяет удаленным участникам команды не чувствовать информационный голод.
Еще один важный элемент для создания эффективной распределенной команды – это регулярные личные встречи всего коллектива. На мой взгляд, такие очные совещания правильнее делать раз в месяц, но не реже раза в квартал. Это позволяет не только усилить командный дух, но и сглаживает разницу в общении с удалёнными сотрудниками, понять, чем сотрудник дышит, как он чувствует себя в проекте.
Особенность удаленной коммуникации состоит в «срезании» каналов передачи информации. На расстоянии, как правило, мы общаемся письменно или голосом. Уходит язык жестов, эмоций. Хороший руководитель не только слушает сотрудника или читает его отчеты, а пытается понять настрой и мотивацию сотрудника, уловить скрытые проблемы, которые не всегда коллеги готовы обсуждать в открытую. Выяснить такие вещи при личной встрече намного проще. Да, и сотрудник в личной беседе скорее обозначит волнующий его вопрос.
Сегодня все используемые в совместной разработке инструменты и платформы имеют дистанционный доступ через интернет, поэтому рабочая среда практически никак не меняется от того, где находится разработчик в офисе или на удаленке.
Исключением являются проекты, когда необходимо написать приложение для какого-то конкретного оборудования или аппаратуры заказчика. Например, «Рексофт» делал подобный проект для «Роскосмоса». Такой стенд возможно организовать только в офисе, и часть команды должна присутствовать на рабочем месте. Примерно та же ситуация с тестировщиками, работающими с огромным количеством устройств. Компания просто не в состоянии обеспечить такой набор техники для каждого сотрудника.
Работа большой распределенной команды: преимущества удаленки, решения проблем, полезные инструменты
Всем привет! Меня зовут Алексей, я тимлид команды Vimbox (платформа для обучения в Skyeng). Не так давно я выступал на конференции с докладом об удаленной работе и особенностях распределенной команды. Неожиданно темой заинтересовалось много людей, хотя я думал, что хайп уже прошел и никого не удивить. Поэтому я решил поделиться и с вами наработками, полученными за четыре года функционирования в этом формате. Поскольку у нас в компании из 55 разработчиков 51 человек постоянно работает вне офиса, да и сам я живу в Калининграде, думаю, наш опыт многим может пригодиться.
В чем смысл удаленной работы, почему не сидеть в одном офисе?
У удаленной работы есть два важных преимущества:
Отмечу, что цели сэкономить на удаленных разработчиках мы не ставим. Все зарплаты у нас московские — иначе и быть не может, потому что специалисты прекрасно знают себе цену и привыкли получать соответствующие навыкам деньги.
Как вы проводите собеседования? Когда нельзя увидеть собеседника лично, пожать руку?
У удаленного собеседования есть ряд преимуществ. Самое главное – комфорт. Не нужно приходить в офис, видеть незнакомых людей, кого-то ждать на неудобном диване. Человек сидит у себя дома с ковром и котом, это расслабляет, помогает установить контакт. Комфортно и интервьюеру: можно иногда смотреть в свои записи, делать пометки, при необходимости отключать микрофон.
Второе преимущество – возможность записи видео. Для таких роликов находится немало применений. Первое – можно посоветоваться, если есть сомнения: дать посмотреть другому тимлиду, продакту, принять совместное решение. Второе — у нас много продуктовых команд, и если я понимаю, например, что человек хороший, но у него недостаточно опыта именно во фронтенде, я могу кинуть запись бекенд-команде, которой тоже нужны люди; им не придется проводить отдельную беседу. Третье, что сейчас внедряем: если человек не прошел испытательный срок, мы пересматриваем собеседование, стараемся понять, были ли допущены ошибки на этапе найма, и можем ли мы их исправить. Четвертое: мы все время стараемся совершенствовать процесс собеседования, поэтому мы выборочно даем посмотреть записи другим тимлидам, обсуждаем, что можно улучшить.
И да, перед каждой беседой предупреждаем кандидата о записи, спрашиваем, можно ли записывать и обещаем, что видео в паблик не уйдет.
Как проследить, что человек на удаленке работает, а не сидит на Ютубе?
Ответ: следить не нужно никак. Мы должны нанимать мотивированных людей, готовых работать. С нашей же стороны нужно обеспечить прозрачность рабочих процессов как для разработчика, так и для команды, тимлида и продакт-менеджера.
Начну с самого базового: ворклоги. Есть три причины, почему мы обязательно ведем их в нашей компании:
1 — на наш взгляд, это дисциплинирует. Когда я в конце дня заполняю ворклог, я вижу, на что я потратил время, анализирую; у меня появляется возможность понять, что я делаю неэффективно. Мы хотим, чтобы такая же привычка была и у наших разработчиков;
2 — если во время спринта мы видим, что на какую-то задачу потрачено намного больше времени, чем планировалось, мы всегда проводим overspent-ретроспективу, чтобы понять, что произошло и как мы можем исправить ситуацию. Здесь нет цели обвинить разработчика — нам необходимо найти причину ошибки и улучшить планирование;
3 — у нас много команд, иногда одна команда заказывает что-то другой, и ей нужно оценить ориентировочную и итоговую стоимость работы: посмотреть, сколько потрачено времени и умножить на базовую ставку;
Есть и бонус: признаюсь, во время испытательного срока мы делаем ревью ворклогов. Это позволяет понять, достаточно ли ответственный человек; это не единственный фактор, но по ним многое видно. После испытательного срока к этому уже не возвращаемся.
У прозрачности есть несколько важных компонентов: актуальные статусы, актуальные remaining estimates, актуальный бэклог. Обеспечив все это, мы избавляемся от бесконечных вопросов от тимлида к разработчику, от продакта к тимлиду и т.д. из серии «когда это будет сделано», «сколько осталось» и «когда на проде». Все всегда можно посмотреть в таск-трекере.
Еще один инструмент повышения прозрачности — текстовые стендапы, которые мы проводим наряду с видеовстречами. Текстовые, чтобы все обсуждение сохранялось в виде букв, не нужно было пересматривать видео и искать в нем нужную минуту. Если пропустил такой стендап, все равно можешь написать репорт и посмотреть, чем заняты коллеги.
Вот так выглядит наша скрам-доска:
Могу точно сказать, что здесь все статусы актуальные и все estimates расставлены верно, но у читателей сразу возникает вопрос: почему пустая колонка code review? Неужели не делаете? Делаем, но мы нашли способ, как обеспечить быстрое прохождение code review.
Для сложных задач необходима мотивация. Когда надо сделать что-то совсем простое — код ревью, деплой и т.д., — людей надо просто тыкать. Раньше этим занимался я: видел на доске, что несколько задач зависло в код ревью, и писал в слаке: давайте сейчас возьмем и сделаем. В какой-то момент мне это надоело, за выходные написал слак-бота, чтобы он тыкал палочкой в разработчика. Каждое утро бот публикует дайджест про то, какие задачи зависли в каких статусах, и тегает людей, которые должны что-то сделать:
Здесь видим, что одна задача зависла на код ревью, две готовы к деплою, одна к тестированию, эстимейты проставлены у всех задач. Все сообщения публичные, по ним сразу видно, у кого что. Такая прозрачная система работает: с тех пор как запустили, задачи перестали зависать в статусах.
Бот не только занимается тыканьем, но и сообщает новости о нашей работе: состояние спринта, насколько выполнен, какой прогресс, estimation accuracy, публикует информацию о важных для нас проектах. Вот скриншот; мы тогда занимались миграцией на ангуляр, проект завершен на 91%, видно, сколько часов осталось:
Стараемся делать это по всем крупным интересным проектам — для себя и для бизнеса, чтобы любой коллега мог это посмотреть.
Ну а еще надо поднимать вовлеченность – ежедневные встречи, планирование и ретроспектива, один на один, вимбоксинги и квартальные презентации (это на самом деле не скучно). Недавно начали играть в Counter-Strike, сначала играли внутри команды, а на днях обыграли маркетинг.
У нас есть инструмент, позволяющий проводить многие онлайн-встречи, особенно те, что проходят в формате брейншторма. Это стандартная ретро-доска, которую многие используют для проведения онлайн-ретроспектив, но мы пошли чуть дальше и используем ее в других целях.
Вот пример нашего рефакторинг-митапа:
В данном случае решается задача оценки технического долга проекта. Раньше это традиционно делал тимлид. Он перечислял слабые места, говорил, что должны исправить, оценивал уровень долга. Потом я понял, что у нас очень много репозиториев, очень много кода, и я один не справляюсь, потому что я не работаю со всем этим объемом непосредственно. Пришла идея делать оценку долга всем вместе. На скриншоте каждая колонка — это один проект. Каждый разработчик за несколько дней вспоминает все костыли, которые он когда-либо в нем встречал, все свои претензии к коду, и пишет все это в карточках. Потом мы собираемся и обсуждаем эти карточки одну за другой. Потенциальные решения преобразуются в тикеты в Джире, потом приоритизируются, в конце концов мы имеем приоритизированный список тикетов, который полностью формализует весь технический долг команды.
Второй пример — стандартные ретроспективы по процессам, оценке задач, они позволяют удобно делиться фидбеком и приоритизировать задачи встроенным инструментом голосования, плюс сохраняется история ретроспектив в одном месте.
Работая в офисе, я хожу в курилку и столовую, где могу поговорить, обсудить, быть в курсе всего, что происходит. А дома я изолирован, вижу задачки в Джире, мне ничто не интересно. Как быть?
Действительно, такая проблема есть, но мне кажется, что мы научились ее решать. Сейчас пойду от меньших способов коммуникаций к большим.
Начнем с тикетов в Джире. Мы используем стандартную Agile практику, у нас практически все тикеты формулируются не задачами (что надо сделать), а проблемами (пользовательский опыт). Это важно при удаленной работе. Вот пример фикса:
Когда разработчик берет эту задачу, он не просто фиксит кнопочку, не работающую в IE11, он знает, что есть конкретный корпоративный клиент, готовый заплатить 15 миллионов рублей, чтобы она у него работала. Он знает контекст, это добавляет мотивации, плюс ведет к тому, что часто предлагаются альтернативные, более эффективные решения.
Дальше – спринт. Спринты мы планируем всей командой, это не только разработка, это еще QA, аналитик, продакт. Последний в начале каждой итерации презентует нам все продуктовые задачи, говорит, какая проблема, как ее решать, к чему придем, как это отразится на пользователях, защищает свою задачу перед командой. Все знают, на какие стандартные вопросы продакт должен ответить: зачем мы делаем эту задачу, есть ли альтернативное решение, действительно ли это нам поможет. Вся команда оказывается в контексте того, куда мы движемся в ближайшие две недели. Таким образом, мы избегаем простого распределения задач.
Квартальные планы: это не так страшно, как звучит; квартальная презентация длится всего 45 минут, идет в форме интерактивной презентации, которую готовит продакт. Здесь обязательно видео, опросы, интервью, она позволяет всей команде узнать, что мы будем делать в течение квартала или года. Иногда в рамках спринта не видно всей картины проекта, квартальная презентация позволяет оценить, как твой маленький кусочек ложится в большую историю.
Недавно ввели новый формат – аналитический стендап. Разработчик не может напрямую общаться с пользователями, поэтому у нас в команде есть собственный аналитик, который раз в неделю рассказывает о всех новостях, произошедших с нашим продуктом: как изменился фидбек, как зашла та или иная фича, какие метрики будем улучшать в ближайшем будущем. В итоге вся команда в курсе того, как ведут себя наши пользователи, что у них происходит, как они реагируют на нашу работу.
Планы других команд – каждая команда публикует планы в виде красивой презентации, чтобы все соседи были в курсе. Эти презентации нельзя делать в экселе, их надо делать кратко, емко, понятно и с картинками, чтобы кто угодно мог зайти, посмотреть и понять, кто что делает. Это зачастую просто интересно.
Ну и наконец – Гоша Live. Наш директор раз в месяц собирает всех сотрудников в онлайне и рассказывает о глобальных результатах и планах, после чего проходит сессия Q&A.
А когда же вы работаете, если у вас все время встречи?
Я накидал типичный график разработчика:
Это наш стандартный 10-дневный спринт, тут фиолетовым обозначены встречи, за исключением квартальных. Видно, что большую часть времени занимает именно работа, а не коммуникации, и если бы это была работа в офисе, не было бы четких границ между работой и общением.
Как быть с часовыми поясами?
Самый большой отрыв по времени сейчас – +7 от Москвы. Это не проблема для митапов в 11 по Москве, а дальше кейсы решаются договоренностями. Если случилось такое, что тебе надо прямо через минуту получить ответ, значит, что-то не так с процессами, их надо перестроить. У нас нет ситуаций, когда надо здесь и сейчас решить рабочий момент. Если же это форс-мажор, то он никак к часовым поясам не привязан, все равно может случиться и среди ночи.
А как же личное общение?
Мы знаем об этой проблеме, такой запрос есть у сотрудников, мы стараемся ее решать.
Два раза в год приглашаем всех разработчиков в московский офис, оплачиваем перелет и проживание, стараемся, чтобы приезжали командами, чтобы люди, работающие вместе, но не видевшие друг друга полгода (а то и вообще никогда) пообщались. В прошлом году впервые попробовали формат хакатона, собрали всю разработку в одном месте на три дня. По хакатону получили фидбек: все круто, но мало общения, слишком много кодили; в этом году сменим фокус.
Спросить человека в офисе проще и быстрее!
Кажется, что коммуникации в одной комнате супер-эффективны в плане скорости: я могу пихнуть Петю, который все знает про свой модуль, и он мне сразу все скажет. Почему же мы считаем, что удаленная работа эффективнее?
Ответ простой: слак – это дешево, а живое общение – дорого. Вы сидите в офисе, работаете, делаете задачу, тут коллега тыкает в плечо и задает вопрос, вы отвлекаетесь, начинаете отвечать. Да, есть практика красной папки, которую можно положить на стол, чтобы вас не трогали, но она тоже работает не так хорошо, как хотелось бы. Изменим ситуацию: человек подходит к соседу и начинает с ним тихо о чем-то говорить, вы слышите какие-то ключевые слова типа «вимбокс», думаете, что сейчас они что-то решат без вас, невольно начинаете прислушиваться и отвлекаетесь от своей задачи. Или идете на кухню, видите Глеба, ваша воспитанность не позволяет просто пройти мимо, вы говорите: «Привет, Глеб, как там дела с аналитикой?» и Глеб 15 минут рассказывает про все свои задачи. Вы с ним потеряли по 15 минут. В офисе смазана граница между работой и коммуникацией, и коммуникации часто бессодержательны.
Но это не значит, что если мы перейдем в слак, наши коммуникации сразу станут эффективнее. Чтобы поддерживать эффективность, мы используем некоторые свои методы. В первую очередь, жесткие конвенции.
В слаке у нас четкая иерархия каналов. Есть некоторые общие, где сидят все сотрудники. Дальше идут горизонтальные по направлениям, в них более 100 человек в каждом. Затем каналы команд, потом каналы под их конкретные задачи и проекты. У каждой команды также есть канал для идей и для багов. Это сделано, чтобы информационный шум направился в один поток. Отдельный тип каналов – интеграции: там появляются автоматические сообщения, если упал сервер или что-то еще сломалось, на них подписываются те, кто может починить.
Наконец, еще один хинт – мы создаем теги таким образом, что если кто-то не знает, как зовут тимлида какой-то команды, можно по определенным правилам сделать запрос и найти всех людей, отвечающих ему.
А как же обмен опытом в команде?
Есть мнение, что если посадить вместе сениора и джуниора, то через какое-то время джуниор станет мидлом, мидл – сениором и т.д. Это отчасти верно, просто мы постарались реализовать обмен опытом и в распределенной команде.
В первую очередь для этого используются упомянутые выше вимбоксинги. Это встречи, где разработчики нашей платформы Vimbox делятся своими достижениями, рассказывают про реализацию интересных проектов с остальной командой.
Вимбоксинги надо правильно организовать. Если вы назначите такие встречи и спросите “Кто хочет выступать?”, то с высокой вероятностью выяснится, что никто. Мы задаем другой вопрос – “Кто про что хочет послушать?” И участники команды говорят: я хочу послушать Глеба, потому что мне интересно узнать о его аналитических инструментах. Или: я хочу послушать Диму, потому что он сделал интересную задачу по поиску. Дальше голосуем за каждую тему, если собрали достаточно голосов, то говорим человеку: тебе придется рассказывать. Пока отказов не получали, проводим раз в неделю или две.
Тривиальная вещь – отдельный канал в слаке, где все делятся прочитанными полезными статьями и интересными книгами.
Раз или два в месяц проводим общие митапы разработки, где рассказываем глобальные вещи, например, про внедрение алертов в инфраструктуре.
С тимлидами используем тот же инструмент ретроспектив, также проводим встречи в формате тимлид конференции, где все делятся позитивным опытом и обсуждают проблемы (есть шанс, что какой-то другой тимлид уже сталкивался с этой проблемой и может подсказать решение). Все встречи, митапы и вимбоксинги записываем на видео: во-первых, у людей может не быть времени, а во-вторых, даже если время есть, его можно сэкономить, посмотрев запись в ускоренном режиме.
Как вы работаете с инцидентами?
Понятно, что если команда сидит в одной комнате, и вдруг что-то упало, все присутствующие начинают срочно это чинить. В удаленном режиме мы пользуемся инструментом OpsGenie. Если что-то случилось, он сначала звонит ответственному дежурному, потом остальной команде – звонит на телефон, всех собирает, начинаем исправлять.
Наверняка есть нерешенные проблемы!
Да, я рассказал про то, с чем мы уже справились, но на самом деле опросы показывают, что есть вещи, с которыми нам только предстоит разбираться. А именно:
— знать, что происходит в соседних отделах
Если вы будете внедрять удаленную разработку, вы, скорее всего, тоже столкнетесь с этими проблемами.
Инструменты эффективной удаленной работы
Отдельно хочу порекомендовать книгу Remote: Office not Required. Она подробно описывает решение проблем удаленного разработчика, а также там много интересного про организацию командной работы. Ну и комикс в тему.
Ах да, чуть не забыл. Нам в команду всегда нужны крутые full stack, frontend разработчики и не только!