Традиционным риском для ИТ-проектов многие своды знаний и эксперты считают недостаточную связь между разработчиками ИТ-компонентов и проектной командой, которая эти компоненты собирает в ИТ-решение, с одной стороны и командой эксплуатации ИТ с другой.
Моя практика это подтверждает: некоторые проекты являются для операционного сегмента (для сервис-деска, например) полным сюрпризом. В некоторых случаях в охват проекта попадает только реализация функциональных требований заказчиков, а эксплуатационные требования не интересуют никого.
В жизни такой риск иллюстрировался, например, «незаводским Китаем»: телефоны, похожие на iPhone, но с телескопической антенной, продающиеся и по сей день. У них крайне невысокая цена, а внешне от прототипа они почти не отличаются. И в них даже можно вставить симку и она будет работать.
Однако, инструкции для пользователей будут на китайском, гарантия производителя закончится с передачей товара вам в руки, а зарядное устройство в комплекте обнаружено не будет.
Отвлёкся. Так вот, недавно на курсе, рассказывая об этом риске ИТ-проектов, я предложил слушателям придумать способы противодействия. Мне, естественно, предложили закладывать требования к эксплуатации в охват проекта, готовить в ходе проекта массу дополнительной документации для пользователей и технической поддержки, а также вовлекать команду эксплуатации ИТ в проект с самых ранних этапов. Всё верно ведь?
Но тут опытом поделился слушатель, работающий на крупного внешнего поставщика ИТ-услуг. Его опыт таков: эксплуатационщики не горят желанием работать на проекте!
У нас полно своей работы, а тут еще вы что-то готовите! Нет ресурсов! Ничего не хотим знать до того, как внедрите! А потом уже скрепя сердце начнём разбираться, чего вы там наваяли!
Встречалась ли вам такая безответственность операционного сегмента? Мне нет. Напротив: техническая поддержка всегда просится в проект, чтобы быть готовой к сопровождению нового решения. Они понимают, что иначе им же будет хуже. Или нет?
Добрый день,
у меня в практике были такие “эксплуататоры”, которые “не горели” желанием и проектами, в которых они участвовали. Тут есть проблемы трех типов: “мертвое дерево”, “реальный перегруз”, “непонимание , а зачем это надо”.
Первый тип – это как “дедушка” в армии, которому ничего не надо, любое изменение – угроза. Это понятие ввел в обиход Ицхак Адизес.
Реальный перегруз – проблема приоритетов и ресурсов, проблема управленческая. Надо решать руководству.
“Непонимание” – это когда человек не понимает своей роли, почему важно, каковы последствия. Эта проблема тоже управленческая, в компании нет зрелого подхода к проектному управлению.