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