Комментарии 27
Использовал такой квадрат для повседневных дел, идея со скрам доской интересная.
0
Немного смутило Срочные-неважные
0
А что именно? Это не я придумал.
По оси Y — Важность. Чтоб больше было понятно как мерить важность я оцениваю стоимость рисков или потерь в случае если задача не будет сделана.
По оси X — Срочность. Т.е. время после которого решение этой задачи уже не будет иметь значения.
Срочные неважные — задачи которые надо сделать срочно. например выставиться на какой-то ярмарке. Но они не очень важные для проекта т.к. там не очень большой профит ожидался.
По оси Y — Важность. Чтоб больше было понятно как мерить важность я оцениваю стоимость рисков или потерь в случае если задача не будет сделана.
По оси X — Срочность. Т.е. время после которого решение этой задачи уже не будет иметь значения.
Срочные неважные — задачи которые надо сделать срочно. например выставиться на какой-то ярмарке. Но они не очень важные для проекта т.к. там не очень большой профит ожидался.
+2
Не знаю, если дело срочно не важное — его можно не делать? А если несрочное важно то можно его не делать в этой итерации?
Вот и получается, что можно с тем же успехом поделить на две оригинальные группы — обязательное и желательное.
Вот и получается, что можно с тем же успехом поделить на две оригинальные группы — обязательное и желательное.
0
вот тут есть хорошая формула
www.vkuzmin.com/2010/08/blog-post_13.html
Спокойно Сам
Мусор Зам
т.е. если оно срочное но неважное лучше его быстренько на кого-то делегировать.
Даже если сделают не так как надо, то потери небольшие.
Если оно важное но не срочное, то моно его в фоновом режиме делать самому. Не торопясь и сконцентрировавшись на срочных важных.
В нашем же посте мы говорим о том что в процесс работы должны уходить первыми те задачи которые срочные важные.
И если в какой-то фиче полно срочно важных, а в какой-то другой таковых не осталось, то если есть возможность вероятно надо перераспределить ресурсы. И самое ценное это видно с одного взгляда.
www.vkuzmin.com/2010/08/blog-post_13.html
Спокойно Сам
Мусор Зам
т.е. если оно срочное но неважное лучше его быстренько на кого-то делегировать.
Даже если сделают не так как надо, то потери небольшие.
Если оно важное но не срочное, то моно его в фоновом режиме делать самому. Не торопясь и сконцентрировавшись на срочных важных.
В нашем же посте мы говорим о том что в процесс работы должны уходить первыми те задачи которые срочные важные.
И если в какой-то фиче полно срочно важных, а в какой-то другой таковых не осталось, то если есть возможность вероятно надо перераспределить ресурсы. И самое ценное это видно с одного взгляда.
0
Так доска то не для боса а для команды!
А если дела только срочно важные, это значит отсутствует управление проектом, а доска это скрывает.
А если дела только срочно важные, это значит отсутствует управление проектом, а доска это скрывает.
0
Я привел нашу ситуацию. Выход на рынок.
когда вы из двух человек должны стать в течении 2-3х месяцев как минимум командой из 10ти человек
их всех надо нанять потому что объем работы на каждую роль уже достаточный.
Надо параллельно искать людей и продолжать управлять продуктом.
т.к. поиск нужного человека не такое быстрое дело.
когда вы из двух человек должны стать в течении 2-3х месяцев как минимум командой из 10ти человек
их всех надо нанять потому что объем работы на каждую роль уже достаточный.
Надо параллельно искать людей и продолжать управлять продуктом.
т.к. поиск нужного человека не такое быстрое дело.
0
Я просто к чему это все. Квадратнт Эйзенхауэра это вещь, но у нее применение другое и вовсе не из этой оперы. А занятие тем как лучше еще раз перегрупировать задачи это как говорли у меня в университете ИБД.
0
ИБД?
Повторюсь.
На вас сваливается поток, который нельзя проигнорировать, его надо разгрести.
Новые задачи сыпятся десятками в день.
Их надо тут же маршрутизировать.
Повторюсь.
На вас сваливается поток, который нельзя проигнорировать, его надо разгрести.
Новые задачи сыпятся десятками в день.
Их надо тут же маршрутизировать.
0
Имитация Бурной Деятельности.
Доска тут НЕ помошник. Больше чем может сделать команда она сделать не может. Поэтому выделили на итерацию то что сделать реально из самого срочного и самого важного — это и есть ваше важное и срочное, то есть правый верхний квадрант, остальное убрали и вернетесь если останется время.
Доска тут НЕ помошник. Больше чем может сделать команда она сделать не может. Поэтому выделили на итерацию то что сделать реально из самого срочного и самого важного — это и есть ваше важное и срочное, то есть правый верхний квадрант, остальное убрали и вернетесь если останется время.
0
Надо отметить что в данном случае команда проекта построена по принципу схожему с принципами Тойоты (родоначальницы канбана) — все что можно аутсорсить надо аутсорсить.
Поэтому команда должна справляться с маршрутизацией задач и контролировать их исполнение.
Для этого все надо держать в голове и оперативно мониторить.
Т.е. команда и эта доска являются такми ЦУПом.
Например субподрядчики по приложению и по вебу могут схавать гораздо больший объем задач
Проблема в том что надо контролировать бюджет, и что особо важно выполнение некоторых задач не имеет смысла без выполнения задач в других потоках. И это можно видеть визуально.
Поэтому команда должна справляться с маршрутизацией задач и контролировать их исполнение.
Для этого все надо держать в голове и оперативно мониторить.
Т.е. команда и эта доска являются такми ЦУПом.
Например субподрядчики по приложению и по вебу могут схавать гораздо больший объем задач
Проблема в том что надо контролировать бюджет, и что особо важно выполнение некоторых задач не имеет смысла без выполнения задач в других потоках. И это можно видеть визуально.
0
Это например желание съесть печенюшку
+3
Что только люди не придумают, чтобы не использовать канбан :)
+3
:)
-1
Про канбан я прекрасно знаю, и использовал его гораздо раньше чем это слово появилось на хабре. т.к. являюсь адептом, консультантом и со-основателем консалтинговой компании спецаилизирующейся на Lean. Agile я практикую уже лет 12.
Канбан изначально придуман там, где идет поставка однотипных изделий.
А когда перед вам стоит такой спектр задач который вы даже охватить не в состоянии разом. Когда майнд-мап проекта становится настолько тяжелым что по нему неудобно осуществлять навигацию и очевидно что надо разбивать на несколько отдельных карт и раздавать на разных ответственных лиц. Тогда вам надо разделять и классифицировать задачи.
Если вы внимательно читали, то я написал что на выходе из квадранта дальше зачастую и идет канбан.
Квадрант тут решает задачу выбора таска на подачу в прцесс исполнения.
Канбан изначально придуман там, где идет поставка однотипных изделий.
А когда перед вам стоит такой спектр задач который вы даже охватить не в состоянии разом. Когда майнд-мап проекта становится настолько тяжелым что по нему неудобно осуществлять навигацию и очевидно что надо разбивать на несколько отдельных карт и раздавать на разных ответственных лиц. Тогда вам надо разделять и классифицировать задачи.
Если вы внимательно читали, то я написал что на выходе из квадранта дальше зачастую и идет канбан.
Квадрант тут решает задачу выбора таска на подачу в прцесс исполнения.
0
А чем квадрант в данном случае отличается от приоритетов в канбане (точнее его айтишном варианте)?
+1
Фактически это одно и тоже. Просто такой способ визуализации.
Мы раньше пробовали визуализировать приоритет цветами, но это оказалось неудобно и все забили на это.
В частности на стикерах видно несколько колонок и одна из них как раз и есть приоритет из багтрекера.
Есть одно кардинальное отличие которое помогает решить матрица.
Вы можете оперативно и понятным образом переигрывать приоритеты.
Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
И все надо сделать вчера.
Если хорошенько потрясти продукт овнера он вам все-таки скажет что некоторые задачи равнее других.
Мы раньше пробовали визуализировать приоритет цветами, но это оказалось неудобно и все забили на это.
В частности на стикерах видно несколько колонок и одна из них как раз и есть приоритет из багтрекера.
Есть одно кардинальное отличие которое помогает решить матрица.
Вы можете оперативно и понятным образом переигрывать приоритеты.
Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
И все надо сделать вчера.
Если хорошенько потрясти продукт овнера он вам все-таки скажет что некоторые задачи равнее других.
0
> Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
использовать стандартные багтреккеры для канбана — естественно, не «комильфо», и потому неудобно. А вот что-то типа trello — очень даже, тогда решается вопрос, уровней приоритета, просто перетаскивается наверх задча, саими PO как вариант, он сам знает, что ему важнее.
использовать стандартные багтреккеры для канбана — естественно, не «комильфо», и потому неудобно. А вот что-то типа trello — очень даже, тогда решается вопрос, уровней приоритета, просто перетаскивается наверх задча, саими PO как вариант, он сам знает, что ему важнее.
0
вот тут habrahabr.ru/post/120517/ хорошо показано
и стикеры можно прямо вот так по карте расположить
и брать в работу тот который максимально близко к правому верхнему углу находится
и стикеры можно прямо вот так по карте расположить
и брать в работу тот который максимально близко к правому верхнему углу находится
0
Если у вас разработка похожа на военные действия, то действительно Матрица Эйзенхауэра как вы говорите «очень хороший инструмент привести голову в порядок». В современных компаниях клиенты и сотрудники — это лояльные партнёры, а вы изначально планируете с ними работу как с вражескими противниками.
В итоге вся эта схема лично у меня рождает только одну ассоциацию: http://img5.joyreactor.cc/pics/post/fuuuu-auto-83005.jpeg
Хватит уже перекладывать бумажки из одного квадрата в другой, от одного сотрудника к другому :-(.
В итоге вся эта схема лично у меня рождает только одну ассоциацию: http://img5.joyreactor.cc/pics/post/fuuuu-auto-83005.jpeg
Хватит уже перекладывать бумажки из одного квадрата в другой, от одного сотрудника к другому :-(.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SCRUM board + Квадрант Эйзенхауэра для управления продуктом