Дедлайн близько! Як робити правильні естімейти проектів

У сучасній індустрії розробки ПЗ є один аспект, при згадці якого у багатьох досвідчених програмістів напевно спливають недобрі спогади, пов'язані з головним болем через необхідність закінчити проект до дедлайну, овертайм і т.д. Йдеться про терміни та оцінку часу, а точніше, кількість людино-годин, які необхідні для виконання проекту. Як зазначають експерти, і з ними важко сперечатися, оцінка кількості часу на розробку тих чи інших проектів — це ахіллесова п'ята для багатьох, якщо не для більшості розробників. За даними дослідженнякомпанії McKinsey, 66% проектів із розробки корпоративного програмного забезпечення вимагають більших витрат, ніж планувалося спочатку. З цих 66%, третина виходять за межі початкового графіка, а близько 20% не виконують поставлені завдання та цілі взагалі. Це ще не все. Дослідники з'ясували, що 17% всіх ІТ-проектів на практиці реалізуються настільки не відповідно до початкових планів, що починають загрожувати самому існуванню компанії. А загальна сума перевитрати коштів через неправильні естімейти при плануванні проектів зовсім колосальна. “У рамках спільного дослідження фахівці McKinsey та Оксфордського університету проаналізували понад 5400 ІТ-проектів у різних індустріях. Порівнявши бюджети, графіки та прогнозовані поліпшення у продуктивності з реальними витратами та результатами, ми з'ясували, що загальний обсяг перевитрат бюджетних коштів у ході реалізації цих проектів перевищив $66 млрд — це більше, ніж ВВП Люксембургу», – йдеться у дослідженні. “Ми також виявабо, що чим довше за планом має тривати проект, тим більш ймовірно, що він вийде за межі часу та бюджету. З кожним наступним роком роботи над проектом перевитрата коштів збільшується на 15%, - додають аналітики. У сьогоднішньому матеріалі ми поговоримо про те, як проводити оцінку часу на розробку найбільш ефективно та на що звертати увагу насамперед. А також дізнаємось, як досвідчені розробники радять підходити до естімейтів. тим більше ймовірно, що він вийде за межі часу та бюджету. З кожним наступним роком роботи над проектом перевитрата коштів збільшується на 15%, - додають аналітики. У сьогоднішньому матеріалі ми поговоримо про те, як проводити оцінку часу на розробку найбільш ефективно та на що звертати увагу насамперед. А також дізнаємось, як досвідчені розробники радять підходити до естімейтів. тим більше ймовірно, що він вийде за межі часу та бюджету. З кожним наступним роком роботи над проектом перевитрата коштів збільшується на 15%, - додають аналітики. У сьогоднішньому матеріалі ми поговоримо про те, як проводити оцінку часу на розробку найбільш ефективно та на що звертати увагу насамперед. А також дізнаємось, як досвідчені розробники радять підходити до естімейтів.

Методи оцінки часу на реалізацію програмних проектів

1. Порівняння з уже реалізованими проектами (метод за аналогом)

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

2. Командна оцінка

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

3. Знизу вгору та зверху вниз

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

4. Стороння оцінка

Для тих команд, яким особливо складно визначитися з естімейтом при оцінці проекту (або протиріччя серед членів команди не вдається вирішити), є варіант звернутися до сторонньої команди, яка зможе подивитися на проект з боку та видати більш виважене та об'єктивне рішення.

5. Потрійна оцінка

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

Поради та думки бувалих

1. Індивідуальні естімети не можуть переходити до інших членів команди без змін

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

2. Закладайте в план на 15-20% більше часу, щоб застрахуватися від ризиків

Ще одна розповсюджена рада — закладати в офіційний план на 15-20% більше часу, ніж потрібно згідно з початковою оцінкою, щоб застрахуватися від можливого перевитрати часу у разі непередбачених проблем та затримок. Найбільш ризикованими з погляду тимчасових витрат, як правило, є найскладніші та/або найнезрозуміліші частини проекту.

