Я долго учился правильно писать это слово: приоритизация, но намного дольше я учился правильно приоритизировать.
Собственно, в самих приоритетах запутаться сложно даже начинающему менеджеру, их всего 4: Низкий, Средний, Высокий и Критический (бывает больше, но это, обычно, извращения). Но вот как их правильно выстроить, как потом отстоять перед заказчиками и какие подводные камни тут вас будут ждать, я расскажу кратко ниже.
Приоритизировать можно и нужно что угодно: собственный поток задач, задачки в беклоге, поток требований от Заказчика, поток багов от Куа, поток задач в разработку – короче, все.
Это очередная статья посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.
Откуда взялись именно 4 приоритета?
Начинается все с трех: высокий, средний и низкий. С ними все просто и ясно: высокий – важно, средний – такое себе, низкий – не важно. Указанных трех, как правило, мало: помимо простого высокого нужен приоритет максимальный. Так появляется четвертый – критический. Это не просто важно, а вот надо «мухой полететь и немедленно сделать». ASAP, как говорят в народе. Указанных четырех, как правило, хватает для любых целей. Бывает так, что их больше, но я считаю, что четырех основных приоритетов должно хватать для любых случаев приоритизации, а все остальное ее усложняет, не давая никаких преимуществ. Как удержаться в 4х приоритетах, как и что именно должно проходить через эти значения – в деталях ниже.
Новые фичи - приоритизация
Для заказной разработки по фикспрайс контрактам.
Заказная разработка делается по ТЗ, которое, в конце дня, должно быть выполнено полностью, иначе не закроют контракт. Потому играться с приоритизацией здесь особого смысла нет, все можно разложить в декомпозицию работ, спланировать и сделать с единым приоритетом.
С приоритетом «высокий» или «критический» можно пускать продолбанные задачи, а остальное пускать с приоритетом «по умолчанию». На моих проектах, по крайней мере, другого никогда на требовалось.
Разработка по беклогу (контракты TnM с подрячиком, inhouse разработка).
Тут интереснее. Как правило, у вас в беклоге задач будет больше, чем может сделать команда (и это правильно, потенциальной работы должно быть больше, чем людей), а значит, без приоритизации не обойтись.
Механизмы приритизации от самых неправильных к более правильным такие:
Кто больше всех орет и влияет на ИТ - тот критичнее, кто меньше всех орет – у того приоритет ниже. Такой механизм, к сожалению, встречается часто в компаниях, где ИТ департаменту не хватает сил или влияния, чтобы запустить иную приоритизацию. Достоинство механизма только в том, что он лучше полного отсутствия приоритетов, плюс тот, кому нужнее, и правда может сильнее всех кричать.
Все остальное – недостатки. В первую очередь потому, что крики и ругань на приоритизации — это показатель хаоса и не выстроенного процесса, а в хаосе побеждает не тот, кому важнее, а тот, кто кричит громче. Проигрывает компания.Более здоровый подход – по степени влияния на бизнес: сколько денег потеряет компания, сколько денег заработает компания. Достоинство подхода в том, что оценивается экономический эффект и по нему выстраиваются все задачи. Недостаток метода в том, что обоснование экономического эффекта – та еще сказка, и далеко не каждый кейс можно разложить на очевидный экономический эффект. То есть неочевидные задачи при таком подходе будут всегда в конце хвоста, а делаться будут только самые простые и прямолинейные.
Еще более здоровый – по степени влияния на бизнес + по сложности задачи. Тут в верх списка попадут небольшие и важные задачи, а неважные и тяжелые – вниз. Мне этот подход нравится больше всего. Но недостаток тот же самый – кто оценивает экономический эффект и как его проверять?
В целом по приоритизации беклога можно почитать в «Настольной книге project-менеджера» Завертайлова – там расписано очень неплохо, за исключением петли обратной связи с замером реального экономического эффекта.
Опять таки: на словах это все звучит красиво, но я не видел ни в одной компании замера реального экономического эффекта и его сравнение с заявленным, что делает все методы оценки выше все равно производными от самого первого: кто громче закричал, того и тапки. Увы.
Если у вас есть опыт настройки эффективной inhouse прироитизации беклога помимо упомянутой – поделитесь в каментах, интересно узнать.
Баги и их приоритизация
Тут тоже достаточно 4х приоритетов, их же обычно описывают в SLA поддержки, в ПМИ или в стратегии тестирования.
Приоритеты, как правило, значат:
Критический –шоустоппер. "Наташа, у нас все упало" и все бегут устранять.
Высокий – не шоустоппер, но страдает много людей. Выживают как-то, но страдают сильно.
Средний – кто-то страдает, но есть обходной путь решения вопроса (workaround).
Низкий – страдает чувство прекрасного, незначительно страдает юзабилити и так далее. То есть жить можно и так, но лучше бы исправить. Оно же улучшайзинг.
Но это в теории. В реале и исполнители, и заказчики давно смекнули, что Низкий приоритет – это то, что делать никто и никогда не будет, Средний – делается в виде большого одолжения, а реально все смотрят на Высокий и Критичный. А если задач или багов много – только на Критичный. И приводит это к девальвации приоритетов.
К примеру, у меня был проект на котором все давно забили на все приоритеты, кроме Критического, зато в Критическом создали под-приоритеты вида: Критический-Средний, Критический-Высокий и Критический-Критический, которые мы нежно звали «Кри-Кри» по имени одного из героев серилала «Элен и ребята» из 90х (Пишу и понимаю, что читать это будут люди, которые в 90х еще не родились, ну и ок, олдам привет).
Почему случается девальвация приоритетов? Виноваты в ней обе стороны: Заказчик, со своей стороны, манипулирует приоритетами, чтобы сделать за счет Исполнителя больше работы в единицу времени и заработать на этом побольше (чем больше критичных – тем быстрее их должен сделать исполнитель). Исполнитель манипулирует приоритетами, чтобы сделать поменьше работы и заработать на этом побольше (давайте перетащим все в низкий приоритет, а потом сдадим без них). Причины веские и у тех, и у тех - базара ноль, но в итоге получается классическая игра с двумя партнерами, где каждый хочет обмануть другого. Задача менеджера, который заботится о хороших отношениях с бизнесом - не обманывать, а договариваться в формате win-win. Это и есть площадка для отстаивания корректной модели приоритизации, указанной выше.
Разумеется, это означает, что в работу надо запланировать все ошибки, включая низкий приоритет.
Если вы заказчик, очень рекомендую не забывать, что если отгружать исполнителю баги исключительно с высоким и критическим приоритетом, то он либо разорвется, как хомяк, либо сделает так, что вы потом сами плеваться будете. Не бывает все и сразу и ASAP. И если у вас такие приоритеты, скорее всего, вы сами их плохо выставляете.
И напоследок о личной приоритизации.
Логика внутренней приоритизации ваших менеджерских задач подчиняется тем же правилам: у вас так или иначе будет внутренний беклог планируемых задач, которые надо делать, и поток багов с прода (или аналогичное в виде заказчика , который звонит вам прямо в мозг и требует сделать немедленно).
И чтобы не разорваться в этом все, как хомяку, вам понадобится научиться выделять главное, приоритизировать, договариваться с вашими заказчиками и затем не позволять сбить вас с выбранного курса.
Это небольшая теоретическая база по приоритизации, а дальше – только суровая практика по выработке вашего подхода. Нет, не к приоритизации, а к согласованию приоритетов. Это намного важнее, как показывает практика внедрения.
Так что удачи с согласованием ?