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

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

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

Burn Rate

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

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

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

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

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

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

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

Flow Efficiency 

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

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

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

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

Team Velocity

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

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

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

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

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

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

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

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

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

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

Test Coverage

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

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

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

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

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

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

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

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

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

ER-диаграмма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Customer Satisfaction Score 

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

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

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

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

Net Promoter Score

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

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

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

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

Retention Rate

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

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

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

Conversion Rate

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

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

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

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

Adoption Rate

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

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

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

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

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

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

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

[wpim]