Программа продолжает работать, но человек, который её создал, больше не участвует в проекте. В компании есть папка с файлами, несколько паролей и привычка «не трогать этот сервер». При первой новой потребности возникает выбор: искать специалиста для доработки или начинать замену.
Решение нельзя принять по возрасту интерфейса или первому впечатлению от кода. Важно выяснить, можно ли воспроизвести систему, объяснить её существенные правила и безопасно проверять изменения. Для заказчика полезен не общий вердикт «всё плохо», а доказательства состояния и понятные варианты действий.
Сначала сохраните возможность продолжать работу
Назначьте ответственного за обследование и согласуйте, какие действия допустимы в действующей среде. Исследование не должно начинаться с обновления компонентов на единственном рабочем сервере.
Соберите имеющиеся материалы: исходные тексты, установочные пакеты, настройки, описание внешних связей, инструкции и историю изменений. Доступы передают через установленный в компании безопасный порядок, не вставляя секреты в общий отчёт.
Зафиксируйте, что реально работает сейчас: версия программы, основные пользователи, расписание фоновых операций, зависимости от других систем. Отдельно перечислите компоненты, назначение которых пока неизвестно.
Резервная копия полезна, только если понятен способ восстановления. Не стоит обещать сохранность на основании одного файла с подходящим названием.
Наличие кода и возможность запуска — разные вещи
Исходный код может не соответствовать рабочей версии. В нём могут отсутствовать части, которые добавлялись непосредственно на сервере, или использоваться недоступные зависимости.
Попросите показать воспроизводимый запуск в отдельной разрешённой среде. Это означает, что другой специалист может получить нужные материалы, выполнить описанную последовательность и открыть проверяемую версию приложения.
Результатом должна быть не только работающая страница, но и перечень условий: какие компоненты нужны, где находятся настройки, что заменено тестовым аналогом и какие функции ещё не проверены.
Если запуск невозможен, это важное ограничение. Оно не всегда означает необходимость полной замены, но меняет риск и стоимость любого дальнейшего изменения.
Условный пример: программа распределения заявок
Рассмотрим вымышленную компанию, использующую самописную программу для заявок на обслуживание. Автор ушёл, а руководитель хочет добавить второй филиал. Пример не является кейсом ExtentLab.
На рабочем сервере программа открывается. В найденном архиве отсутствует расписание фонового задания, которое назначает ответственных. Новый специалист запускает интерфейс отдельно, но заявки остаются без исполнителя.
Обследование показывает, что часть правил находится в конфигурации сервера, а часть — в справочнике подразделений. Значит, папка с кодом ещё не описывает весь продукт.
Следующий результат обследования — восстановленная схема назначения, тестовый пример и перечень настроек. Только после этого можно оценить добавление филиала: простое изменение формы не решило бы задачу.
Восстановите существенные бизнес-правила
Начните с нескольких операций, от которых зависит работа компании. Для каждой попросите пользователя показать обычный случай и исключение.
Записывайте:
- какие данные поступают и откуда;
- кто вправе начать действие;
- какие условия влияют на решение;
- какие значения рассчитываются;
- где появляется результат;
- как исправляется ошибка.
Сопоставляйте объяснения сотрудников с фактическим поведением. Пользователь может помнить устаревший порядок, а код — содержать обходное правило, о котором никто не знает. Оба источника требуют проверки.
Особенно важны даты, округления, статусы и скрытые справочники. Небольшое правило в расчёте может иметь большее значение для бизнеса, чем большая часть интерфейса.
Проверьте данные и внешние связи
Выясните, какие данные являются рабочими, какие — копиями, а какие — временными результатами. Не удаляйте неизвестную таблицу только потому, что её название кажется устаревшим.
Проверьте связи между сущностями на ограниченном наборе: заявка, клиент, ответственный, выполненная работа. Отдельно найдите внешние обмены, файловые папки и задания по расписанию.
Для каждой зависимости определите владельца и наблюдаемый признак исправности. Если импорт перестал выполняться неделю назад, программа может выглядеть доступной, но показывать неполные сведения.
Не обещайте исчерпывающий аудит всей системы за один короткий просмотр. В отчёте должны быть глубина проверки, исследованные части и неизвестные участки.
Малое пробное изменение лучше абстрактной оценки
Когда среда подготовлена, можно выбрать ограниченное изменение без вмешательства в рабочие данные. Например, добавить проверку обязательного поля в тестовом сценарии.
Такой опыт показывает путь от исходников до проверяемого результата: где вносится изменение, как собирается приложение, какие проверки выполняются и как отменяется неудачная версия.
Успешная проба не доказывает, что любое развитие будет простым. Но она даёт основание для оценки следующего похожего шага и выявляет организационные пробелы.
В вымышленном примере добавление филиала всё равно требует проверки разграничения заявок. Нельзя считать готовым расширение только потому, что новый пункт появился в списке.
Как выбрать дальнейшее направление
Доработка разумна, если рабочая версия воспроизводится, существенные правила понятны, а требуемое изменение не затрагивает неизвестные критичные части.
Стабилизация нужна, когда система полезна, но сначала требуется упорядочить запуск, изменения, проверки и восстановление. Это самостоятельный результат, а не скрытая подготовка без окончания.
Замена отдельной функции подходит, если ограничение локализовано и есть проверяемый способ взаимодействия со старой программой.
Полная замена рассматривается, когда ограничения нельзя приемлемо закрыть другими вариантами. При этом всё равно придётся понять данные и действующие обязательства; новый код не освобождает от исследования.
Когда можно перейти на готовое решение
Если фактические процессы стандартны, готовая система может оказаться подходящим продолжением. Сравните её с обязательными операциями, а не с каждой исторической особенностью интерфейса.
Отдельно оцените перенос данных, работу пользователей, внешние связи и ограничения. Готовый продукт не становится пригодным только потому, что поставщик поддерживает его централизованно.
Если уникальные правила действительно определяют ценность бизнеса, заказная доработка или новый сервис могут быть обоснованы. Решение должно опираться на проверенные сценарии и ограничения, а не на привычку сохранять всё самописное.
Требуйте объяснимые основания оценки
В отчёте отделяйте факт, предположение и рекомендацию. Факт подтверждается наблюдением: рабочая версия не собирается из переданных материалов, определённый сценарий даёт расхождение, внешняя зависимость недоступна. Предположение указывает, что ещё нужно проверить.
Рекомендация должна объяснять связь с бизнес-риском. Формулировка «переписать на современном стеке» без описания ограничения не помогает выбрать действие. Полезнее показать, какой результат невозможен сейчас и какие варианты снимают препятствие.
Попросите выделить обязательные работы для ближайшего изменения и улучшения, которые можно отложить. Это защищает обследование от превращения в бесконечный список технических пожеланий.
Также зафиксируйте, что останется неизвестным после выбранного этапа. Частичный аудит может быть достаточен для ограниченной доработки, но его нельзя представлять как полное подтверждение качества всей системы. Следующее решение должно учитывать именно проверенную область.
Что получить по результатам обследования
- Состав доступных материалов и обнаруженные пробелы.
- Описание рабочей версии и внешних зависимостей.
- Подтверждённый способ запуска либо причины невозможности.
- Карта основных сценариев с примерами.
- Перечень проверенных и неисследованных участков.
- Результат пробного изменения, если оно входило в объём.
- Варианты продолжения с условиями и рисками.
- Конкретный следующий этап и критерий его завершения.
С ExtentLab можно начать разговор с текущей программы и одной задачи, которую бизнес не может решить. Это позволяет обсуждать обоснованный следующий шаг, не обещая заранее ни простую доработку, ни обязательную полную замену.