Как аналитикам качественно передать большой проект на поддержку

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

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

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

Для начала разберемся, чем поддержка программы отличается от сопровождения.

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

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

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

Пример: описание процессов

Для примера работы и передачи на поддержку рассмотрим два процесса из реального большого проекта. Один процесс относительно несложный — сертификация товаров. Другой процесс уже посложнее — это закупки российские (то есть не импорт и не закупка в ЕвраЭС).

Данные процессы были смоделированы в программе 1С:ERP. По итогам полученных требований и моделирования были написаны документы «Техническое задание». В документах был описан процесс работы, а также определены функциональные разрывы, то есть места, в которых программа не могла обеспечить работу по требованиям.

Таким образом было зафиксировано описание того, как программа будет работать в будущем. Описание в техническом задании велось в модели to be.

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

При этом при эксплуатации выяснилось, что сработали некоторые риски.

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

Критичность рисков предполагаемых до запуска и после запуска отображено на рисунке.

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

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

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

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

На основе своего опыта могу дать несколько рекомендаций о том, как корректно передать систему на поддержку.

1. Полная и исчерпывающая документация. Информации на крупных проектах очень много, она должна быть зафиксирована. Также во время сопровождения хорошей практикой является периодическая актуализация документов, т.к. на больших проектах новые правки программы и даже целые архитектурные решения неизбежны.
2. Все процессы должны быть отлажены, работать качественно и без ошибок на стороне программы.
3. Поддержка архитектора. В больших компаниях процесс развития и изменения не останавливается, система как отражение компании не будет в стационарном состоянии.
4. Доступность документации. По тегам и ключевым словам, желательно иметь возможность контекстного поиска.
5. Вовлеченность команды поддержки. Чем раньше поддержка со стороны команды заказчика начнет видеть вопросы от пользователей, тем лучше сможет на них отвечать. Хорошая практика — привлекать нескольких ключевых сотрудников техподдержки к проекту еще до начала эксплуатации программы для погружения в работу процессов.

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

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