Оценка проектов: 4.6. Оценка проектов — Эффективный девелопмент

4.6. Оценка проектов — Эффективный девелопмент

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

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

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

Примечание

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

В первом случае это оценка, базирующаяся на реальных потоках проектов с учетом затрат по финансированию проектов и налогов. Эта оценка дает не только абсолютные показатели эффективности проекта (прибыль, рентабельность и пр.), но и показатели, учитывающие фактор времени (NPV, IRR, PI и т.д.). А самое главное, при осуществлении такой оценки расчеты содержат в себе в качестве «побочного продукта», что очень важно, полный бюджет проекта, развернутый по статьям затрат и по времени.

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

Во втором случае из расчетов изымаются затраты по финансированию и налоги, что, безусловно, облегчает расчет, но одновременно отрывает его от реальной почвы, делая его результаты пригодными только для оценки текущей стоимости (капитализации) проекта. А зачем это заказчику, если он не собирается продавать свой проект?!..

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

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

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

1. Экспресс-оценка при поиске перспективных проектов.

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

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

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

Примечание

При организации оценки с целью выявления перспективных проектов необходимо иметь в виду, что коэффициент выхода проектов, годных к приобретению прав, как правило, не превышает 1-2% от количества оцениваемых проектов. Соответственно, даже если компания планирует приобретать за год 1-2 проекта, оценивать придется сотни проектов в год, что требует продуманной инфраструктуры и технологии оценки. Экономия на оценке перспективных проектов всегда выливается в значительные убытки, вне зависимости от того являются эти убытки для компании объективным, осознаваемым фактом или остаются загадкой («меньше знаешь – лучше спишь»!!!).

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

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

Данный вид оценки производится в качестве основного элемента процедуры комплексной проверки (Due diligence).

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

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

О перечисленных выше двух видах оценки см. также в описании работ предпроектного этапа в Главе «Этапы развития проектов (содержание и процедуры)».

3. Оценка при осуществлении плановых и внеплановых актуализаций развиваемых компаний проектов (актуализирующая оценка развиваемых проектов).

Данный вид оценки имеет место в ходе развития проектов, после того, как они последовательно прошли предыдущие 2 вида оценки. Этот вид оценки представляет собой многократные уточняющие перерасчеты результатов оценки, осуществленной при вхождении в проект. Данный вид оценки составляет абсолютно большую часть актов оценки, производимых в отношении проекта. В рамках одной актуализации может производиться несколько оценок проекта. Это имеет место в том случае, если проект требует корректировки, которая может рассматриваться и сопоставляться в нескольких вариантах с целью определения наиболее оптимального из них. Количество оценок, производимых при актуализациях проекта, составляет не менее 10-20, а для крупных проектов, со сроком реализации более 5 лет или для проектов квартальной застройки, число актуализирующих оценок может быть на порядки большим.

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

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

Представленный вид оценки был частично описан в приложении к отдельным этапам развития проекта в Главе «Этапы развития проектов (содержание и процедуры)».

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

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

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

1. Допроектный этап.
   Точность оценки минимальная в среднем составляет не выше 30% и зависит в максимальной степени от уровня компетенции (развитости технологического ресурса) компании. Безусловно, необходимо стремиться к наращиванию навыков компании в оценке проектов, чтобы минимизировать риски возможных будущих потерь. Но! То, что совершенно необходимо сделать – это определить пороговые значения эффективности перспективных проектов, планируемых к вхождению. Очевидно, что компания «не попадет» на прямые убытки или значительно снизит риск их возникновения, если будет входить в проекты, рентабельность которых выше точности оценки на допроектном этапе. Таким порогом, например, для жилых проектов является значение рентабельности проекта на все вложенные средства (в том числе реинвестированные средства), равное 30-40% и более. Естественно, при расчете рентабельности необходимо учитывать затраты по финансированию проекта и налоги.

2. Предпроектный этап.
   Точность оценки в пределах до 20-25%. На данном этапе компания получает массу достоверной информации о проекте и его окружении, недоступной до момента вхождения в проект. Именно на этом этапе у компании «открываются глаза» и она понимает, насколько хорош или плох проект, в который она вошла ранее. Этот этап, безусловно, является самым креативным, так как компания, поспешив по каким-то причинам войти в низкоэффективный или, еще хуже, убыточный проект, вынуждена «совершать подвиг», предпринимая всевозможные действия для формирования необходимого уровня его доходности: «Отступать некуда – позади Москва!».

3. Проектный этап.
   Точность оценки находится в интервале до 10-15%. Правоустановка проекта, включающая регламентирующие документы местной администрации, полностью сформирована. В проекте для компании уже не осталось никаких тайн, однако сравнительно невысокая точность оценки определяется тем, что на этом этапе только начинается детализация общей концепции проекта (в особенности ее архитектурной части), разработанной ранее, происходящая в процессе реализации проектных работ стадии «П». Процесс детализации проекта будет активно протекать также при осуществлении проектирования стадии «РД», начинающегося в конце данного этапа.

4. Этап строительства и коммерческой реализации.

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

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

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

Примечание

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

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

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

У сторонников специализированных программ есть последний аргумент – скорость. Но! Как сказано выше, основная часть времени при оценке тратится не на сам расчет, а на подготовку и форматирование исходных данных. К тому же, сам расчет для среднего по объему объекта (10-30 тыс.кв.м.) выполняется в Exel квалифицированным специалистом по оценке за 3-4 часа. И наконец, к чему скорость, если итоги расчета могут оказаться неадекватными (см.абзац 2 в данном примечании)?!!

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

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

Между тем, все гениальное просто. Есть старые проверенные уже веками использования показатели эффективности — чистая прибыль, рентабельность на все вложенные средства (дополнительно – рентабельность на собственные средства), срок окупаемости. Они, конечно же, не учитывают временной фактор в изменении стоимости денег, поэтому разумно дополнить их 2 «самыми древними», самыми надежными из зависящих от времени показателей – чистым дисконтированным доходом и внутренней нормой доходности. Разве что, добавить еще индекс прибыльности?..

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

