Idea principal

Una pantalla de consulta, una exportación, un cuadro de mando, un consultor de datos montado por un equipo de producto se sitúan al lado del producto: consumen API, agregan información y producen una interfaz útil para quien la ha hecho o para su equipo. Lo que rompen al romperse son ellos mismos.

Un módulo, un recorrido o una variación funcional construidos sobre la base de código de la empresa se sitúan en su prolongación. Reutilizan los bloques existentes, el lenguaje de negocio del código, los componentes propios — y se inscriben en el mismo repositorio, con las mismas dependencias y los mismos clientes al final. Lo que rompen al romperse es el producto.

La distinción no es una diferencia de tamaño ni de ambición: es una diferencia de superficie de impacto, y es ella la que debería decidir el régimen de exigencia, no el hecho de que sea un perfil de producto o un desarrollador quien tenga el teclado.

Por qué es importante

Da un criterio operativo allí donde la discusión suele quedarse en el nivel de la persona. "Al lado" o "en la prolongación" se constata mirando dónde aterriza el código y quién depende de él; "suficientemente competente" no se constata.

También dibuja dos trayectorias distintas y no equivalentes: aliviar a los desarrolladores de las pequeñas herramientas internas es un objetivo modesto y alcanzable; permitir que perfiles de producto contribuyan al producto mismo es otro asunto, con otras condiciones.

Matices y límites

La frontera no es estanca. Una herramienta construida al lado que escribe en la base de producción tiene la superficie de impacto de un objeto de la prolongación, sea cual sea su ubicación en el repositorio.

Y la diferencia de riesgo no dice nada de la diferencia de valor: el objeto más útil no siempre es el que toca el producto.

Preguntas abiertas

• ¿Hasta dónde puede una organización dejar que perfiles de producto construyan en la prolongación del producto sin perder el control técnico, la coherencia y la seguridad del conjunto?