Цикл статей про бизнес-анализ на пресейле. Статья четвертая, или как рассчитать оценку трудозатрат на задачи бизнес-аналитика?

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

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

Ограничения и преимущества разных методов оценки

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

Сама по себе оценка трудозатрат ничего не значит, цифры всегда нужно подкреплять описанием объема работ, результатами (deliverables) и предположениями. BABOK содержит 7 методов, которые можно использовать при оценке трудозатрат. У каждого есть свои ограничения и преимущества, а также один подход можно дополнять другим.

Top-down метод

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

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

Bottom-up метод

К этому методу можно обратиться, когда после изучения RFP уже хорошо понятен весь объем работ. Суть bottom-up эстимации в том, что вся фаза бизнес-анализа разбивается на более мелкие задачи, для которых проще определить сроки выполнения. Затем результаты суммируются в итоговую оценку. При таком подходе аналитик рассматривает элементы более низкого уровня и детализирует функциональность. Артефактами станут фича-листы и декомпозиция работ (work breakdown structure, или WBS). Точность оценки может быть достаточно высокой, но и времени потребуется много.

Parametric estimation

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

Rough order of magnitude (ROM)

Как и Top-down подход, этот метод подойдет при недостатке информации или времени, когда возможно сделать только высокоуровневое описание решения. Эксперт, к примеру, senior-аналитик, дает субъективную оценку, исходя из своего опыта. Важно понимать, что точность такой оценки будет варьироваться в диапазоне от -50% до +50% или -25% до +75%. И лучше перепроверить ее с помощью другого метода.

Rolling waves

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

Delphi

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

Pert

Этот метод еще называют «оценка по трем точкам». Нужно рассчитать оптимистическую, пессимистическую и наиболее вероятную оценки. Для подготовки каждой из них можно использовать любой из перечисленных подходов. Затем к полученным значениям применяется формула: (оптимистическая + пессимистическая + 4 вероятных оценки) / 6. Pert эффективен для оценки задач с большим количеством неопределенности и рисков, когда вероятные разные сценарии развития проекта.

Как выбрать метод расчета оценки и что еще важно учитывать?

Точность оценки на пресейле зависит от многих факторов: от времени, в течение которого нужно сделать эстимацию, полученной от клиента информации, типа контракта (fixed price или times and material). Чем понятнее объем работ, тем точнее будет оценка, так как можно сделать низкоуровневое описание решения и детализировать функциональность. Если у клиента есть только идея или общее представление о проекте, то логичнее предложить Discovery-фазу, по итогам которой уже будет подготовлен фича-лист и оценка.

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

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

Для подготовки  оценки удобно использовать систему для управления проектами Microsoft Project (есть много похожих инструментов, например, Wrike, LiquidPlanner, Concept Draw). В MS Project можно внести активности бизнес-аналитика по фазам и задачам, расставить оценки в часах и длительность в рабочих днях, выбрать старт работы, назначить ресурсы (поставить тайтл и уровень сеньорити бизнес-аналитика). Чтобы сделать календарный план, нужно добавить зависимости между задачами (колонка predecessors), то есть определить их последовательность. Все эти связи будут визуализированы в диаграмме Ганта – справа от списка задач.

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

Автор: Мария Заяц