Пока ИТ-руководители думают об удаленных и гибридных моделях работы команд и внедряют инструменты для виртуальных встреч и обмена файлами, важно не упустить из виду индивидуальные потребности ценной командной роли — разработчика. Главный архитектор Red Hat Джейсон Дудаш обсуждает на портале Enterprisers Project четыре аспекта, которые необходимо учитывать при обустройстве удаленного рабочего места разработчика.

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

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

1. Специальные инструменты для сотрудничества

Это очевидно, но все же стоит сказать: совместная работа наиболее эффективна, когда инструменты приспособлены для конкретной работы. Например, инструменты управления проектами Jira и Trello отлично подходят для совместной работы с требованиями и задачами. Для разработчиков основными результатами работы являются дизайн и код. Большинство команд уже используют инструменты контроля исходного кода (GitHub и GitLab — два популярных варианта), и это отличный старт для совместной работы над кодом. Однако теперь, когда люди работают удаленно, нужно задаться вопросом: «Достаточно ли этого?».

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

2. Доступ к общим ресурсам для создания и тестирования ПО

Когда я общаюсь с разработчиками, то они часто жалуются: «Мой ноутбук недостаточно мощный». Возможно, это нормально, когда у них есть рабочая станция в офисе или доступ к виртуальной машине (ВМ) в дата-центре, но дома у них этого нет. Дома все не так, как в офисе. Удаленность означает более медленное соединение с оборудованием в офисе и новые требования безопасности для защиты конфиденциальных данных. В таких случаях наличие IDE, способных работать на мощностях дата-центра (или облака) и в рамках утвержденных границ безопасности, поможет устранить неприятные проблемы, которые могут у них возникнуть. Для этого существует много вариантов и даже нативные облачные решения с гибридной поддержкой.

Как это выглядит на практике? Предприятие может предоставлять рабочие пространства через браузерную IDE, например CodeReady Workspaces. Централизация управления рабочими пространствами на базовой платформе типа OpenShift позволяет создавать их с достаточно мощными и готовыми к использованию инструментами, так что все, что разработчику нужно на ноутбуке — это современный браузер. Эта стратегия обеспечивает более высокую производительность по сравнению с ВМ, поскольку соединение осуществляется через веб-сокет, который предъявляет меньшие требования к пропускной способности, чем клиент удаленного рабочего стола, и скорость, поскольку общее ядро контейнеров обеспечивает более быстрый запуск, чем ВМ.

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

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

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

4. Практика DevOps поможет сплотить команды

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

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

Поиск новой удаленной нормы для разработчиков

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