Завершая блок по уровню доверия бизнеса к ИТ хочется рассмотреть еще два показателя: стабильность внедренной функциональности и количество переносов плановой даты выполнения задачи.
Начнем со стабильности работы ИТ сервисов при запуске новой функциональности. Первый отчет – стабильность релизов. Здесь можно использовать следующие определения для построения отчета:
- Релизом считается обновление рабочей среды, если было внедрено более 10 задач.
- Анализируем количество созданных инцидентов к закрытым задачам в рамках переноса релиза на рабочую среду.
- Инциденты относятся к конкретному релизу, если были заведены в день релиза или на следующий день, если нет четкой связи между релизом и инцидентом.
Имея указанные выше цифры, отчет построить достаточно просто как по месяцам, так и по релизам:
Если есть процедура определения в рамках какой именно задачи была допущена ошибка, которая привела к появлению инцидента, то анализ может стать на порядок более точным. Кроме более точного графика по стабильности релизов, мы сможем посмотреть историю появления ошибки и из-за чего она возникла в разных измерениях.
Несколько возможных примеров:
- Время жизни инцидента в разрезе по бизнес подразделениям:
- Причины возникновения инцидентов
Так же можно смотреть какой конкретно сотрудник находит нам максимальный объем работы, по исправлению его ошибок, какое направление бизнеса слабо тестирует функциональность на применяемость в своей работе и т.д. Соответственно ИТ руководитель видит не только объем ошибок, но может понять причины возникновения и точечно устранять их, тем самым снижая объем инцидентов и как следствие повышая уровень доверия к ИТ.
Второй вид отчета, о котором я хотел рассказать – это кол-во переносов плановой даты решения задачи. Формула расчета очень простая:
- Берется массив задач, запланированных на каждого сотрудника (в отчете колонка Pl).
- При каждом переносе плановой даты решения в будущее – счетчик пронесенных задач увеличивается на 1 (в отчете колонка Ov.)
- Итоговый % для всего ИТ подразделения считается по аналогичной формуле с учетом общих значений по всем сотрудникам.
Внешний вид может быть представлен следующим образом:
Понятно, что в отчет попадает вся команда и у каждого сотрудника разных объем работ и разный массив задач. Тем не менее, не выполнение установленных дат, всегда является негативным фактором, который в большинстве случаев приводит к обесцениванию обещаний, которые ИТ дает бизнесу.
Это все, что я хотел рассказать о том, как можно измерять уровень доверия бизнеса к ИТ и об основных флагах, которые говорят нам на какие моменты следует обратить внимание. Уверен, что можно придумать еще отчеты и параметры для опосредованного измерения данного показателя, но главное, что сотрудники ИТ должны всегда помнить: “Доверие потерять легко и быстро, а восстанавливается оно долго и путем огромных усилий”.