Хабрахабр

Что важно, а что — срочно?

Матрица Эйзенхауэра – очень известный метод определения приоритетов. Например, в знаменитой книге Стивена Кови «Семь навыков высокоэффективных людей» матрице посвящена целая глава.

Придумал ее, говорят, 34-й президент США Дуайт Эйзенхауэр. Матрица – это инструмент расстановки приоритетов задач. Определять приоритеты с помощью матрицы просто и эффективно.

Выглядит матрица Эйзенхауэра так: Насколько он известен, настолько же и не распространен в нашей среде, касалось бы это работы или жизни.

Выполнять следует в порядке сверху вниз, слева направо. Любая задача, которую надо сделать, попадает в один из четырех квадрантов матрицы. Сначала – срочные и важные, потом – срочные и не важные, дальше не срочные и важные, и, наконец, не срочные и не важные.

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

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

она приоритетнее важности. Начнем со срочности, т.к.

Не помню, где я слышал этот критерий, но он мне очень понравился своей простотой. Какую задачу можно назвать срочной? Просто и понятно. Срочная задача – та, которую после окончания срока можно уже не делать.

Вот перестала у клиента работать база – чинить надо срочно или нет? Но применить такой подход в жизни не просто. базу нужно поднимать и сейчас, и завтра, и через неделю. По критерию – нет, т.к. Если вы попробуете в кризисной ситуации кому-нибудь объяснять критерий срочности, то ничего хорошего не выйдет.

Срочно – это когда высоки потери от того, что задача не решена. Поэтому мы возьмем более сглаженный критерий. Отвлекитесь и подумайте, насколько срочны задачи, которые мы привыкли считать таковыми?

Сожаление вызывает не то, что они не правы, а то, что перестает работать система приоритетов – все задачи выглядят одинаково. К сожалению, многие менеджеры склонны называть срочными задачами все подряд. Программисту становится сложно выбирать.

Или на дворе 19-е число октября, и клиенту надо сдавать НДС, а декларация никак не формируется. В задачах клиентов часто встречается объективная срочность – например, вышеупомянутое падение базы. Или счета-фактуры не печатаются, по необъяснимой причине, и возникают простои в отгрузке. Или, не дай Бог, конец марта, и налог на прибыль никак не посчитать.

И не просто есть – не сданный вовремя налог на прибыль грозит нешуточным штрафом. Такие задачи являются срочными, потому что удовлетворяют нашему критерию – есть реальные потери от того, что задача не решается.

Срок, так или иначе, есть у любой задачи, даже если он не обозначен. Важно уметь разделять понятия «срочность» и «срок выполнения». Равно как и приближение срока – это не срочность. Тут я немного забегаю вперед, о сроках будет рассказано в другой раз, но хочу, чтобы вы поняли: наличие срока – это не срочность.

Например, срок выполнения задачи может вообще быть не типа «дата», а «как можно быстрее, блин!». Срочность задачи никак не соотносится со сроком ее исполнения. А задача, тем не менее, срочная. Т.е., формально, срока-то никакого нет. Или система так устроена, что без указания срока задачу нельзя внести. Или срок у задачи может быть — завтра, но все понимают, что ее поставил человек, которому решение нафиг не нужно — он по первой же просьбе перенесет срок на любую дату.

Срочность – это отдельный атрибут задачи, характеризующий контекст ее рождения и жизни, а не менеджерские обозначения вроде «срока выполнения» или «включения в план этого дня».

Вернемся к классику – Стивену Кови. Теперь о важности. Достаточно простое, хоть и не совсем понятное определение. Он обозначил важными те задачи, которые на будущее. Попробуем расшифровать.

Вот решили вы ее, клиент заплатил деньги, и не произошло никаких значимых изменений – ни у вас, ни у клиента. Есть задачи, от решения которых ничего принципиально не меняется. Решение этой задачи не вызвало шквала новых задач, не запустился долгоиграющий проект, никого не уволили и не приняли на работу, не решилась какая-нибудь гнетущая проблема бизнеса клиента.

