Как реанимировать застрявший проект Salesforce? Методология диагностики и спасения

Краткий ответ

Большинство проектов Salesforce, которые «застревают», сталкиваются с проблемами не из-за плохого кода. Они тормозятся, потому что никто своевременно не задается вопросом о том, что именно меняется в работе пользователей, кто несет ответственность за каждое решение и что происходит, когда что-то идет не по плану. Результат: спринт за спринтом добавляются новые функции, но общая картина не улучшается.

Спасение «застрявшего» проекта Salesforce означает сначала остановить «кровотечение», а затем решить, что делать с уже созданным. Этот порядок критически важен: многие организации приступают непосредственно к этапу исправления, не проведя предварительную диагностику причин провала предыдущего процесса, и повторяют ту же ошибку во второй раз. Те, кто хочет понять, как приоритизировать накопившийся долг, могут углубиться в приоритизацию технического долга Salesforce.

Признаки замедления: как понять, что проект сошел с правильного пути

Существует разница между проектом, который движется медленно, и проектом, который уже остановился. Следующие признаки повторяются почти в каждом случае «спасения», которые мы осуществляли:

• Обсуждения статуса превращаются в объяснительные: Еженедельное совещание по статусу проекта превращается в оправдания того, почему что-то еще не готово, без надежной новой даты завершения.
• Бэклог растет быстрее, чем скорость его закрытия: Новые задачи добавляются каждую неделю, но количество закрытых задач остается постоянным или уменьшается.
• За последний месяц не было версии, протестированной реальным пользователем: Только внутреннее демонстрация технической команды, без взаимодействия с теми, кто будет фактически работать с системой.
• Частое изменение требований без документирования: Каждое обсуждение приводит к «еще одному небольшому изменению», которое не вносится в структурированный документ Scope Document.
• Откровенное недоверие: Пользователи уже создают параллельные таблицы Excel «на всякий случай», и это признак того, что они перестали верить, что система заработает вовремя.

Когда четыре из этих пяти признаков проявляются одновременно, речь идет о «застрявшем» проекте, а не о медленном, и эта разница меняет всю стратегию лечения.

Диагностика за 10 дней: что проверять и в каком порядке

Хорошая диагностика не требует двух месяцев. Десяти рабочих дней при правильном распределении ресурсов достаточно, чтобы получить достаточно достоверную картину для принятия решения. Рекомендуемое распределение:

Дни 1-2: Интервью и первичное картирование. Короткие беседы со спонсором проекта, владельцем процесса, двумя-тремя конечными пользователями и руководителем команды разработки. Цель состоит в сборе различных версий «что пошло не так», а не в немедленном формулировании выводов.

Дни 3-5: Прямая техническая проверка. Вход в сам Org: структура данных, существующая автоматизация, разрешения, журналы ошибок и медленные запросы. Здесь проверяется, является ли проблема архитектурной или операционной.

Дни 6-7: Сравнение обещанного с построенным. Чтение исходных документов (SOW, User Stories, Design Docs, если имеются) по сравнению с фактическим состоянием в Sandbox или Production.

Дни 8-10: Формирование выводов и первоначальное решение. Краткий документ, который классифицирует каждую найденную проблему как проблему Scope, архитектуры или доверия, и представляет первую рекомендацию: Reset, Refactor или продолжение в скорректированном темпе.

Три уровня проблемы: охват, архитектура и доверие

Наиболее распространенная ошибка – рассматривать каждую проблему как единое целое. На практике почти всегда это комбинация трех различных уровней, каждый из которых требует своего подхода.

Проблема охвата (Scope) проявляется в том, что никто толком не знает, что входит в первую версию. Это происходит, когда первоначальное определение было слишком общим («управлять всем процессом продаж в Salesforce») и не было разложено на конкретные сценарии. Решение — это не еще одно совещание по планированию, а написание четкого списка Must/Should/Later, с назначением ответственного за каждый пункт.

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

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

Таблица диагностики: симптом, первопричина и первое действие

Reset против Refactor: как принять решение

Это центральное и самое дорогостоящее решение, поэтому оно должно основываться на критериях, а не на интуиции. Три теста помогают:

