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

Инциденты, требующие доработок ПО

Кажется, что процесс управления инцидентами – одна их немногих глав ITSM, в которой с точки зрения теории, да и практики не осталось пробелов. Было приятно удивиться, что некоторые вопросы организации столь знакомого процесса не имеют у меня готовых ответов. Может быть, они найдутся у тех, кто читает эти строки.

Итак, процесс обеспечивает своевременность решения инцидентов. Инциденты регистрируются, решаются, закрываются. Не успели вовремя – просрочка и штраф группе поддержки, задержавшей решение (иногда всем группам пропорционально вкладу). Справедливо? Безусловно.

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

Дела обстоят иначе у внутреннего ИТ-подразделения: некоторые подрядчики (особенно вендоры ПО) могут быть «навязаны» руководством компании. Корректно ли штрафовать за нарушение нормативов группы поддержки ИТ-подразделения, когда инцидент требует доработки на стороне такого подрядчика? Можно определить в SLA особые обстоятельства, по которым увеличивать нормативы, скажем, до нескольких недель. Вроде бы решение. Однако нередко контракт с вендором предполагает фиксированное количество часов на доработки в месяц. Очередью доработок ПО управляют бизнес-подразделения, и легко представить картину, в которой незначительный дефект, связанный с инцидентом, будет бесконечно вытесняться более приоритетными заданиями, которые требуются для проведения важных бизнес-изменений. 

Получается, что если гарантировать хоть какие-либо сроки затруднительно, нужно предусмотреть механизмы, которые без угрозы штрафа ни в чем не повинных групп поддержки за просрочку все же обеспечат скорейшее решение инцидента, от которого – не будем забывать – страдает пользователь.

Одним из таких механизмов может быть остановка таймера. Как только диагностика инцидента показывает, что без доработки ПО не обойтись, инцидент переводится в специальный статус и ждет решения связанного изменения. После того, как изменение закрыто, работа по инциденту возобновляется, хотя, вероятнее всего, останется получить только подтверждение пользователя. Плюсы: пользователь имеет возможность понятным образом отслеживать статус по доработке; в случае неудачного решения может вернуть инцидент в работу; как время работы над инцидентом учитывается только тот период, когда мяч на стороне внутренних групп поддержки. Минусы: «бэклог» таких особых инцидентов в крупных компаниях может со временем достигать сотен записей. И вообще такой балласт, который будет переходить из периода в период и мозолить глаза менеджеру, может довольно странно смотреться в процессе, жизненный цикл объектов которого, как правило, исчисляется часами, иногда, днями.

Другой вариант – закрывать инциденты, требующие доработки на месте со специальным кодом закрытия – скажем, «требуется доработка», и требовать обязательной привязки инцидента к записи на доработку. Преимуществом такого варианта может быть большая предсказуемость жизненного цикла инцидента и отсутствие тянущегося из месяца в месяц хвоста нерешенных инцидентов, однако потребуется отдельно продумать порядок информирования пользователя по статусу доработки. Минусом для пользователя является отсутствие возможности возврата инцидента в работу, если доработка не сработала – ведь инцидент давно закрыт. Однако в этом случае может быть зарегистрирован новый.

Оба варианта мне кажутся допустимыми при условии:

  1. Помощи пользователю здесь и сейчас. Все знают хрестоматийный пример с переключением рабочей станции на другой принтер – в этом сценарии инцидент с обходным решением может быть закрыт как решенный. Но что если инцидент связан с неверным расчетом значений в отчете по причине некорректно заложенной логики – обходного решения может не быть как такового. Неплохо бы не оставлять пользователя с этой ошибкой наедине на несколько недель, и оказать посильную помощь перед переводом в статус «доработка» или применением особого кода закрытия.
  2. Информирования пользователя по ходу выполнения доработки.
  3. Наличия дополнительных контролей за инцидентами, требующими доработок. И перевод в статус «доработка» с остановкой таймера, и применение специального кода закрытия дают большое пространство для злоупотреблений со стороны групп поддержки, стремящихся избежать штрафов за просрочку. Легитимность использования любого из механизмов требуется регулярно проверять.

