Яка допустима межа помилки при оцінці тривалості проекту?

Компанія, в якій я працюю, прагне мати 10% максимальну похибку. Очікують, що аналітики не пропустять оцінку на більш-менш ніж 10%.

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

Що може бути хорошою базовою лінією для вимірювання, якщо ми оцінюємо занадто неправильно, більш-менш? Скільки (у%), на вашу думку, нормально пропустити?

Якщо ви не оцінюєте щось дуже схоже на те, що ви та ваші колеги робили раніше, +/- 10% є смішно оптимістичним. Ваше керівництво або не має великого досвіду роботи з програмним забезпеченням, або їм не відомі великі обмеження в оцінці програмного забезпечення . У цьому документі є якийсь супровідний супровідний матеріал , і багато досвіду можна знайти.

Давайте розглянемо набагато простішу систему, ніж типовий програмний проект: Куб Рубіка. Ви можете вирішити будь-яку позицію за 20 рухів , макс. Але оскільки ви оцінюєте, ви можете подивитися на даний куб лише кілька хвилин, перш ніж давати рішення. Чи можете ви дати хорошу оцінку? Ні, іноді оцінка процесу займає більше часу, ніж це робиться.

Ще одна проста система: Буратіно. Дерев’яний автомат, його носовий шматок росте, коли він вимовляє брехню. Що відбувається, коли Буратіно знаходиться в спокої, а потім каже "Мій ніс росте"? Деякі системи не піддаються прогнозуванню, вони не визначені.

Ці дві проблеми вбудовані в більшість програмних систем. Через це ви ніколи не отримаєте оцінок, близьких до +/- 10%.

Моя порада - дати сильно оцінену оцінку, працюйте як раб, щоб виконати проект якнайшвидше, а потім виглядайте зайнятим, поки ви не перестанете на 10% менше або більше. У цей момент оголосити вражаючий успіх.

Я б дуже вагався з приводу будь-якого "цільової межі помилки", оскільки це дійсно залежить від проекту. Якщо ви намагаєтеся оцінити, скільки часу буде потрібно для встановлення, налаштування та налаштування нової системи CRM, де ніхто не зовсім впевнений, які види налаштувань знадобляться та які зміни в бізнес-процесах будуть потрібні та у компанії немає історії подібних великих проектів, ваша похибка повинна бути досить великою (тобто ви можете здогадатися, що це займе 18 місяців +/- 50% і котируйте 9-27 місяців). По мірі просування проекту технічні характеристики стають зрозумілішими, приймаються рішення щодо бізнес-процесів, ваші розробники стають більш комфортними і т. Д. Ці межі помилок повинні посилюватися. Якщо ви намагаєтеся оцінити, як довго ви збираєтеся створити 101-й базовий сайт електронної комерції, коли ви ' Ви отримали гарну історію з перших 100, ви могли б очікувати, що зможете дати набагато більш точну оцінку. Однак більшість проектів збираються десь посередині.

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

Хороший базовий рівень буде один заснований на реальних даних , ви зібрали.

Першим кроком для цього є запис усіх оцінок . Другий крок - запис фактичних результатів . Будьте чесними, не спокушайтесь «саморегулювати» фактичне. Зберіть достатньо цієї інформації, і у вас є деякі дані для статистичної бази, наскільки хороші ваші оцінки. Зауважте, це може / залежатиме від норми залежно від того, хто робив оцінку та хто працював. Тільки роблячи це, можна обґрунтовано очікувати, що ви отримаєте "помилку", що є чимось іншим чистим сміттям.

Це також не зупиняється; аналіз того, що призводить до вимкнення оцінок, може допомогти підвищити точність ваших майбутніх оцінок. Примітка. Вони як і раніше залишаються кошторисом , і як такі є лише кошторисом .

Оцінка також не закінчується після першої оцінки; це може бути скориговано в міру прогресування проекту, оскільки отримано більше знань, це зменшить можливу помилку, коли ви йдете далі. Чим ви відкритіші до спілкування, тим раніше обговорюються сюрпризи - це призводить до того, що люди були менш здивовані та дозволяють більше часу на коригування проекту чи очікувань клієнтів.

По-друге, можливо, кращим способом обробки запасу помилок є « внутрішність впевненості », а не просто% похибки. Ви, ніж ви базували прогнозовану дату доставки на інтервалі довіри, а не окремої дати.

PERT - один із прикладів основи для обчислення на основі статистичних міркувань. Наприклад:

"Виходячи з того, що я знаю зараз, у нас є 90% рівень довіри, який ми можемо забезпечити за 8 місяців. 95% впевненість за 10 місяців, 99% впевненість за 2 роки тощо"

