Одне з питань, яке найчастіше задають на тренінгу — «як оцінити, скільки часу піде на виконання задачі Х?». Питання актуальне не лише для бізнес-аналітиків, але і для колег, що обіймають інші посади. Понад усе дане питання актуальне для керівників проєктів. Я хочу поділитися своїм досвідом та розповісти про деякі техніки, які мені довелося використовувати при оцінці трудомісткості задач по бізнес-аналізу.
Для чого потрібна оцінка
Почнемо з деяких загальних відомостей про оцінку трудомісткості. Чому бізнес-аналітики, розробники, тестувальники та інші ролі воліють не озвучувати оцінку задач? Причина доволі тривіальна — оцінка сприймається як зобов’язання або, як доволі часто говорять в аутсорсі, «commitment». Доволі часто фразу «на цю задачу потрібно п’ять — сім днів» керівники проєктів сприймають як «через п’ять днів задача буде готова». А хто ж захоче брати на себе ризики? Простіше всіма доступними засобами уникнути відповіді. Оцінка за замовчуванням не є точною, це прогноз, що спирається на доступну на момент формування інформацію.
Як можна підвищити точність своїх оцінок? Перш за все необхідно почати їх (оцінки) робити, відстежувати точність, аналізувати причини відхилення. Чим більше ми оцінюємо, ти вище точність (якщо ми підходимо до цього процесу свідомо й робимо висновки).
Найгірша оцінка — відсутня оцінка (з погляду того, кому дана інформація потрібна як вхід для подальшого планування). Надаючи оцінку, ми знижуємо рівень невизначеності. Навіть якщо ми оцінюємо назагал, це все одно краще аніж нічого.
Методи оцінювання
Перейдемо від загальних слів до практики.
Перший метод оцінки — оцінка за аналогією. Отримавши запитання «скільки часу потрібно для підготовки вимог до підсистеми Х?» ви можете важко зітхнути та згадати, а скільки часу було витрачено минулого разу на подібну задачу. Це найбільш узагальнений метод оцінки. Його точність збільшується, якщо ви працюєте з ідентичними проєктами без зміни контексту (методологія, перелік зацікавлених осіб, команда розробки, інструменти для керування вимогами тощо)
Підвищити точність оцінки «за аналогією» для об’ємної задачі можна шляхом декомпозиції її на більш дрібні задачі та оцінювання вже безпосередньо їх. Даний метод можна використовувати у випадку, коли керівнику проєкту оцінка задачі загалом здається дещо завищеної. Розбийте задачу на менші задачі, оцініть кожну з них і ви або зможете аргументувати керівнику правильність першої оцінки, або переконаєтесь самі, що ваша оцінка в деталях відрізняється від першочергового прогнозу. Чим більше задача, чим більше невідомих чинників, тим складніше виконати оцінку. Саме тому «слона вартує їсти частинами».
До прикладу, скільки часу буде необхідно для підготовки документа «Концепція проєкту» («Project Vision»)? Відповісти одразу доволі складно. Розділимо документ на розділи, для кожного визначимо перелік необхідних робіт, й ось у результаті ми отримаємо і план робіт, і загальну оцінку.
Наступний метод — параметрична оцінка. До прикладу, вам необхідно написати SRS (Software Requirement Specification), що складається з 20 юзкейсів. Базуючись на вашому попередньому досвіді (ага, привіт, методи оцінки за аналогією), підготовка одного юзкейсу займає приблизно півтора робочих дні. Користуючись тривіальними розрахунками отримаємо результат: усі юзкейси ви підготуєте через 30 робочих днів. У наведеному прикладі параметром слугує трудомісткість підготовки одного юзкейсу. Параметрами можуть бути й кількість екранних форм, бізнес-процесів, які необхідно описати, кількість сутностей при створенні словника даних тощо.
Третій метод — оцінка за трьома точками або PERT. Ми визначаємо оптимістичну, песимістичну та реалістичну оцінки (із використанням будь-якого з вище описаних методів) і застосовуємо магічну формулу:
Оптимістична оцінка + Песимістична оцінка + 4 * Реалістична оцінка
Оцінка = ----------------------------------------------------------------------------------------------------
6
Замість коефіцієнта «4» в чисельнику ви можете використовувати довільний інший коефіцієнт, але в такому випадку важливо не забувати синхронно змінювати коефіцієнт у знаменнику на відповідний.
Експертну оцінку можна використовувати у випадках, коли ви делегуєте право на визначення оцінки спеціалісту, який зробить це краще за вас або разом із вами. Але ж що робити, якщо таких експертів декілька? Тут на допомогу нам приходить метод Дельфі. Припустимо, у нас є список задач та група експертів, яким доручено оцінити їх трудомісткість. Експерти незалежно один від одного проводять оцінювання задач, далі їх оцінки аналізуються. У випадку, коли всі експерти надали однакові або оцінки, що несуттєво відрізняються одна від одної, — ми отримали узгоджений результат. В іншому випадку, експерти отримують інформацію щодо альтернативних точок зору та можуть обґрунтувати своє бачення. Після цього має бути проведений черговий раунд незалежного оцінювання. Ті, хто працює за фреймворком Scrum можуть сказати: «Так це ж Planning Poker!» і будуть абсолютно праві. Так, Planning Poker у Scrum — реалізація методу Дельфі. Використовуючи даний метод, можна організувати роботу експертів у різних галузях та щодо різноманітних питань, а не лише для оцінки трудомісткості задачі.
Приклад використання методу Дельфі та декомпозиції. У моїй команді кількість бізнес-аналітиків коливалася від 3-ох до 6-ти. Головним об’єктом оцінювання були юзер-сторі. Роботу над кожною з них ми розділяли на три етапи: виявлення, специфікація, обговорення + погодження. До сесії групового планування БА-задач ми незалежно оцінювали трудомісткість кожної історії, над описом якої ми в подальшому планували працювати. Під час сесії ми порівнювали отримані оцінки та у випадку значних розбіжностей обговорювали оцінку кожної складової, з’ясовували причини розходження та проводили повторне голосування. Якщо для когось із команди задача була легша через наявність експертизи з даного питання, то він/вона отримував(ла) цю юзер-сторі та саме його/її оцінка приймали за основну (м’яка реалізація принципу «якщо готовий зробити в озвучені терміни — візьми та зроби» 😊).
Наступний метод — метод набігаючої хвилі (Rolling Wave). Інтуїтивно зрозуміло: чим більшим є обсяг роботи, яку ми оцінюємо, тим вищою є неточність. Окрім того, між задачами, які нам необхідно оцінити, можуть бути залежності (до прикладу, допоки не буде зроблена задача А, точно оцінити трудомісткість задачі Б — важко). Однак, від вас очікують оцінку всього списку задач.
Припустимо, вам необхідно написати документ «Бачення» (Vision). Ви визначили структуру документа, підготували верхньорівневий план робіт і дали попередню оцінку трудомісткості в 35 днів. Після цього ви підготували детальний план того, що ви плануєте робити найближчі 5 днів: визначення ключових зацікавлених осіб, формулювання постановки проблеми та визначення процесів, які система має зачепити. Шляхом неймовірних зусиль вам вдалося вкластися в попередню оцінку «5 днів». Після цього стало очевидно, що 35 днів буде недостатньо. Отриманий досвід співпраці із зацікавленими (або не дуже зацікавленими) особами, краще розуміння меж системи, дозволяють вам провести повторне оцінювання трудомісткості решти задач та підготувати детальний план на наступні 5–7 днів. І так повторюємо після кожної ітерації.
Таким чином даний метод передбачає наявність у вас верхньорівневого плану на довготривалу перспективу та детального — на найближчий період. Верхньорівневий план необхідно регулярно переглядати відповідно до результатів завершення проміжного етапу. У даного методу є один суттєвий недолік — ваша перша оцінка може значно змінитися протягом роботи над проміжними етапами (як показує досвід, зміна відбувається в сторону збільшення). Але є і позитивний аспект: ви не відкладаєте сумну звістку про те, що задача не буде виконана вчасно, на останній момент. А це значить, що керівництво матиме більше можливостей застосувати запобіжні або коригувальні дії.
Чим більше разів ви пройдете шлях «дав оцінку — виконав роботу — порівняв план із фактом — проаналізував причини розбіжностей», тим краще будете оцінювати трудомісткість робіт. Коли я говорю про планування, мені на думку приходить книга Де Марко «Вальсуючи з ведмедями». У ній є такий графік:
По осі Х — дати, де дата N — скільки часу нам знадобиться на виконання проєкту, якщо все буде добре, а по осі Y — ймовірність що проєкт буде виконано. Оскільки в нас є доволі багато ризиків, ймовірність вчасно завершити проєкт — відверто не висока. Чим більше разів ви пройдете через описаний вище цикл, тим краще будете розуміти з якими ризиками можете зіштовхнутися, а відповідно і яку похибку необхідно застосовувати до вашої оцінки. В одному з моїх проєктів до питання виявлення даної проблеми підходили системно. В JIRA накопичувалися дані по вихідним оцінкам трудомісткості задач та часу, що фактично було витрачено на їх реалізацію. Через два місяці виявилося, що в середньому при оцінці трудомісткості мої колеги припускаються помилки на 25 % в сторону заниження. Застосовуючи надалі відповідні коефіцієнти при плануванні, нам вдалося знизити кількість вимушених овертаймів та частіше вкладатися в терміни, що були озвучені клієнтам.
Оцінюйте, враховуйте ризики, підбирайте техніки, що будуть відповідати умовам вашого проекту. Переклад виконано: Mariya Terletska (Popova)
Comments