Информация

Дата основания
2004
Местоположение
США
Сайт
alconost.com
Численность
201–500 человек
Дата регистрации

Блог на Хабре

Обновить
77,14
Рейтинг
Alconost
Локализуем на 70 языков, делаем видеоролики для IT

Семь основных привычек для удаленно работающих команд разработчиков

Блог компании AlconostУправление разработкойУправление проектамиУправление персоналомЛайфхаки для гиков
Автор оригинала: Andrew Scott


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

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

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

Переведено в Alconost

Избыточное общение


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

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

Как это реализовать на практике?

  • Рассчитывайте, что у собеседников нет контекста . Обязательно добавляйте к сообщениям соответствующую предысторию, по своему усмотрению — ссылки на предыдущие комментарии, карточки, цепочки в чатах, — чтобы остальные быстрее поняли, о чем речь.
  • Используйте общедоступные и групповые каналы, а не личные сообщения . Если вам и правда нужно обсудить что-то с одним коллегой, это не означает, что остальным новая информация бесполезна.
  • Используйте в команде и закрытые, и общедоступные чаты. Пользователям Slack я рекомендую настроить закрытый канал и дополнительный общедоступный — если нужно. Я с меньшей вероятностью задам глупый вопрос на форуме с более чем 200 умными (а иногда и бойкими на язык) специалистами, чем в канале, где сидят десять человек, с которыми я общаюсь каждый день.
  • Не волнуйтесь о том, который сейчас час . Сообщайте актуальную информацию как можно оперативнее. Если коллеги хотят, чтобы их не беспокоили, им следует научиться пользоваться такими функциями, как «не беспокоить» и «отключить звук». Поверьте: если я не хочу, чтобы меня беспокоили, меня не побеспокоят.

Групповое (парное) программирование



Я (в реальной жизни)

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

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

  • Остерегайтесь формирования «микрокоманд» ‍♀️. В случае удаленных команд может показаться, что удобно работать в паре с теми, кто находится в близких часовых поясах. Однако этого по ряду причин следует избегать. В случае формирования «микрокоманд» есть риск того, что в проекте появится совокупность знаний и навыков, которые могут казаться хорошими для нескольких участников команды, но в целом будут плохими.
  • Парное программирование — это не всегда хороший выбор ‍♂️. Если вас укусит муха парного программирования, может возникнуть ощущение, что его нужно применять ко всем задачам — и это может оказаться ловушкой: в одних случаях работа в одиночку попросту более эффективна, в других же можно здорово «прокачать» собственные навыки, пытаясь решить какую-то задачу самостоятельно. Прежде чем принимать решение о парном программировании, следует хорошенько всё взвесить.
  • Попробуйте асинхронную работу в парах. Этот вид парного программирования связан со следующим разделом. Смысл в том, чтобы организовать процесс так, чтобы можно было легко передать незавершенную работу коллеге в другом часовом поясе и, вполне возможно, на следующий день снова к ней вернуться.



Подводите итоги за рабочий день


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

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

Что включать в ежедневную сводку?

  1. Состояние проделанной совместной работы на конец рабочего дня. Появились ли какие-то заявки? Есть ли прогресс в проектной документации? Указывайте только основные моменты.
  2. Нерешенные проблемы . Если вы целый день пытались решить текущую проблему, не закончили и решили пойти спать, расскажите о проделанном и надейтесь, что коллеги разберутся с вашей задачей до того, как вы проснетесь завтра.
  3. Почаще радуйтесь сделанному . Это обратная сторона предыдущего пункта: если в конце рабочего дня у вас есть причина порадоваться, поделитесь этим с остальными. Всем нравится начинать день с хороших новостей.

Документируйте рабочие процессы


В этот раздел входят на самом деле две привычки.

  1. Все важные процессы должны быть хорошо документированы и понятны членам команды.
  2. Почаще пересматривайте рабочие процессы и исправляйте их по необходимости.

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

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

Взаимное обучение и подбадривание


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

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

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



Личное знакомство


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

Экспериментируйте ️


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

Не так давно я попробовал несколько решений, который мне понравились:

  • Неофициальная утренняя болтовня за кофе.
  • Постоянно открытый командный видеочат на внеочередных совещаниях.
  • Меняйтесь в роли мастера Scrum.

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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

→ Подробнее
Теги:alconostdistributed teamengineering managementалконостраспределенные командыуправление распределенной командой
Хабы: Блог компании Alconost Управление разработкой Управление проектами Управление персоналом Лайфхаки для гиков
Рейтинг +11
Количество просмотров 6,5k Добавить в закладки 63
Комментарии
Комментировать

Похожие публикации

Лучшие публикации за сутки