Оцінка трудомісткості розробки проектів. Частина 2

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

Метод оцінки

У цій частині дано детальні рекомендації для оцінки трудомісткості проекту. Практично за кожним пунктом стоять роки досвіду, успіхів і помилок. Запропонований метод в основному застосовується до проектів на етапі, коли опрацьовані вимоги до рівня користувача або функціональних. Багато ж поради та рекомендації підійдуть до будь-яких проектів розробки та інженерних проектів взагалі.

Крок 1. Підготовка (Prerequisites)

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

Крім часу, може знадобитися доступ до існуючих систем, їх коду і документації, даними, ліцензіями, експертам та іншим ресурсам.

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

3. Уважно читайте контракт, якщо він є, нехай і в формі чернетки. Ви можете відкрити для себе багато нового щодо формальних зобов'язань за проектом. Наприклад, вимоги до якості робіт, постачання, термінів, документації. Це прямо впливає на обсяг робіт та їх оцінку.

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

Крок 2. Опишіть вимоги і рамки проекту (scope)

Чотири категорії вимог за ступенем популярності

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

  1. Known knowns. Заявлене в явному вигляді, зрозуміла і достатня для точної оцінки. Що з цим робити? Оцінити.
  2. Unknown knowns. Непряме заявлений або не заявлена, але легко доступне. Не лінуйтеся прочитати вимоги і специфікації, «прокликать» гіперпосилання в них, зайти на сайт клієнта, запитати SME . Це не вимагає великих трудовитрат, але дозволяє набагато краще зрозуміти вимоги і виявити приховані ризики. Що з цим робити? Знайти, прочитати, запитати, з'ясувати, перевести в Known knowns, оцінити.
  3. Known unknowns. Недостатні вимоги, неготова документація тощо. Наприклад, замовник знає, що буде інтеграція з іншими системами, але не знає протоколів, форматів і обсягів обміну даними.

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

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

Дії по підготовці вимог до оцінки

Якщо ж ви з якоїсь причини не оцінили завдання, необхідно просто написати про це:

Feature Estimate
Login page 24mh — оцінюємо
Single sign-on NOT ESTIMATED — оцінимо пізніше, коли буде зрозуміліша
Sign-up link Out of scope — не збираємося оцінювати і робити

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

  1. Ідентифікуйте ризиковані вимоги. Під ризикованими я маю на увазі такі вимоги, як «сайт повинен працювати в будь-якій точці світу і підтримувати всі мови». Вони часто формулюються одним рядком, але можуть збільшити робота вашого проекту на порядок. Як правило, замовник не усвідомлює всієї складності їх реалізації і йому не потрібні «всі мови». На жаль, для виявлення таких вимог доводиться уважно перечитувати всю доступну документацію, оскільки ці «скарби» можуть бути розкидані на сотнях сторінок тексту.
  2. Зберіть нефункціональні вимоги . Мало хто думає на початку проекту про них, тому варто принаймні поставити питання, вибити з замовника хоча б приблизні оцінки кількості даних, користувачів, доступності системи та внести їх до припущення. Багато з цих параметрів можуть критично вплинути на ваші архітектурні рішення, а отже, і на роботи проекту.
  3. Ретельно проаналізуйте успадковані артефакти (legacy). З початком проекту всі вони, на жаль, можуть стати вашими. Це стосується не тільки код, але і документації, даних, контрактів, сторонніх бібліотек та інших речей, що становлять проект. Часто простіше переписати код, ніж намагатися виправити його після попередніх «фахівців», і краще про це знати заздалегідь. Крім технічного боргу, вам можуть перейти в інші види боргів, такі як залежності від зовнішніх компонент, контрактні зобов'язання, погана документація, нецелостные дані і так далі.

«Зробіть так само, але краще»

Важливе застереження з оцінки проектів переписування старих систем на нові платформи без формальних вимог. Зазвичай такі задачі формулюються у вигляді: «Зробіть те ж саме, тільки краще і на новій платформі, оскільки всі програмісти на COBOL вже на пенсії або померли». Мені невідомі надійні способи оцінки таких проектів. Доступ до старій системі і навіть до її вихідного коду не рятує, оскільки комбінаторна складність всіх сценаріїв виконання коду вхідних даних налаштувань системи і оточення не дозволяє відновити логіку роботи програми за розумний час. Але велика проблема полягає в тому, що ви ніколи не зможете зрозуміти, закінчена робота чи ні, через невідомого кількості сценаріїв, які повинні працювати однаково небудь схоже в двох системах.

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

Крок 3. Створіть ІСР на базі вимог

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

  1. ІСР, заснована на декомпозиції по продукту (noun-oriented), простіше для оцінки за цим методом, що грунтується на розбитті по іншим критеріям.
  2. Рівень деталізації ІСР. Рядки нижнього рівня не повинні займати більше 40, максимум 80 годин.
  3. Всупереч загальноприйнятим рекомендаціям покривати 100% робіт, наша ІСР може не містити деякі види робіт зразок зустрічей і менеджменту. Нижче буде зрозуміло чому.

