Начните с отчетности, а затем измеряйте для достижения успеха
Измерения всегда будут ключом к успеху в бизнесе и в ваших усилия в сфере ИТ для этого бизнеса. Вопрос в том, как правильно выстроить подход к измерениям и отчетности.
Всё о метриках, KPI, CSF, а также об измерении услуг, процессов, технологий. И про CleverKPI.
Измерения всегда будут ключом к успеху в бизнесе и в ваших усилия в сфере ИТ для этого бизнеса. Вопрос в том, как правильно выстроить подход к измерениям и отчетности.
CD3: Cost of Delay Divided by Duration — это метод определения приоритетов/планирования, который максимизирует ценность, полученную за определенный период времени, когда у вас ограниченная производительность. Это особенно полезно в средах, где основным ограничением системы является доступное время относительно фиксированного или “дефицитного” ресурса. Это очень хорошо сочетается с разработкой продукта из-за накладных расходов на коммуникацию, сотрудничество и координацию, которые ограничивают нашу способность наращивать производительность. CD3 является одной из специфических форм метода организации очередей “WSJF – Weighted Shortest Job First” (Сначала Более Ценная и Короткая Работа). Мы могли выбирать вес по другим параметрам (риск, важность для заинтересованных сторон, длительность ожидания и т. д.). В случае CD3 мы…
Зачем измерять что-то, если это не поможет нам принимать лучшие решения? В приведенной статье мы напоминаем, о чем следует подумать, чтобы сделать свою систему измерений наиболее эффективной.
Выводы и заключительные размышления на тему, как подойти к вопросу измерения производительности разработчиков.
Чтобы разобраться с тем, как оценивать производительность и эффективность работы разработчиков, нужно узнать плюсы и минусы существующих подходов и разобраться с тем, какое влияние на бизнес оказывает программная инженерия.
Мы продолжаем рассматривать сложную, но интересную и актуальную тему измерения производительности разработчиков ПО, и сравниваем возможности по измерению работы таких отделов с другими отделами.
Измерение производительности разработчиков – сложная задача, встающая перед руководителями ИТ. Обычные измерения усилий и выходов, применимые для других отделов, могут негативно повлиять на культуру разработки. В данном случае необходимо применять другие подходы.
Весьма вероятно, что вы уверены в том, что ваша команда использует сбалансированный набор таких метрик, однако стоит задуматься – правда ли это? Давайте рассмотрим различные типы показателей и проблемы, с которыми сталкиваются службы ИТ, используя неправильные метрики.
Для формирования системы измерения и оценки необходимо совершить несколько шагов. Причём состав этих шагов сохраняется, какой бы объект управления ни подлежал оценке — процесс, услуга, проект или другие разовые активности.
Обсуждая тему построения эффективной поддержки в ИТ или оптимизацию работы уже существующей, мы всегда сталкиваемся с вопросами измерения. Что измерять? Как измерять? Зачем измерять? Современные технологии Service Desk и выгрузка разных отчетов позволяют легко собирать большие объемы данных о производительности, рациональности, удовлетворенности. Признанными показателями эффективности для Сервис деска будут: Но сегодня я хотел бы затронуть тему удовлетворенности не потребителя, а сотрудника Сервис деска или, как сейчас принято называть, агента. А измеряете ли вы этот параметр вообще? Волнуют ли вас вопросы удовлетворенности работой вашего персонала? Или эти вопросы могут всплывать только при появлении текучести кадров? Удовлетворенность Поговорка о том, что счастливые…
Какие дополнительные метрики можно использовать для анализа скорости работы поддержки? Автор статьи с DevOps.com останавливается на пяти в дополнение к MTTR/MTRS.