×

«Сначала было больно». Как я перевел инжиниринг-отдел на 4-дневку, сохранив объем задач и зарплату сотрудников

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

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

👍ПодобаєтьсяСподобалось34
До обраногоВ обраному12
LinkedIn

Схожі статті




49 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Цікавий і водночас непростий експеримент. Файно, що пробуєте.

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

Постепенно команда поняла: чтобы выполнить пятидневный объем работ за четыре дня, нужно переводить планирование процессов на новый уровень, чтобы даже незапланированная работа получила свою оценку.

Производительность команды и разработчиков
А вот производительность в смысле «теперь команда успевает выложить в прод за 8 рабочих дней столько же небольших фич как раньше за 10» может и выросла — что замечательно.

Выходит, что желание «пятничек» заставляет планировать работу, организовывать буфера по времени и поощряет кросс-функциональное взаимодействие: если фичу дописываешь в четверг днём, а QA инженер её никогда не видел, то можно и не успеть простестить до пятнички, а если писал тест параллельно с разработкой — то можно. Возможно, пятнички эффективнее, чем задушевные разговоры agile-коучей о том, что хорошо бы работать вместе и общаться почаще.

Ну и на крайний срок переработки по пятничкам выступают в роли буфера если уж совсем не успеваем.

Цікавий підхід. Мій тімлід собі теж так робив, але ж не вся команда. Чесно кажучи в підході коли не одиничні люди роблять, а всі інженери мене турбує такі аспекти:
— можливий перехід з пріоритезації найбільш impactful задач на ті які не зафейлять «п’ятнички». Будемо вважати що subconsciously. Іноді треба робити щось не зрозуміле тому що воно найбільш корисне компанії, а не тому що я знаю як розбити проект на таски по два дні.
— не дуже розумію як цей підхід допоміг планувати півріччя. У вас же delivery тепер зрозуміле для тасок довжиною в два дні. І для того щоб передбачити delivery за пів року треба всі проекти одразу поділити на задачі в два дні. Виходить якийсь waterfall.
— як такий режим працював би в компанії де 1к інженерів в сотнях команд і куча залежностей між командами через складність продукту 🤔
— для b2b досить характерно робити певні проекти ASAP тому що від цього залежить підписання контракту. Оскільки режим підходить для long term, то в даній ситуації чи буде він заважати?! 🤔

Для меня лично преимущество 4-дневной рабочей недели больше в том, что за три выходных дня ты успеваешь восстановиться, а двух дней всё-таки недостаточно, особенно с оглядкой на семью и детей. И это повышает продуктивность труда в рабочие дни.

Поэтому я бы не ожидал сиюминутного эффекта от перехода, тут скорее long term, по мере того, как сотрудники будут постепенно восстанавливаться.Ну и может проявиться зависимость от возраста, всё-таки в 20–25 лет восстанавливаешься быстрее, семьи нет и т. п.

Факир был трезв и вывернул хитрый фокус. В фазе проекта когда идёт активный девелопмент — люди практически всегда овертаймят, за 15 лет я ещё ни разу не видел обратного. Вообще сверхурочные, к сожалению, это часть профессии. Затем идёт фаза с перманентным багфиксом и народ на работе, кроме багфиксов и разного по мелочи делает кто что. Кто в пинпонг, кто на кухне анекдоты травит и т.п. Тут уже репу чешут те кому «посчастливилось» работать админами и релиз менеджерами, у которых как раз подгорает. Вот тут менеджер придумал просто отпускать в выходной тех кто пинает по офису, ибо свой кусок закончил. Фишка в том что если не закончишь то и в выходной не пойдешь. К сожалению в целой куче проектов и компаний такой фокус не пройдет, потому как в фазу багфиксинга прибегает клиент и начинает «подсовывать хотелки» (новые фитчи которых не было в изначальных требованиях), и если менеджер продавиться то будут ещё овертаймы. У Google хитрей придумали, дают писать пет проекты вместо выходного. Тоесть если у тебя вдруг сейчас задачи нет потому как такая фаза проекта — можешь приносить Профит педаля опенсурс, который потом можно применить на проде.

Если работа приносит овертаймы то не сильно то и нужна такая работа)

У Google хитрей придумали, дают писать пет проекты вместо выходного

уже не дают

чем туда теперь заманивать, это был один из главных селлинг пойнтов

Рішення поосте — продуктова компанія яке релізить як тільки фіча готова. Немає ніяких замовників, ніяких баг фікс періодів — команда автономно вирішує що і як робити.

Ви занадто ідеалізуєте продуктову розробку. З мого три річного досвіду продуктової розробки маю не погодитись. Завжди існує бізнес доцільність розробки, витрати на неї і відповідно строки. У жодної компанії нема можливості платити і чекати завершення безкінечно. Замовники є завжди, вони можуть бути як внутрішніми: — засновник, сейли, маркетологи і т.і так і зовнішніми — тобто коли працюєте на аутсурс.

Я ж не кажу що можна фічі робити нескінченно довго. Просто немає реліз періодів, баг фікс періодів і усього отого шлака який ви описали як те що завжди є в розробці.

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

Если кол-во часов уменьшили, а объём не упал — значит сотрудники и так волынили это время :-)
Просто теперь оно легитимизировано.

Або збільшилася продуктивність праці. По собі знаю, що в п’ятницю працюється значно гірше, ніж на початку тижня.

Делали ли вы опрос, чем сотрудники занимаются по пятницам? Мне из статьи показалось, что какая-то часть тратит всё равно время на работу, и тогда это больше похоже на гугловскую идею с 80/20.

Кстати в Австрии многие фирмы (не только в IT) работают 4 дня по 8.5 часов + полдня в пятницу. Этакий компромисс, но привыкаешь к нему очень быстро.

Новый способ мотивации сделать работу — получи выходной. Гениально! И еще тем, что платить за эту мотивацию собственнику не надо. :)

Ну, а в целом — хорошая тенденция. Надо хоть чем-то заинтересовать работодателей на 32 часовую неделю.

Прикольно, що в статті про чотириденний робочий тиждень 12 разів зустрічається слово «овертайм», 2 рази «суббота» та навіть один раз «воскресенье». Тобто в нас 4 робочі дні, але іноді 5, іноді 6, а іноді і 7. То, може, в середньому вийде десь 5? :)

Тобто в нас 4 робочі дні, але іноді 5, іноді 6, а іноді і 7.

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

Аналогічно працює «безлімітна відпустка» — люди менше її використовують, а тих хто 4 рази на рік ходить по місяцю в відпустку звільняють ... ой ні, у них просто різко падає перформенс :)

А чому б і не попрацювати трохи в суботу або неділю? :)
І так відпочинок багатьох проходить за тим же монітором, просто з іншим контентом ;-p
Коли компанія з тобою по людськи, і забрала цілу робочу пятницю — то і самому не влом на вихідних годинку-дві зробити щось важливе імхо

Кроме того, что мы продолжали выполнять тот же объем работы, который всегда был на 5-дневке

Если не секрет, в чем «объем» измеряли?

Что у меня в голове не сходится:
— Раньше команда попадала в ожидание на 80-90% , что весьма точно. Т.е. задача оцененная в 2 дня — за два дня с тестированием и делалась.
— Теперь, команда попадает в ожидание с вероятностью 90%+ (что еще точнее), а значит задача, оцененная в 2 дня — должна за два дня с тестированием и делаться
— дней стало меньше, «объем» — тот же. Но при этом оценка точнее...

Как так то? Типа ребята, как услышали о 4хдневках, сразу стали задачи «плотнее» оценивать? (т.е. то, что раньше оценили бы в 2.5 дня, теперь оценивается в 2?) Или задачи на 10 рабочих дней, но делаются за 8?

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

т.е. задача оцененная в 3 дня делается за 2?

Оцінка швидкості виконання задачі протягом спринта базується на швидкості виконання подібних задач протягом минулого спринта. Коли люди стомлені, їм складно сконцентруватися на виконанні завдання, вони виконують завдання повільно. Коли люди гарно відпочили, вони легко концентруються на виконанні завдання, і виконують його швидко. Тому нема нічого дивного, що одне й те ж завдання оцінюється в три дні, коли люди стомлені, і в два дні, коли люди гарно відпочили.
Щодо точності оцінки, то тут працює наступний механізм. Втома має властивість накопичуватися. І люди, які працюють п’ять днів на тиждень, з кожним спринтом працюють повільніше, через це оцінки швидкості задач, побудовані на досвіді виконання подібних задач в попередніх спринтах, виявляються завищені.

Коли люди стомлені, їм складно сконцентруватися на виконанні завдання, вони виконують завдання повільно.

Треба вводити 1-денний робочий тиждень!
Втому не «вилікувати» 1 додатковим вихідним. Більшість людей працює 5+2, яки схема 4+3 приносила результат її б впроваджували масово.
Але проблема в тому, що 4-денний робочий тиждень — це історія не про втому, концентрацію та ефективність. Ця схема може мати корені в досить різних речах, наприклад:
— бажання продемонструвати лояльність компанії до працівників;
— піар на ринку праці;
— відсутність скоупу роботи;
— спроба експлуатувати лояльність працівників до компанії.

В конкретній компанії це спрацювало. Стаття описує досвід, але не описує критерії, що дозволили б прийняти рішення про ефективність того чи іншого підходу для інших компаній.

Треба вводити 1-денний робочий тиждень!

Зверніть увагу, не я перший це запропонував ;)

Крутой эксперимент, молодцы что на него решились.

Самым сложным в переходе на новый график было настроить взаимодействие внутри команд. Когда ребята стали нацелены на командный, а не индивидуальный результат, начали менять процессы для командной, а не индивидуальной работы. В итоге мы получили крутые результаты. Стало намного легче и быстрее масштабироваться, нанимать новые группы разработки и получать от них результаты. Если раньше онбординг команд занимал 6 месяцев, то после перехода на 4-дневку он сократился до полутора месяцев. Описанные выгоды получены не из-за четырехдневки, а благодаря изменениям, которые она нам принесла. Новый график стал мотивацией, за которой подтянулись все остальные нужные изменения. Это можно сделать и другими методами, но у нас этот сработал намного лучше остальных.

Еще один косвенный эффект — снизилось количество багов в продакшене, а предсказуемость релизных циклов увеличилась. Мы долго работали над этими проблемами, а эксперимент с графиком помог их решить и привел к прекрасному результату.

Из глобальных изменений в компании — пятница стала днем без встреч. Даже если периодически какие-то команды не вкладываются в сроки и работают 5 дней в неделю, у них все равно нет встреч по пятницам.

Противоречивые впечатления от статьи. С одной стороны, вроде как победителей не судят, но не совсем понятно, почему было выбрано именно такое средство достижения цели? Здесь же дело не в 4-дневке и лишнем выходном как таковых — просто нужен был триггер, который обострит проблемы. С другой стороны, если все видели (судя по комментариям в том числе), что есть проблемы с планированием, почему бы не прийти к лидам без 4-дневки раньше? И, если раньше приходили, то почему не помогало? Поэтому со стороны создалось впечатление, что менеджмент просто сам не знал, что со всем этим делать, и поэтому решили пойти на радикальные шаги.

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

Работая на 4 дневке — это отличный вариант взять ещё другой проект на парт тайм. Интересно, как много сотрудников так поступают

— Ми подумали і вирішили зробити 4-денний робочий тиждень, щоб у вас було більше часу на життя.
— Але в мене нема життя за межами роботи!...
* Бере проект парт-тайм *
— ...От зароблю мільйон бабла, і тоді-то заживу!

О тааа... Любимо ми відкладати життя на потім...
Як казав один знайомий немолодий індус, замолоду є зуби, але немає хліба, а потім є хліб, та вже немає зубів...

Хулі зуби, зуби вставить можна © Митець

Так вони ж не на аутсорсі — у них немає якихось інших проектів за які доплачують.

Закон Па́ркінсона: будь-яка робота завжди заповнює весь відведений на неї час. Відведете 10 годин, буде зроблено за 10, відведете 5, буде за 5. Дуже актуально в ІТ.

Як колись більшість плювалась на ремоут, а тепер він де-факто стає новим стандартом, так і зменшення робочих годин буде також новим стандартом.

Хоча як на мене, ефективніше саме в плані роботи 5-6 годинний робочий день 5 днів на тиждень замість 8-10 годинного 4 дні в тиждень.

Ті, хто продають результат, будуть «За» і матимуть конкурентну перевагу, ті, хто продають попогодини будуть однозначно проти.

Это справедливо для разовых ситуаций. Если постоянно давать людям по 5 часов на задачу, они выгорят.

Ноу.
Якщо людина буде знати, що у неї є 5 годин на виконання завдання, то вона буде працювати 5 годин.
Якщо людина знає, що у неї є 8 годин і в ці 8 вона може робити роботу, може коментити на ДОУ, лайкати котиків, пограти на приставці, сходити на масаж і т.д. то вона використає набагато більше 8 годин, навіть якщо роботу можна було зробити за 5.

Нормальный разраб сделает задачу за 3-4-5 часов, а потом будет смотреть котиков. А вот если на задачу отведено 5 часов, а там оказались подводные камни, на которые у тебя нет запасного времени (например, «добровольных» пятниц), то это стресс и выгорание.

Або ж він буде 3-4-5 годин дивитись котіків а потім зробить задачу за решту часу. З мого досвіду, більшість так і робить.

Не розумію, чому ви вчепились до того, що хтось мусить закрити задачу за 5 годин і все, а то покарання і смерть.
Якщо людина робила корисну роботу 5 годин, у неї не вистачило часу, вона прийде наступного дня і доробить цю роботу, якщо не закінчить, то доробить наступного і т.д. Якраз для цього і треба ретроспектива і планування. Якщо виявилося, що якісь таски вимагають більше часу бо там є

подводные камни

то це треба враховувати і закладати в естімейт, а не вимагати фікс

подводных камней

у вільний позаробочий час. Це дічь якась.

Вже 100500 раз обговорили те, що ніхто не працює повних 8 годин, максимум, 6, а решта йде на відпочинок.

Якщо людина буде мати більше вільного часу, яке вона присвятить хоббі, сім’ї, друзям, спорту, то якраз це не дозволить вигоріти і явно покращить ворк-лайф баланс, що в свою чергу зменшить стрес і перешкодить вигоранню.

1. Якщо проекту більше умовних 5 років, та в ньому змінилося кілька поколінь розробників, то там завжди буде підводне каміння, яке випливає під час розробки. Крім того, бувають проблеми з інфраструктурою та інше в тому роді. Якщо задачу відкладати на наступний спрінт кожного разу, коли вона «застопорилася», то можна її місяцями робити.
2. П’ятниця у данному випадку не є «вільний час». Просто в цей час ніхто не чекає від тебе, що ти будеш доступний у рабочий час та будеш закривати таски, робити рев’ю та інше. Тобто ти за цей час не «звітуєш». Але спрінт запланований так, ніби ти в п’ятницю працюєш. Нормальна людина не стане «загоняти» себе в психологічну яму лише через те, що може не отримати умовно вільний час на наступні два тижні. Але мати опцію працювати чи не працювати один день на тиждень в залежності від того, як зробили у попередньому спринті, та як йдуть діла у поточному, це завжди приємно.

Тоді дайте просту відповідь, чому б не працювати по 10 годин щодня?

Якщо в класичній моделі спринт це два тижні або 5*8*2=80 годин, то я пропоную 5*6*2 = 60 годин або ж просто відмінусувати із 80 годин час на перегляд ютубу і гортання ФБ.
Дайте просто відповідь: Чи особисто ви ефективно працюєте щодня 8 годин?
Особисто я — ні, хоча репортаю 8, бо цього вимагає керівництво, хоча всі чудово знають, що 8 ніхто не працює. В такому випадку, навіщо це лицемірство?

Ви пишете про те, що фактично вільного дня немає, тому що від тебе очікують, що ти будеш далі працювати, просто без мітингів. Це, як на мене, ще гірше ніж було, тому що раніше люди просто знали, що йдуть працювати 5 днів, а тепер їм декларують, що вони працюють 4 дні, а по факту кажуть, що маєш працювати 5.
Це дуже підлий психологічний прийом, адже відомо, що перевірений спосіб зробити погано, це спочатку зробити добре, а потім перестати і все, людина звикла до хорошого і їй погано.

Ну і наостанок, що заважає вам оцінити перфоманс вашої команди за 4 дні і мати спринт з урахуванням саме 4-денного робочого тижня, а не 4 + 1?
І ще одне: Якщо в спринті тижні по 5 днів, а ви все ще не встигаєте, ви будете змушувати колег чи самостійно праювати в суботу й неділю?

Взагалі цей тред почався з мого меседжу, де я писав про закон Паркінсона, який був доведений дуже багатьма людьми і саме це для мене є найголовнішим аргументом.

а там оказались подводные камни, на которые у тебя нет запасного времени (например, «добровольных» пятниц), то это стресс и выгорание.

Якщо немає «добровільних п’ятниць», то є добровільні суботи, неділі і ночі :)

то є добровільні суботи, неділі і ночі :)

Нету. И пятницы добровольные очень редко случаются)

Не зовсім так. Окрім роботи є ще родина та дозвіл у різних проявах. Тож для підтримання балансу ночі, суботи та неділі не мають бути «умовно робочими». Лише якщо дійсно нудно та нема чим зайнятись, можна трохи попрацювати :). А ось «бонусна» п’ятниця може, тому що вона, скоріше, умовно «вихідна». Крім того, не забуваємо, що задачі плануються так, ніби п’ятниця робоча. Тож така система дійсно допомагає самоорганізації та запобігає цейтноту, а не навпаки.

Крім того, не забуваємо, що задачі плануються так, ніби п’ятниця робоча.

Так тоді можна зробити і 2-денний робочий тиждень (24*2 == 48) :)

І саме через це вона і вигорить, бо запас часу це і про розслаблення, і про ризики самої задачі, і про неробочі форс-мажори. Словом, це про якісь гарантії.

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

Думаю, що існують розробники ПЗ, які так роблять не лише по п’ятницям, але і щодня, і при цьому встигають зробити всі завдання якісно і вчасно. Хотілося б так навчитися, оскільки коли я посеред робочого дня подивлюся фільм та подискутую на доу, то зрештою доводиться ввечері засиджуватися допізна, щоб доробити роботу.

Несмотря на то, что по пятницам я часто работаю, я делаю это в свое удовольствие.

Ви працюєте з понеділка по четвер, але Ви робите це без задоволення.

Потрібно буде якось посеред робочого дня подивитися «Хрещеного батька», бо з цим фільмом та з цитатами з нього виходить як з фільмом та анекдотами про Чапаєва — анекдоти всі знають, а фільм мало хто дивився.

Про плюсы и минусы нового графика
Главный плюс для меня в том, что в пятницу я могу заниматься, чем хочу. Несмотря на то, что по пятницам я часто работаю, я делаю это в свое удовольствие. А когда работать совсем не хочется — могу этого не делать. Всегда мечтал, чтобы в сутках было не 24 часа, а 30 или даже 40. Этот дополнительный выходной дает такое ощущение, потому что можно все успеть. Минусов лично для себя не вижу.

Немедленно представляется диалог подчинённого с начальством.

— Ненуашо. Твоя ставка поменялась?
— Нет.
— Мы тебе выходных добавили?
— Добавили.
— Шо ты ещё хочешь. Иди отсюда.

Підписатись на коментарі