Основные показатели эффективности проекта: описание и расчет

Привлекайте к оценке членов команды и помните об их потенциале

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

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

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

Познакомьтесь с процессами управления проектами в компании

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

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

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

Расширяйте кругозор

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

Относитесь к ошибкам, как к возможности научиться чему-то новому.

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

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

Ознакомьтесь с проектной историей своей команды

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

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

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

Задавайте больше «правильных вопросов»

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

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

Примените иерархическую структуру работ

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

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

Надеюсь, эта статья оказалась для вас полезной.

Алгоритм подготовки и расчета показателей

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

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

Бонус

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

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

А если мы не представляем точно, какой есть запас (и руководствуемся, что он большой, и «государство не обеднеет») — получается неконтролируемое превышение сроков. И уже неважно, какой буфер заложили: 2x, 5x, 100x — если им не управлять, он все равно весь будет съеден.

Виды показателей эффективности

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

Но центральное место в них занимает теория и практика инвестиционного анализа, который также подвержен эволюции в направлении системного подхода. Фундаментальное значение имеют Методические рекомендации по оценке эффективности инвестиционных проектов (II-ая редакция), выпущенные в середине 1999 г.

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

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

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

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

Локальным показателям эффективности инвестиций (NPV, PI, IRR, MIRR, PP, DPP) на нашем сайте уделено подробное внимание в отдельных тематических статьях. Виды эффективности ИП нами были охарактеризованы в материале, посвященном коммерческой эффективности инвестиционного проекта.

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

Зачем давать оценки

В жизни каждого разработчика наступает тот неприятный момент, когда к нам приходят «они» и требуют: «когда будет готово?». «Они» — это менеджеры, продакты, тимлиды, начальники… Вопрос, а зачем это «им»? Что «они» будут с этим делать? Если мы это поймём, то сможем давать им ровно то, что им нужно, и экономить свое время.  Вариантов несколько, и вот основные из них.

• Менеджеру нужно оценить скоуп работ (поставка, релиз, спринт): календарный график и общий их объем. В этом случае важно попасть в суммарную оценку, попадание в каждую конкретную задачу неважно (где-то потратили больше, где-то меньше — в целом сошлось). В дальнейшем от этого планируется работа других подразделений, а также от этого зависят показатели, которыми управляет бизнес. А бизнесу нужна предсказуемость: для уменьшения рисков и повышения управляемости.
• Выстраивание приоритетов в уже существующем скоупе. В этом случае важны оценки каждой задачи, потому что от них может зависеть последовательность работ. Далее менеджер может выстроить последовательность по методике ценность/сложность. Например, в самом простом случае, можно оценить задачи по трёхбалльной шкале (высокая, средняя, низкая) по ценности для бизнеса и сложности для выполнения. И затем выстроить приоритеты так: сначала делаются очень ценные и очень быстрые, потом очень ценные и средне-быстрые и так далее. Малоценные и очень сложные задачи формируют вечный бэклог, откуда выбираются очень долго. Или никогда.
• Оценка проекта (или большого подпроекта целиком). Этот случай характеризуется многими неизвестностями, поэтому оценка нужна примерная. Не стоит пытаться раскладывать на мелкие подзадачи с деталями, потому что данных об этом все равно нет: никто на этом этапе не знает, что точно нужно сделать. Далее на основании этих оценок принимается решение, какие задачи оставить/убрать, какие отложить, какие действия предпринимать прямо сейчас (запуск сложных рискованных процессов), чтобы уложиться. Здесь же идёт планирование затрат (время, ресурсы, определение размеров команды), построение примерных диаграмм Ганта и прочая подобная деятельность.

Хорошо, зачем это «им» разобрали. А нужно ли это «нам»? Представьте себе, что ваш менеджер ушёл в отпуск. Навсегда. И вот вы сидите, спокойно работаете, день, два, неделю. Никто оценок не требует, жизнь удалась. Будете ли давать оценки самому себе?

Давать их или нет — дело личное, но вот аргументы за.

• Оценка показывает способ выполнения задачи. Человеческий мозг — штука затратная, и думать человек не любит — это сложно. Поэтому естественное стремление думать как можно меньше. А как это сделать? Можно разделить деятельность на более узкую. Делим планирование и исполнение: сначала думаем о способе (при оценке), потом переключаемся на исполнение и думаем об исполнении (в процессе работы). 
• Создаем себе рамки, «скелет» плана. Если заметили, что вываливаемся из плана — это повод прекратить исполнение и сесть подумать. Таким образом мы можем себя контролировать, соответствует ли наше ожидание (оценка) реальности (попаданию в оценки) или реальность другая, и первоначальный план не подходит. Помогает принимать решения, если в процессе что-то пошло не так. 
• Если у нас нет оценок — мы не можем планировать свою работу. Без оценок единственное на что мы можем ответить — в каком порядке будем делать задачи. Непонятно, когда можно расслабиться, а когда наоборот этого делать нельзя. Проиллюстрируем примером. У вас есть несколько источников задач, все разной степени срочности и сложности. Приходит к вам очередной коллега и просит сделать небольшую вещь через 2 недели. Ну 2 недели срок приемлемый, вещь небольшая —  вроде норм, согласен. Оценок не даем. И со временем обнаруживаем, что целыми днями заняты, выбиваемся из сил — и все равно ничего не успеваем. Задачи вытесняют друг друга, перестают доходить до конца, новые все пребывают — и вы попадаете в замкнутый круг. Начинаются отрицательные эмоции (обвинение других/себя), это мешает работать и очень ест силы. И уже коллега, который пришел с очередной небольшой задачкой, получает ответ: «Я занят, у меня куча дел!!». Удовлетворение от работы на нуле, сил нет, результата нет. Почему так произошло? Потому что не планировали свою загрузку. Не смогли сказать очередной задаче «нет», потому что сами не знали, что не сможем ее выполнить. Не смогли понять, что сейчас есть возможность снизить темп и отдохнуть, потому что задачи идут одна за одной — и без каких-либо границ.
• Психологический эффект. Если задача сложная, меняется в процессе разработки или меняются наши знания о ней. Если мы не давали исходную оценку, задача в процессе обросла новыми подробностями, и в результате мы не попали — мы не помним, почему. Через несколько таких итераций в голову стучится эффект самозванца. А если бы дали изначальную оценку, то причина зафиксирована: считали, что надо 5 попугаев, а оказалось 10. Почему так оказалось — вопрос второй, его-то как раз хорошо помнят. А причину — не всегда («Разработчики вечно ничего не успевают»/«Эти продакты вечно ничего не могут продумать, а потом всплывает»).

Подготовительные мероприятия к расчетам

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

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

Порядок выполнения оценки эпика

Схема рождается из того, что

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

Пример 11.1. ооо «белый свет»

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

Расчёт показателей коммерческой эффективности проекта

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

Расчет чистой текущей стоимости произведен по формуле:

где,

В общем виде расчёт показателей эффективности проекта приведён в следующей таблице.

Таким образом, проект обладает следующими основными показателями эффективности:

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

Кроме того, в состав доходов предприятия включены доходы от реализации НИОКР для ЗАО «Транс-Сигнал» (г. Нижний Новгород), поскольку, в отличие НИОКР для Фонда, данный НИОКР фактически является оказанием платных услуг, осуществляемых инициаторами проекта Заказчику.

Рентабельность текущей деятельности

В данном пункте приводятся сведения о рентабельности текущей деятельности предприятия по годам реализации проекта. Показатели рентабельности приведены в следующей таблице (Табл. 11.8).

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

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

Значения показателей эффективности проекта свидетельствуют о его высокой эффективности.

Срок окупаемости проекта менее 4-х лет.

Рентабельность текущей деятельности высока.

Пример 11.2. финансовая состоятельность проекта.

С самого начала проверим соответствие нашего баланса золотому правилу финансирования (горизонтальная структура).

Собственный капитал > внеоборотных активов (

5326 : 4440 = 1,20 , что больше единицы.

Или

(5326 1500)/4440 1059 = 1,24

Этот показатель положительно характеризует структура баланса, так как коэффициент покрытия больше 1.0

Далее более подробно рассмотрим показатели устойчивости.

Исходя из полученных показателей можно сделать вывод о финансовой устойчивости предприятия в 2007 году -коэффициент равен 0,8,в 2008 — 0,9 ,при нормативе от 0.8 до 0.9., одновременно предприятие финансово независимо ,так как коэффициент финансовой независимости 0.62в 2007 году и 0,82 в 2008 году, что больше нормативного – 0,5.

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

Ликвидность баланса на конец 2007 года выше нормативной и составляет 2,4.

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

Деловая активность предприятия.

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

Коэффициент устойчивости экономического роста рассчитывается следующим образом:

2007 год — Кр=5316:5326 =99,8% ,в 2008 г — 29464/34790=84,69 %

Хотя в процентном отношении в 2008 году процент снизился по сравнению с
2007 году, но в абсолютном выражении все-таки рост существенен.

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

Фондоотдача также повысилась с 2,9 в 2007 году до 5,0 в 2008 году.

В 2007 г. показатель ресурсоотдачи составил 1,41 ,и 1,56 в 2008 г

Темпы роста прибыли в 2007 г по сравнению с 2007 г составляют 29464/ 5316= 554%

Темпы роста объема продаж 66003:12000 = 550%

Темпы роста валюты баланса 42340 / 8530 = 496%

Золотое правило экономики

В нашем случае 554 >550 >496 > 100%

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

Оценка рентабельности

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

Чистый объем продаж 2007 г- 12000 тыс.руб ,2008 год- 66003 тыс.руб

Чистые операционные затраты- 6477тыс.руб.; 2008 год-26347 тыс.руб

Чистая прибыль 2007 года- 5316 2008 -го-29464

Среднесписочная численность — 2007 — 8,8 чел в т.ч. штатных 2,5 и
2008 г -16,8 чел, в т.ч. штатных — 3,8

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

С использованием модели бизнес-процесса, сформированного в программе «AE-Project», оптимизация бизнеса производится в соответствии с диаграммой, представленной на Рис. 11.4. Начинается процесс со сбора исходных данных, которые формируют характеристики процессов, связанных с выполняемым проектом.

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

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

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

Краткие итоги.

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

Вопросы для контроля:

1. Каким образом в финансовом плане учитывается изменение стоимости капитала во времени?
2. Что такое ставка дисконтирования?
3. Каким образом учитывается поправка на риск?
4. Каково различие в периодах окупаемости – с учетом или без учета ставки дисконтирования?
5. Основные методы вычисления ставки дисконтирования?
6. Различие между планом движения денежных средств и планом доходов и расходов?
7. Связь баланса с планом движения денежных средств и планом доходов и расходов?
8. Основные показатели финансовой эффективности проекта?
9. IRR и его определение?
10. РР и его определение?
11. NPV и его зависимость от ставки дисконтирования?
12. Определение рентабельности основных средств?
13. Ликвидность предприятия?
14. Финансовая устойчивость?

Упражнения

Откройте программу AE-Project и ознакомьтесь с выходными формами «Отчеты» и «Диаграммы». Проведите анализ финансовых потоков проекта. Проведите корректировку финансовых потоков и выпуска продуктов для вывода проекта на удовлетворительные показатели.

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

Процесс оценки

Основа процесса оценки — увидеть стоимость бизнес-задачи, а также основные риски задачи и объем рутины. И затем оценить их, заключив в рамки: точно неизвестно, какое оно, но оно точно больше X и меньше Y. И конечно, оцениваем с той точностью, с которой нужно (потому что точная оценка дорогая, а мозг ленивый).

Состав задачи:

• Реальная бизнес-ценность (зачем задача нужна бизнесу). Минимально допустимый функционал, без которого задача имеет нулевую ценность для бизнеса. Нечто похожее на smoke-test в тестировании. Если мы этого не будем учитывать, можем наткнуться на ситуацию, когда выкатываем задачу, а нам бизнес говорит «она не работает». Как не работает, я же проверял все! Идем дрожащими руками на прод — и все на месте. Показываем бизнесу, а он говорит: «Здесь не хватает такой-то штуки, а без нее мне это не нужно».
• Необходимые дополнительные задачи, которые напрямую в бизнес-ценность не входят, но без них задача не будет работать. «Нагрузка» к бизнес-ценности. Требования юридические, требования интеграций, требования технологические (исполнение архитектуры, покрытие тестами, требования безопасности, требования отказоустойчивости, требования по скорости), согласованность с остальным продуктом — если без них задача не будет принята или не заведется. 
• Риски. Мы чего-то не знаем, не умеем, что-то зависит не от нас. В них оценка может быть в очень широких пределах или мы не знаем, какая она (и сможем уточнить только в процессе). В этом случае разумно попытаться максимально снизить риск на этапе планирования: аналитика разного рода, копание в коде, консультации у экспертов, согласование вопросов с внешними системами (говорим, что нам критично это знать или вот так сделать. Есть и еще один типовой подход — просто переложить ответственность на кого-то другого. Типовые риски: интеграция с внешними системами (особенно неизвестными или под большой нагрузкой, а также если понятно, что система не будет меняться под нас: править баги или консультировать по тому, как работает система, а также, если они только разрабатываются, и есть только документация), зависимость от других подразделений, не заинтересованных напрямую в задаче, новые технологии, новая система (первый день на работе) или часть системы, известная техническая сложность в системе, zero-tolerance к качеству или очень жесткие и неизменяемые требования к задаче, взаимодействие со сложными коллегами, размытые, непонятные или противоречивые бизнес-требования, которые нельзя уточнить. Чтобы упорядочить риски, их оценку можно производить по вероятности (высокий/средний/низкий), по степени влияния (высокая/средняя/низкая). 
• Все остальное.

Процесс оценки конкретной задачи

Хорошо, эпик декомпозировали. А как оценивать размер конкретной задачи?

• Если мы уже делали ровно такую задачу. У нас где-то есть статистика, сколько времени ушло на аналогичную задачу.  Если делали не мы, а коллега — то можем взять его результат и домножить на коэффициент разницы между им тогда и нами сейчас (уровень разработчика, знание системы, знание рисков). Лезем в статистику, домножаем — получаем. 
• Если мы делали примерно такую задачу. Аналогично предыдущему способу, только нужно накинуть примерную разницу между задачами. Например, эта задача совпадает на 60%. Значит, 60% задачи уже мы оценили, оцениваем остаток. Или примерно понимаем, что прошлая задача в полтора раза легче — значит, и оценка будет в 1.5-2 раза больше.
• Если не делали таких задач. Тогда применяем R&D. Если задача мелкая — можно делать исследование сразу, перед оценкой. Если большая — лучше запросить время и делать отдельно. Берем определенное время на аналитику (1, 2, 4 часа), цель которого — дать оценку исходной задаче. Исследуем информацию, разговариваем с экспертами, собираем прототипы на коленке. Если совсем непонятно, сколько времени нужно взять на R&D, то можно взять 1-2 часа на то, чтобы составить план на R&D и его оценить. Тогда цель этого этапа будет — дать оценку R&D. Если надо встретиться и обговорить что-то — время встречи, например, час. Если написать прототип — то N строчек — примерно столько-то (в зависимости от сложности). Если прикинули, взяли и не хватило времени — хотя бы можно сравнить, что мы успели и что хотели. И, разделив одно на другое, получить коэффициент — на него умножить исходное время.

Полезные техники при оценке:

• Обычно разработчики склонны переоценивать проблемы, с которыми они уже сталкивались (и которые есть в задаче) и недооценивать те, которые они видят, но не сталкивались. Это психологическая особенность человека, и о её наличии просто нужно знать, чтобы корректировать себя.
• Planning poker. Оцениваем вместе, используем опыт коллег. Цели две: во-первых, фиксируем внутри команды один способ выполнения задачи и, соответственно, одну оценку, а во-вторых, смотрим на задачу вместе, подстраховывая друг друга,
• Риски можно классифицировать по таблице (вероятность/степень воздействия), оценить коэффициентами и получить в числах. А затем домножить оценки на эти коэффициенты. Например, этот риск средней степени вероятности и разрушительного воздействия. Поэтому берем докидываем в задачу, например, еще 70% на него.
• Оценка ожидаемого времени задачи из PERT. Удобно использовать, если границы вилки (минимум-максимум) по задаче различаются в 5 и более раз. В этом случае простое среднее может быть далеко от реальности.

  Здесь минимум — минимальное возможная длительность выполнения задачи в предположении, что всё происходит наилучшим или наиболее удачным образом, максимум — максимально возможная длительность выполнения задачи в предположении, что всё происходит наихудшим или наименее удачным образом (исключая крупные катастрофы), реализм — длительность выполнения задачи в предположении, что всё происходит так, как бывает чаще всего (как обычно).
  Тогда итог считается как:
  

Коэффициенты 4 и 6 взяты, как я понимаю, из предположения, что в общем случае вероятность риска распределена нормально, и хвосты (min/max) равновероятны.

Процесс попадания в оценки

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

Полезные техники при попадании:

• Декомпозиция на подзадачи не более 6ч. Смысл этого действия: каждый день должна закрываться одна задача. Если не закрылась — это сигнализирует о том, что что-то не так, и разработчик застрял. Надо обратить внимание или менеджеру/лиду, или самому разработчику. Также подобная декомпозиция сужает область деятельности (в рамках такой задачи сложнее «расползтись» или заняться чем-то другим). Например, делали задачу, увидели старый костыль или что-то в результате реализации стало слишком неоптимальным или запутанным. Поставили отдельную задачу и забыли — сейчас цель заниматься основной задачей. Также есть и психологический эффект в виде положительного подкрепления. Зачем сегодня на работу ходил? Сделал задачу N.
• Выстраиваем «ёлку».
• Прикидываем, сколько времени на минимум (бизнес-ценность риски) — минимальное время, которое нам надо на задачу. В моём опыте это обычно составляет около 30%.
• Делаем.
• В процессе отслеживаем план, зачеркиваем (либо другим способом помечаем) выполненные задачи. Как только с начала задачи прошло минимальное время (которое определили два пункта назад) — проверяем, отклонились ли от плана. Если да — повод подумать, ну или сразу бить в набат. Если оценка превышена — скорее всего, она будет превышена и в оставшихся задачах. И пока еще есть время перепланировать работу.
• Приступаем к остальным задачам (не из минимума). И на середине работы общее время внезапно заканчивается. Конечно, у нас есть возможности превысить оценку, попросить еще времени, попросить добавить разработчиков и прочее. Это рабочие способы, но сейчас вопрос в том, какие у нас есть возможности уложиться в исходную. Бессмысленно пытаться «программировать быстрее» — это даст ускорение всего на 20-30%, максимум на 50. Недостающее время отпиливаем от нижней части. Автоматически получаем (и можем эскалировать наверх) прогноз, что, скорее всего, эти задачи не будут сделаны без превышения исходной оценки.

Цель оценки

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

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

Шаг второй

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

1. Объем производства и выручка от реализации до начала проекта, в ходе реализации проекта и по его завершении.
2. Суммы и график инвестиций капитального характера.
3. Динамика изменения остаточной и среднегодовой стоимости внеоборотных активов (основные средства, нематериальные активы) компании в связи с реализацией ИП. Из нее естественно вытекает возможность вычислить размер амортизационных отчислений и налога на имущество.
4. Сведение текущих издержек хозяйственной деятельности субъекта в связи с реализацией ИП в калькуляцию себестоимости планируемой продукции (услуг).
5. Исходя из производственной программы проекта и плана по сбыту, формирование составов затрат по расчетным периодам деятельности, вплоть до плановых отчетных периодов.
6. Расчет размера вложений в запас оборотных материальных ценностей, а также устойчивых пассивов, таких как, например, задолженность по заработной плате перед персоналом, резервы предстоящих платежей и т.п.
7. Расчет плановых значений прибыли в ее типовых формах и сумм налога на прибыль, планируемых к уплате в соответствии с требованиями законодательства.

Шаг первый

Формирование планово-нормативного фундамента расчета основных статей доходной и расходной частей проекта на всем его протяжении (на схеме фрагменты шага выделены свето-синим цветом). Собираются и консолидируются качественные и количественные параметры сбыта, потребного оборудования, СМР, бюджетно-нормативной платформы.

Анализ статистики и нормативов (для действующего предприятия), бенчмаркинг (для вновь проектируемого бизнеса) имеют непреходящее значение для того, чтобы затем возникли интегральные характеристики ИП. Нормы расхода ТМЦ, их запасов, трудовые и технологические нормативы, налоговая модель и цены – все это нужно для планирования бюджетов и последующей оценки.

Шаг третий

Разработка трех основных бюджетов проекта: бюджета доходов и расходов (БДР), бюджета балансового листа (ББЛ) и финансово-инвестиционного бюджета (ФИБ или плана движения денежных средств) проекта. Основные бюджеты неразрывно связаны не только друг с другом, но и определяют возможности расчета двух ключевых групп показателей эффективности.

Шаг четвертый

Выбор составов показателей и собственно выполнение их расчетов.

Заключение

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

Однако экономическая эффективность проекта не может быть ограничена 5-6 критериями, использующими исключительно cash flow. Это связано с тем, что в большинстве случаев ИП интегрирован во всю совокупность процессов компании и затрагивает многие аспекты экономики предприятия. Проект – это зависимая и влияющая подсистема.

Такая позиция нисколько не умаляет значения исследовательского комплекса NPV, PI, DPP, IRR и т.д. Помимо того, что каждый из этих параметров уже разобран отдельно, предстоит еще ни одно погружение в сквозные примеры расчетов. Это необходимо для того, чтобы мы вместе уточнили логику выработки решений на основе закономерностей и неких нормативных рекомендаций.

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

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