Поддержание программы после релиза

Категория: Технические советы

– Автор: Игорь (Администратор)

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

Наверное, эта последовательность знакома каждому. Действие - Результат - Эйфория. Просто вспомните, что и в каком порядке происходило после того, как вы заканчивали длительное дело. И все станет понятно.

Сноска: какой бы сферы вы не касались, эта последовательность будет применима везде.

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

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

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

Как минимум процесс поддержания должен включать в себя следующие пункты:

1. Проверка целостности. Исправление ошибок. Проверка доступности функций. Отслеживание состояния системы. И прочее.

2. Соответствие потребностям. Насколько сегодня программный продукт может решать задачи тех, кто им пользуется. Ответы на такие вопросы, как "Чего не хватает?", "Что не выдерживает?", "Что не используется и почему?" и прочие.

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

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

5. Оценка необходимости. Несмотря на то, что система, как таковая, может быть востребованной, в ней вовсе может не быть необходимости. Если быть точнее, то востребованным может быть решение ряда задач, а не сам программный продукт. Помните, что одни и те же задачи можно решать разными способами. Если преимущества не компенсируют время, силы и ограничения, то такой системой вряд ли кто будет пользоваться. Кроме того, продукт попросту может быть неактуален. Утрируя, создавать сайт ради одной встречи нескольких человек не особенно-то разумно. Проще создать группу в социальной сети или вообще договориться в переписке и т.п. Иными словами, вместо часов/дней/недель, вы уделите решению всего 5-10 минут.

Многое из перечисленного может оставаться без внимания. Даже те факты, что проверки могут занимать не более 5-10 минут для небольших и средних программных продуктов, и что пользы от таких проверок может быть много, никак не влияют на ситуацию. Порой под поддержкой продукта продолжают понимать - исправление ошибок и создание ЧаВО, чего может быть и хватит программному продукту, но является лишь вершиной айсберга.

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

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

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

• Универсальное или уникальное решение: что лучше?
• Какой использовать дизайн для небольшого сайта шаблонный или же уникальный?