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

Перенос сроков

DeadlineУже несколько раз всплывала тема сроков, неважно чего: решения инцидентов, выполнения работ и т.д. И каждый раз когда мы обсуждаем эту тему на семинарах проектирования обязательно возникает вопрос переноса сроков. В основном причина переноса в том, что кто-то не хочет портить статистику/отчетность из-за задержек "по объективным причинам". Особенно ожесточенно вопрос обсуждается, если на горизонте маячит привязка системы мотивации к метрикам, связанным со сроками. 

На досуге задумался о том, что необходимо предпринять, чтобы избежать произвольных переносов сроков до бесконечности. Для примера возьмем наши любимые инциденты. Как мне кажется, есть два основных вопроса на которые надо ответить:

  • Кто?
  • Когда (при каких условиях)?

Конечно есть еще масса вопросов, например, сколько раз можно переносить срок, кого уведомлять о переносах сроков. Но эти три — самые главные.

Для начала давайте определимся со сроками. Если у вас действует SLA с бизнесом, в котором зафиксированы сроки устранения инцидентов, то о каком переносе сроков вообще может идти речь. Поэтому возникает понимание, что срока нужно два: регламентный и плановый (этот вопрос уже как-то обсуждали). Один чтобы иметь ориентир по максимальному сроку решения и понять, что нарушили данные обещания, а второй, чтобы понимать самим и ориентировать пользователей на ожидаемое время восстановления предоставления ИТ-услуг.

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

Итак, КТО? Дать возможность любому ИТ-специалисту бесконтрольно двигать срок, значит вообще потерять значение срока. Одним из вариантов, хоть как-то контролировать это действие — требовать вводить/выбирать причину переноса срока. Но такой подход требует последующего анализа, хотя бы выборочного, на достоверность вводимых причин. С последующим разбором полетов. А значит, скорее всего, рано или поздно такой перенос сроков останется без контроля.

Второй вариант, дать такие полномочия только избранному лицу/кругу лиц, желательно из числа тех, кто может непредвзято оценить необходимость переноса сроков. Т.е. выполняется как минимум два условия: их мотивация не завязана на нарушение сроков, они в состоянии вникнуть в сложившуюся ситуацию.

Далее, КОГДА? "Когда" раскладывается на два вопроса: "в каких ситуациях" и "на каком этапе обработки". Интереснее всего конечно понять в каких ситуациях перенос сроков допустим.  Соответственно для регламентного срока я бы всегда на вопрос КОГДА давал ответ НИКОГДА, а для планового не ставил ограничения. При этом вероятно стоит озаботиться информированием заинтересованных лиц об изменении планового срока.

Решение такого простого вопроса обычно имеет массу последствий, интересно узнать, а как вы поступаете со своими сроками?

 

 

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 10

  • Альберт

    Для того чтобы ответить на вопросы Кто и Когда, нужно посчитать Сколько. А далее матрица полномочий — Кто и влияние на бизнес — Когда. Вот в ответе Сколько могут быть варианты. Обычно тот, кто планирует перенести сроки должен сам обосновать этот перенос.

  • Pavel Solopov

    Мне не понятна проблема, почему мы не можем дать право переноса срока исполнителю и потом анализировать за период, что же мешало нам сделать вовремя — для этого у нас нет ресурсов.

    Но мы можем выделить отдельного человека или группу людей, которые будут рассматривать каждый случай в отдельности и принимать решение. Для этого у нас почему-то ресурсы есть...

    Плюс с выделением отдельного "решающего" по переносу сроков мы получаем такие проблемы:

    1. Время взаимодействия с куратором переноса и время его решения может быть больше чем время на которое переносим срок.

    2. Куратор говорит: "нет переносить нельзя", а исполнитель отвечает: "я рад, но я всё равно не уложусь в регламент".  Схема выродится просто в формальное проставление галочки куратором.

     

    Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

    • Vladimir Kapustin

      Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

      Именно так и делаем.

       

    • Andrey Kapustin

      Полностью согласен с Павлом и теской.

      Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

       

      Именно так и делаем.

  • Сергей Посыльный

    Не согласен я с размышлениями о "регламентном" сроке (в том виде как он здесб сформулирован).

    Да, у нас есть соглашение подписанное по которому мы обязуемся сделать что-то в течении 4-х часов.

    Это SLA и прочее. НО! Если я вдруг договариваюсь с Заказчиком о его переносе для определенного Инцидента (не важно по какой причине, но мы (исполнитель и заказчик) между собой об этом договорились) почему его нельзя перенести?

    Мы пришли к соглашению, что по данному Инциденту переносим "регламентный" срок.

    Перенося срок в системе мы указываем что перенесли и на каком основании.

    Это уже не соглашение, не SLA?

    • Andrey Kapustin

      Сергей, считаю что теоретически можно процедуру переноса "регламентного" срока сделать частью SLA. Но это будет брррр.

      Нарушение "регламентного" срока (времени закрепленного в SLA) может/должно(и будет)  использовано Заказчиком как формальный повод пообщаться о качестве сервиса (и выплате penalty). Внедрение "процедуры переноса" в SLA заведомо снижает риски Сервис Провайдера и переносит их на сторону Заказчика ( на лицо нарушение определения Сервиса по ITIL 🙂 ). Да и практика прописывания "процедуры переноса" в SLA, мне кажется не распространена, если вообще есть. (Там скорее будет только процедура эскалации)

      По переносу "планового" времени (которое, читай "фактическое время решение инцидента") вопрос об ограничениях вообще не касается: 9 женщин не родят за месяц одного ребенка как бы не старались. И на мой взгляд тема раскрыта Павлом в посте выше.

  • Мне кажется интереснее другое — что толку переносить сроки? Как правильно реагировать руководителю, чтобы прекратить постоянные переносы сроков? То есть понятно, что кнутом и пряником, но как быть если кнута особого нет (или он просто уже почти перестал действовать)? Эта ситуация — постоянная реальность множества организаций.

    • Альберт

      Руководителю нужно руководить и не доводить дело до ситуации когда нужно переносить сроки. Если уж это произошло минимизировать воздействие переноса сроков на бизнес. Бывает конечно форсмажор, но на этот случай должен быть DRP.

    • Pavel Solopov

      Как правильно реагировать? Разбираться! А если нет кнута и пряника тоже нет, то надо писать заявление на увольнение — он больше уже не руководитель.

  • Grigory Kornilov

    Если это проект, то PM согласует матрицу ответственности RACI (или другие более широкие варианты), так не забываем про план коммуникаций.

    Если это инцидент, то SM согласует SLA и правила эскалации при разчилных уровнях его нарушений.

    PS: Но кому же хочется тратить время на серьезную прорабокту подобного? Потому и делегируется принятие решения на исполнителя, все работает пока исполнитель справляется, а недостатки не критичны.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT