Как аналитику работать с приоритетами задач
Скажу сразу — приоритизировать свои задачи сложно. Я дошла до четких установок про то, как приоритизировать только тогда, когда несколько лет после работы аналитиком поработала Product Owner’ом, менеджером проекта и руководителем отдела.
Поэтому все, что ниже — это взгляд на работу аналитиком под призмой того, как на это все смотрит ваш «руководитель». Далее я буду применять термин «руководитель» очень вольно — это может быть любой член команды, который отдает вам больше одной задачи в один период времени, без указания в каком порядке делать задачи. Потому что в таком случае он берет задачу приоритизации на себя. От вас будет требоваться только отдавать результаты один за другим в порядке, который за вас уже определили.
Также вольно можно говорить о приоритетах в любой другой работе, но мне ближе аналитика для примера.
Что такое приоритизация задач? Это сортировка всех задач, которые валятся на аналитика в порядке их важности и сроков выполнения.
Тема про приоритеты в работе очень тесно связана с такими soft skills, как ответственность и самостоятельность. Руководитель отдает вам право принимать решение, как вы управляете собственным временем, и верит, что работа будет сделана в срок и в полном объеме, а если у вас есть вопросы, что важнее, то вы придете к нему заранее.
Аспекты работы и приоритеты
Приоритизация касается нескольких аспектов работы аналитика. Давайте рассмотрим линии поведения в каждом, которых, как я считаю, стоит придерживаться, хотя бы до тех пор, пока вы не выстроили для себя свои ориентиры.
Если у вас есть договор / техническое задание, то все требования из него — ваш первый приоритет. Вам сдавать проект по этим требованиям, и в случае, если какое-то требование не реализовано, все те пожелания, которые вы сделали для заказчика, станут не важны. Договор или техническое задание — это юридический документ. Не отвлекайтесь на что-то лишнее и напоминайте команде или менеджеру об обязательствах. Так как работа с требованиями находится в вашей компетенции — ваша же и ответственность.
Если вы, например, работаете по какому-то согласованному скоупу работ на релиз, то принцип тот же, просто оформлены эти требования уже не юридически.
Очень часто бывает, что аналитик один на проекте, и перед аналитиком стоит, например, две задачи на один и тот же день — дописать руководство пользователя (которое не горит, но которое уже хочется закончить) или сформулировать постановку на разработку.
В этот момент я всегда задаюсь вопросом «а есть ли у команды достаточно работы и не торможу ли я работу кого-то еще?».
Время простоя целой команды разработки — это минус в бюджет компании и понижение доверия от менеджера проектов, который отвечает за бюджет проекта. Поэтому если у команды есть запас по задачам для реализации, то можете дописывать руководство. В противном случае смотрите, не тормозите ли вы кого-то еще. А еще не срываете ли вы сроки, выставленные Руководителем — часто две задачи с одним и тем же сроком можно разнести по дедлайнам, но нужно заранее понять, что вы не успеваете, и сообщить о проблемах Руководителю. Причем это нужно сделать за столько времени, чтобы в случае жесткой даты дедлайна вы успели доделать задачу, которая не двигается.
При активной работе с заказчиком хотелки, вопросы и идеи влетают от Заказчика почти каждый день, и часто письма имеют приоритет «срочно! важно!».
Пожалуйста, не бросайтесь реагировать и брать в работу. Приоритеты по скоупу работ и новым требованиям, которые включаются или нет в план проекта, принимает не аналитик. За содержание и объем проекта отвечает менеджер проекта, если не сказано иное (а если у вас за это отвечает аналитик — у вас есть шанс получить повышение, вы выполняете две работы одновременно).
Стратегия поведения, которая опробована мной и уже несколькими командами — это честно сесть с заказчиком и договориться, что делать с такими требованиями и письмами. Нужно будет определить совместно, что считается срочным и важным, и как заказчик хочет, чтобы вы действовали в таких ситуациях. Вариантов может быть очень много — от простого ответа на письмо в течении дня до приостановки релиза и переприоритизации скоупа на релиз.
Из недавнего — пример.
Мы развивали систему по agile, и пользователи уже работали в системе. Рабочая группа от Заказчика (РГ) имела явную дорожную карту того, что должно быть сделано в каждом выпуске. Но от пользователей постоянно прилетали интересные доработки, которые в конечном итоге повышали удобство системы и их очень хотелось сделать. РГ каждый день присылала нам по 5–7 писем с пожеланиями и вопросами. Проблема была в том, что скоуп уже был сформирован на несколько релизов вперед, а аналитик не успевал делать ничего, кроме как отвечать на эти письма, причем по нескольким письмам завязывалась активная переписка. Дополнительно РГ со временем начала злиться, что на их письма «срочно! важно» отвечали с задержкой в несколько дней.
Мы сели с РГ и договорились о следующем:
На все письма мы отвечаем в порядке их прихода (принцип FIFO «Первым пришёл — первым ушёл»). Если какое-то письмо имеет признак важности — мы отвечаем на него первым и затем опять возвращаемся к обработке очереди писем.
В моменты пиковой нагрузки на аналитика (в начале и конце релиза) стараемся отвечать на 2–3 письма в день, в середине релиза нагоняем все «долги». Тут мы подумали о привлечении дополнительного аналитика, но тестер и аналитик решили разделить обязанности по письмам — если был вопрос по системе, тестер готовил ответ самостоятельно и аналитик только проверял и отправлял заказчику.
В скоупе каждого релиза определили низкоприоритетные задачи, занимающие 20% времени от общего скоупа, которыми можно было пожертвовать (либо перенести в следующий релиз) и сделать какие-то критические хотелки от пользователей. Решение о включении или исключении какой-то фичи должно было приниматься совместно с РГ и только до середины релиза, чтобы команда успела реализовать эти фичи.
Принцип матрицы Эйзенхауэра
Работа над приоритетами всегда требует анализа всего списка ваших задач. Мне в работе помогает матрица Эйзенхауэра, которая позволяет разбивать задачи по признаку Срочно / Важно.
Важно и срочно. Это ваш кризис или дедлайн, о котором вы не знали, а он наступил. Примером может быть прилетевший за два дня до закрытия этапа по договору список замечаний к отчетному документу, который вы планировали спокойно сдать. Отложить срок сдачи нельзя, и без исправлений по этому документу у вас его не примут. Решение: вы бросаете все и занимаетесь только им.
Важно, но не срочно. В этом квадрате находятся все задачи по проекту, которые нужно сделать в плановые сроки: реализовать требования технического задания, сформировать выходные документы, пройти обучение на повышение квалификации. Решение: нужно иметь список таких задач с указанием срока их выполнения. Тут я бы дополнительно посоветовала иметь два срока — срок выдачи результата и формальный срок дедлайна. Так у вас будет люфт по времени в случае кризисных задач, и возможность что-то поправить, если придут замечания.
Не важно, но срочно. Обычно это задачи ради задач. Ярким примером может явиться запрос заказчика выгрузить всю jira с статусами по реализации, чтобы понять, насколько вы быстро реагируете по проблемам. Решение: обсуждение и пересмотр сроков таких задач, делегирование задач, обсуждение реальной ценности задачи.
Не важно и не срочно. По возможности избегайте таких задач, они отвлекают от вас от дел. Например — менеджер проекта присылает вам презентацию, которую они сделали с маркетингом по всем проектам заказчика с просьбой посмотреть и дать свое мнение. Это — не ваша обязанность и даже близко не находится в вашей компетенции. Решение: при опознании такой задачи, вашей первой реакцией должно быть слово «нет». Не берите «на борт» их прямо сразу, потом не избавитесь, отказаться всегда сложнее, когда вам уже их скинули.
Про ответственность и самостоятельность
Я настоятельно советую поначалу не полагаться на свое понимание приоритетов. В начале нового проекта, при коммуникации с новым заказчиком, в новой команде нужно обсуждать ожидания от работы аналитика. Так Руководитель будет знать, что вы с ним одинаково понимаете, что нужно делать. Плюс, в любой непонятной ситуации я бы посоветовала сразу же обращаться к Руководителю и прояснять ожидания. Ситуации могут меняться, вы можете знать не все, а Руководитель не успел до вас донести информацию. Меньше непонимания — меньше стресса.
