Неточні оцінки - одна з найпопулярніших проблем в управлінні проектами. Починаючи новий ІТ-проект, ви хочете знати дві речі: скільки часу він займе і скільки він коштуватиме. Щоб відповісти на ці питання, ви повинні оцінити проекти, які збираєтеся запустити. Не існує магічного правила, яке говорить, що проект X займає 12 тижнів і коштує $150,000. Або веб-сайт типу Y розробляється за 10 тижнів і коштує $100,000.
Що ви дізнаєтеся з цієї статті:
- Як керівники проектів готуються до оцінки вартості в управлінні проектами?
- Які методи оцінки корисні для оцінки проекту?
- Як планувати, щоб підготуватися до оцінки витрат за допомогою формул?
Ви не можете оцінити часові рамки або вартість проекту без ретельної оцінки, навіть якщо обсяг проекту дуже схожий на те, що ви робили раніше. Але все ще гірше: оцінка ніколи не дасть вам 100% точної відповіді на ці питання. Отже, чому ми оцінюємо? Тому що це єдиний спосіб зробити припущення щодо термінів і бюджету проекту, робочого навантаження і ресурсів, необхідних для його виконання.
Оцінюючи проект, ви також можете запланувати залучення працівників з відповідним досвідом та набором навичок. Все, що ви можете зробити - це використовувати методології та техніки, які дозволять вам оцінити проект з максимально можливою точністю. Ось як використовувати Agile-методологію та техніку Planning Poker для створення змістовного кошторису вашого проекту.
Джеймс Греннінг розробив стратегію планування покерної сесії, відому завдяки своїй стратегії, у 2002 році під назвою Scrum poker. На початку 1950-х років його метод оцінки, Wide band Delphi, був занадто трудомістким і мав інші обмеження. У випадку Греннінга покерний план спочатку був спрямований на вирішення проблеми, в якій гравці були занадто захоплені і надмірно зосереджені, щоб виграти. Майк Кон, засновник Agile-альянсів та Scrum-альянсів, пізніше використав цю техніку для статті під назвою "Agile-оцінка та планування".
Початок успішного проекту здебільшого залежить від того, наскільки добре ви розумієте, про що він насправді. Це включає в себе:
- Розуміння очікувань клієнта
- Розуміння завдань проекту та його основної мети
- Створення списку необхідних функцій
Ознайомившись з брифом клієнта і отримавши якомога більше інформації про вимоги до проекту, ви можете перерахувати всі функції і передати їх своїй команді.
Для цього створіть беклог продукту, який складається з усіх незавершених функцій. Після цього ви можете розставити пріоритети, оцінити їхню складність і прикинути, скільки часу знадобиться для їхнього завершення. З чого має складатися правильний бэклог продукту:
- Історії користувачів - описують дії, які користувачі можуть здійснювати на кожному кроці використання продукту
- Критерії прийняття - перелічіть елементи, необхідні для завершення історії
- Story points - оцініть обсяг роботи, ризики та складність у відносній бальній оцінці
- Завдання для користувацьких історій - перелічіть завдання, які необхідно виконати, щоб створити користувацьку історію
Дуже важливо залучати команду розробників до створення та визначення пріоритетів для бэклогу продуктів, щоб забезпечити точну та реалістичну оцінку.
Коли список функцій готовий, призначте пріоритет для кожної з них. Ви можете використати метод аналізу MoSCoW, щоб відсортувати їх:
- Мабуть.
- Треба було
- Могла б
- Не буде.
Розробляючи проект, зосередьтеся на тому, що ви повинні зробити в першу чергу. Створення MVP дає вам можливість перевірити гіпотези про вашу ідею до завершення всього проекту, показати його зацікавленим сторонам або бета-користувачам і зібрати відгуки, важливі для подальшої розробки решти функцій.
Визначення пріоритетів також може допомогти вам з оцінкою проекту. Зосередившись на головних функціях і тих, які потрібно зробити в першу чергу, ви зможете зробити більш точні припущення щодо їхнього передбачуваного завершення. Для функцій, які "можуть бути", ви можете почати з приблизної оцінки, оскільки вони знаходяться далі в процесі розробки, і багато чого може змінитися до того часу, як ваша команда до них дійде (і якщо ваша команда до них дійде, оскільки після збору відгуків про вашу MVP ви можете зробити поворот і не включити всі спочатку заплановані функції).
Важливо, однак, оцінити всі функції, незалежно від їхньої пріоритетності (крім тих, що "не будуть", звичайно), оскільки ви хочете отримати загальне уявлення про весь проект одразу. І коли ви перейдете до наступних етапів проекту, ви зможете переоцінити обсяг робіт, щоб переконатися, що ваші оцінки залишаються точними.
Тепер, коли ви склали свій продуктовий беклог, настав час оцінити кожну з його позицій. Для цього ми використовуємо story points. Це одиниці, які Agile-команди використовують для оцінки роботи, необхідної для завершення кожної позиції з бэклогу. Точки історії допомагають призначити відносну цінність елементам бэклогу продукту. Вони не пов'язані з часом і можуть мати різну цінність для різних команд, тому вони не несуть емоційної цінності. Таким чином, є ймовірність, що члени команди не будуть завищувати оцінки про всяк випадок. Planning Poker допомагає командам розробників планувати робочі процеси та покращувати швидкість виконання проектів.
За допомогою сюжетних точок команда може оцінити:
Сеанс планування - це один з методів оцінки на валовому рівні, що використовує модифіковану версію послідовності Фібоначчі: 1, 2, 3, 5, 8, 13, 20, 40, 100. Щоб оцінити позиції з продуктового беклогу, члени команди отримують однакові набори карт для планування з цифрами на них. Потім, після короткого представлення продукту Власником продукту (який не голосує) та обговорення, вони приватно вибирають карту з кількістю сторіпоінтів, які, на їхню думку, відповідають обсягу робіт, необхідних для завершення цього пункту, і одночасно розкривають їх.
Якщо цифри відрізняються, члени команди обговорюють, чому вони обрали саме таку кількість пунктів для історій, а потім знову голосують. Це частина процесу планування покеру - методу оцінки на основі консенсусу, який використовується в Agile для оцінки зусиль для користувацьких історій. Вони роблять це доти, доки не досягнуть консенсусу, а потім переходять до наступного пункту з продуктового беклогу. І якщо узгоджена кількість висока, скажімо, 20, 40 або більше, це означає, що історія може вимагати занадто багато роботи для одного спринту і, можливо, її потрібно розбити на менші завдання. В ідеалі, презентація пункту, обговорення та голосування повинні займати близько двох хвилин, що дозволяє оцінити весь бэклог за короткий проміжок часу. Але оскільки мета полягає в тому, щоб оцінити весь бэклог одразу, не поспішайте і не хвилюйтеся, якщо деякі історії потребують трохи більше часу для оцінки.
Швидкість команди показує вам, яким є темп розвитку проекту. Це допомагає зрозуміти дві речі:
- Який обсяг роботи ваша команда здатна виконати за один спринт
- Яка прогнозована дата завершення всього обсягу робіт, якщо припустити, що вона буде фіксованою
Швидкість у кожної команди різна. Ви можете оцінити її після перших ітерацій, коли ваша команда вже попрацювала над деякими функціями. Наприклад, якщо на першій ітерації ви включили чотири елементи бэклогу продукту загальною кількістю 20 сторіпоінтів, а команда завершила три з них, що дорівнює 15 сторіпоінтам, то це поточна швидкість вашої команди. Пам'ятайте, що рахуються лише завершені завдання. Навіть якщо вони встигли розпочати четвертий пункт, але не завершили його, він не рахується.
Скрам-майстер відіграє вирішальну роль у полегшенні процесу оцінювання та забезпеченні точних оцінок під час цих сесій.
Після узгодження сюжетних точок та оцінки швидкості команди ви можете визначити графік проекту. Для цього складіть швидкість команди за останні три ітерації і розділіть її на три. Наприклад, якщо швидкість цих ітерацій була 20, 23 і 17, то середня швидкість дорівнюватиме приблизно 20 балам. Якщо загальний обсяг роботи був оцінений у 100 сторінок, то при середній швидкості 20 балів для завершення проекту знадобилося б 5 ітерацій. Якщо припустити, що одна ітерація займає два тижні, то проект має бути завершений за 10 тижнів.
Щоб визначити бюджет вашого проекту, ви можете скористатися такою базовою формулою: (загальна кількість сторіпоінтів / швидкість * години команди на спринт) + витрати, не пов'язані з роботою = орієнтовний бюджет. Поділивши загальну кількість сторіпоінтів на середню швидкість, помножте кількість спринтів на 40 годин на тиждень на кожного члена команди, щоб отримати вартість робочої сили. Потім додайте витрати, не пов'язані з робочою силою, такі як капітальні витрати, витрати на обладнання, технічне обслуговування, витрати на навчання тощо. Наприклад, у нас є проект, який оцінюється в 100 сторінок, а середня швидкість нашої команди - 20. Якщо призначити команду з 5 осіб на проект з погодинною ставкою $50, то години команди на спринт коштуватимуть $20,000 і $100,000 за 5 спринтів. При гіпотетичних нетрудових витратах у розмірі $50 000, кошторис нашого проекту становитиме $150 000. Враховуючи довірчі інтервали на зразкових рівнях 80-120%, заявлений діапазон нашого бюджету становить від $120 000 до $180 000.
Пам'ятайте, що жодна оцінка не є 100% точною. Найкраще переоцінювати проєкт кожні кілька ітерацій, оскільки такі речі, як доступність ресурсів, швидкість роботи команди або обсяг проєкту, можуть змінюватися з часом. Переоцінюючи, ви переконуєтесь, що ваша оцінка актуальна. Використання програмного забезпечення для відстеження часу та планування ресурсів також допоможе вам керувати доступністю команди і перепризначати їх, якщо це необхідно. Використовуючи правильні методи та інструменти, ви можете зробити свій кошторис більш надійним і краще спланувати наступний проект.
Точна оцінка проекту має вирішальне значення для успішного управління проектом. Розуміючи очікування та цілі, створюючи детальний беклог продукту, визначаючи пріоритетність функцій та використовуючи такі методи, як story points і Planning Poker, ви можете підвищити точність своїх оцінок. Регулярна переоцінка та використання інструментів для відстеження часу і управління ресурсами ще більше підвищують надійність термінів і бюджетів ваших проектів. Дотримуючись цих практик, ви зможете подолати проблеми, пов'язані з неточними оцінками, і забезпечити кращі результати проекту.
З легкістю використовуйте техніку оцінки планування покеру
Дізнайтеся, чому наше програмне забезпечення для управління ресурсами обирають менеджери проектів з Hill-Knowlton або Stormind Games
Ефективне планування ресурсів є ключовим завданням для компаній будь-якого розміру, незалежно від того, працюють вони в Інтернеті чи в традиційних галузях. З огляду на широке розмаїття бізнесів, які потребують планування ресурсів, складно надати універсальну рекомендацію...
Компанії зазвичай докладають багато зусиль до розподілу ресурсів. Ви хочете, щоб усі були зайняті, але при цьому були впевнені, що їхні завдання є цінними (що часто означає оплачуваними) для компанії. Це стає дійсно складним, оскільки ваша команда...
Команди по всьому світу стикаються зі схожими проблемами, коли справа доходить до планування робочого графіка. Створити план проекту складно самотужки, а підтримувати його в актуальному стані та реагувати на зміни - ще складніше...