Життя цеглин. Чому розстановка пріоритетів - ключовий елемент планування

Це спроба на картинках поміркувати, чому проекти так складно випускати вчасно, і як завдання пріоритетів може поліпшити ситуацію.

Отже, ми приймаємося за розробку проекту. Вже визначені цілі і загальні обриси проекту, але поки абсолютно нічого не відомо про його реалізацію. Які завдання доведеться вирішувати? Які будуть потрібні ресурси? Незрозуміло.

На цьому етапі проект для нас - відчутна, але все ще досить безформна хмара.

Що нам необхідно - це деталі. Починаючи від цілей проекту, ми крок за кроком поділяємо його на відносно невеликі, і головне - дуже конкретні завдання, вирішення яких і означатиме успішне завершення всього проекту.

В результаті з спочатку обтічних форм задуму проступають кутові контури його технічної реалізацій - у вигляді сукупності задач- «цеглинок», разом складових весь проект. «Вагомо, грубо, зримо».

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

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

Перелічені вище дії вже повинні дати нам відповідь на ряд важливих питань:

• Які ресурси необхідні для завершення проекту?
• Які завдання потрібно вирішити?
• Які ресурси потрібні для виконання кожного з завдань?

Схоже, це не просто відповіді на питання - це план. Приступаємо до його реалізації.

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

На жаль, зі світовою гармонією трапляються труднощі. Рано чи пізно якесь із завдань (а зазвичай - не одне) раптово виявляються складнішими, дорожчими, довше - або все відразу. Вона вже не вміщається в заздалегідь відведене їй місце - її, як би це сказати, розпирає.

Тут настає один з найбільш неприємних моментів розробки - цеглини посипалися з полиці. Завдання, що витратили більше ресурсів, ніж було для них заплановано, не тільки самі по собі стали «дорожче» - вони забрали місце у тих завдань, які ще тільки належить реалізувати - тих завдань, що акуратно промальовані на схемі пунктиром.

Можливо, удача ще посміхнеться, і ми все ж таки зуміємо вмістити всі завдання назад на полку - але для цього доведеться залишилися зробити з меншими витратами, ніж планувалося. Наскільки ймовірний такий результат?..

Не будемо обманювати себе і приймемо як даність - в будь-якому проекті рано чи пізно цеглини падають з полиці. Чому не випустити проект вчасно, але без частини запланованих функцій? Просто тому, що дуже часто в самому кінці проекту раптом виявляються дуже важливі речі.

Як бути? Вирішення проблеми - в початковій розстановці пріоритетів.

В силу ймовірнісної сутності будь-якого проекту не можна бути абсолютно впевненим в тому, що все піде строго за планом. Коли і в який бік з нами зіграє випадковість - невідомо, але можна з упевненістю говорити, що чим ближче завдання заплановане до кінця проекту - тим вище у неї шанс опинитися «за бортом» реалізації. На неї може просто не вистачити часу, або будь-яких інших ресурсів - і, на жаль, не завжди є можливість збільшити бюджет проекту.

Мабуть, сама по собі можливість втратити одне або навіть кілька завдань (шляхом «не влізання в бюджет») не є величезною проблемою; справжньою ж проблемою це стане лише в тому випадку, якщо «під скорочення» потрапляють якісь дуже істотні елементи проекту.

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

Істотний момент: складно і непродуктивно відштовхуватися при завданні пріоритетів від «неважливих» завдань, вважаючи всі інші «важливими». По-перше, важко що-небудь в проекті з самого початку відзначити як несуттєве і «не дуже потрібне» - тим більше займатися подальшим його плануванням і реалізацією. По-друге, вишукуючи в проекті «другорядне», дуже легко упустити критичні і першорядні завдання.

Набагато ефективніше поставити питання - «без чого проект не може бути випущений?». З цим питанням вже не так просто забути про такі важливі, але легко втрачені при плануванні «цеглини» проекту, як тестування, супровідна документація, «setup.exe» і тому подібні завдання. Які, звичайно, варто постаратися реалізувати якомога раніше, щоб знизити ризики падіння цеглин з полиці.

Підіб'ємо підсумки:

• початкові оцінки ресурсів, необхідних для реалізації проекту, а так само їх фактичне споживання в процесі розробки - величина ймовірнісна, що має в собі елемент випадковості;
• в силу ймовірнісної сутності проектів існують ризики дефіциту бюджету, які часто призводять до відмови від реалізації будь-яких частин проекту;
• завдання, заплановані на ранні етапи розробки, мають кращі шанси отримати необхідні ресурси;
• завдання пріоритетів на етапі планування дозволяє критичні завдання проекту запланувати на ранні етапи розробки, залишаючи другорядні на завершальні етапи - тим самим підвищуючи шанси успішної реалізації найбільш важливих елементів проекту.