Но может быть есть и другие варианты?

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Rafkhat Osmonov

    Добрый день!

    Можно использовать одноименный статус "Требуется доработка", при переходе в который секундомер останавливается. А если обращений несколько, то использовать это в качестве аргумента для повышения приоритета доработки.

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

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

  • Олег Иваненко

    Добрый день!
    По-моему таких инцидентов не так много. Что получается: ПО работало, работало, потом вдруг сломалось? Чаще наоборот, доработка ПО вызывает инциденты, которые должны устраняться в рамках процесса управления изменениями, непосредственно корректировкой изменения.  

    • Shrizt

      Всякое бывает. Меняется окружение, данные, интерфейсы. Сложные приложения живут не в замкнутом цикле.

  • Алексей Кротов

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

    Неверная логика – даете алгоритм, как считать правильно вручную. Считаете сами. Регистрируете RFC,

    Но вот зависший "в доработке" инцидент – хуже некуда.

  • Сергей Семикин

    Что получается: ПО работало, работало, потом вдруг сломалось?

    Может измениться среда, в которой работало ПО, и для восстановления решено дорабатывать именно ПО, а не среду. 

    • Олег Иваненко

      Опять же Изменение предшествует возникновению инцидента. Или среда поменялась безконтрольно? Есть конкретные примеры?

      • Сергей Семикин

        Оk. Пример, используем веб-сервис со скриптами выгрузки данных на него, провайдер выполняет апдейт и скрипты перестают работать. Изменилась среда и она вне нашейц зоны контроля.

  • Сергей Семикин

    Как вариант, если инцидент решен, например применено обходное решение, то инцидент можно закрыть, но "привязать" его к записи о проблеме и/или к RFC. Если не решен, то "поставить на паузу" и также привязать к записям последующих процессов (GM, PM).

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

  • Олег Иваненко

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

  • Сергей Гончаров

    Может я ошибаюсь, но если причиной инцидента является ошибка ПО, то значит у нас на лицо проблема в виде ошибки ПО. Если обходного пути нет, значит инцидент нужно закрывать со статусом "Невозможно устранить" (или типа того по смыслу). После устранения проблемы – исправления ПО – все связанные с этой проблемой инциденты независимо от того, закрыты они или открыты, проверяются, чтобы убедиться, что проблема действительно устранена, и такие инциденты впредь больше не возникнут.

    • С одной стороны, в книжном понимании, ошибка ПО является причиной прерывания услуги и является проблемой, корневым источником инцидента.

      Но мне не нравится такой подход: опыт разработчика говорит о том, что проблемой должна быть названа причина, по которой эта ошибка ПО добралась до продуктивной среды, Т.е. не делать процесс управления проблемами глубиной “в одну ступень”.

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

      • Сергей Гончаров

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

        Вопрос автором ставился с точки зрения управления инцидентами. Если смотреть "изнутри" этого процесса, то: мы причину возникновения инцидента установили, проблему зарегистрировали. Устранить инцидент мы не можем, значит инцидент закрываем (но не забываем о нем путем привязки к проблеме) и передаем эстафету следующим участникам, которые будут разбираться в проблеме.

        • Обращаться к проблемам полезно, т.к. даже если у нас нет возможности устранить ошибку в ПО, как причину инцидента. В этом случае мы ищем способы и обходные решения: скрипты, правки данных, ручная предобработка. Закрывать инцидент с кодом “нельзя устранить” можно, только если это разрешено контрактом.

          При этом сама корневая причина в виде проблемы будет устранена изменением. То, о чем я хотел сказать, это чтобы процесс управления проблемами не останавливался на устранении ошибки в ПО. В силу разнообразия багов в ПО простого устранения очевидно недостаточно. Пусть будет несколько проблем: одна для устранения ошибки в ПО, вторая, например, для уточнения охвата и методики тестирования. На практике второго часто нет.

          Проблемы, как процесс, должен улучшать наши услуги и процессы в первую очередь.

          • Сергей Гончаров

            Я думаю, что даже если на первом остановимся, уже хорошо. Многие и до этого не доходят 🙂

            А для того, чтобы охватить и второе, должно быть также управление качеством, а не только проблемами. Однако в ITIL этап Build совершенно не охвачен, потому понятно ваше стремление затянуть все в процесс управления проблемами.

  • Ульяна

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


Добавить комментарий для Андрей ТруфановОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM