Оцінка вартості проекту

Доброго дня! Проходжу курс по управлінню ІТ-проектами.

Підкажіть, будь ласка, як оцінювати вартість вартість проекту в людино-годинах / людино-місяцях.

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

Проте, ні родичів/друзів/знайомих розробників чи тестувальників в мене немає, лише сисадміни.

Дякую за допомогу!) Слава Україні!

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Є така книга, відомий безцелер, Автор Фредеріка Брукс, програміст і менеджер IBM — називається «Міфічний людино-місяць». В цій книзі зібрана статистика, яку збирали IBM. Так от там якраз і написано, що ще з 60-х років минулого сторіччя відомо, що програмні продукти оцінювати в людино годинах загалом не вірно.
Так само як і сформульовано закон Брукса — якщо проект відстає від графіку, введення до нього нових людей не пришвидшує — а уповільнює його.

Проект загалом можна оцінювати двома методами.

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

Другий метод персон і функціональних одиниць, також відомих як User Story. Коли відомо що команда може робити в середньому, скажімо, 70 функціональних одиниць в двотижневий термін, можна зробити високо-рівньову оцінку усіх ініціатив, або епіків якщо ініціатива це і є проект і розділити на 70 отримаєте кількість двотижневих ітерацій. Щоб керувати послідовністю ініціатив і епіків будують діаграму відому як Product Roadmap, за змістом дуже схожу на діаграму Ганта але із відмінностями. Цей метод набув широкої розповсюдження при створенні більшості бізнес проектів, від інтернет магазинів до відео ігор. Сам метод дуже добре розписаний в книзі Алана Купера The in mattes Are Running the Asylum. Також в книзі дядька Боба — Clean architecture, де персони називаються Actor і розглядаються як ролі — а не конкретні люди.

Також потрібно робити аналіз та керування ризиками, яке також обов’язково має мати відображення на строки і бюджет.

Усе необхідне можете знайти в одній книзі Демарко Deadline, розписано для початківців в дуже легкій і зрозумілій манері.

Про питання як робити оцінки, коли нема ні експертів ні команди? Пошукати в інтернеті чи де інде чий небудь чись досвід зі створення аналогічних чи схожих проектів + закласти час якраз на формування команди, співбесіди, помилки найму, онбордінги і т.п. Різні ангельські інвестори роблять так, описано в роботах Гая Кавасакі.

Підкажіть, будь ласка, як оцінювати вартість вартість проекту в людино-годинах / людино-місяцях.

Так само як і оцінити скільки буде коштувати ремонт в квартирі.

Тільки з досвіду виконання таких робіт.

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

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

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

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

Тому я і написав що треба мати досвід щоб правильно домножити.

множиш на магічний коефіцієнт, його ти взнаєш з досвіду бо у всіх він різний.

Учитывай, что каждый незнакомый фреймворк для команды автоматически умножает время разработки на 3. Можешь правда рискнуть и подумать что у тебя ниндзи сидят и с тобой ничего не случится и можно умножить на 1. Это может сработать в проекте длиной в месяц. Но через уже 3-4 месяца наступит катастрофа.

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

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

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

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

Підписатись на коментарі