Cómo trabajamos · un proyecto, de principio a fin
Demostrarlo.
Endurecerlo.
Mantenerlo vivo.
Todos los proyectos siguen el mismo camino: demostrados rápido, endurecidos por un proceso automatizado y después mantenidos vivos toda su vida. La secuencia no cambia, y ese es justo el punto. Desplázate para recorrerla una vez.
Estación 01 · La materia prima
La administración es la materia prima.
Los formularios, las aprobaciones, las conciliaciones, los traspasos de once días, la hoja de cálculo que alguien rehace cada mes. En unos quince países, ese trabajo lo hacen personas contratadas para otra cosa.
No tiene glamour, es enorme y es casi enteramente automatizable. Esa es la materia prima con la que trabajamos.
Estación 02 · Parte 1 — PoC Services
Demostrarlo, rápido.
Ingenieros con soltura en negocio se integran en una empresa, averiguan cómo funciona de verdad y construyen algo que funciona con agentes de IA. Demuestran —o desmienten— el valor, lo llevan hasta MVP y lo entregan.
- Perfil
- Forward Deployed Engineers
- Reloj
- Días para algo sencillo, semanas para algo complejo
- Cuándo termina
- Cuando el valor está demostrado y el paquete de entrega está entregado
Estación 03 · El proceso de industrialización
Todos los proyectos pasan por él.
Sin excepciones.
Un agente lo planifica y después un flujo automatizado añade lo que un prototipo no tiene: escala multiusuario, autenticación, ejecución asíncrona, APIs, webhooks y pruebas. Las personas solo intervienen cuando el agente las pide.
Un casi-MVP con el valor demostrado
Un sistema desplegado, probado, protegido y multiusuario
Estación 04 · Parte 2 — El Tech Lab
Y entonces alguien se queda con ello.
Un Product Owner y un desarrollador recogen el producto endurecido y lo hacen suyo durante toda su vida: recogen las necesidades del negocio, siguen construyendo, lo mantienen y lo operan.
- Perfil
- Product Owner · desarrolladores · DevOps
- Reloj
- Continuo, durante toda la vida del producto
- Cuándo termina
- Nunca: este es el equipo que lo mantiene vivo
Estación 05 · El bucle se cierra
Lo que enseña operarlo
se convierte en la siguiente entrada.
Has dado una vuelta completa. Eso es la empresa entera: un camino agéntico y repetible de la idea al producto en marcha, y vuelta a empezar.
Todo el recorrido, en detalle →Un equipo de PoC sin equipo de producto es un cementerio de prototipos: demos que impresionan, nada en producción. Un equipo de producto sin equipo de PoC construye cosas que nadie ha pedido.
Casi todos los programas de automatización tienen exactamente una de las dos mitades, y culpan a las personas en lugar de a la estructura. Este está montado como un bucle para que no pueda pasar.
Por qué construimos más rápido
Toda implementación empieza con un agente que la planifica, trabaja la arquitectura a fondo y revisa lo que sale. Los ingenieros dirigen ese trabajo y deciden qué se entrega. La ganancia no es que se escriba más código: es que las partes lentas de construir —leer, comprobar y dar una segunda opinión honesta— dejan de ser aquello que hace esperar a todo lo demás.
La revisión la hace algo que no escribió el código y que no recuerda haber pretendido nada con él. Un autor que revisa su propio trabajo, humano o no, confirma de forma fiable lo que quiso hacer y no lo que hizo en realidad.
Los agentes tampoco se van a casa. Un fallo a las tres de la mañana se detecta cuando ocurre, se rastrea hasta lo que se rompió de verdad y se responde con una corrección propuesta esperando cuando llega el equipo. No se despierta a nadie, y nada se queda sin tocar hasta el lunes.
Las personas son mejores en criterio, en contexto y en saber si algo merece la pena construirse. No son mejores estando disponibles de forma continua, y pedírselo es como se desgastan los equipos. Así que usamos personas para lo primero y agentes para lo segundo.
Nada de lo que produce un agente llega a producción sin que una persona lo apruebe. Esa restricción es lo que hace que todo lo demás se pueda decir con tranquilidad.
Todo el recorrido
El paseo de arriba es una vuelta completa de esto. Aquí está paso a paso, que es lo que quieres si estás decidiendo si encargarnos algo.
Parte 1 · PoC Services — demostrarlo
- 0 Entrada
El problema, el responsable, el criterio de éxito, lo que cuesta hoy y qué datos toca; y después puntuado en un nivel de tamaño por alguien que no responde del resultado. Esa independencia es lo que hace honesta la promesa.
- 1 Entender el proceso
Cómo funciona hoy el trabajo de verdad, observado en lugar de descrito. Casi todo el valor se encuentra aquí, no en el desarrollo.
- 2 Comprobar qué existe ya
Reutilizar antes que reinventar, aplicado antes de escribir una línea.
- 3 Escribir la arquitectura funcional
Rigor de especificación antes de construir. Qué hace, para quién, y qué significa terminado.
- 4 Desarrollo agéntico
Los agentes construyen la mayor parte. El ingeniero dirige, revisa y decide.
- 5 El bucle con los stakeholders
Tres prototipos cada vez más reales, enseñados a quienes hacen el trabajo mientras todavía es barato equivocarse. Cada demostración empieza diciendo lo que aún no es.
- 6 Casi-MVP y el paquete de entrega
Valor demostrado o desmentido, más todo lo que el siguiente equipo necesita. Casi-MVP significa usable, no producción: el proceso de industrialización va en medio.
El proceso de industrialización — endurecerlo
- I Entrada al proceso
Nada se lo salta. Se niega a arrancar sin un código que compile desde un clon limpio, con sus etiquetas rellenas y una persona con nombre que responda por él.
- II Se planifica
Qué significa industrializar esta cosa se escribe antes de cambiar nada. Ese plan es del que trabaja todo lo demás, y lo que lee una persona cuando hace falta una decisión.
- III Se endurece
Un prototipo se convierte en software de producción. Este es el paso que cambia las respuestas de seguridad e infraestructura, y es el mismo paso para todos los proyectos.
- IV Personas, solo cuando se piden
El ingeniero que lo construyó, con el Head of Engineering; no un comité de revisión permanente. Su segundo trabajo: asegurarse de que quien lo construyó entiende lo que construyó. Una entrega escrita por alguien que no lo entiende no es una entrega.
- V Pruebas, seguridad, despliegue
Un listón del 100 % superado. La máquina decide cuándo está hecho; una persona decide cuándo sale.
Parte 2 · Tech Lab — mantenerlo vivo
- 7 Entrega a una pareja
Un Product Owner y un desarrollador asumen algo que no construyeron, lo que solo funciona porque todos los productos llegan con la misma forma. Lo aceptan probándolo.
- 8 Hacerlo suyo, construirlo, operarlo
Continuo. El PO sostiene la relación con el negocio, el backlog y la aceptación; el desarrollador sostiene el desarrollo, la arquitectura y la release. Un producto que deja de evolucionar deja de usarse.
- 9 Graduación, si alguna vez se va
Algunos productos se estabilizan y dejan de necesitar velocidad de desarrollo. Salir es un camino con nombre, acordado caso por caso, nunca una deriva. Una condición de éxito, no un fracaso.
Dos reglas que marcan el ritmo
- El reloj es el proceso, no el calendario
- Días para algo sencillo, un trimestre para algo genuinamente difícil, fijado por la puntuación de complejidad de la entrada. Un plazo corto sobre un proceso sin examinar no hace el trabajo más rápido; hace que la primera conversación honesta llegue más tarde. Y un no honesto es un resultado entregado: si el valor no está, paramos y lo escribimos.
- Cada demostración empieza diciendo lo que no es
- Qué hace, y qué no hace explícitamente en seguridad, infraestructura y datos, dicho antes de la demo y no después. A los diez minutos de software funcionando, una advertencia suena a marcha atrás; dicha primero suena a alcance. Esto importa sobre todo en casi-MVP, que parece mucho más terminado de lo que es seguro.
Qué contiene realmente una entrega
El paquete de entrega no es un paquete. Es el repositorio, más las cosas que un repositorio no puede contener. Casi todo se escribe durante la etapa que lo produce, no se monta al final.
- El repositorio
- No una carpeta de documentos: el repositorio en sí. Puerta de entrada, índice de documentación y orden de lectura, la arquitectura, y un registro de decisiones que anota qué se eligió, por qué, y qué haría revisarlo.
- Cuatro documentos de producto
- El mapa del proceso tal como se hace el trabajo de verdad. La arquitectura funcional. El caso de beneficio con su línea de base medida. El mapa de stakeholders: a quién le importa qué, y a quién llamar cuando se rompe.
- La declaración de profundidad técnica
- Qué se revisó y quién lo revisó, o sencillamente que no se revisó nada. Dónde quedó superficial el diseño, y los huecos que quien lo construyó ya conoce.
- El manual de operación
- Despliegue y rollback, ejecutados en lugar de descritos. Cada alerta y qué significa. Las tres cosas con más probabilidad de romperse. El registro del simulacro de restauración.
- La hoja de ruta
- Lo que deliberadamente no se construyó, y por qué.
- Flujos de incorporación
- Un camino de primera vez dentro del producto, un cómo-se-hace de una página para la tarea más común, y el primer grupo de usuarios con nombre, incorporado de verdad antes de la entrega.
- Seis campos de registro
- Responsables que corresponden a personas reales. Nivel de tamaño vinculante, clasificación de datos, nivel de riesgo, desviaciones declaradas; y una condición de retirada, nunca en blanco.
- Dos reuniones acotadas
- Un recorrido grabado de noventa minutos y una presentación a los stakeholders. Y ahí termina.
El paquete se acepta probándolo
Un arranque en frío: el desarrollador que recibe, solo, desde un clon, sin nadie a quien preguntar, lo pone en marcha y entrega un cambio trivial. Hasta que eso pasa, quien lo construyó no ha salido. Después responde defectos del paquete y nunca preguntas de producto: una pregunta que solo puede responder quien lo construyó es el defecto. Y entonces se va del todo.
La asignación sigue una puntuación, no una opinión
El tamaño es una puntuación compuesta sobre tres ejes —superficie (hasta dónde llega el radio de impacto), carga de operación (lo que cuesta mantenerlo) y complejidad de desarrollo—, no una negociación. La complejidad es deliberadamente la de menor peso: donde los agentes construyen la mayor parte, el esfuerzo de desarrollo es el insumo barato y la propiedad es el escaso.
El nivel fijado en la entrada es un pronóstico. Se vuelve a puntuar en la entrega, por gente que ha construido la cosa y ha visto a usuarios reales tocarla, y ese es el que vincula. Una pareja hereda un nivel, no una opinión.
¿Algo en tu empresa
que no debería ser manual?
Cuéntanos cómo funciona hoy el trabajo de verdad. Si hay algo ahí, lo sabrás en días y no en trimestres.