Cómo ejecutamos un proyecto de software de principio a fin (y dónde se paran antes de tiempo casi todos los partners)

Casi todos los partners de software se paran en uno de dos sitios: en el match o en la demo. En el match se paran las empresas de staffing: ingeniero colocado, factura enviada. En la demo se paran las agencias: funcionalidad enseñada, sprint cerrado. Ninguno de los dos es el punto en el que tu producto empieza a ganar dinero, y ninguno de los dos es donde vive el riesgo.

Me dedico a dirigir proyectos de ingeniería, y he estado en el lado del cliente en suficientes de ellos como para saber dónde se tuercen. No se tuercen en el código. Se tuercen en las costuras: entre el discovery que nadie escribió y la arquitectura que nadie eligió; entre el sprint que se cerró y el sistema en producción que nadie tiene a su cargo. Así que cuando un founder me pregunta «¿cómo ejecutáis un proyecto de principio a fin?», la respuesta honesta es una lista de costuras y de lo que ponemos en cada una.

Esta es esa lista. Cuatro fases, la cadencia dentro de cada una, los roles y las cifras que firmamos. El proceso es el mismo tanto si el encargo es un MVP a precio cerrado, un squad integrado o un solo ingeniero senior dentro de tu equipo: la cadencia se reduce, las costuras no desaparecen.

El discovery dura una semana y termina con un documento que puedes rebatir

La primera semana no es un taller con pósits. Es un alcance por escrito: qué tiene que hacer el producto en el lanzamiento, qué no tiene que hacer todavía, qué sistemas existentes toca y qué significa «hecho» expresado en una cifra que puedas comprobar. Lo redactamos como un RFC técnico —la misma forma que usamos internamente, y la misma que he defendido que debería usar cualquier equipo—, porque un documento con el que puedes discrepar línea a línea vale más que diez presentaciones con las que asientes.

Del discovery salen dos cosas que la mayoría de partners se saltan. La primera es una lista de riesgos ordenada por lo que cuesta equivocarse: la API de terceros sin entorno de pruebas, el modelo de datos que costará migrar, el requisito de cumplimiento que cambia la decisión de hosting. La segunda es un criterio de cancelación: la condición bajo la cual te aconsejaríamos no construir esto, o no construirlo con nosotros. Prefiero perder un proyecto en la primera semana a entregar en la semana doce algo que nunca deberías haber empezado.

La arquitectura se decide por escrito antes del primer sprint, y cada decisión lleva fecha

Entre el discovery y el desarrollo hay un paso que suele comprimirse en un «ya lo iremos viendo», y en esa compresión nace la deuda técnica. Nosotros no arrancamos sprints hasta que la arquitectura está escrita en forma de registros de decisión: el stack, el destino de despliegue, quién es dueño de los datos, el modelo de autenticación, qué es un monolito y qué no lo es. Cada registro lleva fecha, las alternativas que se valoraron y el motivo por el que se descartaron.

La regla que aplico es la misma que expuse en la pieza sobre monolito frente a microservicios: la arquitectura que saca un MVP adelante es la que puedes operar con el equipo que tienes de verdad, no la que mejor queda en un diagrama. Para un producto que va de cero a sus primeros diez mil usuarios, eso es casi siempre un monolito modular con un pipeline de despliegue limpio, observabilidad desde el primer día y un modelo de datos que no tendrás que arrancar de cuajo. Las partes exóticas esperan a que una cifra diga que hacen falta.

Este paso decide también la forma del equipo. Construir un producto exige un squad: un Tech Lead que responde del resultado, dos ingenieros de backend, uno de frontend, QA y un ingeniero de IA cuando el producto lo necesita. Un alcance más estrecho recibe un equipo más pequeño. Pero el Tech Lead no se negocia, porque alguien tiene que responder de que la arquitectura sobreviva al contacto con los sprints.

Los sprints siguen una cadencia que reconocerías, con una primera PR mergeada antes de acabar la semana uno

El sprint cero es el arranque: backlog refinado con tu product owner, el mapa de arquitectura en la pared, la definition-of-done cerrada. A partir de ahí el ritmo es aburrido a propósito, porque un ritmo aburrido es lo que permite predecir la entrega:

• Sincronización diaria en tu Slack, en tu standup. El squad no es un proveedor al otro lado de una cola de tickets; está en la sala.
• Primera pull request mergeada antes de acabar la primera semana. No una rama de prototipo: una PR a tu main, a través de tu CI. Prueba a la vez el pipeline, los accesos y el acuerdo de trabajo.
• Demo cada dos semanas, en vivo, sin diapositivas. Software funcionando o plan de rollback. Si la demo no puede ejecutarse, el sprint no se ha cerrado.
• Retro con un scorecard contra el KPI que acordamos al definir el alcance. No la velocidad: la cifra que el producto tiene que mover.

Debajo de las ceremonias hay una capa de seguimiento que considero el producto que vendemos en realidad. Un delivery manager habla con el cliente y con los ingenieros —cada semana por defecto, cada día cuando la fase lo pide—, porque los problemas que matan un proyecto aparecen primero como un tono de voz en una reunión individual, no como un ticket en rojo. Es la cara operativa de lo que he llamado el modelo forward-deployed aplicado al talento de ingeniería: el staffing termina en el match, el despliegue termina en la entrega, y en la distancia entre ambos es donde nos ganamos los honorarios.

Dónde mueren los proyectos: en la costura entre «la demo funciona» y «producción es tuya»

Voy a conceder la objeción más fuerte, porque es la que yo mismo plantearía: hay muchas agencias que ejecutan buenos sprints y aun así te dejan con un producto que no puedes operar. La demo funciona; el turno de guardia no existe; el despliegue vive en el portátil de un ingeniero; la documentación es un README del segundo mes. Este fallo es tan frecuente que «la agencia lo construyó y ahora nadie es dueño de ello» es una de las cinco señales que enumero cuando un founder me pregunta si necesita un CTO fraccional.

Por eso la entrega no es la última semana. Es una fase con sus propios entregables, y la empezamos a mitad del proyecto, no al final:

1. Producción antes de «terminado». El producto se despliega en infraestructura real, bajo tus cuentas, con monitorización y alertas, semanas antes de que aterrice la última funcionalidad. El último sprint debería estar enviando código a un sistema que ya funciona.
2. Documentación que sobrevive a las personas. La arquitectura, los registros de decisión, la guía de despliegue y el runbook de las tres cosas con más probabilidades de despertar a alguien a las tres de la madrugada.
3. Cuentas, claves y repositorios a tu nombre. Y después un borrado seguro de cada copia de tu contenido corporativo en nuestro lado, confirmado por escrito.
4. Una ventana de transferencia de conocimiento dimensionada según el equipo que hereda el sistema: media jornada si lo recibe un equipo senior, dos semanas de sesiones en pareja si es tu primera contratación.

Lo que esto nos cuesta es margen al final del proyecto, justo cuando la tentación es dejarse llevar. Lo que te compra es un sistema que es tuyo el día en que se detiene la factura.

Las cifras que firmamos, para que puedas exigírnoslas

Una descripción del proceso vale lo que valen las condiciones que la respaldan. Las nuestras, por escrito:

• Facturación mensual, preaviso operativo de 30 días. Sin permanencia de doce meses. Un encargo que ha dejado de aportar valor tiene que poder terminar.
• Alcance fijo y precio cerrado para un MVP: ocho semanas. Discovery, sprints de dos semanas, lanzamiento y entrega. Si el alcance se mueve, lo redefinimos por escrito; el precio no se desplaza en silencio.
• Garantía de sustitución de 30 días, sustituto presentado en 7, sin coste añadido. Cada ingeniero que colocamos está en nuestra nómina, así que el coste de un match fallido lo asumimos nosotros.
• Un único responsable en nuestro lado para todo el recorrido —el delivery manager—, de modo que «¿a quién llamo?» tiene una sola respuesta.

Y la cifra que más me importa, porque es la única que un cliente no puede fingir: las renovaciones. Nuestro encargo más largo en curso, un squad integrado de tres ingenieros y un delivery manager que construye el núcleo de un protocolo y sus SDKs verificadores, arrancó con un presupuesto de 200.000 € y se renovó por 400.000 € más: cada entregable en fecha, cero bugs. Una renovación es una evaluación con precio.

Lo que le preguntaría a cualquier partner antes de firmar, nosotros incluidos

Si estás eligiendo un partner de desarrollo de software, recorre esta lista. Las respuestas te dicen dónde se van a parar.

1. «Enséñame el documento de discovery de vuestro último proyecto.» Si es una presentación, se paran en la venta.
2. «¿Quién es dueño de la decisión de arquitectura y dónde está escrita?» Si la respuesta es «el desarrollador senior», se paran en el sprint.
3. «¿Cuándo llega la primera PR mergeada a mi repositorio?» Si es «después de la fase de prototipo», el pipeline no está probado.
4. «¿Qué pasa en una demo que falla?» Si el sprint se cierra igualmente, la cadencia es teatro.
5. «¿Quién habla con los ingenieros, no solo conmigo?» Si nadie, los problemas te llegan tarde.
6. «¿Qué incluye la entrega, por escrito: cuentas, documentación, borrado?» Si es «os enviamos el código», se paran en la demo.
7. «¿Cuáles son las condiciones de sustitución y de salida?» Si tienes que preguntarlo dos veces, ya tienes la respuesta.

El partner que quieres es el que se para el último: después de que el sistema funcione a tu nombre, después de que la documentación la haya leído alguien que no estaba en la sala, después de que su copia de tus datos haya desaparecido. Todo lo anterior es un match y una demo, y un match y una demo son los dos puntos en los que se abandonan en silencio casi todos los proyectos.

Si quieres la versión de este proceso ajustada a tu producto, la definimos en una llamada de 30 minutos, y empezamos por escribir el criterio de cancelación.