1. Объем технического долга по сравнению с объемом уже работающего. Если 70% функциональности работает удовлетворительно и только определенные части дают сбои, это Refactor. Если проблема коренится в базовой модели данных, почти всегда предпочтительнее частичный Reset.
2. Стоимость объяснений по сравнению со стоимостью перестройки. Если новой команде требуется более недели, чтобы понять, почему что-то было построено определенным образом, вероятно, будущие затраты на поддержку превысят стоимость чистой сборки.
3. Состояние доверия пользователей. Когда доверие очень низкое, целенаправленный и открытый Reset (с объявлением «мы начинаем новую, исправленную версию») иногда дает больше сотрудничества, чем тихое исправление, которое пользователи не замечают.

На практике большинство успешных «спасений» являются гибридными: Reset для проблемного основного компонента (например, модели Opportunity или процесса утверждения), наряду с Refactor для остальной части системы. Подробное сравнение подходов приведено в перестроить Salesforce, где описаны критерии для каждого сценария.

90-дневный план спасения

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

Восстановление доверия пользователей

Доверие не возвращается благодаря презентации; оно возвращается благодаря последовательной модели небольших обещаний, которые выполняются. Несколько принципов, которые работали на практике:

• Четко объявите о маленькой победе. Когда вы устранили повторяющуюся проблему, отправьте короткое сообщение, точно указывающее, что было исправлено и кто об этом просил. Такая прозрачность строит больше доверия, чем общий список достижений.
• Приглашайте пользователей на предварительное тестирование, а не только на UAT в конце. Тот, кто видит промежуточную версию и чувствует, что его замечания были учтены, становится амбассадором проекта среди остальной команды.
• Не обещайте дату, в которой не уверены. Дата, которая переносится в третий раз, наносит больший ущерб доверию, чем реальный, но менее оптимистичный график.
• Публично документируйте неудачи. Когда что-то не сработало, короткое объяснение того, что произошло и что меняется, строит больше доверия, чем молчаливое игнорирование.

Процесс восстановления доверия обычно занимает больше времени, чем само техническое исправление, поэтому его стоит планировать как параллельный путь к 90-дневному плану, а не как его автоматический результат. Организации, которым требуется структурированное сопровождение этого процесса, включая тесное сопровождение команды и руководства, могут использовать сервис Salesforce Health Check в качестве полноценной рабочей среды.

Пример организационного сценария

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

10-дневный диагностический план показал, что основная проблема не была технической: техническая команда получала противоречивые требования от двух разных менеджеров, не скоординированных друг с другом. Решение заключалось в частичном рефакторинге, а не в полном сбросе, поскольку большая часть кода была корректной. Первый этап был сосредоточен исключительно на процессе утверждения, который был основным источником разочарования, и в течение пяти недель была выпущена стабильная версия, совместно одобренная менеджерами. Только после этого продолжилось расширение остальных процессов.

Основной урок: проблема не возникла из-за однократного технического сбоя, а из-за отсутствия единого ответственного за все решения. Такая роль, даже если она временная, зачастую является разницей между проектом, который успешно реализуется во второй раз, и проектом, который снова застревает.

Чек-лист перед принятием решения о спасении

• ☐ Выполнена 10-дневная диагностика с интервью, проверкой Org и сравнением с исходными документами
• ☐ Проблемы четко классифицированы по категориям Scope, архитектура или доверие
• ☐ Принято задокументированное решение о Reset/Refactor с обоснованиями
• ☐ Выбран один процесс для первой волны на основе реальной проблемы пользователей
• ☐ Определена «заморозка» изменений (Change Freeze) на период диагностики и принятия решения
• ☐ Установлены базовые показатели (Baseline) перед началом исправления
• ☐ Существует план регулярной коммуникации для пользователей и руководства
• ☐ Назначен единственный ответственный за все решения
• ☐ 90-дневный план включает измеримые этапы, а не только дату завершения
• ☐ Определен процесс передачи управления (Governance) и обслуживания после завершения спасения

Профессиональные ресурсы

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
• HPI Pro – Поддержка и сопровождение — https://hpi.pro/support