О приоритетах
в рубрике Project Management
“Эту задачу следует выполнить. Приоритет задачи - 3”. Как много в этих словах… Всего много… Только смысла мало.
В моей картине мира приоритет каждой задачи – уникален. Его можно выразить одним числом, но оно не должно повторяться. Уникальное значение приоритета равносильно выстраиванию задач в общую очередь: сверху самые важные задачи, внизу – то, без чего никто не сдохнет. Мысль не нова, не я первый придумал такой способ приоритезации, но замолвить об этом словечко хочется.
Итак, почему очередь лучше, чем приоритеты вида 1,2,3?
Мысль первая
Если число задач превышает возможности команды, то все эти коды приоритетов рано или поздно сводятся к двум: «нужно делать» и «не нужно делать». Естественно, не явно, но сводятся. Что означает «приоритет 3»? Это значит, что приступать к этой задаче стоит, когда выполнены все задачи с приоритетом 2. А эти задачи не могут выполняться, пока есть задачи с приоритетом 1. Вы можете вспомнить, когда у вас не было задач с приоритетом 1? Все команды, с которыми я так или иначе сталкивался, львиную долю своего времени уделяли задачам только первого приоритета. Задача с приоритетом 3 как правило мариновалась до тех пор, пока для заказчика она не будет иметь приоритет 1. В итоге все сводится к реактивной методике – FDD (Fuck-up Driven Development).
Мысль вторая
В системе приоритетов «1,2,3», стоимость повышения приоритета не очевидна для заказчика. Если заказчику кажется, что команда выполняет его задачи не так быстро, как ему хотелось бы, то появляется великое искушение выбрать какую-нибудь задачу и сказать: «Парни, теперь у нее приоритет 1». Сказать легко. Но подобные трюки не проходят бесплатно – повышение приоритета одной задачи неизбежно отражается на выполнении других, и механизм очереди способен это наглядно показать. Если задача действительно важная, то мы берем и поднимаем ее выше. Естественным образом все задачи между старым и новым местами в очереди сдвигаются вниз. Многие ненавидят этот механизм…

Мысль третья
Человек не способен эффективно выполнять больше одного дела одновременно. Наиболее эффективный режим – взять ОДНУ задачу, сделать, взять еще ОДНУ, сделать, и т.д. Таким образом, если число задач превышает допустимую область значений параметра «приоритет», то неизбежно у нас будет несколько задач с одинаковым значением этого параметра. Хорошо. Перед нами куча задач, с приоритетом 1, так все-таки, какую из них взять первой? Не понятно? Конечно! Нужно ввести еще тучу параметров, определяющий серьезность, стоимость, возврат инвестиций, бизнес необходимость, значимость для репутации… Потом обязательно придумать страшенную формулу, по которой рассчитывать очки кармы для каждой задачи. И все равно, какую из этой кучи начать делать первой? Конечно! Нужно собраться и обсудить. В итоге будет решено, что 5 задач из этой кучи все-таки самые важные и на каждую из них нужно назначить 20% ведущего разработчика… Это дорога в ад.
Делать 5 задач одновременно – самый лучший способ искренне затрахаться, без всякого полезного результата.
Комментариев: 2 на “О приоритетах”
Прокомментировать
Вы должны быть авторизованы для комментирования.




tatarin2005:
Так какое же решение, Макс. Каждой задаче уникальный приоритет?
25 декабря, 2009 в 15:02
Дорофеев Макс:
Ага. При определенных условиях уникальный приоритет очень даже работает. Уникальный приоритет эквивалентен очереди (про нее у меня было тут: http://cartmendum.livejournal.com/27842.html)
А вообще в свое время над этой статейкой много терли у меня в ЖЖ (http://cartmendum.livejournal.com/37160.html), и там была ветка комментов про случаи, когда уникальный приоритет - это “дорого”. Как правило это случается, если уже задач (или багов), подлежащих приоритезации становится очень много. Но в этом случае, как мы все понимаем, у нас уже проблемы, лечить которые нужно комплексно.
28 декабря, 2009 в 20:54