Как работать удаленно и оставаться лучшим

Пояс с инструментами удаленного работника

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

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

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

Настройка удаленного или домашнего офиса

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

Вот некоторые инструменты для удаленной работы, которые я считаю необходимыми в своем домашнем офисе:

• Гарнитура . Мне особенно нравятся проводные гарнитуры, потому что они не разряжаются в критические моменты. Вы будете носить его часто, поэтому убедитесь, что вы надели что-то удобное. У меня две гарнитуры iMicro: одна для рабочего стола, а другая в сумке для ноутбука. Как гарнитура в сумке для ноутбука, она обладает двумя замечательными качествами: поскольку она питается от USB, мне не нужно беспокоиться о подзарядке аккумуляторов, и ее очень дешево заменить, если она сломается в моей сумке. На самом деле, я нахожу эту конкретную гарнитуру немного неудобной для длительных конференций; если вы делаете это часто, я рекомендую Corsair Vengeance 2000: удобную беспроводную гарнитуру с аккумулятором, позволяющую работать весь день. (Кстати: ни одна из этих ссылок не является реферальной.)
• Тихое место для размышлений с закрывающейся дверью, особенно если вы живете с другими людьми, и особенно если у вас есть семья.
• Стабильное интернет-соединение или хорошее резервное соединение. Например, у меня есть DSL, и я настроил модем на своем телефоне, если DSL отключается. Если у вас постоянно возникают проблемы со Skype или вы сбрасываете звонки, вы становитесь менее надежным и менее профессиональным в глазах других, которые могут пытаться управлять несколькими удаленными сотрудниками.
• Скайп . Это хорошо для специальных конференц-звонков, обмена мгновенными сообщениями с клиентами или даже для создания чатов с низким уровнем церемоний.
• SkypeOut , который позволяет принимать и совершать звонки со своего телефона на контакты Skype. Это здорово, особенно когда вы находитесь вдали от компьютера и (вы неправильно рассчитали время, у клиента возникла чрезвычайная ситуация и т. д.).
• Электрический чайник . Иногда я хочу горячего кофе, но не хочу нарушать свой поток, чтобы получить его.
• Галлонный кувшин воды . Для чайника или для питья. Для длительных сеансов кодирования или длительных телефонных конференций.

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

Программные средства

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

• AwayFind , который хорош для срочных электронных писем, особенно сообщений в последнюю минуту от участника собрания, поскольку он пересылает их сообщения вам через SMS.
• Конвертер часовых поясов для работы с клиентами и коллегами по всему миру. Мне нравятся мировые часы Time And Date, Every Time Zone, World Time Buddy или The Time Now в более доступной версии для слабовидящих.
• Комнаты чата/IRC для всех членов команды. Это может быть формальный стиль (например, комната у костра) или просто чат в Skype (в стиле Keep It Simple, Silly).
• Баг-трекер — заслуживает отдельного раздела, см. ниже.

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

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

Рекомендации по удаленной работе: отслеживание ошибок

Мне нравится узнавать три вещи из баг-трекера, которым я пользуюсь:

• Над чем я сейчас работаю?
• Что у меня на тарелке для следующего выпуска этого программного обеспечения?
• Каковы результаты всей команды для этой версии программного обеспечения?

У каждого из них есть цель.

Во-первых, «Над чем я сейчас работаю?». Когда вы работаете в обычном офисе, у вас есть фоновая болтовня — это дает вам общее представление о том, чем занимаются все остальные. Явный маркер в системе отслеживания ошибок, указывающий «Да, я активно работаю над этим прямо сейчас», может ввести аналогичный шаблон и ощущение удаленной работы.

Во-вторых, «Что у меня на тарелке для следующего релиза?» означает «За какие ошибки я отвечаю» или «Какие ошибки я обрабатываю». Конечно, в каждой команде есть какие-то споры, но также полезно знать, к кому обратиться, если вы хотите найти ошибку или вам нужна помощь в доработке ваших ошибок для выпуска.

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

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

Я включил некоторые рекомендации для конкретных средств отслеживания ошибок в нижней части поста.

Рекомендации по удаленной работе: общение в команде

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

В офисе, когда вы проходите мимо всех на пути к своему месту, вы немного подшучиваете, люди говорят «Привет». Ваши коллеги знают, что вы на работе, потому что видят вас там, за столом, за работой.

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

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

Сделайте свое присутствие ощутимым: не оставайтесь невидимым

Я почерпнул некоторые из этих идей из подкаста Wide Teams, выпуск 48.

В начале дня зайдите в IRC (или любой другой инструмент, который использует ваша команда) и скажите «Привет» , поболтайте о том, как проходят дни людей, и т. д. и т. д. Даже если это означает, что нужно зайти в IRC и спросить о детях, выходных спортивные команды или хакерство на выходных. Когда люди знают, что вы в настоящее время усердно работаете дома, вы не становитесь невидимым. Стройте отношения и дайте людям знать, что вы рядом .

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

Сообщения «Начальный день», «Время обеда» и «Вернусь»

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

Если вы работаете в команде с несколькими другими разработчиками или управляете удаленными сотрудниками, имеет смысл зарегистрироваться, когда вы начинаете свой рабочий день. Простое «Всем доброе утро», чтобы люди знали, что вы находитесь за своим столом и готовы начать работу над проектом, а не дома или в постели.

