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

в 16:45, , рубрики: опять этот придурок что-то написал, управление персоналом, Управление продуктом, управление проектами, управление разработкой, черт знает что

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

Автор: nmivan

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js