Комментарии 7
Это правило нужно, чтобы эффективно расходовать рабочее время команды. И терпение.
Каким бы радужным ни пытался сделать наш мир Scrum, на практике на daily во время выступления одного члена команды его слушает не вся оставшаяся команда, а 1-2 человека. Остальные просто ждут своей очереди. Обычно для команд в 10 человек такие daily длятся от получаса до часа, что означает, что большая часть команды большую часть этого часа просто сидит и кукует. Перевод в текстовый формат делает daily быстрыми, лаконичными и, ко всему прочему, зафиксированными.
Хочется спросить — а вы прям по 8 часов в день работаете, не разгибая спины? И поэтому экономия 20 минут в день так важна?
А вы из тех, кто любит на дейли эти 20 минут покуковать?) Не хотите, чтобы манагеры эти 20 минут блаженного времени у вас отнимали?)
Отвечая на вопрос.
Во первых, экономия в среднем начинается от 20 минут.
Для команд размером в 8-10-12 человек экономия времени стремится к 40 минутам.
Скажем, если 4 человека в команде по 30 минут в день делают непонятно что во время дейли, то суммарно на команду потеря человеческого времени равняется 2 часам в день. В неделю это 10 выкинутых человеко-часов.
Отсюда получаем во вторых — зачем сжигать чье-то время, когда можно этого не делать?
Тут же вспомним, что это время еще и кто-то оплачивает. Получается, сжигается не только время сотрудника, но и деньги компании. В пустую, в никуда.
В третьих (причем не по важности), речь не только о времени. Но и о настрое. Если взять какую-то произвольную команду, снять с себя розовые очки, то окажется, что около половины команды в гробу видали дейли в формате stand up. И эти дейли им действуют на нервы, что в свою очередь в течение некоторого времени перед/после дейли отражается на их рабочем настрое, который в свою очередь бьет по эффективности.
Ответил на вопрос?
Отвечая на вопрос.
Во первых, экономия в среднем начинается от 20 минут.
Для команд размером в 8-10-12 человек экономия времени стремится к 40 минутам.
Скажем, если 4 человека в команде по 30 минут в день делают непонятно что во время дейли, то суммарно на команду потеря человеческого времени равняется 2 часам в день. В неделю это 10 выкинутых человеко-часов.
Отсюда получаем во вторых — зачем сжигать чье-то время, когда можно этого не делать?
Тут же вспомним, что это время еще и кто-то оплачивает. Получается, сжигается не только время сотрудника, но и деньги компании. В пустую, в никуда.
В третьих (причем не по важности), речь не только о времени. Но и о настрое. Если взять какую-то произвольную команду, снять с себя розовые очки, то окажется, что около половины команды в гробу видали дейли в формате stand up. И эти дейли им действуют на нервы, что в свою очередь в течение некоторого времени перед/после дейли отражается на их рабочем настрое, который в свою очередь бьет по эффективности.
Ответил на вопрос?
Сначала немного завидовал организации, а потом как-то стало страшновато от количества правил и каналов. Но кое-что попробую позаимствовать. Жаль Телеграм, в котором у нас коммуникации, не имеет таких фич, как реакции (блин, они даже в Скайпе есть) и треды (пускай и не идеальные они в Слаке).
Вообще начал Телеграмом пользоваться активно совсем недавно и не понимаю чего все от него в таком восторге.
Телеграм — я его обожаю за стикеры и гифки :D
Что касается количества правил — у нас они step by step появлялись.
Каждый раз, как мы обнаруживали какую-то проблему — появлялось какое-то правило или практика, нейтрализующие эту проблему. Такие крупные конструкции из правил/практик не сразу появляются, а по-тихоньку, с течением времени, поэтому на практике изнутри это все не кажется чем-то накрученным.
В каждой команде есть свои проблемы, для ликвидации которых нужны свои правила и практики. Поэтому, я постарался писать эту статью не как «мануал», а как наш опыт.
И постарался изложить таким образом, чтобы написанные правила/практики были отделимы друг от друга, и как следствие каждый мог стырить то, что ему понравилось. Как на шведском столе.
Надеюсь вам удастся найти на этом шведском столе что-то, что сделает жизнь вашей команды лучше.
Что касается количества правил — у нас они step by step появлялись.
Каждый раз, как мы обнаруживали какую-то проблему — появлялось какое-то правило или практика, нейтрализующие эту проблему. Такие крупные конструкции из правил/практик не сразу появляются, а по-тихоньку, с течением времени, поэтому на практике изнутри это все не кажется чем-то накрученным.
В каждой команде есть свои проблемы, для ликвидации которых нужны свои правила и практики. Поэтому, я постарался писать эту статью не как «мануал», а как наш опыт.
И постарался изложить таким образом, чтобы написанные правила/практики были отделимы друг от друга, и как следствие каждый мог стырить то, что ему понравилось. Как на шведском столе.
Надеюсь вам удастся найти на этом шведском столе что-то, что сделает жизнь вашей команды лучше.
Спасибо автору за полезный материал. Для себя отметила два больших раздела в подходе: методологию организованности и настройку инструментов.
Будучи совсем не из ИТ, для простолюдина скажем так, некоторые манипуляции со Slack и Jira показались сложными. Для себя в качестве эксперимента попробую настроить по схожему принципу Discord (просто он мне ближе и знаком, а Slack и Jira еще нужно будет изучить).
Проекты можно создавать в виде «серверов» и приглашать туда людей. Внутри можно сделать деление на каналы по аналогии как в посте. В переписке каждого канала так же можно пользоваться общеустановленными тегами, определять людей в группы и отмечать (хоть конкретного человека, хоть группу), назначать права доступа и оставлять эмоджи сообщениям (например при прочтении или голосовании за какой-то вариант).
Возможно изобрела велосипед, если кто-то уже пробовал нечто похожее в дискорде поделитесь опытом и мнением. Как оно получилось и является ли такой вариант альтернативой приведенному автором примеру?)
Будучи совсем не из ИТ, для простолюдина скажем так, некоторые манипуляции со Slack и Jira показались сложными. Для себя в качестве эксперимента попробую настроить по схожему принципу Discord (просто он мне ближе и знаком, а Slack и Jira еще нужно будет изучить).
Проекты можно создавать в виде «серверов» и приглашать туда людей. Внутри можно сделать деление на каналы по аналогии как в посте. В переписке каждого канала так же можно пользоваться общеустановленными тегами, определять людей в группы и отмечать (хоть конкретного человека, хоть группу), назначать права доступа и оставлять эмоджи сообщениям (например при прочтении или голосовании за какой-то вариант).
Возможно изобрела велосипед, если кто-то уже пробовал нечто похожее в дискорде поделитесь опытом и мнением. Как оно получилось и является ли такой вариант альтернативой приведенному автором примеру?)
После трехдневной профилактики, когда не заходил ни в какие чаты, с любопытством обнаружил, что любые инстант мессенджеры просто разрывают в клочья рабочий процесс. Теперь, если нужно обсудить вопрос, идем в дискорд, шарим экраны и фокусно решаем задачу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто владеет информацией — тот владеет миром. Как организовать коммуникацию и распространение информации на проекте?