Бизнес метрика в it это

Основные метрики и KPI в разработке программного обеспечения

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

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

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

Что такое KPI для целей разработки программного обеспечения

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

ПРОДУКТ в IT. Как рассчитать основные метрики? Просто о сложных формулах

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

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

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

Почему важны метрики

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

При возникновении проблем наличие набора метрик поможет определить где были недоработки и выделить наиболее важные из них.

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

Чтобы определить правильность KPI, необходимо учесть некоторые нюансы. Каждый из ключевых показателей должен быть расписан по методике SMART. Это означает, что они должны быть:

• Specific: Конкретный
• Measurable: Измеримый
• Achievable: Достижимый
• Relevant: Значимый
• Time-bound: Ограниченный во времени

Виды KPI

Метрики разработки программного обеспечения мы можем разделить на 5 категорий

МЕТРИКИ. КЛЮЧЕВЫЕ ПОКАЗАТЕЛИ ТВОЕГО БИЗНЕСА

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

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

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

Показатели удовлетворенности клиентов помогают компаниям измерить, насколько их клиенты удовлетворены работой программного обеспечения. К ним относятся Net Promoter Score, Customer Satisfaction Score и Customer Effort Score.

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

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

Давайте обсудим их.

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

Измерение работы в процессе ее выполнения

Скорость работы команды

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

Существует множество способов измерения скорости, например, стори поинты. Один из них — измерение объема работы, который войдет в итоговый программный продукт.

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

Важные советы по измерению скорости работы сотрудников

Если скорость остается неизменной после нескольких спринтов, подумайте о включении в расчет других факторов.

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

Если вы хотите строить прогнозы на основе скорости разработки — среднего значения трех спринтов будет достаточно для прогнозирования будущих показателей.

Диаграмма сгорания задач (спринт Вurndown)

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

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

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

Диаграмма сгорания задач для выпуска проекта

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

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

Выстроенный процесс разработки и возможные узкие места

Время цикла разработки

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

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

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

Накопительная диаграмма потока

Накопительная диаграмма потока (Cumularive Flow) — это визуальное отражение статуса всех задач, находящихся в процессе выполнения. В ней используется цветовая схема, которая отражает различные этапы проекта. Цель этой диаграммы — визуальное представление распределения задач по этапам.

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

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

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

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

Эффективность потока

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

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

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

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

Качество кода

Метрика покрытия кода тестами

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

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

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

Стабильность кода

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

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

Простота кода

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

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

Метрика скорости изменения файлов в проекте (code churn)

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

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

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

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

Как разработчики измеряют KPI?

Конкретные инструменты, которые вы будете использовать для измерения KPI, зависят от систем, которые ваши команды и сотрудники используют для выполнения своей работы. Маркетинговые команды могут использовать Google Analytics для измерения KPI, команды продаж — CRM, а команды поддержки — отчеты службы поддержки.

Метрики в IT-проектах: как выбрать, внедрить и отследить

IT-проект – сложный «механизм», который требует организации и контроля. В этой статье backend-разработчик SimbirSoft Ринат рассматривает метрики как один из способов наблюдения за состоянием проекта, приводит примеры метрик и области их применения на проектах. Материал будет полезен менеджерам проектов, в которых еще не внедрены метрики, и начинающим разработчикам, которые задумываются об улучшениях в работе.

2232 просмотров
Зачем нужны метрики и как их выбрать

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

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

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

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

Метрики в проблемных местах

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

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

Также метрики помогают исследовать слабые места в проекте. Когда мы знаем слабые места, можно добавить показатели и отслеживать их изменение. Если таких мест нет, возможно, стоит посмотреть внимательнее и обнаружить их с помощью метрик, которые были введены в проект ранее.

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

Метрики в системе управления проектом

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

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

Пример дашборда соотношения открытых багов к закрытым за неделю

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

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

Пример дашбордов в Allure

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

Метрики для мониторинга проекта

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

Пример дашбордов в Grafana

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

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

5 популярных инструментов для работы с метриками

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

• Jira: позволяет создавать графики и дашборды для отслеживания результатов и прогресса команды.
• Grafana — инструмент для визуализации, мониторинга и анализа данных. Выше о нем уже упоминали. Он обладает гибкой настройкой и включает в себя большое количество плагинов. Часто используется в паре с Prometheus.
• Prometheus — приложение, которое основано на базе данных временных рядов и используется для мониторинга событий. Этот инструмент удобен для настройки оповещения. Он имеет свою базу данных и собирает в неё сведения, а Grafana их визуализирует.
• Allure — инструмент для создания отчетов по результатам тестов и построения различных графиков, которые можно использовать для отслеживания прогресса проекта. Подробнее о нашем опыте можете почитать здесь.
• Excel: для небольших проектов может быть более эффективно собирать данные вручную и строить графики в Excel, чем подключать различные инструменты.

Сразу отметим, что у каждого из них есть аналоги, которые для конкретного проекта могут подойти лучше.

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

Больше кейсов и полезных материалов в наших каналах:

• ВК и Telegram для разработчиков
• ВК и Telegram для владельцев продуктов и IT-управленцев.

Источник: vc.ru

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 можно обратиться за разработкой программного обеспечения на заказ . Мы всегда готовы проконсультировать по любому вопросу — пишите!

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

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

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

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

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

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

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