Матрица – это инструмент расстановки приоритетов задач. Придумал ее, говорят, 34-й президент США Дуайт Эйзенхауэр. Определять приоритеты с помощью матрицы просто и эффективно.
Насколько он известен, настолько же и не распространен в нашей среде, касалось бы это работы или жизни. Выглядит матрица Эйзенхауэра так:
Любая задача, которую надо сделать, попадает в один из четырех квадрантов матрицы. Выполнять следует в порядке сверху вниз, слева направо. Сначала – срочные и важные, потом – срочные и не важные, дальше не срочные и важные, и, наконец, не срочные и не важные.
Ключевая проблема, с которой сталкиваются люди при работе с матрицей Эйзенхауэра, это классификация задач по срочности и важности. А если точнее, то главная беда – понять, что вообще такое срочность и важность. Так и не разобравшись, люди бросают матрицу, поигравшись день или два. Попробуем разобраться.
К сожалению, или к счастью, однозначных критериев нет. Любой человек может придумать свои правила, но не любой будет этим заниматься. Поэтому поступим так: я расскажу, как я определяю срочность и важность, а вы решите для себя, годится вам такой подход, или нет. Ну и придумаете свои правила.
Начнем со срочности, т.к. она приоритетнее важности.
Какую задачу можно назвать срочной? Не помню, где я слышал этот критерий, но он мне очень понравился своей простотой. Срочная задача – та, которую после окончания срока можно уже не делать. Просто и понятно.
Но применить такой подход в жизни не просто. Вот перестала у клиента работать база – чинить надо срочно или нет? По критерию – нет, т.к. базу нужно поднимать и сейчас, и завтра, и через неделю. Если вы попробуете в кризисной ситуации кому-нибудь объяснять критерий срочности, то ничего хорошего не выйдет.
Поэтому мы возьмем более сглаженный критерий. Срочно – это когда высоки потери от того, что задача не решена. Отвлекитесь и подумайте, насколько срочны задачи, которые мы привыкли считать таковыми?
К сожалению, многие менеджеры склонны называть срочными задачами все подряд. Сожаление вызывает не то, что они не правы, а то, что перестает работать система приоритетов – все задачи выглядят одинаково. Программисту становится сложно выбирать.
В задачах клиентов часто встречается объективная срочность – например, вышеупомянутое падение базы. Или на дворе 19-е число октября, и клиенту надо сдавать НДС, а декларация никак не формируется. Или, не дай Бог, конец марта, и налог на прибыль никак не посчитать. Или счета-фактуры не печатаются, по необъяснимой причине, и возникают простои в отгрузке.
Такие задачи являются срочными, потому что удовлетворяют нашему критерию – есть реальные потери от того, что задача не решается. И не просто есть – не сданный вовремя налог на прибыль грозит нешуточным штрафом.
Важно уметь разделять понятия «срочность» и «срок выполнения». Срок, так или иначе, есть у любой задачи, даже если он не обозначен. Тут я немного забегаю вперед, о сроках будет рассказано в другой раз, но хочу, чтобы вы поняли: наличие срока – это не срочность. Равно как и приближение срока – это не срочность.
Срочность задачи никак не соотносится со сроком ее исполнения. Например, срок выполнения задачи может вообще быть не типа «дата», а «как можно быстрее, блин!». Т.е., формально, срока-то никакого нет. А задача, тем не менее, срочная. Или срок у задачи может быть — завтра, но все понимают, что ее поставил человек, которому решение нафиг не нужно — он по первой же просьбе перенесет срок на любую дату. Или система так устроена, что без указания срока задачу нельзя внести.
Срочность – это отдельный атрибут задачи, характеризующий контекст ее рождения и жизни, а не менеджерские обозначения вроде «срока выполнения» или «включения в план этого дня».
Теперь о важности. Вернемся к классику – Стивену Кови. Он обозначил важными те задачи, которые на будущее. Достаточно простое, хоть и не совсем понятное определение. Попробуем расшифровать.
Есть задачи, от решения которых ничего принципиально не меняется. Вот решили вы ее, клиент заплатил деньги, и не произошло никаких значимых изменений – ни у вас, ни у клиента. Решение этой задачи не вызвало шквала новых задач, не запустился долгоиграющий проект, никого не уволили и не приняли на работу, не решилась какая-нибудь гнетущая проблема бизнеса клиента.
А есть задача клиента, решив которую, вы получаете проект. Есть центральная задача этапа проекта, которая переводит его из тестирования в эксплуатацию. Есть задача на проверку гипотезы в рискованной разработке, после решения которой у вас случается первый релиз, и вы можете, наконец, показать свой продукт пользователям и получить обратную связь. Есть задача, от решения которой зависит репутация команды или всей вашей компании. Есть задача, по которой будут судить о вашем повышении в должности. Есть задача, от которой зависит ваша часовая ставка.
Вот эти задачи – важные. От них что-то зависит. И не просто «что-то», а конкретное, понятное вам и полезное для вас «что-то». Они не только влияют на будущее, но и формируют его.
Вот, например, я создаю этот материал, который впоследствии станет курсом. Пока я не напишу материал, курса не будет. Не будет курса – не будет продаж. Напишу курс – все случится. Написание курса – важная задача. Вместо этого я могу отвлекаться на текущие задачи – сделать что-нибудь для клиентов, или выпустить очередной релиз. Возможно, это срочные задачи, но они не создают будущего. А курс – создает.
Вот это и есть важность задачи. Подспудно ее все понимают, но вот в чем загвоздка – одного понимания недостаточно. Когда мы говорили о выборе задачи, то отмечали: если человек сам решает, за какую задачу взяться, то он руководствуется собственными критериями. А какой человек, в здравом уме, по своей воле возьмется за важную задачу?
Сами понимаете: высокая важность – это высокая ответственность. Что бы мы не думали о людях, или о себе, то ответственности мы стараемся избегать. Поэтому важная задача будет откладываться, а программист займется тем, что ему по душе.
Чтобы важные задачи выполнялись в первую очередь, необходимо скорректировать систему приоритетов и помочь исполнителю с выбором. И вот настал момент, когда мы вносим в нашу систему приоритетов первый алгоритм – будем определять порядок выполнения в зависимости от срочности и важности.
Технически это очень просто. Достаточно добавить к задаче два поля – срочность и важность, и упорядочить по ним очередь. Например, рассчитав приоритет выполнения задачи в виде цифры. Если задача срочная, то добавляем 2 условных единицы, если важная – 1 условную единицу.
Итого, не важная и не срочная задача будет иметь приоритет, равный нулю. Срочная и не важная – 2. Не срочная и важная – 1. Срочная и важная – 3. Теперь упорядочиваем список задач по убыванию рассчитанного приоритета, и получаем результат – правильную последовательность, которая отражает нашу стратегию.
Правила расчета цифр срочности и важности – не жесткие. И, к сожалению, работают только в том случае, если срочность и важность присваиваются задаче вдумчиво, а не просто так, чтобы побыстрее сделали.
Например, часто встречается ситуация, когда задачи от клиентов записывают менеджеры, а исполняют – программисты. Менеджеры, поняв систему приоритетов, начинают лепить срочность и важность всем задачам подряд, особенно когда за менеджером или клиентом не закреплен конкретный программист. Желание менеджера продвинуть свою задачу в начало очереди, в общем-то, понятно, но своим стремлением побыстрее получить как можно больше подписанных актов он сводит на нет все ваши усилия по построению системы приоритетов. И серьезно выбешивает программистов.
Решений у этой проблемы несколько.
Первое, пожестче – не давать менеджеру ставить срочность и важность. Пусть просто записывает задачу. Если есть какие-то дополнительные требования, способные повлиять на приоритет, пусть излагает в описании задачи. На самом деле, вдруг там и правда срочно? Координатор, или тимлид, или ведущий программист в этом случае будет ориентироваться на информацию от менеджера.
Второй вариант, помягче – делать две оценки срочности и важности. Одну – от менеджера, вторую – от того, кто что-то понимает, а итоговый приоритет вычислять по сумме условных единиц. Максимум 3 условных единицы от менеджера, и максимум 3 – от координатора. Система приоритетов станет более многогранной и сбалансированной.
Ну и не стоит забывать простое правило: есть на свете задачи не срочные и не важные. Когда появляются такие регуляторы, как срочность и важность, то рука сама так и тянется ими воспользоваться. Кажется, что чего-то не хватает, когда срочность и важность не указаны.
Отсутствие срочности и важности у задачи – это нормально. Но есть одна проблема – такая задача, теоретически, может не выполниться никогда, если постоянно будут появляться новые, имеющие хотя бы одну условную единицу приоритета. Как такой ситуации избежать, поговорим в другой раз.
Резюме
- Матрица Эйзенхауэра – это простой инструмент определения приоритетов;
- Приоритет регулируется двумя признаками – срочность и важность;
- Срочная задача – та, потери от невыполнения которой высоки;
- Важная задача – та, которая влияет на будущее;
- Срочность приоритетнее важности;
- Бывают задачи не срочные и не важные;
- Приоритеты работают только при осознанном определении срочности и важности.
Комментарии (28)
dmitryrf
11.05.2019 20:49+9Идея на счёт оценки срочности/важности менеджерами: выдать каждому конечное число баллов для оценки. Слил все — новые задачи становятся не важными и не срочными. Либо перекидывай оценки с других задач.
И, по-моему, можно добавить ещё тегов :)VBV78
12.05.2019 18:30… выдать каждому конечное число баллов......-перекидывай оценки с других задач
дельный вариант ). Не панацея конечно, но для начала вполне конструктивно. Ну, и запретить изменения приоритетов для задач, которые уже в исполнении )
Tyusha
11.05.2019 21:55У меня в систему приоритетов всегда вмешается ещё трудоёмкость задачи, т.е. сколько на неё надо потратить времени. Пример. Вы делаете срочную важную задачу длительностью, допустим, в полдня. В этот момент приходит срочная неважная на 10 минут делов. И как быть в парадигме матрицы Эйзенхауэра?
Так что срочность задачи (которую можно измерить во времени) надо каким-то образом «взвесить» на время исполнения задачи.
gonchik
11.05.2019 22:04+1если внедрить понятие business value? или это усугубит?
vokzamag
12.05.2019 00:08Чтобы определить, в каком порядке выполнять задачи из пула, нужны и срочность, и важность, и оценка трудозатрат, и business value, и ещё несколько критериев, типа суммарной производительности команды, эластичности сроков и т. д.
Частный случай, описанный Tysha, я бы решал примерно так.
Исходя из производительности и загруженности команды, сколько задач мы успеем к сроку — обе, только важную, только быструю?
Можно ли большую задачу разрезать на две и выдать клиенту частями?
Можем ли мы подвинуть сроки у какой-то из задач?
Можем ли мы расширить команду?
Есть ли у нас время выяснять это всё? Если нет — неважная задача идёт нафиг, чтобы не рисковать плюшками, сулимыми важной задачей (и не выкинуть в мусорку неделю работы над ней в случае срыва сроков)
submagic
12.05.2019 03:02+1Матрица Эйзенхауэра — подход (в изложенном в статье виде) давно устаревший. Кроме срочности и важности, как Вы правильно заметили, есть ещё ресурсоёмкость (начиная с потребного времени), а также эластичность / непредсказуемость. В современном виде это выглядит примерно так:
1) Срочность <—> Потребное время выполнения
2) Важность <—> Стоимость
3) Эластичность <—> Непредсказуемость
Если с первыми двумя пунктами всё более-менее понятно — срочность считается не как «срочность в чистом виде», а как срочность минус потребное время выполнения, важность по тому же принципу относительно стоимости — то про третий пункт следует сказать особо.
Собственно, это возможность декомпиллировать задачу или объединить её с иными (в том числе, чужими) — в противопоставлении с неопределённостью её статуса. То есть, чем задача «покладистей», тем выше её приоритет. Что прекрасно выражает старая армейская мудрость: «Не спеши выполнять приказ, дождись следующего, что его отменяет».
Соответственно, чем проще передать задачу другим людям, объединить её с иной задачей или разбить на подзадачи, имеющие самостоятельную ценность — и чем меньше вероятность изменения или полной отмены этой задачи по ходу её выполнения — тем она приоритетней.
Вот как-то так, если не вдаваться в подробности.bbb
12.05.2019 11:58Ух ты! А где о таком подходе можно больше почитать?
submagic
12.05.2019 12:29У Владимира Тарасова в обуждениях его «Искусства управленческой борьбы» было. Точную ссылку сейчас не дам (несколько лет назад читал), но, полагаю, нагуглить нетрудно. Ну, или саму книжку можно почитать (не сами же они это придумали).
cuwHuk
12.05.2019 12:13Матрица Эйзенхауэра — подход (в изложенном в статье виде) давно устаревший.
Весь цимес этого подхода сосредоточен в квадрате «важно, но не срочно», т.е. долгосрочное планирование. Если долгосрочное планирование проводится тщательно, то количество срочных задач значительно уменьшается и появляется возможность их своевременной реализации.submagic
12.05.2019 12:21Вот этот подход и устарел, в первую очередь. Потому что сейчас время течёт очень быстро, всё стремительно меняется, долгосрочное планирование становится всё более проблематичным в силу постоянно растущего потока новой информации и новых задач. Стратегическая расстановка приоритетов «из будущего» теряет приоритет в силу пункта 3).
cuwHuk
12.05.2019 18:03Повышается «мощность» информационного шума, фундаментальные, системообразующие процессы наоборот тормозятся в связи с ростом продолжительности жизни людей, IMHO роль долгосрочного планирования только возрастает.
dpyzhov
13.05.2019 13:34Рост непредсказуемости только повышает требования к способности создавать и адаптировать стратегии. Иначе окажешься в ситуации Кэрролловской Алисы — вроде и бежишь со всех ног, но на месте.
dpyzhov
13.05.2019 13:27Квадрант «важно и срочно» имеет не меньшее значение, так как туда попадают все ошибки долгосрочного планирования. Соответственно по каждой задаче из этого списка стоит проводить разбор полётов на тему «как избежать повторения этой ситуации в будущем»
sanalex76
12.05.2019 18:30За много лет работы следую правилу, что задачи, которые можно решить за 10 минут, должны быть решены в тот же день. Во-первых, позволяет не накапливать задачи, во-вторых, иногда полезно отвлечься на 10 минут от основной задачи.
Не программист.
equity
12.05.2019 12:57Аристотель, «Никомахова Этика»
Всякое искусство и всякое учение, а равным образом поступок и сознательный выбор, как принято считать, стремятся к определенному благу. Поэтому удачно определяли благо как то, к чему все стремится.
Без понятия «наивысшее благо» или максимизации функции полезности/блага получается «социальный аспирин», о котором писали ранее. Для более глубокого понимания нужно вводить понятия миссия компании и общее дело команды.
…
Если же у того, что мы делаем, существует некая цель, желанная нам сама по себе, причем остальные цели желанны ради нее ..., то ясно, что цель эта есть собственно благо, то есть наивысшее благо.
Разве познание его не имеет огромного влияния на образ жизни? И словно стрелки, видя мишень перед собою, разве не вернее достигнем мы должного?
maxxannik
12.05.2019 14:17Некогда читал заметки автора системы Планфикс, где они придумывали как правильно сделать приоритеты задач в системе.
На то время я тоже искал ответ на вопрос как эффективно ставить приоритеты?
Там ребята пришли к выводу что единственно верная система — это плоский список задач.
Вообще слово Приоритет если изучить его этимологию означает «Первый». Сколько задач одновременно могут быть первыми? :)
И вот когда заставляешь всех работать по такому списку, где физически не возможно 2 задачи поставить на 1е место ) Вот тогда люди реально начинают думать. А разработчики реально понимают что надо делать.
В идеале. В реальности конечно и эту систему можно сломать и изуродовать. Но ничего лучше пока не нашел.
Еще это называется Backlog в мире Agile. Который вам как то не по душе. Судя по некоторым мыслям проскакивающим в тексте.
Например. Иногда подключаюсь к проектам/командам, в которых творится хаос, не понимание между руководством и разработчиками, полная чехорда. Одни орут что сроки не исполняются, другие что задачи не внятные. И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
Плоский список задач — это проще чем матрица ) Играть с матрицей кончил лет 10 назад.
Я боюсь представить что будет когда вы узнаете что такое OKR )
NewMan_by
12.05.2019 16:42Это ж за менеджер, который не знает важности и срочности задачи? Менеджер и должен собирать в один список как бизнес задачи, так и технические от команд и выставлять сквозные приоритеты.
sshmakov
12.05.2019 17:59Тезисно
1. Важность и срочность необходимо аргументировать. Каждый раз, для каждой задачи. Автор привел их определение, но почему-то, против моих ожиданий, не сказал, что это обязанность инициатора в задаче написать, почему, по каким узаконенным признакам, эта задача считается столь важной/срочной. Если инициатор этого не пишет, то задача по умолчанию не важная и не срочная. Исполнитель может поднять ей приоритет, а может и не поднять.
2. Деление по важности и срочности годится только для предварительной группировки (не сортировки) задач. Получаем четыре группы, но внутри каждой группы задачи не упорядоченны.
3. После группировки можно присвоить приоритет задачам. Приоритет задачи — это не важность или срочность, а ее положение в общем пуле задач. То есть приоритет является производной величиной. Например, можно взять за правило назначения приоритета:
— 100-299 — низкий приоритет
— 300-499 — обычные текущие задачи
— 500-699 — важные задачи
— 700-899 — срочные задачи
— 900-999 — критические задачи, всё упало, все на абордаж!
По умолчанию назначается нижняя граница. Задачи могут иметь один приоритет, если нет значения, в каком порядке их выполнять. Задачам стоит дать разный приоритет, если из каких-либо соображений одну стоит сделать раньше другой.
4. Задачи делаем в порядке убывания приоритета, но тут надо не забывать про взаимосвязи задач — сдача в тираж, конечно, срочная и важная задача, но не стоит ее делать прежде, чем будет готов продукт.
Loggus66
12.05.2019 18:30Вот перестала у клиента работать база – чинить надо срочно или нет? По критерию – нет, т.к. базу нужно поднимать и сейчас, и завтра, и через неделю.
Через неделю клиент разорвёт контракт, или организация-подрядчик разорвёт контракт с исполнителем. Если клиент готов мириться с недельным простоем, то это, действительно, несрочно.
fn112
13.05.2019 13:45Начнем со срочности, т.к. она приоритетнее важности.
Что-то мне подсказывает, что такой подход к делу вызывает «Эффект дырявого стека» очень хорошо описанного Максимом Дорофеевым в его «Джедайские техники» пункт 2.3.2. Благодаря этому подходу каждое новая входящая задача автоматически становиться более важной и срочной чем та, которая поступила 5 минут назад и соответственно шанс ее выполнения резко падает.
Не зря в статье есть много реальных замечанийК сожалению, многие менеджеры склонны называть срочными задачами все подряд
илиМенеджеры, поняв систему приоритетов, начинают лепить срочность и важность всем задачам подряд, особенно когда за менеджером или клиентом не закреплен конкретный программист.
А вот maxxannik очень точно подметилИ просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
— плоский список задач и поможет избежать такой ситуации.
Также автор лихо перемешал задачи с проектами:А есть задача клиента, решив которую, вы получаете проект. Есть центральная задача этапа проекта, которая переводит его из тестирования в эксплуатацию.
Кажется здесь идет речь именно о проекте, а не о задаче.
ИМХО, статья сильно запутывает в отношении того, на что нужно действительно обращать внимание.
Vlad_fox
13.05.2019 15:43+1кроха сын к отцу пришел,
и спросила кроха
Важно — это хорошо?
срочно — это плохо?
папа репу почесал
и ответил крохе
чтоб на харбе почитал
на одном из блохов
halted
Давно подумывал об эксперименте, где заставив управленцев сыграть в любую стратегию, попробовать оценить их навыки управления.
qw1
По результатам уволить всех топов с MBA-дипломами и нанять корейских киберспортсменов )))
halted
Как вариант, но предполагается, что любой руководитель должен уметь играть в стратегию лучше рядовых сотрудников. Хотя бы из-за того, что управление подразумевает умение стратегически мыслить. Конечно до рекордсменов старкрафта необязательно дотягивать, но в пошаговую цивилизацию вполне.
qw1
Есть мнение, что Quake очень стратегическая игра: нужно решить, пойти за бронёй или оружием, или срочно гнаться за противником, чтобы ему не дать забрать mega-health. Кроме того, нужно предугадывать действия оппонента, как на микро-уровне (куда стрелять ракетой), так и на макро (в какой корридор он побежал?).
То есть, пока руководитель меня в Quake не обыграет, он мне не начальник?
mishasneg
В комментарии неверное предположение, что умение хорошо играть в стратегии коррелирует с умением стратегически мыслить. Но мысль проверять стратегическое мышление интересна.