Muchas empresas de desarrollo de software optaron por adoptar metodologías de desarrollo ágil, entre ellas una de las más populares, SCRUM. El equipo en SCRUM está conformado por el scrum master (encargado de evangelizar a la empresa sobre scrum y sus ceremonias), el equipo de desarrollo y el product owner. El product owner en esta metodología es el encargado de recopilar los requerimientos del cliente, priorizarlos de tal manera que generen la mayor cantidad de valor y bajarlos a los desarrolladores de tal forma que estos sepan el porqué se están haciendo, dejando explícitamente los criterios de aceptación de cada tarea. Así, el PO (product owner, de ahora en adelante llamado así en el artículo) no es solo un intermediario entre el cliente y los desarrolladores: es quien realmente guía hacia dónde está yendo el producto.
Puede que muchas empresas no tengan clientes externos, pero el rol de PO siempre es importante, y en algunas ocasiones recae en el CTO, como en el caso de las start-ups: llegan los requerimientos, son priorizados, refinados, trabajados y entregados. Los desarrolladores, si están bien informados del porqué de cada decisión, se van involucrando en la lógica de negocio —no necesariamente para tomar las decisiones, sino para entenderlas—. Cuando estás informado del roadmap puede que estés de acuerdo o no, pero te involucra, y aunque sientas que las decisiones no son correctas, te importa que el producto que estás ayudando a construir tenga éxito.
Creo que este es uno de los errores que cometen algunas empresas: a los desarrolladores simplemente se les dice “tenemos la siguiente historia de usuario, la vamos a trabajar y la entregaremos en el sprint X”, y así, sin más, sin explicar el porqué. De esta forma, el desarrollador se convierte únicamente en alguien que implementa lo que le piden. Y esto no solo afecta la motivación o el sentido de pertenencia: también puede afectar las decisiones técnicas.
Si no sé hacia dónde va el producto, ¿cómo sé si la solución que estoy construyendo tendrá que crecer? ¿Cómo sé si vale la pena hacer algo más flexible o si, por el contrario, una solución sencilla es suficiente?
Aquí volvemos a caer en la discusión de siempre: ¿hacer sobreingeniería o no? He ahí la cuestión. Las metodologías ágiles también nos dicen que todo está en constante evolución, pero nada de eso es excusa para tener una deuda técnica gigante si no se me explica hacia dónde va el desarrollo.
En plena revolución de la inteligencia artificial, cada vez vemos más herramientas capaces de asumir tareas que antes estaban distribuidas entre diferentes personas del equipo de desarrollo. Hace poco me estuve documentando sobre cómo utilizar IA en mi trabajo y encontré BMAD, una metodología en la que diferentes agentes representan roles tradicionales dentro del ciclo de desarrollo. Un agente puede asumir el papel de arquitecto, otro el de product owner, otro el de desarrollador, otro el de QA y otro el de DevOps.
De repente, algo que antes imaginábamos como un equipo compuesto por varias personas puede ser orquestado por una sola persona utilizando diferentes agentes especializados. El arquitecto diseña la solución, el PO define y prioriza las tareas, el desarrollador implementa, QA valida y DevOps hace el deploy. Todo puede suceder mucho más rápido y, dependiendo del caso, con diferentes niveles de supervisión.
Y aquí es donde la cosa empieza a ponerse interesante.
Si la IA puede ayudarnos a cubrir cada vez más partes del ciclo de desarrollo, ¿qué pasa con la separación tradicional entre estos roles?
“Lo más difícil de desarrollar software con IA para negocios reales no es pedirle que cree una API, diseñe o haga frontend + backend + base de datos. Eso la IA ya lo puede generar. Lo difícil es entender al cliente: no siempre sabe lo que quiere exactamente, su problema suele ser más complejo de lo que cree y, si por él fuera, te pediría una interfaz con 50 botones y una tabla enorme al estilo Excel, sin mencionar que no tiene ninguna consideración de cómo escalar un sistema real. Ahí está el trabajo real del desarrollo actual: ser el intermediario entre la IA (la que genera el código) y el cliente (el que explica el problema).”
Al leerlo pensé inicialmente: “Oye, este tipo está diciendo que los desarrolladores deben ser PO”.
Creo que la IA sí empieza a cambiar algo: la distancia que existe entre el PO y el desarrollador. Hasta ahora, un PO podía tener conocimientos muy profundos del negocio sin saber programar, y un desarrollador podía tener conocimientos técnicos muy profundos sin entender completamente el negocio. Eso funcionaba porque cada uno tenía un rol definido y existía una frontera relativamente clara entre ambos.
Pero ¿qué pasa cuando la IA empieza a reducir el conocimiento técnico necesario para construir software?
Y este era el punto al que quería llegar: la convergencia de estos dos roles. Con el tiempo, los PO se volverán desarrolladores o los desarrolladores se volverán PO. Un PO con buen contexto, utilizando la IA de forma correcta, puede crear software, así como el desarrollador puede complementarse con un agente. El PO podrá tener a su disposición un agente arquitecto que lo guíe en escoger el stack tecnológico correcto; de igual forma, cuando los desarrolladores se involucren más en la lógica de negocio, en “entender” al cliente, podrán crear mejores productos. Esta brecha no será cerrada por ninguno de los dos roles: lo decidirán las empresas. ¿Me quedo con un PO que programe o con un programador que gestione proyectos? Ambas soluciones para mí son válidas, y dependerá de las skills de cada persona qué tan bien encaje en la reestructuración de las empresas y tal vez, sin darnos cuenta, ahí es donde empiece a aparecer el próximo rol.