NP (Net Profit)	Чистая прибыль проекта	Разность между выручкой проекта и всеми вложенными средствами (полный объем затрат проекта, включая налоги и затраты по финансированию).
ROI (Return On Investment)	Рентабельность проекта	Отношение чистой прибыли проекта ко всем вложенным средствам (полный объем затрат проекта, включая налоги и затраты по финансированию)
ROE (Return On Equity)	Рентабельность проекта на собственные средства	Отношение чистой прибыли проекта ко всем собственным средствам, вложенным в проект.
PBP (PayBack Period)	Срок окупаемости	Период времени, по истечении которого общее сальдо проекта приобретает положительное значение
IRR (Internal Rate of Return)	Внутренняя норма доходности	Соответствует ставке дисконтирования проекта, при которой NPV проекта обращается в «0».
NPV (Net Present Value)	Чистый дисконтированный доход	Арифметическая разность между дисконтированными потоками выручки и затрат проекта.
PI (Profitability  Index)	Индекс прибыльности	Отношение дисконтированной выручки к дисконтированным затратам.

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

Очень полезная манипуляция при оценке проекта – расчет чувствительности проекта к изменению ключевых показателей затрат и выручки. Есть только одно «но». К сожалению, расчет чувствительности требует крайне высоких трудозатрат, поскольку для каждой расчетной точки при определении чувствительности требуется перерасчет экономики проекта «в потоке». Если, конечно, не стоит задача формирования показательной чувствительности проекта, допускающая использование метода апроксимации (линейной или нелинейной?..) в качестве главного инструмента расчета. Весьма актуальным расчет чувствительности может быть при подготовке обоснования для вхождения в проект, подготавливаемого в ходе процедуры Due diligence. На последующих этапах развития проекта расчет чувствительности не является целесообразным.

Примечание

Отдельные и особые слова следует сказать о «любимой теме» автора – о понятии общей площади объекта, используемом в процессе оценки проектов (см также графическую интерпретацию в Главе «Технология расчета сметной стоимости строительства на разных этапах развития девелоперских проектов»). Разные участники рынка, употребляя это понятие, имеют в виду, по крайней мере, 5 вариантов смысла в него вкладываемого: общая площадь в габаритах внешнего периметра внешних стен, общая площадь в габаритах внутреннего периметра внешних стен, рассчитанная в соответствии со СНиП, общая поэтажная площадь, общая площадь помещений, и даже общая коммерческая площадь. Первый вариант дает максимальный показатель площади и используется проектировщиками-генпланистами, что обусловлено объективной необходимостью, а также проектировщиками-архитекторами, что чаще обусловлено субъективно-меркантильными соображениями (чем больше площадь объекта, тем выше стоимость работ по проектированию). Второй вариант меньше первого с поправочным коэффициентом 0,89-0,92, зависящим от типа проектируемого здания, используется обычно строителями, а также опытными заказчиками и очень-очень опытными инвесторами. Другие варианты используются прочими участниками. Скажем еще, что, например, для жилого монолитного здания общая коммерческая площадь соответствует примерно 0,75 от общей площади во внешнем периметре.

А теперь читателю предлагается представить «дебаты» по цене строительства некоего объекта, происходящие между 2-мя среднестатистическими участниками рынка, каждый из которых может использовать любой из 5 вариантов общей площади. Имеется «всего-то» 25 сценариев этих переговоров. Далее необходимо учесть, что на рынке нет единого понятия, что такое стоимость строительства объекта (см. главу «Технология расчета сметной стоимости строительства на разных этапах развития девелоперских проектов»). Это понятие у разных участников рынка находится где-то в интервале от отдельно взятой 2 главы ССР до суммы всех глав с 1 по 12. К тому же не всегда бывает просто привести к общей размерности наземную и подземную площади, существующие в разных объектах в разном соотношении. Итоговая картина становится похожей на библейскую историю о строителях Вавилонской башни.

Для «нормального» девелопера или оценщика существует единственный выход из описанного тупика – путь развития и повышения технологического уровня своего собственного и своей компании, когда с легкостью можно оперировать любым из приведенных показателей в зависимости от ситуации и стоящих перед компанией задач. Этот выход отнюдь не является простым — автору в свое время потребовалось «всего лишь» 4-5 лет целенаправленных усилий, чтобы полностью разобраться в этой «пустяковой проблеме».

Заканчивая данную главу, хочется вспомнить гениальный принцип, сформулированный еще в 14 веке монахом-францисканцем, а по факту философом Уильямом Оккамом. Этот принцип прекрасно подходит ко многим областям жизни в качестве базового, в том числе и к деятельности по оценке проектов недвижимости. Называется он – «Бритва Оккама» — и звучит так: «Что утверждаемо посредством меньшего, не следует выражать посредством большего» (Frustra fit per plura quod potest fieri per pauciora) или, выражаясь короче: «Не нужно множить сущее без необходимости». В конце-то концов, оценка должна делаться не только для самих оценщиков… Ее результаты и последовательность операций, приведших к ним, должны быть понятны коллегам, многие из которых не имеют финансового образования. «Птичий язык» здесь не очень уместен!

Оценка проектов в Agile по методу MoSCoW

10 Авг 2015

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

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

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

MoSCoW – это аббревиатура для четырёх основных этапов приоритизации элементов в процессе разработки:

• «MUST». Первая буква означает те элементы, которые непременно должны быть включены в продукт, иначе он не будет выполнять наиболее важные функции и приносить пользователю ценность. Также к данной категории относятся требования законодательства, необходимые для реализации проекта. Эта категория имеет наивысший приоритет.
• «SHOULD». В данной группе находятся те элементы, которые следует включить в финальную версию продукта. Это те элементы, которые важны для заказчика, и продукт не будет полноценным, но при этом будет работать. Вторая группа по уровню приоритета.
• «COULD». Те элементы и опции, которые клиент хотел бы видеть в своём продукте. Наличие опций из этой группы приносит наибольшее удовлетворение клиенту или заказчику. Эти опции можно сказать, «вишенка на торте», имеют низкий приоритет, но для удовлетворения заказчика, необходимы.
• «WON’T». В эту группу включаются те опции, которые решено было не включать в нынешнюю версию продукта.

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

 

Рисунок 1. Пирамида MoSCoW

Когда элементы продукта сгруппированы, команда проекта проводит сравнительную оценку каждого из них при помощи story point – абстрактной единицы измерения, имеющей смысл только для данного конкретного проекта. На первом этапе выбирается элемент, для выполнения которого требуется наименьшее количество времени или сил. Сложность его выполнения принимается за 1 story point. То, что именно брать за базу, полностью зависит от команды и её особенностей. Главное, чтобы эта оценка отражала трудность и/или длительность работы над элементом. На следующем этапе проводится оценка оставшихся элементов путём сравнения их с базой.

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

1. Из элементов продукта выбираются 3-4 элемента с наименьшей степенью неопределённости.
2. Команда проводит декомпозицию работ по каждому элементу, чтобы затем провести оценку времени, стоимости и ресурсов для реализации данного элемента в продукте. В данном случае требуется «идеальная» оценка времени и затрат, при самых благоприятных условиях.
3. По результатам данной оценки определяется стоимость 1 story point’a в часах. Время работы над элементом делится на количество story point’ов. Если у взятых 3-4 элементов эти значения немного расходятся, чаще всего берут среднее значение. То же самое повторяется для оценки затрат.
4. Сумма story point’ов по продукту умножается на стоимость в часах – таким образом получается предварительная оценка проекта. Аналогично проводится оценка затрат.

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

Мультипликаторы:

• Х*1.25 – Типовой проект. Такое значение авторы предлагают для случая, когда команда реализует привычный для них продукт, который они производили уже не раз, с минимальными отличиями. В таком случае степень неопределённости невысока, а команда уже знает о возможных трудностях, а потому их оценка требует лишь небольшой корректировки.
• Х*1.5 — Чётко определённый проект. Чтобы получить такой мультипликатор, проект должен иметь невысокую неопределённость, но не быть типовым для команды. Например, если у команды не так много опыта с конкретным типом продукта или клиент просить серьёзно модифицированный продукт, что вносит некоторую степень риска.
• Х*2.0 – Новые разработки. Данный мультипликатор используется в случае, если команда вынуждена столкнуться с чем-то абсолютно новым для себя в рамках работы над продуктом.
• Х*2.0 и выше – Быстрый старт. Используется тогда, когда нет времени на тщательную декомпозицию работ и проработку проекта. В таком случае проводится грубая оценка проекта с подобным мультипликатором.

В заключении приведём пример, как примерно выглядит этот процесс:

1. Пусть суммарная оценка всего проекта составляет 150 story point’ов.
2. Если проект чётко определён, то с учётом мультипликатора, оценка станет 225 story point’ов.
3. Пусть 1 story point будет равен 10 часам. Тогда по плану, вся работа над нашим проектом должна уложиться в 2250 часов, или 282 рабочим дням.

Таким же образом можно произвести оценку затрат проекта или потребности в ресурсах.

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

Смотрите также:

 

Оригинал: http://www.pmhut.com/an-agile-primer-agile-estimating-and-the-moscow-process

Оценка новых проектов / Хабр

«Почему Я?!»

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

Начнем по порядку. За время работы в ИТ ко мне, как в принципе, и к любому ИТ специалисту, приходят с просьбами оценить ту или иную задачу, функциональность или проект. Первая реакция у всех одна и та же: «Почему я?!». На такой вопрос идут типизированные ответы: «Ты же хотел чего-то нового?!», «Ты классный специалист!», «Это твое развитие!» и т. д. и т.п. Можете сами продолжить смысловой ряд, почему жребий судьбы пал именно на вас.

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

Агент специального назначения

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

Вы же спецагент! Действуйте!

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

Собираем велосипед

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

Ведро с гвоздями

Наконец-то добрались до самой оценки поставленной задачи!

Начинаем разбивать одну большую задачу на атомарные, пока точно не сможете сказать — сколько времени нужно на нее. По-своему опыту могу сказать, что задача должна быть оценена в часах и не должна быть больше 16 (два дня работы непосредственно на то, чтобы реализовать ее).
Не стоит забывать о работах для задачи. Следует оценить также участие в митингах, написание юнит тестов, тестирование и т. п.

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

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

«Насуем в проект соломы!»

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

Чем точнее и подробнее написаны риски и допущения, тем больше шансов, что проект пойдет как надо, и в итоге вам скажут спасибо!

Обрезание и корректировка

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

К чему же пришли?

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

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

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

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

Оценка эффективности проекта — услуги Первый Эксперт

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

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

Задачи оценки эффективности проекта

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

1. определение процента реализуемости, что означает выполнение проверки удовлетворения проекта всем требуемым параметрам и установленным ограничениям;
2. установление целесообразности воплощения проекта, что предполагает рассмотрение и сопоставление совокупных результатов и понесенных затрат;
3. изучение сравнительной результативности проекта, исследование и сопоставление его преимуществ в сравнении с аналогами и альтернативными идеями.

Методы оценки эффективности проекта

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

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

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

В практическом применении наибольшее распространение имеют такие группы методов оценки:

1. Статистические

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

1. Срок окупаемости инвестиционных вложений.

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

1. Коэффициент эффективности инвестиционных вложений.

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

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

2. Динамические

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

1. чистый дисконтированный доход. Он показывает рост капитала компании, и поэтому положительное значение данного показателя является весомым аргументом для принятия проекта. Если встает вопрос выбора между несколькими проектами, то решающим фактором как раз является большее значение данного показателя;
2. индекс рентабельности инвестиций. Расчет этого значения позволяет увидеть соотношение стоимости денежного притока и оттока в текущем периоде. При этом учитывается сумма первоначально вложенных инвестиционных средств. Проект следует принимать в том случае, если данный показатель имеет значение больше единицы;
3. внутренняя норма рентабельности. С помощью данного значения определяется максимально возможный уровень, до которого могут доходить расходы на реализацию всех стадий проекта;
4. модифицированная внутренняя норма рентабельности. На основании расчета данного показателя компания может выполнять реинвестирование в том случае, если в процессе реализации проекта происходил неоднократный отток финансовых ресурсов;
5. дисконтированный срок окупаемости инвестиций. На основании данной величины определяется период, в течение которого полученные от запуска проекта доходы перекроют вложенные в него инвестиционные ресурсы.

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

Критерии оценки эффективности проекта

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

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

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

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

Показатели оценки эффективности проекта

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

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

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

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

Услуги оценки эффективности проекта

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

Экономическая оценка проектов

Принятие инвестиционных решений на основании глубокого экономического анализа

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

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

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

Стандартизация экономической оценки

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

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

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

Анализ рисков и неопределенностей

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

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

Методология трехточечной оценки проекта

Какой подход к оценке стоимости проекта используете?

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

Ловушка приблизительной оценки

