Как оценить эффективность разработанной программы

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

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

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

В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.

Как оценить эффективность команды / Алексей Катаев (Skyeng)

Уже трудно найти (по крайней мере, в открытых источниках) информацию об использовании в качестве метрики количества отработанных часов, числа строк в тексте исходного кода (SLOC), Function Points или количества багов, создаваемых каждым разработчиком.

В публичном дискурсе удалось прийти к консенсусу, что работать больше — не значит работать лучше, что решение с 200 строками кода может быть быстрее или производительнее, чем решение с 1 тыс. строками, а метрика Function Points, созданная в 1979 году, безнадежно устарела.

Но что вообще произошло с желанием все измерить и посчитать? Судя по всему, оно никуда не исчезло.

Netflix

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

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

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

Алгоритм / функция / дизайн (×) увеличение взаимодействия подписчиков с сервисом и, в конечном счете, их удержание.

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

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

Как оценить эффективность и окупаемость обучения

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

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

IBM

Самая старая и наиболее «очевидная» метрика для разработки программного обеспечения — подсчет числа строк, произведенных отдельным разработчиком или командой, и количества времени, потраченного на это. Впервые эту метрику использовали в IBM. В документальном фильме «Triumphof the Nerds: The Rise of Accidental Empires» Стив Баллмер заметил, что в 1980-х годах IBM, похоже, сделала из этого показателя «религию».

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

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

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

SpaceX

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

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

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

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

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

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

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

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

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

Amazon

Amazon обладает одной из самых интересных стратегий, изложенной в этом 40-минутном интервью с директором AWS Developer Tools.

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

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

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

Изначально Amazon имела монолитную структуру и архитектуру программного обеспечения (Perl/Mason/C++). Затем архитектура была декомпозирована на службы, а структура организации — на пицца-команды. Так облачный сервис Amazon Elastic Compute Cloud (Amazon EC2) был сформирован группой, состоящей всего из двух «пицца-команд».

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

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

Проверки встроены во все пайплайны посредством сочетания локальных и глобальных доверительных политик. Руководитель может самостоятельно устанавливать политику проверок для своей команды (например, перед деплоем каждый новый коммит на 70 % должен быть охвачен юнит-тестированием).

При этом существуют и общие правила Amazon, охватывающие каждый деплой (к примеру, запрет на единовременное развертывание в каждом регионе).

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

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

Что там у стартапов

Благодаря опросам, проведенным Stackify (облачная платформа для мониторинга и выявления неисправностей в веб-приложениях), удалось выяснить отношение к метрикам в некоторых известных стартапах и в компаниях «средней руки».

CircleCI — популярный, в том числе и в России, Continuous Integration-сервис с гибкой настройкой для веб и мобильных приложений. Роб Зубер, CTO CircleCI, считает, что лучшей метрикой для измерения производительности и эффективности разработки программного обеспечения является показатель времени, необходимого для перехода кода от коммитинга к развертыванию — Commit-to-Deploy Time (CDT).

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

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

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

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

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

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

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

Заключение

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

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

• Блог компании VK
• Программирование
• Управление разработкой
• Управление проектами
• История IT

Источник: habr.com

15 метрик разработки программного обеспечения для создания успешного продукта

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

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

Время чтения: 7 минут

Менеджерские метрики

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

Burn Rate

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

• конкретный спринт — это называется sprint burndown chart или диаграмма сгорания задач за спринт;
• весь проект — это называется release burndown chart или диаграмма сгорания задач до релиза.

График представляет собой кривые, идущие вниз: они показывают динамику решения задач. По шкале X отмечают количество дней до окончания спринта или до релиза. По шкале Y — число задач. Одна из линий графика демонстрирует то, как быстро планировалось выполнить работу. Вторая линия — то, как работа идет на самом деле. Диаграмма может выглядеть, например, так:

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

По диаграмме сгорания задач смотрят:

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

Хотите разобраться, чем полезна диаграмма сгорания задач на примере реального проекта? Читайте наш кейс:

READ MORE Фотографы, $250 тысяч инвестиций и 300 экранов «какого-то» дизайна. Кейс Purrweb

Flow Efficiency

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

Например, если над задачей работали 3 дня, а еще 2 она «висела» в ожидании, когда разработчик для нее освободится, формула эффективности потока будет: 3/(2+3) *100%.

Эта метрика разработки программного обеспечения служит, чтобы:

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

Team Velocity

Эта метрика разработки программного обеспечения демонстрирует, какой объем работы команда способна выполнить за спринт. Для вычисления показателя производительности в продуктовых командах используют стори поинты (story points) — с их помощью каждой задаче в бэклоге назначают вес в зависимости от ее сложности. Если вы работаете со студией, вместо стори поинтов оценка идет в часах: так всем проще и понятнее.

Сумма всех стори поинтов или всех часов за спринт — это и есть производительность.

Метрику используют, чтобы:

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

Среднее количество багов за спринт

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

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

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

READ MORE Проектный менеджмент и SCRUM: как, зачем и почему?

Технические метрики

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

Test Coverage

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

Специалистам компании по разработке программного обеспечения метрика помогает понять:

• достаточно ли тестов было проведено;
• насколько велик риск, что какие-то баги в программе остались незамеченными и попадут в релиз.

Скорость загрузки страниц

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

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

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

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

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

ER-диаграмма

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

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

Если с ней что-то не так, возможно:

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

Использование зрелого фреймворка

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

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

Хороший фреймворк дает следующие преимущества:

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

Например, мы в Purrweb для мобильной разработки используем React Native — это фреймворк JavaScript, поддерживаемый Facebook. В отличие от других технологий React Native позволяет экономить 30-35% времени и бюджета на создании приложений для iOS и Android.

Проверка дублирования кода

Этот показатель важно проконтролировать при разработке программного обеспечения на заказ . Код с большим количеством повторений отдельных кусков считается низкокачественным: он занимает больше строк, требует больше времени на обработку. Соответственно, такой софт работает медленнее. Иногда код повторяют для упрощения процесса программирования, но зачастую это случайные повторы. Есть специальные сервисы, позволяющие автоматически выявить дублирование: в них загружают код, и система выдает, какие фрагменты повторяются. Один из них — Sonarqube https://www.sonarqube.org/

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

Пользовательские метрики

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

Customer Satisfaction Score

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

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

Это может быть важно для:

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

Net Promoter Score

Метрика NPS рассчитывается по ответу на вопрос «насколько вы порекомендуете сервис друзьям и знакомым?». Обычно предлагается оценить вероятность по десятибалльной шкале.

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

NPS дает понять, как много пользователей:

• в высшей степени лояльны и готовы рекомендовать продукт;
• не определились или нейтрально относятся к приложению;
• имеют негативные впечатления от продукта.

Retention Rate

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

Показатель возвращаемости нужен, чтобы:

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

Conversion Rate

Метрика разработки программного обеспечения показывает, сколько людей среди посетителей приложения совершили целевое действие. Это может быть подписка, покупка, клик по нужной кнопке — в качестве целевого действия можно выбирать то, что нужно в рамках конкретного анализа. Коэффициент конверсии рассчитывается в процентах. Скажем, всего на странице за день было 200 человек, из них 20 кликнули на нужную кнопку — выходит конверсия 10%.

У этой метрики одно назначение — понять, насколько привлекателен CTA-элемент для аудитории.

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

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

READ MORE Разработка дизайна приложения для стартапа: основные этапы

Adoption Rate

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

По метрике видно:

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

Что делать дальше

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

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

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

Насколько публикация полезна?

Оцени эту статью!

63 оценок, среднее 4.6 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной.

Подписывайтесь на нас в соцсетях!

Источник: www.purrweb.com

Расчет эффективности обучения персонала: от опросников к ROI

«Предоставляем бесплатное обучение», — когда-то возможности написать так в вакансии было достаточно, чтобы убедить руководство поддержать запуск корпоративного обучения. Теперь вопросов все больше, и главный из них: «Сколько обучение сотрудников помогает заработать?». Только в США в 2018 году общие расходы на обучение составили 87,6 млрд долларов.

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

Что такое ROI обучения и зачем его измерять

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

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

Пример 1. Компания «Бета» вложила в обучение сотрудников 650 000 рублей. Благодаря этому удалось повысить продажи и заработать на 1 750 000 рублей больше. ROI = (1 750 000 — 650 000)/650 000*100 = 169%

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

