Отправить своих разработчиков на удалёнку — полбеды. Вопрос в другом: как потом с ними работать? Ищите в нашей статье 15 рекомендаций, которые помогут бизнесу получить максимальную выгоду от такого сотрудничества.
Удаление разработчиков из офиса — выгодное, распространённое решение для бизнеса. Частично или практически полностью компании переводят специалистов из штата на удалёнку или, вообще, ищут работников для таких видов работ изначально.
В особенности удаление из офиса популярно в сфере IT, где профессиональные качества разработчиков важнее их очного присутствия в бизнес-центре. Больше того, специалисты могут быть из разных городов или стран, из-за чего организовать им всем единовременное пребывание где-либо проблематично.
И в этом кроется первая сложность.
Выбор каналов связи
Важный момент. Необходимо не только вкладываться в обеспечение этой возможности, но и самостоятельно прививать культуру коллективных встреч (звонков), а также участвовать (либо найти хорошего продукт-менеджера) в обсуждениях команды.
1. Первое, что нужно сделать, — начать использовать таск-менеджер. Один из наиболее популярных — Jira, однако это, скорее, рекомендация, чем обязательное для всех ПО.
Лучше всего, если в карточках разработчики также будут указывать важные мелочи. Например, сложности или причины задержки. Чем больше информации будет у остальных членов команды, тем ниже шанс, что кто-то недопоймёт ситуацию.
2. По той же причине рекомендуется выбирать для связи чаты или другие групповые каналы, а не приватные диалоги в соцсетях или мессенджерах. Ещё один важный момент — своевременное оповещение о проблемах.
Особенно это актуально для команд, разработчики которой находятся в разных часовых поясах. Не нужно бояться писать о сложностях в любое время. Если человек отдыхает, он может отключить звук, чтобы не отвлекаться. А кто-то может помочь и подсказать даже в свой выходной, что сэкономит время команды в будущем.
Хороший вариант — сделать поэтапную систему оповещений. Для этого можно использовать, например, бесплатный инструмент Opsgenie. Если нашёлся какой-то баг или что-либо упало — ответственному разработчику приходит оповещение. В случае отсутствия какого-либо ответа в течение 5–10 минут то же оповещение приходит уже всей команде.
Предположим, в течение 15–20 минут ничего не исправляют, происходит звонок на телефон менеджера по продукту. Через полчаса — уже руководителю (если проблема осталась, конечно). Каждый этап автоматизирован.
Важный момент. Такая система должна обязательно учитывать приоритет проблемы. Если она несрочная, не стоит беспокоить разработчика до начала его рабочего дня. В случае, когда упало что-то важное (особенно перед релизом или же после него) — можно писать и звонить даже ночью.
А ещё, в идеале, необходимо выделить хотя бы 4 часа, когда команда будет онлайн в полном составе. Для этого нужно найти плюс-минус удобный для всех часовой пояс и предварительно договориться с участниками.
Регулярные обсуждения результатов
Необходимы. Это не только рационализирует процесс работы, но и даёт команде полное представление о том, что происходит с продуктом, что важно во время работы на удалёнке.
3. Совершайте ежедневные звонки с целью контроля работы руководителем (или продукт-менеджером), а также обмена информацией о процессах. Спрашивайте всё: как идут дела, были ли проблемы, есть ли какие-то идеи, беспокоит ли что-то членов команды и т. д. Задавайте открытые вопросы, т. е. такие, на которые разработчики не смогут ответить односложно или просто «да, нет».
Включайте в свои беседы аналитика. Разработчики должны всегда быть в курсе того, как пользователи воспринимают продукт, что нравится и не нравится людям, какие моменты необходимо отредактировать, оптимизировать или убрать вообще.
4. Обсуждайте возможные планы на завтрашний день. Старайтесь заранее рационально распределить работу, чтобы команда не тратила на это время с утра (особенно, если люди живут в сильно различающихся часовых поясах).
Организация внутри команды
Один из самых сложных моментов, т. к. требует постоянного присутствия, проявления лидерских способностей и психологической работы с разными по характеру (а иногда и менталитету) специалистами.
5. Следите за тем, чтобы внутри команды не формировались микрогруппы. Это вредит общему делу, хотя и кажется поначалу вполне удобным. Особенно если разработчики группируются по часовым поясам или специализации. Проблема в том, что остальные могут недополучать информацию о процессах работы или же отставать от группы, где профи объединены.
6. Если разработчики всё-таки начинают сбиваться в группы и вы не в силах это остановить, предложите им иногда меняться парами или представителями их мини-команд.
Асинхронное групповое программирование поможет не только держать всех разработчиков в курсе дел, но и позволит им учиться новому, обмениваться релевантным опытом и лучше узнавать своих коллег.
Помните, что между командой и группой есть разница. Команда находится в общем поле, а у её участников есть единая цель, которую все сотрудники осознают и пытаются достичь коллективно. Члены команды дополняют друг друга и ощущают ответственность не только за себя, но и за других.
Люди вовлечены и доверяют друг другу. Это позволяет им разговаривать даже на сложные профессиональные темы, признавать свои ошибки и говорить о некомпетентности в каких-то вопросах открыто.
В процессе работы в команде сотрудники не держатся за условное лидерство, а легко передают его другим во благо общей цели. При этом основной руководитель команды не выделен, хотя технически присутствует и выполняет свои функции (однако решения в итоге принимают все члены команды).
Эмоциональная работа с командой
Поможет избежать проблем «на пустом месте».
Для этого нужно придерживаться хотя бы двух простых рекомендаций.
7. Позвольте разработчикам говорить. Да, конечно, не стоит затягивать групповые звонки, но если вы видите, что кто-то из участников способен поделиться важными знаниями по продукту или сфере — позвольте ему передать эту информацию, а лучше задайте вопросы сами.
8. Не стесняйтесь радоваться. Напоминайте своим разработчикам, что они молодцы, если это действительно так. Это можно делать в конце звонка, во время рассылок или при комментировании карточек.
Всем будет приятно услышать похвалу и благодарность за проделанную работу. Это позитивно скажется не только на лояльности специалиста, но и на общем боевом духе. Главное, хвалить за дело. Всех в равной степени.
Если вы видите потенциал для роста какого-то разработчика, помогите ему развиться. Внедрите в команду улучшение, которое обеспечит более высокую слаженность и производительность команды. Так, в полной степени, сможет раскрыться не один специалист, а, может быть, и кто-то ещё.
Техническая работа с командой
Требует от руководителя, тимлида или продукт-менеджера наличия хотя бы базовых знаний в области разработки. Это не всегда просто организовать, однако без соблюдения следующих пяти пунктов риск не успеть сделать всё в срок (а также риск пост-релизных проблем с продуктом) резко растёт.
9. Валидируйте код даже если изменения в нём небольшие. В идеале это необходимо делать самостоятельно, в крайнем случае — можно поручить штатному сотруднику. Например, тимлиду, руководителю проекта, продукт-менеджеру и т. д. Это профилактика возможных проблем внутри и вне команды (рефакторинг после передачи проекта клиенту).
10. Придерживайтесь стандартов. Например, PSR. Это необходимо, чтобы масштабировать ресурсы, а также оперативно и легко подключать (или заменять) участников команды.
11. Распределяйте нагрузку рационально. Пусть каждый работает в том направлении, в котором хорош. Для того, чтобы знать правильные векторы, говорите с разработчиками перед наймом и давайте им тестовые задания по указанным в резюме направлениям.
12. Делайте автотесты. Как минимум на всём критическом функционале крупных проектов (можно привлекать другие организации или тестировщиков-аутсорсеров). Как правильно проводить QA-тестирования, вы можете прочитать здесь.
13. Используйте чек-листы. Это профилактика риска временных и финансовых потерь. Чек-листы позволят проверить, точно ли команда выполнила все задачи и насколько хорошо она это сделала.
Погружение в работу и удержание специалистов
Последние два аспекта неочевидны, но очень важны в работе со специалистами на удалёнке. Их выполнение — вклад в перспективу: безопасность и финансовую стабильность компании в будущем.
14. Необходимо контролировать не только решения и процесс работы команды, но и технологии, которые они применяют. Это нужно, чтобы компания смогла доработать продукт или оптимизировать его самостоятельно, если специалист откажется от дальнейшего сотрудничества.
Важно понимать, как реализована та или иная система.
Это позволит в дальнейшем не тратить время и деньги на её анализ.
15. Постарайтесь удержать сотрудника как можно дольше. Дело не только в том, что поиск хорошего специалиста занимает какое-то время и стоит немалых денег. Это может банально сорвать проект. Представьте, что вы рассчитываете на определённого человека, а он отказывается от сотрудничества. При этом договор с заказчиком уже подписан.
К тому же не все люди добросовестны. Вместе с разработчиком компанию покидают знания о внутренних технологиях, продукте, процессах работы и т. д., что может быть использовано конкурентами.
Для того, чтобы специалисты не убегали от нанимателя, нужно обеспечить им:
- комфортные условия работы;
- приятный психологический микроклимат в команде;
- возможность расти, учиться и развиваться;
- адекватную на современном рынке IT оплату труда.
Ещё один вариант разрабатывать что-либо без сотрудников в офисе — аутсорс. Кстати, о плюсах и минусах этой системы работы читайте здесь.
Но, вообще, просто переведите специалистов на удалёнку.
И удалите проблемы из своей жизни.