Как составить модель оценки

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

• Что такое финансовая модель
• Для чего нужна финансовая модель
• Структура финансовой модели
• Разработка финансовой модели: основные рекомендации
• Совет эксперта

Принцип построения всех типов финансовых моделей одинаковый

2. Оценить стоимость компании
Поглощение, слияние, покупка готового бизнеса — прежде чем проводить такие сделки, составляют финансовую модель компании, которую собираются приобрести. Это позволяет понять, какую сумму или условия предлагать на переговорах. Если расчёт показал, что компания стоит 100 млн ₽, вокруг этой цифры и будет строиться переговорный процесс.

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

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

К оценке стоимости компании применяются те же подходы, что и к оценке инвестпроектов. Можно сказать, что стоимость компании равна стоимости всех её проектов.

3. Спрогнозировать динамику котировок ценных бумаг
Инвесторы и аналитики фондового рынка разрабатывают финансовые модели, чтобы сравнить стоимость компании и её акций, например, сейчас и через год, и принять решение — покупать или нет.

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

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

Выручка. В этом подразделе содержится информация о предполагаемом сбыте: сколько тонн муки производить, какого сорта, по какой цене продавать, в какие города и страны будут идти поставки. Например, предприниматель планирует выпускать пшеничную и ржаную муку двух сортов, а ещё кукурузную и безглютеновую. Стоимость одной тонны муки высшего сорта — 20 000 ₽, объём производства — 120 000 тонн в год, география поставок — по всей России.

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

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

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

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

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

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

Баланс. Этот отчёт формируется на основе двух предыдущих, исходя из остатков на конец периода по денежной задолженности, по капиталу, по кредиторской задолженности.

Именно оценка эффективности проекта помогает принять решение — вкладывать в него деньги или нет

Предположения, сделанные на этапе планирования, могут не сбыться на 100%. К примеру, изначально инвестор рассчитывал продавать по 3 000 тонн муки в месяц, но как будет складываться ситуация через 2–3 года и сколько реально муки он сможет продавать, не ясно. Чтобы учесть все возможные риски, проводят анализ чувствительности проекта. Он позволяет рассчитать, какой будет эффективность проекта, если инвестиции вырастут в 1,5 раза или объём продаж получится на 20% меньше запланированного. Проверка подобных предположений даёт возможность понять, какие риски могут существенно повлиять на ключевые показатели эффективности. А дальше у инвестора есть два варианта: искать способы снизить риски или отказаться от проекта, если они слишком велики.

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

Совет эксперта

Артём Анилов
Построение финансовой модели — это технический навык, который можно и нужно совершенствовать. С первого раза не у всех получается сделать всё идеально, для этого нужны опыт и насмотренность. Придумать самостоятельно хорошую финмодель сложно. Можно попросить наставников или старших коллег поделиться удачным примером, чтобы изучить его и понять, что и как нужно делать. И, конечно, важно больше практиковаться. Тем, кто видит финансовую модель в первый раз, таблица кажется очень сложной, но если постепенно и вдумчиво изучить каждый раздел, всё получится.

Фото: zeljkosantrac / Getty Images

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Финансовая модель — инструмент для управления бизнесом или проектом. С её помощью прогнозируют развитие компании и оценивают эффективность принимаемых решений.

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

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

В статье разберёмся:

• что такое финансовая модель и для чего она нужна;
• с помощью каких инструментов можно построить финмодель;
• какие показатели она включает и по какой форме её составляют;
• как разработать хорошую финансовую модель;
• как узнать больше о финансовом планировании бизнеса.

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

Финансовая модель помогает:

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

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

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

Как строят финансовые модели? Обычно финансовые модели собирают в Microsoft Excel или «Google Таблицах». Некоторые компании используют для этого специализированные программы. Как правило, эти программы заточены под одну цель.

Основное преимущество Microsoft Excel или «Google Таблиц» — их гибкость. С помощью формул можно смоделировать и рассчитать любые сценарии. Также они позволяют настроить отображение результатов в удобном формате.

