Как топ менеджменту определить KPI IT-проекта?

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

Наша компания 5 лет разрабатывает интернет магазины и B2B порталы и управляет IT проектами. Мы не сразу пришли к тем параметрам, которые позволяют увязать бизнес-показатели и культуру написания кода вместе.

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

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

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

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

• статический анализ кода;
• индексы страниц в PageSpeed;
• опросы команды;
• количество ошибок в проекте на серверах (404, 500, и т. п.);
• количество релизов и задач в них;
• количество открытых задач в разработке и поддержке;
• количество сообщений в чате между операторами и разработчиками.

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

Индексы страниц в PageSpeed или YSlow, как прямая оценка от Google и Yahoo, содержат данные по скорости работы сайта и рекомендации по их улучшению. Эти параметры важно контролировать, чтобы поисковые системы правильно ранжировали сайт. Ошибки при ранжировании страниц сказываются на конверсии.

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

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

Когда показатель количества открытых задач представлен рядом с бизнес-показателями, это позволяет сделать вывод о том, хватает ли разработчиков на проекте. Показатель количества сообщений в Телеграм-чате с определенными хэштегами позволяет оцифровать удобство интерфейса, наличие инструкций, подготовленность операторов и качество технической поддержки. У вас это может быть количество заявок или звонков или что-то еще. Например, если у нас 100 обращений с хэштегом #проблема и техподдержка закрыла 90 обращений с хэштегом #неподтверждено, значит, проблема качества документации или количества операторов. Если же из 100 проблем было не подтверждено мало, значит, проблема с качеством разработки или нехваткой ресурсов. Телеграм упрощает общение между всеми членам команды, так как не надо создавать большие заявки в трекере.

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

Для упрощения процесса постановки KPI в IT сфере используют программы для мониторинга производительности приложений (application performance monitoring). В идеале, эта программа должна выполнять сбор параметров производительности всего IT продукта и их интерпретацию, в фокусе выполняемых бизнес процессов и транзакций, сравнение текущих параметров и базовых, отправку уведомлений об ошибках и адаптацию для их устранения. В своей работе, для достижения указанных целей, мы используем программу APMinvest.com.

Результаты внедрения APMinvest.com в snowqueen.ru. За полгода использования APMinvest, в сравнении с этим же периодом прошлого года, конверсия выросла на 48,82%, доход вырос на 64,69%, количество покупок выросло на 60,24% и средний чек увеличился на 3% (lfl 2017-2018 май-август).

В итоге для того, чтобы топ менеджменту интернет магазина определить KPI подрядчика ему обязательно нужен APM.

Авторы: Андрей Путин @a.putin, Анастасия Ловкова facebook.com/anastasia. lovkova

#ktteam #it #ecommerce #magento #apm #apminvest #application #application_perfomance_monitoring #kpi #kpi_it #kpi_разработчиков #статический_анализ #page_speed #релиз #конверсия #конвертация_приложений #конверсия_в_платежи #конверсия_регистраций #интернет_магазины #показатели #показатели_эффективности #показатели_проекта #разработка_интернет_магазина #эффективность_интернет_магазина