9 октября 2014 г.
Что нужно сделать при переходе от внедрения к сопровождению?
Дорогие читатели. Хочу поделиться с вами своим многолетним опытом и попытаться рассказать, как избежать банальных и оттого обидных ошибок.
Итак, Подрядчик, выполнявший внедрение, рапортует о выполнении работ, пользователи подтверждают, что все их запросы и пожелания выполнены, сформированная служба сопровождения готова к работе. Пора подписывать последний акт и наслаждаться всеми преимуществами внедренного функционала.
Но проходит совсем немного времени, и начинает происходить множество неприятных происшествий. То выяснится, что остановился важный фоновый процесс (запущенный еще консультантом команды внедрения — и вот именно сейчас его логин наконец-то заблокировали), и пользователям приходится сторнировать и создавать заново все документы за последние две недели. И ведь о нем было даже написано на триста n-ой странице Проектного решения (но кто ж его читает?). То вылезет какая-то ошибка, и программисту сопровождения приходится не один день разбирать многомесячные наслоения исходного кода, написанного несколькими поколениями программистов команды внедрения. Часть этого «пирога» не используется, часть дублирует друг друга, и т.п., что, конечно же, нарушает принципы Регламента ведения разработок, принятого еще на стадии подготовки к внедрению (но кто ж его читает и уж тем более соблюдает, особенно когда сроки поджимают, а за время проекта меняется несколько программистов, что случается очень часто?). Да и сами программисты сопровождения уже успели внести свою лепту в хаос. Им то уж точно некогда читать всякие заумные документы и документировать свои разработки (очень распространенное мнение среди программистов).
Недовольство пользователей растет, все пытаются найти виноватых, но как обычно все кивают друг на друга.
Конечно, спустя какое-то время наконец-то все нормализуется. Система «вылизана». Все работает стабильно на радость пользователям.
Пора бы уже подумать о развитии. И тут выясняется, что кроме нескольких человек в сопровождении никто не знает, как ЭТО все работает. Система давно уже «ушла» от первоначально задуманного и (самое важное!) описанного в проектной документации, а тут еще одни из Гуру решил уволиться. Что делать?! Начинаем уговаривать его остаться, платим ему двойную зарплату и т.д. Да и Подрядчику приходится заплатить за анализ текущего состояния системы перед началом проектом развития.
Наученные горьким опытом, запускаем проект редокументирования. Но проходит еще чуть-чуть времени и все повторяется, актуализированную документацию снова можно слить в утиль.
Что же делать? Как избежать всего этого?
Совсем уберечься от подобных проблем, наверное, нельзя. Но можно существенно сократить их количество и затраты на ликвидацию последствий.
Начнем с этапа перехода в ПЭ.
Для начала необходимо понять, что процесс перехода их ЭПЕ в ПЭ — это важный этап и даже, возможно, небольшой проект (в зависимости от объема внедрения).
В ходе него служба сопровождения должна выполнить как минимум следующее:
— провести анализ настроек и исходного кода на соответствие регламентам, нормам единообразия, принятым правилам наименования, отсутствия дублирования, отсутствие неисполняемого кода, и т.п.;
— провести анализ систем на соответствие Проектному решению;
— проверить актуальность всех пользовательских и технологических инструкций, наличия руководств администратора, программиста, и т.д.
— проверить систему на недокументированные фичи.
— по итогу проверки силами проектной команды исправить все недочеты.
В том числе в ходе таких мероприятий консультанты службы сопровождения максимально глубоко знакомятся с системой, что тоже не лишне.
Но что делать, если служба сопровождения собрана из вчерашних ключевых пользователей, которые не способны провести такой детальный анализ? Поверить на слово Подрядчику? Не лучшая идея. Лучше всего будет обратиться в специализированную компанию, предоставляющую такого рода сервисы. На сегодняшний момент их на рынке не так много, поэтому есть смысл договориться с ними заранее (и затраты заложить изначально) еще на стадии подготовки к внедрению.
Такая компания проанализирует систему, на птичьем (профессиональном) языке обсудит все выявленные недочеты с Подрядчиком и не даст ему «соскочить», пользуясь недостаточными знаниями Клиента. Также она подготовит соответствующую эксплуатационную документацию и определит правила «игры» службы сопровождения, дабы избежать рисков появления «Гуру» и отсутствия неактуальной документации.
См. также: Что нужно учесть, создавая собственную службу сопровождения
Источник: Кирилл Щепетов, директор департамента управления КИСУ компании «Энергодата»
