Краткий ответ
Три перечисленных подхода не являются взаимозаменяемыми. Repair устраняет симптомы, Refactor изменяет реализацию без изменения поведения, а Rebuild меняет базовую модель. Решение принимается на основе одного вопроса: кроется ли проблема в способе реализации или в первоначальном определении.
Если модель данных корректна, а сложности связаны с запутанными автоматизациями и сложными разрешениями — это Refactor. Если один и тот же объект используется в трех противоречивых процессах и по нему невозможно сформировать отчетность — это системный корень проблемы, и тогда Rebuild становится предметом обсуждения.
Четыре критерия принятия решения
| Критерий | Указывает на Refactor | Указывает на Rebuild |
|---|---|---|
| Модель данных | Корректна, но страдает от избытка полей | Объекты, обслуживающие противоречивые цели |
| Источник проблем | Производительность, дублирование автоматизаций | Невозможность формирования отчетности или масштабирования |
| Масштаб затронутых пользователей | Частичный, поддающийся изоляции | Обширный, затрагивающий все процессы |
| Стоимость повторного тестирования | Можно протестировать отдельную область | Любое изменение требует полного регрессионного тестирования |
Для принятия решения достаточно совпадения трех строк. Различия между строками, как правило, означают, что проблема локальнее, чем кажется.
Почему Rebuild дороже, чем оценка
Стандартная оценка учитывает только стоимость перестройки. Она почти всегда игнорирует четыре аспекта: миграцию исторических данных со всеми накопленными исключениями, перестройку интеграций, каждая из которых согласовывается со сторонними поставщиками, период параллельной работы двух систем и полное переобучение всех пользователей.
На практике эти четыре аспекта зачастую составляют более половины общей стоимости. Организация, рассматривающая Rebuild и не включившая их в смету, сравнивает «яблоки» с «половиной апельсина».
Практический путь: поэтапная замена
Даже когда принято решение о Rebuild, реализация проекта по принципу «останови и замени» сама по себе является рискованной. Рабочим подходом является поэтапная замена:
- Создание новой модели рядом со старой – новые объекты, без затрагивания существующих.
- Перенос одного законченного процесса – с его пользователями, данными и отчетами.
- Отключение старого аналога – это шаг, который большинство организаций откладывают, что делает проект двойным.
- Повторение до тех пор, пока старая система не будет опустошена.
Шаг три является проверкой. Система, в которой старое и новое сосуществуют в течение целого года, увеличила затраты и не сократила технический долг.
Что необходимо изменить в любом случае
Оба подхода терпят неудачу, если механизм изменений остается прежним. Минимальное управление – кто одобряет изменение модели, какое обязательное тестирование проводится перед развертыванием и кто является владельцем каждой области – это условие, предотвращающее возвращение к исходной точке. Приоритизация технического долга подробно описана в Приоритизация технического долга Salesforce, а предварительные признаки – в 8 признаков необходимости обновления Salesforce.
Заключение
Выбор стоит не между «исправлением» и «началом заново», а между исправлением реализации и исправлением определения. В большинстве случаев, которые кажутся Rebuild, скрывается корректная модель данных, погребенная под десятилетием автоматизаций — и эту проблему решают волнами, а не полным удалением.