25.08.2014 |  support@ida-web.ru

Поддержание продукта после выпуска

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

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

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

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

  • Проверка целостности . Исправление ошибок. Проверка доступности функций. Отслеживание состояния системы. И прочее.
  • Соответствие потребностям. Насколько сегодня продукт может решать задачи тех, кто им пользуется. Ответы на такие вопросы, как "Чего не хватает?", "Что не выдерживает?", "Что не используется и почему?" и прочие.
  • Оценка потенциала и перспектив. Потенциально, система вполне может выдерживать текущие нагрузки и обеспечивать пользователей всем необходимыми. Однако, в зависимости от перспектив, потенциала может не хватать. Верна и обратная зависимость. Если в перспективе ожидается снижение нагрузки из-за оттока пользователей, то смысла в расширении системы нет.
  • Оценка и корректировка целей и задач. Каждый продукт преследует определенные цели и решает конкретные задачи. Тем не менее, иногда, их так же следует оценивать и, при необходимости, корректировать. Продукт, неявно пытающийся решить задачи, для которых он не предназначен, столкнется с огромными проблемами. Помните, что все остальные критерии рассматриваются с точки зрения установленных целей и задач, а не с точки зрения явно и неявно решаемых.
  • Оценка необходимости. Несмотря на то, что система, как таковая, может быть востребованной, в ней вовсе может не быть необходимости. Если быть точнее, то востребованным может быть решение ряда задач, а не сам продукт. Помните, что одни и те же задачи можно решать разными способами. Если преимущества не компенсируют затраты и ограничения, то такой системой вряд ли кто будет пользоваться. Кроме того, продукт попросту может быть неактуален.

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

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

Компания "IDA-Web" надеется, что данный материал позволит Вам лучше понять особенности поддержания продуктов после выпуска.



Так же советуем

Обратная связь

Я согласен с вашими правилами и условиями

Опыт Знания Умения