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