Четыре продакт оунера бэклог приоритизировали-приоритизировали...
... да так и не выприоритизировали. А все потому, что приоритизация — задача вовсе не такая уж простая, как многим на первый взгляд кажется. Зачем она вообще нужна, кто ее делает, и как можно существенно облегчить себе жизнь — об этом и многом другом в журнале «А хрен его знает!» этом посте. Проходите внутрь, пожалуйста, устраивайтесь поудобнее. Даже кто к agile не особо тяготеет — все равно интересный вопрос.
Приорите́т (лат. prior — первый, старший) — понятие, показывающее важность, первенство. Например, приоритет действий определяет порядок их выполнения.
Что ж, вроде бы все понятно. В деле приоритизации задач, которые предстоит выполнить, суть в том, чтобы понять, что делать в первую очередь.
Тут, конечно, надо вспомнить, что в проектном, «классическом» подходе это все не так уж и важно. Собрали требования, написали спецификацию, хоть по порядку разрабатывайте, хоть по алфавиту, хоть по зодиаку — как все сделаете, так и будем тестировать и внедрять. Ну постройте там себе диаграмму Гантта, поставьте end-to-begin связи — вот и отлично все будет.
А ну как требования поменяются? Или, не дай бог, вообще цель проекта?
Тут классический проджект-менеджмент разводит руками — другая цель, другие требования, все поменялось, сейчас вот заново все соберем, запланируем, будет новый срок, новые вехи, к нам какие претензии, когда так все меняется?
— Он не хотел брать на себя. Он как чувствовал. А они ему все время: «Бери на себя... бери на себя». Он взял на себя. Теперь он здесь, а они в стороне.
М. М. Жванецкий
Agile как раз потому и крут, что он под именно такие ситуации и заточен, проект, разрабатываемый по заветам agile будет готов к изменениям: он их не только не боится, он их приветствует! И в этом мире у приоритизации совсем другая миссия и значение.
Вместо спецификации с диаграммой Гантта у нас теперь беклог.
Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано.
Почему так? Потому что agile «заточен» под изменения, значит изменение ожидается. Значит, когда оно придет — мы будем готовы. Что нам хочется при изменениях? Хочется, чтобы мы не потеряли много времени и работы, а как можно скорее начали полноценное движение к новой цели.
Для этого мы делаем две вещи. Во-первых, не держим слишком много задач «открытыми». До тех пор, пока задача не закончена — мы не получим от нее никакой бизнес-ценности, зато при изменении курса все «начатые и еще не законченые» задачи как бы исчезают, все усилия, которые мы на них потратили — ушли впустую. Чем больше задач «in progress» и чем больше их среднее время нахождения в этом состоянии — тем сильнее потери от изменений. От этого возникает важный принцип — концентрироваться на как можно меньшем количестве самых важных задач, стараясь закончить их как можно быстрее.
Вторая вещь — это сортировка всех задач в соответствии с приоритетом. То есть, что нам важнее всего сделать в первую очередь, что после этого, и так далее. Сортировать это дело, как предполагается, должен product owner в соответствии с бизнес-ценностью задач (а также учитывая их стоимость/сложность), таким образом это решение задачи многокритериальной оптимизации, и это не то, с чем человеческий мозг справляется блестяще. Так что там тоже все очень и очень нелегко.
В свете этого, у беклога есть две важные фишки. Первая — по нему всегда можно сказать, что сейчас самое важное. Это самая верхняя задача в беклоге. Вторая особенность, когда самая важная задача будет сделана — у нас все равно будет самая важная задача, и она опять будет самая верхняя в беклоге (прямо как в очереди FIFO, если вы понимаете, о чем я).
Есть два конкурирующих подхода к приоритизации. При одинаковой цели — отразить важность задач для концентрации на важнейшей из них, реализация бывает воплощена в двух разных механизмах. В одном случае приоритет моделируется как некоторое свойство задачи и имеет какое-то значение. Во втором случае, приоритет представляет собой отношение между двумя задачами, подобное рычажным весам: можно сказать, который из двух тяжелее, но нельзя определить собственно вес.
Итак, в одном случае (приоритет-значение) мы говорим, что приоритет — это такое свойство у задачи и мы пытаемся его определить. Выразим его в значениях какой-то шкалы и получим возможность упорядочить все задачи по приоритету. Это может быть, например, число от одного до десяти. Или количество «звездочек важности» в трекере. Или значения шкалы типа «неважно, так себе, умеренно важно, важно, очень важно, вообще очень супермегаважно», что, как вы понимаете, ничем от чисел не отличается по сути.
Во втором случае (приоритет-отношение) про одну конкретную задачу мы ничего сказать не можем. Ну, задача и задача. Насколько она важна? Ну, черт ее знает, надо на остальные смотреть. Может очень важная, прям самая важная сейчас, а может и не очень. Вы мне другую задачу дайте — и я тогда точно скажу, какая важнее.
Я сейчас собираюсь показать, что второй подход — крайне правильный, а первый — полное убожество.
Проблемы первого подхода достаточно очевидны. Во-первых, возникает проблема одинаковых значений. Пусть приоритет выражается числом от 1 до 5. И у нас есть сто задач. Как много задач получат «высший» приоритет? Ну, наверное, выходит так, что не одна. Следовательно, в такой системе нет ответа на вопрос «какая ОДНА задача сейчас самая важная». То есть, вообще говоря, имея число от 1 до 5 можно сделать беклог только длиной в пять задач — дальше начнутся неоднозначности с приоритетом.
Кроме того, список, как мы знаем, имеет тендецию меняться. Не только вследствие радикальных изменений, но и с эволюцией проекта. Если мы сделали самую важную задачу — теперь у нас новая самая важная задача. Это как с карьерной лестницей — продвижение полковника в генералы вызывает цепочку повышений, какой-то подполковник станет новым полковником, майор — подполковником, капитан — майором, и так далее. Что произойдет со списком значений? Надо будет переназначить приоритеты всех задач.
Все эти проблемы не существуют для приоритета-отношения из-за строгого порядка, обеспечиваемого отношением. Из инструментов у нас — только сравнение пары задач (кстати, это значительно проще, чем оценить приоритет-значение для конкретной одной задачи), следовательно, построение беклога — ни что иное, как сортировка пузырьком. Это единственное, что можно сделать с таким отношением — упорядочить список. Самая верхняя = самая важная. Первая сделана — у нас все равно есть самая важная, уже другая, автоматически. Хочется вставить новую задачу — надо сравнивать ее с другими и найти такие две, между которыми она окажется.
Раз это так легко и правильно, почему так все не делают?
Я вижу тому несколько причин. Во-первых — нужда в концентрации. Если нет необходимости концентрироваться на самой важной задаче — нет такого ажиотажа вокруг приоритетов, это ни на что особо не влияет. Во-вторых, как бы это ни было смешно, большинство инструментов поддержки процесса (трекеров) этого не позволяют, даже многие «заточенные под agile». На самом деле, каждый программист подтвердит — с точки зрения разработки приоритет-значение реализовать куда легче, чем приоритет-отношение.
Кроме того, их же легко перепутать. Например, когда вы слышите «это нужно сделать срочно, эта задача имеет топ-приоритет!» — это же можно воспринять по-разному. Возможно, человек отдает себе отчет и имеет в виду, что это означает — новая задача самая важная, она выигрывает в сравнении со всеми остальными задачами«. А может быть он сразу после этого говорит «и вот эта тоже — топ!». Эмм... тоже?
Сморите, какой фокус. «Вот десять задач, их нужно сделать». Ок, хорошо, понятно, в каком порядке? Какая самая важная? «О, они все очень важные!». Ну да. Это то же самое, что сказать «они все абсолютно неважные» — никакой разницы не будет. «Важная» в данном случае используется как средство мотивации коллектива, а вовсе не как приоритизация беклога.
Я лично очень люблю фразу «это важно», потому что она... ничего не значит. Я отвечаю так, когда нечего ответить, а нужно как-то продолжить разговор. Внушительно звучит и не имеет никакого смысла, очень удобно в некоторых ситуациях, рекомендую. Потому что важность — отношение, а не значение. «Это важно» — не имеет смысла. «Это важнее, чем...» — имеет смысл.
Итак, выводы. Приоритет — это не число, это не значение, это не абсолютная характеристика задачи. Приоритет — это отношение между двумя задачами, когда для любой пары задач, можно сказать какая из них имеет приоритет, то есть обладает более высокой важностью по сравнению с другой.
Использование приоритетов-значений не повергает вас в пучину страданий немедленно, но со временем это непременно будет ставить вас в неудобные ситуации. И не факт, что вы будете понимать, почему так получается.
И да, если вы не понимаете, почему важно концентрировать усилия на малом количестве самых важных задач, и не делаете этого — вам, в целом, все равно, как приоритизировать, не парьтесь.
В общем — хорошей вам приоритизации, это важно! :)
P.S. Вот вам легендарное смешное видео, от которого делается грустно в контексте статьи.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
40 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.