Roles que Impulsan el Ritmo del Proyecto
En un proyecto Salesforce, es posible contar con un arquitecto excelente, un equipo de desarrollo experimentado y un director de proyecto organizado, y aun así quedarse atrás en el cronograma. La razón más común no es el ritmo de construcción, sino el ritmo de la toma de decisiones. El desarrollo espera una decisión, la decisión espera una reunión y la reunión espera una agenda.
Por lo tanto, la división efectiva de roles no se basa en quién hace qué, sino en quién decide qué y con qué tiempo de respuesta. Una revisión de las etapas en las que se requiere cada rol se encuentra en la Guía de Implementación de Salesforce.
Los Nueve Roles y Su Mandato
Executive Sponsor — Resuelve conflictos entre departamentos, aprueba dispensas del alcance y protege la prioridad frente a presiones concurrentes. Si no tiene autoridad presupuestaria, no es un Sponsor, sino un representante.
Dueño del Proceso — Define cómo se realizará el trabajo en la práctica después del cambio, y valida que el proceso construido se ajusta a la realidad. Uno por cada proceso central, no un comité.
Product Owner / Gerente CRM — Gestiona la prioridad en el backlog, resuelve solicitudes concurrentes y mantiene la conexión entre los requisitos y el valor.
Director de Proyecto — Cronograma, dependencias, riesgos, coordinación de proveedores e informes.
Arquitecto de Soluciones — Decide sobre el modelo de datos, permisos, límites del sistema y la forma de implementación; responsable de documentar alternativas consideradas.
Salesforce Admin — Configuración, entornos, gestión de usuarios y mantenimiento continuo después del lanzamiento.
Desarrollador — Lógica personalizada, integraciones, pruebas automatizadas.
Dueño de Datos — Determina la fuente de la verdad, qué se considera un registro válido y quién aprueba la carga.
Líder de Adopción y Capacitación — Comunicación, formación según el rol, gestión de la resistencia y medición del uso.
En un proyecto pequeño, una persona puede desempeñar dos roles, pero hay dos pares que es preferible no unificar: arquitecto y director de proyecto (conflicto entre exhaustividad y velocidad), y dueño del proceso y líder de pruebas (se prueba a sí mismo).
Quién Debe Ser Interno
| Rol | Posibilidad de Provisión Externa | Explicación |
|---|---|---|
| Executive Sponsor | No | Requiere autoridad organizacional |
| Dueño del Proceso | No | Requiere apropiación del trabajo en la práctica |
| Dueño de Datos | No | Requiere responsabilidad regulatoria y empresarial |
| Product Owner | Parcialmente | Es posible el acompañamiento, no la sustitución |
| Director de Proyecto | Sí | Común y adecuado |
| Arquitecto de Soluciones | Sí | Recomendable con acompañamiento interno para el conocimiento |
| Admin | Sí, temporalmente | Preferible transferir a un recurso interno antes del Go Live |
| Desarrollador | Sí | Estándar |
| Líder de Adopción | Parcialmente | El mensaje interno debe provenir de la organización |
Matriz RACI para los Puntos de Decisión Clave
| Decisión | Responsable (Accountable) | Consultado (Consulted) | Tiempo de Respuesta Requerido |
|---|---|---|---|
| Estructura del modelo de datos | Arquitecto | Dueño del proceso, Dueño de Datos | Hasta una semana |
| Cambio en el Alcance (Scope) | Sponsor | Product Owner, Director de Proyecto | Hasta una semana |
| Prioridad en el Backlog | Product Owner | Dueños de procesos | Hasta dos días |
| Definición de campo obligatorio | Dueño del proceso | Admin | Hasta dos días |
| Aprobación de carga de datos | Dueño de Datos | Arquitecto | Hasta tres días |
| Aprobación de paso a producción | Sponsor | Director de Proyecto, Dueño del proceso | Según puerta definida |
| Resolución de incidencia bloqueante | Director de Proyecto | Arquitecto, Admin | El mismo día |
La columna de tiempo de respuesta es la parte interesante de la tabla. Un RACI sin SLA para la decisión es una descripción agradable que no cambia el ritmo.
Disponibilidad Real — El Error Recurrente en la Planificación
| Rol | Etapa de Definición | Etapa de Construcción | Etapa de Pruebas | Go Live y Semanas Posteriores |
|---|---|---|---|---|
| Sponsor | Baja, constante | Baja | Media | Media |
| Dueño del Proceso | Alta | Media | Muy alta | Alta |
| Product Owner | Alta | Alta | Alta | Media |
| Admin | Media | Alta | Alta | Muy alta |
| Dueño de Datos | Media | Baja | Alta | Media |
| Líder de Adopción | Baja | Media | Media | Muy alta |
La planificación defectuosa común es la suposición de que la carga del dueño del proceso disminuye después de la definición. En realidad, vuelve a aumentar en la fase de pruebas, justo cuando el empleado regresa a su trabajo habitual.
Ejemplo Ilustrativo: Colegio Universitario
El escenario es hipotético y tiene fines ilustrativos. Un colegio implementó un sistema de gestión de candidatos. El equipo se definió correctamente en papel, pero el "dueño del proceso" era el jefe de la sección de admisiones, quien dedicaba dos horas semanales al proyecto. Cualquier pregunta sobre el estado de un candidato esperaba hasta el martes por la mañana.
Después de dos meses, se determinó que el retraso acumulado por la espera de decisiones superaba el retraso por cualquier otra razón combinada. La solución no fue contratar más desarrolladores. El colegio designó a un subalterno que recibió un mandato expreso para tomar decisiones diarias hasta un nivel de impacto definido, dejando al jefe de la sección solo las decisiones que modificaban la política. El ritmo de desarrollo aumentó sin cambios en el tamaño del equipo del proveedor.
Modelo de Trabajo con el Proveedor
Tres mecanismos son suficientes para la mayoría de los proyectos:
- Registro de decisiones compartido — Cada decisión con fecha, responsable, justificación y alternativas rechazadas. Esta es también la única documentación que sigue siendo útil dos años después.
- Punto de contacto único en ambos lados — Las solicitudes directas de múltiples participantes a los desarrolladores son la forma segura de perder la trazabilidad.
- Ciclo de demostración a ritmo constante — El dueño del proceso ve un producto funcional, no una presentación. La brecha entre la expectativa y la implementación se revela en dos semanas en lugar de dos meses.
En organizaciones grandes, se requiere una capa adicional de gobernanza entre unidades de negocio, como se describe en la Guía de Implementación de Salesforce en una Organización Enterprise.
Puntos de Encuentro con Otras Etapas
La composición del equipo se deriva directamente de dos aspectos: los entregables requeridos en la fase de definición, detallados en la Guía de Descubrimiento de CRM, y el alcance de la primera ola, determinado según las reglas en la Guía de Definición de MVP. Una primera ola más delimitada requiere menos dueños de procesos concurrentes, y esta es una razón independiente para reducir la amplitud.
Revisión Rápida Antes de Iniciar un Proyecto
Responda a cuatro preguntas con nombre y apellido, no con el nombre de un departamento: ¿Quién decide cuando Ventas y Operaciones no están de acuerdo?; ¿Quién aprueba que el proceso construido se ajusta a la realidad?; ¿Quién indica qué datos son fiables?; y ¿Quién mantendrá el sistema dentro de un año? Una respuesta faltante a cualquiera de ellas es el mayor riesgo en el proyecto, y es también la única que no se resuelve con dinero.