Наприклад, для найпростішої системи обробки замовлень ІСР може виглядати так:

  1. Login page
    • 1.1. UI
    • 1.2. Login
    • 1.3. Logout
  2. Order page
    • 2.1. UI
    • 2.2. Create order
    • 2.3. Confirm order
    • 2.4 Cancel order
    • 2.5. Search and filtering
  3. Integration with payment
    • 3.1. Outbound
    • 3.2. Inbound
ul.disc li{list-style:none!important;}">

Крок 4. Зафіксуйте припущення (Assumptions)

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

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

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

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

Крок 5. Оцініть кожну задачу і проект в цілому

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

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

1. Домовтеся про те, що є розробка

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

Середньостатистичний розробник під час оцінки, швидше за все, оцінить тільки дії, виділені червоним. Розуміння розробника, менеджера і клієнта про те, закінчена розробка завдання, може відрізнятися кардинально, див. Definition of Done . Тому необхідно прийти до загального розуміння.

Далі, дії 2-5 виконуються для кожного рядка ІСР, якщо відповідний тип робіт необхідний.

2. Оцініть час розробки

Для кожної строчки ІСР оцініть реалістичне час розробки у вибраних одиницях вимірювання. Враховуючи властивий більшості людей оптимізм, після цього варто провести уявний експеримент по моделюванню найгіршого випадку, коли все йде не так. Це допоможе виявити приховані ризики і скорегувати реалістичну оцінку в більшу сторону. Оцінка повинна враховувати кількість роботи, складність і ризик.

Якщо різні види розробки оцінюються окремо в рамках одного завдання, наприклад front-end і back-end, то їх оцінки необхідно скласти.

Будьте більш песимістичні в оцінці великих завдань і оптимістичні в оцінці малих. Помилки недооцінки на великих завданнях, очевидно, більш ризиковані. Крім того, переоцінка малих завдань сильно кидається в очі і створює враження непрофесіоналізму або сильної переоцінки всього проекту, підриваючи довіру до вас. При цьому недооцінка малих завдань практично ніякого ризику для проекту не несе.

Якщо ваша команда сформована і спрацьована, хороші оцінки може дати Planning poker , хоча це і відносно дорога техніка.

3. Додайте час на роботу з вимогами та дизайнами

Додайте час на з'ясування, опис, узгодження та уточнення функціональних вимог і дизайнів, а також архітектурне проектування та супровід — близько 70% часу розробки при наявності добре сформульованих бізнес-вимог.

4. Додайте час на забезпечення якості

Додайте часу на роботи по тестуванню (написання тестової документації та безпосередньо ручне тестування, включаючи інтеграційне) — 50% від часу розробки. Якщо ви збираєтеся використовувати автоматизоване тестування, окремо додайте час і на нього.

5. Додайте час на ризики

Оцініть ступінь ризику (Contingency) по завданню. Це суб'єктивний показник того, наскільки розробник впевнений в оцінці та розумінні завдання за наступною шкалою:

Вище 30% — дуже високий ризик, завдання вимагає додаткового дослідження або розбиття на підзадачі. Хоча на ранніх стадіях проекту, в умовах високої невизначеності, коефіцієнт ризику може бути вище.

Ступінь ризику потім множиться на повне час виконання завдання (BA + DEV + TST).

6. Додайте час на общепроектные завдання

Для всього проекту додайте:

7. Зведіть всі разом

В результаті для нашої простої системи обробки замовлень вийде приблизно такий розрахунок:

BA & UI — Business analysis and UX/UI design
DEV — Development
TST — Test
Cont — Contingency

Червоним кольором позначені числа, які необхідно отримати від оцінювачів. Інші ж обчислюються автоматично.

Округляйте оцінку до цілих годин, десятків, сотень, в залежності від кінцевого результату. Число 1574,56 може створити у читача хибне відчуття точності, на відміну від 1580 або 1600.

Зауважте, що трудомісткість всього проекту в три рази вище трудомісткості безпосередньо розробки: 971 людино-годину проти 312. Цікаво, що це співвідношення збігається з висновком в класичній книзі Ф. Брукса з управління проектами «Міфічний людино-місяць» , написаної аж у 1975 році. Воно також може служити грубої перевіркою повноти оцінки.

Крок 6. Оформіть оцінку

Хороша «упаковка» оцінки не менш важлива, ніж її структура та цифри. Правильна комунікація — критично важлива частина процесу оцінки. Документ повинен виглядати акуратно, професійно і бути інтуїтивно зрозумілим.

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

Майте на увазі, що будь-яка оцінка, озвучена вашому менеджменту або замовнику, може бути сприйнята як обіцянку (commitment). Припущення і застереження забудуться, а число чи дата — запам'ятаються.

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

Рівень деталізації документа оцінки залежить від конкретного проекту, клієнта і ваших з ним стосунків. Тут складно давати універсальні поради. Деякі клієнти хочуть бачити всі деталі. Інших же, як правило більше вам довіряють, цікавить тільки кінцева цифра.

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

Чек-листи

