Уже несколько раз всплывала тема сроков, неважно чего: решения инцидентов, выполнения работ и т.д. И каждый раз когда мы обсуждаем эту тему на семинарах проектирования обязательно возникает вопрос переноса сроков. В основном причина переноса в том, что кто-то не хочет портить статистику/отчетность из-за задержек "по объективным причинам". Особенно ожесточенно вопрос обсуждается, если на горизонте маячит привязка системы мотивации к метрикам, связанным со сроками.
На досуге задумался о том, что необходимо предпринять, чтобы избежать произвольных переносов сроков до бесконечности. Для примера возьмем наши любимые инциденты. Как мне кажется, есть два основных вопроса на которые надо ответить:
- Кто?
- Когда (при каких условиях)?
Конечно есть еще масса вопросов, например, сколько раз можно переносить срок, кого уведомлять о переносах сроков. Но эти три – самые главные.
Для начала давайте определимся со сроками. Если у вас действует SLA с бизнесом, в котором зафиксированы сроки устранения инцидентов, то о каком переносе сроков вообще может идти речь. Поэтому возникает понимание, что срока нужно два: регламентный и плановый (этот вопрос уже как-то обсуждали). Один чтобы иметь ориентир по максимальному сроку решения и понять, что нарушили данные обещания, а второй, чтобы понимать самим и ориентировать пользователей на ожидаемое время восстановления предоставления ИТ-услуг.
Соответственно регламентный срок, как мне кажется, не должен изменяться ни при каких условиях, за исключением изменения параметров от которых он зависит. Например, уровня влияния или ИТ-услуги. Плановый срок может изменяться по ходу обработки инцидента, т.к. он позволяет понять заинтересованным лицам (пользователям, другим ИТ-специалистам), когда ожидать решения. Соответственно по ходу решения оценка может изменяться. Поэтому ограничения на изменение планового срока должны быть сняты.
Итак, КТО? Дать возможность любому ИТ-специалисту бесконтрольно двигать срок, значит вообще потерять значение срока. Одним из вариантов, хоть как-то контролировать это действие – требовать вводить/выбирать причину переноса срока. Но такой подход требует последующего анализа, хотя бы выборочного, на достоверность вводимых причин. С последующим разбором полетов. А значит, скорее всего, рано или поздно такой перенос сроков останется без контроля.
Второй вариант, дать такие полномочия только избранному лицу/кругу лиц, желательно из числа тех, кто может непредвзято оценить необходимость переноса сроков. Т.е. выполняется как минимум два условия: их мотивация не завязана на нарушение сроков, они в состоянии вникнуть в сложившуюся ситуацию.
Далее, КОГДА? "Когда" раскладывается на два вопроса: "в каких ситуациях" и "на каком этапе обработки". Интереснее всего конечно понять в каких ситуациях перенос сроков допустим. Соответственно для регламентного срока я бы всегда на вопрос КОГДА давал ответ НИКОГДА, а для планового не ставил ограничения. При этом вероятно стоит озаботиться информированием заинтересованных лиц об изменении планового срока.
Решение такого простого вопроса обычно имеет массу последствий, интересно узнать, а как вы поступаете со своими сроками?
Для того чтобы ответить на вопросы Кто и Когда, нужно посчитать Сколько. А далее матрица полномочий – Кто и влияние на бизнес – Когда. Вот в ответе Сколько могут быть варианты. Обычно тот, кто планирует перенести сроки должен сам обосновать этот перенос.