Мій (нетехнічний) колега пригрозив мені діаграмою Ганта для нового проекту, який ми зараз плануємо. Що це може нам забезпечити і чи стане це корисним інструментом?
Мій (нетехнічний) колега пригрозив мені діаграмою Ганта для нового проекту, який ми зараз плануємо. Що це може нам забезпечити і чи стане це корисним інструментом?
Відповіді:
Як говорить Вікіпедія, діаграма Ганта - це тип гістограми (частіше "типу рядка"), яка допомагає при плануванні проектів. Його часто малюють вручну на стіні на великому (дійсно великому) аркуші паперу, оскільки він легко змінюється в такому форматі.
Це дуже простий тип інструменту планування; ви можете виготовити його в Excel або іншому еквіваленті; і досить ефективний, якщо час, необхідний для певних етапів проекту, можна приблизно оцінити. Якщо є затримка - немає проблем - один рядок подовжується, інші залишаються незмінними, і у вас є нова дата закінчення проекту.
На ньому легко помітити фази, що перекриваються (часові), так само легко, як і залежність початку однієї фази, спираючись на кінець іншої.
'це все є для цього насправді.
Звичайно, проблема з Гантом (або "графіком часу", як його зазвичай називають у моїй частині світу) полягає в тому, що на початку проекту у вас все це гарно складено на стіні, відчуваючи ентузіазм і щасливо, ... тоді відбувається одна затримка, і ти змінюєш її на графіку, і ти все ще залишаєшся щасливим ... потім виникає інша затримка, ти знову її оформляєш, і ти все ще відчуваєш себе досить добре .. 100-кратні затримки ... Ви відчуваєте себе _______ (під цензурою).
Це означає, що це лише хороший інструмент планування проектів, якщо ви насправді дотримуєтесь цих маленьких термінів. Тож перестаньте витрачати час тут і приступайте до роботи!
Добре виготовлений та підтримуваний графік Ганта може бути чудовим інструментом. Головні переваги - показ, які завдання залежать від інших завдань, прогнозування того, як на проект можуть вплинути затримки, і виділення витрачених годин, оскільки ви чекали чогось іншого.
У минулому я успішно використовував графіки Ганта для управління проектами програмного забезпечення. Я також бачив, як люди розчаровуються від них.
Будь-який інструмент управління проектами корисний, лише якщо він відповідає на питання, які хтось насправді задає. У моєму випадку мені постійно задавали два запитання, і моя діаграма Ганта могла відповісти на нього:
Отже, які фактори необхідні, щоб діаграма Ганта була корисною?
Це повинно бути очевидним. Якщо є лише один член команди, то все, що вам потрібно, - це список завдань в одному стовпчику. Ви будете робити їх лише один за одним.
Це здається черговим очевидним твердженням, але ви здивуєтеся, скільки програмних проектів недостатньо чітко визначені, щоб їх можна було розділити на завдання. Насправді вам знадобляться попередні специфікації та деякий ступінь передового дизайну. У деяких методах гнучкості / екстремальності ви не могли використовувати діаграму Ганта, тому що ви не знаєте, які завдання будуть перед наступною 3-тижневою ітерацією.
Хтось МОЖЕ вкласти час, щоб підтримувати річ. Занадто часто хтось проводить дні, складаючи детальну схему Ганта, а потім нехтує нею. Можливо, він вийде це через місяць, нервово посміяться і відкине, ніколи більше про це не говорити.
Отримавши завдання та найкращі оцінки, ви ставите їх на графік. І коли перше завдання буде виконано, ви повинні позначити це на графіку, а потім перемістити всі інші завдання навколо, щоб компенсувати той факт, що ваша оцінка була неправильною. А через два дні ти знову робиш це. А потім знову, ще через два дні. І звичайно, коли виявляється, що ти щось забув або з’являється дефект, ти повинен поставити нові завдання на графік.
Це може здатися значним постійним зобов'язанням у часі, і ви маєте рацію. Звідки береться мотивація до цього?
Часи, коли я успішно використовував графік Ганта, - там, де проводилися щотижневі зустрічі з управління проектами. Менеджер обійшов кімнату, попросивши кожного керівника команди заявити, коли буде здійснено їх проект. Якщо проект відставав, тоді ресурси будуть перерозподілені. На перших двох зустрічах я б затуманився, що я не знав насправді, коли це буде зроблено, і придумав би розпливчасте "через три місяці". Збентеження цього змусило мене змінити свою стратегію і переконатися, що я маю діаграму Ганта, яка була актуальною та точною перед кожною зустріччю.
Як побічний ефект, це зробило мій проект краще організованим та ефективнішим, а членів моєї команди більш мотивованими.
Жоден винахід не заслуговує на більше заслуги за те, щоб зробити проектне планування таким же непопулярним, як сьогодні, ніж "Відстеження Гантів". Відстеження Гантів не тільки слід вважати шкідливим - їх слід вважати злим. Ось чому.
Причина №1: Їх мотивація
Відстеження Гантів дозволяє вам бачити, на кожному кроці вашого плану, як довго ви думали, що це триватиме, і скільки часу насправді потрібно. Ви дізнаєтесь, щодня та на зборах зі статусом, що етап X повинен був розпочатися до березня, але це, очевидно, не розпочнеться до травня. Дивовижно. Ви вже знали, коли ви робили початкове планування, що план повинен буде змінюватися в міру просування проекту. Нова інформація з’являється на світ. Люди та ресурси непередбачувані і т. Д. Тож чому важливо постійно нагадувати на кожній зустрічі зі статусом, наскільки погано ваші ранні прогнози справді реальні?
Причина №2: Вони змушують вас дотримуватися початкового плану
Сама ідея відстеження діаграми Ганта проекту означає, що замість того, щоб концентруватися на постійній адаптації вашого робочого плану на основі нової інформації, ви вирішили дотримуватися застарілого плану, лише тому, що він дозволяє вказувати пальцями та виділяти неправильні прогнози, які були неминучий результат величезної кількості невизначеності, яка спричинила за собою ранній етап планування проекту. Зрештою, ви не можете відстежити Ганта, якщо дозволите плану кардинально змінитися, правда? Він повинен мати однакову загальну форму і складатися з одних і тих же сходинок, інакше нічого не можна відстежити ... Пристрасть до планів є головною причиною, чому "Водоспад" в наші дні насправді вважається виразним терміном. Планування заздалегідь плутається з дотриманням початкового плану.
Причина №3: Вони нічого не вчать
Це не так, як затримка цього проекту насправді змінить спосіб планування наступного проекту, якщо тільки проекти, які ви плануєте, передбачувано подібні та повторювані. Зрештою, саме для цього Гантс спочатку використовувався для планування роботи на виробничих лініях, де завдання дуже чітко визначені і їх тривалість надзвичайно передбачувана.
Значення, яке відстеження додає до діаграми Ганта з розробки програмного забезпечення, дорівнює нулю. Можливо, навіть менше нуля. Мало того, що минулі оцінки не мають значення для нових проектів, ілюзія, що ви можете фактично покращити свою здатність до оцінювання з часом за допомогою ретроспекції. Впевнений, студент CS може насправді не знати, що інтеграція потребує багато часу в реальному житті. Але кожен, хто за життя брав участь у більш ніж двох проектах, уже добре знає звичних підозрюваних у запізнілих проектах. Справжня причина затримки проектів - це не якийсь математичний коефіцієнт помилки, який слід застосовувати до оцінок в цілому - це властива невизначеність, яка виникає з того, щоб робити щось вперше, і не знаючи, як саме це буде виправлено.
Насправді існують системи управління проектами, які намагаються атакувати проблему з цього неправильного кута. Вони вимірюють ваші прогнози та фактичну ефективність і намагаються виправити загальну оцінку за допомогою статистичного аналізу. Наче «Денні завжди недооцінює все на 14,3%» - це колись так. Денні не дурний, і вважати, що помилка його прогнозування передбачувана, справді ідіотська. Це плутає примітивне "лікування" - додавання факторів до вашої оцінки - з причиною проблеми. Ваша оцінка не є неточною, оскільки її не множили на "правильний" коефіцієнт. Ваш план просто неповний; і кожен план по-своєму неповний.
Причина №4: Вони зосереджують вашу увагу на неправильних речах
Замість того, щоб зосереджуватися на тому, що потрібно зробити, щоб виконати своєчасно, ви тепер зосереджені на виправданні своїх неточних прогнозів. Замість того, щоб зосереджуватися на плануванні більш детально та адаптувати свій план до нової інформації, ви переосмислюєте застарілий план. Проекти рідко затягуються, оскільки деталі плану роботи були неправильно оцінені. Вони затримуються, тому що безладні речі просто залишилися поза початковим планом. Відстеження Гантса робить це ще гірше, адже яка мотивація ви повинні вставити більше деталей у свій план, якщо все просто буде завершено, що підкреслюється як погані оцінки на кожній нараді зі статусом? Вони змушують вас дотримуватися великих, відстежуваних фрагментів роботи у вашому графіку Ганта. Замість того, щоб дозволяти вам зосередитись на адаптації та стати на правильний шлях,
Існує також проблема недостатнього вдосконалення інструментів для управління досить складними планами. У вас є набагато більший шанс побудувати хороший початковий план (і оцінку), якщо ваші інструменти дозволять вам викрити всі ці часто занедбані кроки на цьому шляху. Традиційні Ганти - звірі з низькою роздільною здатністю, які розробники по праву розглядають як карикатури на реальність управління проектами. Необхідний інструмент, який дозволяє легко додати якомога більше інформації до робочого плану на самому ранньому етапі, а потім зробити так само легко адаптувати свій план, оскільки туман невизначеності повільно згасає над вашим проектом. Останнє, що вам потрібно - це постійні нагадування низької роздільної здатності про ваші неточні минулі прогнози. Відстеження Гантів добре для вказівки пальцями і прикриття ослів, а не для того, щоб робити речі.
Програмне забезпечення діаграми Ганта дозволяє аналізувати складні взаємозалежності та прогнозувати наслідки перевитрат та затримок.
Однак для більшості програмних проектів мало залежностей і зовнішніх входів, тому ключовим для прогнозування є знання того, який правильний множник використовувати, коли команда програмного забезпечення каже, що це займе 3 тижні.
Як зазначають інші, діаграма гантів (зазвичай неофіційно їх називають планом проекту) - це спосіб відображення завдань та взаємозалежності між цими завданнями, метою яких є встановлення мінімального загального пройденого часу для проекту.
З точки зору управління ключовим результатом є ідентифікація критичного шляху, тобто переліку завдань, які, якщо вони затримуються, то проект затримується.
Дуже простий приклад - скажімо, що два програмісти працюють над проектом із трьома завданнями (кодовий модуль A бере один програміст 10 днів, кодовий модуль B приймає один програміст 5 днів, потім інтегрують a і b, приймаючи обох програмістів 2 дні). Перші два завдання (модулі кодування A і B) працюватимуть паралельно, мета - виконати всі три завдання і, таким чином, спроектувати його за 12 днів.
У цьому випадку критичним шляхом є модуль кодування A, а потім тестування інтеграції. Кодування модуля B може насправді починатись із запізненням на 5 днів (або запускатись на п’ять днів), не впливаючи, оскільки навіть якщо воно закінчилось вчасно, модуль кодування A займе це набагато довше. З іншого боку, якщо модуль кодування A або інтеграційне тестування пропустить будь-який час, весь проект пробухне.
Знаючи подібні речі допомагають зрозуміти, як розгорнути ресурси та чи може затримка певного завдання вплинути на весь проект.
Чи корисні вони? Очевидно, що так, але з одним істотним застереженням: лише до тих пір, поки інформація, яка потрапляє в них, є доброю - тобто:
І звідти команда повинна працювати над графіком і виконувати завдання в потрібному порядку (не роблячи щось цікавіше, ніж поставлене завдання як таке потенційно може затримати щось / когось іншого за лінією).
Якщо ви все це зробите, то так, тоді це дійсно може допомогти вам, але роботу потрібно поставити перед собою, щоб гарантувати її точність та реальність.
Я люблю діаграми Ганта, і якби Mac мав кращий вибір програмного забезпечення для їх створення, я б користувався ними весь час.
Побачити залежність величезна. "Якщо у нас не буде виконано заповнення даних частиною проекту, то побудова на розширеннях Whatsit не може розпочатися."
Якщо ваш проект є проектом розробки програмного забезпечення, то діаграма гантів не буде дуже корисною і в основному буде марною тратою часу. Вони не розроблені для текучого характеру розробки програмного забезпечення, тобто.
Підсумок полягає в тому, що ви витратите більше часу на оновлення плану, ніж виконуючи роботу.
Просто керуйте своїми вимогами, і все інше подбає про себе.
YMMV