Все самое важное об оценке программных проектов

Успех проекта во многом зависит от точности его оценки. Это непростая задача, требующая понимания всех этапов проекта, экспертизы и хорошего владения программными инструментами.

Каждая компания-разработчик имеет свои алгоритмы работы над проектами, поэтому, вместо того, чтобы пытаться обобщить и унифицировать подходы, мы поделимся собственным видением процесса оценки проектов по разработке программного обеспечения.

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

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

Если заказчик согласен с грубой оценкой, специалисты углубляются в детали разработки и делают детальную оценку, в которой отображаются минимальные и максимальные расчетные часы для каждого этапа проекта.

Детальная оценка всегда содержит так называемую вилку часов. Для небольшого или типового проекта вилка будет небольшой, например, 500–550 человеко-часов; для крупных проектов или совершенно новых задач диапазон будет более существенным.

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

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

Оценка проекта по разработке приложения может включать портфолио с приложениями, созданными командой, и скриншоты приложений, чтобы клиент мог оценить навыки проектирования UI/UX.

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

От чего зависит точность оценки софтового проекта? Перечислим некоторые факторы.

• Наличие ТЗ

Чтобы составить максимально точную оценку разработки ПО, команда должна четко понимать предмет проекта и его масштаб. Чем больше информации клиент предоставит о будущем программном решении, тем точнее команда разработчиков сможет оценить продолжительность проекта.

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

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

Клиент готовит Discovery phase report – отчет об исследовательском этапе, который содержит подробное описание продукта и варианты его использования, макет программного решения и UX-дизайна для него, и многие другие детали.

Команда использует такой отчет сначала для оценки проекта, а затем периодически обращается к нему на протяжении всей разработки.

• Размер проекта и его сложность
  
  

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

• Опыт разработки подобных решений
  

Оценка типового проекта (например, аудио- и видео драйверов Windows) не займет много времени и не вызовет каких-либо затруднений. Грубая оценка будет очень близка по значениям к фактическим цифрам.

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

• Опыт работы с программными инструментами

Если разработчики программного обеспечения свободно владеют всеми необходимыми для данного проекта инструментами – языками программирования, библиотеками, фреймворками и средами разработки, – им гораздо проще оценить продолжительность каждого этапа, поскольку они четко понимают все задачи и могут предвидеть возможные проблемы.

Часы проекта можно разделить на две группы:

• человеко-часы на разработку;
  
  
• человеко-часы на тестирование и администрирование.

Поговорим о часах, отведенных на разработку. Для софта и электроники составляющие оценки будут разные, поскольку разные предметы оценки.

Разработка программного обеспечения может включать в себя такие задачи, как создание пакетов поддержки платформы для различных ОС, UI/UX-дизайн, проектирование баз данных, разработку серверного ПО, драйверов, библиотек, бэкенд и фронтенд разработку и т. д.

Разработка электроники может включать в себя разработку принципиальной схемы устройства, проектирование схемотехники платы, трассировку платы, проверку схемы и платы, подбор корпуса и компоновку и т.д.

Создание электронного устройства всегда включает в себя разработку встроенного ПО, но процесс этот имеет свои особенности и отличается от разработки прикладных программ (например, встроенное программное обеспечение часто не имеет интерфейса).

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

Паузы, вызванные ожиданием компонентов, а также параллельные процессы разработки хорошо видны на диаграмме Ганта. Это незаменимая вещь для оценки IT-проектов, поскольку позволяет наглядно показать течение проекта во времени и эффективно распределить рабочую нагрузку между разработчиками.

Оценка дополнительных часов включает примерно одинаковые компоненты как для софтовых, так и для хардварных проектов. Это тестирование, отладка, подготовка документации, управление проектом, коммуникации и передача заказчику.

Дополнительные активности занимают значительную часть проекта – 50% и более, и растут вместе с размером проекта. Чем масштабнее разработка, тем больше времени тратится на тестирование и администрирование.

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

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

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

Обратите внимание, что изменения в выборе электронных компонентов неизменно повлияют на встроенное программное обеспечение, а значит, время разработки может значительно увеличиться.

Существует множество различных методик оценки объема и стоимости проекта. Перечислим самые популярные из них.

Аналоговая оценка основана на сравнении текущих задач с прошлыми проектами. Метод используется как самостоятельно, так и в составе комплексных подходов к оценке для анализа отдельных этапов, помогая сэкономить время и ресурсы, поскольку команда не оценивает каждую задачу с нуля.

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