Отправка сообщений «Вернусь через 1 час» во время обеденного перерыва или рабочего перерыва в течение дня тоже хороша. Удаленная работа хороша во многих случаях, но один тревожный сценарий заключается в том, что вы задаете коллеге вопрос и не получаете ответа. Они не отвечают, потому что их нет 30 минут? Или потому что они глубоко в зоне и не слушают болтовню? Может на встрече? Сообщения «Вернись…» могут облегчить эти опасения и сгладить рабочий процесс.

Когда вы закончите вечер, дайте людям знать, когда вы вернетесь. Может быть, это «Увидимся утром» или «Приду сегодня вечером, чтобы сделать [x]». Но, как и сообщения «Вернусь через 1 час», они задают определенное ожидание, к которому ваша команда может адаптироваться.

Есть интересный стартап под названием Sqwiggle, который может решить некоторые из этих проблем (хотя сам я еще не пробовал). Помимо фотографирования вас каждые несколько секунд, он также позволяет членам команды щелкнуть ваше изображение, чтобы начать видео-/аудиочат, а также предоставляет компонент текстового чата. Идея изображения состоит в том, чтобы сразу увидеть, находитесь ли вы за своим компьютером или нет. (Нет ничего хуже, чем пытаться пообщаться с кем-то онлайн и не получить быстрого ответа. Он что-то поймал? Глубоко в зоне? Не видите уведомления чата? Прямо сейчас в ванной?). Я слышал о Sqwiggle в эпизоде ​​83 подкаста Wide Teams.

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

Удаленные фриланс-концерты всегда разные. (Это часть привлекательности!) Иногда вас приглашают в существующую команду разработчиков исключительно в качестве пополнения штата. Может быть, эта команда уже какое-то время вместе и, в таком случае, у них уже налажена практика общения.

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

Стендап-встречи

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

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

Как часто вам следует проводить стендап-встречи, зависит от размера и культуры команды. Тем не менее, вот мои рекомендации:

• 1-3 разработчика: 2 стендап-встречи в неделю
• 4+ разработчиков: ежедневные стендап-встречи

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

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

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

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

Удаленное предоставление следующего релиза

В зависимости от размера проекта мне нравятся отчеты, отправляемые клиенту еженедельно для небольших (1-2 разработчиков) и раз в две недели для более крупных (3+ разработчиков) проектов. Этот ритм дает разработчикам достаточно времени для выполнения значительных объемов работы, включая интерфейс (или улучшенный пользовательский интерфейс), чтобы клиент мог его видеть.

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

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

В зависимости от типа программного проекта не все эти клиентские выпуски будут выпущены для широкой публики. Например, если вы работаете над проектом Rails, вы можете захотеть немедленно развернуть утвержденные изменения; с другой стороны, с мобильным приложением вы можете назвать выпуск «1.3a10», но текущий выпуск является лишь частью более широкого набора функций новой версии программного обеспечения 1.3, которая будет развернута позже.

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

1. Что на тарелке команды для этого результата
2. Если это было завершено
3. Если работа одобрена заказчиком.

Клиент знает, чего ожидать от этого релиза, а разработчики знают, какая работа им предстоит.

Если ваша удаленная команда достаточно зрелая, чтобы использовать непрерывное развертывание и/или Канбан, тогда все в порядке. Тем не менее, это очень продвинутые методы, которые больше подходят для организаций с сильной культурой, основанной на разработке. Большинство организаций, в которых разработка программного обеспечения на заказ считается необходимой, но дорогостоящей, вероятно, не готовы ни к одному из этих методов. Почему это? Две вещи, которые я заметил, это то, что клиент не успевает за количеством изменений, которые разработчики хотят, чтобы они рассмотрели , или приоритеты меняются слишком быстро, чтобы разработчики могли выполнить хоть что-то .

Рекомендации

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

• Planscope.io , в еженедельном режиме. Это трекер времени + трекер ошибок + инструмент оценки проекта, который ежедневно отправляет клиентам электронные письма, когда вы работаете над их проектом, и позволяет им видеть, как идут дела с точки зрения прогресса и бюджета. Это отлично подходит для проектов размером 1-4 разработчиков в месяц.
• App Trajectory — это средство отслеживания ошибок для небольших команд, основное внимание в котором уделяется оценке и разбиению проекта на фрагменты (итерации) продолжительностью от одной до двух недель. App Trajectory может сообщить вам, какой объем работы вы выполняете за одну итерацию и сколько итераций нужно выполнить, пока не будет завершена вся известная работа. Это отлично подходит для проектов размером от 2 до 12 разработчиков в месяц.
• Pivotal Tracker — это инструмент отслеживания ошибок для клиентов, специализирующихся на методологиях Agile. Это здорово, если вы выполняете формальные итерации Agile или размер проекта измеряется в разработчиках/годах.
• FlowDock для чата. Flowdock предлагает некоторые преимущества по сравнению с простым чатом IRC или Skype: помимо интеграции с популярными сервисами, он также позволяет вам помечать разговоры для быстрого ознакомления позже. FlowDock также хранит список статусных действий (проверки кода и т. д.), которые отделены от обычных чатов. (То есть в веб-интерфейсе автоматические обновления статуса слева, а чаты справа.)
• Опять же, Campfire также отлично подходит для чата.

Заключение

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