?

Log in

No account? Create an account

Previous Entry | Next Entry

Заметки о приоритетах

Вызнаете такое чудо, как «метод приоритезации MoSCoW»? Больше матриц 2х2 просвещенные менеджеры любят только аббревиатуры, складывающиеся в слова, не имеющие ничего общего со сферой применения…
Суть метода заключается в том, что каждому приоритезируемому элементу ставится один из следующих приоритетов:

  • Must Have

  • Should Have

  • Could Have

  • Would Like

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

Вроде как распределить все задачи между двумя корзинками нам сложно, но стоит добавить еще несколько корзинок, типа "Надо сделать но не срочно", "надо сделать, если будет время", "надо сделать, когда не будет ничего срочного (то есть никогда)", то все тут же упрощается, хотя мы не сделали ничего особенного, а просто распилили на части первую корзинку.

Это чем-то мне напоминает то, о чем пишет Талеб в Черном Лебеде:
Психологи Канеман и Тверски, чьи имена уже знакомы вам по предыдущей главе, провели такой эксперимент: испытуемых (а это были люди, чья профессия связана с составлением прогнозов) просили оценить вероятность двух событий:

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

По мнению респондентов, первый вариант менее вероятен, чем второй: ведь землетрясение в Калифорнии — это причина, которую легко допустить и которая делает ситуацию наводнения более представимой, тем самым повышая ее вероятность в наших глазах. Точно так же, если я спрошу: "Как вам кажется, сколько ваших сограждан больны раком легких?" — вы назовете какую-нибудь цифру (ну, скажем, полмиллиона). Однако если я спрошу, сколько человек в вашей стране заболели раком легких в результате курения, цифра, которую вы назовете, окажется гораздо (пожалуй, что и в два-три раза) больше. Если указана причина явления, это явление выглядит куда более правдоподобным — и куда более вероятным.


Типа, если в приоритете указать, при каких условиях эта задача будет выполнена, то нам кажется, что шанс ее выполнить становится выше, чем если бы мы просто пообещали ее выполнить?
Или здесь идет заход в сторону неопределенности? Сказать, что "мы это сделать не обещаем, но постараемся", что бы когда мы это не сделаем, можно было бы сказать: "ну мы старались". И, кстати, много ли мы знаем примеров, когда "could/should/would" задачи все же выполнялись и не по счастливой случайности?

Про это мне еще нравится что пишет Вольфрам Мюлер в книге Tame the Flow (перевод мой):
Общепринятый подход в скраме защитить (буферизировать) дату поставки с приоритетами should/could/would оказывается довольно сложным на практике. Все, что слышат стейкхолдеры это: «Я получу истории X, Y в дату Z». Они понимают все «should, could, would» как «Возможно я это получу», но очень разочаровываются, когда не получают.

Comments

( 29 comments — Leave a comment )
bjglj
Jul. 3rd, 2014 08:04 pm (UTC)
Про наводнение с землетрясением и без спрашивали разных людей (один вопрос на человека)?
cartmendum
Jul. 3rd, 2014 08:08 pm (UTC)
Ага. Одного и того же человека просили оценить вероятность двух событий.
bjglj
Jul. 4th, 2014 12:24 am (UTC)
Тогда не понял. Неужели "люди, чья профессия связана с составлением прогнозов" не учили в школе про множества и подмножества? Это ведь даже не старшие классы.
andy1618
Jul. 4th, 2014 05:24 am (UTC)
+1
Тоже об этом подумал.
Хотя, учитывая, как народ из других стран решал задачку про 7+7*7+7/7-7, я уже ничему не удивляюсь :)
cartmendum
Jul. 4th, 2014 07:58 am (UTC)
Сам удивлялся :)

по данным психолога Пола Словича и его коллег, люди, представьте себе, охотнее платят за страхование от терактов, чем от авиакатастроф (хотя в число последних террористические акты входят как частный случай).
bandures
Jul. 4th, 2014 10:43 am (UTC)
Кстате разумно, в 2012 в самолётах погибло ~200 человек, от терроризма ~20тыс. При этом в самолётах чаще погибали не от терроризма.
cartmendum
Jul. 4th, 2014 10:57 am (UTC)
Хм... Действительно тут тонкий и неоднозначный момент... Интересно, огрехи перевода или что-то не так Талеб передал?
gleb_kudr
Jul. 3rd, 2014 08:45 pm (UTC)
Модель Кано вспомнилась чего-то. Вроде, похоже на нее по сути?


