Теория и практика автоматизации хаоса

Сопровождение внедренных приложений. Теория и практика автоматизация хаоса

Введение

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

Для программистов он чаще всего означает копание в чужом, плохо структурированном коде, латание «дыр» и постепенное отставание от современных технологий.

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

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

Термин «Сопровождение ПО» определяется IEEE (IEEE Standard 1216) как «процесс модификации программной системы или ее компонентов, проводимый после поставки системы заказчику с целью устранения отказов, повышения производительности или улучшения других характеристик системы или адаптации к изменившемуся программному окружению».

Из данного определения можно выделить основные направления:

• Корректирующее сопровождение — это исправление или обход ошибок и недочетов, выявленных в ходе эксплуатации программного обеспечения. На этой стадии пользователи ожидают от специалистов максимально оперативного решения проблем; а в идеале выявление ошибок вообще не должно касаться бизнес-пользователей. Количество выявленных проблем автоматически снижает удовлетворенность пользователей и повышает напряженность внутри компании.
• Улучшающее сопровождение — это дополнение программного продукта новыми функциями. Требования на расширение функционального охвата системы обычно исходят от пользователей и аналитиков. При этом задачи улучшающего сопровождения, как правило, выделяются в отдельные проекты с самостоятельными бюджетами, сроками и ответственными лицами.
• Адаптивное сопровождение — можно определить как внесение изменений в работающее приложение, необходимое для поддержки новых программных и аппаратных средств. При этом функциональность системы не нуждается в расширении. Приложение должно выполнять старые функции в новых условиях.
• Профилактическое сопровождение (preventive maintenance) — это модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, как они приведут к реальным сбоям.

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

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

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

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

Сценарии работ по сопровождению

Как должно быть

Рассмотрим обычный сценарий работы с требованиями к программному продукту. Например, у пользователя возникла проблема. Он звонит по телефону или пишет письмо по электронной почте в службу сопровождения и сообщает о ней. Назовем это письмо «Требованием», оно должно быть зарегистрировано, пользователю сообщается код регистрации. Далее это требование должно быть передано экспертам для анализа. В случае, если есть возможность решить проблему «мирным» путем, то есть данное требование не порождает задач разработки программного кода или дополнительных регламентов, проблема может быть решена путем краткой консультации для пользователя. Данная консультация в письменном виде, факсом или по электронной почте предоставляется пользователю и требование закрывается. В противном случае руководитель службы сопровождения определяет трудоемкость и техническую возможность исполнения данных работ. Координационный совет осуществляет определение бюджета реализации и приоритетов реализации данного требования. Далее к данному требованию формируются задачи, определяются исполнители, устанавливаются планы и т.д.

Как часто бывает

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

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

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

Но на самом деле это полбеды, настоящая беда случится, когда этот специалист придет к своему начальнику и скажет, что хочет от этой жизни чего-то большого и светлого, и в его жизненные планы никоим образом не входило просиживание штанов в попытках объяснить «тупому» пользователю, кто есть кто. И, либо его должны оградить от пользователей, либо он найдет себе новую творческую работу. А при текущем состоянии рынка труда действительно найдет, не сильно утруждая себя, и при этом еще и на более высокую зарплату. А теперь представьте себе, как новый сотрудник остается один на один с системой, с пользователями и бардаком, оставленным предшественником. Сколько у него уйдет времени на разбор ситуации и на какое время ваша корпоративная система останется без сопровождения вообще и без качественного сопровождения, в частности?

Есть еще одна проблема, которая возникает в результате неуправляемого процесса сопровождения, — часто такое сопровождение закачивается коллапсом системы, пусть и не в прямом смысле этого слова. Систему настолько набивают заплатками, что буквально еще одну она перенести уже не в состоянии, а на полный рефакторинг нет ни времени, ни ресурсов, ни документации. Автор видел такие системы неоднократно, причем в подобное состояние они приводились всего за два года сопровождения двумя вполне работоспособными специалистами. Причем специалисты были неплохие и работали они иногда по 12 часов в день, — пользователи-то просят сделать как можно быстрее и как можно проще.

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

Управление требованиями в программном продукте
Управление внедрением и сопровождением

Модель управления требованиями, автоматизирующая следующий бизнес-процесс:

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

Документирование подлежащих исполнению работ происходит на уровне связки «Задачи» с объектами метаданных.

Данный подход позволяет сформировать следующую цепочку данных:

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

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

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

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

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