Расстановка приоритетов выполнения задач - чрезвычайно важная тема. Настолько важная, что у нее нет правильного решения. Существуют десятки, если не сотни методик, рекомендаций, диссертаций и исследований на тему того, в каком порядке надо решать задачи.
На первый взгляд, кажется, что проблема только в технике. Достаточно придумать некий алгоритм сортировки, исходя из ограничений и целей, и всё заколосится. А каковы цели? А какие задачи ведут к цели? А если целей несколько?
А что, если у нас не тупой конвейер по выполнению мелких сервисных задач? Если нам надо и клиентов обслуживать, и проектные задачи делать, и собственные продукты создавать? Как решить, что и когда делать? Особенно, если пул задач насчитывает одновременно сотни записей.
Если честно, правильного ответа на вопрос не знаю ни я, ни вы. Поэтому просто расскажу об инструменте, который кажется мне наиболее универсальным, и способным быть основой для создания системы приоритетов, подходящей под ваши цели, ограничения и процессы. Речь пойдет о матрице Эйзенхауэра.
Матрица Эйзенхауэра – очень известный метод определения приоритетов. Например, в знаменитой книге Стивена Кови «Семь навыков высокоэффективных людей» матрице посвящена целая глава.
Матрица – это инструмент расстановки приоритетов задач. Придумал ее, говорят, 34-й президент США Дуайт Эйзенхауэр. Определять приоритеты с помощью матрицы просто и эффективно.
Насколько он известен, настолько же и не распространен в нашей среде, касалось бы это работы или жизни. Выглядит матрица Эйзенхауэра так:
Любая задача, которую надо сделать, попадает в один из четырех квадрантов матрицы. Выполнять следует в порядке сверху вниз, слева направо. Сначала – срочные и важные, потом – срочные и не важные, дальше не срочные и важные, и, наконец, не срочные и не важные.
Ключевая проблема, с которой сталкиваются люди при работе с матрицей Эйзенхауэра, это классификация задач по срочности и важности. А если точнее, то главная беда – понять, что вообще такое срочность и важность. Так и не разобравшись, люди бросают матрицу, поигравшись день или два. Попробуем разобраться.
К сожалению, или к счастью, однозначных критериев нет. Любой человек может придумать свои правила, но не любой будет этим заниматься. Поэтому поступим так: я расскажу, как я определяю срочность и важность, а вы решите для себя, годится вам такой подход, или нет. Ну и придумаете свои правила.
Начнем со срочности, т.к. она приоритетнее важности.
Какую задачу можно назвать срочной? Не помню, где я слышал этот критерий, но он мне очень понравился своей простотой. Срочная задача – та, которую после окончания срока можно уже не делать. Просто и понятно.
Но применить такой подход в жизни не просто. Вот перестала у клиента работать база – чинить надо срочно или нет? По критерию – нет, т.к. базу нужно поднимать и сейчас, и завтра, и через неделю. Если вы попробуете в кризисной ситуации кому-нибудь объяснять критерий срочности, то ничего хорошего не выйдет.
Поэтому мы возьмем более сглаженный критерий. Срочно – это когда высоки потери от того, что задача не решена. Отвлекитесь и подумайте, насколько срочны задачи, которые мы привыкли считать таковыми?
К сожалению, многие менеджеры склонны называть срочными задачами все подряд. Сожаление вызывает не то, что они не правы, а то, что перестает работать система приоритетов – все задачи выглядят одинаково. Программисту становится сложно выбирать.
В задачах клиентов часто встречается объективная срочность – например, вышеупомянутое падение базы. Или на дворе 19-е число октября, и клиенту надо сдавать НДС, а декларация никак не формируется. Или, не дай Бог, конец марта, и налог на прибыль никак не посчитать. Или счета-фактуры не печатаются, по необъяснимой причине, и возникают простои в отгрузке.
Такие задачи являются срочными, потому что удовлетворяют нашему критерию – есть реальные потери от того, что задача не решается. И не просто есть – не сданный вовремя налог на прибыль грозит нешуточным штрафом.
Важно уметь разделять понятия «срочность» и «срок выполнения». Срок, так или иначе, есть у любой задачи, даже если он не обозначен. Тут я немного забегаю вперед, о сроках будет рассказано в другой раз, но хочу, чтобы вы поняли: наличие срока – это не срочность. Равно как и приближение срока – это не срочность.
Срочность задачи никак не соотносится со сроком ее исполнения. Например, срок выполнения задачи может вообще быть не типа «дата», а «как можно быстрее, блин!». Т.е., формально, срока-то никакого нет. А задача, тем не менее, срочная. Или срок у задачи может быть — завтра, но все понимают, что ее поставил человек, которому решение нафиг не нужно — он по первой же просьбе перенесет срок на любую дату. Или система так устроена, что без указания срока задачу нельзя внести.
Срочность – это отдельный атрибут задачи, характеризующий контекст ее рождения и жизни, а не менеджерские обозначения вроде «срока выполнения» или «включения в план этого дня».
Теперь о важности. Вернемся к классику – Стивену Кови. Он обозначил важными те задачи, которые на будущее. Достаточно простое, хоть и не совсем понятное определение. Попробуем расшифровать.
Есть задачи, от решения которых ничего принципиально не меняется. Вот решили вы ее, клиент заплатил деньги, и не произошло никаких значимых изменений – ни у вас, ни у клиента. Решение этой задачи не вызвало шквала новых задач, не запустился долгоиграющий проект, никого не уволили и не приняли на работу, не решилась какая-нибудь гнетущая проблема бизнеса клиента.
А есть задача клиента, решив которую, вы получаете проект. Есть центральная задача этапа проекта, которая переводит его из тестирования в эксплуатацию. Есть задача на проверку гипотезы в рискованной разработке, после решения которой у вас случается первый релиз, и вы можете, наконец, показать свой продукт пользователям и получить обратную связь. Есть задача, от решения которой зависит репутация команды или всей вашей компании. Есть задача, по которой будут судить о вашем повышении в должности. Есть задача, от которой зависит ваша часовая ставка.
Вот эти задачи – важные. От них что-то зависит. И не просто «что-то», а конкретное, понятное вам и полезное для вас «что-то». Они не только влияют на будущее, но и формируют его.
Вот, например, я создаю этот материал, который впоследствии станет курсом. Пока я не напишу материал, курса не будет. Не будет курса – не будет продаж. Напишу курс – все случится. Написание курса – важная задача. Вместо этого я могу отвлекаться на текущие задачи – сделать что-нибудь для клиентов, или выпустить очередной релиз. Возможно, это срочные задачи, но они не создают будущего. А курс – создает.
Вот это и есть важность задачи. Подспудно ее все понимают, но вот в чем загвоздка – одного понимания недостаточно. Когда мы говорили о выборе задачи, то отмечали: если человек сам решает, за какую задачу взяться, то он руководствуется собственными критериями. А какой человек, в здравом уме, по своей воле возьмется за важную задачу?
Сами понимаете: высокая важность – это высокая ответственность. Что бы мы не думали о людях, или о себе, то ответственности мы стараемся избегать. Поэтому важная задача будет откладываться, а программист займется тем, что ему по душе.
Чтобы важные задачи выполнялись в первую очередь, необходимо скорректировать систему приоритетов и помочь исполнителю с выбором. И вот настал момент, когда мы вносим в нашу систему приоритетов первый алгоритм – будем определять порядок выполнения в зависимости от срочности и важности.
Технически это очень просто. Достаточно добавить к задаче два поля – срочность и важность, и упорядочить по ним очередь. Например, рассчитав приоритет выполнения задачи в виде цифры. Если задача срочная, то добавляем 2 условных единицы, если важная – 1 условную единицу.
Итого, не важная и не срочная задача будет иметь приоритет, равный нулю. Срочная и не важная – 2. Не срочная и важная – 1. Срочная и важная – 3. Теперь упорядочиваем список задач по убыванию рассчитанного приоритета, и получаем результат – правильную последовательность, которая отражает нашу стратегию.
Правила расчета цифр срочности и важности – не жесткие. И, к сожалению, работают только в том случае, если срочность и важность присваиваются задаче вдумчиво, а не просто так, чтобы побыстрее сделали.
Например, часто встречается ситуация, когда задачи от клиентов записывают менеджеры, а исполняют – программисты. Менеджеры, поняв систему приоритетов, начинают лепить срочность и важность всем задачам подряд, особенно когда за менеджером или клиентом не закреплен конкретный программист. Желание менеджера продвинуть свою задачу в начало очереди, в общем-то, понятно, но своим стремлением побыстрее получить как можно больше подписанных актов он сводит на нет все ваши усилия по построению системы приоритетов. И серьезно выбешивает программистов.
Решений у этой проблемы несколько.
Первое, пожестче – не давать менеджеру ставить срочность и важность. Пусть просто записывает задачу. Если есть какие-то дополнительные требования, способные повлиять на приоритет, пусть излагает в описании задачи. На самом деле, вдруг там и правда срочно? Координатор, или тимлид, или ведущий программист в этом случае будет ориентироваться на информацию от менеджера.
Второй вариант, помягче – делать две оценки срочности и важности. Одну – от менеджера, вторую – от того, кто что-то понимает, а итоговый приоритет вычислять по сумме условных единиц. Максимум 3 условных единицы от менеджера, и максимум 3 – от координатора. Система приоритетов станет более многогранной и сбалансированной.
Ну и не стоит забывать простое правило: есть на свете задачи не срочные и не важные. Когда появляются такие регуляторы, как срочность и важность, то рука сама так и тянется ими воспользоваться. Кажется, что чего-то не хватает, когда срочность и важность не указаны.
Отсутствие срочности и важности у задачи – это нормально. Но есть одна проблема – такая задача, теоретически, может не выполниться никогда, если постоянно будут появляться новые, имеющие хотя бы одну условную единицу приоритета. Как такой ситуации избежать, поговорим в другой раз.
Резюме
- Матрица Эйзенхауэра – это простой инструмент определения приоритетов;
- Приоритет регулируется двумя признаками – срочность и важность;
- Срочная задача – та, потери от невыполнения которой высоки;
- Важная задача – та, которая влияет на будущее;
- Срочность приоритетнее важности;
- Бывают задачи не срочные и не важные;
- Приоритеты работают только при осознанном определении срочности и важности.
