Как экономить 30% времени на оценке проекта или зачем нужен аналитик на пресейле

Привет! На связи Евгений Крылов — CEO & founder digital-агентства nopreset. Мы создаём, развиваем и поддерживаем интернет-магазины, мобильные приложения и сложные системы для бизнеса.

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

Попросили нашего бизнес-аналитика Светлану рассказать о том, как устроен этот процесс в nopreset сейчас.

1. Чем занимается аналитик на пресейлах?

2. Что входит в верхнеуровневое проектирование?

3. Для чего/кого это нужно?

4. Результаты деятельности аналитика на пресейлах

Многие считают, что проект начинается с момента заключения договора с клиентом. А если я скажу, что это не так? До заключения договора проводится обширная предпродажная работа по поиску и квалификации клиентов — пресейл.

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

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

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

Рассмотрим подробнее каждый этап работ аналитика в рамках пресейлов.

1. Подготовка к брифу

Предусловие: Аналитик получает задачу от менеджера по продажам с кратким описанием заказчика, сути будущего проекта, а также всеми документами, присланными заказчиком.

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

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

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

2. Проведение брифа

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

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

По итогам брифинга у аналитика должна сложиться полная верхнеуровневая картина будущего проекта.

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

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

3. Составление документа «О концепции и границах»

Аналитик собрал всю необходимую информацию о проекте и приступает к верхнеуровневому проектированию.

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

По результатам проектирования создается документ «О концепции и границах». Документ содержит:

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

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

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

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

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

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

Напомним, как проходили процессы:

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

Получились следующие результаты:

В среднем, члены команды разработки тратили около 83 минут на оценку проекта. Теперь, несмотря на увеличение объема информации с которой требуется ознакомиться, показатель упал до 57 минут.

Вывод: Новый процесс экономит около 30 минут времени членов команды при оценке трудозатрат на проект.

Оценки трудозатрат всегда давались промежутками «от Х часов до Y часов» на тот или иной раздел. Это явление связано с тем, что на этапе предпродаж не уточняются мелкие детали и нет готовой реализации, поэтому оценки даются приблизительные. Мы просчитали среднюю погрешность, которую давали члены команды на трудозатраты (разница между минимальной и максимальной оценкой на весь проект). По старому процессу средняя погрешность составляла 79,17 часа. В новом процессе погрешность составляет 52,08 часа.

Вывод: Детализация описания проекта повысила точность оценки трудозатрат.

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

Можно сделать общие выводы:

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

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

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

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

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

Автор материала: Илясова Светлана Юрьевна— бизнес-аналитик nopreset