3. Не забувайте про час, що йде на комунікації

У своєму бестселері Manage the Unmanageableпро управління командою розробників автори Міккі Мантл (Mickey W. Mantle) та Рон Лішті (Ron Lichty) стверджують, що в середньому у девелоперів йде на кодинг лише близько 55% часу, тоді як решта 45% вони витрачають на взаємодію та спілкування з колегами, менеджерами, тестерами, дизайнерами, представниками клієнта тощо. Крім того, експерти пишуть, що лише одна шоста від загального часу роботи над проектом припадає безпосередньо на написання коду. Половина часу, а то й більше, йде на тестування та виправлення помилок. Тому досвідчені розробники радять завжди пам'ятати цю статистику та враховувати її під час складання планів. Особливо це важливо для команд, які налічують чимало розробників. За спостереженнями, додавання нових кодерів до команди, щойно їх загальна кількість починає перевищувати певний поріг (зазвичай це 5-6 людина максимум), починає неминуче уповільнювати роботу над проектом загалом. Відбувається це через те, що новому розробнику завжди потрібен якийсь час на те, щоб познайомитись із членами команди та вже існуючим кодом проекту.

Своєчасно коригуйте помилки в естімейтах

“Оновлювати та коригувати початкову оцінку після того, як проект запущено та перебуває в процесі реалізації, абсолютно нормально. Чим більше інформації надає клієнт, тим краще ви розумієте, скільки людино-годин знадобиться на його реалізацію. І чим швидше ви зрозумієте, що план потрібно скоригувати, і зробите це тим краще. Не соромтеся обговорювати це питання з клієнтом, навіть якщо потрібно перенести дедлайн або додати в команду нових спеціалістів,” – радить Серхіо Акоста (Sergio Acosta), досвідчений розробник мультиплатформних додатків. “Звичайно, насамперед за цим повинен стежити проджект менеджер чи тимлід, але насправді їм часто не обійтися без участі рядових розробників. Особливо в тих випадках, коли менеджер/тимлід проджект займається кількома проектами одночасно або занадто зайнятий,

5. Варіанти оцінки часу на проект для клієнта не повинні сильно відрізнятися

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

6. Оцінюйте різні види роботи над проектом окремо

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

Замість епілогу

Втім, деякі експерти вважають, що естімейти у сфері розробки софту — це зло, і від них треба відмовитися зовсім, принаймні у жорсткій формі. Про це у статті Software Estimation is a Losing Gameпише Річард Клейтон (Richard Clayton), старший розробник компанії LotMonkey. Чи потрібні нам естімейти часу при розробці ПЗ? Я ставив це питання проджект-менеджерам та корпоративним босам неодноразово, коли мене просабо зробити оцінку для якогось клієнта, зовсім не маючи достатньої інформації та розуміння завдань. "Звичайно потрібні, адже інакше клієнт не підпише з нами контракт," відповіли вони. І, на жаль, це вірна відповідь. Він вірний, тому що ми дозволяємо системі працювати таким чином, незважаючи на те, що розробка софту погано підходить під цю систему, пише Клейтон. “Насправді команда розробників може лише реалізувати набір можливостей, пропорційно до тієї кількості часу та ресурсів, які були виділені. У якомусь сенсі в цьому ми схожі на туристичну індустрію — ми не можемо гарантувати гостеві. що за тиждень у нашому резорті він чудово відпочине і повністю відновиться. Все що ми можемо — пообіцяти, що чим довше гість у нас залишається, тим більше він від'їжджатиме,» — вважає експерт. Пишіть у коментарях, що ви думаєте з цього приводу. Які методи естімейтів вам здаються найбільш ефективними, чи влаштовує вас нинішній підхід до оцінки проектів, і чи варто докорінно змінювати цю систему, як пропонує Річард?