Как довести команду до четырехдневной рабочей недели

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

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

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

Пожары, они были по всюду. Work-Life balance было из разряда ругательств, а работа до поздна и в выходные были так же привычны, как кофе утром.

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

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

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

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

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

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

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

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

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

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

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

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

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

На четырехдневную рабочую неделю мы перешли в середине июля. С тех пор прошло почти пять месяцев.

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

А что же я? Я получил уникальный опыт построения процесса разработки, где разработка не является ограничивающим фактором