Project Expert — компьютерная система, предназначенная для создания финансовой модели нового или действующего предприятия независимо от его отраслевой принадлежности и масштабов. Построив при помощи Project Expert финансовую модель собственного предприятия или инвестиционного проекта, Вы получаете возможность:
разработать детальный финансовый план и определить потребность в денежных средствах на перспективу;
определить схему финансирования предприятия, оценить возможность и эффективность привлечения денежных средств из различных источников;
разработать план развития предприятия или реализации инвестиционного проекта, определив наиболее эффективную стратегию маркетинга, а также стратегию производства, обеспечивающую рациональное использование материальных, людских и финансовых ресурсов;
проиграть различные сценарии развития предприятия, варьируя значения факторов, способных повлиять на его финансовые результаты;
сформировать стандартные финансовые документы, рассчитать наиболее распространенные финансовые показатели, провести анализ эффективности текущей и перспективной деятельности предприятия;
Как быстро и точно провести оценку проекта?
подготовить безупречно оформленный бизнес-план инвестиционного проекта, полностью соответствующий международным требованиям на русском и нескольких европейских языках.
Работа с Project Expert может быть представлена в виде следующих основных шагов:
Определение потребности в финансировании
Разработка стратегии финансирования
Анализ финансовых результатов
Формирование и печать отчета.
Ввод и анализ данных о текущем состоянии проекта в процессе его реализации.
Процесс построения модели наиболее трудоемкий и требует значительной подготовительной работы по сбору и анализу исходных данных. Различные модули Project Expert независимы и доступны пользователю практически в любой последовательности. Однако, отсутствие некоторых необходимых исходных данных может блокировать доступ к другим модулям программы. Независимо от того разрабатываете ли Вы детальный финансовый план или хотите произвести предварительный экспресс-анализ проекта Вы должны в первую очередь ввести следующие исходные данные:
дата начала и длительность проекта;
перечень продуктов и/или услуг, производство и сбыт которых будет осуществляться в рамках проекта;
валюта расчета или две валюты расчета для платежных операций на внутреннем и внешнем рынках, а также их обменный курс и прогноз его изменения;
перечень, ставки и условия выплат основных налогов;
для действующего предприятия также следует описать состояние баланса, включая структуру и состав имеющихся в наличие активов, обязательств и капитала предприятия на дату начала проекта.
Следующим этапом процесса построения модели является описание плана развития предприятия (проекта). Для этого необходимо ввести следующие исходные данные:
инвестиционный план, включая календарный план работ с указанием затрат и используемых ресурсов;
Как провести предварительную оценку IT-проекта с нуля. Технореволюция 2.0
операционный план, включая стратегию сбыта продукции или услуг, план производства, план персонала, а также производственные издержки и накладные расходы;
Определение потребности в финансировании
Для определения потребности в финансировании следует произвести предварительный расчет проекта. В результате предварительного расчета определяется эффективность проекта без учета стоимости капитала, а также определяется объем денежных средств, необходимый и достаточный для покрытия дефицита капитала в каждый расчетный период времени с шагом один месяц.
Разработка стратегии финансирования предприятия
После определения потребности в финансировании разрабатывается план финансирования. Пользователь имеет возможность описать два способа финансирования:
посредством привлечения акционерного капитала;
посредством привлечения заемных денежных средств.
В процессе разработки стратегии финансирования проекта пользователь имеет возможность промоделировать объем и периодичность выплачиваемых дивидендов, а также стратегию использования свободных денежных средств (например: размещение денежных средств на депозит в коммерческом банке или приобретение акций сторонних предприятий).
Анализ эффективности проекта
В процессе расчетов Project Expert автоматически генерирует стандартные отчетные бухгалтерские документы:
отчет о прибылях и убытках;
отчет о движении денежных средств;
отчет об использовании прибыли.
На основе данных отчетных бухгалтерских документов осуществляется расчет основных показателей эффективности и финансовых коэффициентов.
Пользователь может разработать несколько вариантов проектов в соответствии с различными сценариями их реализации. После определения наиболее вероятного сценария проекта он принимается за базовый. На основе базового варианта проекта производится анализ чувствительности и определяются критические значения наиболее важных факторов, влияющих на финансовый результат проекта.
После завершения анализа проекта формируется отчет. В Project Expert предусмотрен специальный генератор отчета, который обеспечивает компоновку и редактирование отчета по желанию пользователя. В отчет могут быть встроены не только стандартные графики и таблицы, но также таблицы и графики, построенные пользователем при помощи специального редактора.
Также пользователь имеет возможность встраивания в отчет комментариев в виде текста.
Контроль за ходом реализации проекта
В Project Expert предусмотрены средства для ввода фактической информации о ходе реализации проекта. Актуальная информация может вводиться ежемесячно. На основе введенной актуальной информации и плана формируется отчет о рассогласованиях плановой и фактической информации, которая может быть использована в процессе управления проектом.
Project Expert можно использовать для количественной оценки риска инвестиционного проекта предлагается использовать следующие алгоритмы:
Алгоритм имитационного моделирования (инструмент “РИСК-АНАЛИЗ”):
1.Определяются ключевые факторы ИП. Для этого предлагается применять анализ чувствительности по всем факторам (цена реализации, рекламный бюджет, объём продаж, себестоимость продукции и т. д.), используя специализированные пакеты типа Project Expert и Альт-Инвест, что позволит существенно сократить время расчётов. В качестве ключевых выбираются те факторы, изменения которых приводят к наибольшим отклонениям чистой текущей стоимости (NPV).
2. Определяются максимальное и минимальное значения ключевых факторов, и задаётся характер распределения вероятностей. В общем случае рекомендуется использовать нормальное распределение.
3. На основе выбранного распределения проводится имитация ключевых факторов, с учётом полученных значений рассчитываются значения NPV.
4. На основе полученных в результате имитации данных рассчитываются критерии, количественно характеризующие риск ИП (матожидание NPV, дисперсия, среднеквадратическое отклонение и др.).
Для проведения сценарного анализа разработана методика [ 3 ], позволяющая учитывать все возможные сценарии развития, а не три варианта (оптимистичный, пессимистичный, реалистичный), как это предлагается в литературе. Предлагается следующий алгоритм сценарного анализа:
Алгоритм сценарного анализа
1.Используя анализ чувствительности, определяются ключевые факторы ИП (см. выше).
2.Рассматриваются возможные ситуации и сочетания ситуаций, обусловленные колебаниями этих факторов. Для этого рекомендуется строить “дерево сценариев”.
3.Методом экспертных оценок определяются вероятности каждого сценария.
4.По каждому сценарию с учетом его вероятности рассчитывается NPV проекта, в результате чего получается массив значений NPV
5. На основе данных массива рассчитываются критерии риска ИП
В общем же случае для определения ключевых параметров проекта можно использовать анализ чувствительности, в качестве оптимального инструмента для этого рекомендуется применять соответствующий модуль анализа программных пакетов “Project Expert” и “Альт-Инвест”, которые обеспечивают возможность быстрого пересчёта по всем факторам. Хотя в большинстве случаев ключевые факторы проекта известны из предыдущего опыта, либо установлены по результатам маркетингового исследования, а анализ чувствительности необходим лишь для количественного определения степени влияния этого фактора.
Моделируя значение NPV в зависимости от ключевых факторов были получены значения NPV по трём опорным вариантам развития событий (оптимистичный, пессимистичный, реалистичный). Методом экспертных оценок были определены также вероятности реализации этих вариантов. Полученные результаты использовались как исходные данные для имитационного моделирования.
На основе исходных данных проводим имитацию. Для проведения имитации рекомендуется использовать функцию “Генерация случайных чисел” Для осуществления имитации рекомендуется использовать нормальное распределение, так как практика риск-анализа показала, что именно оно встречается в подавляющем большинстве случаев. Количество имитаций может быть сколь угодно большим и определяется требуемой точностью анализа.
На основе полученных в результате имитации данных, используя стандартные функции MS Excel проводим экономико-статистический анализ Имитационное моделирование продемонстрировало следующие результаты:
Пусть, например, получены такие результаты:
Среднее значение NPV составляет 15950,79 тыс. руб.
Минимальное значение NPV составляет 15940,15 тыс. руб.
Максимальное значение NPV составляет 15962,98 тыс. руб.
Коэффициент вариации NPV равен 12%
Число случаев NPV < 0 – нет.
Вероятность того, что NPV будет меньше нуля равна нулю.
Вероятность того, что NPV будет больше максимума также равна нулю.
Вероятность того, что NPV будет находится в интервале [M(E) + s; max] равна 16%.
Вероятность того, что NPV будет находиться в интервале [M(E) — s; [M(E)] равна 34%.
Оценим риск данного инвестиционного проекта.
Для расчёта цены риска в данном случае используем показатель среднеквадратического отклонения — s, и матожидания – М (NPV). В соответствии с правилом “трёх сигм”, значение случайной величины, в данном случае – NPV, с вероятностью близкой 1 находится в интервале [М-3s; М+3s ]. В экономическом контексте это правило можно истолковать следующим образом:
-вероятность получить NPV проекта в интервале [15950,79-3,58; 15950,79 +3,58] равна 68%;
-вероятность получить NPV проекта в интервале [15950,79-7,16; 15950,79 +7,16] равна 94%;
-вероятность получить NPV проекта в интервале [15950,79-10,74; 15950,79 +10,74] близка к единице, т.е. вероятность того, что значение NPV проекта будет ниже 15 940,05 тыс. руб. (15950,79-10,74) стремится к нулю.
Таким образом, суммарная величина возможных потерь характеризующих данный инвестиционный проект, составляет 10,74 тыс. руб. (что позволяет говорить о высокой степени надёжности проекта).
Иначе говоря, цена риска данного ИП составляет 10,74 тыс. рублей условных потерь, т.е. принятие данного инвестиционного проекта влечёт за собой возможность потерь в размере не более 10,74 тыс. руб.
Рекомендуется использовать сценарный анализ только в тех случаях, когда количество сценариев конечно, а значения факторов дискретны. Если же количество сценариев очень велико, а значения факторов непрерывны, рекомендуется применять имитационное моделирование.
Следует отметить, что, используя сценарный анализ можно рассматривать не только три варианта, а значительно больше. При этом можно сочетать сценарный анализ с другими методами количественного анализа рисков, например, с методом дерева решений и анализом чувствительности.
Эффективность применения описанных технологий инвестиционного проектирования обусловлена тем, что они могут быть легко реализованы обычным пользователем ПК в среде MS Excel, а универсальность математических алгоритмов, используемых в технологиях, позволяет применять их для широкого спектра ситуаций неопределённости, а также модифицировать и дополнять другими инструментами.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Предварительная оценка программного проекта
В качестве иллюстрации применения методики оценки, изложенной в разделе «Выполнение оценки проекта на основе LOC- и FP-метрик», рассмотрим конкретный пример. Предположим, что поступил заказ от концерна «СУПЕРАВТО». Необходимо создать ПО для рабочей станции дизайнера автомобиля (РДА). Заказчик определил проблемную область проекта в своей спецификации:
- ПО РДА должно формировать 2- и 3-мерные изображения для дизайнера;
- дизайнер должен вести диалог с РДА и управлять им с помощью стандартизованного графического пользовательского интерфейса;
- геометрические данные и прикладные данные должны содержаться в базе данных РДА;
- модули проектного анализа рабочей станции должны формировать данные для широкого класса дисплеев SVGA;
- ПО РДА должно управлять и вести диалог со следующими периферийными устройствами: мышь, дигитайзер (графический планшет для ручного ввода), плоттер (графопостроитель), сканер, струйный и лазерный принтеры.
Прежде всего надо детализировать проблемную область. Следует выделить базовые функции ПО и очертить количественные границы. Очевидно, нужно определить, что такое «стандартизованный графический пользовательский интерфейс», какими должны быть размер и другие характеристики базы данных РДА и т. д. Будем считать, что эта работа проделана и что идентифицированы следующие основные функции ПО: 1. Средства управления пользовательским интерфейсом СУПИ. 2. Анализ двухмерной графики А2Г. 3. Анализ трехмерной графики А3Г. 4. Управление базой данных УБД. 5. Средства компьютерной дисплейной графики КДГ. 6. Управление периферией УП. 7. Модули проектного анализа МПА. Теперь нужно оценить каждую из функций количественно, с помощью LOC-оценки. По каждой функции эксперты предоставляют лучшее, худшее и вероятное значения. Ожидаемую LOC-оценку реализации функции определяем по формуле LOCожi =(LOCлучшi +LOCхудшi +4 х LOCвероятнi)/6, результаты расчетов заносим в табл. 2.22. Таблица 2.22. Начальная таблица оценки проекта
| Функция | Лучш. [LOC] | Вероят. [LOC] | Худш. [LOC] | Ожид. [LOC] | Уд. стоимость[$/LОС] | Стоимость[$] | Произв. [LOC/ [чел-мес] | Затраты [чел-мес] |
| СУПИ | 1800 | 2400 | 2650 | 2340 | ||||
| А2Г | 4100 | 5200 | 7400 | 5380 | ||||
| АЗГ | 4600 | 6900 | 8600 | 6800 | ||||
| УБД | 2950 | 3400 | 3600 | 3350 | ||||
| КДГ | 4050 | 4900 | 6200 | 4950 | ||||
| УП | 2000 | 2100 | 2450 | 2140 | ||||
| МПА | 6600 | 8500 | 9800 | 8400 | ||||
| Итого | 33360 | |||||||
Для определения удельной стоимости и производительности обратимся в архив фирмы, где хранятся данные метрического базиса, собранные по уже выполненным проектам. Предположим, что из метрического базиса извлечены данные по функциям-аналогам, представленные в табл. 2.23. Видно, что наибольшую удельную стоимость имеет строка функции управления периферией (требуются специфические и конкретные знания по разнообразным периферийным устройствам), наименьшую удельную стоимость — строка функции управления пользовательским интерфейсом (применяются широко известные решения). Таблица 2.23. Данные из метрического базиса фирмы
| Функция | LOCанi | УД_СТОИМОСТЬанi[$ /LOC] | ПРОИЗВанi[LOC/чел-мес] |
| СУПИ | 585 | 14 | 1260 |
| А_Г | 3000 | 20 | 440 |
| УБД | 1117 | 18 | 720 |
| КДГ | 2475 | 22 | 400 |
| УП | 214 | 28 | 1400 |
| МПА | 1400 | 18 | 1800 |
Считается, что удельная стоимость строки является константой и не изменяется от реализации к реализации. Следовательно, стоимость разработки каждой функции рассчитываем по формуле СТОИМОСТЬi = LOCожi х УД_СТОИМОСТЬанi. Для вычисления производительности разработки каждой функции выберем самый точный подход — подход настраиваемой производительности: ПРОИЗВ i =ПРОИЗВанi х (LOC анi / LOCожi). Соответственно, затраты на разработку каждой функции будем определять по выражению ЗАТРАТЫ i = (LOCожi /ПРОИЗВ i)[чел.-мес]. Теперь мы имеем все необходимые данные для завершения расчетов. Заполним до конца таблицу оценки нашего проекта (табл. 2.24). Таблица 2.24. Конечная таблица оценки проекта
| Функция | Лучш. | Вероят. | Худш. | Ожид. [LOC] | Уд. стоимость [S/LOC] | Стоимость [$] | Произв. [LOC/ чел.-мес] | Затраты [чел-мес] |
| СУПИ | 1800 | 2400 | 2650 | 2340 | 14 | 32760 | 315 | 7,4 |
| А2Г | 4100 | 5200 | 7400 | 5380 | 20 | 107600 | 245 | 21,9 |
| A3Г | 4600 | 6900 | 8600 | 6800 | 20 | 136000 | 194 | 35,0 |
| УБД | 2950 | 3400 | 3600 | 3350 | 18 | 60300 | 240 | 13,9 |
| КДГ | 4050 | 4900 | 6200 | 4950 | 22 | 108900 | 200 | 24,7 |
| УП | 2000 | 2100 | 2450 | 2140 | 28 | 59920 | 140 | 15,2 |
| МПА | 6600 | 8500 | 9800 | 8400 | 18 | 151200 | 300 | 28,0 |
| Итого | 33360 | 656680 | 146 |
Учитывая важность полученных результатов, проверим расчеты с помощью FP-указателей. На данном этапе оценивания разумно допустить, что все информационные характеристики имеют средний уровень сложности. В этом случае результаты экспертной оценки принимают вид, представленный в табл. 2.25, 2.26. Таблица 2.25. Оценка информационных характеристик проекта
| Характеристика | Лучш. | Вероят. | Худш. | Ожид. | Сложность | Количество |
| Вводы | 20 | 24 | 30 | 24 | х 4 | 96 |
| Выводы | 12 | 15 | 22 | 16 | х 5 | 80 |
| Запросы | 16 | 22 | 28 | 22 | х 4 | 88 |
| Логические файлы | 4 | 4 | 5 | 4 | х 10 | 40 |
| Интерфейсные файлы | 2 | 2 | 3 | 2 | х 7 | 14 |
| Общее количество | 318 |
Таблица2.26.Оценка системных параметров проекта
| Коэффициент регулировки сложности | Оценка | |
| F1 | Передачи данных | 2 |
| F2 | Распределенная обработка данных | |
| F3 | Производительность | 4 |
| F4 | Распространенность используемой конфигурации | 3 |
| F5 | Скорость транзакций | 4 |
| F6 | Оперативный ввод данных | 5 |
| F7 | Эффективность работы конечного пользователя | 5 |
| F8 | Оперативное обновление | 3 |
| F9 | Сложность обработки | 5 |
| F10 | Повторная используемость | 4 |
| F11 | Легкость инсталляции | 3 |
| F12 | Легкость эксплуатации | 4 |
| F13 | Разнообразные условия размещения | 5 |
| F14 | Простота изменений | 5 |
Таким образом, получаем: FР = Общее количество х (0,65+ 0,01 х
) = 318 x 1,17 = 372. Используя значение производительности, взятое в метрическом базисе фирмы, Производительность = 2,55 [FP / чел.-мес], вычисляем значения затрат и стоимости: Затраты = FP / Производительность = 145,9 [чел.-мес], Стоимость = Затраты х $4500 = $656500. Итак, результаты проверки показали хорошую достоверность результатов. Но мы не будем останавливаться на достигнутом и организуем еще одну проверку, с помощью модели СОСОМО II. Примем, что все масштабные факторы и факторы затрат имеют номинальные значения. В силу этого показатель степени В = 1,16, а множитель поправки Мp= 1. Кроме того, будем считать, что автоматическая генерация кода и повторное использование компонентов не предусматриваются. Следовательно, мы вправе применить формулу ЗАТРАТЫ = A х РАЗМЕР B [чел.-мес] и получаем: ЗАТРАТЫ = 2,5(33,3) 1,16 =145,87 [чел.-мес]. Соответственно, номинальная длительность проекта равна Длительность = [3,0 х (ЗАТРАТЫ) (0,33+0,2( B- 1,01)) ]=3(145,87) 0,36 = 18[мес]. Подведем итоги. Выполнена предварительная оценка программного проекта. Для минимизации риска оценивания использованы три методики, доказавшие корректность полученных результатов.
Источник: studfile.net
Как сделать предварительную оценку ИТ-проекта эффективной
Эксперты ИТ-компании SimbirSoft накопили большой опыт предварительной оценки проектов и рассказывают об этом в статье, подготовленной для TAdviser.
В начале работы над ИТ-проектом, как правило, проводят оценку. Её отсутствие или неточность может сформировать неправильные ожидания по срокам и бюджету проекта.
В итоге может случиться так, что деньги, которые планировали направить на проект, закончились раньше срока или презентация продукта прошла, а одна из критически важных фич не до конца готова. Это может произойти по разным причинам, в частности, если состав команды разработки подобран неоптимально. Например, кому-то из специалистов не хватает экспертизы в выбранном стеке или не учтены все задачи, которые потребуется решить на проекте. Как правило, это становится следствием некорректной или недостаточной оценки.
За более чем 20 лет разработки ИТ-систем разной сложности мы в SimbirSoft накопили большой опыт предварительной оценки проектов. В среднем за год специалисты нашей компании анализируют по 400 идей клиентов, даже при отсутствии подробного технического задания или иной документации. Расскажем, как выстроенные в компании процессы позволяют проводить предварительную оценку ИТ-проекта быстро, точно и прозрачно.
Актуальные методы оценки ИТ-проекта
Выбор метода оценки будет зависеть от того, нужно ли реально оценить трудозатраты по проекту или просто определить потенциал клиента и соотнести с предполагаемыми затратами.
Если достаточно просто оценить потенциал, можно использовать метод аналогии и привести данные по похожим проектам. Очевидно, что для этого компании нужно иметь накопленную базу. Такой метод мы иногда используем, когда заказчику для каких-то целей нужна быстрая оценка. Как правило, она занимает от одного до трех часов. Ранкинг TAdviser100: Крупнейшие ИТ-компании в России 2023
Для более детальной оценки трудозатрат в большинстве ИТ-проектов подходит метод по фичам. Мы чаще всего используем именно его. При таком способе проект декомпозируется, разбивается на фичи. Затем они описываются и оцениваются отдельно пресейлом каждого направления. Это позволяет увидеть, сколько времени на конкретную фичу потратит аналитик, дизайнер, фронт, бэк, QA и т.д.
Далее вся информация сводится в единый список.
По нашему мнению, такой подход позволяет учесть все необходимые работы и подобрать оптимальный состав команды специалистов. Сроки выполнения предварительной оценки методом по фичам зависят от особенностей проекта: для стандартного приложения – до 8 часов при условии одновременного проведения оценки всеми экспертами сразу. Но в этом процессе могут участвовать специалисты нескольких направлений, поэтому в среднем предварительная оценка занимает 3-5 дней.
Есть два общепринятых варианта подсчета трудозатрат:
1. диапазонный метод (от X до Y часов), когда оценщик на основании своего опыта дает пессимистические и оптимистические данные по трудозатратам на фичу,
2. метод PERT – расчет выполняется по трем точкам:
где to – оптимистическое время – минимально возможная длительность выполнения задачи,
tp – пессимистическое время – максимально возможная длительность выполнения задачи,
tm – наиболее вероятное время – наиболее вероятная длительность выполнения задачи,
te – ожидаемое время – оценка длительности выполнения задачи на основе оценок оптимистического, пессимистического и наиболее вероятного времени.
Опираясь на наш проектный опыт, мы в SimbirSoft экспериментальным путем вывели формулу, которая позволяет проводить предварительную оценку ИТ-проекта без привлечения дополнительных экспертов. Этот алгоритм встроен в платформу Estimate. Но об этом чуть позже.
Как проходит предварительная оценка
Отправляя заявку в ИТ-компанию, заказчик обычно преследует одну из целей:
1. Просит оценить проект «под ключ». У него может быть определен объем задач и разработано техническое задание (ТЗ) или только объем задач без ТЗ.
2. Хочет узнать, что можно сделать в рамках определенного бюджета или в конкретные сроки.
Рассмотрим, как проходит процесс предварительной оценки ИТ-проекта. Расскажем на примере нашей компании.
Этап № 1 – обсуждение проекта и потребностей клиента
Чтобы выяснить все детали по проекту, специалист компании (обычно сотрудник отдела продаж) организует созвон с клиентом. Один из способов получить необходимые для предварительной оценки данные – вместе с клиентом заполнить бриф и ответить на ключевые вопросы о будущем ИТ-продукте. Основными из них мы поделимся в чек-листе в конце статьи. Но обычно беседа с клиентом проходит в свободной форме. Это позволяет выявить действительно важные для него и его бизнеса аспекты.
После этого разговора мы понимаем, достаточно ли клиенту дать оценку «по аналогии» или нужна более детальная оценка по фичам, и есть ли у нас вся необходимая информация для проведения предварительной оценки.
На этом этапе формируются ответы на ключевые вопросы:
- Границы разработки – какие этапы работы нам нужно оценить (и в перспективе выполнить), а какие клиент берет на себя?
- Какие направления разработки стоит подключить к оценке?
- Какой стек будет предпочтителен?
- Что еще нужно заложить в оценку? Например, клиент решает, что дизайн будет разрабатывать сам. Значит, в оценку нужно включить время на приемку дизайна заказчика – проверить, соответствует ли дизайн функционалу системы.
Логично, что для корректной оценки требуется детальное описание реализации. Однако иногда мы проводим оценку и без технического задания. В этом случае аналитики, используя полученную в ходе обсуждения с клиентом информацию и свой практический опыт, составляют видение проекта, а именно – техническую концепцию с разбивкой по фичам для оценки.
Бывают случаи, когда у клиента есть просто идея, и данных для формирования технической концепции недостаточно. В таких ситуациях мы предлагаем заказчику начать проект с мини-аналитики, т.е. провести «дискавери-фазу».
Этап № 2 – presale
Далее к работе подключаются пресейлы направлений – специалисты, которые будут делать оценку ИТ-проекта по своей части. Модератор создает чат, куда подключаются все необходимые эксперты. В крупных компаниях этот подход позволяет специалистам провести оценку в удобное время, но в рамках четко установленных сроков. Поскольку все пресейлы – высококвалифицированные специалисты, и они постоянно задействованы на коммерческих проектах.
В чате оценки мы ведем всю переписку и обсуждение оценки, фиксируем договоренности и допущения, варианты реализации. Там же обмениваемся мнениями по поводу выбора стека, преимуществ и недостатков того или иного способа реализации, возможности применения готовых фреймворков и коробочных решений, необходимости проведения тех или иных работ.
- Например, если мы видим, что на конкретном проекте важен UX, добавляем работы по исследованию юзабилити, проверке гипотез на фокус-группах и т.п. А если есть требования к производительности, принимаем решение о необходимости выполнения нагрузочного тестирования.
Все сведения по оценке, ее статус и результаты храним в таск-трекере. Модератор вносит туда ключевую информацию, в том числе готовое коммерческое предложение, которое в итоге отправляем клиенту. В нашей компании есть строгие регламенты и требования к проведению оценок.
- Например: оценка разработки одной фичи не должна превышать 8 (в крайнем случае — 16) часов, а диапазон разброса минимальных и максимальных значений не должен превышать 40%. В ином случае возможен высокий уровень неопределенности в реализации фичи, что может привести к увеличению рисков проекта. Также есть обязательное требование, чтобы оценщик зафиксировал в комментариях, как он видит реализацию задачи за указанное время.
После того, как все оценщики завершили свою часть работы, проводим проверку оценки. Далее готовим описание и на основе сметы – примерный состав будущей команды ИТ-проекта, сроки реализации или roadmap. Для достижения качественных результатов мы подбираем слаженную команду с экспертизой в конкретной отрасли и опытом совместного решения задач.
Чтобы ускорить процесс оценки и сделать его более точным и прозрачным, мы в SimbirSoft используем свои наработки. И поскольку в работе стараемся выделять как можно более конкретные задачи, это позволяет анализировать «предстоящий фронт работ» точнее.
Платформа Estimate, о которой мы упоминали в начале, – это облачный аналог разработанного нами алгоритма предварительной оценки ИТ-проекта. Сервис дает возможность пользователям оценить трудозатраты на любые виды работ по проекту. С помощью встроенных в него шаблонов можно автоматизировать оценку и ускорить срок ее проведения. Причем им можно воспользоваться как бесплатно, так и приобрести расширенную корпоративную версию.
Этап № 3 – подготовка коммерческого предложения
По итогам проведенной оценки готовим коммерческое предложение и направляем клиенту. При необходимости модератор вместе с группой оценщиков проводит защиту оценки и презентацию коммерческого предложения клиенту и его потенциальным инвесторам. Ранее (до пандемии) мы выезжали в офис клиента, чтобы сделать этот процесс эффективнее и узнать друг друга перед возможным стартом проекта, сейчас делаем это в режиме онлайн.
Бывают кейсы, когда после ознакомления с оценкой клиент вносит корректировки: или изменились требования, или надо выделить MVP, уложиться в рамки изменившегося бюджета или сроки. В данном случае мы запускаем переоценку по изменившимся вводным данным той же самой командой. После согласования переходим к обсуждению договора и условий сотрудничества.
Перед стартом работ подобранная на проект команда вместе с клиентом еще раз проверяет оценку фич. К этому времени ситуация может измениться: необходимость в одних фунциональностях отпасть, для других выясниться подробности или возникнуть совершенно новые фичи, поскольку бизнес не стоит на месте.
- По правилам нашей компании, предварительная оценка актуальна в течение трех месяцев. Поскольку за большее время уже могли измениться и технологии, и видение проекта, и уровень экспертизы, что позволит предложить новое решение данной задачи. Поэтому если клиент приходит для реализации проекта через три месяца и позже, перед подписанием проекта мы еще раз переоцениваем его командой пресейла.
Выбор – за клиентом
Оценка трудозатрат – важный и ответственный этап при разработке ИТ-продукта. Она позволяет построить путь к достижению конечной цели заказчика – готовому решению. Поэтому требует внимательного подхода от ИТ-компании и клиента. И если экспресс-оценка «по аналогии» дает приблизительный результат, то детальная «по фичам» – более точный. Этот метод позволяет команде уделить оценке больше времени, задать заказчику дополнительные вопросы и погрузиться в проект еще до его старта.
Чек-лист: что подготовить к брифингу для оценки по фичам
Рассказываем, какие особенности будущей ИТ-системы владельцу продукта важно обсудить с подрядчиком перед началом оценки проекта по фичам. Для наибольшей объективности мы рекомендуем клиентам обсудить ответы вместе со своей командой. Еще раз подчеркнем, что это базовый набор вопросов, но в зависимости от особенностей проекта он может изменяться и дополняться.
Блок 1. Общее описание будущей ИТ-системы:
* Какие задачи она должна решать?
* Кто ей будет пользоваться, на каких устройствах и что можно будет делать с помощью этой ИТ-системы?
* Требования к производительности и нагрузке системы. Интеграция с какими внешними и внутренними сервисами предполагается и т.п.
* Есть ли у нее аналоги? Что в них нравится, а что нет?
Блок 2. Варианты сотрудничества:
* Предполагаемые зоны ответственности и формат работы над системой
* Будет ли команда заказчика принимать участие в разработке?
* Были ли уже какие-то наработки?
* Какие требования к code style, стандартам и сертификации предъявляются?
Блок 3. Реализация будущей ИТ-системы:
* Ожидания по срокам и бюджету.
* Предпочтения по архитектуре, стеку, фреймворкам, системе управления базами данных и т.п.
* Есть ли брендбук для разработки дизайна?
* Какую статистику/аналитику предполагается собирать? Планируется ли подключение внешних систем аналитики?
* Требуется ли нагрузочное и автоматизированное тестирование?
Если у вас остались вопросы, напишите нам на электронную почту
Источник: www.tadviser.ru