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

Техподдержка против ИТ-проектов?

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

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

В жизни такой риск иллюстрировался, например, «незаводским Китаем»: телефоны, похожие на iPhone, но с телескопической антенной, продающиеся и по сей день. У них крайне невысокая цена, а внешне от прототипа они почти не отличаются. И в них даже можно вставить симку и она будет работать.

Однако, инструкции для пользователей будут на китайском, гарантия производителя закончится с передачей товара вам в руки, а зарядное устройство в комплекте обнаружено не будет.

Отвлёкся. Так вот, недавно на курсе, рассказывая об этом риске ИТ-проектов, я предложил слушателям придумать способы противодействия. Мне, естественно, предложили закладывать требования к эксплуатации в охват проекта, готовить в ходе проекта массу дополнительной документации для пользователей и технической поддержки, а также вовлекать команду эксплуатации ИТ в проект с самых ранних этапов. Всё верно ведь?

Но тут опытом поделился слушатель, работающий на крупного внешнего поставщика ИТ-услуг. Его опыт таков: эксплуатационщики не горят желанием работать на проекте!

У нас полно своей работы, а тут еще вы что-то готовите! Нет ресурсов! Ничего не хотим знать до того, как внедрите! А потом уже скрепя сердце начнём разбираться, чего вы там наваяли!

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

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

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

  • Георгий Меметов

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

    • В описанном случае, полагаю, был гибрид всех трёх типов)) Управленческая задача на практике будет сведена к лёгкому и регулярному постукиванию по голове всем троим типам. Но это только в случае готовности линейных начальников к такому воздействию.
      Хуже, если Мертвое дерево руководит коллективом эксплуатационщиков из Реальных Перегрузов и Непониманий…

      • Георгий Меметов

        я обобщил практику нескольких проектов 🙂 а от МД нет другого лекарства, как выкорчевывание. Это важно. Начальник-МД подбирает себе персонал – МД или делает из них МД.

  • Grigory Kornilov

    Попробуйте операционистам предложить роль ‘Заказчик’.

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

    PS:
    На стадии project proposal хорошо бы расчитать не только расходы по новому на создание\внедрение, но и TCO (включая ресурсы операционистов).

    • Pavel Solopov

      “Если проектная команда получит их требования, то будет обязана их реализовать.”
      Это она по PMBOK, возможно, что-то и обязана. А по жизни вполне может и забить на требования службы поддержки. Или просто эти требования не впишутся в бюджет/сроки.
      А знаете, какое самое лучшее средство получить “мёртвое дерево”? Это проигнорировать инициативу (это не по Адизесу, это моё личное мнение).

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

      • Grigory Kornilov

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

        Роль заказчика и том, чтобы обосновывать и отставивать свои требования. В любом случае не выполненные требования есть фиксированное решение о принятых на себя бизнесом рисках\или дополнительных затратах.

  • Alexander Peshkov

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


Добавить комментарий для Grigory KornilovОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM