Гибкий.ру Визуализация
Обычно используется та же самая доска, что и в Scrum. Самый простой вариант — прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач — WIP (Work in Progress).
Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».
Обычно команда начинает с большого ограничения задач в работе, например, не более двух задач на человека. Если у меня один тестировщик — две задачи для разработки, если четыре тестировщика — восемь задач. Постепенно общее количество задач уменьшается, скорость работы возрастает. И доска уже выглядит примерно так.
Здесь есть те же самые WIP, внизу — критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система.
Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали — количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход.
Вторые важные критерии — Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.
В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time — насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.
Гибкие графики рабочего времени в ритейле: особенности, автоматизация, перспективы |
Для крупных компаний, в том числе в ритейле, расходы на персонал – самая большая статья в бюджете. И если думать про повышение эффективности бизнеса и управление прибыльностью, то один из существенных рычагов воздействия, помимо увеличения объема продаж, – это управление расходами на персонал.
Учитывая, что ежегодно зарплаты в этой отрасли растут, одним из важнейших инструментов снижения расходов и оптимизации HR-процессов является управление рабочим временем.
В ритейле, как и любой отрасли, есть свои особенности, которые необходимо учитывать при ведении проектов автоматизации процессов планирования и табелирования массового персонала. О них мы беседуем с Алексеем Мельниковым, начальником управления внедрений компании «БОСС. Кадровые системы».
Итак, в чем же особенности учета рабочего времени в ритейле и почему возникают сложности с табелированием?
– Ритейл очень зависим от клиентского потока: в выходные большое количество покупателей, а в будние дни в части магазинов может никого не быть. Существует также сезонность и праздники. На неравномерность посещения влияют и внутренние факторы, например, промо-акции или инвентаризации. Это значит, что планировать графики нужно очень гибко, и управление рабочим временем в ритейле просто необходимо!
Многие компании-ритейлеры перевели персонал на гибкие графики труда: такой режим рабочего времени, при котором сотрудник начинает смену в оговоренное с работодателем время, а её продолжительность в разные дни может отличаться. При этом руководитель по ТК РФ должен предоставить сотруднику возможность и условия для выработки определённой суммы часов, а также предоставлять отдых каждые 7 дней. Есть и другие ограничения: минимальная и максимальная продолжительность смены, ограничения по продолжительности отдыха между сменами.
Вести и контролировать такой порядок работы довольно сложно. Кроме того, управление рабочим временем – это и привлечение работников с неполной занятостью, временный персонал или использование сотрудников, которые работают по совместительству. И все эти режимы автоматизированная система должна обрабатывать в штатном порядке.
У многих наших заказчиков свои схемы работы, но это может учитываться путем доработки нашего основного решения
«Планирование графиков рабочего времени и табелирование», созданного на базе системы управления персоналом БОСС-Кадровик.
Как в этом модуле учитывается такая специфика ритейла?
– Гибкость нашей программы позволяет их учитывать. Установить нормативы можно как на всю компанию, так и использовать их для каждого департамента раздельно, вплоть до конкретного отдела. Есть возможность хоть каждый месяц создавать разные нормы, если это требуется. Например, ряд магазинов выделяет определенный фонд рабочего времени на конкретный период: то есть могут установить, что в феврале компания потратит 30% от годового фонда рабочего времени, а в июле только 10. Данные параметры задаются в справочниках нормативов нашей системы.
Читайте также: Настроить бизнес так, чтобы он работал без вас: недостижимая мечта или реальность
Как система помогает руководителям в планировании рабочих графиков?
– Руководители могут быстро планировать гибкие графики с помощью удобного интерфейса и вспомогательных функций. На экране отображается перечень работников, их должности, данные о планируемом и фактическом рабочем времени. По каждому сотруднику представлена информация по планируемым сменам, времени их начала и окончания. Менеджер может как вручную, так и автоматически вести этот документ. Если он вносит данные вручную, то проставляет только время начала смены и ее продолжительность, а время окончания рассчитывает система, автоматически учитывая необходимые перерывы по заложенному алгоритму. Решение «Планирование графиков рабочего времени и табелирование» помогает не только рассчитывать смены и тратить на это минимальное количество времени, но и примерно оценить эффективность загрузки торговых точек персоналом.
Также программа предоставляет руководителям определенную гибкость в планировании: они могут поставить сотруднику то количество часов, которое считают необходимым. Но, поскольку у менеджеров бывает разная квалификация, в модуле предусмотрены определенные проверки и ограничения, чтобы избежать ситуации, когда руководитель в первые полгода ставил работникам по 250 часов на каждый месяц и выбрал всю норму, а на конец года, когда обычно идет всплеск продаж, рабочего времени сотрудников не осталось.
Для удобства планирования в модуле реализованы статистики: по каждому работнику считается норма – сколько человек должен отработать за год, сколько часов из них руководитель уже потратил, сколько у сотрудника осталось до конца года. В табеле есть специальное поле, в котором отображается остаток – сколько в среднем за месяц можно поставить часов, – это очень помогает сориентироваться. Если же менеджер сам не очень следит за статистикой, то вступает в действие программный контроль – например, запускаются проверки отклонений от среднемесячной нормы. Система нарастающим итогом отслеживает эти параметры и сначала дает подсказку руководителю, что он приближается к норме, а потом начинает блокировать его действия и просит изменить табель. Менеджер такие проверки может запускать несколько раз в месяц нажатием всего одной кнопки. Автоматически они отрабатывают в конце планирования, когда закрывается график, и в конце табелирования, когда идет оформление документов перед расчетом зарплаты.
Какие еще процедуры планирования графиков выполняются автоматически?
– В программе есть возможность создать шаблоны рабочих графиков. Причем, как на всю компанию, так и разработать набор своих графиков, привязать их к сотруднику и заполнять нажатием одной кнопки, а потом вручную отредактировать, если нужно. То есть, обычно у работника есть какой-то базовый режим работы, например, 3/2, но при этом время начала и окончания работы в конкретном месяце нужно изменять. Проще всего сначала по шаблону заполнить стандартный график, а потом внести необходимые корректировки. Это помогает быстрее работать с документом.
А как происходит заполнение данных по посещаемости?
– Каждый день в программе происходит табелирование: его можно делать автоматически – руководитель заходит в интерфейс и нажимает кнопку «Заполнить за один день». Система проставляет данные по плану, а дальше руководитель уточняет факт – неявки или переработки. Так можно вносить данные по каждому сотруднику, либо по всему табелю сразу. Менеджеры компаний оценили такой способ: возможность работать со своим набором шаблонов и таким образом снизить общее время заполнения табеля. Поскольку это гибкий график, его можно менять в течение месяца постоянно, хоть каждый день. Если какой-то сотрудник не вышел на смену, и его нужно заменить, руководитель нажимает кнопку, видит, кто у него свободен в этот день и проставляет смену другому работнику. Также нажатием кнопки можно посмотреть количество занятых работников и состав смен. По отзывам этот инструмент очень эффективен: позволяет руководителям работать быстрее и проще.
Планируется ли дальнейшее развитие этого решения, и если да, то в каком направлении?
– Если говорить про развитие, то существует специализированная методология Workforce Management (WFM) и отдельные решения на её основе, в которых автоматизированные системы сами строят рабочие графики. Они собирают информацию о так называемых бизнес-драйверах: продажах, клиентском потоке, чеках и полностью планируют персонал «на точках» за руководителей. На текущий момент подобных решений российского производства нет – все они имеют определенные технические ограничения, например, по возможностям оценки эффективности. Сейчас эта задача задает вектор развития функциональности нашего решения
«Планирование графиков рабочего времени и табелирование» на базе системы управления персоналом БОСС-Кадровик.
Заказать презентацию решения или демоверсию: sales@bosshr.ru
Для чего нужна методология гибкой разработки?
Итак, для чего же применяется методология Agile?
- Ускорение вывода продукта на рынок. Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн — это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
- Управление изменениями в приоритетах. Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что мы, программисты, аналитики и дизайнеры, никогда не знаем, что нужно не только заказчику, который нам платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
- Улучшение взаимодействия между IT и бизнесом. Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.
Ответом на все эти вызовы явился Манифест гибкой разработки ПО.
Зачем нужен такой режим работы
В России проживает около 150 миллионов человек. Каждый из этих людей имеет свои особенности, свой особый ритм жизни, профессиональную квалификацию, семейные обстоятельства. В различных жизненных ситуациях человек вынужден искать работу, которая отвечает его запросам и ограничениям.
Некоторые категории граждан не имеют возможности работать в течение стандартного рабочего дня.
Одним из таких примеров являются молодые мамы с детьми. Воспитание детей требует постоянного внимания, а для этого нужно много времени. Поэтому свободный график работы является в подобных случаях удобным вариантом.
В некоторых профессиях в силу особенностей их производственного процесса свободный график работы будет более эффективен по сравнению с обычным. Одним из примеров здесь могут быть работники, которые занимаются ремонтом или ликвидацией аварий.
В других случаях род деятельности сотрудника таков, что эффективность его работы может возрасти, если позволить ему в большей степени управлять организацией его рабочего времени. В этом случае руководитель и работник приходят к определенному соглашению и последний в оговоренных рамках получает большую степень свободы в рассматриваемом вопросе.
Важно подчеркнуть, что гибкий режим рабочего времени — это не отсутствие всяких рамок и не полная свобода от любых ограничений:
- он полностью регулируется положениями законодательства, в том числе Трудовым кодексом РФ;
- всё происходит в строго определенных рамках, которые определяются руководством по согласованию с работником;
- гибкий режим применяется только в тех случаях, когда от этого ожидается повышение эффективности работы.
Компоненты scrum
РолиScrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.
- Почему мы говорим, что Scrum — это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта — новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
- Владелец продукта, product manager — человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
- Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.
Процессы
- Ежедневный скрам — это планерка, на которой члены команды рассказывают, что сделано, с какими проблемами столкнулись, что планируется сделать в ближайшее время, чтобы каждый понимал, кто и что делает.
- Спринт — итерация с фиксированным сроком, то есть в Scrum должен быть ритм.
- Планирование спринта. Перед началом спринта все собираются и определяют, что нужно сделать в течение спринта и в каком виде.
- Обзор спринта или демонстрация: все собираются и демонстрируют, что нового в инкременте продукта, смотрят, фиксируют замечания, может быть, меняют ближайшие планы.
- Ретроспектива: все собираются и думают, что можно улучшить в следующем спринте. Например, было много багов, пользователи недовольны. Давайте попробуем в следующем спринте использовать модульное тестирование. Пробуем, на следующей ретроспективе смотрим, помогло или нет, придумываем что-то еще.
Бэклог спринта — верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1—4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.
Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».
После завершения спринта проводится демонстрация — «Обзор», смысл которой заключается в том, что команда показывает сделанную работу владельцу продукта или кому-то еще. Затем проводится ретроспектива, на которой команда обсуждает, что получилось, а что нет, происходит разбор рабочих процессов, атмосферы в коллективе, предпринимаются попытки что-то улучшить. После этого запускается следующий спринт. В итоге работу Scrum-команды можно представить как цепочку множества спринтов.
АртефактыЭто могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте — JIRA, Redmine и т.д.
Манифест гибкой разработки
Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:
- Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
- Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
- Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
- Готовность к изменениям во взвешивании со следованием первоначальному плану.
В Agile есть план, оценки и прогнозы. Но если у вас есть какой-то первоначальный план для годового проекта, а вы через три месяца уже предоставили какую-то версию продукта, пользователи его пощупали, вы сняли метрики, посмотрели, что и как они используют, узнали что-то новое, то после этого первоначальный план можно почти полностью поменять.
Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой — поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи.
Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:
Пилотные этапы
Проект запускали в несколько этапов. С октября по декабрь 2022 года он действовал только в центральном офисе в Москве. Сотрудники могли два дня в месяц работать из дома, причем домашний адрес фиксировался в дополнительных соглашениях в качестве второго рабочего места. В части гибкого графика мы предоставили три интервала на выбор — с 8 до 16.30, с 9 до 17.30 или с 10 до 18.30.
Второй этап — с февраля по апрель 2022 года — охватывал все регионы присутствия компании в России. Мы учли пожелания сотрудников, которые часто говорили, что им удобнее было бы начинать рабочий день в разное время в зависимости от дня недели, а также работать не только из дома.
Число дней дистанционной работы увеличилось с двух до пяти в месяц. Появилась возможность трудиться из любого места, например, кафе или коворкинга. Опции гибкого графика тоже расширились. Действовал интервал начала рабочего дня с 8 до 10 утра, и внутри этого интервала сотрудники могли сами выбирать, во сколько они придут в офис в тот или иной день недели.
По итогам как первого, так и второго этапа мы получили очень позитивную обратную связь, и приняли решение двигаться дальше. В ходе опросов 90% участников отметили, что проект положительно повлиял на баланс работы и личной жизни. 88% уверенно заявили, что гибкий график и дистанционная работа позитивно сказались на их продуктивности.
В мае 2022 года проект запустили на более продолжительное время — до декабря нынешнего года. Опции остались прежними: участвует вся страна, можно работать до пяти дней в месяц дистанционно и выбирать время начало рабочего дня в промежутке с 8 до 10 утра.
В декабре планируем еще раз собрать обратную связь о проекте от его участников. И если обратная связь снова окажется положительной, постараемся и дальше развивать доступные опции — расширять количество дней для дистанционной работы и интервал для начала рабочего дня.
Плюсы — для всех
Для компаний, которые перевели своих сотрудников на гибкий график, может найтись множество плюсов. Во-первых, это дает возможность распределенным командам больше общаться. Чем дальше друг от друга расположены офисы компании, тем сложнее сотрудникам вести коммуникацию друг с другом.
Во-вторых, гибкий график отдельных сотрудников позволяет организации “покрывать” больше рабочих часов. Например, у вас есть поддержка, но она не круглосуточная, работает только днем. Если все сотрудники будут начинать и заканчивать работу в одно и то же время и находиться в офисе, скажем, с 09.00 до 18.
00, то клиенты, обратившиеся за помощью вечером, не получат ее. Утром же сотрудники будут завалены работой: текущими запросами и разбором вчерашних обращений. Если в команде поддержки более четырех сотрудников, выводите их на работу в разное время (например, с 8.00 до 11.00).
И наконец, гибкий график нравится сотрудникам. Эффективность многих зависит не от того, во сколько они пришли на работу, а зачастую от привычек и образа жизни. “Жаворонки”, как известно, максимально заряжены утром, когда им нипочем даже самые сложные задачи, а некоторые “совы” и после полудня не могут полностью погрузиться в работу.
Работая в компании с гибким графиком, сотрудник легче выстраивает баланс между работой и отдыхом. С возможностью управлять утренним и вечерним временем жить становится значительно проще. Скажем, в первой половине дня можно успеть отвезти детей в сад или школу, позаниматься спортом или даже решить какие-то бытовые вопросы.
Или же ранний старт, наоборот, может освободить вечер для семьи, хобби или других дел. В больших городах мы часто забываем о том, что время — это очень ценная валюта. И если компания позволяет использовать его с максимальной пользой не только для работы, но и для личных целей, это дорогого стоит.
Правила применения
Если скользящий график применяется по отношению к матерям, которые имеют малолетних детей, это может быть организовано различным образом:
- Может быть сделано вообще без ограничения срока.
- Данный режим работы может быть определен в течение определённого срока.
- Такой график в некоторых случаях предоставляется до достижения детьми определенного возраста.
- Иногда гибкий режим работы даётся на период учёбы детей в школе, в течение учебного года.
- Обязательным условием должен быть точный контроль проработанного времени. Его годовой норматив должен быть соблюден несмотря на предоставленный молодой матери относительно свободный график работы.
В некоторых случаях предоставление гибкого графика работы происходит не в связи с решением руководства данного предприятия, а в соответствии с нормативными актами ведомственного уровня.
Примером такой ситуации является Приказ Минсвязи РФ №112 от 8 сентября 2003 года, который даёт возможность использовать рассматриваемый график работниками определенных профессий. В документе указан список таких специальностей.
В него, в частности, входят:
- сотрудники, которые занимаются исправлением повреждений и ликвидацией аварийных ситуаций;
- работники, которые занимаются приёмом и отправкой почты, ее сортировкой, перевозкой и другой аналогичной работой.
В некоторых случаях данный порядок регламентируется отраслевым соглашением. Например, Федеральное агентство по метрологии в таком документе включило норму о том, что по согласованию с профсоюзами директор может своим приказом вводить на предприятии режим работы, при котором учет рабочего времени сотрудников ведется суммарно за определенный период.
При этом продолжительность рабочего дня (включая обеденный перерыв) не может превышать 12 часов.
Исключается такая ситуация, когда решение о гибком графике принимается сотрудником предприятия в одностороннем порядке. Такой распорядок возможен на основе нормативных актов или при согласовании между руководством и работником.
Решение, как правило, не может быть принято без участия данного работника.
Примеры scrum-практик: оценки
Здесь не будет канонического/кошерного/ванильного Scrum’а, который описан Швабером и Сазерлендом, и про который можно почитать здесь:
. Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа.
Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска.
Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point.
Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном — она занимает 1 попугай, 1 story point.
Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.
Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point.
Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт.
Разновидности
Предоставление гибкого графика может происходить по-разному:
- Такой распорядок работы может быть предоставлен отдельному сотруднику с учетом возложенных на него задач.
- В некоторых случаях установление гибкого графика может относиться к отдельному подразделению. В таком случае данный режим работы может регламентироваться локальным нормативным актом или определяться правилами внутреннего распорядка.
Одним из применений данного графика может быть его предоставление матерям, которые имеют маленьких детей.
Особенности
Важно отметить, что предоставление гибкого или скользящего графика не меняет условий труда сотрудников, в связи с которыми нормируется, начисляется и выплачивается заработная плата.
Установление гибкого графика включает в себя следующие элементы:
- Отрезок времени в начале рабочего дня, в пределах которого разрешено изменять время начала рабочего дня.
- Промежуток в конце рабочего дня, когда работник может по своему решению окончить работу.
- Сотруднику дается возможность устанавливать начало обеденного перерыва, определять его продолжительность или разделять его на части. При этом необходимо учитывать, что его продолжительность не входит в рабочее время.
- Указание фиксированной нормы времени, которая относится к определенному временному периоду. Работник в обязательном порядке должен отработать суммарное количество рабочих часов за указанный промежуток времени.
Несмотря на определённую свободу при использовании гибкого графика, обычно не применяются варианты, когда длительность рабочего дня равна 10 часам или превышает данную величину.
В самых исключительных ситуациях продолжительность времени пребывания на работе доходит до 12 часов. В данном случае учитывается также время перерыва для приема пищи и отдыха.