Заказчик хочет, чтобы ему дали оценку. Поскольку проект объемный, чтобы его правильно оценить, нужно уточнить все требования, расписать хотя бы задачи и отдать эксперту на оценку. Суммарно это 1-2 недели плотной работы. А заказчик ждать не будет. Поэтому выход один: выставить приблизительную цену, а если говорить честно, то цену “с потолка”. В итоге заказчик еще просит скидку. А в довершение требует еще и зафиксировать цену проекта в договоре (“fixed price”).

Поддаваясь соблазну заполучить заказчика, подрядчик идет на это.

Смотрите видео: Методика оценки на практике и мнение клиента

Что же будет дальше? 

Дальше подрядчик приступает к работе.

И выясняется:

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

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

Вопрос доверия

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

Как вы думаете, что руководство компании заказчика легче примет:

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

Вопрос доверия к партнеру (как внешнему, так и внутреннему) — один из важнейших факторов успешного сотрудничества.

Что будет, если бюджет закончился, а проект — нет?

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

• вести работы по проекту за свой счет — убыток;
• требовать доплату и пересмотр договора — конфликт, возможен разрыв договора, потеря репутации;
• экономить на всем: программистах, аналитиках, тестировании, описаниях — в итоге можно получить очень некачественный код и в целом проект, а это плохой опыт и репутация;
• вкладывать расходы в цену будущего сопровождения — заказчик может и отказаться от “дорогого” сотрудничества;
• остановить проект, когда закончатся деньги — потеря проекта…

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

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

Вот так выигранный по цене тендер еще не гарантирует успеха проекта.

Как обеспечить финансовый успех проекта

Наш многолетний опыт внедрений и опыт внедрений наших партнеров показывает:

• Заказчик практически никогда не присылает на оценку описание, достаточно детальное для оценки, — поэтому нужно проводить предварительное обследование (скоро выпустим видео).
• Нужно выставлять адекватную, реальную цену. Пользуйтесь проверенными практиками оценки. Сегодня мы расскажем о Трехточечной оценке, которую используем в своей работе.
• Никогда не соглашайтесь на “fixed price” и честно, грамотно объясняйте заказчику, чем это грозит.

Трехточечная оценка: как это работает

Это методика оценки проекта или отдельных задач.

После детализации задачи проводится 3 оценки по задачам или этапам проекта:

1. Минимально возможное время, за которое можно выполнить задачу;
2. Экспертная оценка по выполнению задачи или этапа;
3. Оценка ресурсов, превышать которые не понадобится для выполнения данной задачи, с вероятностью 95%+.

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

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

Если будут требовать (так часто бывает) фиксированную ставку или единую цену, ее можно усредненно посчитать по формуле (1мин+4сред+1макс)/6.

Что думают о цене “в диапазоне” заказчики

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

В качестве примера можно привести выступление нашего крупного клиента, компании Zeppelin, Евгения Осьмака, Head of corporate IT.

Евгений рассказывает:

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

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

И обратная сторона такого требования в том, что разработчик вообще перестает давать более-менее четкую оценку, называя сроки по задаче, к примеру, от 2 до 800 часов, тем самым не давая зажать его в любые рамки”.

Трехточечная оценка в графике

Проект: у него есть время, раньше которого его не сделать.

Есть риски и вероятности.

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

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

А также есть практическая оценка максимальной суммы, которую придется потратить.

Все эти три цены важно озвучивать заказчику — они обоснованы, и такой информацией можно оперировать.

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

По формуле оценку можно усреднить, но эта средняя цена тоже ни о чем не скажет.

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

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

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

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

Вот такое мнение высказывает специалист по внедрениям компании Zeppelin. Полную версию выступления на CIO-Jazz-2018 можно посмотреть здесь >>>

Проведите трехточечную оценку для себя и оцените ее эффективность

Для примера мы вложили
наш шаблон оценки проекта. 

Воспользуйтесь им. 

Как это проверить:

1) Получили список задач на оценку. Может, ваши аналитики (специалисты) согласовали такой список.

2) Его нужно оценить.

На первый взгляд, есть несколько задач с подробным описанием. И после ознакомления можно дать интуитивную оценку в 2-3 дня или 24-38 часов.

Часто так и считают.

3) Попробуйте посчитать по трехточечной методике.

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

И по каждой проставляем 3 оценки.

4) Еще предусматриваем обязательные вспомогательные работы, добавляем % на:

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

По итогам расчета вы увидите ощутимую разницу в цифрах.

Как показать таблицу заказчику

Часто заказчик плохо воспринимает всю таблицу целиком. Поэтому, ориентируясь на понимание, можно давать 3 оценки или 2: минимальную и среднюю.

Решать, что показывать, в принципе, можно самостоятельно.

Но главное — вы для себя получите инструмент для понимания границ и рисков.

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

Зачем и как проводить предварительный анализ проекта, смотрите в нашем видео (скоро на канале).

Зачем мы рассказываем все это? — Делимся опытом

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

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

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

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

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

В своей компании мы работаем по модели time and material (T&M).

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

---

Откуда взялась методика трехточечной оценки

Получив многочисленные вопросы и комментарии к видео по Трехточечной оценке, мы решили дать ответ на наиболее частый «Откуда взята методология?» детали смотрите в нашем видео >>>

Читать статью про стандарт PMI PMBoK 6th Edition >>>

---

Полный текст видео

Зосим Максим: Привет всем! С вами Зосим Максим и команда tqm system.

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

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

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

Собственно говоря, мы считаем, что нужно показывать все три цифры вашим заказчикам. И апеллировать в бюджете нужно не одной фиксированной ценой, а всеми тремя. Естественно, клиент может требовать от вас (и скорей всего будет) какую-то фиксированную ставку, для чего можно усреднить оценку, с помощью формулы: взять 1 минимальную + 4 средних и + 1 максимальную и поделить это все на 6. Дальше мы посмотрим на примере как это делается.

А пока, что говорить об этом один из наших крупных клиентов:

Евгений Осьмак: Найбільша пастка бюджета наступна: це коли до людини приходять питать estimate, тобто оцінку, а потім в якийсь момент вона непомітно стає commitment, тобто зобов’язанням. Да? Тобто ще раз: поки воно estimate – все добре. Як тільки воно стає commitment, перший раз в житті, да? Наступний раз ІТ-шник що обере? — estimate помножить на π. Точніше досвідчений на π, не досвідчений на е. Ну правильно? – це ж математика.