Наполегливо рекомендую створювати, використовувати і пропагувати контрольні списки (чек-листи). Неважливо, скільки ви проектів оцінили у своєму житті, завжди є шанс щось упустити. Відмінна книга з цієї теми — The Checklist Manifesto: How to Get Things Right , в якій її автор, Атул Гаванде, описує, як чек-листи рятують здоров'я і життя в авіації і медицині. Цей дешевий і простий інструмент може якось врятувати і ваш проект.

Приклади пунктів, які я використовував для самоконтролю, щоб не забути про час:

Трохи математики

В принципі, вищевикладеного достатньо для того, щоб застосовувати цей метод для оцінки ваших проектів. Далі — трохи математики «під капотом» і моїх думок на тему оцінки виконання проекту. Буду вдячний професійним математикам за коментарі та виправлення неточностей.

Випадкові величини

Час виконання проекту, як і кожної його завдання, — випадкові величини . Локальна мета оцінки проекту — знайти довірчий інтервал роботи проекту з високим рівнем довіри.

Емпірично ми знаємо, що щільність розподілу часу виконання завдання можна змоделювати так, як показано на малюнку нижче, з довгим правим «хвостом» (свого роду наслідок законів Паркінсона і Мерфі ), оскільки кількість негативних ризиків, по суті, не обмежена. На відміну від позитивних ризиків.

Джерело

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

Критика методу трьох точок

Класичний метод знаходження оцінки математичного очікування — це метод трьох точок . У ньому пропонується оцінити якесь оптимістичний, реалістичний та песимістичний час на завдання:

Потім за допомогою формул знайти оцінку зваженого середнього і стандартного відхилення. Формули для знаходження середнього залежать від передбачуваного розподілу, PERT або трикутного :

Зауважте, що навіть у загальноприйнятих описах методу немає чітких визначень і відмінності між найвірогіднішим (most likely) і реалістичним. Також не кожен розробник знає і розуміє, що таке математичне очікування.

Уявімо, що ми дали одну і ту ж задачу 25 розробникам приблизно однакової кваліфікації. І отримали фактичні значення витраченого часу, як на діаграмі нижче. Математичне очікування в такому випадку буде дорівнює 6,16, а найбільш імовірний час виконання — 5. Тобто при неправильній комунікації реалістичної оцінки можна «промазати» на 20-25%.

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

  1. Придумувати три величини для кожної задачі досить трудомістко. На практиці оптимістичні і песимістичні оцінки можуть проставлятися «від ліхтаря», особливо якщо задач десятки або сотні.
  2. Неточність у визначеннях, що є a, m, b, вносить неточність і оцінку.
  3. «Ризик завдання», на мій погляд, набагато більш інтуїтивна категорія, ніж «три крапки».
При цьому метод трьох точок можна порекомендувати для окремих великих і ризикованих завдань. А також для боротьби із зайвою оптимістичністю оцінювача і коригування реалістичної оцінки.

Центральна гранична теорема

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

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

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

На практиці вважається, що доданків має бути не менше 20.

Джерело

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

Збільшуємо довірчий інтервал

Отже, чи підійде нам сума оцінок всіх завдань в якості фінальної оцінки? Тільки в випадку, якщо нас задовольнить 50-відсоткова ймовірність попадання в бюджет... Щоб бути більш впевненим у завершенні проекту в строк і в рамках бюджету, необхідно додати ще деяку величину. При використанні триточкового методу для всіх завдань її можливо обчислити досить строго, наприклад +3 сігми для довірчого інтервалу в 99,7%.

У нашому ж методі додаємо проектний буфер у розмірі від 5% до 15%, величина якого визначається виявленими ризиками, взаимозависимостями між завданнями, розміром проекту, а також лояльністю клієнта до такого роду перестраховикам:

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

Таким чином, наш метод оцінки отримує якесь нестроге математичне обґрунтування.

Висновок

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

  1. Ретельно описуйте рамки оцінюваного проекту, припущення та ризики.
  2. Знайдіть, навчіть кваліфікованих оцінювачів і боріться з оптимізмом усіх учасників оцінки.
  3. Добре оформіть оцінку і постійно спілкуйтеся з усіма стейкхолдерами.
  4. Перевіряйте себе, використовуючи чек-листи і допомогу колег.
Якісна оцінка — необхідна, але недостатня умова успіху. Наслідування кращих практик управління проектом і змінами на всіх його стадіях абсолютно необхідні. При цьому добре виконана і структурована оцінка може сильно допомогти в наступних проектних заходах. Сподіваюся, що цей матеріал покращить життя багатьом керівникам, проектів, командам і компаніям.

Опубліковано: 25/11/19 @ 11:00
Розділ Різне

Рекомендуємо:

Висновок реалізацій інтерфейсів в Scala c бібліотекою Shapeless
Java дайджест #45: Micronaut і Quarkus, відео з Devoxx Belgium 2019
Здоров'я ІТ-спеціаліста: сон, харчування, фізична активність
Certonid — SSH центр сертифікації, який працює на AWS Lambda
Шукаємо причини овертаймів в команді: чек-лист для менеджера