Как проект-менеджер перестал грустить, определил приоритеты для команды с помощью матрицы приоритизации задач

Ситуация: в проекте много задач-фич, и совершенно неясно, что делать в первую очередь. Осложняется тем, что решение «что делать в первую очередь» влияет на всю компанию. Решение — использовать любую матрицу приоритизации задач.

То есть каждую задачу оценить по своим критериям, вроде «быстро», «легко», «полезно» и так далее. В работу взять только те, что набрали наивысшую оценку. Но есть нюансы! Разберемся с ними с помощью условного проект-менеджера Остапа.

На картинке условный проект-менеджер Остап, сидит и грустит. История про Остапа, но мы-то с вами понимаем, что вместо Остапа будете вы или любой менеджер, которому приходилось принимать решение, «что делать в первую очередь».

У Остапа классическая проект-менеджерская ситуация: команда приносит классные идеи. Некоторые предложения улучшают продукт, а другие обещают принести больше клиентов. Задач о-о-очень много, и легко потеряться. За что браться и куда направить фокус внимания?

В общем, Остапу кажется, что он постоянно что-то упускает, из-за чего можно сделать серьезную ошибку. К тому же есть стандартные нюансы вроде кто-то не хочет или не может делать задачу Х, нужно искать исполнителя, а задача Y потребует большого бюджета и непонятно, стоит ли за нее вообще браться?

Опытные проект-менеджеры скажут: в первую очередь избавляйся от срочных и важных задач, как завещал Дуайт Эйзенхауэр! Однако что делать, если «срочных» и «важных» слишком много?

Максим Дорофеев утверждает, что между «срочными» и «важными» мы выбираем самые понятные задачи, скорее всего, они будут ещё и интересными для исполнителя. Можно заявить, когда слишком много «срочных» и «важных» задач, то у нас появятся дополнительные факторы, которые будут влиять на «что делать в первую очередь».

Когда люди делают интересные задачи — они развивают навыки, которые интересны им, и это значит, что на другие задачи не хватит времени и сил. Потребности бизнеса и клиентов идут во вторую очередь.

Если долго игнорировать бизнес-задачи и потребности клиентов, может прилететь. Люди получат интересный опыт, положат проект в портфолио и будут искать новую работу.

В общем, «понятная» задача, которая, «если повезет, будет срочной и важной», — плохой критерий для определения, «что делать в первую очередь». Чтобы меньше зависеть от «понятности» или «интересности», опытные проект-менеджеры проводят более глубокую оценку задачи и используют различные матрицы приоритизации задач: матрицу Эйзенхауэра или ее вариации, AARRR, RICE, WSJF и другие методики.

Впрочем, все методики работают по одному принципу: берешь задачу Х, оцениваешь ее по различным критериям вроде «важности». Добавишь много критериев — будет более точная оценка.

Матрица приоритизации задач — простой и известный инструмент. Самый популярный, пожалуй, матрица Эйзенхауэра.

Обычно ее используют так: берут задачу Х, задают к ней вопрос: «Эта задача важная?», и у нас два варианта ответа — да и нет. Если критериев «важности» и «срочности» не хватает, можно добавить «легко сделать», «наибольшее влияние на результат» и прочее. Тогда это будет уже другая матрица, но суть оценивания останется, а у горы задач появляется сортировка «задача важная, срочная и легко сделать».

Но даже используя матрицы, может быть путаница. Что делать раньше: «Х — то, что срочно, легко сделать и принесет больше охватов» или «Y — то, что не срочно, но принесет больше клиентов».

В классической матрице Эйзенхауэра две шкалы: важно и срочно и две оценки: да и нет или 1 и 0. Но не все задачи одинаково важны, поэтому можно добавить пятибалльную или десятибалльную шкалу оценки. Задача «прикрутить эквайринг» важна на 5, а «исправить отображение меню в Safari» — на 3.

А еще взгляд на одинаковые задачи у разных специалистов может быть разным. Поэтому можно одну задачу оценивать разными специалистами. Если к оценке задачи «меню в Safari» пригласить комьюнити-менеджера, маркетолога и веб-мастера, то тот, кто чаще всего получает жалобы на неработающее меню, поставит наивысший приоритет задаче, но все мнения помогут проект-менеджеру Остапу принять более объективное управленческое решение.

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

На самом деле гугл-таблицы — это костыль, задачи в них нужно перенести, хорошо, если есть экспорт. К тому же труднее отследить, кто оставил оценку, а кто нет. Есть вариант поудобнее — сервис приоритизации «Дукалис».

Сервис сам заберет ваши задачи, по крайней мере, если работает в популярных таск-менеджерах: «Трелло», «Жира», «Асана», «Битрикс» и прочее. Синхронизирует задачи в реальном времени и покажет, «кто не проголосовал», а также — «вот у этой задачи слишком большая разница оценок». Помните пример с «меню в Safari», разработчик считает, что это не важная задача, а комьюнити-менеджер каждый день получает жалобы на это, поставит большую оценку — проект-менеджер увидит это и разрулит.

Выглядеть это может вот так ↓

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

Подробнее с «Дукалисом» можно познакомиться на сайте hello.ducalis.io. А можно использовать их шаблон в гугл-таблицах. Шаблон в гугл-таблице — это законно!