Декомпозиция, или оценка «снизу вверх» охватывает весь объем проекта и предполагает расчет стоимости и сроков выполнения каждой задачи. Такой детальный подход вовлекает всех членов команды и фокусируется на мельчайших деталях. Проходя все этапы разработки, программисты могут найти оригинальные способы решения задачи за более короткое время без потери качества.

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

Существуют две формулы расчета.

1. Классический метод – средневзвешенное значение оптимистической оценки (o), пессимистической оценки (p) и наиболее вероятной оценки (m).

2. Бета-распределение (или PERT) – средневзвешенное значение оценок, при этом наиболее вероятному сценарию придается в четыре раза больший вес, чем оптимистической и пессимистической оценкам.

Как правило, метод PERT точнее классической оценки по трем точкам.

Методика Wideband Delphi основана на коллегиальной оценке времени, необходимого для выполнения задачи. Методика предполагает проведение нескольких раундов анонимной оценки задач. Члены команды обсуждают результаты между раундами и могут пересматривать свои ответы в следующем цикле. В конце концов, команда должна прийти к наиболее точной оценке.

Методики оценки могут быть связаны с подходами к управлению проектами. Agile подход, например, использует гибкие методы оценки проектов.

T-Shirt Sizes (Размеры футболки) – метод, который проводит параллель между масштабом задач проекта и размерами футболок. Для всех понятна разница между размерами XS и XL. Так и разработчики используют типовые размеры задач для сравнения без точной оценки каждой из них.

Покер планирования (или Scrum-покер) – это метод оценки, используемый в подходе к управлению проектами Scrum. Проект оценивается с помощью колоды карт. Такая техника минимизирует эффект привязки, когда оценки участников подсознательно смещаются в сторону оценки, ранее высказанной другим членом команды (особенно авторитетным).

У каждого метода есть плюсы и минусы, поэтому вы можете использовать некую целостную оценку, базирующуюся на нескольких методиках для достижения максимальной точности прогноза.

Так, например, техника оценки PERT часто используется с аналоговой методикой или с экспертной оценкой.

Эффективно использовать разные методы для разных этапов. Например, метод покерного планирования можно применить в начале проекта при существенной неопределенности и недостатке информации, а технологию трехточечной оценки использовать позже, когда все данные собраны.

Команда КЕДР Solutions использует несколько методик при оценке софтового проекта. Наши первичные оценки основаны на опыте аналогичных прошлых разработок и экспертном мнении специалистов. Мы также часто используем трехточечный метод для оценки продолжительности и стоимости проекта.

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

Иногда наша команда может использовать методы Scrum, такие как Размеры футболок, Покер планирования и т. д., чтобы понять, насколько быстро мы можем проходить этапы разработки и как оптимизировать процессы.

За оценку отвечает менеджер проекта. Он добавляет в смету проекта необходимые дополнительные часы на тестирование, документацию и т.д. За оценку времени разработки могут отвечать разные специалисты, в зависимости от выбранного метода оценки IT-проекта.

В КЕДР Solutions продолжительность работы над каждой задачей оценивают техлид и разработчики. Кроме того, технический директор всегда проверяет окончательную оценку проекта перед отправкой ее заказчику.

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

По статистике, неправильные оценки при планировании проекта являются одной из наиболее частых причин его провала. Есть две крайности - недооценка и переоценка проекта.

К чему приводит недооценка проекта?

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

• Спешка, вызванная отставанием от графика, а также недостаток времени на поиск лучшего решения отражаются на качестве программного продукта. В результате заказчик либо получает сырое решение со множеством недостатков, либо вынужден ждать, пока разработчики выявят и устранят ошибки.

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

Неправильная оценка может погубила не один проект. К сожалению, такой опыт есть и у нас.

Наша команда сделала грубую оценку проекта по разработке электроники и встроенного программного обеспечения. Были некоторые сомнения, правильно ли мы поняли пожелания заказчика и можем ли взяться за реализацию проекта. Мы посоветовали клиенту провести предпроектную подготовку и написать подробное ТЗ.

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

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

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

• Разработчики программного обеспечения неправильно поняли требования заказчика.
  
  

Чаще всего это происходит из-за отсутствия ТЗ или его плохого качества. Тщательная предпроектная работа и подробное техническое задание позволяют минимизировать риски некорректной оценки.

• Работа над задачей заняла больше времени, чем планировалось.

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

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

Такие ситуации сложно предсказать, поэтому грамотная оценка разработки ПО должна включать дополнительные часы на сложные задачи и непредвиденные обстоятельства.

• Заказчик захотел внести изменения в функционал электроники или ПО.

Чаще всего речь идет о добавлениях новых фичей в ПО, например, при разработке приложений, поскольку в таком случае разработка программного решения не ограничена возможностями аппаратной архитектуры.

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