Евгений Осьмак: Там два множника: е – 2,76 і π – 3,14. Все решта – то не наукове. Не треба — Нє, дивіться… як я вирішую цю проблему з commitment(ами) і estimate(ами), да? Інакше просто якщо ми прив’язуємо commitment до estimate – ти з експерта нічого не виб’єш. Він просто стає в жостку опозицію, починає видавати там… не знаю.. від 2х до 800 годин оцінку. Скільки задача займе? – від двох до 800 годин. Ну тобто це називається пасивна агресія. Розумієте, да? Ну точніше це навіть не пасивна.

Є поняття трьохточечної оцінки. Трьохточечна оцінка. Графік ймовірності виглядає таким чином.

У бідь-якого проекта значить є: мінімальний час, за який його можна зробити. В принципі мінімальний. Дев’ять жінок за місяць не зроблять одну дитину. Оце так пояснюю – всі розуміють. Тобто є мінімальний час за який.. менше якого не можливо цей проект зробити. От ніяк. От тут це наймолюсінька можливість, що якщо все буде добре і все ні одної проблеми, і всі… попутній вітер – то це перший там… це може бути або час, або гроші – не важливо. Нехай це будуть гроші.

Тепер, що тут ще є: тут є найбільш ймовірне значення. Його особливість в тому, що його відчувають експерти. Експерт інтуїцією своєю, накопиченим досвідом… Коли, за скільки зробиш? — ві задає оце найбільш ймовірне значення. Розумієте? Він відчуває. Ох, два дні.

Голос из зала: По оси y — это вероятность?

Евгений Осьмак: Да, да, да. Це ймовірність, що будуть… в результаті такі зусилля. З часом механіка така сама.

Голос из зала: Доли там? 0%, 100%

Евгений Осьмак: Ні, ні, ні. Це є розподіл… інтеграл оцього 100%. А це функція щільності-ймовірності. Нє? Ну… Окей. Це звичайна ймовірність. От тут, наприклад, 20%, тут – 19. Якщо всі оціі скласти, то получиться 100. Це означає, що в даному випадку, отак на око, ймовірність 25%, що буде оця точка. Ну я не знаю… І є третя точка — це з дуже великою ймовірністю, наприклад, з ймовірністю 95% — це не займе більше ніж.

Таким чином ми маємо: оптимістичний, в середньому і песимістичний… значення. Я всі три показую. Я бізнесу три показую. Прям три. Я говорю: от дивіться, оптимістичний прогноз – буде 10 тисяч доларів, але він неможливий, песимістичний – 16, експерти думають – 14 і робіть з цим що хочете. Ще раз, це та інформація надійна, яку я можу дать. Я що оракул, що знаю скільки вона буде стоїть?! Я що буду когось обманувать?! Я що ведун?! Якщо люди шукають чарівників – вони находять казкарів – це ж очевидно. Якщо людина шукає оракула дельфійського – вона знаходить…

У нас був… знаєте увійшов в фольклор фразой: at basically everything is possible. Можна це зробити? – basic. А там по англійськи у нас просто, проект був англомовно. is it possible – basically everything is possible. Молодец! Вот ето! Як ми тебе чекали. А знаєте до чого потім… Значить, дивіться у нас вже обговорення і режим afterparty. От є життєвий цикл продукта, є життєвий цикл проекта, а є життєвий цикл ПМ(а) проекта. Ну… Тобто, печаль наступає тоді коли… ось тут — basically everything is possible, а потім життєвий цикл ПМ(а) короче чем у проекта. Тому що от тут десь наступає фаза терморектального криптоаналізу… ну прочитаєте на цьому… на Lurkmore про терморектальний криптоаналіз, ну ви розумієте

Голос из зала: Тут все ІТ-шники.

Евгений Осьмак: Коли питають доколе, почем і так далі. Головне от тут піти на підвищення у цей момент.

Голос из зала: Хороший способ.

Евгений Осьмак: Так працює. Я не пробував, но я бачив як це працює, прям в реалє.

Фрагмент фильма: I believe I can fly, I believe I can soar. I believe I can fly. I believe! I believe! I believe! I believe!

Евгений Осьмак: Із-зі цього я даю бізнесу таку трьохточечну оцінку по будь-якій задачі, яка крупна. І говорю, що… є думка, якщо вжити таку формулу: (мін+4*серед+макс) / 6. Математика нічого кращого ніж це не придумала. Тобто якщо вам треба одна оцінкка, то вона ні о чом, но можете взяти таку формулу. Нічого кращого немає. Но воно все рівно ні о чом. Тобто ще раз, коли вони мене починають кальоним залізом видавлювать одну цифру, я їм говорю, тільки це ні в якому разі не commitment(не) – це по перше. По друге, от де я її взяв, от… і це ширше оце… Тобто дивіться, оцей чим він вужчий – тим більше експерт впевнений що ризики не великі. Чим ця штука ширша… в перший раз у бізнесах, це викликало яку-то таку роботу думки всередині. Зараз вони не уявляють по іншому. Це 7 років так працювали. Розумієте?

Це я їм приніс. Ребята, я не чарівник. От є мінімальний, він неможливий. Ну хочете… Знаєте яка ще єсть небезпека? – бізнес питає: за скільки зробите? Ну ви ж не знаєте, яка з цих трьох точок його цікавить. Надійна оцінка чи оптимістична. А ви не знаєте. Якщо ви не запитали, може бути така небезпека: він питав про оцю (максимальна), а ви йому відповіли оцю (мінімальна). Із-за цього будь в якому випадку, коли результуючий проект закінчується от тут (між експертною оцінкою і максимальною), да? Ми говоримо: ну все хорошо, пішов трохи песимістичний сценарій, ми вклались в свою оцінку, значить ми молодець. Да? Тобто ми регулярно міряємо на скільки ми попадаємо в цю оцінку. Якщо ми з нею починаємо вивалюватися, значить ми лохи. Понімаєте? Ми не розуміємо вообще то чим займаємося і вон із професії. Якщо ми попадаєм, да?… Більше того, тут же основний дзен полягає в тому що найбільш ймовірне значення відрізняється від медіани. Бо в середньому буде оттак. Із-за хвоста, розумієте? То есть середньому виходить більше, ніж говорять експерти. Із-за того всі розуміють, що його треба множити. Тільки ніхто не знає на скільки. На π чи на е.

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

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

