Вот метод оценки проекта разработки программного обеспечения, который я успешно использовал в десятках проектов.

  1. Определите главную цель вашей оценки. Это планирование, ответ на RFP или подготовка бюджета на следующий год? Ответ определяет, на какой риск вы хотите пойти, что включить в свою оценку и как ее представить.
  • Будьте честны с собой и своим клиентом. Если какие-либо части проекта или даже проект в целом невозможно оценить в данный момент из-за отсутствия информации, ресурсов или других неопределенностей, сообщите об этом как можно раньше.
  • Некоторые клиенты могут не захотеть видеть буферы проекта и могут настаивать на том, чтобы вы удалили их, чтобы уменьшить бюджет. Вы можете скрыть буфер проекта, просто добавив 5–15% к каждой задаче.

2. Определите объем оцениваемого проекта. Запишите, какие работы, элементы функциональности, целевые системы и т. д. входят в сферу охвата, а какие выходят за ее пределы, и при каких допущениях, если вам не хватает уверенности.

3. Создайте СПП. Предпочтение отдается существительному, он разбивает работу на части функциональности, отвечая на вопрос Что? вопрос, а не как? или Когда? Проще говоря, это иерархический список функций, которые вы собираетесь разрабатывать.

4. Для каждой строки WBS попросите разработчиков оценить время, необходимое для разработки задачи. До этого согласуйте, что включает в себя разработка (настройка IDE, кодирование, исправление ошибок, развертывание, тестирование разработки, проверка кода и т. д.).

5. Для каждой строки WBS добавьте время для бизнес-анализа, дизайна UX/UI (30–100 % времени разработки) и мероприятий по тестированию (50–100 % времени разработки).

6. Добавьте Risk Buffer для каждой строки WBA (5–30% от BA + DEV + TEST, в зависимости от того, насколько четко определена задача или сколько технических и других рисков она несет).

7. Суммируйте полученное время для каждой строки (QA + DEV + TEST + Risk Buffer)

8. Добавьте время для совещаний (20–30 % времени разработки), управления проектами (10–20 % времени разработки) и DevOps (5–10 % времени разработки).

9. Добавьте проектный буфер (5–30 % совокупного времени, т. е. QA + DEV + TEST + Risk Buffer + Management + Meetings + DevOps).

10. Эмпирическое правило заключается в том, что ваше общее время должно быть примерно в три раза больше, чем чистое время разработки.

11. Запишите масштабы, которые вы оценили, и предположения, которые вы сделали на этом пути. Это неотъемлемая часть вашей оценки.

Вы можете найти шаблон Excel для этого метода на https://www.project-estimate.com/2022/12/software-project-estimate-template.html, а также советы, хитрости и другие секреты оценки. процесс.