Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Измерение и оценка ИТ

Всё о метриках, KPI, CSF, а также об измерении услуг, процессов, технологий. И про CleverKPI.

Вебинар “Расчёт интегрального показателя на примере оценки качества услуг” 10 июня

10 июня в 11:00 по московскому времени приглашаем вас на бесплатный вебинар “Расчёт интегрального показателя на примере оценки качества услуг”. В ходе вебинара рассмотрим сложности, встречающиеся при выполнении оценки: Какие метрики использовать для оценки качества услуг Зачем и как сформировать общий интегральный показатель по услуге Роль интегрального показателя в отчётности Ведущая вебинара: Наталья Коляда, технический эксперт Cleverics, ITIL 4 Managing Professional, один из авторов и разработчиков решения MARS, предназначенного для оценки и анализа операционных процессов управления услугами, созданного компанией Cleverics Регистрация https://integral.cleverics.ru/

Как ускорить поток создания ценности?

Работая над созданием ценности, команда ИТ-разработки живёт в привычных для неё организационных процессах. Непредвзято взглянуть на свой поток и разобраться, где в нём существуют проблемные зоны, требующие улучшения, бывает очень не просто. Задачки ставятся и двигаются от этапа к этапу по сложившемуся маршруту. И кажется, что все логично, что ускорить этот процесс нельзя без увеличения количества исполнителей. Но так ли это на самом деле? Внутри потока создания ценности могут существовать процессы, существенно замедляющие его течение, делающие его непредсказуемым и неравномерным. Давайте рассмотрим причины, которые препятствуют движению элементов работы в потоке. Недостаточно информации для решения задачи Для того чтобы элементы работы…

Продуктовые метрики для enterprise/b2b или gov продуктов

Как ответить на вопрос: насколько успешен наш продукт? Как оценить насколько мы продвинулись вперед, к нашему пониманию успеха, или наоборот, насколько мы отступили назад? Можем ли мы объективно измерять эту метрику успеха? Конечно, скажут нам профессионалы, ваши метрики должны быть выстроены вокруг потребителя и его потребностей, показывать степень заинтересованности потребителя в вашем продукте, т.к. чем сильнее вы своим предложением улучшаете/изменяете его жизнь, тем крепче и дольше будет поддерживаться его заинтересованность. Практики часто выстраивают наборы метрик в соответствии с AARM: Аcquisition – набор метрик, доказывающий наличие интереса к продукту; Activation – метрики, направленные на измерение того, как происходит процедура приобретения, получение…

Как повысить предсказуемость на уровне всей компании с гибкими подходами

Обычно мы воспринимаем гибкие подходы как почти синонимы адаптивности, и предполагаем, что смена парадигмы или культуры в сторону её увеличения – правильный шаг чтобы начать agile-трансформацию. Но на деле одна из самых распространённых целей организаций, которую они хотят достичь с помощью трансформаций, – это предсказуемость. Почему? Потому что она приносит организации бизнес-результаты и итоги, которые руководство хочет получить для успешности и роста компании в целом. Однако, в то время как уровень руководства нуждается в предсказуемых результатах и итогах, приверженцы гибких методологий склонны думать, что нельзя стать предсказуемыми, будучи адаптивными. Отнюдь – можно. Вы не только можете, но и должны, если…

Поток создания ценности – поток создания чего?

Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а что же такое ценность? Много говорится о потоке создания ценности, о том, какие организационные шаги необходимо предпринять, чтобы сделать его сбалансированным и управляемым, но зачастую команды разработки плохо представляют, что лежит за самим этим понятием. Кажется, что вся работа продуктовой команды направлена на создание ценности. Люди живут в привычном рабочем процессе и считают, что все их действия строго необходимы для развития продукта. Очень сложно заходит мысль, что часть этих рабочих процессов с точки зрения…

Все говорят: «Поток!». А ты построй поток

«А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход к продуктовым командам и организация работы по потоку – то, что происходит во многих компаниях, которым важна скорость поставки при создании/изменении цифровых продуктов. При этом необходимо произвести серьёзные изменения в разных областях функционирования компании. Чаще всего мы, изучая что-либо новое, пытаемся сопоставить это новое с уже имеющимися у нас опытом, знаниями. При этом есть риск того, что мы не разглядим в новом какие-то существенные отличия. Посчитаем, что это тоже самое, с чем мы уже…

Управление потоком создания ценности: следующий эволюционный шаг в разработке программных продуктов

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

Трудности SMART

Наверное, все знакомы с набором критериев SMART, которым должна соответствовать правильно поставленная цель, задача. По моим наблюдениям самая большая проблема на практике у людей возникает с «R». Следует уточнить, что несмотря на то, что нередко под «R» понимают, как и было предложено в первой публикации, где этот акроним использовался, «realistic» (реалистичный), я имею в виду наиболее часто используемый ныне смысл «relevant» (релевантный). Соотнесение цели с контекстом. В широком смысле это означает в том числе соотнесение измерения с целями измерения. «Зачем измерять?» – первый вопрос, на который необходимо ответить при формировании любого отчёта и любой системы измерения и оценки. Например, так…

Сколько времени уходит на устранение дефектов

На прошедшей неделе компания Rollbar (поставщик платформы постоянного совершенствования кода) опубликовала результаты исследования, которое провела независимая исследовательская компания Propeller Insight в конце декабря 2020.Исследование проводилось методом опроса репрезентативной (для США) выборки 950 разработчиков. Поскольку инициатива проведения исследования исходит от компании, бизнес которой – автоматизация работ по повышению качества кода, предсказуемым лейтмотивом отчёта видится значимость проблемы – борьба с дефектами ведёт к существенным потерям бизнеса, а ручной формат этой борьбы крайне неэффективен. Однако, если отбросить классическое «Я не верю в микробов. Их придумали продавцы мыла», любопытными кажутся цифры, полученные в результате опроса. 38% респондентов сказали, что тратят до 25% своего времени…

Метрика эффективности потока, похоже, совершенно бесполезна

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо. И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке. К примеру, вот что написано в словаре книжки “Essential Kanban Condensed”…

Топ-10 метрик для измерения производительности

В данной статье рассматривается десять лучших (по мнению автора) метрик для измерения производительности команды поставки. Измерение и отслеживание прогресса является ключом к успеху при выполнении любой задачи. Как известно, Если вы не можете измерить что-то, вы не можете это улучшить Метрика Назначение / описание Время цикла Измерение времени выхода на рынок новой функции, помогающей создать ценность для потребителя. Показывает скорость работы команды. Длительность от начала работ до запуска в днях/неделях Число релизов Измерение способности команды поддерживать бизнес-потребности в отношении времени выхода на рынок.Число релизов за период Предсказуемость спринта Измерение и сопоставление прогнозируемого и фактического времени поставки. Эту метрику можно использовать для…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM