¿Cómo rescatar un proyecto Salesforce estancado? Metodología de diagnóstico y rescate

La respuesta corta

La mayoría de los proyectos de Salesforce que se estancan no lo hacen por un código deficiente. Se estancan porque nadie se detuvo a tiempo para preguntar qué cambia realmente en el trabajo de los usuarios, quién es responsable de cada decisión y qué sucede cuando algo no sale según lo planeado. El resultado: sprint tras sprint que añade funcionalidades, sin que el panorama general mejore.

Rescatar un proyecto de Salesforce estancado significa, ante todo, detener la “hemorragia” y solo después decidir qué hacer con lo ya construido. Este orden es crucial: muchas organizaciones pasan directamente a la fase de corrección sin diagnosticar primero por qué falló el proceso anterior, repitiendo el mismo error por segunda vez. Aquellos que deseen entender cómo priorizar la deuda acumulada pueden profundizar en priorización de deuda técnica en Salesforce.

Señales de estancamiento: cómo identificar que el proyecto ya no va por el camino correcto

Hay una diferencia entre un proyecto que avanza lentamente y uno que ya no se mueve. Las siguientes señales se repiten en casi todos los rescates que hemos realizado:

• Las reuniones de estado se convierten en reuniones de justificación: una reunión de estado semanal que se transforma en excusas sobre por qué algo aún no está listo, sin una nueva fecha límite fiable.
• El backlog crece más rápido que la tasa de cierre: se añaden nuevos elementos cada semana, pero el número de elementos cerrados permanece constante o disminuye.
• Ninguna versión ha sido probada con un usuario real en el último mes: solo demostraciones internas del equipo técnico, sin contacto con quienes realmente utilizarán el sistema.
• Cambios frecuentes de requisitos sin documentación: cada conversación genera "otro pequeño cambio" que no se incorpora a un documento de alcance organizado.
• Falta de confianza evidente: los usuarios ya están creando hojas de cálculo de Excel paralelas "por si acaso", y esa es una señal de que han dejado de creer que el sistema funcionará a tiempo.

Cuando cuatro de estas cinco señales se presentan simultáneamente, se trata de un proyecto estancado y no de un proyecto lento, y esa diferencia cambia toda la estrategia de abordaje.

Diagnóstico en 10 días: qué verificar y en qué orden

Un buen diagnóstico no requiere dos meses. Diez días hábiles, con la asignación adecuada, son suficientes para obtener una imagen lo suficientemente fiable como para tomar una decisión. Una distribución recomendada:

Días 1-2: Entrevistas y mapeo inicial. Conversaciones breves con el patrocinador, el propietario del proceso, dos o tres usuarios finales y el jefe del equipo de desarrollo. El objetivo es recopilar diferentes versiones de "qué salió mal", sin llegar aún a una conclusión.

Días 3-5: Revisión técnica directa. Acceso al propio entorno (Org): estructura de datos, automatizaciones existentes, permisos, registros de errores y consultas lentas. Aquí se verifica si el problema es arquitectónico u operativo.

Días 6-7: Comparación entre lo prometido y lo construido. Lectura de los documentos originales (SOW, User Stories, Design Docs si existen) frente al estado real en el Sandbox o Producción.

Días 8-10: Formulación de hallazgos y decisión inicial. Un documento conciso que clasifica cada problema encontrado como alcance, arquitectura o confianza, y presenta una primera recomendación: Reinicio (Reset), Refactorización (Refactor) o Continuación a un ritmo rectificado.

Tres capas del problema: Alcance, Arquitectura y Confianza

El error más común es abordar cada estancamiento como si fuera un único problema. En realidad, casi siempre se trata de una combinación de tres capas diferentes, cada una de las cuales requiere un enfoque distinto.

El problema de Alcance se manifiesta en que nadie sabe realmente qué se incluye en la primera versión. Esto ocurre cuando la definición original era demasiado general ("gestionar todo el proceso de ventas en Salesforce") y no se desglosó en escenarios concretos. La solución no es otra reunión de planificación, sino la redacción de una lista clara de “Obligatorio”, “Debería tener” y “Para más adelante”, con un Propietario para cada elemento.

El problema de Arquitectura se manifiesta en elecciones técnicas que no resisten a escala: un modelo de datos que no soporta la cantidad de registros, una automatización que se ejecuta en un orden incorrecto, una integración que falla silenciosamente. Aquí se requiere una verificación técnica profunda y, a veces, la intervención de una actualización del sistema Salesforce como infraestructura paralela para la corrección.

El problema de Confianza es, en su mayoría, el resultado de los dos primeros, pero adquiere vida propia: los usuarios dejan de informar problemas porque "de todos modos no los arreglan", y la dirección deja de financiar cambios porque "ya lo intentamos". Un problema de confianza no se resuelve con declaraciones, sino con pruebas pequeñas y repetidas.

Tabla de diagnóstico: Síntoma, Causa Raíz y Primera Acción

Reinicio (Reset) versus Refactorización (Refactor): cómo decidir

Esta es la decisión central y también la más costosa, por lo que debe basarse en criterios y no en una intuición. Tres pruebas ayudan:

1. El alcance de la deuda técnica frente al alcance de lo que ya funciona. Si el 70% de la funcionalidad funciona razonablemente y solo partes específicas fallan, es una Refactorización. Si el problema radica en el modelo de datos básico, casi siempre es preferible un Reinicio parcial.
2. El costo de la explicación frente al costo de la reconstrucción. Si al nuevo equipo le lleva más de una semana entender por qué algo se construyó de cierta manera, es probable que el costo de mantenimiento futuro supere el costo de una construcción limpia.
3. El estado de confianza de los usuarios. Cuando la confianza es muy baja, un Reinicio enfocado y transparente (con el anuncio "estamos iniciando una nueva versión, corregida") a veces logra más cooperación que una corrección silenciosa que los usuarios no perciben.

En la práctica, la mayoría de los rescates exitosos son híbridos: un Reinicio para el componente central problemático (por ejemplo, el modelo de Opportunity o el proceso de aprobación), junto con una Refactorización del resto del sistema. Una comparación estructurada entre los enfoques se presenta en reconstruir Salesforce, que detalla los criterios para cada escenario.

Plan de 90 días para el rescate

Es crucial planificar la etapa de la "primera ola" en torno a un proceso único que los usuarios notarán en cuestión de semanas, y no en torno al componente técnicamente más interesante. Los proyectos que fallan por segunda vez suelen hacerlo porque vuelven a cometer el mismo error: empezar por la capacidad impresionante en lugar del dolor real. Esta etapa está directamente relacionada con el rendimiento en la práctica, y aquellos que experimenten problemas de velocidad de respuesta pueden consultar optimización del rendimiento de Salesforce.

Recuperación de la confianza con los usuarios

La confianza no se recupera por una presentación; se recupera por un patrón consistente de pequeñas promesas cumplidas. Algunos principios que han funcionado en la práctica:

• Anuncie una pequeña victoria de manera explícita. Cuando haya corregido un error recurrente, envíe un mensaje breve que diga exactamente qué se corrigió y quién lo solicitó. Dicha transparencia genera más confianza que una lista general de logros.
• Invite a los usuarios a una prueba temprana, no solo a la UAT al final. Quien ve una versión intermedia y siente que sus comentarios fueron tomados en cuenta, se convierte en un embajador del proyecto ante el resto del equipo.
• No prometa una fecha de la que no esté seguro. Una fecha pospuesta por tercera vez daña la confianza más que un cronograma realista pero menos optimista.
• Documente un fallo públicamente también. Cuando algo no funcionó, una breve explicación de lo sucedido y lo que cambia genera más credibilidad que una silenciosa omisión.

El proceso de recuperación de la confianza suele durar más que la propia corrección técnica, por lo que es aconsejable planificarlo como una vía paralela al plan de 90 días y no como un resultado automático del mismo. Las organizaciones que desean un acompañamiento estructurado para este proceso, incluyendo un seguimiento cercano del equipo y la dirección, pueden utilizar el servicio Salesforce Health Check como un marco de trabajo completo.

Escenario organizacional de ejemplo

Una empresa de servicios financieros ejecutó un proyecto Salesforce durante nueve meses sin un Go Live. En la revisión, se descubrió que el alcance se había triplicado respecto a lo planeado originalmente, que el equipo técnico había construido tres versiones diferentes del mismo proceso de aprobación sin documentar el porqué, y que los usuarios clave ya habían migrado la gestión del informe mensual a una hoja de cálculo separada.

El plan de diagnóstico de diez días reveló que el problema central no era técnico: el equipo técnico había recibido requisitos contradictorios de dos gerentes diferentes sin que nadie los coordinara. La decisión fue una Refactorización parcial, no un Reinicio completo, porque la mayor parte del código estaba correcto. La primera etapa se centró únicamente en el proceso de aprobación, que era la principal fuente de frustración, y en cinco semanas se lanzó una versión estable que los gerentes aprobaron conjuntamente. Solo entonces continuaron con la expansión de los demás procesos.

La lección principal: el estancamiento no se debió a un fallo técnico puntual, sino a la ausencia de una única persona que tuviera el mapa completo de decisiones. Un rol ऐसे como este, incluso si es temporal, suele ser la diferencia entre un proyecto que tiene éxito la segunda vez y uno que vuelve a estancarse.

Lista de verificación antes de decidir sobre un rescate

• ☐ Se realizó un diagnóstico de 10 días con entrevistas, revisión del Org y comparación con documentos originales
• ☐ Los problemas se clasificaron claramente en Alcance, Arquitectura o Confianza
• ☐ Se tomó una decisión documentada de Reinicio/Refactorización con justificaciones
• ☐ Se seleccionó un proceso para la primera ola basado en un dolor real de los usuarios
• ☐ Se definió un Change Freeze para el período de diagnóstico y decisión
• ☐ Se establecieron métricas de línea base antes de iniciar la corrección
• ☐ Existe un plan de comunicación continuo para usuarios y dirección
• ☐ Se designó un único Propietario que tiene el mapa completo de decisiones
• ☐ El plan de 90 días incluye hitos medibles y no solo una fecha de finalización
• ☐ Se definió un proceso para la entrega de Gobernanza y mantenimiento al finalizar el rescate

Recursos profesionales

• 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 – Soporte y acompañamiento — https://hpi.pro/support