Saltar al contenido principal

SaaS · Ingeniería · En evolución · CTO + Arquitectura · 23 julio 2026

Un asistente que lleva la petición de Slack a producción

De una idea escrita en Slack a la funcionalidad desplegada: el asistente crea el ticket en Jira, la documentación en Confluence, desarrolla y despliega.

Arquitectura

Petición en Slack Ticket Jira + doc en Confluence Desarrollo con agentes Deploy a producción

El problema: las peticiones de desarrollo se pierden entre Slack y la memoria de alguien

En una empresa de software real, las peticiones no llegan como tickets limpios: llegan como mensajes en Slack. "¿Podemos hacer que…?", un audio, una captura. Y ahí empieza el desorden: alguien lo tiene que convertir en ticket, alguien lo tiene que documentar, alguien lo tiene que desarrollar y alguien lo tiene que desplegar — y cada salto pierde contexto.

El resultado típico: features que viven solo en la cabeza de quien las pidió, tickets sin documentación, y desarrollos que nadie sabe muy bien por qué se hicieron.

La decisión: un asistente que sea dueño del hilo, de la idea al deploy

En vez de sumar pasos manuales, montar un asistente que acompañe la petición de punta a punta: que la recoja en Slack, la formalice en Jira, la documente en Confluence como documentación de producto, ayude a desarrollarla y la lleve hasta el despliegue — dejando rastro en cada paso. La persona decide y revisa; el asistente hace el trabajo de coser el flujo.

Qué construí: el ciclo completo, cosido

  • Entrada por Slack: la petición se recoge en el canal donde de verdad ocurre, con su contexto (texto, audios transcritos, capturas leídas).
  • Ticket en Jira creado con el método y las convenciones de la empresa, no un ticket genérico.
  • Documentación de producto en Confluence, para que la funcionalidad quede explicada, no solo hecha.
  • Desarrollo asistido por agentes: parte del código lo escriben, corrigen y prueban agentes, con la persona validando.
  • Despliegue a producción vía CI/CD, con verificación — cerrando el círculo desde "lo pidió alguien en un canal" hasta "está desplegado y documentado".

Resultado: de una frase en un canal a una funcionalidad viva y explicada

  • El ciclo petición → Jira + Confluence → desarrollo → deploy deja de depender de que cada persona recuerde su parte.
  • Cada desarrollo nace documentado: ticket + doc de producto, sin un paso manual extra de "acuérdate de escribirlo".
  • El conocimiento deja de vivir en la cabeza de quien pidió la feature y pasa a estar donde cualquiera puede consultarlo.

Lección: el valor no está en el código, está en coser el flujo

Automatizar "escribir código" es la parte fácil y la menos importante. Lo que de verdad cambia el ritmo de una empresa es coser el flujo completo — recogida, formalización, documentación, desarrollo, despliegue — para que ninguna petición se pierda entre dos personas. El asistente no sustituye a nadie: elimina las costuras.

Casos relacionados

← Volver a casos