June 9th, 2014

Cartmendum

Матрица Эйзенхауэра: важноенесрочное

Многие из тех, кто начинают заниматься вопросом личной эффективности идут в гугл с запросом «тайм-менеджмент» либо на соответствующий тренинг, где они с очень хорошей вероятностью сталкиваются с матрицей Эйзенхауэра. Матрица Эйзенхауэра – это частный вид любимой консультантами матрицы 2х2, где по одной оси откладывается условная срочность, по другой – условная важность. Предлагается, что человек будет использовать эту матрицу для расстановки своим задачам приоритетов, уделяя все больше и больше внимания тому, что важно, но не срочно.

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

В джедайской технике пустого инбокса момент приоритезации сильно упрощен, есть всего два приоритета: надо сделать/не надо сделать. Приоритезировать задачи таким образом на много сложнее (Забавно, не правда ли? Стоит добавить еще пяток промежуточных приоритетов, как дело само собой упрощается…), зато довольно быстро мы уходим от впихивания невпихуемого. И вместо того, чтобы бесконечно откладывать на потом выполнение невпихуемого, мы намного раньше признаем тот факт, что оно не будет сделано вообще, и начинаем корректировать свои действия исходя из этого.

Похожий подход мне нравится и в командах разработчиков: однозначный приоритет пользовательских историй сделаем/не сделаем вместо всяких замысловатых: must-should-could, так как он оставляет меньше места всяким неоднозначностям.