Пример 2. Компания «Гамма» потратила на обучение 250 000 рублей. Обученные сотрудники принесли компании дополнительные 75 000 рублей. ROI = (75 000 — 250 000)/250 000*100 = -70%

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

Пока всё просто, в чём подвох?

• Это хорошо или плохо?
• Что помешало добиться большего ROI?
• Как можно повысить ROI?
• Точно ли результат получен благодаря обучению сотрудников, а не новой рекламной кампании?

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

Методология оценки эффективности обучения: модели Киркпатрика и Филлипса

Самая известная модель для измерения эффективности обучения — четырехуровневая модель Дональда Киркпатрика. Основная претензия в адрес Киркпатрика заключалась в его убеждении, что измерять результаты обучения в деньгах невозможно или не имеет смысла. Вот почему позднее Джек Филлипс создал свою 5-уровневую модель ROI.

Сравнение моделей Киркпатрика и Филлипса

Филлипс доработал модель Киркптарика, добавив в неё Уровень 0 (Затраты) и Уровень 5 (ROI) — те самые конкретные цифры, которые хочет видеть заказчик. Кроме того, Филлипс предложил способы изоляции результатов обучения от влияния других факторов, например, маркетинга. Это серьёзно повышает достоверность оценки.

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

Response to LinkedIn Post: Kirkpatricks vs. Phillips

Как измерить ROI обучения

Измерение ROI по методике Филлипса состоит из четырёх этапов: планирование оценки, сбор данных, анализ и подготовка отчёта.

Последовательность действий при измерении ROI. Источник: ROI Institute

1. Определяем цели обучения

Чётко поставленные и зафиксированные цели гарантируют, что в процессе сбора данных вы будете задавать правильные вопросы и ничего не упустите. Патти Филлипс в своей книге «The Bottomline on ROI» рекомендует прорабатывать цели сверху вниз, начиная с желаемого экономического результата и заканчивая реакцией учащихся на учебный курс.

За 12 месяцев сократить объём брака на 20%

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

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

• Знают, что такое система «андон», понимают её цель и то, как именно она работает.

Рейтинг курса не ниже 9 баллов из 10 возможных.

Патти Филлипс рекомендует проводить исследования первого уровня (Реакция) для 90-100% учебных программ, а вот измерение ROI необходимо лишь в 5-10% случаев.

2. Разрабатываем план

На этом шаге создаём и утверждаем три документа: план сбора данных, план по анализу данных и план по расчёту ROI — по этим документам вы будете контролировать ход проекта и оценивать свои успехи.

Что важно прописать в плане:

• цели проекта;
• способы их достижения;
• инструменты (например, СДО);
• сроки;
• ответственных за выполнение каждого пункта.

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

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

3. Собираем данные во время обучения и после него

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

Для этого можно использовать:

• листы реагирования
• опросы
• интервью
• фокус-группы
• тестирование
• решение кейсов
• контрольные листы
• карты и фотографии рабочего дня

Пример вопросов из листа реагирования (Уровень 1)

Категорически не согласен Абсолютно согласен

1. Тема курса была актуальна	1	2	3	4	5
2. Преподаватель хорошо разбирается в предмете и понятно объясняет	1	2	3	4	5
3. Я смогу применить полученные знания в повседневной работе	1	2	3	4	5

Пример измерения изменений в поведении (Уровень 4)

4. Изолируем эффект от обучения

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

Наиболее доступные техники изоляции:

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

5. Переводим результаты в деньги

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

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

6. Оцениваем затраты на программу

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

7. Рассчитываем ROI по формуле

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

8. Определяем нематериальные выгоды

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

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

Если сомневаетесь, нужно конвертировать показатель или нет, воспользуйтесь подсказкой от ROI Institute:

9. Готовим отчёт и представляем результат

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

А) Подготовить отчёт для разных целевых аудиторий. Разной аудитории нужна разная информация, поэтому заранее продумайте, какие отчёты потребуются. Хорошая идея — готовить сразу две версии каждого отчёта: краткую и подробную. Так вы облегчите понимание результатов, за что вам точно будут признательны.

Заказчики, высшее руководство

Полный отчёт о проведении оценки программы обучения

Упрощенный отчёт, описание кейсов

Источник: www.ispring.ru