Тем кто привык к офисному формату работы удалёнка может показаться даже пугающей перспективой. Но все больше известных компаний отдают ей предпочтение, и роль эффективных инструментов для того чтобы оставаться эффективным вне офиса только растет. В этой статье мы познакомим тебя с инструментами и практиками, полезными в долгосрочной и краткосрочной удаленной работе с крупными и мелкими проектами.
Советы будут разные — от определённого софта и техники до рекомендаций, как укладываться в командные дедлайны.
Начнем с организации рабочего места
Правильно организовать рабочее место очень важно. Это повлияет не только на продуктивность, но и на профессионализм в глазах коллег. Например, чтобы не было посторонних шумов во время созвонов, понадобятся наушники с гарнитурой. Казалось бы, мелочь! Но во время работы на удалёнке они имеют большое значение.
Вот несколько вещей, без которых не получится нормально работать дома.
- Наушники с гарнитурой. Лучше проводные наушники, которые не разрядятся в самый ответственный момент. В наушниках вы будете проводить много времени, так что они должны быть удобные.
- Тихое место для размышлений, где есть возможность уединиться. Особенно если вы живёте с другими людьми или семьёй.
- Стабильное подключение к Интернету или хороший запасной вариант связи. Хотя бы возможность при небольшой аварии с вайфаем пересесть на какое-то время на мобильный интернет. Если у вас постоянно какие-то проблемы со Skype или всё время пропадает соединение, то доверие к вам как к профессионалу в глазах коллег, которые пытаются работать с несколькими удалёнными сотрудниками, может постепенно падать.
- Skype. Он подходит для недолгих созвонов, переписки с клиентами и даже для расслабленного общения в чатах.
- SkypeOut. Через эту программу можно звонить с телефона контактам в Skype. Это очень удобно, особенно когда вы находитесь вдали от компьютера (например, неправильно рассчитали время или у клиента возник какой-то срочный вопрос).
- Электрический чайник. Иногда хочется выпить горячий кофе, не отрываясь от работы.
- Двухлитровая бутылка воды. Для чайника или для утоления жажды. Для длинных рабочих сессий или конференц-звонков.
Возможно, что-то из этого покажется очевидным, но удивительно много удалённых работников упускают из виду подобные вещи. Разработчикам нам нужно тихое место чтобы хорошенько спокойно все обдумать. Удалёнщикам нужно тихое место для созвонов, совещаний, совместного кодинга и так далее. Вероятно, работать с дивана — не самое лучшее решение в долгосрочной перспективе.
Программы
Существует много программных инструментов, которые могут дополнить привычную вам среду разработки и помочь преодолеть сложности удалённой работы. Вот несколько популярных:
- AwayFind хорошо подходит для срочных писем, особенно уведомлений в последний момент перед совещанием. Письма пересылаются в виде обычного SMS.
- Конвертер часовых поясов для работы с клиентами и коллегами со всего мира. Хороши Time And Date’s World Time Clock, Every Time Zone, World Time Buddy или же The Time Now в качестве версии для слабовидящих.
- Chat/IRC чаты для всех участников команды. Чат может быть формальным (например, комната в Campfire) или неформальной в Skype (в стиле «чем проще тем лучше»).
- Баг-трекер заслуживает отдельного раздела, так что о нём – ниже.
Совещания нужно планировать с учётом временных поясов. При получении приглашения важно посчитать их и убедиться, что время получилось правильно конвертировать. Если совещание затрагивает несколько временных зон, стоит указать время по UTC. Небольшое замечание чтобы убедиться, что все друг друга поняли.
Пример из практики.
В крупную Rails-команду приходит новый разработчик, опытный в удалённой работе. Несколько её участников как минимум половину времени проводят на удалёнке, а сложившаяся в команде культура предполагает, что большая часть работы делается вечером. Новый участник предлагает тимлиду создать общий чат, например в Campfire или другом платном сервисе. Несколько недель ничего не происходит, и новичок сам заводит чат в Skype и только для разрабов. Его эксперимент столь успешен, что вся команда переходит на Skype.
Баг-трекинг
Самое главное, о чем может сообщать баг-трекер:
- Над чем я сейчас работаю?
- Что мне нужно сделать для следующего релиза этого софта?
- Что сделала вся команда для этого релиза?
Каждый из этих пунктов выбран неспроста.
Первый помогает реинтегрировать опыт офисной работу в удаленку. В офисе на фоне постоянно присутствует какая-то болтовня, и поэтому всегда есть понимание, кто чем занят. Чётко выраженный маркер в баг-трекере, показывающий: “да, сейчас я работаю вот над этим” может привнести похожее чувство и в удалённую работу.
Второй помогает вернуться в здесь-и-сейчас и четко осознать, какие конкретно баги надо исправить. А третий – отследить кто еще над чем работает и как можно перераспределить нагрузку в случае необходимости.
Коммуникация в команде
Один из самых тяжелых аспектов удаленной работы для очень многих людей. Но проблемы возникают только если пустить дела на самотёк. В офисе здороваешься с кем-то даже пока просто идёшь рабочему месту; коллеги знают, что ты на работе, потому что видят тебя за компьютером, погружённым в процесс.
А вот удалённым работникам приходится громче заявлять о себе! Но если правильно наладить общение, то коллеги будут рядом, на расстоянии одного клика. И никакого хождения из одного угла офиса в другой, катания на лифте и т.д.
Эти советы полезнее удалённым разработчикам из больших команд, но могут подойти и офисным сотрудникам.
Заяви о своём присутствии, не теряйся
В начале дня зайди в IRC (или в тот мессенджер, которым пользуется команда) и поздоровайся, спроси как дела и т.д. Даже если при этом придётся общаться о детях, выходных, спорте или хакинге. Строй деловое общение таким образом, чтобы люди знали, что ты на месте.
“Приступаю к работе”, “Перерыв” и “Скоро вернусь”
Стоит не только обозначить своё присутствие, но и дать команде понять, когда вы не работаете.
Как и в офисе, не надо пропадать без объяснений на целый день, оставляя коллег в недоумении.
Разумно отмечаться с утра (простое “Всем доброе утро” даст людям понять, что вы уже сели за компьютер и готовы приступить к работе над проектом), неплохо также отправлять сообщение “Буду через час”, уходя на обед или перерыв в течение дня. У удалённой работы много плюсов, но один из минусов — когда задаёшь коллеге вопрос и не получаешь ответа. Может, он молчит, потому что он отошёл на полчаса? Или потому что ушёл с головой в задачу и не следит за чатом? А может, он на совещании? Сообщения “Вернусь через …” помогут снять подобные сомнения и сгладят рабочий процесс.
В конце рабочего дня хорошо отправить прощание: “Увидимся завтра” или “Вернусь позже вечером, чтобы доделать…” Как и с “Вернусь через час”, эти сообщения помогают команде понять, на что ориентироваться.
Летучки
Пара слов о летучках. В офисе это обычная практика, да и на удалёнке, как правило тоже. Это просто ещё один способ наладить связь между разработчиками, а также с клиентами.
Во время традиционных летучек обычно задаются вопросы — над чем вы работали вчера, что будете делать сегодня, и есть ли какие-то трудности. Насколько этот формат подходит — зависит от размера команды: если это проект с одним разработчиком, задавать подобные вопросы просто нет смысла.
Насколько часто проводить летучку, зависит от размера команды и сложившейся культуры, но в среднем можно ориентироваться на что-то такое:
- 1-3 разработчика: 2 раза в неделю
- 4+ разработчиков: ежедневно
Все просто: трем разработчикам и так все понятно, все про все в курсе. Но чем больше сотрудников – тем выше вероятность ошибок в командной работе. Двух летучек в неделю для маленькой команды достаточно: корректировка курса происходит быстро, а у разработчиков есть, что сказать на встрече.
Удалённое выкатывание релиза
В зависимости от размера проекта стоит отправлять клиенту результаты либо еженедельно (1-2 разработчика, небольшой проект), либо раз в две недели (3+ разработчика, крупный проект). При таком ритме у разработчиков остаётся достаточно времени, чтобы выполнить весомую часть работы, чтобы клиенту было, на что посмотреть. Ведь технически не подкованные клиенты судят о прогрессе лишь по одному показателю — тому, что они видят на экране…
Важно помнить, особенно при работе с такими клиентами, что зачастую прогресс, который можно показать через пользовательский интерфейс — единственное, что имеет для них значение. Не разбирающихся в технической части клиентов не волнует, что на этой неделе вы написали 500 строчек кода, или что вы упорно трудились над каким-то веб-сервисом; они измеряют прогресс лишь одним показателем — тем, что видят на экране. Дело тут не в том, что работа над бэк-эндом не важна, а скорее в том, что нужно сделать её заметной для клиента.
Потому-то и стоит отправлять результаты как минимум раз в две недели. Срок поменьше зачастую ставит разработчика в неудобное положение: он мог застрять в работе над серверной частью и не успеть доделать интерфейс. Тогда и клиенту показать будет нечего.
И вот здесь пригодятся лучшие практики баг-трекинга. С баг-трекингом клиент знает:
- Что должна делать команда и какие результаты представить.
- Когда это будет готово.
- Была ли работа утверждена клиентом.
Клиент знает, что ожидать от этого релиза, а разработчики знают свой фронт работ.
Хорошо, если команда достаточно опытна, чтобы пользоваться непрерывным развёртыванием и/или Kanban’ом. Но это весьма продвинутые техники, которые больше подходят крупным организациям с сильной, ориентированных на разработчиков культурой. Большинство организаций, где разработка ПО на заказ считается необходимым, но дорогим удовольствием, возможно, не готовы к подобным нововведениям.
Почему? Во-первых, клиенту сложно следить за рядом изменений, которые просят оценить разработчики. Во-вторых, приоритеты меняются слишком быстро, чтобы успеть довести до ума хотя бы что-то.
Рекомендации
Если в новой команде только предстоит внедрить эти практики, то вот список инструментов для организации удалённой работы. Все эти рекомендации не универсальны; и если какой-то инструмент не приглянулся, возможно, где-то есть тот, что лучше подойдёт именно под твои нужды.
- Planscope.io в недельном режиме. Это инструмент для тайм-менеджмента, баг-трекинга и оценки состояния проекта, который ежедневно посылает клиентам уведомление о принятых в работу задачах. Он показывает, как идут дела с точки зрения прогресса и бюджета. Подходит для проектов на 1-4 разработчика.
- App Trajectory — это баг-трекер для маленьких команд, с прицелом на оценку проекта и разбиение его на этапы по 1-2 недели. App Trajectory может подсказать, сколько было сделано за какой этап, сколько этапов осталось до полного завершения. Он хорошо подходит для проектов размером на 2-12 разработчиков.
- Pivotal Tracker — это баг-трекер для клиентов, ориентированный на методологию Agile. Он прекрасно подходит, если вы следуете формальным этапам Agile или работаете над проектом, который исчисляется разработчико-годами.
- FlowDock для чатов. Flowdock обладает некоторыми преимуществами перед обычными IRC или Skype чатами: помимо интеграции с популярными сервисами, он также позволяет ставить теги диалогам, чтобы быстро вернуться к ним позже. FlowDock также ведёт список активностей (проверка кода и т.д.), которые отделены от общих чатов (например, в веб-интерфейсе автоматическое обновление статуса находится слева, а чаты — справа).
- Опять же, для чатов хорош Campfire.
Заключение
В самом начале удаленной работы приходится во многом подстраиваться как разработчику, так и клиенту. Иногда все идет по маслу, а иногда наперекосяк. Но когда всё идёт хорошо, удалёнка может помочь клиентам или сотрудникам решить проблему дефицита специалистов, а также открыть более широкий круг возможностей для разработчиков, живущих вдали от крупных технологических центров или стартап-хабов. Продуктивность разработчиков на удалёнке, работающих с применением лучших практик, может быть очень высока.
Написано по статье How to Work Remotely and Still Be the Best Райана Уилкокса, консультанта и разработчика международных компаний, инженера Toptal и основателя собственного проекта.