Edited at 2014-07-03 08:45 pm (UTC)
cartmendum
Jul. 3rd, 2014 08:47 pm (UTC)
Не совсем. У Кано фичи анализируются в разрезе того, на сколько они нужны пользователям, а тут в разрезе того, сколько влезет в команду разработки.
(Anonymous)
Jul. 3rd, 2014 09:59 pm (UTC)
MoSCoW is ok
Когда мы попросили пользователя оценивать по Москоу, то дело сильно продвинулось. Мне кажется из-за интуитивной понятности категорий. До этого были приоритеты 1-5 и ращница между 3 и 4, например, была мало кому понятна. И да - мы реализовали даже Would в итоге, если на момент обсуждения скоупа такие требования все еще былы интересными кастомеру.
cartmendum
Jul. 4th, 2014 07:57 am (UTC)
Re: MoSCoW is ok
Если раньше были приоритеты 1..5 а потом стали называться понятными словами, то тут ясно, что у заказчика добавилось понимания :)Тут могла быть любая другая шкала с человеческими названиями категорий, вместо цифр :)
Vasilii Artemev
Jul. 3rd, 2014 11:02 pm (UTC)
Когда нам рассказывали про этот метод W расшифровывали как Won't have. То есть клиент чего-то хочет, но мы это делать сейчас не будем.
cartmendum
Jul. 4th, 2014 07:55 am (UTC)
Где правда - не знаю :) встречал и так и так :)
Андрей Копылов
Jul. 4th, 2014 03:21 am (UTC)
Стейкхолдер - это наверное заказчик в данном контексте.
cartmendum
Jul. 4th, 2014 07:55 am (UTC)
Да, заказчик
bas4all
Jul. 4th, 2014 07:30 am (UTC)
Мне кажется, что это связано с психологией. Если человеку (заказчику) сказать, что это не будет сделано, то он никогда не согласится и тут мы попадаем в ловушку, что ВСЕ д.б. сделано.
Посмотри принятие решение по фасилитации, там как раз применяется оценка по множественной шкале, а не по шкале согласен/не согласен. И множественная шакала реально лучше работает.
cartmendum
Jul. 4th, 2014 07:54 am (UTC)
Да, то, что это из психологии - понятно. Не очень понятно, почему оно так происходит? Страх неопределенности? Жадность? Нежелание думать?
Алексей Лосев
Jul. 4th, 2014 10:06 am (UTC)
Добрый день.
Во-первых, докладываю, инфицирование меня практиками GTD у тебя удалось, сегодня даже эту бацилу вываливал на студентов технарей из калужской Бауманки.
Во-вторых, по теме поста, наш мозг плохо выбирает из двух вариантов... У нас больше тринарная логика. Даже из сказок, витязь на распутье трех дорог, три девицы под окном и т.д. Поэтому, если тяжело оценить в две категории, то воспользовавшись вот этой частью диаграммы:
165.png
Мы как раз и получим 3 варианта:
1. Сделаем
2. Не сделаем
3. Сделаем когда-нибудь
И если так заказчику будет проще, то почему бы и нет...
cartmendum
Jul. 4th, 2014 10:09 am (UTC)
ДА я понимаю тринарность логики, просто глумлюсь над неспособностью признать очевидное: "сделаем когда-нибудь" - это примерно то же самое, что и "сделаем, когда не будет срочного". То есть - никогда :)

Так не всегда, но очень часто.
Алексей Лосев
Jul. 4th, 2014 10:40 am (UTC)
Возвращаясь к Талебу, все мы умные в учебной аудитории. А вот в жизни... У меня в бэклоге, если честно, в самом низу лежит несколько требований, которым уже очень много месяцев. А вдруг пригодится?! И вот в апреле этого года, мы реализовали требование которому исполнился год. Поэтому пока их там мало, пусть лежат ;)
bjglj
Jul. 4th, 2014 02:02 pm (UTC)
То есть то, что делать самому и займет больше двух минут, не будет сделано никогда? Ну Вы, блин, даете.
Алексей Лосев
Jul. 4th, 2014 02:17 pm (UTC)
Не, не даю... Даже если требование которое сформулировал заказчик я могу реализовать за 2 минуты, то оно все равно попадет в список задач (отложить), т.к. должно будет подвергнуться, как минимум, тестированию. ;)
Sergey Galkin
Jul. 4th, 2014 01:07 pm (UTC)
У Канемана в Думай медленно... Решай быстро (http://www.ozon.ru/context/detail/id/24286114/) ситуация, когда вероятность частного воспринимается выше выроятности общего, называется сonjunction fallacy (http://en.wikipedia.org/wiki/Conjunction_fallacy).

Edited at 2014-07-04 01:14 pm (UTC)
cartmendum
Jul. 4th, 2014 01:18 pm (UTC)
Спасибо за наводку :)
calculus_logi
Jul. 5th, 2014 01:35 pm (UTC)
"Делать сейчас" "Не делать сейчас" и "Выкинуть нафиг это... нечто". В общем-то как указали выше - три варианта.

По сути второе это субоптимизация. Оно решает небольшую кучу задач, которые в принципе можно решать другим способом.
Например:
1. Нужен буфер задач для инженера, потому что так просто быстрее - меньше переключения контекста, меньше простой и так далее.
2. Тебе нужно средство долгосрочного планирования и/или установки alignment в команде (нужное подчеркнуть в зависимочти от степени мудаковатости менеджмента).
3. Тебе нужно умудриться не потонуть в текучке
cartmendum
Jul. 5th, 2014 05:55 pm (UTC)
По сути второе это субоптимизация.
Второе - это что?
calculus_logi
Jul. 5th, 2014 06:00 pm (UTC)
"Не делать сейчас". Оно же "делать потом".
cartmendum
Jul. 5th, 2014 07:44 pm (UTC)
В итоге да, 3 категории - это хорошо. Но в среднесрочной перспективе (скажем, если мы приоритезируем очередной релиз) "не делать сейчас" может оказаться избыточным :)

Можно, конечно, ввести эту категорию, типа сделаем следующих релизах, но если у нас сейчас проблема, что в один релиз все не влезает, откуда уверенность, что в следующий релиз оно влезет?
calculus_logi
Jul. 5th, 2014 07:50 pm (UTC)
"Делать сейчас" это именно сейчас. Т.е. сегодня. Все остальное это "Делать потом". Потому что если уж быть совсем честным, то любой список "делать сейчас" расписанный, скажем, на неделю вперед это условность.
( 29 comments — Leave a comment )