Оценка трудозатрат

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

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

Тогда это застало врасплох.

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

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: Сколько времени это займет?

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

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

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

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: Не знаю часов 600?

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200часов.

Не очень люблю вспоминать тот день.

Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?

Цель проведения оценки

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

Оценка объема работы используется в основном в двух целях:

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

• Выставление счета клиенту.

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

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

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

Допустим, в вашей команде разработчиков три человека. Каждый работает по 40часов в неделю это примерно 160часов в месяц, или 480часов в квартал (на троих примерно 1500часов).

Представьте, что ваша команда должна выполнить пять проектов с оценками объемов работ 800, 400, 300, 200 и 50часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки на случай, если разработка займет больше времени, чем предполагалось.

С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50часов, и при этом осталась бы некоторая свобода для маневра.

Выставление счета клиенту

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

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

Примечание. Это применимо не ко всем компаниям разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.

Ключевые факторы при оценке

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

1. Не оценивайте, сколько времени понадобится ВАМ

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

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

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

2. Не занижайте завышайте

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

Если разработчики выйдут за отведенный вами срок, это нарушит график работ.

Находиться в границах 20% это нормально, но только если оценка оказалась завышена а не занижена.

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

3. Повышение квалификации

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

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

4. Примеры аналогичных проектов

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

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

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

5. Не забывайте об аналитиках

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

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

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

Заключение

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

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

Если резюмировать самое главное, запомните вот что:

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

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

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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

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

Как происходит оценка проекта

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

• созваниваться с клиентом для уточнения требований, согласования вариантов решения и стека технологий;

• курировать процесс оценки;

• предлагать варианты реализации;

• оценивать и закладывать риски;

• определять состав команды разработки;

• составлять предварительный роадмап проекта.

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

• требования клиента изменились, например, он подготовил более детальное ТЗ и макеты;

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

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

Риски и трудозатраты на управление

При оценке нужно учитывать трудозатраты на управление проектом (Project Management или PM), в том числе:

• распределение и контроль выполнения задач

• проведение митингов;

• коммуникации с заказчиком продукта и устранение препятствий;

• ретроспективы с командой;

• демо с заказчиком;

• работа с метриками и оценка рисков.

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

• команда часто перерабатывает, причем больше, чем на 10-15%;

• ТЗ постоянно меняется, а тестовая документация при этом не обновляется;

• фактическое время выполнения задачи сильно превышает планируемое.

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

Оценка трудозатрат

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

1. Приемка приложения

2. Аналитика и дизайн

3. Непосредственная разработка и интеграция с другими IT-системами

4. Тестирование и обеспечение качества (QA)

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

Веб-приложение

Мы посчитали, в каком соотношении в этих проектах распределялись трудозатраты по разным видам работ (в процентах):

• Аналитика 7%

• Backend 30%

• Frontend 24,6%

• Тестирование 15%

• Управление 22%

Как показывает практика, разработка занимает около 50-60% от общих сроков реализации веб-приложения.

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

Мобильная разработка

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

В веб-проектах трудозатраты распределились так:

• Аналитика 3,8%

• Backend 18,9%

• iOS 16,1%

• Android 25,8%

• Тестирование 25,1%

• Управление 10,3%

По нашим оценкам, Backend- и мобильная разработка в среднем составили около 60% трудозатрат.

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

Особенности расчетов

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

Заключение

В этой статье мы рассчитали особенности распределения трудозатрат в разных видах продуктов. В наших веб-проектах разработка составила в среднем 50% от общих трудозатрат, а в мобильных проектах около 60%.

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

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

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

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

С этой темой я выступал на ArchDays 2020. По ссылке вы найдете слайды и видео (скоро будет опубликовано) выступления https://blog.byndyu.ru/2020/12/archdays-2020.html.

1 Изменение подхода к работе с мастер-данными

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

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

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

1. анализ схемы данных монолита,

2. анализ потоков обработки данных,

3. анализ использования данных сторонними системами,

4. бизнес-цели компании по работе с данными,

5. "нарезка" данных по новым базам,

6. миграция данных в новые базы микросервисов,

7. тестирование миграции.

