Приоритизация задач: высшая математика или легкая разминка перед завтраком?

Это первая статья из цикла об основах, методиках и ошибках приоритизации. Сейчас поговорим о сложностях приоритизации. А в следующей статье разберем, какие ошибки подкидывает нам наш мозг, когда дело касается сложного выбора...

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

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

Что же такое приоритизация?

Определение, которое дает Wikipedia: «Приоритизация — понятие, показывающее важность, первенство. Например, приоритет действий определяет порядок их выполнения во времени». Если пойти еще дальше в этимологию слова, увидим слово «priority» («предшествующий»), еще дальше — «prior» («передний», «прошлый», «старший»).

Из определения становится понятно, что основная цель приоритизации — понять, «что важнее чего». После того как мы каким-то образом это поняли, результаты приоритизации нужно как-то закрепить или задокументировать: расставить в порядке приоритета или наделить особыми свойствами (номер, вес, важность, срочность и т. д.).

Сложности приоритизации

Выбор измерения

Одна из основных сложностей проведения приоритизации — выбор шкалы или измерения, относительно которого будут расставляться приоритеты.

Даже на простом примере можно проиллюстрировать сложность выбора измерения.

Вот представьте: вы проводите семинар для группы участников, и вас до начала занятий просят провести ранжирование (это синоним приоритизации) в группе. У вас очень немного параметров, чтобы сделать это качественно, и все они так или иначе связаны с внешними атрибутами: алфавитный порядок фамилий, возраст, рост. По этим измерениям мы сможем легко расставить приоритет. И даже повторения будут не страшны, т. к. их должно быть немного.

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

По внешним признакам легко провести ранжирование. Но когда вас попросят оценить их знания и потенциал в теме семинара, ваша предыдущая приоритизация уже не имеет смысла, и нужно выбирать новые параметры и новые способы их проверить.

Чтобы измерение хорошо подходило для приоритизации, оно должно обладать несколькими свойствами:

  • Сравнимость. Получив два значения на шкале, мы должны точно знать, что лучше и что хуже. Прибыль в 20 у.е. лучше прибыли в 7.
  • «Генеральность». Все объекты сравнения должны иметь свойство этой шкалы. Работу землекопа и программиста мы можем оценить только через шкалы время, стоимость и т. д. Нет смысла сравнивать их производительность по «количеству операций в час».

К сожалению, для многих процессов, действий или даже предметов сравнение через единую шкалу — очень малоценно. Вспомните войну фанатов устройств от Apple и Google! Там в ход идут десятки и может даже сотни измерений, которые выходят за рамки физических и технических характеристик.

Комбинирование измерений

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

Признаться, я тоже не думал, что этот раздел математики мне когда-то пригодится, а тут, оказывается, мы делаем это каждый день!

Пример. Как бы мы выбирали автомобиль? Это достаточно сложный продукт, и обычно (кроме случаев «хочу красненький» :)) выбирают по нескольким шкалам:

1. Мощность.
2. Внешний вид.
3. Удобство салона.
4. Вместительность.
5. Комфортность вождения.
6. Безопасность.
7. Цена и т. д.

Тут-то и начинается «ад комбинаторики». Во-первых, надо понять, какое измерение нам важнее всего («OMG, это же приоритизация для измерений! Это рекурсия какая-то»). Во-вторых, многие шкалы очень относительны. Как измерить удобство салона или комфорт вождения? В-третьих, не ясен подход к сравнению всех показателей: лучше мощность с убогим внешним видом и высокой безопасностью или хорошая цена при средних параметрах?

Чтобы приоритизация по нескольким измерениям была успешна, нам опять нужны несколько условий:

  • «Вес» или приоритет каждой шкалы в общем списке измерений. Что важнее: «цена производства» или «интеграция с новой системой»?
  • «Вес» каждого значения внутри шкалы. «Низкая цена» побьет «плохой внешний вид» или нет?
  • Единая «формула», которая позволит собрать эти параметры и отобразить в одномерном пространстве (опять привет «факторному анализу»). Да, именно в одномерном, т. к. приоритет — ответ на вопрос «это важнее этого» по одной шкале :)

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

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

Нашим инженерным привычкам очень сложно смириться с мыслью, что не существует универсальной формулы. Нам хочется верить, что есть единый закон, который даст нам ответ. Но (по крайней мере, пока) этот подход не найден, и предлагаются десятки методик и формул проведения приоритизации, о которых и пойдет речь ниже.