Давайте разберем простой пример, а также инструменты использования методологии. К примеру, клиент присылает вам список задач, в виде нескольких файлов с задачами. Или предположим, что это ваши специалисты согласовали эти задачи и их необходимо оценить. На первый взгляд есть несколько задач с подробным описанием. И если вы или ваш специалист ознакомиться с ними, то интуитивно (это я по себе могу судить) эта оценка будет 3-4 дня или от 24 до 32 часов. Часто именно так и поступают партнеры.

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

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

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

Возможно, у вас возник вопрос: зачем мы это делаем? Ответ прост. Последнее время мы конкурируем с другими продуктами или качеством обслуживания клиентов. Мы все больше конкурируем с конкретной ценой. А конкретней с неправильной оценкой с головы у начинающих партнеров или с отсутствующим опытом и не имея какой-либо более-менее понятной методологии оценки, мы сталкиваемся просто с оценками наугад и сильно заниженной стоимостью для клиента. Это приведет к плохим последствиям, как для клиента, так и для партнера. Особенно для тех, кто работает по фиксированной модели. С одной стороны, за ваши оценки вы выиграете тендер. Но с другой, при неправильной оценке вы в итоге работаете в ноль. И вам придётся жертвовать, или качеством выполнения работ, подвергая рискам дальнейшую работоспособность вашего кода. А если вы сильно уйдете в минус, то и с клиентом придётся объясняться. Либо объяснять почему он должен доплачивать. Либо вы попытаетесь заложить и риски, и расходы в следующие работы, что в результате служит негативное отношение, как к вам, так и к другим партнерам.

Мы уже не раз сталкивались с ситуацией и отзывами клиентов и долго объясняли почему оценка задачи – это всегда диапазон. И почему нельзя работать по фиксированной ставке. Именно поэтому мы в нашей компании работаем по модели time and material.

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

Кстати, если у вас есть интересные кейсы, как вы оцениваете, делитесь ими в комментариях.

Анализируйте, оценивайте и работайте с выгодой.

Не забывайте подписываться на канал и ставить колокольчик.

Скоро будет ролик про необходимость и структуру этапа экспресс обследования в проектах.

---

Грамотно составит требования к системе и провести экспресс-обследование: TQM systems

Хотите оценить проект, построить стратегию внедрения? Проконсультируем.

Отправь запрос!

Видео о ключевых моментах внедрения систем автоматизации на канале TQM systems: кейсы, методики работы, параметры выбора, новые разработки и возможности.

Наши контакты >>>

Art: ,ID:

• Контент-маркетолог TQM systems (1C / BAS) Nataliya Raevskaya
• 6/21/2020 8:58:35 AM
• articles

Зачем нужна оценка IT-проектов: результат без разочарований

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

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

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

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

Экспресс-оценка – По модулям и компонентам: 1-2 дня

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

Средняя оценка – По крупным задачам с детализацией: 4 дня

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

Точная оценка – По задачам с мелкой детализацией: 5-7 дней

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

Вообще есть мнение, что оценки IT-проектов рассчитываются неверно. Как следствие, проекты выполняются дольше и существенно дороже, чем планировалось. Это происходит, потому что заказчик часто торопит исполнителей и надеется получить окончательные расчёты “здесь и сейчас”, не вдаваясь в подробности, что именно требуется. Стремление бизнеса ускорить процесс вполне понятно – клиентам важно выпустить свой программный продукт на рынок раньше конкурентов. Но если слишком быстро бежать к финишу, без оглядки на дорогу, то она может увести вас совсем в другую сторону.

Оценка IT-проектов – это ответственный этап в процессе разработки любого продукта. Она требует внимательного подхода как со стороны команды разработки, так и со стороны клиентов. Только так вы добьётесь высокой точности оценки, и результат вас не разочарует.

% PDF-1.2 % 2072 0 объект > эндобдж xref 2072 106 0000000015 00000 н. 0000002457 00000 н. 0000002801 00000 н. 0000002850 00000 н. 0000003152 00000 п. 0000003244 00000 н. 0000003318 00000 н. 0000003410 00000 п. 0000003482 00000 н. 0000004325 00000 н. 0000004754 00000 н. 0000005073 00000 н. 0000005200 00000 н. 0000005261 00000 п. 0000005386 00000 п. 0000005447 00000 н. 0000005571 00000 н. 0000005632 00000 н. 0000005756 00000 н. 0000005818 00000 н. 0000005942 00000 н. 0000006004 00000 п. 0000006129 00000 н. 0000006191 00000 н. 0000006315 00000 н. 0000006377 00000 п. 0000006501 00000 н. 0000006563 00000 н. 0000006687 00000 н. 0000006749 00000 н. 0000006873 00000 н. 0000006935 00000 н. 0000007060 00000 н. 0000007122 00000 н. 0000007246 00000 н. 0000007308 00000 н. 0000007432 00000 н. 0000007494 00000 н. 0000007618 00000 н. 0000007680 00000 н. 0000007804 00000 н. 0000007866 00000 н. 0000007990 00000 н. 0000008052 00000 н. 0000008176 00000 н. 0000008238 00000 п. 0000008362 00000 н. 0000008424 00000 н. 0000008548 00000 н. 0000008610 00000 п. 0000008734 00000 н. 0000008796 00000 н. 0000008921 00000 н. 0000008983 00000 п. 0000009107 00000 п. 0000009169 00000 н. 0000009293 00000 н. 0000009355 00000 н. 0000009479 00000 н. 0000009541 00000 н. 0000009665 00000 н. 0000009727 00000 н. 0000009851 00000 н. 0000009913 00000 н. 0000010037 00000 п. 0000010099 00000 н. 0000010223 00000 п. 0000010285 00000 п. 0000010409 00000 п. 0000010471 00000 п. 0000010596 00000 п. 0000010659 00000 п. 0000010783 00000 п. 0000010846 00000 п. 0000010970 00000 п. 0000011033 00000 п. 0000011157 00000 п. 0000011220 00000 н. 0000011397 00000 п. 0000011427 00000 п. 0000011915 00000 п. 0000012094 00000 п. 0000012652 00000 п. 0000012837 00000 п. 0000013011 00000 п. 0000013188 00000 п. 0000013722 00000 п. 0000013913 00000 п. 0000013986 00000 п. 0000014176 00000 п. 0000014998 00000 п. 0000015020 00000 н. 0000015628 00000 п. 0000015650 00000 п. 0000016239 00000 п. 0000016261 00000 п. 0000016931 00000 п. 0000016953 00000 п. 0000017543 00000 п. 0000017565 00000 п. 0000018217 00000 п. 0000018239 00000 п. 0000018931 00000 п. 0000018953 00000 п. 0000019667 00000 п. 0000003574 00000 н. трейлер > startxref 0 %% EOF 2073 0 объект > / OpenAction [2081 0 R / XYZ ноль ноль ноль ] / Контуры 121 0 R / Тип / Каталог / PieceInfo> >> / Метаданные 2062 0 R / LastModified (D: 20080306135727) / PageMode / UseNone / Страницы 2064 0 R / StructTreeRoot 2069 0 R >> эндобдж 2074 0 объект [2075 0 руб. 2077 0 руб. 2079 0 руб. ] эндобдж 2075 0 объект > / Ж 2076 0 Р >> эндобдж 2076 0 объект > эндобдж 2077 0 объект > / Ж 2078 0 П >> эндобдж 2078 0 объект > эндобдж 2079 0 объект > / Ж 2080 0 Р >> эндобдж 2080 0 объект > эндобдж 2177 0 объект > поток

Планирование оценки проекта: общие принципы

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

Показатели

Процесс оценки проекта включает анализ различных компонентов или показателей, которые характеризуют прогресс проекта в достижении его целей и задач. Этими компонентами / индикаторами являются Outcomes и Impact .

Результаты

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

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

Несколько примеров результатов проекта:

• Новые навыки и компетенции, полученные персоналом
• Повышение уровня знаний
• Лучшее понимание бизнес-среды
• Активное участие в принятии решений

Удары

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

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

Вот некоторые примеры воздействия проекта:

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

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

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

• Голы
• Цели
• Деятельность
• Результаты
• Удары

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

План оценки

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

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

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

При разработке плана оценки проекта мы рекомендуем следующие общие рекомендации по оценке проекта:

Шаг №1. Определить результат и влияние

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

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

Шаг №2. Выберите метод оценки

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

Вот несколько примеров методов, которые вы можете включить в шаблон плана оценки проекта:

• Обзор реализации
• Опросы
• Анкеты
• Фокус-группы
• Анализ записей
• Интервью

Шаг 3. Отчет об оценке

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

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

Методы оценки проекта — CEOpedia

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

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

Существует также разделение на момент выполнения оценки: оценка ex ante, (до реализации), текущая оценка (во время реализации) и ex post, оценка (после реализации).

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

Статические методы оценки проектов

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

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

Предлагается использовать только простой метод:

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

К наиболее часто упоминаемым и описываемым статическим методам оценки инвестиционных проектов относятся:

• Срок окупаемости
• Счет сравнительных затрат
• Счет сравнительной прибыли
• Счет сравнительной рентабельности
• Средняя доходность инвестиций
• Тест первого года

Преимущества и недостатки статических методов оценки проектов

К их преимуществам можно отнести:

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

Критика этих методов включает:

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

Динамические методы оценки проектов

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

• NPV — чистая приведенная стоимость
• IRR — Внутренняя норма доходности
• MIRR — Модифицированная внутренняя норма доходности
• Аннуитетный метод
• Индекс доходности
• NPVR — показатель чистой приведенной стоимости пересмотрен

См. Также:

Список литературы

• Коупленд, Т.Э., Уэстон Дж. Ф. и Шастри К. (1983). Финансовая теория и корпоративная политика (Том 3). Ридинг, Массачусетс: Эддисон-Уэсли.
• Дасгупта П., Сен А. и Марглин С. (1972). Руководство по оценке проектов. В ЮНИДО. Разработка и оценка проекта (Том 2). Организация Объединенных Наций. ЮНИДО.
• Девараджан С., Сквайр Л. и Сутиварт-Наруэпут С. (1997). Помимо нормы доходности: переориентация оценки проекта . Наблюдатель за исследованиями Всемирного банка, 12 (1), 35-46.
• Frechtling, J. (2002). Удобное руководство по оценке проектов 2002 г. .

Глава 7: Этапы и процессы оценки | Принципы взаимодействия с общественностью

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

Планирование

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

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

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

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

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

Начало страницы

Внедрение — Формирующая и оценка процесса

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

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

Начало страницы

Завершение — Итоговая оценка, оценка результатов и воздействия

После завершения программы оценка может изучить ее непосредственные результаты или долгосрочное воздействие или суммировать ее общую результативность, включая, например, ее эффективность и устойчивость.Результат программы можно определить как «состояние целевой группы населения или социальных условий, которые, как ожидается, должна изменить программа» (Росси и др., 2004, стр. 204). Например, контроль уровня глюкозы в крови был подходящим результатом программы при оценке эффективности обучения пациентов с диабетом, основанного на расширении прав и возможностей (Anderson et al., 2009). Напротив, количество людей, получивших образование по расширению прав и возможностей или любую программную услугу, не будет считаться результатом программы, если только участие само по себе не представляет собой изменение поведения или отношения (например,g., участвуя в программе по лечению токсикомании). Точно так же количество пожилых людей, не привязанных к дому, которые получают питание, не будет считаться результатом программы, но полезные питательные свойства фактически потребляемых обедов для здоровья пожилых людей, а также улучшение их воспринимаемого качества жизни будут подходящими результатами программы. (Росси и др., 2004). Оценка программы также может определить степень, в которой изменение результата может быть связано с программой. Если оценивается партнерство, вклад этого партнерства в результаты программы также может быть частью оценки.Модель CBPR, представленная в главе 1, является примером модели, которую можно использовать для оценки как процесса, так и результатов партнерства.

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

Начало страницы

Распространение и отчетность

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

Распространение результатов оценки требует адекватных ресурсов, таких как люди, время и деньги. Членам сообщества, у которых есть другие обязательства, может быть сложно найти время для написания статей и презентаций (Parker et al., 2005). Кроме того, ученые не могут быть вознаграждены за ненаучные презентации и, следовательно, не решаются тратить время на такую ​​деятельность. Для перевода материалов могут потребоваться дополнительные ресурсы, чтобы гарантировать их соответствие культурным традициям.

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

