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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

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

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

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

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

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

Трудности SMART

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

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

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

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

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

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

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

Я знаю три слова…

Есть довольно ощутимые вещи, которые вы можете сделать, чтобы прокачать свои знания в ITSM: посетить учебные курсы, мастер-классы, деловые игры, семинары и тренинги. Что выбрать в этом многообразии и как учесть тенденции быстро меняющегося мира? Да, мир не стоит на месте и вслед за официальным объявлением AXELOS об отмене сертификации ITILv3, о котором мы уже писали, набирает обороты новая линейка курсов и сертификации ITIL4. Но что делать тем, которым нужны знания в области ITSM, при этом вопросы сдачи англоязычных экзаменов не так актуальны? А если еще учесть то, что материалов в публикациях «ITIL® 4 Practice Guide» намного больше, чем требуется...

Не зрелость

Запись вебинара «Не зрелость», посвященного оценке процессов управления ИТ в интересах руководителя, опубликована на канале YouTube Cleverics. Программа вебинара: Что такое зрелость системы управления Что даёт оценка зрелости Чего оценка зрелости дать не может Оценка эффективности Целевые аудитории для разных видов оценки Ведущий: Дмитрий Исайченко, управляющий партнёр Cleverics. Практикующий консультант с пятнадцатилетним стажем, преподаватель. Имеет опыт обследования и реорганизации работы подразделений ИТ ряда средних и крупных компаний: ВТБ24, Raiffeisenbank, UniCredit Bank, Банк «Санкт-Петербург», М.видео, Спортмастер и других. ITIL Expert, ITIL 4 Managing Professional, соавтор и рецензент материалов ITIL 4. Автор публикаций и программных продуктов по управлению ИТ.

Мероприятия предстоящей недели

В четверг 17 декабря пройдёт вебинар «Не зрелость», посвященный оценке процессов управления ИТ в интересах руководителя.  Ведущий вебинара: Дмитрий Исайченко, управляющий партнёр Cleverics, практикующий консультант с пятнадцатилетним стажем, соавтор и ITIL 4.  Программа вебинара:  Что такое зрелость системы управления Что даёт оценка зрелости Чего оценка зрелости дать не может Оценка эффективности Целевые аудитории для разных видов оценки Начало вебинара 11:00 по московскому времени Регистрация В пятницу 18 декабря сообщество ИТ-специалистов Infostart проведёт митап «Методологии управления в ИТ». В программе митапа – 5 докладов от экспертов, применяющих ITSM-методологии, как в международных компаниях, так и в среднем бизнесе.  Вопросы, которые обсудим на мероприятии:...

Он и тебя посчитал

В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной работы, где все (хочется надеяться) друг друга знают, притёрлись к особенностям и лёгким странностям соратников, и слаженно (потому что как ещё это можно видеть изнутри?) работают, я особенно зацепилась за вопрос привлечения сторонних консультантов к диагностике. То, что это – хорошая практика ясно: взгляд со стороны, отсутствие замыленности, ведь консультанты находятся вне жизни команды. Но так ли тут всё однозначно и просто, как кажется на первый взгляд? Сама процедура регулярной диагностики достаточно прочно ассоциируется...

Диагностика продуктовых команд как поток

Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что с этой командой мы какое-то время поработали: разобрались в её рабочем процессе, особенностях, составе, области ответственности... Реализовали набор практик, помогающих работу/результаты структурировать, визуализировать, организовывать, измерять и улучшать. Всё на основе важных принципов и исходя из определённого, нового продуктово-гибкого mindset'а (это слово я на русский перевести затрудняюсь). Итого: первоначальные инвестиции сделаны, далее ожидается более самостоятельное движение этой команды вперёд. Возникают важные управленческие вопросы: как убедиться, что команду можно «отпускать в более свободное плавание»?..

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM