Respuesta breve
A un cliente le sirve mejor un único especialista con nombre que tiene autoridad para decidir sobre prioridades, alcance y aceptación, y que responde del resultado. Las normas públicas del trabajo digital, del Digital Services Playbook de Estados Unidos a la Guía de Scrum, dicen lo mismo: una persona, no un comité. Antes de firmar, pregunte quién es esa persona, qué puede decidir sin pedir permiso, quién la sustituye y con qué rapidez llegará una decisión, no una simple respuesta.
Un buzón compartido puede contestarle; no puede decidir
Muchas empresas de servicios dan al cliente una dirección que no pertenece a nadie en concreto: un buzón de proyectos, un formulario de soporte, una cola de incidencias. Tiene virtudes reales. Los mensajes no se pierden cuando alguien está de vacaciones, varias personas ven el historial y el cliente siempre tiene adónde escribir. Para las peticiones rutinarias es justo lo que hace falta.
La debilidad aparece con la primera pregunta que exige criterio. ¿Se puede mover el lanzamiento una semana? ¿Entra este cambio en el precio? ¿Cuál de estas dos opciones elegirían ustedes? Un buzón puede acusar recibo de un mensaje así en minutos. No puede contestarlo, porque una respuesta es una decisión, y una decisión necesita a alguien con derecho a tomarla y dispuesto a respaldarla.
La distinción útil no es, por tanto, entre una persona y un buzón. Es entre un canal, que transporta mensajes, y un dueño, que los resuelve. Un proyecto puede tener ambos, y a menudo debe. De lo que no puede prescindir es del segundo: un especialista con nombre que responde del resultado y tiene la autoridad que eso requiere.
Tres normas públicas llegan a la misma regla: una persona
El Digital Services Playbook del Gobierno de Estados Unidos convierte la regla en el título de su sexta jugada: asigne un solo líder y pídale cuentas a esa persona. El texto pide un único product owner con la autoridad y la responsabilidad de asignar tareas, tomar decisiones de negocio, de producto y técnicas, y responder del éxito o el fracaso del servicio en su conjunto.
La Guía de Scrum (Scrum Guide), en la que Ken Schwaber y Jeff Sutherland definen el marco Scrum, es aún más breve: el Product Owner es una persona, no un comité. Añade una condición que es fácil pasar por alto. Para que esa persona tenga éxito, toda la organización debe respetar sus decisiones, y quienes quieran cambiar el orden del trabajo pueden hacerlo tratando de convencer al Product Owner.
El GOV.UK Service Manual dice del service owner, el responsable del servicio, que debe tener autoridad de decisión para sacar adelante todos los aspectos de un proyecto. Los tres documentos se escribieron para equipos que construyen software y servicios públicos, no para un estudio que diseña una marca ni para una agencia que lleva una campaña. El razonamiento se traslada sin cambios, porque trata de cómo se toman las decisiones y no de lo que se construye.
Responder del resultado no significa hacer todo el trabajo en solitario
La objeción habitual a un único nombre es que nadie puede saberlo todo. Es cierto y no viene al caso. La Guía de Scrum separa con precisión las dos ideas: el Product Owner puede hacer el trabajo o delegar la responsabilidad en otros y, en cualquier caso, sigue siendo quien rinde cuentas. Los diseñadores diseñan, los desarrolladores construyen, los analistas miden. Una persona responde de que el conjunto equivalga a lo prometido.
El Service Manual traza la misma línea para la calidad. Considera la calidad de un servicio digital responsabilidad de todo el equipo y sitúa la responsabilidad final en el responsable del servicio. Para un cliente, ese es el sentido práctico de rendir cuentas: hay una persona que no puede contestar que era tarea de otro departamento cuando algo se cae entre dos especialistas.
También explica por qué la persona con nombre debe ser un especialista y no un repetidor de mensajes. La lista de comprobación del Playbook espera que el product owner tenga formación en gestión de producto y la experiencia técnica necesaria para evaluar alternativas y sopesar compromisos. Quien solo reenvía preguntas a los que las entienden añade un paso a cada respuesta y no quita nada al riesgo del cliente.
Decisiones que la persona designada debe poder tomar sin preguntar
Un nombre en un contrato vale lo que vale la autoridad que lo respalda. El Playbook ofrece la prueba en forma de pregunta clave: ¿qué hace falta para que el product owner añada o elimine una funcionalidad del servicio? Si la respuesta sincera es una reunión de cinco personas y un correo a un director, el proyecto tiene un portavoz, no un dueño.
En un proyecto comercial importan cuatro tipos de decisión. Prioridades: qué se hace primero cuando falta tiempo. Alcance: si una petición entra en lo acordado y qué se deja fuera si se añade algo. Aceptación: si una parte del trabajo está terminada, tarea que el Service Manual asigna al product manager cuando habla de aceptar las historias de usuario una vez completadas. Y los compromisos entre fecha, coste y calidad cuando no se pueden mantener los tres.
Ningún proveedor sensato da a un empleado un poder ilimitado, y un cliente no debería esperarlo. Lo que importa es que los límites estén declarados. En un acuerdo viable, el responsable único del proyecto decide todo lo que cabe en el presupuesto y el plazo pactados, y se nombra a quien aprueba lo que los excede. Un límite escrito es una fortaleza. Un límite descubierto en la tercera semana es el buzón anónimo con otro nombre.
Continuidad cuando la persona designada enferma, está de permiso o se va
El argumento serio a favor del buzón compartido es la continuidad. La gente enferma, se va de vacaciones y cambia de trabajo, y un proyecto que vive en una sola cabeza se detiene cuando esa cabeza falta. El temor está justificado. El remedio no es hacer a todos igual de responsables, lo que en la práctica significa que nadie lo es, sino planificar la ausencia de antemano.
Tres cosas hacen sustituible a un responsable con nombre sin volver anónima la función. Un suplente, también con nombre, que sigue el trabajo lo suficiente para tomar el relevo. Un registro escrito de las decisiones, guardado donde el cliente pueda leerlo, para que el sucesor herede razones y no solo archivos. Y cuentas, archivos y accesos que pertenecen a la empresa o al cliente, nunca al usuario personal de un individuo.
Aquí el buzón compartido se gana su sitio. Usado en copia, da al suplente el historial y al cliente una dirección de respaldo, mientras la cuestión de quién decide sigue resuelta. Pida que cualquier cambio de responsable se le comunique por escrito y, si es posible, con un periodo de traspaso. Un proveedor que lo ha pensado contesta enseguida, porque el mecanismo ya existe.
Dos relojes: el tiempo hasta la respuesta y el tiempo hasta la decisión
Las promesas de servicio describen a menudo el primer reloj: cuánto se tarda en acusar recibo de un mensaje. Un buzón con varios lectores sale bien parado en esa medida. El calendario del cliente depende del segundo reloj: cuánto pasa hasta que la pregunta queda realmente resuelta. Un proyecto puede acumular respuestas rápidas y amables durante quince días y no moverse.
El GOV.UK Service Standard da el motivo en su punto sobre los equipos multidisciplinares: es importante que las personas que participan en la toma de decisiones formen parte del equipo, para que rindan cuentas ante él y el equipo en su conjunto pueda responder con rapidez a lo que aprende. Cuando quien decide está fuera de la conversación, cada respuesta hace un viaje de ida y vuelta. Cuando quien decide es la persona a la que usted escribe, no.
Acuerde ambos relojes por escrito. Solo como ilustración: un día hábil para acusar recibo, tres para decidir una cuestión que necesita la opinión de otros y un número de teléfono para cualquier cosa que bloquee un lanzamiento. Sus cifras serán otras. Lo que no debería cambiar es que el horario, la zona horaria, el canal urgente y la vía de escalado se conozcan antes del primer plazo y no durante él.
Preguntas que revelan cómo está organizado el trabajo antes de firmar
Empiece por la primera pregunta clave del Playbook, con sus propias palabras: ¿quién es el product owner de nuestro proyecto? Lo que busca es un nombre y una función, no «el equipo». Después pida hablar con esa persona antes de firmar el contrato. Si el responsable aparece solo después de la venta, usted ha conocido el proceso comercial y no el proyecto.
Siga con otras cuatro. ¿Qué puede decidir esta persona sin consultar a nadie? ¿Quién la sustituye cuando no está, y puedo conocerlo? ¿Con qué rapidez debo esperar una decisión, que no es lo mismo que una respuesta? ¿Qué ocurre si el responsable deja la empresa durante el proyecto? Las respuestas claras llevan unos minutos. Las vagas también son información.
Observe cómo se comporta el candidato en esa conversación. Un verdadero responsable único del proyecto pregunta por sus objetivos antes de describir un proceso, rechaza o aplaza al menos una petición explicando el motivo y es concreto sobre lo que queda fuera de su control. Luego busque los mismos hechos sobre el papel: el responsable y el suplente nombrados en el contrato o en el acta de arranque, y una línea sobre cómo se gestiona un cambio de responsable.
El cliente también necesita un solo nombre, y el buzón conserva su función
La regla vale en los dos sentidos. Un proveedor con un único responsable se atasca igualmente si el cliente contesta por comité, con tres compañeros que envían comentarios contradictorios. La frase de la Guía de Scrum se aplica en espejo: el Product Owner puede representar las necesidades de muchos interesados y sigue siendo una sola persona. Designe a quien decide por su parte y dígale al proveedor quién es.
Nada de esto jubila la dirección compartida. Las facturas, las solicitudes de acceso, las actualizaciones rutinarias de contenido y las averías fuera de horario se atienden mejor con una cola que vigilan varias personas, porque ahí la rapidez y la cobertura pesan más que el criterio. El error es hacer pasar las decisiones por la cola o tratar al responsable como un servicio de asistencia.
Un buen acuerdo tiene, por tanto, dos partes, y el cliente puede pedir las dos: un canal que nunca pierde un mensaje y una persona que no puede decir que la decisión no era suya. Si una oferta solo le da lo primero, está comprando respuestas. Si le da ambas cosas, con los límites de autoridad por escrito, sabe quién responderá del resultado el día en que algo salga mal.
Lista práctica
- Pida el nombre y la función de la persona que responde de su proyecto y hable con ella antes de firmar.
- Haga que el proveedor ponga por escrito qué puede decidir sola esa persona sobre prioridades, alcance y aceptación, y quién decide más allá.
- Consiga el nombre de un suplente y confirme dónde se registran las decisiones y los accesos, para que una ausencia no pare el trabajo.
- Acuerde por escrito dos plazos, uno para acusar recibo y otro para llegar a una decisión, además de un canal urgente.
- Designe a una sola persona que decida por su parte y envíe los comentarios consolidados únicamente a través de ella.
Preguntas frecuentes
¿Es lo mismo un interlocutor único que un responsable del proyecto?
No necesariamente. Un interlocutor recibe y transmite mensajes; un responsable tiene autoridad para decidir y rinde cuentas del resultado. La diferencia se ve en la primera pregunta difícil. Si su contacto tiene que llevar a otra persona cada petición sobre prioridades, alcance o aceptación, usted tiene un intermediario, y quien decide de verdad es alguien a quien no conoce.
¿Qué debe poder decidir un jefe de proyecto sin aprobación?
Como mínimo, el orden del trabajo, si una petición entra en el alcance acordado, si un entregable se acepta y cómo equilibrar fecha, coste y calidad dentro del presupuesto y el plazo pactados. Las decisiones que superen esos límites pueden corresponder a un superior con nombre. Lo importante es que tanto los límites como ese segundo nombre consten por escrito antes de empezar.
¿Qué pasa con mi proyecto si el especialista designado se marcha?
Con preparación, muy poco. Pida de antemano un suplente con nombre que siga el trabajo, un registro de decisiones que usted pueda leer y cuentas y archivos a nombre de la empresa o de usted, no de un individuo. Pida también aviso por escrito de cualquier cambio de responsable y, cuando sea posible, un periodo de traspaso en el que ambas personas estén disponibles.
¿Un buzón de proyecto compartido es siempre una mala señal?
No. Una dirección compartida es la herramienta adecuada para facturas, solicitudes de acceso, actualizaciones rutinarias y averías urgentes fuera de horario, donde la cobertura importa más que el criterio. Solo se convierte en señal de alarma cuando es la única vía para preguntas que requieren una decisión y nadie sabe decirle qué persona la tomará.
¿Cómo compruebo la responsabilidad antes de firmar un contrato?
Pregunte quién responderá del resultado e insista en hablar con esa persona, no solo con el equipo comercial. Plantee la pregunta que sugiere el Digital Services Playbook de Estados Unidos: ¿qué necesitaría esta persona para añadir o eliminar una funcionalidad? Después verifique que el contrato o el acta de arranque nombran al responsable, al suplente y el procedimiento para sustituir a cualquiera de los dos.