Четыре основные стратегии работы с мастер-данными описаны в статье Управления мастер-данными в микросервисной архитектуре.

Как и остальные 9 факторов, переработку мастер-данных нужно оценивать и учитывать в бюджете перехода на микросервисы еще до старта перехода.

2 Невозможность переиспользования исходного кода монолита

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

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

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

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

3 Проектирование системы заново

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

Запланируйте время IT-архитектора, бизнес-аналитиков и стейкхолдеров на анализ бизнес-требований. Кроме этого, запланируйте время на проектирование API будущей системы.

4 Создание нового подхода к управлению инфраструктурой

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

Что нужно учесть в оценке:

1. Создание инфраструктуры для управления API: анализ вызовов, система прав, публикация API и т.д. Для примера рекомендую посмотреть функциональность Apigee.

2. Переход DevOps-инженеров на работу только в концепции IaC и контейнеризацию.

3. Реализовать тотальное логирование и мониторинг микросервисной архитектуры.

5 Измерение и проверка SLA каждого микросервиса

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

Для любителей SRE уточню, что здесь было бы правильнее использовать термин SLO, потому что SLA = SLO + санкции за нарушение договоренностей.

Другими словами, ранее неявный SLA становятся явными и требует проработки:

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

6 Микросервисы добавят на порядок больше точек отказа

Вместе со значительным увеличением числа сервисов по сравнению с монолитом, вы получаете рост точек интеграции, усложнение процесса CI/CD и распределение мастер-данных, что значительно усложнит всю инфраструктуру. Шанс получить проблему на проде будет очень высоким, если целенаправлено не вкладываться в fault tolerance на всех уровнях: проектирование архитектуры, разработка и тестирование.

Чтобы создавать стабильные системы, выдерживающие "толчки" внешней среды, заложите в бюджет перехода на микросервисы следующее:

1. Нагрузочное и стресс-тестирование, и, в идеале, применение chaos engineering.

2. Применение шаблонов проектирования, таких как Circuit Breaker и Tolerant Reader.

3. Настройка инфраструктуры: service discovery, health-check,...

7 Реорганизация команд

Когда монолит распадется на много маленьких независимых микро-систем, то встанет вопрос, как теперь организоваться людей вокруг этого "роя"?

Общее решение звучит так: создавайте кросс-функциональные команды (build-and-run team) под каждый микросервис. Но есть нюансы. До старта работ обсудите и выберете какая оргструктура подойдет под ваши задачи и ваш бизнес. Обратите внимание на следующее:

1. Выберите подход к распределению ответственности команд между микросервисами. Например, возьмите вот такой Service per team.

2. Примерьте на себя InnerSource, чтобы разгрузить команды микросервисов от входящих запросов. InnerSource и микросервисы хорошо работаю вместе.

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

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

Ремарка о постепенности перехода

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

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

8 Обратная совместимость с монолитом

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

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

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

9 Интеграция и обучение служб поддержки

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

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

10 Догоняющий поток фич от бизнеса

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

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

1. Заранее договориться с командой, разрабатывающей монолит о правилах совместной работы.

2. Договориться с бизнесом о процессе внесения новых фич в период жизни обеих систем.

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

Чеклист

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

1. Мастер-данные

2. Написание кода по-новому

3. Проектирование IT-продукта заново

4. Создание новой инфраструктуры

5. Измерение и проверка SLA

6. Вклад в fault tolerance на всех уровнях

7. Реорганизация команд

8. Работы по обратной совместимости

9. Интеграция служб поддержки

10. Догоняющий поток фич

Если в плане перехода вы учли все пункты, то скорее всего довольно точно попадете в оценку.

После всего описанного выше вы могли задуматься, зачем вообще переходить на микросервисы, если это так долго и дорого? Ответ на этот вопрос есть, например, в моем выступлении на AgileDays 2017 и в описании на microservices.io. Чтобы принять взвешенное решение о переходе, а не просто пойти за модой, желательно оценить плюсы и минусы для вашей конкретной ситуации.

Ссылки для погружения:

1. The Death of Microservice Madness in 2018, Dave Kerr

2. The hidden costs of microservices, Wayne Geils, Mike Hostetler

