Когда показатель количества открытых задач представлен рядом с бизнес-показателями, это позволяет сделать вывод о том, хватает ли разработчиков на проекте. Показатель количества сообщений в Телеграм-чате с определенными хэштегами позволяет оцифровать удобство интерфейса, наличие инструкций, подготовленность операторов и качество технической поддержки. У вас это может быть количество заявок или звонков или что-то еще. Например, если у нас 100 обращений с хэштегом #проблема и техподдержка закрыла 90 обращений с хэштегом #неподтверждено, значит, проблема качества документации или количества операторов. Если же из 100 проблем было не подтверждено мало, значит, проблема с качеством разработки или нехваткой ресурсов. Телеграм упрощает общение между всеми членам команды, так как не надо создавать большие заявки в трекере.
При любом наборе метрик возможна ситуация, когда все метрики находятся в зеленой зоне, а проект находится в жопе (с)
Да, возможно и такое! В теории.
Но на практике, всегда есть показатели, которые твой технический долг олицетворяют.
Количество ошибок в статанализе не подходит? Ок, давайте смотреть на ошибки на аппах.
Там всё чисто, а проект "в жопе"? Ок, давайте посмотрим на общения первой линии поддержки и второй.
Если ошибок нет, операторы КЦ молчат, условно, количество отмененных заказов небольшое - то или проект не так плох, или трафика нет.
Задача менеджера не жаловаться, а такие параметры искать. Парадигма 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 подтвержденных - значит, ситуация с багами именно такая, и тут нужно смотреть глубже (менеджер должен классифицировать эти обращения и вынести на обсуждение команды что сделать чтобы эти и эти типы обращений уменьшить). Часто это бывают проблемы в интерфейсе (нелогично), а не только баги. Но это так или иначе технический долг. Если ты его не оцифруешь, то ты с ним и не работаешь.