Оцінка проектів для початківців

Кожному з нас в житті доводилось робити оцінки часу. Скільки часу треба на те, щоб дійти від дому до роботи? Або скільки часу знадобиться, щоб зробити домашні справи на вихідних? За скільки часу треба приїхати в аеропорт, щоб встигнути на рейс? Гадаю, хід думок зрозумілий. У більшості людей не виникає особливих труднощів з визначенням конкретних цифр. Деякі оцінки виявляються точними, деякі помилковими. Ми звикли завжди оцінювати час і робимо це на підсвідомому рівні. У веб-проектах (та і в будь-яких інших) оцінках часу (а на основі неї і вартості) проводиться так само, як ми звикли робити це щодня. Різниця лише у вартості помилки.

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

Одноосібна оцінка

Без будь-яких сумнівів заявляю, що це найрозповсюдженіший метод оцінки. Особливо ним грішать молоді та недосвідчені команди. При отриманні нової задачі, менеджер проекту (або інший член команди, який виконує його функції) проводить аналіз та видає кінцеву цифру. Під словом "аналіз" може бути заховано що завгодно, від підкидання монентки до проведення складних розрахунків. Головна особливість методу полягає в тому, що кінцева оцінка заснована на суб'єктивній думці однієї людини. В більшості дрібних та стандартних веб-проектів, досвіду хорошого менеджера достатньо для формування біль-менш точної оцінки, проте для проектів з унікальним функціоналом, не варто зупинятись лише на висновках однієї людини.

Оцінка по аналогії

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

Параметрична оцінка

Метод є доволі схожим з попереднім, проте передбачає формування оцінки на основі окремого параметру, наприклад — рядках коду, сторінках дизайну, діалогових вікнах, таблицях бази даних і т.д. Якщо ми знаємо (з попередніх проектів), що на створення дизайну однієї сторінки необхідно витратити три робочі дні, а новий проект передбачає необхідність створення 20 сторінок, з цього можна зробити висновок, що на весь дизайн знадобиться 60 днів.

Оцінка трьома точками (або PERT)

Дуже корисний метод для усунення проблеми "суб'єктивності" оцінок. Він передбачає формування трьох окремих прогнозів: песимістичного (П), оптимістичного (О) та найбільш ймовірного (Н). Отримані показники обраховуються по формулі, в результаті якої ми отримуємо передбачувану тривалість: (П + 4Н + O)/6. Наприклад, програміст каже, що на реалізацію певного функціоналу, йому буде потрібно: в найкращому випадку (якщо його ніхто не буде відволікати) 10 днів, в найгіршому (якщо все піде "не так як очікувалось") 25 днів, але ймовірніше за все (враховуючи що відсітність відволікання на роботі просто неможлива, але і "зальотів" також не передбачається), він впорається за 15 днів. Провівши простий обрахунок ми отримуємо майже 16 днів.

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

P.S. Якщо вас цікавлять методи оцінки часу та вартості проектів, рекомендую прочитати книгу Стіва Макконела "Скільки коштує програмний проект".