Важко передбачати майбутнє! Ці поради допоможуть вам уникнути поспішних оцінок.
Більшість людей повинні робити оцінки робіт, які вони виконують, але ми не дуже добре справляємося з оцінкою у галузі програмного забезпечення. У цій статті Карл пропонує шість безпечних порад, які потрібно враховувати при підготовці оцінок вашого проекту та вашої персональної роботи.
Порада #1 для оцінки: Метою є не сама оцінка
Дата делівері, встановлена менеджментом чи маркетингом – це не про оцінку часу, це про ціль. Команда якогось певного розміру та рівня продуктивності може створити обмежену кількість високоякісної функціональності за визначений період часу. Часто навчальні матеріали з проведення оцінки надаються з припущенням, що обсяг роботи чітко визначений, а метою самої оцінки є визначення відповідного зусилля, вартості та часу, необхідних для виконання цієї роботи. Іноді, однак, оцінка працює по-іншому. Якщо деякий великий елемент функціональності обов’язково повинен бути виконаним до конкретної дати, то оцінювач повинен визначити, яка кількість якісної функціональності може бути реалізована протягом визначеного часу. Це є передумовою для визначення розміру історій користувачів в agile розробці та їх вписування у спринт фіксованого розміру. Зобов’язання мають ґрунтуватися на правдоподібних оцінках, а не лише на бажаних цілях. Якщо не існувало реальної можливості завершити роботу до встановленої кінцевої дати, то вважати її простроченою не варто.
Порада #2 для оцінки: Ваша оцінка повинна бути незалежна від того, що, на вашу думку, замовник хоче почути
Якщо ваша оцінка занадто відрізняється від очікувань замовника, тоді, звичайно, вам потрібно буде досягнути певних домовленостей. Проте не змінюйте свою оцінку просто тому, що комусь вона не сподобалась. Припустимо, ваш менеджер запитує оцінку для певної роботи, і ви відповідаєте: “Два місяці”. “Два місяці?” – здивовано запитує ваш менеджер. “А моя бабуся з легкістю зробила б це за три тижні навіть з однією рукою зв’язаною за спиною!” Тож ви пропонуєте ще раз: “Добре, можливо, один місяць?” Що змінилося за ці декілька секунд? Нічого! Завдання не скоротилося, ви не отримали жодної допомоги, і ви магічним чином не стали більш продуктивним. Вашому менеджеру не сподобалася ваша перша відповідь, тому ви запропонували альтернативу, яка може бути прийнятною.
Немає потреби зменшувати ретельно пропрацювану оцінку просто тому, що хтось нею не задоволений. Ми не очікуємо, що дощовий день стане сонячним просто тому, що ми хочемо піти на пікнік (особливо тут, в Портленді, штат Орегон). Також не має сенсу змінювати власні очікування майбутнього, якщо не відбулися зміни у факторах, які впливають на вашу думку про те, що повинно відбутися. Ви можете перевірити припущення, спробувати різні методи оцінки, дослідити ризики або обговорити обсяг, ресурси чи якість. Але не піддавайтеся тиску лише для того, щоб хтось усміхнувся.
Порада #3 для оцінки: Правильна відповідь на будь-який запит щодо оцінки: “Я повернусь до вас з відповіддю”
Краще уникати спокуси давати комусь оцінку нашвидкуруч, якщо ви ще докладно не обміркували проблему. Насправді ви не проробили оцінку, ви просто сказали оцінку навмання. Нажаль, такі випадкові припущення часто звучать як зобов’язання для тих, хто їх чує. Перед тим, як надати оцінку, добре подумайте, що саме вимагається. Потім оцініть, скільки часу та зусиль дійсно знадобиться для виконання цього запиту.
Це особливо поширена проблема при обробці запитів щодо зміни вимог. Невеликий аналіз впливу часто показує, що реальний обсяг робіт є значно більшим, ніж ви думали на основі початкової інформації, яка була вам доступна. Тому перед тим, як сказати “Звичайно, жодних проблем”, переконайтеся, що розумієте, на що ви погоджуєтеся. Іноді надання більш реалістичної оцінки дозволяє заявнику відмовитися від ідеї, оскільки вона просто не варта витрат часу чи коштів. Краще знати про це до початку роботи, ніж дійти наполовину і викинути все, що вже було вкладено, коли зміна виявиться надто великою, щоб її виправдати.
До теми – ВІГЕРСОПЕДІЯ – Обговорення реалістичних зобов’язань.
Порада #4 для оцінки: Уникайте надання точкових оцінок
Оцінки містять невизначеність – саме тому їх не називають прогнозами. При наданні оцінки зважайте на свою впевненість у її точності. На скільки відсотків ви впевнені, що закінчите роботу протягом запропонованого часу: на 10, 50 чи 90 відсотків? Зазвичай ми навіть не думаємо про це, не кажучи вже про висловлення цього в голос. Людина, яка отримує оцінку, ймовірно, припускає, що ви впевнені в оцінці на дев’яносто відсотків, навіть якщо ви пропонуєте найкращий сценарій з імовірністю у десять відсотків. Ця розбіжність може призвести до неприємних сюрпризів, коли оцінка виявиться надто оптимістичною. Тож поділіться своїми думками щодо ймовірності відповідності вашої оцінки з реальним результатом. Або презентуйте оцінку як діапазон значень, а не як окреме число. Визначте мінімально можливу тривалість (або вимірюваний чинник) роботи, найбільш ймовірне або очікуване значення та максимально очікувану тривалість, за винятком якоїсь катастрофічної події.
Ви можете розрахувати єдину номінальну оцінку за цією формулою:
Оцінка = (Мінімальне значення + 4 × Очікуване значення + Максимальне значення) ÷÷ 6
Це дає зважений середній показник, який приблизно відображає розподіл ймовірності. Нажаль, люди, які отримують ваш діапазон оцінок, можуть вибирати найменшу значення з діапазону як ту, яку вони хочуть почути. Менеджер, який йде з мінімальною оцінкою вибирає для себе управління проектом з низьким рівнем впевненості, лише з малою ймовірністю виконання проектних зобов’язань. Немає захисту від нерозумних людей, які відкидають обґрунтовані оцінки, але принаймні візьміть за звичку визнавати наявну невизначеність, що пов’язана з усіма передбаченнями майбутнього.
Порада #5 для оцінки: Включіть в оцінки буфери на випадок непередбачених ситуацій
Ніщо не відбувається точно за планом. Тому закладайте в оцінку додатковий час для кожної частині роботи. Ці резерви допоможуть врахувати будь-які непередбачені завдання, які можуть виникнути, і компенсують оцінки, які виявляться надто низькими. Крім того, резервні буфери допомагають впоратися з ризиками, які перетворюються на проблеми. Якщо ви не залишаєте жодного резервного запасу у своєму графіку, перша ж неочікувана ситуація зруйнує ваші плани. Працюйте, за визначеними оцінками, але зовнішньо дотримуйтесь оцінок, що враховують буфер. Додатковий буфер іноді сприймаються просто як додатковий запас часу, що захищає вас, якщо ви не супер профі в створенні оцінок. Менеджери іноді хочуть позбутися додаткового буферу, припускаючи, що це якимось чином скоротить проект. Однак менеджер, що зневажає на запланований додатковий часовий резерв, керується кількома припущеннями:
- Усі оцінки є ідеальними;
- Ризики не перетворяться на проблеми;
- Проект не збільшиться;
- Нічого несподіваного не відбудеться.
Кожен, хто коли-небудь працював в проекті програмного забезпечення знає, що ці припущення є нереалістичними. Щоб допомогти менеджеру уникнути цих жахливих припущень можна навести з досвіду попередніх проектів приклади неочікуваних ситуацій. Поцікавтеся, чи є якась причина вірити, що новий проект буде іншим, і жодних неприємних кейсів не повторяться. Якщо ж поважних аргументів не буде наведено, буфери повинні залишатися.
Порада #6 для оцінки: Записуйте фактичні результати та порівнюйте їх з оцінками
Можливо, ви чули, що добре обґрунтовувати свої оцінки, посилаючись на історичні дані. Одного разу мене запитали: “Але де ми можемо взяти історичні дані?” Що ж, якщо ви записуєте, що ви робили сьогодні, то завтра це вже стане історичними даними. З наведеного прикладу це не є надто складним. Тому привчайте себе записувати свої оцінки і зберігати записи про те, що насправді відбулося. Це єдиний спосіб покращити оцінки в майбутньому. Насправді, якщо ви цього не робите, то наступного разу ви не будете оцінювати, ви будете вгадувати, знову. Якщо наявна суттєва розбіжність між прогнозом та реальністю, потрібно зрозуміти, чому це сталося та подумати, що можна зробити в майбутньому, щоб провести краще оцінку подібної роботи. Чи є додаткові фактори ризику, які потрібно врахувати наступного разу? Чи були ви надто щедрими в своєму припущенні щодо продуктивності? Чи ви пропустили якусь задачу? Можливо, ви могли б створити таблицю із завданнями для кожного типу роботи. Наприклад, люди часто забувають про необхідність планувати час на перероблення вже після закінчення фази тестування або рецензування. Однак, як показує мій власний досвід, майже завжди є щось, що потребує перероблення і на виконання цього потрібний певний час. Тож включайте задачі над переробленням до своїх оцінок, навіть якщо ви не знаєте, скільки саме роботи потрібно буде виконати в конкретній ситуації. З часом, коли у вас буде достатньо даних, ви зможете розрахувати середні значення, які допоможуть вам складати більш детальні та якісні оцінки майбутньої роботи.
Ці шість порад з безпеки можуть не допомогти вам створювати такі оцінки, якими будуть задоволені всі: ваші клієнти, менеджери та колеги, але вони, принаймні, допоможуть вам та вашій команді бути на одній хвилі.
Оригінальна стаття – Six Estimation Safety Tips, переклад – Анна Захарова, ревью – Олександра Серебрянська (Business Analysis Community Kyiv), оригінальне фото від Marc A з сайту Pixabay.