Приоритеты при распределении задач на проекте

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

Чехов. Остров Сахалин.

Знакомая ситуация?

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

Мы помним о квадрате Эйзенхауэра для эффективной организации личного времени (см. например, http://uspeh-success.ru/matritsa-eyzenhauera/) для быстрого принятия решений о приоритете поступающих заданий.

А вот для классификации задач в проекте можно использовать квадрат Кантора (http://gaperton.livejournal.com/28186.html).

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

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

Kantor

Вуаля! Я думаю, интуитивно почти все понимают такой подход.

Поэтому практически ни в одном своем проекте я не тратил много времени на подготовку подробных руководств по эксплуатации. Ну кто же их читает?

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

Конечно, чтобы успешно применять такой подход, необходимо:

  1. Научиться разбивать весь проект на отдельные задачи
  2. Научиться оценивать приоритет
  3. Научиться оценивать риски

При разработке IT-проектов Gaperton рекомендует иметь дело не с задачами-активностями, а с фичами, По Gaperton «фича — это функциональность, видимая пользователю, которая может быть протестирована» и предлагает усложненный вариант, предусматривающий оценку отношения value/cost — и сортировку по этому отношению, но это уже некоторое усложнение.
В проектах, вовлекающих изготовление и приобретение железа, согласование документов, разработку ПО, подготовку отчетов и документации чаще всего разбиение на отдельные задачи возможно, но далеко не всегда порядок разработки произволен. Например, нельзя запустить изготовление испытательного образца до того как согласованы требования к нему. Тут еще на этапе заключения нужно аккуратно разбивать работу на этапы, желательно основываясь на опыте выполнения аналогичных проектов.

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

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

Вперед, докопаем наш тоннель до конца!

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: