SCRUM board + Квадрант Эйзенхауэра для управления продуктом

    Думаю, что большинство тех, кто внедрял у себя в командах тот или иной инструмент (особенно, если он родом из страны с другой ментальностью) согласиться, что внедрение не всегда проходит гладко. Однажды один академик мне сказал: «Ну а как ты хотел? Внедрение — это по определению вторжение чужеродного объекта в тело. Должно быть оСВОЕние. Делание своим!». С тех пор, для меня осознание того, что инструмент работает не совсем так, как задумывалось — является лучшим признаком освоения. Команда или сотрудник модернизировали по своему и начали использовать. И еще лучше, когда команда берет два разных инструмента и сама комбинирует их. Так произошло и в этот раз.

    Из названия топика и картинки суть идеи будет сразу понятной. Ну а за подробностями, и связью с управлением продуктом, прошу под кат…




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

    Вот примерно так я объяснял действие квадранта нашему руководителю стартапа (Вика, 23 года). И мы вместе разбирались с лавиной задач, которые свалились на нее в преддверии боевого запуска проекта на рынок (бета-тестирование пройдено). Ведь, до этого мы тихонько пилили какой-то проектик, а тут сразу: делать колцентр, нанимать людей, рекламная кампания, делать приложения для мобильных платформ, редизайн веба,… и все срочно, все вчера.

    Так мы разобрались на примере с частью задач, которые были уже описаны. Понятно? Понятно! Дальше надо также систематизировать и разобраться с остальными задачами самостоятельно. Прихожу через пару дней в офис и вижу одну из наших скрам досок в странном состоянии.
    Вика встроила квадрант в первый этап на скрам-доске.

    На скрам-доске большие горизонтальные секции разделяют задачи по фичам.
    В первой вертикальной секции «план» — фича разделена на квадрант «срочные-важные».
    Это помогает визуализировать приоритеты и важность задач.
    На основании этого можно удобно балансировать ресурс между фичами.



    В итого у нас получилась очень полезная стратегическая доска для управления продуктом. Можно сказать, визуальное представление продукт-баклога. По факту больше канбан, чем скрам, т.к. четкие такты невозможно соблюсти везде (например, в найме), но разные фичи могут идти отдельно либо по скраму, либо по канбану.
    Например, разработка веб-приложения и мобильного приложения — это разные фичи с тактами.
    Решили попробовать этот инструмент перенести и в разработку других проектов.
    Думали о том, надо ли вставлять квадрант в другие колонки. Например, в «DO — в процессе» это было бы актуально для фичи, в которой могут быть длительные процессы.

    Мы продолжаем этот интересный эксперимент.
    Очень интересны ваши мысли по этому поводу.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 27
      0
      Использовал такой квадрат для повседневных дел, идея со скрам доской интересная.
        0
        Как по вашему мнению, стоит ли добавлять квадрант в колонки DO, TEST, DEMO (Check, ...)?
        Мне показалось что будет визуальный шум.
          0
          Думаю что квадрата на первое время достаточно для задач в TODO, дальше надо экспериментировать
        0
        Немного смутило Срочные-неважные
          +2
          А что именно? Это не я придумал.
          По оси Y — Важность. Чтоб больше было понятно как мерить важность я оцениваю стоимость рисков или потерь в случае если задача не будет сделана.
          По оси X — Срочность. Т.е. время после которого решение этой задачи уже не будет иметь значения.

          Срочные неважные — задачи которые надо сделать срочно. например выставиться на какой-то ярмарке. Но они не очень важные для проекта т.к. там не очень большой профит ожидался.
            0
            Не знаю, если дело срочно не важное — его можно не делать? А если несрочное важно то можно его не делать в этой итерации?
            Вот и получается, что можно с тем же успехом поделить на две оригинальные группы — обязательное и желательное.
              0
              вот тут есть хорошая формула
              www.vkuzmin.com/2010/08/blog-post_13.html

              Спокойно Сам
              Мусор Зам

              т.е. если оно срочное но неважное лучше его быстренько на кого-то делегировать.
              Даже если сделают не так как надо, то потери небольшие.

              Если оно важное но не срочное, то моно его в фоновом режиме делать самому. Не торопясь и сконцентрировавшись на срочных важных.
              В нашем же посте мы говорим о том что в процесс работы должны уходить первыми те задачи которые срочные важные.
              И если в какой-то фиче полно срочно важных, а в какой-то другой таковых не осталось, то если есть возможность вероятно надо перераспределить ресурсы. И самое ценное это видно с одного взгляда.
                0
                Так доска то не для боса а для команды!
                А если дела только срочно важные, это значит отсутствует управление проектом, а доска это скрывает.
                  0
                  Я привел нашу ситуацию. Выход на рынок.
                  когда вы из двух человек должны стать в течении 2-3х месяцев как минимум командой из 10ти человек
                  их всех надо нанять потому что объем работы на каждую роль уже достаточный.
                  Надо параллельно искать людей и продолжать управлять продуктом.
                  т.к. поиск нужного человека не такое быстрое дело.
                  0
                  Я просто к чему это все. Квадратнт Эйзенхауэра это вещь, но у нее применение другое и вовсе не из этой оперы. А занятие тем как лучше еще раз перегрупировать задачи это как говорли у меня в университете ИБД.
                    0
                    ИБД?

                    Повторюсь.
                    На вас сваливается поток, который нельзя проигнорировать, его надо разгрести.
                    Новые задачи сыпятся десятками в день.
                    Их надо тут же маршрутизировать.
                      0
                      Имитация Бурной Деятельности.
                      Доска тут НЕ помошник. Больше чем может сделать команда она сделать не может. Поэтому выделили на итерацию то что сделать реально из самого срочного и самого важного — это и есть ваше важное и срочное, то есть правый верхний квадрант, остальное убрали и вернетесь если останется время.
                        0
                        Надо отметить что в данном случае команда проекта построена по принципу схожему с принципами Тойоты (родоначальницы канбана) — все что можно аутсорсить надо аутсорсить.
                        Поэтому команда должна справляться с маршрутизацией задач и контролировать их исполнение.
                        Для этого все надо держать в голове и оперативно мониторить.
                        Т.е. команда и эта доска являются такми ЦУПом.

                        Например субподрядчики по приложению и по вебу могут схавать гораздо больший объем задач
                        Проблема в том что надо контролировать бюджет, и что особо важно выполнение некоторых задач не имеет смысла без выполнения задач в других потоках. И это можно видеть визуально.
              +3
              Это например желание съесть печенюшку
                0
                Если при этом вы еще не ели 7 дней, то оно может оказаться еще и жизнено-важным :-)
              +3
              Что только люди не придумают, чтобы не использовать канбан :)
                –1
                :)
                  0
                  Про канбан я прекрасно знаю, и использовал его гораздо раньше чем это слово появилось на хабре. т.к. являюсь адептом, консультантом и со-основателем консалтинговой компании спецаилизирующейся на Lean. Agile я практикую уже лет 12.

                  Канбан изначально придуман там, где идет поставка однотипных изделий.
                  А когда перед вам стоит такой спектр задач который вы даже охватить не в состоянии разом. Когда майнд-мап проекта становится настолько тяжелым что по нему неудобно осуществлять навигацию и очевидно что надо разбивать на несколько отдельных карт и раздавать на разных ответственных лиц. Тогда вам надо разделять и классифицировать задачи.

                  Если вы внимательно читали, то я написал что на выходе из квадранта дальше зачастую и идет канбан.
                  Квадрант тут решает задачу выбора таска на подачу в прцесс исполнения.

                    +1
                    А чем квадрант в данном случае отличается от приоритетов в канбане (точнее его айтишном варианте)?
                      0
                      Фактически это одно и тоже. Просто такой способ визуализации.
                      Мы раньше пробовали визуализировать приоритет цветами, но это оказалось неудобно и все забили на это.
                      В частности на стикерах видно несколько колонок и одна из них как раз и есть приоритет из багтрекера.

                      Есть одно кардинальное отличие которое помогает решить матрица.
                      Вы можете оперативно и понятным образом переигрывать приоритеты.
                      Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
                      И все надо сделать вчера.
                      Если хорошенько потрясти продукт овнера он вам все-таки скажет что некоторые задачи равнее других.
                        0
                        > Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?

                        использовать стандартные багтреккеры для канбана — естественно, не «комильфо», и потому неудобно. А вот что-то типа trello — очень даже, тогда решается вопрос, уровней приоритета, просто перетаскивается наверх задча, саими PO как вариант, он сам знает, что ему важнее.
                          0
                          Ну вот смысл матрицы в том что она добавляет еще одно измерение.
                          Просто вверх или низ конечно же лучше чем просто хаос.
                          Но разброс по плоскости дает больше информации для принятия решения человеком.
                          Безусловно это нужно не всегда.
                        0
                        вот тут habrahabr.ru/post/120517/ хорошо показано
                        и стикеры можно прямо вот так по карте расположить
                        и брать в работу тот который максимально близко к правому верхнему углу находится
                          0
                          Зачем на доску вешать мусор из трех других квадрантов?
                            0
                            Ну оно по сути мусором не является и «крайне желательно чтоб было сделано срочно» :-)
                    0
                    Если у вас разработка похожа на военные действия, то действительно Матрица Эйзенхауэра как вы говорите «очень хороший инструмент привести голову в порядок». В современных компаниях клиенты и сотрудники — это лояльные партнёры, а вы изначально планируете с ними работу как с вражескими противниками.
                    В итоге вся эта схема лично у меня рождает только одну ассоциацию: http://img5.joyreactor.cc/pics/post/fuuuu-auto-83005.jpeg
                    Хватит уже перекладывать бумажки из одного квадрата в другой, от одного сотрудника к другому :-(.
                      0
                      Уважаемый iPR я же написал что руководитель проекта САМА придумала это.
                      Как инструмент решения СВОИХ задач.
                      никто не заставлял.

                      Более того если говорить про партнеров.
                      То, Вика 23 года, является партнером и владеет 10% в ООО стартапа.

                      Ну и таки да, запуск стартапа это военные действия.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое