Многие разработчики были бы не против перейти на 4-дневный рабочий график. А некоторые даже добавляют это к условиям в своем резюме. Мы пообщались с Software Engineering Manager Алексеем Токарем, который ввел в своем инженерном отделе такую практику. А также с несколькими разработчиками этого отдела, которые уже давно работают на 4-дневке. Расспросили, как прошел переход на новый график, какие проблемы возникли, как это повлияло на результаты работы, производительность команд и зарплаты сотрудников, а также о плюсах и минусах подобной схемы для сотрудников.
Начинал я как руководитель разработки, а через полтора года возглавил весь инженерный департамент. Я отвечал за стабильность системы, развитие персонала и взаимодействие как в своем отделе, так и в компании. Наши продуктовые менеджеры часто задавали вопросы о производительности труда: почему так мало сделано или почему так медленно. Они всегда хотели больше, выше, веселее. Измерять производительность разработчиков в компании начинали с субъективной оценки. Потом решили ввести формальные показатели, то есть измеряли статистический объем работ, которые команда может выполнить за период времени. По сути, оценка стала сводиться к соотношению запланированного объема работы к фактически выполненному.
Одна из задач, которая передо мной стояла и решалась разными способами на протяжении 5 лет, — повышение предсказуемости поставки продуктов в продакшн и объемов производимой продукции. Добивались этого в основном техническими инструментами, связанными с измерениями Software Development Life Cycle. Например, автоматизировали этапы, изменили технологические карты взаимодействия отделов, а также структуры отделов, приоритетность задач, инструменты для их решения. Одним из способов достижения этой цели стал и 4-дневный рабочий график.
Посчитать, сколько часов инженер разрабатывает, сложно. Нельзя сказать, что с 9 утра до 6 вечера он непрерывно приносит пользу компании. С другой стороны, когда приходишь домой, не всегда удается переключиться в режим «все, больше не работаю и решения не принимаю». Иногда идеи появляются вечером в душе или утром во время чистки зубов. Соответственно, это тоже рабочее время.
Исходя из этих размышлений, я предложил в качестве эксперимента ввести 4-дневный рабочий график. Выбрал для этого одну команду, которая показывала более-менее стабильный и предсказуемый результат, и решил попробовать улучшить его еще больше. Задумано все было так: у команды есть две недели разработки, если за это время она выполняет все задачи, то на протяжении следующих двух недель получает два дополнительных выходных.
Если вместе с дополнительными выходными команда снова выполняет запланированный объем, то получает еще два выходных на следующие две недели. А если не успевает справиться с поставленными задачами, то на следующие две недели возвращается на 5-дневку. Зарплата сотрудников не меняется.
Мы ввели правило, что выполнение одной задачи не должно превышать двух рабочих дней у инженера, то есть все таски в спринте должны быть небольшими. Чем меньше задачи, тем более конкретные требования к ним можно выставить и тем более предсказуемо их выполнение. Для оценивания использовали Burndown charts. Когда команда из 8–12 человек выполняет двухдневные задачи, график плавно опускается к концу спринта. Если сроки выполнения завышены, кривая опускается резко, а до конца спринта остается ровная линия. Если же команда переоценила свои силы, это тоже будет видно на диаграмме. Мы решили: если на Burndown charts кривая отходит от нормы, это повод встретиться с руководителем команды и проговорить конкретные задачи.
Мы начали эксперимент в июле 2019 года. Сначала было больно: за первые два месяца команда получила только две недели с дополнительными выходными. Все остальное время что-то не получалось, сотрудники не успевали полностью справляться с поставленными задачами. Больше всего страдали самые ответственные, потому что они не могли допустить срыва объёмов. Как результат — работа по вечерам и иногда выходным. Даже когда специалисты отдыхали в пятницу, они продолжали работать, чтобы успеть. Но на третий месяц люди адаптировались и практически целый месяц работали на 4-дневке. В конце квартала мы провели ретроспективу — и ребята сказали, что им нравится такой график.
Кроме того, что мы продолжали выполнять тот же объем работы, который всегда был на 5-дневке, оказалось, что предсказуемость результата выросла на 10%. Если раньше команда могла гарантировать результат на 80–90 %, то при 4-дневке эти показатели выросли до 92–95%.
Самое важное в переходе на новый формат — договориться на берегу о правилах игры. Например, когда все задачи сделаны, но не протестированы, считается ли, что они выполнены? А если протестированы, но недоступны конечными пользователям? Все эти нюансы мы прописали. По окончанию эксперимента у нас появился документ с четкими критериями, которые могли использовать другие команды.
С ноября 2019-го мы перевели на 4-дневный рабочий день остальные четыре инженерные команды, которые занимаются развитием продукта.
Тяжелее всего это давалось самым ответственным людям в компании, потому что они не могли просто все бросить и ничего не делать в дополнительные выходные. Тимлиды сильно переживали и выходили на работу по пятницам, чтобы успеть закрыть задачи в 8-дневном спринте и гарантировать таким образом и следующие два выходных. Со временем все адаптировались. Переход на 4-дневку помог наладить работу внутри команд: ребята поняли, в каких процессах проблемы, и смогли их исправить. Обычно команды со слабыми процессами не умеют правильно встраиваться в цепочку поставки задачи, если в ней работают специалисты разных областей, например разработчики и QA. Иногда они теряют баланс и набирают задач для разработчиков, а тестировщикам нечем заниматься, зато в следующем спринте все происходит наоборот, и зашиваются уже QA.
Подход к 4-дневному графику в компании тоже изменился. Изначально концепция была такая: если сотрудники выполняют заявленный объем работы, они выбирают два любых выходных дня. Ребята экспериментировали, выбирая, например, пятницу и понедельник следующей недели выходными, чтобы иметь 4 выходных подряд. Пробовали делать выходной в среду, чтобы отдыхать посреди недели. Но в результате все команды пришли к тому, что идеальный вариант — брать выходной в пятницу и стабильно отдыхать три дня в неделю.
Внутри компании этому появилось название «пятничка» и соответствующие фразы: «А ты заработал пятничку?» или «Что ты сделал ради пятнички?». Все подхватили это, и «пятнички» стали частью культуры компании.
Внедрить новую схему работы в инженерные команды, которые занимаются поддержкой и инфраструктурой, было сложнее. Они взаимодействуют с пользователями напрямую и не могут не предоставлять услуги по пятницам. Поэтому для них мы придумали другую модель: в дополнительный выходной на дежурстве оставался один человек, все остальные работали 4 дня. Каждый раз дежурные в команде менялись.
Когда мы внедрили систему в остальных инженерных командах, менеджмент начал задавать вопросы, как еще можно оптимизировать процесс. Ребята работают 4 дня в неделю и делают 100% результата, а если будут работать 5 дней в неделю, может, будут все 120%? Финансовый менеджмент при этом спрашивал, почему мы продолжаем платить сотрудникам так, как раньше, если они работают на 20% меньше. Приходилось вести переговоры и объяснять, что загнанный инженер — это плохой инженер, что выгоревшие работники не дадут результатов. Примерно через год топ-менеджмент перестал приходить с такими вопросами, а последний год мы «летели» на 4-дневке в автономном режиме.
Еще один косвенный эффект — снизилось количество багов в продакшене, а предсказуемость релизных циклов увеличилась. Мы долго работали над этими проблемами, а эксперимент с графиком помог их решить и привел к прекрасному результату.
Из глобальных изменений в компании — пятница стала днем без встреч. Даже если периодически какие-то команды не вкладываются в сроки и работают 5 дней в неделю, у них все равно нет встреч по пятницам.
Важно добавить небольшую предысторию о том, как мы закрывали спринты. Команда в целом справлялась с большинством запланированных задач, но частыми были случаи, когда разработчики сделали задачу, тестировщики не успели протестировать, и ее приходилось переносить на следующий спринт. Поэтому сначала члены команды не были уверены, что мы сумеем справиться со всем объёмом за 4 дня вместо 5. Но все-таки решили попробовать.
Первый экспериментальный спринт команда закрыла на 70%, а для того, чтобы получить дополнительные выходные, надо было выполнить более 90% задач. Я думал, что это может демотивировать ребят, но все, наоборот, собрались, сделали выводы и следующий спринт закрыли успешно и получили 4-дневку. Это нереально воодушевило команду, и в следующий спринт мы опять выполнили все вовремя.
Четвертый спринт завалили и после этого на ретроспективе начали обсуждать, что делаем не так и как нам получить наши «пятнички». Эти обсуждения привели нас к пересмотру процессов работы, таким образом 4-дневка потянула за собой ряд улучшений: мы начали вырабатывать командные практики, которые бы позволили улучшить результаты. Например, решили разбивать большие задачи на маленькие. Если есть задача, которая занимает больше 10% всего спринта, это сигнал о том, что она может застопорить команду. Ее нужно подробить.
Также договорились, что в спринт нельзя брать таски, которые друг от друга зависят: если кто-то один застопорится на первой задаче, второй тоже не успеет выполнить свою. И все это может привести к провалу спринта.
Я тоже часто овертаймил. Стоит сказать, что я работаю в компании уже 14 лет и воспринимаю продукт как свой. К тому же живу за городом, поэтому в доковидные времена, чтобы не стоять в пробках, приезжал в офис на 7 утра, а если не успевал уехать домой до 5 вечера, оставался здесь допоздна. Иногда проводил в офисе по 12 часов. Поэтому не могу сказать, что причина переработок была только в 4-дневки, но действительно бывали ситуации, когда понимал, что нужно поднажать, чтобы команда получила свои «пятнички». Но это не доставляло мне дискомфорт.
Даже когда команда получала дополнительные выходные, я все равно работал практически каждую пятницу. В основном из дому, в свободном графике во время, свободное от семейных и личных дел. Это не были полноценные рабочие дни: я просыпался не так рано, как обычно, мог пойти в зал или посмотреть сериал, заняться личными делами и немного поработать. При этом от меня этого никто не ожидал, это было необязательно.
Поскольку обязанности тимлида занимали у меня практически все рабочее время, свободных часов на разработку не оставалось. А работа по «нерабочим» пятницам дала возможность программировать в свое удовольствие.
Минусов лично для себя не вижу.
Ни для кого не секрет, что программисты не работают по 8 часов в день. Если хотя бы 50–60% рабочего времени уходит на работу, то это хорошо. Я не считаю, что это плохо, это просто факт. А переход на 4-дневку означает, что работать надо более сфокусировано и не так много прокрастинировать. Думаю, что для людей, обладающих высокой самоорганизацией, это не было проблемой. Но кто-то все-таки мог ощутить, что нагрузка стала более интенсивной. Знаю, что некоторые ребята из команды начали интересоваться инструментами для повышения продуктивности, завели личные Trello или Todoist и пытались меньше прокрастинировать. По моим наблюдениям, у них это неплохо получается. Я не испытывал с этим трудностей, так как уже давно пользуюсь личным Trello, где каждый день завожу таски для себя.
И в целом мы в команде выработали правило, что если не успеваем выполнять задачи, то никто не обязан овертаймить, чтобы успеть. Для нас это значило, что нужно посмотреть на ретроспективе, где были проблемы, которые привели к незакрытию спринта. Так что в целом переработки, если и были, то по личному желанию каждого сотрудника.
Адаптация к новому режиму заняла примерно 2–3 месяца, то есть 4–5 спринтов (они у нас двухнедельные). Как по мне, чтобы полностью приспособиться, важно поработать в новом графике и новом темпе хотя бы несколько спринтов. Если они короче или длиннее, то и адаптация может занять другое количество времени.
Также команда становится более нацеленной на результат, поскольку если спринт не закрыт вовремя, то и 4-дневки в следующем спринте не будет. Все в команде это понимают, соответственно работа идет более бодро.
Одним из главных минусов является то, что иногда в погоне за 4-дневкой может теряться качество выполнения задач. Это важно замечать и исправлять такой подход, потому что это может демотивировать членов команды.
Не могу сказать, что при 4-дневке чувствую бОльшую нагрузку, чем при 5-дневке. Как мне кажется, это сильно зависит от человека. Для себя я просто выработал подход, при котором имею чуть больше рабочей нагрузки каждый день, но это не дает ощущения большой загруженности в целом. Этому есть две причины.
Во-первых, выполнение того же количества задач за меньшее время требует бОльшей концентрации. То есть просто меньше времени тратится впустую (хотя и без этого никуда). А во-вторых, рабочие дни и дни отдыха распределены более равномерно — 4/3 дня вместо 5/2. В целом благодаря этому ощущаю себя более отдохнувшим и заряженным.
К тому моменту, когда схема показала себя хорошо и ее распространили на другие команды, уже стало интересно попробовать «пятнички».
При традиционном планировании спринта получить первые дополнительные выходные оказалось нетрудно. Мы успешно закрыли его и получили возможность отдыхать по пятницам. Но повторить результат уже оказалось сложнее — и следующие три-четыре спринта мы «провалили» и работали 5 дней.
Постепенно команда поняла: чтобы выполнить пятидневный объем работ за четыре дня, нужно переводить планирование процессов на новый уровень, чтобы даже незапланированная работа получила свою оценку.
Иногда овертайм означает пару часов работы на выходных, иногда — перегруженный будний день. Но дополнительный выходной, как правило, позволяет восстановиться, в итоге получаешь больше, чем теряешь.
Два-три месяца — и ты «на крючке» у дополнительного выходного.
Значительный плюс — дополнительный выходной в будний день. Это позволяет или разгрузить выходные от рутинной домашней работы, или запланировать что-то «нестандартное» на пятницу.
Из минусов — более плотные (иногда и более длинные) рабочие дни, жизнь по запланированному расписанию. Также чувствуется более сильная нагрузка. Если не следить за рабочими часами, еcть риск выгореть. Хочется верить, что это промежуточная «фаза эволюции» к чистым четырем рабочим дням, ведь по опыту зарубежных коллег уже статистически доказано, что три выходных позволяют как лучше отдыхать, так и лучше работать. То есть, даже не втискивая пять рабочих дней в четыре, можно достичь успеха.
dou.ua
Software Engineering Manager — о внедрении 4-дневного рабочего графика
Алексей Токарь работает в IT уже 17 лет. До 2021 года был Software Engineering Manager в американской компании FORM.com с инженерным отделом в Киеве. Перевести одну из команд своего отдела на 4-дневную рабочую неделю он решил в 2019 году в качестве эксперимента. Сейчас весь инженерный отдел работает по такому графику.Цель 4-дневки — повысить предсказуемость работы команд
Последние 5 лет я работал в FORM.com — продуктовой компании из США, которая предоставляет бизнес-решения для инспекций и аудита. Главный офис и отдел продаж находится в США, а инженерный отдел на 80 человек — в Киеве. Здесь все наши разработчики, тестировщики, сисадмины.Начинал я как руководитель разработки, а через полтора года возглавил весь инженерный департамент. Я отвечал за стабильность системы, развитие персонала и взаимодействие как в своем отделе, так и в компании. Наши продуктовые менеджеры часто задавали вопросы о производительности труда: почему так мало сделано или почему так медленно. Они всегда хотели больше, выше, веселее. Измерять производительность разработчиков в компании начинали с субъективной оценки. Потом решили ввести формальные показатели, то есть измеряли статистический объем работ, которые команда может выполнить за период времени. По сути, оценка стала сводиться к соотношению запланированного объема работы к фактически выполненному.
Одна из задач, которая передо мной стояла и решалась разными способами на протяжении 5 лет, — повышение предсказуемости поставки продуктов в продакшн и объемов производимой продукции. Добивались этого в основном техническими инструментами, связанными с измерениями Software Development Life Cycle. Например, автоматизировали этапы, изменили технологические карты взаимодействия отделов, а также структуры отделов, приоритетность задач, инструменты для их решения. Одним из способов достижения этой цели стал и 4-дневный рабочий график.
Посчитать, сколько часов инженер разрабатывает, сложно. Нельзя сказать, что с 9 утра до 6 вечера он непрерывно приносит пользу компании. С другой стороны, когда приходишь домой, не всегда удается переключиться в режим «все, больше не работаю и решения не принимаю». Иногда идеи появляются вечером в душе или утром во время чистки зубов. Соответственно, это тоже рабочее время.
Исходя из этих размышлений, я предложил в качестве эксперимента ввести 4-дневный рабочий график. Выбрал для этого одну команду, которая показывала более-менее стабильный и предсказуемый результат, и решил попробовать улучшить его еще больше. Задумано все было так: у команды есть две недели разработки, если за это время она выполняет все задачи, то на протяжении следующих двух недель получает два дополнительных выходных.
Если вместе с дополнительными выходными команда снова выполняет запланированный объем, то получает еще два выходных на следующие две недели. А если не успевает справиться с поставленными задачами, то на следующие две недели возвращается на 5-дневку. Зарплата сотрудников не меняется.
Использовали Burndown charts, чтобы избежать рисков
Единственный риск для компании был в том, что сотрудники могли специально занижать объем работы. Каждая команда самостоятельно оценивает объем задач, которые может выполнить. Чтобы избежать таких нюансов, я использовал инструменты ненавязчивого контроля и плотно работал с руководителями команд.Мы ввели правило, что выполнение одной задачи не должно превышать двух рабочих дней у инженера, то есть все таски в спринте должны быть небольшими. Чем меньше задачи, тем более конкретные требования к ним можно выставить и тем более предсказуемо их выполнение. Для оценивания использовали Burndown charts. Когда команда из 8–12 человек выполняет двухдневные задачи, график плавно опускается к концу спринта. Если сроки выполнения завышены, кривая опускается резко, а до конца спринта остается ровная линия. Если же команда переоценила свои силы, это тоже будет видно на диаграмме. Мы решили: если на Burndown charts кривая отходит от нормы, это повод встретиться с руководителем команды и проговорить конкретные задачи.
Сначала было больно
Эксперимент должен был длиться три месяца. Если он удачный, команда не выгорает, а я вижу, что это помогает повысить предсказуемость производительности, продвигаю эту идею руководству. Если «наверху» претензий нет, внедряем 4-дневку в других командах инженерного департамента.Мы начали эксперимент в июле 2019 года. Сначала было больно: за первые два месяца команда получила только две недели с дополнительными выходными. Все остальное время что-то не получалось, сотрудники не успевали полностью справляться с поставленными задачами. Больше всего страдали самые ответственные, потому что они не могли допустить срыва объёмов. Как результат — работа по вечерам и иногда выходным. Даже когда специалисты отдыхали в пятницу, они продолжали работать, чтобы успеть. Но на третий месяц люди адаптировались и практически целый месяц работали на 4-дневке. В конце квартала мы провели ретроспективу — и ребята сказали, что им нравится такой график.
Кроме того, что мы продолжали выполнять тот же объем работы, который всегда был на 5-дневке, оказалось, что предсказуемость результата выросла на 10%. Если раньше команда могла гарантировать результат на 80–90 %, то при 4-дневке эти показатели выросли до 92–95%.
Самое важное в переходе на новый формат — договориться на берегу о правилах игры. Например, когда все задачи сделаны, но не протестированы, считается ли, что они выполнены? А если протестированы, но недоступны конечными пользователям? Все эти нюансы мы прописали. По окончанию эксперимента у нас появился документ с четкими критериями, которые могли использовать другие команды.
С ноября 2019-го мы перевели на 4-дневный рабочий день остальные четыре инженерные команды, которые занимаются развитием продукта.
Все команды столкнулись с овертаймами
Вначале около половины работников настороженно относились к новому графику, потому что не до конца понимали, как это работает. Кто-то зарабатывал два выходных, а кто-то нет. Все команды столкнулись с однотипными проблемами — прежде всего с овертаймами. Часто некоторым людям приходилось работать в один из дополнительных выходных, потому что они не успевали закрыть все задачи. Кто-то доделывал их в субботу и воскресенье. Это негативно сказывалось на этих сотрудниках, они возмущались, что работают на выходных, пока остальные отдыхают.Тяжелее всего это давалось самым ответственным людям в компании, потому что они не могли просто все бросить и ничего не делать в дополнительные выходные. Тимлиды сильно переживали и выходили на работу по пятницам, чтобы успеть закрыть задачи в 8-дневном спринте и гарантировать таким образом и следующие два выходных. Со временем все адаптировались. Переход на 4-дневку помог наладить работу внутри команд: ребята поняли, в каких процессах проблемы, и смогли их исправить. Обычно команды со слабыми процессами не умеют правильно встраиваться в цепочку поставки задачи, если в ней работают специалисты разных областей, например разработчики и QA. Иногда они теряют баланс и набирают задач для разработчиков, а тестировщикам нечем заниматься, зато в следующем спринте все происходит наоборот, и зашиваются уже QA.
Подход к 4-дневному графику в компании тоже изменился. Изначально концепция была такая: если сотрудники выполняют заявленный объем работы, они выбирают два любых выходных дня. Ребята экспериментировали, выбирая, например, пятницу и понедельник следующей недели выходными, чтобы иметь 4 выходных подряд. Пробовали делать выходной в среду, чтобы отдыхать посреди недели. Но в результате все команды пришли к тому, что идеальный вариант — брать выходной в пятницу и стабильно отдыхать три дня в неделю.
Внутри компании этому появилось название «пятничка» и соответствующие фразы: «А ты заработал пятничку?» или «Что ты сделал ради пятнички?». Все подхватили это, и «пятнички» стали частью культуры компании.
Внедрить новую схему работы в инженерные команды, которые занимаются поддержкой и инфраструктурой, было сложнее. Они взаимодействуют с пользователями напрямую и не могут не предоставлять услуги по пятницам. Поэтому для них мы придумали другую модель: в дополнительный выходной на дежурстве оставался один человек, все остальные работали 4 дня. Каждый раз дежурные в команде менялись.
Топ-менеджмент поддержал идею
Я пришел к топ-менеджменту с идеей о 4-дневке с четким объяснением, как это поможет компании. Поскольку предсказуемость работы команд важна для полугодичного, годичного и долгосрочного планирования компании, я показал, как благодаря новому графику мы можем выполнять тот же объем с более предсказуемым результатом. Руководство поддержало идею.Когда мы внедрили систему в остальных инженерных командах, менеджмент начал задавать вопросы, как еще можно оптимизировать процесс. Ребята работают 4 дня в неделю и делают 100% результата, а если будут работать 5 дней в неделю, может, будут все 120%? Финансовый менеджмент при этом спрашивал, почему мы продолжаем платить сотрудникам так, как раньше, если они работают на 20% меньше. Приходилось вести переговоры и объяснять, что загнанный инженер — это плохой инженер, что выгоревшие работники не дадут результатов. Примерно через год топ-менеджмент перестал приходить с такими вопросами, а последний год мы «летели» на 4-дневке в автономном режиме.
4-дневка сплотила команды и помогла наладить процессы
Самым сложным в переходе на новый график было настроить взаимодействие внутри команд. Когда ребята стали нацелены на командный, а не индивидуальный результат, начали менять процессы для командной, а не индивидуальной работы. В итоге мы получили крутые результаты. Стало намного легче и быстрее масштабироваться, нанимать новые группы разработки и получать от них результаты. Если раньше онбординг команд занимал 6 месяцев, то после перехода на 4-дневку он сократился до полутора месяцев. Описанные выгоды получены не из-за четырехдневки, а благодаря изменениям, которые она нам принесла. Новый график стал мотивацией, за которой подтянулись все остальные нужные изменения. Это можно сделать и другими методами, но у нас этот сработал намного лучше остальных.Еще один косвенный эффект — снизилось количество багов в продакшене, а предсказуемость релизных циклов увеличилась. Мы долго работали над этими проблемами, а эксперимент с графиком помог их решить и привел к прекрасному результату.
Из глобальных изменений в компании — пятница стала днем без встреч. Даже если периодически какие-то команды не вкладываются в сроки и работают 5 дней в неделю, у них все равно нет встреч по пятницам.
Что думают разработчики, которые работают по 4-дневному графику
Александр Килинский, Head Of Development
Про отношение к переходу на 4-дневку
Моя команда, в которой я был тимлидом, первой попробовала на себе эксперимент с 4-дневкой. Алексей пришел с этой идеей ко мне, и я, долго не раздумывая, согласился. Команда восприняла ее в основном позитивно, но, как часто бывает среди разработчиков, были и скептики, которые искали подвох.Важно добавить небольшую предысторию о том, как мы закрывали спринты. Команда в целом справлялась с большинством запланированных задач, но частыми были случаи, когда разработчики сделали задачу, тестировщики не успели протестировать, и ее приходилось переносить на следующий спринт. Поэтому сначала члены команды не были уверены, что мы сумеем справиться со всем объёмом за 4 дня вместо 5. Но все-таки решили попробовать.
Первый экспериментальный спринт команда закрыла на 70%, а для того, чтобы получить дополнительные выходные, надо было выполнить более 90% задач. Я думал, что это может демотивировать ребят, но все, наоборот, собрались, сделали выводы и следующий спринт закрыли успешно и получили 4-дневку. Это нереально воодушевило команду, и в следующий спринт мы опять выполнили все вовремя.
Четвертый спринт завалили и после этого на ретроспективе начали обсуждать, что делаем не так и как нам получить наши «пятнички». Эти обсуждения привели нас к пересмотру процессов работы, таким образом 4-дневка потянула за собой ряд улучшений: мы начали вырабатывать командные практики, которые бы позволили улучшить результаты. Например, решили разбивать большие задачи на маленькие. Если есть задача, которая занимает больше 10% всего спринта, это сигнал о том, что она может застопорить команду. Ее нужно подробить.
Также договорились, что в спринт нельзя брать таски, которые друг от друга зависят: если кто-то один застопорится на первой задаче, второй тоже не успеет выполнить свою. И все это может привести к провалу спринта.
Про овертаймы
Конечно, приходилось овертаймить. Но это были не классические переработки, когда приходит тимлид и говорит команде: «Так, надо поднапрячься и поработать в субботу». Все было на добровольных началах: разработчик или тестировщик мог позаниматься дома вечером или на выходных.Я тоже часто овертаймил. Стоит сказать, что я работаю в компании уже 14 лет и воспринимаю продукт как свой. К тому же живу за городом, поэтому в доковидные времена, чтобы не стоять в пробках, приезжал в офис на 7 утра, а если не успевал уехать домой до 5 вечера, оставался здесь допоздна. Иногда проводил в офисе по 12 часов. Поэтому не могу сказать, что причина переработок была только в 4-дневки, но действительно бывали ситуации, когда понимал, что нужно поднажать, чтобы команда получила свои «пятнички». Но это не доставляло мне дискомфорт.
Даже когда команда получала дополнительные выходные, я все равно работал практически каждую пятницу. В основном из дому, в свободном графике во время, свободное от семейных и личных дел. Это не были полноценные рабочие дни: я просыпался не так рано, как обычно, мог пойти в зал или посмотреть сериал, заняться личными делами и немного поработать. При этом от меня этого никто не ожидал, это было необязательно.
Поскольку обязанности тимлида занимали у меня практически все рабочее время, свободных часов на разработку не оставалось. А работа по «нерабочим» пятницам дала возможность программировать в свое удовольствие.
Про плюсы и минусы нового графика
Главный плюс для меня в том, что в пятницу я могу заниматься, чем хочу. Несмотря на то, что по пятницам я часто работаю, я делаю это в свое удовольствие. А когда работать совсем не хочется — могу этого не делать. Всегда мечтал, чтобы в сутках было не 24 часа, а 30 или даже 40. Этот дополнительный выходной дает такое ощущение, потому что можно все успеть.Минусов лично для себя не вижу.
Ни для кого не секрет, что программисты не работают по 8 часов в день. Если хотя бы 50–60% рабочего времени уходит на работу, то это хорошо. Я не считаю, что это плохо, это просто факт. А переход на 4-дневку означает, что работать надо более сфокусировано и не так много прокрастинировать. Думаю, что для людей, обладающих высокой самоорганизацией, это не было проблемой. Но кто-то все-таки мог ощутить, что нагрузка стала более интенсивной. Знаю, что некоторые ребята из команды начали интересоваться инструментами для повышения продуктивности, завели личные Trello или Todoist и пытались меньше прокрастинировать. По моим наблюдениям, у них это неплохо получается. Я не испытывал с этим трудностей, так как уже давно пользуюсь личным Trello, где каждый день завожу таски для себя.
Сергей Балганбаев, Software Development Engineer
Про отношение к переходу на 4-дневку
Поначалу было тяжело распределить свое рабочее время так, чтобы задачи выполнялись равномерно на протяжении спринта. То есть получалось так, что они делались по времени плюс-минус как раньше (как при 5 рабочих днях), поэтому под конец спринта приходилось по умолчанию работать быстрее и больше.Про овертаймы
Нашей команде не приходилось часто овертаймить, но мне кажется, что это зависит от организованности коллектива. Со временем мы научились делать задачи более равномерно на протяжении спринта. Поэтому проблемы, связанные с закрытием тасков в панике под конец спринта, стали случаться все реже.И в целом мы в команде выработали правило, что если не успеваем выполнять задачи, то никто не обязан овертаймить, чтобы успеть. Для нас это значило, что нужно посмотреть на ретроспективе, где были проблемы, которые привели к незакрытию спринта. Так что в целом переработки, если и были, то по личному желанию каждого сотрудника.
Адаптация к новому режиму заняла примерно 2–3 месяца, то есть 4–5 спринтов (они у нас двухнедельные). Как по мне, чтобы полностью приспособиться, важно поработать в новом графике и новом темпе хотя бы несколько спринтов. Если они короче или длиннее, то и адаптация может занять другое количество времени.
Про плюсы и минусы нового графика
По поводу плюсов могу сказать, что три дня выходных имеют совершенно другой эффект, чем два дня. Нет ощущения, что выходные только начались и сразу закончатся. За счет этого чувствуешь себя более отдохнувшим в понедельник.Также команда становится более нацеленной на результат, поскольку если спринт не закрыт вовремя, то и 4-дневки в следующем спринте не будет. Все в команде это понимают, соответственно работа идет более бодро.
Одним из главных минусов является то, что иногда в погоне за 4-дневкой может теряться качество выполнения задач. Это важно замечать и исправлять такой подход, потому что это может демотивировать членов команды.
Не могу сказать, что при 4-дневке чувствую бОльшую нагрузку, чем при 5-дневке. Как мне кажется, это сильно зависит от человека. Для себя я просто выработал подход, при котором имею чуть больше рабочей нагрузки каждый день, но это не дает ощущения большой загруженности в целом. Этому есть две причины.
Во-первых, выполнение того же количества задач за меньшее время требует бОльшей концентрации. То есть просто меньше времени тратится впустую (хотя и без этого никуда). А во-вторых, рабочие дни и дни отдыха распределены более равномерно — 4/3 дня вместо 5/2. В целом благодаря этому ощущаю себя более отдохнувшим и заряженным.
Николай Хазанович, Java Back-end Developer
Про отношение к переходу на 4-дневку
Моя команда была не первой, кто перешел на 4-дневный график. Когда я услышал, что коллеги будут работать по принципу «планируем на пять дней, а работаем четыре», у меня возникло недоумение. Я даже выступал своего рода оппонентом этому нововведению.К тому моменту, когда схема показала себя хорошо и ее распространили на другие команды, уже стало интересно попробовать «пятнички».
При традиционном планировании спринта получить первые дополнительные выходные оказалось нетрудно. Мы успешно закрыли его и получили возможность отдыхать по пятницам. Но повторить результат уже оказалось сложнее — и следующие три-четыре спринта мы «провалили» и работали 5 дней.
Постепенно команда поняла: чтобы выполнить пятидневный объем работ за четыре дня, нужно переводить планирование процессов на новый уровень, чтобы даже незапланированная работа получила свою оценку.
Про овертаймы
При 4-дневке периодически приходилось овертаймить, иногда приходится и сейчас. Но овертаймы случаются и при 5-дневной рабочей неделе. Обычно к этому приводят ошибки в оценке сложности тикетов. Поэтому мы стали уделять больше времени исследованию пути решения задач, чтобы максимально повысить точность планирования.Иногда овертайм означает пару часов работы на выходных, иногда — перегруженный будний день. Но дополнительный выходной, как правило, позволяет восстановиться, в итоге получаешь больше, чем теряешь.
Два-три месяца — и ты «на крючке» у дополнительного выходного.
Про плюсы и минусы нового графика
Для меня такой режим в первую очередь означает, что неделю желательно распланировать заранее. Речь идет как о рабочем, так и о личном времени, которое нужно согласовать с другими членами семьи.Значительный плюс — дополнительный выходной в будний день. Это позволяет или разгрузить выходные от рутинной домашней работы, или запланировать что-то «нестандартное» на пятницу.
Из минусов — более плотные (иногда и более длинные) рабочие дни, жизнь по запланированному расписанию. Также чувствуется более сильная нагрузка. Если не следить за рабочими часами, еcть риск выгореть. Хочется верить, что это промежуточная «фаза эволюции» к чистым четырем рабочим дням, ведь по опыту зарубежных коллег уже статистически доказано, что три выходных позволяют как лучше отдыхать, так и лучше работать. То есть, даже не втискивая пять рабочих дней в четыре, можно достичь успеха.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua