Idea

Una decisión de producto, una decisión técnica y una decisión de experiencia conservan cada una su responsable aunque todo el mundo contribuya

Info

Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.

Idea principal

Cuando un Product Manager sube una pull request y un desarrollador entrevista a clientes, la conclusión tentadora es que las responsabilidades se disuelven junto con los perímetros. Ocurre lo contrario: la difuminación de los roles hace más necesaria la designación de responsables, no menos.

Una decisión de producto sigue siendo una decisión de producto — visión, posicionamiento, coherencia, arbitrajes, lectura del mercado, señal del cliente — y le corresponde a producto. Una decisión técnica sigue siendo una decisión técnica — seguridad, rendimiento, capacidad de aguantar la carga, arquitectura, mantenibilidad — y le corresponde a ingeniería. Una decisión de experiencia sigue siendo una decisión de experiencia — sistema de diseño, coherencia de uso, accesibilidad, nivel de exigencia — y le corresponde a diseño o al front.

La organización que funciona no es, por tanto, aquella donde cada uno hace de todo por su cuenta: es aquella donde cualquiera puede intervenir más allá de su dominio inicial porque hay responsables que han fijado los estándares, las barreras y los límites. Es la claridad de esas tres líneas la que autoriza a salirse de ellas, y no al revés.

Por qué es importante

Da la vuelta a una intuición muy extendida sobre los equipos autónomos: las contribuciones no se amplían borrando las fronteras, se amplían nombrando quién responde de qué.

Y ofrece un orden de operaciones a un equipo que quiere abrirse: designar primero a los responsables, abrir después los perímetros.

Matices y límites

Los tres dominios no se reparten limpiamente. Una decisión de arquitectura compromete el coste de la evolución futura del producto, una decisión de experiencia impone restricciones técnicas: el responsable decide dentro de su dominio, no decide en solitario lo que esa decisión produce en otra parte.

Y un responsable puede convertirse en un cuello de botella: si todo tiene que pasar por él, la función de garantía se transforma en autorización previa, y la apertura que debía permitir se cierra de nuevo.

Preguntas abiertas

  • ¿Cómo fija un responsable un estándar lo bastante explícito para que las contribuciones se ajusten a él sin tener que consultarle cada vez?