Size: a a a

SPb SPM: Software Managers Club

2020 June 02

VZ

Vadim Zhivotovsky in SPb SPM: Software Managers Club
Ivan Selikhovkin
Насколько знаю консенсус в индустрии = focus factor должен быть в районе 0,6 - 0,8. Если ниже - обычно значит что в команде есть что улучшать
Нерепрезентативно, но всё же ещё один пример. В этом году на Хабре проскочила статья с голосовалкой ровно по этому вопросу - сколько % рабочего времени у вас уходит непосредственно на работу. Несколько сотен человек поучаствовало. Насколько помню, подавляющее большинство было  в районе 40-60%.
источник

MV

Mikhail Vyazov in SPb SPM: Software Managers Club
Denis Kachnov
Возможно, лучшим вариантом будет считать эффективный рабочий день ~6 часов. Это значение использовать при планировании.
Счет выставлять за полный день 8 часов либо увеличить цену часа пропорционально.
ну да, так и делаем сейчас :) + к "неэффективному" времени добавляем еще прогнозируемое время на доработку/правки, которые практически всегда бывают после сдачи задачи в тестирование. это просто к тому, что странно до сих пор видеть, что есть РП/руководители, которые требуют чистую 8 часовую выработку в день
источник
2020 June 03

СС

Станислав Сваричевск... in SPb SPM: Software Managers Club
Mikhail Vyazov
Подскажите пожалуйста, есть ли у вас информация сколько люди работают по факту? Т е с необходимым отдыхом и отвлечениями?
В офисе по учету по карточкам из 8 рабочих часов минимально работают 5 часов. В среднем где-то 6. Без учета что там делается на компьютере. Имеются ввиду часы работы за компьютерами. Остальные часы, это пойти в столовку за кофем, попить, потом пойти на улицу покурить, снова запить курево кофе и печенюшками, поболтать, налить чай для рабочего места, перерывчик на настольный теннис и т. п. не считая обеда (с обедом 9 часов рабочий день)

В почасовой удаленной схеме все работают по 8 часов эффективных. Но не подряд, а когда захотят, главное чтобы в неделю было не менее 40 часов (точней примерно 1980 часов в год). В принципе много лет работаем с удаленщиками по такой схеме и проблем с теми кто прошел испытательный срок не было ни разу. По трекеру видно что многие удаленщики выбирают для себя офисный график и уходит на работу около 9.5 - 10 часов с учетом их перерывов. (Против 9 в офисе).

Есть противники и того и того. Кто-то не хочет ехать в офис по часовым пробкам и им кайф дома, а кто-то не может дома с 3мя маленькими детьми работать вообще и стремиться в офис.
источник

СС

Станислав Сваричевск... in SPb SPM: Software Managers Club
Работа на дому эффективна для профи. Но в офисе сильно эффективней повышение скила новичков. На удаленке требуется отдельно этим заниматься и выстраивать процессы.
источник

MV

Mikhail Vyazov in SPb SPM: Software Managers Club
Станислав Сваричевский
В офисе по учету по карточкам из 8 рабочих часов минимально работают 5 часов. В среднем где-то 6. Без учета что там делается на компьютере. Имеются ввиду часы работы за компьютерами. Остальные часы, это пойти в столовку за кофем, попить, потом пойти на улицу покурить, снова запить курево кофе и печенюшками, поболтать, налить чай для рабочего места, перерывчик на настольный теннис и т. п. не считая обеда (с обедом 9 часов рабочий день)

В почасовой удаленной схеме все работают по 8 часов эффективных. Но не подряд, а когда захотят, главное чтобы в неделю было не менее 40 часов (точней примерно 1980 часов в год). В принципе много лет работаем с удаленщиками по такой схеме и проблем с теми кто прошел испытательный срок не было ни разу. По трекеру видно что многие удаленщики выбирают для себя офисный график и уходит на работу около 9.5 - 10 часов с учетом их перерывов. (Против 9 в офисе).

Есть противники и того и того. Кто-то не хочет ехать в офис по часовым пробкам и им кайф дома, а кто-то не может дома с 3мя маленькими детьми работать вообще и стремиться в офис.
А что вы делаете с выгоранием? Вообще есть ли такая проблема?
источник
2020 June 04

СС

