Оцінка для мобільних проєктів — що це, методи оцінки завдань

Що таке оцінка?

Оцінка (від англ. estimate — оцінювання) — це прогнозування кількості часу або зусиль, необхідних для виконання завдання. У мобільній розробці оцінки бувають у годинах, днях, сторіпоїнтах або грошовому вираженні. Мета оцінки — не точне передбачення, а зниження невизначеності для прийняття рішень.

Чим оцінка відрізняється від зобов'язання

Оцінка — це прогноз із похибкою. Зобов'язання (commitment) — це обіцянка виконати завдання до певної дати. Різниця критична: оцінка говорить «ймовірно, 5 днів», зобов'язання — «зробимо за 5 днів». Менеджери часто плутають ці поняття, перетворюючи оцінку на дедлайн без права на помилку.

Оцінка як комунікаційний інструмент

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

Методи оцінювання в розробці

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

Planning Poker

Planning Poker — найпопулярніший метод оцінки в Agile. Кожен розробник отримує колоду карт із числами Фібоначчі (1, 2, 3, 5, 8, 13, 21). Після обговорення завдання всі одночасно показують карту. Якщо оцінки розходяться — розробники з мінімальною та максимальною оцінкою пояснюють свою логіку, потім іде повторне голосування. Метод виключає вплив авторитетів і дає більш точну оцінку.

T-Shirt sizing

T-Shirt sizing — груба оцінка за розміром футболки: XS, S, M, L, XL, XXL. Метод використовується для швидкої оцінки великих завдань (епіків) на ранніх стадіях, коли деталі невідомі. Пізніше кожне таке завдання декомпозується та оцінюється в Planning Poker. T-Shirt sizing займає 5-10 хвилин на завдання, але дає тільки порядок величини.

Three-point estimation (PERT)

PERT використовує три оцінки: оптимістичну (O), песимістичну (P) і найбільш імовірну (M). Підсумкова оцінка вважається за формулою: (O + 4M + P) / 6. Метод враховує невизначеність і дає більш реалістичний результат, ніж одинична оцінка. PERT особливо корисний для завдань із високими ризиками або новими технологіями.

Точність оцінки: очікування vs реальність

Точність оцінки залежить від стадії проєкту та кількості відомої інформації. Чим раніше робиться оцінка, тим вища похибка — це нормально і має враховуватися в плануванні.

Конус невизначеності

Конус невизначеності (Cone of Uncertainty) — модель, що описує, як знижується похибка оцінки в міру просування проєкту. На етапі концепції похибка становить 400% (завдання може зайняти від 1 до 4 місяців). На момент спринту — 20% (1-1.2 місяця). Усвідомлення цієї моделі допомагає не вимагати точних оцінок на ранніх стадіях.

Фактори, що впливають на точність

• Складність завдання — нова технологія чи знайома? Невідоме збільшує похибку в 2-3 рази.
• Розмір завдання — дрібні завдання (до 2 днів) оцінюються точніше великих. Декомпозиція покращує точність.
• Досвід команди — команда, яка працювала разом 6+ місяців, оцінює на 30-50% точніше нової.
• Історичні дані — наявність метрик velocity і циклометрії підвищує точність прогнозів.

Відносна vs абсолютна оцінка

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

Як покращити точність оцінки: найкращі практики

Точність оцінки можна підвищити системним підходом, колективним обговоренням та аналізом минулих помилок. Є кілька практик, що довели свою ефективність.

Декомпозиція до 1-2 днів

Будь-яке завдання, оцінене більш ніж у 2 дні, має бути декомпозоване на підзавдання. Принцип: якщо завдання не можна оцінити точніше ніж на 50%, значить, воно занадто велике. Розбийте його на кроки, кожен із яких зрозумілий і оцінюваний. Після декомпозиції сумарна оцінка часто виявляється в 1.5-2 рази більшою за початкову.

Історичні дані та метрики

Ведіть історію оцінок і порівнюйте з фактичними затратами. Наприклад: «завдання, оцінені в 3 сторіпоїнти, в середньому робляться за 4 дні, а не за 2». Використовуйте velocity команди для прогнозування: якщо команда закриває 20 сторіпоїнтів за спринт, не плануйте 30. Аналіз точності минулих оцінок — найкращий тренажер для навички оцінювання.

Якоріння та калібрування

Якоріння — психологічний ефект, коли перша озвучена оцінка впливає на всіх учасників. Щоб уникнути якоріння, у Planning Poker всі показують карти одночасно, а не по черзі. Калібрування — регулярне звіряння оцінок із фактом: через 10-20 спринтів команда вчиться оцінювати точніше за рахунок зворотного зв'язку.

Врахування ризиків в оцінці

Кожне завдання містить приховані ризики: хвороба розробника, проблема з API, зміна вимог. Додавайте в оцінку risk-adjusted factor: для завдань із високими ризиками — множник 1.5-2, з низькими — 1.1-1.2. Прозоро показуйте замовнику, які ризики враховані та як вони впливають на терміни.

Типові помилки при оцінюванні

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

Оптимістична оцінка

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

Оцінка під тиском

Коли менеджер каже «потрібно до п'ятниці», розробник підсвідомо підганяє оцінку під цей дедлайн. Оцінка під тиском завжди занижена і веде до зриву термінів. Рішення: оцінка має передувати дедлайну, а не навпаки. Спочатку команда оцінює, потім сторони домовляються про терміни.

Плутанина між складністю та часом

Складність завдання (скільки думати) і час (скільки робити) — різні метрики. Завдання може бути простим, але довгим (верстати 10 екранів). Або складним, але швидким (знайти баг у легасі). У сторіпоїнтах зазвичай оцінюється складність, а час виводиться з velocity команди.

Ігнорування контекстних перемикань

Розробник не працює 8 годин поспіль над одним завданням: мітинги, код-рев'ю, допомога колегам, адмінка віднімають 30-50% робочого часу. Контекстні перемикання мають бути враховані в оцінці: реально розробник пише код 3-4 години на день.