Поделиться
Гид разработчика: наследуем ИТ-систему
Достаточно часто предприятие, эксплуатирующее какую-либо АС в течение нескольких лет, в силу тех или иных причин не хочет отказываться от нее и при смене разработчика или передаче функций по ее обслуживанию на аутсорсинг. В этом случае внешним компаниям придется заниматься поддержанием работы, а также дальнейшим развитием унаследованной системы. Подобные проекты имеют свои особенности. Это, конечно, взаимосвязанные причины: недовольство сервисом ИТ-компании приводит к неудовлетворенности качеством системы в целом – в бизнесе обычно нет дыма без огня. Конечно, встречаются еще политические, корпоративные, финансовые, личные мотивы смены производителя ПО, но их анализ выходит за рамки статьи.Возникающие при смене компании-разработчика проблемы имеют специфический характер. В этом случае в системе не будет многообразия используемых технологий и языков. Носитель знаний, скорее всего, существует - это разработчик, который до последнего времени поддерживал развитие системы. Остаются четыре основных проблемы. Первая - недоступность носителя знаний по системе. Ведь вендор, у которого "отобрали" систему, не всегда идет навстречу своему конкуренту. Следующая трудность – опять же, отсутствие либо недоступность полной документации по системе. Вообще, это проблема большинства разработчиков. Кроме того, сложности может вызвать несоответствие исходных кодов функциональности последней версии системы. Заказчик просит передать исходные коды системы новому вендору, но не может отвечать за их адекватность. В итоге, последнюю версию исходных кодов новый вендор может получить только после нескольких попыток.
Типичные проблемы, возникающие при передаче обслуживания системы другому разработчику
| Ранг по степени критичности | Проблема |
| 1 | Отсутствие исходных кодов системы |
| 2 | Несоответствие исходных кодов функциональности последней версии системы |
| 3 | Отсутствие, либо недоступность полной документации по системе |
| 4 | Недоступность носителя знаний по системе |
Источник: Instream, 2008
И, наконец, самая серьезная проблема, которая может возникнуть, - это отсутствие исходных кодов системы.
Обычно заказчик ставит перед новым разработчиком унаследованной системы следующие задачи: повысить производительность системы, реализовать критичные и срочные требования заинтересованного бизнес-подразделения, принять в поддержку и улучшить качество работы (снизить количество дефектов и инцидентов), внедрить систему в другом филиале/регионе /стране. Каждую из них стоит рассмотреть более детально.
Когда разработчик сталкивается с задачей повышения производительности, чаще всего система уже испытывает трудности и не справляется с нагрузкой. При этом требование может быть в виде конкретного значения, например, 2500 операций в секунду, либо будет указан желаемый срок стабильной работы системы при текущем маркетинговом прогнозе. Такая задача - клад для пытливых архитекторов и амбициозных разработчиков.
Задача внедрения унаследованной системы в новом филиале или регионе представляет собой отдельное направление деятельности
Как появляется задача реализовать новую функциональность в унаследованной системе? Бывает, что новая услуга/акция заказчика отлично укладывается в рамки существующей системы. И доработка этой системы может обойтись дешевле, чем разработка новой. Но, увы, у заказчика нет собственных ресурсов на доработку старой системы. Так она попадает к внешнему разработчику, в чьих интересах взять ее на развитие.
Очень важная задача – улучшить качество работы системы. Не секрет, что многие пользователи годами страдают от существующих ошибок, сбоев и других проявлений некачественной разработки и поддержки системы. Если у заказчика нет собственных ресурсов для обеспечения высокого уровня качества сервиса, то логично передать обслуживание внешней компании. Ее прямой обязанностью будет поддерживать систему в состоянии, за которое ему будет не стыдно. Здесь существует прямой вызов профессионализму разработчиков, тестировщиков и менеджеров. Известно, что не многие могут похвастаться благодарными отзывами от заказчиков и пользователей поддерживаемых ими систем.
Задача внедрения унаследованной системы в новом филиале/регионе/стране представляет собой отдельное направление деятельности компании-разработчика. При расширении географии бизнеса у заказчика возникает вполне резонное желание перенести существующие, годами отлаженные бизнес-процессы на новую территорию. При этом возникает необходимость копирования структуры ИТ-систем, поддерживающих эти процессы. Типичные задачи - кастомизация системы под местные особенности бизнес-процессов, локализация пользовательских интерфейсов, интеграция с существующим ИТ-окружением. И все это - в рамках жестко фиксированного срока запуска. При этом заказчик часто может не представлять объем необходимых для внедрения доработок, но в процессе первого внедрения происходит плавный переход от оптимизма к здоровому пессимизму.
В целом, при грамотном подходе как заказчика, так и разработчика, унаследованные системы могут не только "выжить", но и существенно помочь бизнесу заказчика. Для их развития не требуются многомиллионные вложения на внедрение, обучение пользователей, нет длительного периода "привыкания" к системе. Довольно разумно использовать уже имеющийся "багаж" отлаженных унаследованных систем, тем более, если они успешно решают конкретные задачи бизнеса.
Стратегия и тактика решения проблем, возникающих при работе с унаследованными системами, будут рассмотрены в следующей статье.
Короткая ссылка