Финансовые модели бизнеса или проектов необходимы внутренним и внешним пользователям.

Внутренние пользователи — собственники компании и менеджеры. С помощью финмодели они могут:

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

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

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

Мы определили, что такое финансовая модель и чем она полезна бизнесу. Дальше разберём, какие показатели она в себя включает и по какой форме её составляют.

Финансовые модели в компаниях и проектах могут быть разными, но, как правило, структура у них одна. Все финмодели состоят из трёх блоков: входные данные, расчёты и выходные данные.

Блок входных данных. В эту часть вбивают все данные для расчётов, которые нужно заложить в модель.

Основные показатели, которые нужно сюда включить:

• капитальные вложения — например, затраты на покупку недвижимости, оборудования, транспорта с учётом амортизации;
• расходы компании — например, на аренду, зарплаты сотрудникам, закупку материалов, маркетинг, услуги подрядчиков, платежи по кредитам, налоги;
• прогнозы финансовых показателей — например, количество покупателей, размер среднего чека, прогноз изменения цен;
• финансирование — например, вложения собственников, инвесторов, кредиторов.

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

Входные данные можно менять, объединять в сценарии — рассчитывать модель сразу в нескольких вариантах.

Блок расчётов. Этот блок связывает формулами все параметры, которые задали в блоке входных данных.

Здесь проводят все необходимые расчёты. Цель — получить итоговый прогноз операционной и чистой прибыли компании.

Для внешних пользователей финмодели блок расчётов может быть «чёрным ящиком» — они не обязаны разбираться в том, как работает финансовая модель. Главное, что нужно понимать, — изменение входных данных влияет на выходные данные через формулы блока расчётов.

Блок выходных данных. Этот блок собирает все данные, которые получили в блоке расчётов, и показывает результаты.

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

Подробно о том, как составлять финмодели, проводить их анализ и интерпретировать результаты,  — на курсе Skillbox «Финансовое моделирование».

Здесь можно посмотреть и скачать упрощённый шаблон финансовой модели от сервиса «ПланФакт».

Более развёрнутую форму финмодели разработали в «Нескучных финансах». Её можно посмотреть и скачать здесь.

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

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

• Чётко обозначьте, где входные данные, где расчёты, а где выводы. Для этого в электронных таблицах удобно использовать разные листы и разноцветные ярлыки для них.
• Внутри блока делайте отдельные разделы для каждой области вводных или расчётов. Например, выручку лучше считать не в том же разделе, в котором считали расходы.
• Не используйте одну и ту же строку модели для разных данных. По возможности соблюдайте принцип: «одна строка — одна формула». Это позволит растягивать формулы на любые периоды.
• Если под данные каждого месяца отводится отдельный лист, используйте одну структуру колонок для всех листов. Один и тот же показатель на разных листах должен находиться в одном и том же столбце. Это также упростит расчёты в следующих периодах.

• Все строки и столбцы должны быть подписаны. Любой пользователь должен понимать, о чём идёт речь в каждом блоке.
• Не забывайте оформлять блок расчётов. Чаще всего внешние пользователи изучают только блоки входа и выхода. Но в некоторых случаях — например, при выдаче кредитов или долгосрочном финансировании — пользователей может заинтересовать, каким образом компания пришла к таким цифрам. В этом случае блок расчётов будет для них самым интересным, поэтому все данные в нём должны быть также подписаны.
• Указывайте единицы измерения каждой величины. Хотя бы там, где могут возникнуть сомнения.
• Числа в модели должны иметь 3–4 значащие цифры — остальное лучше убрать с экрана. Для этого используйте форматирование ячеек — не нужно менять значения ячейки вручную или с помощью формул.
• Визуально отделяйте блоки друг от друга заголовками и «подсвечивайте» важные строки отдельными цветами. Лучше всего использовать для этого стили отображения таблиц.

• Не стремитесь рассчитывать показатели максимально точно. У финмодели нет цели отразить реальность на 100%. При необходимости точность расчётов можно будет увеличить на более поздних этапах.
• Не используйте сложные формулы. Модели с простыми формулами проще читать самим и проще объяснять другим.

• Финансовая модель — таблица, в которой объединены показатели доходов, расходов и прибыли компании. Она показывает связь между ними и помогает прогнозировать развитие компании, оценивать эффективность принимаемых решений.
• Финмодели используют как собственники и управленцы компании, так и внешние пользователи — например, банки, инвесторы и контрагенты.
• Чтобы финансовой моделью могли пользоваться все заинтересованные лица, важно позаботиться о её читаемости и простоте.
• Единой структуры у финмоделей нет. Каждая компания может разработать свою форму.
• Чаще всего финансовые модели собирают в Microsoft Excel или в «Google Таблицах».

• Если вы только начинаете разбираться в финансовом планировании, прочитайте нашу статью — «Главное о финансовом планировании: зачем оно нужно и как компании планируют бюджеты».
• Научиться анализировать финансовое состояние бизнеса и оценивать инвестиционные проекты можно на курсе Skillbox «Профессия Финансовый менеджер».
• Научиться составлять финансовые модели для компаний из разных отраслей, проводить финансовый анализ и интерпретировать результаты можно на курсе Skillbox «Финансовое моделирование».
• Ещё в Skillbox есть курс «Финансы для предпринимателя». Подойдёт тем, кто хочет создать прозрачную систему финансов компании, понимать, на что идут расходы и сколько зарабатывает бизнес.

Научитесь: Профессия Финансовый менеджер
Узнать больше

Цели и задачи разработки финансовой модели предприятия

Методика построения финансовой модели предприятия

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

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

В качестве вспомогательного материала к этой статье используйте расчетные таблицы в Excel, представленные в нашем «Сервисе форм». Их вы тоже можете применить в своей работе.

Цели и задачи разработки финансовой модели предприятия

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

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

Бизнес-план почти всегда используется для обоснования выгодности совершаемых инвестиций в развитие бизнеса компании. Он состоит из несколько разделов. В одном из разделов приводятся расчеты финансовых результатов, денежных потоков и сроков окупаемости необходимых для реализации бизнес-плана инвестиций. Поэтому финансовый раздел бизнес-плана может охватывать как общие (если цель инвестиций — расширить или модернизировать существующее направление бизнеса), так и локальные (например, если цель инвестиций — запустить новое направление бизнеса) объемы деятельности компании.

Финансовая модель предприятия служит в первую очередь инструментом прогнозирования и моделирования результатов бизнеса и помогает собственникам и руководству:

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

• оценить, как повлияет на финансовые результаты и состояние компании изменение объемов реализации в большую или меньшую сторону;

• рассчитать, как запуск нового направления бизнеса или выпуск нового вида продукции повлияют на общие финансовые результаты и состояние компании;

• просчитать влияние тенденций прошедшего периода в развитии бизнеса на финансовые результаты и состояние компании в будущем периоде;

• оценить, насколько устойчив бизнес компании к действиям конкурентов или изменениям законодательства;

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

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

Обратите внимание!

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

В то же время в любой финансовой модели предприятия должны присутствовать следующие разделы:

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

Для заполнения разделов финансовой модели используются следующие источники информации:

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

• в прогнозе прямых затрат на выпуск продукции фиксируют данные о необходимом для выполнения плана продаж объеме выпускаемой продукции, количестве и сумме расхода сырья и материалов на выпуск продукции, а также фонде заработной платы (зарплата плюс отчисления в внебюджетные фонды) производственного персонала, занятого непосредственно выпуском продукции;

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

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

Маржинальная прибыль = Сумма реализации – Сумма прямых затрат;

Операционная прибыль = Маржинальная прибыль – Сумма накладных затрат;

Прибыль до налога = Операционная прибыль – Расходы на обслуживание кредитов – Внереализационные расходы + Внереализационные доходы;

