Мы добавляем блокер в том случае, если над задачей полностью прекращена работа. Как именно это делать - уже зависит от таск-трекера. Например в jira делали флажком, сейчас используем кайтен и там есть функционал установки блока другой карточкой.
Если говорить о том, что канбан-доска визуализирует ваш процесс, то точно у вас в процессе есть пауза? Мне больше нравится блокировка задачи на том этапе процесса, на котором она случилась. И блокер так же показывает, что мы делаем что-то не так. А регулярная работа с блокерами, их кластеризация и оценка влияния, позволяет вносить изменения в работу всей системы, минимизируя частоту их возникновения
Очень печально видеть такой уровень подготовки материала от компании разрабатывающей таск-трекер. Канбан Тойоты (используемый в материальном производстве) и канбан-метод (используемый в нематериальном производстве) - абсолютно разные вещи, а вы их объединяете. Про то, что канбан-метод вынесен из под зонтиков lean и agile я молчу
Я тут говорю в контексте различия Product Owner и Product Manager. Product Owner (владелец продукта) – это чисто скрамовская роль, предполагающая очень конкретный круг задач в рамках этого фреймворка, и не более того. А вот Product Manager (менеджер продукта) – это уже про управление продуктом как таковым без привязки к способу/методу разработки. На нем и работа с рынком и с пользователями, продвижение продукта в различных каналах и прочее
Включая режим душнилы хочется сказать, что Product Owner - это исключительно роль фреймворка Scrum. И если у вас не Scrum, то выходит, что у вас должен быть какой то другой менеджер - видимо Product Manager.
Зависит от контекста задачи. Можем привлекать лидов направлений (разработки, QA, etc), а не всю команду. Открытые вопросы могут закрывать различные роли: БА, СА, РО, деливери или любой другой член команды, который может помочь
Я являюсь деливери лидом в рамках "большого продукта". Тут больше идет именно процессная работа. Дополнительно - работа с деливери, работающими в командах и решение различных проблем, которые мешают движению задач дальше по потоку.
Я являюсь деливери в одной из команд. Тут, помимо процессной части, идет непосредственная работа с командой, с людьми в команде, решение проблем с инфраструктурой, душевные диалоги с ИБ и т.п.
Также "подрабатываю" OKR-коучем в продукте. Тут на мне ведение всего процесса OKR: ретроспективы, формирование OKR, синхронизация и выравнивание OKR и т.п.
Сейчас у нас достаточно простой flow. Т.к. команда одна, то и люди в двух процессах участвуют практически одни и те же. На данный момент задача discovery — сократить уровень неопределенности и понять возможные риски. На этом этапе мы подготавливаем верхнеуровневое описание требований, смотрим на них с архитектором, понимаем, какие могут быть зависимости и как задача может декомпозироваться. После чего обсуждаем с РО и заказчиками дальнейшую судьбу инициативы. Либо она отменяется (понимаем, что делать не надо), либо принимается решение, что делать надо и тогда инициатива попадает в бэклог деливери. Тут еще можно рассказать про роль OKR во всем этом процессе, но это на отдельную статью выйдет))
Все, кому хочется))) Выставление тегов не регламентировано, поэтому в реальности добавить какие-то свои теги могут любые заинтересованные. Нам, как деливери, важно отслеживать теги, которые показывают систему/команду, в которой должна быть реализована задача. И для некоторых задач еще выставляем тег типа, к которому относится рабочий элемент, чтобы более точно давать оценки сроков, а не причесывать все задачи под одну гребенку.
Если уж быть совсем честным, то Голдратт говорил о другом. Нет необходимости сразу расширять узкое место. Первое, что нужно сделать - подчинить всю производственную систему работе с узким местом. Узкое место должно работать со 100% загрузкой и перед ним всегда должен находиться некий буфер запасов/задач/etc, а вся остальная система может работать с меньшей загрузкой, нет смысла нагружать ее на 100%. К тому же узкое место надо освободить от любой другой непрофильной работы, оно должно выполнять только возложенные на него обязанности
"Расшивая" каждый раз узкие места, вы будете ловить их в других местах - закон физики, от которого не уйти. К тому же "расшивание" узких мест может быть для бизнеса крайне дорогим удовольствием, нежели подчинении всего производственного процесса работе с узким местом.
P.S.: Пример с логотипом, в контексте узких звеньев, вообще не понял
Когда работа и дом находятся на определенном удалении, то нереализуемо. Я живу в 100км от работы, поэтому приходится таскать рюкзак с собой. Правда я ни разу не забывал, тьфу-тьфу-тьфу.
Спасибо за статью. Большую часть уже знал, но нашел и новое для себя. Сейчас нахожусь «в активном поиске» хорошего таск-менеджера. Пока остановился на связке todoist+toggl (не реклама). Вроде все устраивает, но есть чувство, что чего то не хватает. Можете (можно и личку) написать, чем пользуетесь Вы?
Такая же ситуация. Но я решил быть более настойчивым. На следующий день, когда на карточку упала ЗП, сделал повторный запрос. В итоге одобрили 20К овердрафта)))
Эта фича уже более 2 лет в вебмастере. После разбора YML, в выдаче Яндекс.Поиск появляется товар уже с ценой. Возможно это и хорошо, если ваш сайт на первой странице. Особого роста конверсии на размещаемых сайтах я не заметил.
Мы добавляем блокер в том случае, если над задачей полностью прекращена работа. Как именно это делать - уже зависит от таск-трекера. Например в jira делали флажком, сейчас используем кайтен и там есть функционал установки блока другой карточкой.
Если говорить о том, что канбан-доска визуализирует ваш процесс, то точно у вас в процессе есть пауза? Мне больше нравится блокировка задачи на том этапе процесса, на котором она случилась. И блокер так же показывает, что мы делаем что-то не так. А регулярная работа с блокерами, их кластеризация и оценка влияния, позволяет вносить изменения в работу всей системы, минимизируя частоту их возникновения
Очень печально видеть такой уровень подготовки материала от компании разрабатывающей таск-трекер. Канбан Тойоты (используемый в материальном производстве) и канбан-метод (используемый в нематериальном производстве) - абсолютно разные вещи, а вы их объединяете. Про то, что канбан-метод вынесен из под зонтиков lean и agile я
молчуЯ тут говорю в контексте различия Product Owner и Product Manager. Product Owner (владелец продукта) – это чисто скрамовская роль, предполагающая очень конкретный круг задач в рамках этого фреймворка, и не более того. А вот Product Manager (менеджер продукта) – это уже про управление продуктом как таковым без привязки к способу/методу разработки. На нем и работа с рынком и с пользователями, продвижение продукта в различных каналах и прочее
Включая режим душнилы хочется сказать, что Product Owner - это исключительно роль фреймворка Scrum. И если у вас не Scrum, то выходит, что у вас должен быть какой то другой менеджер - видимо Product Manager.
Зависит от контекста задачи. Можем привлекать лидов направлений (разработки, QA, etc), а не всю команду. Открытые вопросы могут закрывать различные роли: БА, СА, РО, деливери или любой другой член команды, который может помочь
Спасибо за вопросы. Отвечу по пунктам
Конкретно у меня пул работ достаточно обширный:
Я являюсь деливери лидом в рамках "большого продукта". Тут больше идет именно процессная работа. Дополнительно - работа с деливери, работающими в командах и решение различных проблем, которые мешают движению задач дальше по потоку.
Я являюсь деливери в одной из команд. Тут, помимо процессной части, идет непосредственная работа с командой, с людьми в команде, решение проблем с инфраструктурой, душевные диалоги с ИБ и т.п.
Также "подрабатываю" OKR-коучем в продукте. Тут на мне ведение всего процесса OKR: ретроспективы, формирование OKR, синхронизация и выравнивание OKR и т.п.
Сейчас у нас достаточно простой flow. Т.к. команда одна, то и люди в двух процессах участвуют практически одни и те же. На данный момент задача discovery — сократить уровень неопределенности и понять возможные риски. На этом этапе мы подготавливаем верхнеуровневое описание требований, смотрим на них с архитектором, понимаем, какие могут быть зависимости и как задача может декомпозироваться. После чего обсуждаем с РО и заказчиками дальнейшую судьбу инициативы. Либо она отменяется (понимаем, что делать не надо), либо принимается решение, что делать надо и тогда инициатива попадает в бэклог деливери. Тут еще можно рассказать про роль OKR во всем этом процессе, но это на отдельную статью выйдет))
Все, кому хочется))) Выставление тегов не регламентировано, поэтому в реальности добавить какие-то свои теги могут любые заинтересованные. Нам, как деливери, важно отслеживать теги, которые показывают систему/команду, в которой должна быть реализована задача. И для некоторых задач еще выставляем тег типа, к которому относится рабочий элемент, чтобы более точно давать оценки сроков, а не причесывать все задачи под одну гребенку.
Если уж быть совсем честным, то Голдратт говорил о другом. Нет необходимости сразу расширять узкое место. Первое, что нужно сделать - подчинить всю производственную систему работе с узким местом. Узкое место должно работать со 100% загрузкой и перед ним всегда должен находиться некий буфер запасов/задач/etc, а вся остальная система может работать с меньшей загрузкой, нет смысла нагружать ее на 100%. К тому же узкое место надо освободить от любой другой непрофильной работы, оно должно выполнять только возложенные на него обязанности
"Расшивая" каждый раз узкие места, вы будете ловить их в других местах - закон физики, от которого не уйти. К тому же "расшивание" узких мест может быть для бизнеса крайне дорогим удовольствием, нежели подчинении всего производственного процесса работе с узким местом.
P.S.: Пример с логотипом, в контексте узких звеньев, вообще не понял