Уверен, многие сталкивались с ситуацией, когда почти все задачи внезапно становятся срочными.
Открываешь таск-трекер — пять задач, и у каждой высокий приоритет. Сразу возникает вопрос: за что браться первым?
Сначала может появиться лёгкая паника. Потом собираешься и начинаешь придумывать приоритет самостоятельно. Например, смотришь, какую задачу можно сделать быстрее, берёшь её и закрываешь. Возвращаешься к списку.
Опять нужно решить, что брать следующим. На это снова тратятся внимание и силы.
Хуже, когда берёшь очередную задачу, начинаешь разбираться и через какое-то время понимаешь: сделать её нельзя, пока не выполнена другая. Время уже потрачено, а результата нет.
Так высокий приоритет перестаёт помогать и начинает создавать дополнительную работу.
Дальше я буду говорить о разработчиках, но данная проблема не привязана к профессии: если человеку дают несколько одинаково срочных задач без понятного порядка, приоритеты перестают работать в любой команде.
Инфляция приоритетов
Такая ситуация называется инфляцией приоритетов — когда слишком много задач объявляют важными или срочными и высокий приоритет постепенно теряет смысл.
Если в очереди десять задач и восемь из них имеют High Priority, этот статус уже ничего не говорит разработчику.
Он отвечает на вопрос:
Эти задачи важные?
Но не отвечает на гораздо более полезный:
Какую из них мне делать первой?
В результате приоритет всё равно приходится определять вручную уже самому разработчику.
Иногда выбирается самая простая задача, иногда самая понятная, а иногда та, про которую последним спросил менеджер. На выбор может повлиять и самый настойчивый заказчик.
Получается странная ситуация: формально приоритеты есть, но фактически порядка нет.
Выбор следующей задачи — тоже работа
Кажется, что посмотреть на пять задач и выбрать одну мелочь, но этот выбор приходится повторять снова и снова.
Нужно вспомнить контекст каждой задачи, оценить её размер, понять зависимости, сравнить возможную пользу и решить, за что взяться.
Это тоже требует внимания.
В книге «Думай медленно… решай быстро» Даниэль Канеман описывает медленное, сознательное мышление: оно требует усилий и внимания. На практике это хорошо заметно и в работе с задачами. Чем больше лишних решений приходится принимать разработчику, тем меньше внимания остаётся на саму работу.
Особенно странно тратить это внимание на вопрос, который в большинстве случаев должен был быть решён раньше:
Что для нас сейчас действительно важнее?
Приоритет — это ещё и порядок
Одного High, Medium и Low иногда недостаточно.
Допустим, есть пять задач. Все стоят в высоком приоритете.
Разработчик идёт к менеджеру и спрашивает:
Что из этого действительно нужно сделать первым?
После разговора оказывается, что две задачи критичны, а остальные три просто хотелось бы сделать в ближайшее время.
У разработчика есть возможность закончить три задачи.
Тогда порядок становится понятным:
- сначала первая критичная задача;
- потом вторая;
- из оставшихся выбирается самая важная.
Две другие остаются на следующий цикл. На следующем планировании мы смотрим на них уже вместе с новыми задачами и снова расставляем приоритеты. Это нормальная практика.
Приоритет не обязан оставаться у задачи навсегда. Сегодня задача может быть пятой в очереди, а через неделю стать первой, потому что изменились обстоятельства или приоритеты бизнеса.
Главное, чтобы в каждый конкретный момент команда понимала порядок работы.
Похожая проблема возникает и на уровне стратегии. McKinsey приводит пример североамериканского поставщика финансовых и программных сервисов: его пятилетняя стратегия разрослась более чем до 25 приоритетов. Руководство поняло, что такой список невозможно одновременно контролировать и понятно объяснять сотрудникам, поэтому стало выбирать не более пяти стратегических приоритетов на год.
Масштаб здесь другой, но принцип тот же: длинный список важного ещё не помогает понять, на чём сосредоточиться сейчас.
Зависимости должны быть видны заранее
Ещё одна причина, почему одной цифры приоритета недостаточно. Задачи могут зависеть друг от друга.
Формально эта зависимость может быть описана внутри ТЗ. Но чтобы её обнаружить, разработчику сначала придётся открыть задачу, прочитать описание и разобраться в контексте. Только после этого он поймёт, что начинать с неё пока нельзя.
Получается, часть времени уже потрачена просто на то, чтобы выяснить правильный порядок работы.
Если зависимость известна заранее, лучше показать её прямо в таск-трекере.
Зависимости надо выявлять ещё при планировании.
Номер задачи сам по себе ничего не говорит о порядке работы. Это просто идентификатор.
«Может, успеет всё» — не приоритет
Иногда руководитель видит пять важных задач и ставит высокий приоритет всем пяти.
Логика может быть примерно такой:
Всё важно. Дадим все пять, а там, может быть, получится сделать всё.
Но это не приоритизация. Это перенос решения на разработчика.
Если сотрудник физически может выполнить три задачи из пяти, руководителю всё равно придётся ответить на вопрос:
Какие три задачи мы хотим получить, если остальные две сделать не получится?
Лучше ответить на него сразу.
Иначе сотрудник может идеально выполнить три задачи — и потом узнать, что бизнес на самом деле ждал совсем другие три.
Срочность создаёт давление
У постоянного High Priority есть ещё один эффект. Он создаёт ощущение, что разработчик всё время отстаёт.
Одна срочная задача — понятная ситуация:
Сейчас нужно отложить остальное и решить вот это.
Пять срочных задач одновременно дают другое сообщение:
Ты уже не успеваешь пять важных вещей.
Хотя физически делать пять задач одновременно всё равно невозможно.
Если такая ситуация становится постоянной, высокий приоритет перестаёт восприниматься как сигнал срочности и превращается в фон. Постоянное ощущение, что вокруг всё горит и ты всегда что-то не успеваешь, вполне может становиться дополнительным источником стресса и выгорания.
После отсутствия особенно нужен контекст
Отдельная история — возвращение сотрудника после отпуска или другого длительного отсутствия.
Плохой сценарий выглядит примерно так:
Пока тебя не было, мы решили, что вот эти три задачи очень срочные. Забирай.
Человек ещё не знает, что происходило последние две недели, какие решения приняли, почему изменились приоритеты и какие новые зависимости появились.
При этом от него уже могут ждать быстрого результата.
В такой ситуации время всё равно придётся потратить — только уже не на выполнение задачи, а на восстановление контекста.
Поэтому перед срочной задачей после длительного отсутствия полезно сначала объяснить:
- что изменилось;
- почему задача стала важной;
- что уже сделали остальные;
- от чего она зависит;
- какой результат сейчас нужен.
Несколько минут передачи контекста могут сэкономить часы неправильной работы.
Что надо сделать
Вернуть порядок
Разобрать очередь, которая уже есть, и дать команде понятный порядок хотя бы на ближайшее время. Для этого руководитель вместе с теми, кто отвечает за продукт, определяет, какие задачи действительно нужно сделать первыми, какие могут подождать, а какие пока нельзя начать из-за зависимостей. Если одна задача заблокирована, должно быть заранее понятно, к какой переходить, чтобы команда не простаивала.
Для меня хороший приоритет должен отвечать не только на вопрос «насколько это важно?», но и на вопрос «что делать следующим?».
Поэтому я бы придерживался нескольких правил:
- не ставить высокий приоритет всем задачам подряд;
- явно определять порядок действительно важных задач;
- учитывать реальную загрузку и возможности команды;
- разделять текущие задачи, следующие и бэклог;
- показывать зависимости между задачами;
- задавать порядок подзадач внутри родительской задачи;
- регулярно пересматривать приоритеты;
- давать контекст, если человек не участвовал в обсуждении;
- не перекладывать окончательный выбор бизнес-приоритета на разработчика.
Даже если важны все задачи, какую-то из них всё равно придётся делать первой. Если пять задач имеют самый высокий приоритет, разработчику всё равно придётся решить, какую открыть первой. Если это решение каждый раз принимает сам разработчик, значит приоритизацию не сделали — её переложили на разработчика.
Разделить очередь на три группы
Задача, которая не попала в начало очереди, не обязательно становится неважной. Для неё просто нет обещания, что команда возьмёт её прямо сейчас.
На практике задачи можно разделить на три группы:
- делаем сейчас — короткий список, который соответствует возможностям команды и имеет явный порядок;
- делаем следующими — задачи, к которым команда перейдёт после текущих;
- оставляем в бэклоге — идеи и запросы без обещанного срока, которые ещё нужно сравнить с новой работой.
Так заказчик видит, что его задача не потерялась, но понимает: сейчас она не первая. На следующем планировании задачи из второй и третьей групп снова сравниваются с новыми. Часть из них поднимется выше, часть останется в бэклоге, а устаревшие можно будет закрыть.
Есть работа, которую срочные продуктовые задачи будут постоянно вытеснять: технический долг, обновление зависимостей, улучшение инструментов. Если она важна для команды, под неё лучше заранее выделить часть времени, а не надеяться, что когда-нибудь появится свободное окно.
Определить порядок подзадач
Если родительская задача описывает один бизнес-результат, приоритет нужен прежде всего ей. Ставить High Priority каждой подзадаче необязательно: это не добавит информации. Если некоторые шаги можно делать параллельно, это тоже лучше указать в связях между подзадачами.
Если одна подзадача блокирует сразу несколько родительских задач или имеет самостоятельный результат, её лучше вынести в отдельную задачу и связать с теми, которые она разблокирует. Тогда у неё появляется собственное место в общей очереди.
Найти причину перегруза
Навести порядок в списке недостаточно. После этого лиду или руководителю стоит разобраться, откуда вообще взялось столько срочной работы.
Например, у компании могло появиться новое направление, но состав команды остался прежним. Мог вырасти объём поддержки, добавиться незапланированная работа или измениться одна из бизнес-целей, а старые обязательства при этом никто не снял. В результате тот же состав команды должен выполнять больше задач, чем было заложено в план.
Такой разрыв между объёмом работы и возможностями команды важно показывать бизнесу. Замалчивать его и компенсировать переработками опасно.
По отчётам это может выглядеть как рост эффективности и даже стать поводом похвалить руководителя: прежний состав команды вдруг начал делать больше. Но если результат держится на переработках, эту дополнительную нагрузку сотрудники оплачивают своим временем и силами.
Кто-то сможет работать в таком режиме дольше, а кто-то выгорит или решит уйти.
Пересмотреть планирование
Полезно вернуться и к планированию квартала или целей и честно ответить себе на несколько вопросов:
- учли ли мы работу, которой не было в плане;
- заметили ли, что новое направление заберёт часть ресурсов;
- убрали ли старые обязательства, когда появились новые;
- предупредили ли бизнес, что текущего состава команды может не хватить;
- не побоялись ли прямо сказать о рисках и ограничениях.
Смысл такого разбора не в том, чтобы найти виноватого. Нужно понять, какое допущение оказалось неверным, договориться с бизнесом о реальном объёме работы и не повторить ту же ситуацию в следующем спринте.
Команде тоже важно говорить правду о происходящем. Если кто-то регулярно перерабатывает, нельзя делать вид, что всё идёт по плану. Честнее пересмотреть сроки, объём задач или ресурсы и решить, что действительно должно быть первым.