Desde hace un tiempo estoy trabajando un equipo de producto de más de 20 personas y estamos organizados en una estructura que es nueva para mi pero que al mismo tiempo me parece viene resultando efectiva. La siguiente figura resume esta estructura.

Si bien todo el equipo de producto son más de 20 personas, en el día a día estamos divididos en 4 equipos: 3 feature teams y 1 equipo de toolsmiths (este nombre lo tomé del enfoque FDD, pero no es el nombre real del equipo)

Los 3 feature teams trabajan en funcionalidades del producto y están en el día a día con gente de negocio.

El equipo de toolsmiths es donde yo trabajo. Actuamos como proveedores/facilitadores de los features teams y nos encargamos de mantener/optimizar la infraestructura de desarrollo: repositorios, build server, ambientes, etc. Incluso en ocasiones agregamos código al producto, pero obviamente relacionado a cuestiones de soporte/infra como feature flags, health endpoints, etc. Como parte de nuestro trabajo tenemos que interactuar con otros grupos de soporte organizacional que se encargan de infraestructura de base y regulaciones (seguridad, red, etc). En el equipo somos 3 personas con skills mixtos: podemos codear, agregar tests, configurar servers, scriptear infraestructura pero sobre todo podemos hablar con otros grupos y generar concenso. Alguien podría tentarse de decir que somos DevOps, pero no lo vemos así, porque de entrada no creemos que DevOps sea ni un rol ni un área, sino un mindset con un conjunto de prácticas.

No se si este es el mejor enfoque para la estructura de un equipo de producto, pero consideramos que nos viene resultando bien: el negocio está contento, los distintos equipos están contentos, el producto está estable y tenemos la capacidad de ir a producción bajo demanda y de forma altamente automatizada.