Пріоритети при розподілі завдань на проекті, ndtpm

Керівництво проектами та неруйнівний контроль

завдань

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

У проекті 100 500 фіч, і чомусь до кінця доробити все не виходить. І як прикро, коли зроблено всі бантики, упаковка та перехідники, а сам віз не щастить. Треба, треба вчитися розставляти пріоритети.

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

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

Як зазвичай у матриці 2х2 ми маємо чотири типи завдань, класифікованих за шкалами «пріоритет» та «ризик». Отже, орієнтирів у нас два - пріоритет ( є завдання без яких взагалі ніяк, а є збоку бантик, який ще невідомо - потрібен чи ні) і ризик (там де можна сильно помилитися з оцінкою).

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

пріоритети

Вуаль! Я думаю, що інтуїтивно майже всі розуміють такий підхід.

Тому практично в жодному своєму проекті я не витрачав багато часу на підготовку докладних посібників з експлуатації. Ну, хто ж їх читає?

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

Звичайно, щоб успішно застосовувати такий підхід необхідно:

  1. Навчитися розбивати весь проект на окремі завдання
  2. Навчитися оцінювати пріоритет
  3. Навчитися оцінювати ризики

При розробці IT-проектів Gaperton рекомендує мати справу не із завданнями-активностями, а зфічами, Gaperton «фіча - це функціональність, видима користувачеві, яка може бути протестована» і пропонує ускладнений варіант, що передбачає оцінку відношення value/cost - і сортування по цьому відношенню, але це вже деяке ускладнення. У проектах, що залучають виготовлення та придбання заліза, погодження документів, розробку ПЗ, підготовку звітів та документації найчастіше розбиття на окремі завдання можливе, але далеко не завжди порядок розробки довільний. Наприклад, не можна запустити виготовлення випробувального зразка перед тим, як узгоджені вимоги до нього. Тут ще на етапі укладання потрібно акуратно розбивати роботу на етапи, бажано ґрунтуючись на досвіді виконання аналогічних проектів.

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

Про методи оцінки проектів можна побачити, наприклад, оглядову доповідь Сергія Архипенкова тут, про оцінку шляхом трьох точок на Стратоплані.