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

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

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

С чего все началось

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

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

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

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

Первые изменения и результаты

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

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

И все пошло не по плану

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

Новая надежда

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

Упорядочиваем коммуникацию

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

Избавляемся от лишних встреч

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

Новые вызовы

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

Эксперимент, который изменил меня

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

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

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

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

Результаты

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

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

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

0
43 комментария
Написать комментарий...
Ника Бабаева

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

Ответить
Развернуть ветку
Елена Славянинова

А рабочая неделя так и осталась 40 часов?

Ответить
Развернуть ветку
Denis Ulyanov
Автор

Нет, мы пришли к 32 часам. На мой взгляд работать 4 дня по 10 часов менее продуктивно, чем работать 5 дней по 8 часов.

Ответить
Развернуть ветку
Уинстон Смит

5 дней по 10 часов тоже неплохо получается

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Никита Важаев

четырехдневка это очень круто конечно

Ответить
Развернуть ветку
Кот отца Пигидия

4 дневная неделя это просто мечта

Ответить
Развернуть ветку
Alexander Marginal

"Планирование и ретро попали под нож и были выкинуты."
- И как работается бе осознанного бэклога? Встречка так то занимает не больше 15 минут при хорошем грумминге.
- А где как не на ретро команда может высказать все свои опасения и переживания и подумать о том, как ее улучшать процессы?
Вы выкинули просто важнейшие встречи, скрам и так оставляет минимум самых важных встреч которые нельзя резать.

"Дейли переработаны и стали встречей, где команда может просто поболтать на фоне графиков."
- Ага, то есть вместо ретро которое для этого создано вы сделали длинные и неинформативные дейлики вместо 5-10 минутных?

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

Ответить
Развернуть ветку
alex b

Теперь мой взгляд как разработчика - я на груминге с командой помог PO выстроить критерии приемки задачи, дал оценку, проверили требования и дополнили их недостающей инфой, задача в бэклоге, потом меня выдирают на планирование где вся команда тупо слушает пока менеджмент решит что из бэклога накидать в спринт, вот лично мне зачем это? Я в этом обсуждении не участвую. Насчет ретро - его функционал можно заменить сбором анонимного фидбека от команды в любое время и проведение ретро когда наберется достаточное число вопросов, а не сидеть заполнять хелсчек раз в спринт, потом писать карточки и мусолить что было решено из прошлого бомбежа, что не решено, потом поделитесь своим мироощущением и как вы во сне покакали радугой. Я на работе работу работать пришел, а не говорильней заниматься, которая не несет полезной нагрузки. Дейли окей, грумминг окей, ретро по итогам обратной связи - окей, но не по 2 часа каждый спринт устраивать этот маразм просто потому что так написано в учебнике по скраму и менеджеру скучно. По итогу типичный рабочий день - только сел поработать, в 10 стартовал дейли, дейли не вписался в таймбокс из-за болтовни не по делу, итого в 10.40 закончили трындеть, в 11 грумминг на час, тоже не вписывается в таймбокс, освободился к часу дня, обед, после обеда начинает названивать тестировщик, которому надо пояснить как тестировать задачу, только сел пописать код по своей таске как на ревью начался холивар, команда собирается решать спорные моменты, по итогу в день хорошо если часа 2 на работу уходит, если это день окончания спринта то вообще вешайся. А через месяц приходят сверху и начинают трахать команду - а почему это дедлайн провафлили и фича не была доставлена юзерам?

Ответить
Развернуть ветку
Alexander Marginal

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

Судя по вашему комменты, вы устраиваете грумминг, ретро и планирование каждый день

Ответить
Развернуть ветку
alex b

Для проставления зависимостей задач друг от друга в Джире есть отличный функционал и флаги, это все выставляется еще на грумминге при оценке и обсуждении задачи. Нет, график у нас другой - грумминг каждый день кроме среды, по часу если верить календарю, по факту больше. Дейли само собой ежедневно, планнинг и ретро раз в спринт. Плюс каждый спринт еще болтовня - спринт ревью где бизнесу команды отчитываются что сделали, по факту можно было провести узким кругом PO от каждой команды, все равно только они презентуют, зачем туда собирать все 150 человек разработки и тестирования - большая загадка. Про ретро я уже писал - есть куча внутренних ресурсов, можно завести еще один куда можно кинуть свою попоболь в виде анонимного письмеца с указанием команды. Собралось 10 таких писем от команды - устраиваем ретро, по итогу окажется что не так много проблем требующих обсуждения и ретро будут проводить раз в 2-3 спринта

Ответить
Развернуть ветку
Alexander Marginal

Менеджеры во время наполнения спринтов редко смотрят в зависимости.
тн ревью спринта - называется демо. И там не нужна вся команда, но желательно конечно чтобы тот кто делал тот и рассказывал плюс давать заказчику самому это все пощупать поткать, а не слайды показывать. Так можно найти проблемные места

Ответить
Развернуть ветку
alex b

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

Ответить
Развернуть ветку
Alexander Marginal

Говорю по себе что код пишу 7 часов в день, в дни когда есть грумминг или ретро - 6

Ответить
Развернуть ветку
alex b

Значит у вас скрам приготовили лучше) У нас творится тот треш что описал выше - работать банально некогда и сейчас я это пишу на очередном созвоне

Ответить
Развернуть ветку
Alexander Marginal

Ну так может быть вам стоит пригласить скрам мастера или отправить на обучение кого-то из команды?

Ответить
Развернуть ветку
alex b

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

Ответить
Развернуть ветку
Alexander Marginal

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey

Ну спорно, спорно. У нас скрам-мастер помог выстроить процесс так, что мы-разрабы тратим не более 5-10 минут в день на синкап, один час раз в два спринта на ретро и час раз в спринт на груминг - всё великолепно работается, мозги не трахаются, человек честно отработал деньги, усовершенствовав процесс

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Marginal

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

Ответить
Развернуть ветку
Andrew U

У нас было так же, как итог - проект утонул

Ответить
Развернуть ветку
alex b

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

Ответить
Развернуть ветку
Alexander Marginal

@channel !!!!

Ответить
Развернуть ветку
alex b

@here !!!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Marginal

Для синхронизации команды

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Marginal

Эм что? Тратится 10-15 минут в прицнипе на дейлик. Никаких на собраться попиздеть.
Ценность - корректировка статусов и ясность кто чем занимается, что было сделано вчера и что будет делаться сегодня.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Marginal

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Marginal

Давай, расскажи мне о своих очень толковых встречах?

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Alexander Marginal

А ты необразованная

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
sheshotov

Дивные комментарии

Ответить
Развернуть ветку
Скрытый Потанцевал

какой смысл ? раз команда может оптимизироваться по времени, значит можно ее сократить и вернуть 40 часов.

Ответить
Развернуть ветку
Алексей Дидух

Денис, ты пишешь ‘мы не стали делать меньше’, а как вы это поняли?

Ответить
Развернуть ветку
Alexander Marginal

В jira же так мало графиков, да?

Ответить
Развернуть ветку
Denis Ulyanov
Автор

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

Ответить
Развернуть ветку
Аля Васильева

Классный кейс! Спасибо. И отличная идея с запретом личных сообщений.

Ответить
Развернуть ветку
40 комментариев
Раскрывать всегда