Как определить конец веб-приложения?
Этот вопрос может привести к большому количеству мнений, но я хотел бы получить комплекс мер, которые помогут мне и моей компании определить срок годности продукта, который мы продаем.
Мы продаем систему CMS, с этой системой мы создаем несколько субпродуктов
- Веб-сайты
- Создатель предложения
- Отслеживание маркетинговой кампании
Мы готовы приступить к планированию дорог (на 2010 и 2011 годы) и пытаемся выяснить, когда закончится срок службы нашего приложения. Некоторые из вас могут подумать, что очень хорошо спроектированное приложение (я не думаю, что наше приложение хорошо спроектировано) не нуждается в окончании срока службы, но это приложение, которое мы используем, работает не менее 6-7 лет и имеет почти нет документации (реальная жизнь). На данный момент только ОДИН человек знает, как изменить основные функции (страшно).
Пожалуйста посоветуй,
Geo
Спасибо всем! Я очень ценю ваши комментарии, мнения и мысли по этой теме.
Я расскажу о нескольких ответах на вопросы в списке ниже.
- Есть один разработчик, который может поддерживать основные функции нашего продукта. (только и только один)
- Есть два разработчика, которые могут повысить функциональность до определенной точки. Оба разработчика ограничены ограничениями основного продукта, и они оба должны работать в этих пределах.
- Очень важное замечание. Продукт, который мы собираемся использовать в конце срока службы, по большей части строится подрядчиком. Подрядчик - единственный разработчик, способный поддерживать основные функциональные возможности. Мы развиваемся только на основе контрагента.
Я буду добавлять ответы, пока буду читать все ответы.
8 ответов
Поскольку приложение очень хорошо спроектировано, вы можете не захотеть от него отказаться и потерять все инвестиции, которые вы сделали на сегодняшний день.
Вот мои предложения:
- Пригласите младшего разработчика присоединиться к этому текущему разработчику.
- Дамп большинства будущих обновлений на младшего разработчика (с помощью старшего разработчика)
- Попросите младшего разработчика сделать документацию его работы
- Попросите старшего разработчика просмотреть документацию
Через какое-то время у вас появится другой человек, который может поддержать это приложение, и оно также будет задокументировано. Теперь вам не нужно будет убивать собственное очень хорошо спроектированное приложение своими руками.
,
Расширение этого решения предложением Джеффри ниже ("Иногда переписывание - это хорошая инвестиция".)
Если вы все еще хотите удалить текущее приложение и переписать его, вам все равно нужно документировать существующую систему и создавать требования для новой системы на ее основе.
Используя документацию по текущей и предлагаемой системе, вы можете захотеть узнать, можете ли вы постепенно увеличивать модуль за модулем (переписывать) компоненты. Это возможно, если приложение очень хорошо спроектировано.
Согласно вашим (Geo) комментариям
У организации Geo есть собственное стороннее (с одним и только одним разработчиком по контракту) CMS-приложение, которое реализует бизнес-требования, не соответствующие бизнес-требованиям, и платит лицензионный сбор за поддержку и использование его кода.
- Бизнес-требования для CMS
- Веб-сайты
- Создатель предложения
- Отслеживание маркетинговой кампании
Вот мои предложения
- Создайте подробный пример использования модуля за модулем для этого проекта. Ваш разработчик может сделать это, или было бы идеально иметь отдельного бизнес-аналитика для того же.
- Наймите старшего разработчика, чтобы оценить, может ли CMS с открытым исходным кодом удовлетворить все или большинство ваших требований (например, Joomla, Drupal и т. Д.).
- Самым важным здесь будет возможность перенести существующие данные в новую систему. Вам может понадобиться помощь от вашего существующего разработчика контракта, чтобы сделать это.
- Возможно, вам придется обновить бизнес-процесс или рабочий процесс, чтобы использовать новую систему.
- Модули, которые не могут быть реализованы с использованием CMS с открытым исходным кодом, могут потребоваться для реализации с использованием пользовательского веб-сайта.
Многое из этого также зависит от ваших деловых отношений с существующим контрактом разработчика и лицензионного соглашения. То, с чем вы столкнулись, - это блокировка поставщика в сценарии. Возможно, вы захотите продолжить исследования решений, чтобы устранить эту ситуацию вендора.
Это только мое мнение, но если это продукт, который вы продаете, то все сводится к перспективам бизнеса. Если товар не продается, бросьте его. Если у продукта есть будущее, то инвестируйте в него и сделайте его лучшим программным обеспечением, которое вы сможете, путем рефакторинга, переписывания или всего, что вам нужно сделать. Если у вас есть постоянные клиенты или сильный бренд, то это стоит защитить.
Иногда переписывание всего этого в другой технологии является хорошей инвестицией, если текущее программное обеспечение имеет удачный дизайн, который можно скопировать, имеет сильный бренд и если это можно сделать правильно.
Приложение истекло в тот момент, когда оно было отправлено без какой-либо документации. Начните разработку сейчас, и вы можете подумать о замене человека, который знает оригинальную систему. Если они прошли 6/7 лет, не создавая какой-либо документации, они не те, кого вы хотите видеть в своей компании.
Единственный вид документации, который продлит срок службы вашей системы, - это вещи, которые остаются согласованными по мере изменения системы в течение срока ее службы, такие как наборы тестов, инструменты самодиагностики, комментарии к коду, декларативные контракты, такие как интерфейсные интерфейсы, и автоматически генерируемая документация.
Другие артефакты документации, управляемые вручную, такие как руководства, руководства для разработчиков, документы по архитектуре, форматы данных, как правило, устаревают пропорционально количеству документации. Я бы не стал считать их факторами, которые увеличивают ожидаемый срок службы вашего приложения, если вы уже не учли стоимость его обслуживания.
Если вы не можете "позволить" избыточность разработчика для надежной поддержки приложения, вы не можете позволить себе обновлять документацию. Отсутствие документации - это действительно технический долг, который вы решили, возможно, неосознанно взять на себя. Если более длинный жизненный цикл является требованием, то стоимость этого должна учитывать выполнение этого требования.
Короче говоря, я в сопоставимой ситуации.
Пока это приложение похоже на cashcow, но компания не может позволить себе (или намеревается) разработать новое приложение, оно не умрет, пока клиенты не решат купить более свежую систему.
Переписать без (задокументированных) требований практически невозможно.
По крайней мере, опыт специализированных отделов должен быть задокументирован таким образом, чтобы это было полезно для дальнейшего развития.
Если вам нужно поддерживать это приложение, вы должны ввести интерфейсы между модулями, чтобы уменьшить общую сложность. Поэтому старые модули, какими бы грязными они ни были, не заботятся о том, нужно ли вам добавлять новые функции.
Даже если он очень хорошо спроектирован и функционирует, тот факт, что он не имеет документации и зависит от одного человека в течение всей жизни, означает, что продукт очень хорошо вошел в состояние, не подлежащее ремонту. Это не хороший знак. Я бы согласился, что продукт давно прошел "Конец жизни"
Я прошел похожий процесс. У нас было веб-приложение, которое работало почти 8 лет. За это время было проведено много технического обслуживания, и мы расширили его так, как мы не предполагали. Тем не менее, ядро было хорошим, и его можно было растянуть.
Что нас подтолкнуло, так это стоимость обслуживания. Найти людей с правильным набором навыков было легко 8 лет назад. Сегодня никто не хочет работать в таких условиях; даже не мы:)
После анализа мы поняли, что можем заменить его в течение 12 месяцев на идентичные функции, и что потраченное время быстро окупится.
Таким образом, мы использовали снимки экрана в качестве наших функциональных требований, обновили внешний вид и даже смогли повысить функциональность. Мы также изучили данные об использовании, чтобы идентифицировать детали, которые использовались редко или никогда не использовались, и обрезали их, а также сосредоточили больше внимания на деталях, которые были использованы.
В конечном итоге мы были успешны. Отчасти потому, что все в команде хорошо разбирались в новых технологиях, поэтому не было особой необходимости в обучении. Другие способствующие факторы включали хорошо продуманный дизайн. Я думаю, что мы потратили 3 месяца на дизайн, прежде чем что-то писать.
Последний фактор заключался в том, что наше приложение является модульным. Таким образом, мы смогли распределить его по размерам, достаточно маленьким, чтобы иметь комбинацию коротких графиков доставки с периодом простоя / анализа между каждым результатом. Это гарантировало, что мы были на правильном пути на каждом этапе.
Вот такие вещи, которые я мог бы учитывать при принятии решения о том, может ли система работать "в конце срока службы":
Доступна ли функциональность, предоставляемая этой системой, конечным пользователям в более дешевой, надежной или простой в использовании форме? Если не сейчас, то когда это возможно? Является ли этот продукт жизнеспособным в долгосрочной перспективе?
Написано ли это в технологии, от которой клиенты будут избегать, поскольку было бы неудобно взаимодействовать с их продуктами или требовать от них запускать "устаревшие" платформы? Создаст ли у потенциального клиента впечатление, что ваша компания значительно отстает от времени, например, VB6, вероятно, все еще в порядке, даже в 2010 году, но, вероятно, не требует совместимости с Win16.
Можете ли вы нанять хороших людей, которые знают основную техническую платформу по разумной цене? В более старых технологиях может быть так, что есть много людей, которые знают платформу, но видят в ней тупик и будут просить премиальную зарплату, если их карьера затихнет в унынии, пока они работают над ней.
Если это имеет значение для вас, платформа разработки все еще поддерживается поставщиком? Будете ли вы ограничены тем, на каком оборудовании или ОС вы можете его запустить, если поставщик больше не обновляет его? Аналогично, есть ли в платформе дыры в безопасности, которые, возможно, потребуется обновить? Даже нишевые продукты с открытым исходным кодом могут пострадать от этого. Как только продукт перестает пользоваться популярностью, а основные разработчики переходят на новые проекты, сообществу может быть сложно сделать исправления.
Если это поддерживается, поставщики взимают плату за поддержку более старой платформы? Если не сейчас, то как долго они это делают?
Насколько сложно интегрировать в нее новые технологии, чтобы воспользоваться преимуществами современных тенденций, которые предлагают расширенные функциональные возможности конечным пользователям, чтобы сохранить вашу конкурентоспособность? Вас это волнует? Это может не иметь значения, если вы используете закрытую систему.
Насколько сложно вносить в него функциональные изменения без значительных изменений "дробовика", которые распространяются по всей системе? Это возвращается к тому, как модульная система была разработана, чтобы быть в первую очередь. Если вы не хуже, чем ваши конкуренты в выводе функций на рынок, то вы, вероятно, в порядке.
Какова будет стоимость переписывания системы? Как это соотносится с тем, насколько дешевле будет поддерживать или увеличивать доход от продаж? Это может быть экономически нецелесообразно сделать полностью переписать. Если платформа разработки надежна, то вы можете просто попробовать больше рефакторинга. Здесь хороший набор тестов и документация помогают.