Pull to refresh

Comments 6

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

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

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

Очень часто при планировании действительно сложно выудить у заказчика, что важнее, что нет, звучит постоянно «Надо это. И это надо. И это. Вы можете сделать только одно? Надо всё и сразу!». А со временем оказывается, что некоторые задания могут год никем не делаться, а заказчик успешно забыл, так как появилось множество других, таких же важных заданий. Это, конечно, плохо, но говорит о том, что заказчики не могут адекватно оценить, что на самом деле надо, а что — нет. И тогда на помощь приходит [i]business case[/i]. Вычисление занимает какое-то время, но с данной оценкой куда проще расставлять приоритеты и показывать заказчику, что он сам оценивает некоторые «важные» вещи в копейку.
хорошая метафора получилась, понятная и наглядная.
Sign up to leave a comment.

Articles