Как топ менеджменту определить KPI IT-проекта?
Опыт объединения в KPI достижения бизнес целей и качества разработки кода, на примере интернет магазина, и чек-лист технических параметров влияющих на прибыль.
Опыт объединения в KPI достижения бизнес целей и качества разработки кода, на примере интернет магазина, и чек-лист технических параметров влияющих на прибыль.
Правильно ли я понимаю, что Вы пишете только о внешних измерительных приборах, которые реализуются внешними сервисами/парсерами/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 подтвержденных - значит, ситуация с багами именно такая, и тут нужно смотреть глубже (менеджер должен классифицировать эти обращения и вынести на обсуждение команды что сделать чтобы эти и эти типы обращений уменьшить). Часто это бывают проблемы в интерфейсе (нелогично), а не только баги. Но это так или иначе технический долг. Если ты его не оцифруешь, то ты с ним и не работаешь.