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

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

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

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

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

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

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

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

Чек-лист технических параметров, влияющих на прибыль

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

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

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

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

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

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

Когда показатель количества открытых задач представлен рядом с бизнес-показателями, это позволяет сделать вывод о том, хватает ли разработчиков на проекте. Показатель количества сообщений в Телеграм-чате с определенными хэштегами позволяет оцифровать удобство интерфейса, наличие инструкций, подготовленность операторов и качество технической поддержки. У вас это может быть количество заявок или звонков или что-то еще. Например, если у нас 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

33
6 комментариев

При любом наборе метрик возможна ситуация, когда все метрики находятся в зеленой зоне, а проект находится в жопе (с)

4

Да, возможно и такое! В теории.
Но на практике, всегда есть показатели, которые твой технический долг олицетворяют.
Количество ошибок в статанализе не подходит? Ок, давайте смотреть на ошибки на аппах.
Там всё чисто, а проект "в жопе"? Ок, давайте посмотрим на общения первой линии поддержки и второй.
Если ошибок нет, операторы КЦ молчат, условно, количество отмененных заказов небольшое - то или проект не так плох, или трафика нет.
Задача менеджера не жаловаться, а такие параметры искать. Парадигма Disciplined Agile Delivery
как раз и говорит, что у тебя должна быть цифра, которая свидетельствует как-то о техническом долге. Если человек не в состоянии такую цифру подобрать, то возможно он не должен быть менеджером проекта.

Уважаемый Nikita Tanygin спасибо за ваш комментарий. Факторов влияющих на проект достаточно много и все учесть сложно. Но в статье мы хотели акцентировать внимание на то, что в KPI IT проекта необходимо включать не только бизнес метрики, но и показатели качества разработки кода. Чем больше показателей мы учитываем, тем более полную картину состояния проекта мы получаем. Если метрики в зеленой зоне, а в проекте проблемы, значит мы какие-то показатели не учли и нужно их найти.

Правильно ли я понимаю, что Вы пишете только о внешних измерительных приборах, которые реализуются внешними сервисами/парсерами/JS-ками?
Ничего не увидел, про серверную аналитику, загрузки процессора/памяти/дисков (общей нагрузки), кол-ва обрабатываемых запросов и скорости обработки, каждого из них.
Наша практика (in-house), показывает, что внутренние инцеденты и настроенные алармы (скорость реагирования на инцеденты), очень значимо влияют на "деньги" и кол-во транзакций.
Не очень понятны утверждения, про кол-во релизов и их статусу. От релиза к релизу, задачи, их кол-во (как и человеко часы на одну задачу), очень варьироваться могут, как и их влияние на "деньги". Одно дело, перелопатить пересчет корзины на живую, с учетом акционных механик/предложений/условий доставки/способов оплаты и т.д. и выкатить "зеленую кнопку", вместо "оранжевой". Мне кажется, очень абстрактными последних три пункта, особенно этот показатель, ну очень сомнительный (на мой вкус): "количество сообщений в чате между операторами и разработчиками".

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

Это разное.
Есть гигиена, есть лечение.
Ритмичность релизов, количество ошибок на app-ах, pagespeed ранки и прочее - это именно параметры дисциплины. Есть такое понятие, как DAD (disciplined Agile delivery).

Например, у нас Magento. Для неё есть статический анализ, для неё есть встроенный репорт об ошибках. Менеджеру важно знать одно: что там в цифрах.
Если сегодня ошибок 10 а завтра 20 - плохо. Если сегодня 20 а завтра после релиза стало 10 - хорошо. Подробности не нужны.

Аналогично, если у вас app сервер рапортует о 5000 ошибках в сутки, а потом стало 4000 - молодцы, скорее всего стало лучше (или трафик снизился, но это детали).

Да, вы скажете, что всё это уже есть в New Relic, есть Zabbix, есть масса штук. Только всё это не используется в ритмичных улучшениях (когда мы понимаем что технический долг большой, и нужно его маленькими итерациями улучшать).

Количество сообщений в чате между первой линией поддержки и второй и связь подтвержденных и не подтвержденных обращений очень важна по той же причине для менеджера:
если у тебя на проекте 50 сообщений и подтвержденных 2 - значит, первой линии не хватает знаний (документация, тренинги).
Если 50 сообщений и 40 подтвержденных - значит, ситуация с багами именно такая, и тут нужно смотреть глубже (менеджер должен классифицировать эти обращения и вынести на обсуждение команды что сделать чтобы эти и эти типы обращений уменьшить). Часто это бывают проблемы в интерфейсе (нелогично), а не только баги. Но это так или иначе технический долг. Если ты его не оцифруешь, то ты с ним и не работаешь.