Чистая прибыль = Прибыль до налога – Налог на прибыль;

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

Методика построения финансовой модели предприятия

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

Рассмотрим порядок расчетов на каждом этапе построения финансовой модели.

Этап 1. Сформируйте прогноз продаж

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

Этот объем можно рассчитать одним из двух способов:

• суммируя объемы в детализациях периода (если продажи считают как сумму объема прошлого отрезка периода, измененную на коэффициент роста/падения продаж в следующем отрезке периода);

• распределяя годовой объем продаж на периоды пропорционально сезонности покупательского спроса (если продукция компании подвержена сезонным колебаниям спроса).

Далее спрогнозируйте цену реализации единицы продукции с учетом планов компании по повышению или понижению отпускной цены в прогнозируемом периоде.

И в завершение рассчитайте суммы реализации продукции, умножив количество единиц на цену реализации единицы.

Как сформировать прогноз реализации продукции, покажем на примере производственного предприятия «Дельта», выпускающего три вида продукции. Прогноз реализации продукции этого предприятия на 2023 г. в поквартальной детализации приведен в табл. 1.

При составлении прогноза учитывались:

• фактор сезонности спроса на продукцию предприятия, на основании которого годовые объемы продаж были распределены по кварталам года;

• фактор повышения цен реализации продукции.

Этап 2. Сформируйте прогноз объема выпуска продукции

Чтобы сформировать прогноз необходимого для обеспечения продаж плана выпуска продукции в натуральных единицах, нужны данные плана продаж (см. табл. 1) и значения норматива остатков ГП на складе, который удобнее всего считать в днях реализации. Нормативный остаток запаса готовой продукции в натуральных единицах определяется по формуле:

Нормативный остаток запаса готовой продукции = (Плановый объем продаж ГП предстоящего периода / Количество дней предстоящего периода) × Норматив запасов ГП в днях.

Рассчитав нормативные остатки запаса готовой продукции на складе, переходим к расчету необходимого выпуска продукции:

Плановый объем выпуска ГП = Плановый объем реализации ГП за период + Нормативный остаток запасов ГП на конец периода – Нормативный остаток запасов ГП на начало периода.

Результаты расчета плана выпуска продукции для предприятия «Дельта» сведены в табл. 2.

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

Этап 3. Сформируйте прогноз прямых затрат на сырье или покупные товары

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

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

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

1. Базовая теория

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

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

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

2. Метод оценки — Декомпозиция

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

Конечно, на начальных этапах проекта данный метод будет менее точным, чем на последующих.

Ниже приведён пример таблицы для декомпозиции задач:

В неё можно добавить дополнительные аналитики, например:

• грейд сотрудника (junior, middle, senior — т.к. от грейда будет зависеть ставка).

• Локация сотрудника (Москва, СПБ, Екатеринбург и т.д.)

• Подразделение сотрудника

• Риски (описание возможных рисков)

• Сложность задачи

• Важность задачи

• и т.д.

Приведённая выше таблица не является исчерпывающей. Вы можете добавлять в неё любое количество аналитик, которое потребуется. Я специально не использую термин ИСР (Иерархическая структура работ) или WBS (Work Breakdown Structure) т.к. для большинства специалистов он ассоциируется с планированием работ, хотя на самом деле инструмент многоуровневой декомпозиции нужен именно для оценки. Он не включает в себя календарное планирование (календарные сроки выполнения работ). Для календарного планирования правильно использовать другой инструмент — план-график проекта. К тому же, если мы говорим про гибкие подходы к разработке, то детальных план-графиков может не быть, планирование происходит по другому (спринты, канбан и т.д., другие словами итеративное планирование и выполнение задач), при этом метод декомпозиции всегда будет актуален.

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

Упрощённый список основных видов затрат для ИТ-проектов (для примера):

Ключевой вопрос при декомпозиции — как сильно надо детализировать? т.е. на насколько мелкие задачи необходимо разбивать? На старте проекта важно учесть все задачи, которые влияют на scope (содержание) проекта, при этом понимая, что со временем требования будут детализироваться и оценку потребуется уточнять, сверять с бизнес-целями.