Обсуждения

Теперь самая главная мысль, которую хотелось бы раскрыть в статье. Все методики приоритизации созданы для упрощения обсуждения приоритетов со всеми заинтересованными лицами. Заметьте: не заменить обсуждения техниками или формулами, а упростить и наполнить содержательными аргументами!

Именно для этих обсуждений, дискуссий, споров, конструктивных конфронтаций и созданы методы приоритизации. Наши методики и формулы — всего лишь база для обсуждений. Именно от этой базы мы будем отталкиваться, но уж точно не останемся на ней до конца обсуждений.

Наша цель — не только расставить правильные коэффициенты, но и убедиться, что такая расстановка как минимум приемлема для других участников, а как максимум — полностью поддерживается ими.

Вернемся к примеру с покупкой авто. Когда вы делаете взвешенный анализ по 10 параметрам, все может сложиться вполне качественно, и вы подберете вес параметра «мощность двигателя» так, чтобы точно победила машина с приемистым движком. Но попробуйте подключить к обсуждению друзей или семью. Тут вес параметров у каждого будет свой. И если вы не выслушаете пожелания этих участников, это может привести к конфликтам, недовольствам и даже к плохому выбору. Отец может уточнить: «А как автомобиль будет вести себя зимой, особенно на бездорожье?» И окажется, что температурный режим выпал из ваших измерений. Супруга может спросить о креплениях для детских кресел и на ваше утверждение «так у нас нет детей», вполне возможно, услышать: «Так, может, пора задуматься?» И внезапно с помощью приоритизации и выбора одного продукта вы узнаете о многом другом :)

Чтобы обсуждение было эффективным, есть несколько простых правил:

  1. Услышать всех. Каждый должен высказать комментарии и замечания по поводу приоритетов. И метод молчаливого согласия тут скорее мешает, чем помогает.
  2. Быть открытым к изменениям. Шкалы и приоритеты меняются под действием многих факторов. И цель обсуждения — понять, что пора вносить изменения.
  3. Минимизировать негативные ощущения участников группы: «меня игнорируют», «они не понимают, что это важно», «думают только о себе» и т. д. Это достигается неассертивным и неагрессивным обсуждением проблем каждого участника.

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

Еще раз скажем, что есть огромный соблазн заменить обсуждения на четкую приоритизацию с помощью формул и методов. К сожалению, это ускорит принятие решения, но резко ухудшит качество самого решения.

Как применяется приоритизация в проектах разработки программного обеспечения

Переходя от теории к практике, в нашей индустрии есть множество техник проведения приоритизации.

Есть очень хорошая статья (на английском), которая дает краткое описание 20 техник приоритизации продукта. Хорошее, но далеко не полное собрание техник, которые открывают глаза на разнообразие подходов. Автор статьи идет еще дальше и пытается систематизировать и классифицировать методы по двум измерениям, что сильно упрощает понимание.

Оказывается (!), наши потуги каждый раз придумать подход к приоритизации можно очень облегчить :)

Статья не покрывает всех техник приоритизации. Она дает быстрое описание и ссылки на подробные инструкции. Однозначный must read для ознакомления! Запланируйте себе спокойные 30-40 минут на чтение, в том числе и комментариев, которые содержат ссылки на другие техники.

В качестве упражнения, попробуйте в каждой из техник определить измерения и интегральную формулу, которую предлагают для конечной «одномерной» приоритизации.

Выбирайте для своих проектов любую технику или комбинацию техник. В комбинации они могут усилить друг друга. Но не старайтесь делать их слишком много, т. к. основная задача — обсудить сложные задачи, а не подобрать правильную шкалу :)

Вывод

Приоритизация — сложная задача. В наших проектах мы постоянно (ежедневно, еженедельно, ежемесячно) решаем непростую задачу многофакторного анализа и структуризации. И пока живет и развивается продукт, эта задача не закончится.

Правильная приоритизация построена на осознанном подходе к выбору измерений и «формул» для объединения этих измерений. Не существует ни одного универсального правила, и для каждого проекта вам придется подбирать заново измерения и формулы.

Человечество придумало уже много техник для приоритизации работ в проектах разработки ПО, поэтому не стоит их игнорировать. Лучше переиспользовать и улучшить.

Стоит напомнить еще раз, что все эти методики направлены на то, чтобы структурировать ваши обсуждения и сфокусироваться на главном. Общение с командой, пользователями и заинтересованными лицами (они же stakeholders) — ключ к правильному расставлению приоритетов, которые вы никогда не получите, просто применив любую комбинацию описанных выше техник.

Общайтесь, задавайте сложные вопросы, добирайтесь до сути вопроса «Почему это важно для вас сейчас?», и тогда у вас будут прекрасно сформированы приоритеты.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn



34 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Если бы сжиганием ведьм занимались специалисты по приоретизации, ведьмы бы умирали со смеху.

Если бы существовали ведьмы, то, вероятно, в той же альтернативной вселенной существовали бы и «специалисты по приоритизации»

Блин, меня терзают смутные сомнения.
Я несколько лет занимаюсь приоритезацией задач, отвечаю за роадмап продукта и все время держу руку на пульсе беклога и того, что попадает в наши релизы. А сегодня я узнал, что оказывается есть как минимум 20 методик этой самой приоритезации, о которых я грешным делом и не слышал ранее, и даже не подозревал, что они мне могут быть нужны.
Может правда у нас маленькая команда (15 человек в компании) и слишком близкая коммуникация, но обычно мы садимся 3-4 человека и обсуждаем что мы думаем пойдет в следующий релиз (примерно 1 раз в 3 месяца) — среди этого есть зарепорченные баги, запросы клиентов, которые мы им пообещали сделать, и наши собственные идеи. Мы конечно, ориентируемся на это, но обычно план выполняется примерно на 50-70%, потому что за это время приходят какие-то новые баги, новые клиенты с новыми запросами, которые мы пообещали им, если они купят продукт, ну и новые идеи, более важные, чем старые. Хотя если посмотреть на протяжении 1-2 лет, то мы делаем почти все, что когда-то собирались.
А потом еще просто садимся с продакт-менеджером и проходим по тому, что мы будем делать следующие 1 или 2 спринта, типа вот, вот, и вот. А он такой, давай не это, а это, и не так, а вот так. Ну давай. Ну все, взялись. Вот и вся методика.
А потом во время спринта еще прилетает что-то срочное, и вся украинская дев-команда начинает ворчать, что мы им методологию ломаем, «это не скрам», почему типа невозможно все спланировать на 100% точно?
Ну да, «это не скрам», невозможно, можете поворчать, who cares? :)

Я несколько лет занимаюсь приоритезацией задач, отвечаю за роадмап продукта и все время держу руку на пульсе беклога и того, что попадает в наши релизы. А сегодня я узнал, что оказывается есть как минимум 20 методик этой самой приоритезации, о которых я грешным делом и не слышал ранее, и даже не подозревал, что они мне могут быть нужны.

.
Ну вот, всегда приятно узнать, что есть альтернативные спососбы со своими достоинствами и недостатками.

А потом еще просто садимся с продакт-менеджером и проходим по тому, что мы будем делать следующие 1 или 2 спринта, типа вот, вот, и вот. А он такой, давай не это, а это, и не так, а вот так. Ну давай. Ну все, взялись. Вот и вся методика.

Отлично! посмотрите, вам достаточно 2 человека, чтобы принять решения. И еще у вас, вероятно, за много лет уже сформировались критерии важности-ценности-срочности, которые вам даже не нужно выражать в числах. Это уже в зоне неосознанной компетенции.

А потом во время спринта еще прилетает что-то срочное, и вся украинская дев-команда начинает ворчать, что мы им методологию ломаем, «это не скрам», почему типа невозможно все спланировать на 100% точно?

Так вот как раз статья может и поможет. Если скрам нельзя выполнить (хотя есть вопросы почему так), то можно дать людям объяснение, что как бы мы не планировали, есть вещи, которые могут поставить всю нашу работу «вверх дном». И даже десятки техник не дают гарантии правильного, полноценного, неизменного планирования. Это свойство системы, а бороться со свойствами системы всегда намного дороже.

Ну вот, всегда приятно узнать, что есть альтернативные спососбы со своими достоинствами и недостатками.

Согласен. Я просто написал, что мне в работе никогда не приходилось испытывать ощущение, что «что-то вот мне не хватает, чтобы правильно расставить приоритеты», поэтому даже не интересовался а есть ли специальные методики для этого?

И еще у вас, вероятно, за много лет уже сформировались критерии важности-ценности-срочности, которые вам даже не нужно выражать в числах.

Вероятно, плюс как я написал, компания небольшая, и слава богу :)

Если скрам нельзя выполнить (хотя есть вопросы почему так)

Потому что мы не делаем скрам, мы используем скрам. Но да, неисключено, что некоторым людям в компании, в том числе мне, стоит еще потренировать скилл «говорить нет», хотя все равно такие ситуации были, есть и будут, вопрос в частоте.

Это свойство системы, а бороться со свойствами системы всегда намного дороже.

Нет, это свойство планирования — потому что планирование это всегда гадание. Поэтому нет смысла расстраиваться, что что-то пошло не по плану и «во что бы то ни стало следовать правилам скрама», важно уметь правильно реагировать на изменения.

Есть очень хорошая статья (на английском)

статья — супер ) Ее ценность в том, что она систематизирует техники по целям и условиям приоритезации. Например: приоритезация для выбора фич для MVP и приоритезация для спринта — разные цели, разные техники.
Тоже всегда рекомендую.

Да, статья хороша, поэтому решил не переписывать, а просто дать ссылку. :)
Для поддержания объективности стоит заметить, что там собраны далеко не все техники. Я очень люблю WSJF, который описан в SAFe. Хотя и он не лишен недостатков, так как сильно играет в сторону тактических выиграшей, а не стратегических инициатив.

Правильная приоритизация построена на осознанном подходе к выбору измерений и «формул» для объединения этих измерений.

Какая это — правильная, Сергей?

Ну если вкратце, то это про всю статью: это подход, при котором мы смогли выбрать несколько измерений и шкал, которые упростили нам первоначальное ранжирование/приоритизацию, а потом мы все это «полирнули» взвешенной беседой :)

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

Вот приятно дискутировать с умным человеком. Спасибо за коммент.
Понимаешь, в том-то и загвоздка, что для каждого метода можно найти свою целевую функцию. То есть если брать один метод приоритизации (тот же «важно-срочно»), то целевая функция будет максимальной, когда значение 2 параметров — максимально.
Когда же мы говорим о комбинации методов, то целевая функция будет строиться из «весовых коэфициентов» для значения каждого метода. А это, к сожалению, субьективный процесс (как пример с выбором машины) когда каждый человек подгоняет их под себя.
В коллективе, у каждого из людей свой набор весовых коэфициентов, что дает нам или математическое вычисление среднего или долгое обсуждение и в итоге коэфициенты как-то общим усилием уточняются.
НО(!) если еще усложнить, то эти все коэфициенты — временные. Когда у нас лежит прод, то вся приоритизация будет направлена на стабилизацию, несмотря на то, что очень хочется увеличить средний чек.
Поэтому краткий ответ: целевая функция — принятие такой приоритизации всеми заинтересованными лицами :)

Это, безусловно, субъективный процесс. Однако же не сожалению, а очень даже к счастью!

И раз уж так, то попытки втащить все факторы и человеческие иррациональности в волшебную формулу — тщетны, и нет смысла тратить на них энергию. Кроме того, вводить множественные факторы и шкалы — верный путь заблудиться в трех соснах, дополнительно усложнить и без того не самую простую ситуацию.

Вместо этого, как мне кажется, куда продуктивнее выразить вопрос «что важнее всего» не в задачах, а в более абстрактных ценностях, которые позволят легко приоритизировать задачи. Уменьшить количество факторов. Например, решаем, что следующий спринт посвящен перфомансу, следоватиельно, в топ выходят задачи с максимальным потенциалом оптимизации. Это естественно, означает, что туда не смогут войти задачи, посвященные, скажем, юзер экпириэнсу — для них надо будет объявить «спринт юзабилити». Поломка прода, естественно, автоматически включит «спринт восстановления прода». Так можно будет менять фокус и делать прорывы в нужном направлении. Как продакт менеджеру мне такое понравится куда больше чем некая «сбалансированная» приоритизация каждый раз — у нее же нет «руля», я не могу на нее повлиять. А так можно управлять разработкой.

Леша, ты сейчас описал еще один подход к приоритизации: Дискретные отрезки времени под одну область (ux, стабилизация и т.д.). Вполне хорошая техника и ТОЖЕ подходит. Она не лучше и не хуже других и есть ведро недостатков и очень много достоинств.
Она хороша, когда круг людей, принимающих решения, достаточно небольшой и находится очень рядом.

Так твое «зачем» — упростить себе задачу приоритизации. Ты принимаешь решения на более высоком уровне (какой тип спринта будет), а потом забиваешь этот спринт себе нужными задачами по приоритету уже внутри группы.
Так все методики приоритизации направлены на упрощение. Тебе нравится вот эта. И это хорошо :)

Нет же, мое «зачем» — для того, чтобы получить определенный рычаг управления разработкой, иметь возможность сконцентрировать разработку в определенном направлении (и при этом все еще иметь согласие всех стейкхолдеров).

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

Ты совершенно прав, говоря, что критерием будет являться «принятие такой приоритизации всеми заинтересованными лицами». И при этом совершенно же прав, говоря «мы осознаем, что этот список идей становится слишком длинным... ...приходится решать, что будем делать в первую очередь». То есть, фактически, нам нужен такой процесс, при котором все стейкхолдеры могут получить убедительный ответ на вопрос «почему моя любимая история не на первом месте?» и даже «почему ни одной моей истории вообще нет?». Убедительный настолько, что они поддержат такую приоритизацию.

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

У нас у всех разные вкусы. Мама любит белый хлеб. Дети сладкую сдобу. Дедушка черный бородинский. Но когда мы собираемся за столом, мы все едины в одном: пожалуй, старый хрыч обойдется без бородинского.

Отличный пример: хорошо показывает работу с разными запросами и хорошо показывает шкалу по которой идет выбор (жаль, что она не в пользу бородинского :) )

Можно поставить приоритеты на задачи по простейшей SWOT-матрице: срочно/несрочно + важно/неважно, затем в каждой из категорий уже ранжировать по убывания приоритета и делать именно в таком порядке, как бы мозг не пытался увильнуть в прокрастинацию.

Всех дел и задач все равно не сделать, но сделав наиболее важные, человек достигнет успеха гораздо быстрее, чем в случае, если будет прозябать в лапах прокрастинации, отвлекаясь на мелочевку.

Олег, как раз в статье, на которую есть ссылка, очень подробно рассказаны 20 или даже больше техник приоритизации. Матрица Эйзенхауэра (которую вы назвали SWOT, вероятно ошибочно) с измерениями «важность-срочность» — эта одна из техник.
К сожалению, техника приоритизации по матрице 2×2 тоже далеко не идеальна и хороша для группировки, но не для составления списка дел :)

Расставить приоритеты задача простая
А вот когда их меняют раз в месяц...

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

А вот когда их меняют раз в месяц...

Если радикально меняют — конечно, опаньки. Но частичный пересмотр на основании новых данных — это то, что можно и нужно делать. И не раз в месяц, а чаще; для типичной продуктовой компании я бы предположил недельный пересмотр.

Да я уже выше написал, что если это идет от поиска ниши и постоянных контролируемых экспериментов, то это ок. А если просто от «потолочного озарения» или сиюминутной прихоти/идеи менеджмента, то нужно БЕЖАТЬ! :)

И все-таки «приоритИзация» или «приоритЕзация» ? Проверочное слово — приоритЕт, не ?

Меня самого мучал этот вопрос. Словари говорят, что оригинальное происхождение от priority делает овер-рул на правило проверочного слова: ru.wiktionary.org/wiki/приоритизация

Нет никакого оверрула, всё и так верно без него. Шаблон генерации слов с заменой -тет -> -тезация отсутствует, как и сами такие слова. Поэтому — чистое заимствование.

Вот, мое обьяснение уточнили. Спасибо!

А шаблон замены гласной для благозвучия — есть
orfogrammka.ru/OGL02/81920096.html

И ничего по этой ссылке не подходит к обсуждаемому случаю.

Режет глаз, но все же через И.

Проверочное слово — приоритЕт, не ?

Не. Потому что не приоритетизация.

Так вот приоритИзация. В угоду благозвучию русский язык меняет гласную в корне. Всё потому, что русский язык — звуковой, написание подстраивается под звучание. В идеале, если бы слово изначально фиксировалось в народном языке, а не бюрократическом — было бы прЕоритИзация и прЕоритет. Но уже устаканилось так.

В украинском это бы звучало как пріоритизація.

Если бы наследовалось сейчас, был бы приоритайзинг

Підписатись на коментарі