Есть центральная задача этапа проекта, которая переводит его из тестирования в эксплуатацию. А есть задача клиента, решив которую, вы получаете проект. Есть задача, от решения которой зависит репутация команды или всей вашей компании. Есть задача на проверку гипотезы в рискованной разработке, после решения которой у вас случается первый релиз, и вы можете, наконец, показать свой продукт пользователям и получить обратную связь. Есть задача, от которой зависит ваша часовая ставка. Есть задача, по которой будут судить о вашем повышении в должности.

От них что-то зависит. Вот эти задачи – важные. Они не только влияют на будущее, но и формируют его. И не просто «что-то», а конкретное, понятное вам и полезное для вас «что-то».

Пока я не напишу материал, курса не будет. Вот, например, я создаю этот материал, который впоследствии станет курсом. Напишу курс – все случится. Не будет курса – не будет продаж. Вместо этого я могу отвлекаться на текущие задачи – сделать что-нибудь для клиентов, или выпустить очередной релиз. Написание курса – важная задача. А курс – создает. Возможно, это срочные задачи, но они не создают будущего.

Подспудно ее все понимают, но вот в чем загвоздка – одного понимания недостаточно. Вот это и есть важность задачи. А какой человек, в здравом уме, по своей воле возьмется за важную задачу? Когда мы говорили о выборе задачи, то отмечали: если человек сам решает, за какую задачу взяться, то он руководствуется собственными критериями.

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

И вот настал момент, когда мы вносим в нашу систему приоритетов первый алгоритм – будем определять порядок выполнения в зависимости от срочности и важности. Чтобы важные задачи выполнялись в первую очередь, необходимо скорректировать систему приоритетов и помочь исполнителю с выбором.

Достаточно добавить к задаче два поля – срочность и важность, и упорядочить по ним очередь. Технически это очень просто. Если задача срочная, то добавляем 2 условных единицы, если важная – 1 условную единицу. Например, рассчитав приоритет выполнения задачи в виде цифры.

Срочная и не важная – 2. Итого, не важная и не срочная задача будет иметь приоритет, равный нулю. Срочная и важная – 3. Не срочная и важная – 1. Теперь упорядочиваем список задач по убыванию рассчитанного приоритета, и получаем результат – правильную последовательность, которая отражает нашу стратегию.

И, к сожалению, работают только в том случае, если срочность и важность присваиваются задаче вдумчиво, а не просто так, чтобы побыстрее сделали. Правила расчета цифр срочности и важности – не жесткие.

Менеджеры, поняв систему приоритетов, начинают лепить срочность и важность всем задачам подряд, особенно когда за менеджером или клиентом не закреплен конкретный программист. Например, часто встречается ситуация, когда задачи от клиентов записывают менеджеры, а исполняют – программисты. И серьезно выбешивает программистов. Желание менеджера продвинуть свою задачу в начало очереди, в общем-то, понятно, но своим стремлением побыстрее получить как можно больше подписанных актов он сводит на нет все ваши усилия по построению системы приоритетов.

Решений у этой проблемы несколько.

Пусть просто записывает задачу. Первое, пожестче – не давать менеджеру ставить срочность и важность. На самом деле, вдруг там и правда срочно? Если есть какие-то дополнительные требования, способные повлиять на приоритет, пусть излагает в описании задачи. Координатор, или тимлид, или ведущий программист в этом случае будет ориентироваться на информацию от менеджера.

Одну – от менеджера, вторую – от того, кто что-то понимает, а итоговый приоритет вычислять по сумме условных единиц. Второй вариант, помягче – делать две оценки срочности и важности. Система приоритетов станет более многогранной и сбалансированной. Максимум 3 условных единицы от менеджера, и максимум 3 – от координатора.

Когда появляются такие регуляторы, как срочность и важность, то рука сама так и тянется ими воспользоваться. Ну и не стоит забывать простое правило: есть на свете задачи не срочные и не важные. Кажется, что чего-то не хватает, когда срочность и важность не указаны.

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

Резюме

  • Матрица Эйзенхауэра – это простой инструмент определения приоритетов;
  • Приоритет регулируется двумя признаками – срочность и важность;
  • Срочная задача – та, потери от невыполнения которой высоки;
  • Важная задача – та, которая влияет на будущее;
  • Срочность приоритетнее важности;
  • Бывают задачи не срочные и не важные;
  • Приоритеты работают только при осознанном определении срочности и важности.
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть