Про користь і шкоду детального планування

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

Отже, що ж добре в плануванні (або погано без нього):

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

Артефакти, на яких базується кожен план: завдання, ресурси для виконання, виконавці, тривалість конкретного завдання, послідовність завдань.

Я навмисне опускаю фази проекту, періоди між фазами і т.п., тому що впевнений, що все ж більшість проектів є плоскими, а не кубічними сутностями з величезною кількістю зовнішніх взаємозв'язків.

Подивимося пильніше на артефакти:

Завдання . Тут мається на увазі детальний опис завдання в такому стилі: «Установка кріплення типу цвях у стіну, на висоті 2 метри від підлоги в 20 см з лівого боку внутрішньої частини вхідних дверей». Готовий стверджувати що 90% завдань страждають проблемою ястності в описі, особливо коли мова йде про більш складні абстракціях, ніж «цвях» і «стіна».

Ресурси для виконання . Це як правило матеріали, і як наслідок - їх постачальники з їх термінами, цінами, якістю і т.п.

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

Тривалість завдання - дуже сильно залежить від усіх трьох попередніх артефактів і як наслідок не може бути зафіксована з високою точністю. У деяких галузях прийнята одиниця виміру день, у більш точних - секунда. У розробці софта я найчастіше стикався з мінімальною одиницею виміру - 1:00.

Послідовність завдань - ще складніший артефакт, що залежить як від пріоритетів, наявності ресурсів у певний момент часу, стадії завершеності попередніх завдань і т.п.

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

Проблеми, пов'язані з черезмерно детальним плануванням:

Ошукані надії . Проект дуже часто виявляється значно дорожче, ніж за планом, значно повільніше і з меншим об'ємом робіт, ніж очікувалося.

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

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

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

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

Отже, якщо плани такі погані, то як же жити далі?

Відповідь проста і знаходиться в мудрості віків. Наприклад: «Богу - богове, кесарю - кесареве».

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

Ви скажете - здорово, але як же боротися з тим, що проект ставати нескінченним? Відповідь така: потрібно після закінчення кожного завдання і перед початком роботи над наступною переглядати пріоритети і задаватися питанням - а чи не досить?

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

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

Заклик цієї статті - не відмова від планів як таких, а перенаправлення енергії, яка витрачається на створення черезмерно детальних планів, на створення чогось матеріального - наприклад, продукту.

Коли люди будували перші хатини, вони не починали з плану, то ж з автомобілями, літаками і т.п. Або вони відмовилися б, порахувавши, скільки все це коштує? :-)

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

Опубліковано: 18/04/12 @ 10:13
Розділ Різне

SEO Блог