3. Microservice Trade-Offs, Martin Fowler

4. Pattern: Microservice Architecture, Chris Richardson

5. The Hidden Costs of Microservices, Justin Leitgeb

6. Challenges and benefits of the microservice architectural style Part 1 + Part 2, Andr Fachat

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

Предлагаем 7 вариантов оценки эффективности презентации:

• По цели достигнута или нет

• По переходам поставьте специальную ссылку

• По реакции аудитории сделайте голосование

• По обратной связи проведите опрос

• По публикациями в СМИ посчитайте упоминания

• По тиражированию оцените количество скачиваний

• По чек-листу самооценка.

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

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

"Как прошло? Этот вопрос спикер слышит от своего партнера, коллег, подписчиков в Facebook или организаторов. Ответ зависит от цели выступления, которую спикер ставил. Для одних успех - когда спросили кто вам сделал такую красивую презентацию?. Кто-то ждет предложения от потенциального партнера о встрече на завтра. Третьим важно увидеть выдержки из слайдов в СМИ", - говорит Виктория Рындина, MBA по коммуникациям, соосновательстудии дизайна иноформацииVisualMethod.

Давайте пройдемся по каждому пункту оценки эффективности презентации и разберем на примерах.

1. Оцените эффективность презентации по цели

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

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

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

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

Метрики:

• Достигли SMART-цели или нет.

2. Сделайте UTM-ссылку для презентации

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

Через QR-код участник сможет перейти по ссылке прямо во время мероприятия. Также презентацию можно встраивать в воронку Цель-Презентация-Лендинг-Целевое действие.

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

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

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

Метрики:

• Количество переходов

• % перешедших по ссылке от общего числа участников

• Глубина просмотра

• Время на сайте

• % отказов

• Количество загрузок файлов

• Количество подписок/покупок

3. Замерьте знание аудитории во время выступления

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

Для создания опроса в режиме реального времени можно воспользоваться бесплатным сервисомMentimeterили создать опрос в мобильном приложении для мероприятия, если организаторы его используют.

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

Метрики:

• % вовлеченных участников от общего числа

• % ответов участников, которые совпадают с целевой информацией

4. Соберите обратную связь о вашей презентации.

Есть три варианта.

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

Быстрый. Добавьте ссылку на опрос на последнюю страницу презентации и предложите всем, кто его пройдет, какой-то бонус. Удобнее для участников получить ссылку, если у вас презентация для отправки, или QR-код, если презентация оффлайн. Создать анкету можно с помощьюГуглилиЯндексформ. Так вы сможете сразу увидеть результаты и проанализировать как средние показатели, так и отдельные ответы.

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

• Сделали/сделают участники то, на что вы надеялись?

• Разделяют ваши идеи? Думали об этом раньше, а может уже внедряли? Если да, то какой опыт получили?

• Как оценивают презентацию? Легко читалась, что зацепило?

Метрики:

• % участников опроса

• статистика о качестве презентации и желании выполнить целевое действие

• Качественный анализ презентации и выступления

5. Проанализируйте активность в соцсетях и СМИ

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

Замерить распространение информации в социальных сетях и СМИ, упоминание вашего имени можно с помощью платных автоматизированных сервисов Медиалогия, Интерфакс СКАН,Brand Analytics. Из бесплатных систем используйте Яндекс.Новости или Гугл.Новости. Количество публикаций вряд ли вам даст понимание об эффективности, а вот цитаты из презентации покажут, насколько она была полезной.

Метрики:

• Охват аудитории

• Прирост подписчиков в соцсетях

• Количество упоминаний

• Тональность упоминаний

• Количество лайков, комментариев, репостов

6. Узнайте, сколько раз скачали вашу презентацию

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

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

Метрики:

• Количество скачиваний

• Переходы из презентации на целевые страницы

7. Оцените эффективность презентации и выступления по чек-листу

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

В финале

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

Хотите знать об оформлении презентаций больше? Посмотрите большое руководство Как избежать самых популярных ошибок в презентациях для публичных выступлений (можно скачать без ссылок и регистраций). VisualMethod сделал его вместе с топ-организаторами конференций в России.