На картинке ниже продемонстрировано, как снижается неопределённость по мере детализации требований.

3. Метод оценки — Расчёт по метрикам и сравнение исторических данных

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

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

Примеры метрик, которые могут быть использованы для оценки объёма работ и стоимости разработки:

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

При использовании метода расчёта по метрикам очень важно понимать какие проекты сравнивать. Многое зависит от языка разработки и стека технологий. Например, надо очень осторожно сравнивать показатели из проекта на Платформе 1С и проектов на open source технологиях, даже если бизнес задача идентичная (что маловероятно, но для простоты примера). А вот если сравнивать проекты на базе 1С с другими проектами на 1С (при условии схожести задачи), тогда точность оценки на базе метрик будет высокой.

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

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

3.1. Определение размера программного продукта

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

Системные метрики, например:

1. Модули системы (если они системно разделены)

2. Веб-страницы, пользовательские окна (интерфейс)

3. Классы

4. Компоненты системы

5. Таблицы базы данных

6. Строки кода (LOC)

Функциональные метрики, например:

1. Функции системы

2. Систематизированные требования к системе (если у требований есть чёткая классификация)

3. Сценарии использования (Use Case)

4. Пользовательские истории (user story)

5. Количество запросов от пользователей

6. Количество запросов по API

Функциональные метрики (функционально-ориентированные метрики) позволяют измерять программный продукт, процесс его разработки с помощью классификации и разделения функционала.

Системные метрики (размерно-ориентированные метрики) позволяют достаточно точно измерить программный продукт и процесс его разработки с помощью системных артефактов. Самый популярный и всем известный пример размерно-ориентированной метрики это — LOC (Lines Of Code) количество строк кода в программном продукте.

Для разных программных продуктов будет правильно использовать разные системные и функциональные метрики, например для относительно простых сайтов подойдут — веб страницы. Для систем, которые чётко разделены на разные функции — функции системы. При этом стоит использовать несколько метрик сразу (например, таблицы БД, строчки кода и функции).

Ниже приведён достаточно простой пример определения средней стоимости, качества и производительности на основании количества строк кода.

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

Производительность = Длина тысяч LOC / затраты чел.мес

Качество = Кол-во ошибок / Длина тысяч LOC

Средняя стоимость = Стоимость (млн. руб.) / Длина тысяч LOC

Документированность = Кол-во страниц документации / Длина тысяч LOC

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

3.2. Использование поправочных коэффициентов

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

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

4. Метод оценки — Экспертный

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

Есть несколько основных правил использования данного метода:

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

2. Существенную пользу принесёт подготовка чек листов для всех участников. Это поможет не упустить важные моменты и повысить точность. Чек листы будут очень сильно отличаться в зависимости от типа задачи, поэтому следует попросить экспертов самостоятельно составить их.

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

В экспертной оценке часто используют метод PERT (Program Evaluation Review Technique). Идея PERT заключается в определение ожидаемой оценки на основании оптимистичного, среднего и пессимистичного сроков выполнения задачи. Вот, как это выглядит:

Формула для расчёта:

PERT = (Оптимистично + (4 * Наиболее вероятно) + Пессимистично)/6

5. Другие модели и подходы к оценке

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

5.1. Косвенные оценки

Данный метод предполагает использование связанных показателей для оценки задачи. Например, у вас есть информация, что один тестовый сценарий на аналогичном проекте выполняется за 2 часа, но нет понимания, сколько этих тестовых сценариев будет. Самый простой способ, это посчитать их относительно количества сформулированных требований (например, user story) или количества запросов на изменение.

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

5.2. Специальные системы для проведения оценок

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

5.3. Покер планирование (или Scrum Poker)

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

5.4. Модели оценки (стандарты)

Есть несколько, если можно так выразится, стандартов по проведению оценки стоимости проектов по разработке ПО:

• Модель Oracle AIM для оценки трудоёмкости. Она основании на полном и точном знании процесса, а также крайне глубокой декомпозиции.

• Модель СОСОМО (и СОСОМО II) — сложная модель оценки разработанная ещё в 70-х года, которая устанавливает соответствие между размером системы в тысячах условных строк кода, типом проекта и трудоемкостью разработки системы.

  Немного более современные модели IFPUG FPA и FPA mkII, в них были введены понятия транзакции, а также репозитория кода.

• ГОСТы:

  ГОСТ Р 58302-2018 управление стоимостью жизненного цикла. Номенклатура показателей для оценивания стоимостижизненного цикла изделия.

  ГОСТ Р 56136-2014 управление жизненным циклом продукции военного назначения. Термины и определения

  ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения(square).

6. Ключевые ошибки при проведении оценок

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

Оценки с запасом. Часто сотрудники берут немного времени «про запас» т.е. сверху и дают завышенную оценку.

Интуитивные оценки. Лучше потратить 10 минут на анализ задачи, её детализацию и уточнение, а потом уже давать оценку. Интуитивные оценки чаще всего ведут к нарушению сроков и увеличению стоимости.

Оценка ради бизнес-цели. Когда оценку даёт человек, который заинтересован в выполнении бизнес-цели. Желание выполнить поставленную цель не является плохим явлением, но очень важно давать объективные оценки (особенно, если это касается заказчика или вывода продукта на рынок).

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

Косвенные затраты и задачи. Не весь объём задач по разработке системы учитывается при оценке. Часто это бывает из за недостаточности проработанной бизнес модели, бизнес требований или отсутствие проектирования.

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

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

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

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

• Упрощённый и недостаточный анализ требований.

• Отсутствие вовлечённости бизнес пользователей и заказчика.

• Упрощённое проектирование и отсутствие подходов к разработке, качеству написания кода.

• Отсутствие подходов к тестированию или тестирования в целом.

7. Итог

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

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

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

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

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

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

Рис.
4.7 Отношения между эталонной моделью,
моделью оценки и методами оценки.

Структура
и принципы модели оценки

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

Модель
оценки расширяет эталонная модель,
добавляя определение и использование
показателей оценки (см. рис.4.8). Показатели
оценки – объективные атрибуты или
характеристики метода или рабочего
продукта, которые поддерживают решения
асессора о выполнение и возможности
оцениваемого процесса.

Измерение
возможности

Уровни
возможности

Атрибуты
процесса

Показатели
возможности

процесса

Метод
управления

Показатели
атрибутов

Эталонная модель Модель оценки

Показатели
выполнения

метода

ИЗМЕРЕНИЕ
ПРОЦЕССА

Категории
процесса

Процессы

Показатели
исполнения

процесса

Базовый
метод

Рабочие
продукты и

характеристики

Показатели оценки

Рис.
4.8 Связь между эталонной моделью и
моделью оценки.

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

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

характеристики
исполнения метода, которые обеспечивают
управление в реализации метода;

ресурсы
и характеристики инфраструктуры, которые
обеспечивают механизмы для помощи
управления процессом;

процессы,
связанные с измерением процесса, которые
поддерживают метод управления.

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

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

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

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

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

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

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

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

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

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

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

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

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

Эта
модель оценки представляет набор
показателей, чтобы формировать основу
такого набора зарегистрированного
доказательства. Показатель определен
как целевой атрибут или характеристика
метода или рабочего продукта, которое
поддерживает решение исполнения или
возможности, осуществленного процессом.
Из этой области определения, два различных
класса показателей могут быть
идентифицированы: показатели выполнения
процесса и показатели возможности
процесса. Внутри контекста этой модели,
эти типы показателей касаются,
соответственно, базовых методов,
определенных при измерении процесса,
и методов управления при измерении
возможности. Классы и типы показателей,
их отношение к выходу оценки, показаны
на рис. 4. 9.

Соседние файлы в папке ТЕКСТЫ для лабработы 2

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #