Расчет сроков и стоимости проектов: как это делается и можно ли упростить процесс?
Если вы когда-либо занимались разработкой приложений на заказ, то наверняка знакомы с довольно рутинным процессом расчета стоимости и сроков реализации проекта. И ладно бы, если расчет проекта выполнялся лишь единожды, но зачастую потенциальные заказчики не могут уложиться в бюджет, и начинают на ходу менять требования к продукту:
— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?
Стандартные пути упрощения расчетов, такие как установка фиксированной стоимости дня работы сотрудника или компании, как правило ведут к потере точности результатов и все равно не избавляют нас от ручных вычислений.
Но, как и любой другой процесс, характеризующийся словами “рутина”, “точность” и “вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.
Процесс расчетов
Прежде всего нам следует определиться с тем, как в общем случае формируются конечные сроки и стоимость проектов.
Шаг 1: Оценка задач
Первое, что необходимо сделать после изучения требований заказчика, это разделить проект на независимые друг от друга функциональные части (задачи). К примеру, если мы выполняем оценку мобильного приложения для стандартного интернет-магазина, то деление может выглядеть примерно следующим образом:
- Каталог товаров
- Корзина и оплата заказов
- Новости магазина
- Контакты
После этого командой разработчиков осуществляется определение временных трудозатрат на реализацию всех перечисленных задач:
| Задача | UI/UX | Back-end | Android | iOS |
|---|---|---|---|---|
| Каталог товаров | 4 дня | 2 дня | 3 дня | 4 дня |
| Корзина и оплата заказов | 3 дня | 5 дней | 4 дня | 5 дней |
| Новости магазина | 2 дня | 2 дня | 1 день | 2 дня |
| Контакты | 1 день | 2 дня | 2 дня | 3 дня |
Шаг 2: Расчет сроков разработки проекта
Как бы ни старалась разработчики, но их оценка сроков крайне редко соответствует действительности. Так что, первым делом, отталкиваясь от сложности проекта и опыта команды, мы определяем страховку: количество дополнительного времени, необходимого для разрешения различных непредвиденных обстоятельств. Обычно страховка выглядит как некоторый множитель (процент), на который увеличивается общий срок разработки.
Далее нам следует определить очередность этапов выполнения работ (workflow). Вне зависимости от используемой методологии (agile или waterfall) нам нужно знать в каком порядке нашей командой выполняются различные виды работ. В рассматриваемом нами примере с мобильным приложением порядок мог бы выглядеть следующим образом:
То есть, сначала независимо друг от друга выполняется разработка бэк-энда и пользовательского интерфейса, и при их завершении начинается параллельное программирование приложения под разные платформы. После того, как все этапы будут завершены, проект будет считается выполненным.
Теперь мы располагаем всей необходимой информацией и можем приступить к расчету сроков:
В случае с Waterfall: суммируем количество времени для каждого вида работ (UI/UX, Back-end, etc.), добавляем к ним страховку, и, учитывая их очередность, находим самую длительную последовательность работ, которая, собственно, и представляет общее количество времени, необходимое для реализации проекта.
В случае с Agile: учитывая очередность работ, мы определяем время на реализацию каждой из задач (каталог товаров, новости, etc.), после чего, путем их суммирования и добавления страховки, получаем конечный срок реализации проекта.
Шаг 3: Расчет стоимости разработки проекта
Следующее, что нам следует получить — это себестоимость проекта, которая обычно формируется из двух типов затрат: общих ежемесячных расходов (аренда офиса, оплата серверов, лицензий на ПО, etc.) и зарплат непосредственных исполнителей проекта. Что касается зарплат менеджмента, то они больше подходят к первой категории, так как являются более “пассивной” статьей расходов, и в некоторых случаях они могут быть опциональными (к примеру, если речь идет о небольшой команде фрилансеров).
“Общие ежемесячные расходы” рассчитываются предельно просто: делим их сумму на среднее количество дней в месяце и умножаем на количество календарных дней, необходимых для реализации проекта.
Расчет расходов на зарплаты исполнителей зависит от используемой методологии разработки:
В случае с Waterfall: для каждого сотрудника делим ежемесячную зарплату на среднее количество рабочих дней в месяце и умножаем результат на количество рабочих дней, необходимых для реализации этапа работ, за который он ответственен; в конце суммируем все выплаты.
В случае с Agile: для каждого сотрудника делим зарплату на среднее количество рабочих дней в месяце и умножаем на количество рабочих дней, необходимых для реализации всего проекта, в конце суммируем результаты.
Теперь, зная себестоимость проекта (выплаты исполнителям + общие расходы), мы можем получить конечную стоимость, добавив к ней ещё пару вещей:
1. Прибыль: здесь все довольно просто, мы либо прибавляем желаемый процент от себестоимости проекта, либо добавляем соответствующий пункт к “общим расходам” (если желаем получать фиксированный ежемесячный доход).
2. Налоги: каждый считает их немного по-своему в связи с разнообразием систем налогообложения и способов уклонениях от них. В некоторых случаях можно считать налоги как некоторый усредненный процент от себестоимости проекта с включенной прибылью.
3. Комиссия менеджера по продажам: зависит от ваших условий сотрудничества, если вы выплачиваете процент от сделки, то это процент от суммы себестоимости, прибыли и налогов, и если вы выплачиваете процент от прибыли, то, очевидно, считаете ее как процент от заложенной прибыли, полученной в первом пункте.
Итак, теперь мы располагаем итоговой стоимостью проекта. Но что делать, если клиент, услышав результат, спросит нас: “А что если сделаем без X?”.
Автоматизация вычислений
Можно ли разработать приложение, которое бы производило подобные расчеты автоматически? Ознакомившись с процессом вычислений, теперь мы можем сказать, что да, это возможно, но не без пары нюансов. И первый из них — это расчет налоговой части.
Учет всех возможных вариантов налогообложения при расчетах требует не только значительных трудозатрат на разработку, но и на постоянную поддержку формул в актуальном состоянии. Вариантов решения проблемы здесь несколько: либо жертвуем точностью расчетов и считаем налоги как некоторый процент от стоимости проекта, либо же значительно усложняем систему расчетов, добавляя возможность ее ручной модификации.
Следующий нюанс — это способ безопасного хранения информации о всех расходах, зарплатах и проектах компании. Здесь тоже есть несколько возможных вариантов:
- Храним данные на сторонних серверах приложения (SaaS). Быстро и удобно, но требует доверия к владельцам сервиса.
- Разворачиваем приложение на собственных серверах. Этот вариант требует трудозатрат на настройку и сопровождение приложения, но позволяет самостоятельно контролировать безопасность данных. Дополнительно можно сделать приложение доступными только из собственной инфраструктуры, но это лишает определенных удобств, таких как возможность обратиться к расчетам с личного телефона за пределами офиса.
- Реализация программы для расчетов в виде самостоятельного десктоп-приложения, хранящего все данные в локальном файле. Этот случай не предполагает никакой настройки окружения и позволяет самостоятельно контролировать безопасность данных, жертвуя возможностью предоставления общего доступа к данным.
Тем не менее, несмотря на перечисленные проблемы, автоматизация процесса расчетов все равно возможна, и она несет за собой ряд преимуществ:
— Жизнь сотрудника, занимающимся расчетами, станет немного легче
— Клиенты смогут получать перерасчеты в считанные секунды
— Стоимость разработки станет чуть более справедливой и конкурентной
На сегодняшний день существует очень небольшое количество решений для подобного вида расчетов, и все они имеют достаточно высокий порог вхождения из-за своей монструозности. В связи с этим хотелось бы задать вопрос аудитории Хабра: а каким способом выполняются расчеты в вашей компании?
Источник
Управление стоимостью проекта
Проект считается успешным, если он завершен в установленные сроки, выполнен в рамках бюджета и в соответствии с ожиданиями заказчика. Управление стоимостью заключается в обеспечении выполнения тройного ограничения на управление проектами — по стоимости, срокам и содержанию [ 10 ] . Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета. К процессам управления стоимостью относятся:
стоимостная оценка — определение примерной стоимости ресурсов, необходимых для выполнения операций проекта;
разработка бюджета расходов — суммирование оценок стоимости отдельных операций или пакетов работ с целью формирования базового плана по стоимости ;
управление стоимостью — воздействие на факторы, вызывающие отклонения по стоимости, и управление изменениями бюджета проекта .
Взаимодействие процессов представлено на рис. 6.1.
При отсутствии управления стоимостью проект, как правило, выходит из-под контроля, и его стоимость возрастает. Рассмотрим подробнее каждый из процессов.
Стоимостная оценка
Стоимостная оценка — это процесс установления стоимости ресурсов проекта , основанный на определенных фактах и допущениях. Для определения стоимостной оценки прежде всего необходимо определить операции ( пакет операций ), длительность операций и требуемые ресурсы. Процесс оценки и его результат в значительной степени зависят от точности описания содержания, качества доступной информации, от стадии проекта. На процесс стоимостной оценки оказывают влияние: время, отведенное для проведения оцениваемой операции , опыт менеджера, инструменты оценивания , заданная точность . Оценка стоимости проекта начинается на предпроектной стадии (до заключения контракта) и выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки стоимости [ 12 ] :
- оценка порядка величины;
- концептуальная оценка;
- предварительная оценка;
- окончательная оценка;
- контрольная оценка.
На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от (-50%) до (+100%). Точность концептуальной оценки находится в интервале (-30%) — (+50%). Точность предварительной оценки проекта колеблется от (-20%) до (+30%). На этапе окончательной оценки точность колеблется от (-15%) до (+20%). Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку ( рис. 6.2).
Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т. д.) для облегчения сравнения проектов и операций внутри проекта.
Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь , Интернет , арендованные помещения, а также особые статьи расходов, например учет уровня инфляции или расходы на непредвиденные обстоятельства.
Входная информация для процесса оценки стоимости [9]
Факторы внешней среды предприятия. К факторам внешней среды относятся конъюнктура рынка, коммерческие базы данных и прайс-листы. Конъюнктура рынка — это рынок информационных систем, их конкурентная функциональность, стоимость, услуги на внедрение, сопровождение. Коммерческие базы данных и прайс-листы содержат сведения о квалификации и стоимости трудовых ресурсов, стоимости внедрения информационных систем.
Активы организационного процесса — официальные и неофициальные правила, процедуры и руководства по стоимостной оценке, шаблоны стоимостной оценки, информация о стоимости ранее выполненных проектов.
Описание содержания проекта содержит важную информацию о требованиях, ограничениях и допущениях проекта, которую необходимо учитывать при стоимостной оценке.
Иерархическая структура работ определяет взаимоотношения между всеми элементами проекта и результатами проекта.
Словарь ИСР содержит подробное описание работы для каждого элемента ИСР .
План управления проектом — общий план мероприятий по исполнению, мониторингу и контролю над проектом, содержащий указания и руководства по составлению плана управления стоимостью и контролю за его исполнением, а также дополнительные планы:
- план управления расписанием ;
- план управления обеспечением проекта персоналом содержит характеристики кадрового обеспечения и тарифные ставки персонала проекта и являются необходимыми элементами при составлении стоимостной оценки расписания;
- реестр рисков — при определении стоимостной оценки учитывается информация, касающаяся реагирования на риски. Риски могут приводить к негативным или благоприятным последствиям, поэтому они оказывают влияние как на плановые операции, так и на стоимость проекта. В случае возникновения негативного риска стоимость проекта может увеличиться.
Инструменты и методы, используемые для оценки стоимости
В зависимости от стадии проекта, необходимой степени точности, возможных расходов и трудозатрат применяются различные типы оценок стоимости .
Оценка сверху-вниз применяется на ранних стадиях в условиях недостаточной информации о проекте. Производится только одна оценка стоимости всего проекта на самом верхнем уровне. Такая оценка не требует много усилий, но имеет низкую точность.
Оценка по аналогам представляет вид оценки сверху-вниз. При этом используется фактическая стоимость ранее выполненных проектов для оценки текущего проекта. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта . Оценка по аналогам не требует много усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимость подготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта.
Оценка снизу-вверх применяется на этапе подготовки базового плана проекта и формировании контрольной оценки. Процесс начинается с оценки деталей проекта с последующим суммированием деталей на итоговых уровнях. Степень точности оценки зависит от уровня детализации ИСР . Оценка снизу-вверх обеспечивает точность от +0,15/-10% до +5%/-5%, но имеет высокую стоимость (от 0,45% до 2% от общей стоимости проекта) и продолжительность.
Параметрическая оценка применяется на ранних этапах проекта . Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода: для оценки стоимости проекта достаточно знать «ставки» привлекаемых ресурсов: недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической оценки составляет 0,04%-0,45% от общей стоимости проекта.
Контрольные оценки представляют собой разновидность оценок снизу-вверх [ 10 ] . В качестве уровня детализации для выполнения оценки стоимости используется ИСР . Контрольная оценка основана на принципе более детальной оценки снизу-вверх. При оценке затрат на работы проекта, как правило, определяют наиболее вероятное значение затрат, затраты при благоприятных и неблагоприятных обстоятельствах, то есть оптимистическую, пессимистическую и наиболее вероятную оценку. Для расчета математического ожидания и среднеквадратичного отклонения применяют формулы, которые используются в методике PERT :
Математическое ожидание = [оптимистическое + пессимистическое + (4x наиболее вероятное)]/6
Среднеквадратичное отклонение = (пессимистическое — оптимистическое)/ 6 1 Предполагается, что читатель знаком с основами статистики.
Контрольные оценки обладают высокой точностью, применяются для формирования базового плана проекта, но их выполнение продолжительно и стоит довольно дорого.
Выходы процесса стоимостной оценки
Оценка стоимости операции — количественная оценка примерной стоимости ресурсов, необходимых для выполнения плановых операций. Она может предоставляться в сжатой форме или развернуто. Затраты оцениваются по всем ресурсам, использованным в оценке стоимости операции.
Вспомогательные данные , на основании которых была произведена стоимостная оценка , должны содержать описание содержания работ проекта для плановой операции:
- документацию того, как оценка получена;
- документацию обо всех допущениях, сделанных для оценки;
- документацию обо всех ограничениях.
Запрошенные изменения. При составлении стоимостной оценки может возникнуть необходимость запроса изменения на требования к ресурсам операции и на другие элементы плана управления проектом . Запрошенные изменения обрабатываются установленным образом, и в процессе общего управления изменениями вносятся соответствующие коррективы в план.
План управления стоимостью (обновления). Если в процессе составления стоимостной оценки появляются одобренные запросы на изменение и если эти одобренные изменения влияют на управление стоимостью , то происходит обновление элемента плана управления стоимостью .
Источник