Станислав Сваричевск... in SPb SPM: Software Managers Club
Mikhail Vyazov
А что вы делаете с выгоранием? Вообще есть ли такая проблема?
нет такой проблемы. Наоборот, когда доходят до топового уровня, могут уходить в компании с более высоким окладом, но это к выгоранию не относиться. На удалёнке вообще никто не уходит более 6 лет. Это не касается ротации на испытательном сроке, где отсеиваются неподходящие сотрудники.
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Ivan Selikhovkin
Не в agile, а в Скрам. :) Agile он разный.

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

ST

Sergey Titkov in SPb SPM: Software Managers Club
Mikhail Vyazov
Спасибо, коллеги! Значит, чтобы абсолютно добросовестно говорить, что разработчик/дизайнер выработал 8 часов, он по факту должен работать не меньше 10. Вероятно, все 11. Или что то не так понимаю? Просто не очень опытный ПМ. Всегда казалось, что такой режим приводит к сильному выгоранию и уходу разработчиков "с галеры".  Есть ли какой то опыт борьбы с выгоранием команд, раз уж выбрали этот подход?
Тебе что важно выработка или результат?
Если часы списать, вот коллеги рассказали как.

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

И эти два подхода не смешиваются, либо одно, либо другое.
источник

IS

Ivan Selikhovkin in SPb SPM: Software Managers Club
Например в канбан анализ  производительности позволяет установить более адекватный wip-лимит для каждой роли (столбца) в канбан-системе. И в целом канбан очень сильно метрико-ориентирован во всех смыслах. И это только в плюс. Оттого что вы измерили производительность человека, звена, пары программистов и т.п. вы только стали обладателем доп. информации (что всегда полезно). Смещение фокуса и разброс в сто раз - это чистая эмоция. Извращения возможны в любой системе и при любом подходе. Задача грамотного менеджера из избегать :)
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Ivan Selikhovkin
Например в канбан анализ  производительности позволяет установить более адекватный wip-лимит для каждой роли (столбца) в канбан-системе. И в целом канбан очень сильно метрико-ориентирован во всех смыслах. И это только в плюс. Оттого что вы измерили производительность человека, звена, пары программистов и т.п. вы только стали обладателем доп. информации (что всегда полезно). Смещение фокуса и разброс в сто раз - это чистая эмоция. Извращения возможны в любой системе и при любом подходе. Задача грамотного менеджера из избегать :)
Иван я ведь не зря сказал про два порядка:)
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Мы мерили :)
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Даже на сильно атамарных задачах получаем разброс на порядок
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
И ящик с усами построили
источник

IS

Ivan Selikhovkin in SPb SPM: Software Managers Club
Разброс производительности в сто раз. Проблема точно не в квалификации / понимании задачи? :)
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Ivan Selikhovkin
Разброс производительности в сто раз. Проблема точно не в квалификации / понимании задачи? :)
Для некоторых типов задач да.
Для брльшинства от 10 до 30
источник

MF

Maxi Frolof in SPb SPM: Software Managers Club
Ivan Selikhovkin
Например в канбан анализ  производительности позволяет установить более адекватный wip-лимит для каждой роли (столбца) в канбан-системе. И в целом канбан очень сильно метрико-ориентирован во всех смыслах. И это только в плюс. Оттого что вы измерили производительность человека, звена, пары программистов и т.п. вы только стали обладателем доп. информации (что всегда полезно). Смещение фокуса и разброс в сто раз - это чистая эмоция. Извращения возможны в любой системе и при любом подходе. Задача грамотного менеджера из избегать :)
Прошу прощения, что вмешиваюсь, но в канбан системах столбцы - это не роли, а дискретные активности по накоплению знаний. Лимит ставится на них и исследуются они, а не люди
источник

IS

Ivan Selikhovkin in SPb SPM: Software Managers Club
Maxi Frolof
Прошу прощения, что вмешиваюсь, но в канбан системах столбцы - это не роли, а дискретные активности по накоплению знаний. Лимит ставится на них и исследуются они, а не люди
Так. А кто выполняет дискретные активности?
источник

ST

Sergey Titkov in SPb SPM: Software Managers Club
Ivan Selikhovkin
Разброс производительности в сто раз. Проблема точно не в квалификации / понимании задачи? :)
Вот можем тут чат померить :) и посмотреть разброс :)
источник

IS

Ivan Selikhovkin in SPb SPM: Software Managers Club
Иначе можно сказать что и скрам команда оценивает не свою производительность а выполнение дискретных активностей :)
источник

IS

Ivan Selikhovkin in SPb SPM: Software Managers Club
Sergey Titkov
Вот можем тут чат померить :) и посмотреть разброс :)
Можем? :))
источник