Зауважте тут: чим впевненіше вони хочуть вас, тим більша буде оцінка. Залежно від складності (він же, наскільки точним ви могли бути), це може бути невеликою різницею між 80% і 90%, або вона може бути величезною!

Нарешті - удачі;) Якщо ви коли-небудь вирішите "максимальну кількість помилок" в оцінці програмного забезпечення, згідно з яким ви можете вказати щось на кшталт "усі наші оцінки становитимуть +/- 10%", не забудьте замовити кінофільм на решту нас у галузі програмного забезпечення. Я думаю про щось на зразок схрещування між Office Space та The Matrix: D

Насправді багато залежить від розміру та складності проекту.

Якщо ваша оцінка проекту - 1 тиждень - 10% розумно. Це означає +/- 1/2 дня.
Якщо це 1 місяць, 10% хитне - з мого досвіду неможливо передбачити, що ви відкриєте за 1 місяць.

Більше одного місяця - всі ставки відключені :).

Вони розраховані на одного розробника - так для 4-х команд розробників 1 тиждень == 1 місяць.

Для 4-х команд розробників в основному корисно скласти список функцій, які можна виконати за 1 місяць, і бути в межах 10% для цих функцій. Потім переоцініть на наступний місяць.

Я зробив тут кілька наївних припущень

1. Усі розробники можуть виконувати роботу паралельно.
2. Не вважався тестером - у них повинен був би час на тестування
3. Всі розробники рівні - Frontend, Backend, дизайнери тощо ...

Ви повинні взяти до уваги ті, але .. це загальна ідея.

Існує безліч змінних:

1. Як довго триває проект?

2. Як буде керуватися проектом? Водоспад? Спритний? СКРУМ?

Я б припустив з питання Водоспад. Якщо це так, ви, напевно, очікуєте невдачі на деякий відсоток, враховуючи запит на надбавку.

Якщо відповідь - якась Agile методологія, особливо щось на зразок SCRUM. Не важливо, який відсоток маржі. 50-відсоткова помилка на 2-тижневому спринті - 1 тиждень, на 1-тижневий спринт - 2,5 дня, обидва вкрай гірші сценарії. Це тому, що дата доставки переоцінюється в кожному спринті, і він буде з часом бути все точнішим, а не меншим і меншим.

Із водоспадом 50% помилок не чути жодного з них, але за 12-місячний проект, який становить 6 місяців, і він насправді не виявляється / не захоплюється, це погано до 10 місяців у 12.

Ще коли я керував програмними групами, приблизно навколо мелової та третинної меж, ми фактично наблизились до досягнення +/- 10% за оцінкою. Це було приблизно +/- 15%, якщо моя мізерна пам'ять служить. Але це було тому, що ми оцінювали те, що ми вже зробили : відносно просту прошивку для зв’язку в режимі реального часу, яка приймала байти від A і переміщувала їх до B за допомогою знайомої нам мови, в розробленому нами середовищі в реальному часі. , розмовляючи з апаратними засобами, розробленими хлопцями в кількох офісах. Багато незначних варіантів на вищезгадану тему, буквально років .

Чекаючи досягнення такого рівня помилок у звичайній оцінці програмного проекту, відверто кажучи, смішно . Коли ви бачите, що це, очевидно, досягнуто, це тому, що або люди завищені і недооцінені (роблять зайві речі та проекти для домашніх тварин, щоб витратити бюджет), або недооцінені і працювали, як собаки у вечірній та вихідний дні, щоб поповнити час.

Ви напевно чули річ на 300%, правда?

Я фактично цим користуюся. Повністю спираючись на те, що я бачив роками. Коли я чую день чи два, це справді треба зробити тиждень або більше . І випробувано. У всіх середовищах. Документація оновлена. Перевірена працездатність. Тестування продуктивності. Навантаження перевірена. Пару годин насправді більше схожий на день.

Я думаю, що ми насправді погано оцінюємо через:

• Допомога іншим
• Переривання
• Навчання нових людей
• Інші речі придумують
• Хворіння або нездужання
• Покриття людей, які виїжджають
• Потребує відпустка або вихідний час
• Відволікаючись на інших
• Дотримуючись інших груп
• Бути надто оптимістичним над реалістичним
• Не виділяючи час для роботи над переривчастими тестами
• Легко виключаючи час на тестування, зокрема написання автоматизованих тестів

Тож на найвищому рівні, з діловими людьми, які потребують кращих, ніж 300% оцінок, те, що ми в кінцевому підсумку робимо, - це прагнення до досить хороших оцінок, але ціною вищого рівня та загальніших. "У нас буде функція редагування користувача", навіть якщо версія 1 означає лише для 1 групи користувачів для зміни 1 поля.

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