Начало страницы

План оценки

— узнайте, как создать эффективный план оценки

Что такое план оценки?

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

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

1. Формирующий
2. Итоговый

Формирующий план оценки

Формирующий план оценки завершается до или во время проекта. Формирующая оценка имеет следующие характеристики:

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

Итоговый план оценки

Итоговый план оценки «подводит итог» проекта.Таким образом, он пишется по завершении проекта. Итоговый план характеризуется следующими характеристиками:

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

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

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

Как написать план оценки

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

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

2. Использование и пользователи плана оценки — Важно четко описать использование плана оценки.Для прозрачности и подотчетности в этом разделе вы должны четко показать пользователям плана. Опять же, вы должны описать участие заинтересованных сторон и финансистов проекта в этом же разделе.

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

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

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

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

Важность плана оценки

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

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

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

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

Выводы

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

Дополнительные ресурсы

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

• Аудит существенности Порог существенности в аудитах Порог существенности в аудитах означает контрольный показатель, используемый для получения разумной уверенности в том, что аудит не обнаружит каких-либо существенных
• Due DiligenceDue Diligence ReportExample отчет о проверке сделок M&A. Этот отчет DD предназначен для комплексной проверки слияний и поглощений и содержит список вопросов, на которые необходимо ответить перед закрытием.Отчет о комплексной проверке отправляется в виде служебной записки членам исполнительной группы, которые оценивают сделку, и является требованием для закрытия сделки.
• Срок окупаемости Срок окупаемости Срок окупаемости показывает, сколько времени требуется бизнесу, чтобы окупить вложения.
• Шаблон бюджета проекта Шаблон бюджета проекта Этот шаблон бюджета проекта предоставляет вам инструмент для суммирования бюджета затрат по проекту. Бюджет проекта — это инструмент, используемый руководителями проектов для оценки общей стоимости проекта.Шаблон бюджета проекта включает подробную оценку всех затрат, которые могут быть понесены до завершения проекта

5 вопросов, на которые вы должны ответить

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

Отказ мобильного приложения Vine — одна из них. Несмотря на то, что вначале Vine генерировал больше мемов и культурных моментов, чем большинство приложений с вдвое большим количеством пользователей, в 2013 году не удалось справиться с серьезной проблемой конкуренции.Мобильное приложение не давало изменений достаточно быстро, и в результате более динамичные конкуренты Instagram и Snapchat захватили пользователей. Вот почему так важно регулярно оценивать успешность проекта. В конце концов, каждый инвестор хочет возмещения затрат на проект, и процесс оценки проекта поможет в этом!

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

Что такое «процесс определения целей» и почему он так важен?

Для определения целей проекта хорошо оставить его S.M.A.R.T. (Конкретный, измеримый, достижимый, реалистичный, связанный со временем) или даже S.M.A.R.T.E.R. (Оценено, рассмотрено). Эта методика позволит вам сосредоточиться на целях и работать более уверенно. Вы и ваша бизнес-среда должны знать, почему вы хотите реализовать этот проект, какие цели в данном случае являются наиболее важными и какие инструменты будут использоваться для его реализации. Помните, стоит правильно подготовиться перед запуском ИТ-проекта.

Итак, как правильно оценивать проект?

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

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

5 вопросов, на которые нужно ответить, чтобы оценить успех вашего проекта

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

# 1 Какой прогресс был достигнут?

Посмотрите на улучшения и направление вашего проекта. Сравните реальность с предполагаемым планом проекта. Убедитесь, что вы находитесь на том месте со своим проектом, которым хотели бы стать в данный момент. А если нет — по каким причинам?

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

# 2 Были ли достигнуты желаемые цели проекта?

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

Например: для вас фраза «приложение работает» означает, что оно опубликовано в App Store, и вы можете отправить его своим друзьям, чтобы проверить его. Но для разработчиков программного обеспечения это может означать, что на их серверах есть рабочий код. В обоих случаях приложение работает, не так ли? 😉 Здесь очень важно взаимопонимание.

# 3 Оправдывают ли результаты проекта вкладываемые средства?

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

А вот кастомный софт стоит дорого — скрывать нет смысла.Важнейшая цель этого вопроса — установить ваши ожидания на правильном уровне. Поскольку вы не можете пойти в магазин с 10 долларами в кармане и потребовать самое дорогое вино, аналогичная ситуация и с разработкой приложений. Но бывает и наоборот: если вы чувствуете, что слишком много заплатили за полученный результат, сообщите об этом в отдел разработки программного обеспечения. Если он правильный, они смогут объяснить, почему такая цена. Если они начнут паниковать — это красный флаг для вас.

Я приведу вам пример из нашей собственной игровой площадки — в течение нескольких месяцев мы не могли найти время, чтобы обновить наш. Занятые созданием потрясающих приложений, мы пренебрегли самым важным маркетинговым активом нашей компании. Потому что давайте будем честными — создание совершенно нового веб-сайта с нуля — дорогое удовольствие. Между проектами у нас ушло 6 месяцев напряженной работы, но мы уже видим, что наши усилия окупились. Более высокая конверсия, больше трафика и, самое главное, больше лидов от владельцев бизнеса, которые мы теряли раньше из-за устаревшего дизайна.Вы можете узнать больше и посмотреть видео с сайта ниже!

# 4 Удовлетворены ли результатом все участники команды?

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

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

# 5 Что можно было сделать лучше?

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

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

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

Всем, кто хочет увидеть примеры из реальной жизни Discovery Phase, подготовленные на основе конкретной идеи приложения: загрузите нашу новую БЕСПЛАТНУЮ электронную книгу ниже!

Вы узнаете из него:

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

Заключение

Помните, что любой подход может быть правильным для вашего проекта. Главный индикатор успеха — достижение целей проекта или бизнес-задач. Мы настоятельно рекомендуем вам потратить некоторое время на Ретроспективу проекта с командой проекта и руководства. Для этой системы очень важна возможность сравнить план проекта с полученным результатом. Этот метод универсален и позволит вам оценить многие ваши ИТ-проекты.В результате реализации успешного проекта вы можете создать ценный продукт или услугу. Продолжать!

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

Автор

Катажина Дерень, специалист по контент-маркетингу

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

стратегий оценки проектов | Малый бизнес

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

Метрики проекта

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

Временные рамки оценки

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

Управление данными

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

Соображения

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