Com executem un projecte de software de cap a cap (i on s'aturen abans d'hora gairebé tots els partners)

Gairebé tots els partners de software s'aturen en un de dos llocs: al match o a la demo. Al match s'hi aturen les empreses de staffing: enginyer col·locat, factura enviada. A la demo s'hi aturen les agències: funcionalitat ensenyada, sprint tancat. Cap dels dos és el punt on el teu producte comença a guanyar diners, i cap dels dos és on viu el risc.

Em dedico a dirigir projectes d'enginyeria, i he estat a la banda del client en prou projectes per saber on es torcen. No es torcen al codi. Es torcen a les costures: entre el discovery que ningú no va escriure i l'arquitectura que ningú no va triar; entre l'sprint que es va tancar i el sistema en producció que ningú no té al seu càrrec. Així que quan un founder em pregunta «com executeu un projecte de cap a cap?», la resposta honesta és una llista de costures i del que hi posem a cadascuna.

Aquesta és la llista. Quatre fases, la cadència dins de cadascuna, els rols i les xifres que signem. El procés és el mateix tant si l'encàrrec és un MVP a preu tancat, un squad encastat o un sol enginyer sènior dins del teu equip: la cadència es redueix, les costures no desapareixen.

El discovery dura una setmana i acaba amb un document que pots rebatre

La primera setmana no és un taller amb post-its. És un abast per escrit: què ha de fer el producte al llançament, què no ha de fer encara, quins sistemes existents toca i què vol dir «fet» expressat en una xifra que puguis comprovar. El redactem com un RFC tècnic —la mateixa forma que fem servir internament, i la mateixa que he defensat que hauria de fer servir qualsevol equip—, perquè un document amb què pots discrepar línia a línia val més que deu presentacions a les quals assenteixes.

Del discovery en surten dues coses que la majoria de partners es salten. La primera és una llista de riscos ordenada pel que costa equivocar-se: l'API de tercers sense entorn de proves, el model de dades que costarà migrar, el requisit de compliment que canvia la decisió de hosting. La segona és un criteri de cancel·lació: la condició sota la qual t'aconsellaríem no construir això, o no construir-ho amb nosaltres. M'estimo més perdre un projecte la primera setmana que lliurar la setmana dotze una cosa que mai no hauries d'haver començat.

L'arquitectura es decideix per escrit abans del primer sprint, i cada decisió porta data

Entre el discovery i el desenvolupament hi ha un pas que sol comprimir-se en un «ja ho anirem veient», i en aquesta compressió neix el deute tècnic. Nosaltres no arrenquem sprints fins que l'arquitectura és escrita en forma de registres de decisió: l'stack, el destí de desplegament, qui és propietari de les dades, el model d'autenticació, què és un monòlit i què no ho és. Cada registre porta data, les alternatives que es van valorar i el motiu pel qual es van descartar.

La regla que aplico és la mateixa que vaig exposar a la peça sobre monòlit contra microserveis: l'arquitectura que treu un MVP endavant és la que pots operar amb l'equip que tens de veritat, no la que queda més bé en un diagrama. Per a un producte que va de zero als primers deu mil usuaris, això és gairebé sempre un monòlit modular amb un pipeline de desplegament net, observabilitat des del primer dia i un model de dades que no hauràs d'arrencar de soca-rel. Les parts exòtiques esperen que una xifra digui que fan falta.

Aquest pas decideix també la forma de l'equip. Construir un producte demana un squad: un Tech Lead que respon del resultat, dos enginyers de backend, un de frontend, QA i un enginyer d'IA quan el producte el necessita. Un abast més estret rep un equip més petit. Però el Tech Lead no es negocia, perquè algú ha de respondre que l'arquitectura sobrevisqui al contacte amb els sprints.

Els sprints segueixen una cadència que reconeixeries, amb una primera PR mergejada abans d'acabar la setmana u

L'sprint zero és l'arrencada: backlog refinat amb el teu product owner, el mapa d'arquitectura a la paret, la definition-of-done tancada. A partir d'aquí el ritme és avorrit a propòsit, perquè un ritme avorrit és el que permet predir el lliurament:

• Sincronització diària al teu Slack, al teu standup. El squad no és un proveïdor a l'altra banda d'una cua de tickets; és a la sala.
• Primera pull request mergejada abans d'acabar la primera setmana. No una branca de prototip: una PR al teu main, a través del teu CI. Prova alhora el pipeline, els accessos i l'acord de treball.
• Demo cada dues setmanes, en viu, sense diapositives. Software funcionant o pla de rollback. Si la demo no es pot executar, l'sprint no s'ha tancat.
• Retro amb un scorecard contra el KPI que vam acordar en definir l'abast. No la velocitat: la xifra que el producte ha de moure.

Sota les cerimònies hi ha una capa de seguiment que considero el producte que venem de debò. Un delivery manager parla amb el client i amb els enginyers —cada setmana per defecte, cada dia quan la fase ho demana—, perquè els problemes que maten un projecte apareixen primer com un to de veu en una reunió individual, no com un ticket en vermell. És la cara operativa del que he anomenat el model forward-deployed aplicat al talent d'enginyeria: l'staffing acaba al match, el desplegament acaba al lliurament, i a la distància entre tots dos és on ens guanyem els honoraris.

On moren els projectes: a la costura entre «la demo funciona» i «producció és teva»

Concediré l'objecció més forta, perquè és la que jo mateix plantejaria: hi ha moltes agències que executen bons sprints i tot i així et deixen amb un producte que no pots operar. La demo funciona; el torn de guàrdia no existeix; el desplegament viu al portàtil d'un enginyer; la documentació és un README del segon mes. Aquesta fallada és tan freqüent que «l'agència ho va construir i ara ningú no n'és propietari» és un dels cinc senyals que enumero quan un founder em pregunta si necessita un CTO fraccional.

Per això el lliurament no és l'última setmana. És una fase amb els seus propis lliurables, i la comencem a mig projecte, no al final:

1. Producció abans d'«acabat». El producte es desplega en infraestructura real, sota els teus comptes, amb monitoratge i alertes, setmanes abans que aterri l'última funcionalitat. L'últim sprint hauria d'estar enviant codi a un sistema que ja funciona.
2. Documentació que sobreviu a les persones. L'arquitectura, els registres de decisió, la guia de desplegament i el runbook de les tres coses amb més probabilitats de despertar algú a les tres de la matinada.
3. Comptes, claus i repositoris al teu nom. I després un esborrat segur de cada còpia del teu contingut corporatiu a la nostra banda, confirmat per escrit.
4. Una finestra de transferència de coneixement dimensionada segons l'equip que hereta el sistema: mitja jornada si el rep un equip sènior, dues setmanes de sessions en parella si és la teva primera contractació.

El que això ens costa és marge al final del projecte, just quan la temptació és deixar-se anar. El que et compra és un sistema que és teu el dia que s'atura la factura.

Les xifres que signem, perquè ens les puguis exigir

Una descripció del procés val el que valen les condicions que l'avalen. Les nostres, per escrit:

• Facturació mensual, preavís operatiu de 30 dies. Sense permanència de dotze mesos. Un encàrrec que ha deixat d'aportar valor ha de poder acabar.
• Abast fix i preu tancat per a un MVP: vuit setmanes. Discovery, sprints de dues setmanes, llançament i lliurament. Si l'abast es mou, el redefinim per escrit; el preu no es desplaça en silenci.
• Garantia de substitució de 30 dies, substitut presentat en 7, sense cost afegit. Cada enginyer que col·loquem és a la nostra nòmina, així que el cost d'un match fallit l'assumim nosaltres.
• Un únic responsable a la nostra banda per a tot el recorregut —el delivery manager—, de manera que «a qui truco?» té una sola resposta.

I la xifra que més m'importa, perquè és l'única que un client no pot fingir: les renovacions. El nostre encàrrec més llarg en curs, un squad encastat de tres enginyers i un delivery manager que construeix el nucli d'un protocol i els seus SDKs verificadors, va arrencar amb un pressupost de 200.000 € i s'ha renovat per 400.000 € més: cada lliurable en data, zero bugs. Una renovació és una avaluació amb preu.

El que preguntaria a qualsevol partner abans de signar, nosaltres inclosos

Si estàs triant un partner de desenvolupament de software, recorre aquesta llista. Les respostes et diuen on s'aturaran.

1. «Ensenya'm el document de discovery del vostre últim projecte.» Si és una presentació, s'aturen a la venda.
2. «Qui és propietari de la decisió d'arquitectura i on és escrita?» Si la resposta és «el desenvolupador sènior», s'aturen a l'sprint.
3. «Quan arriba la primera PR mergejada al meu repositori?» Si és «després de la fase de prototip», el pipeline no està provat.
4. «Què passa en una demo que falla?» Si l'sprint es tanca igualment, la cadència és teatre.
5. «Qui parla amb els enginyers, no només amb mi?» Si ningú, els problemes t'arriben tard.
6. «Què inclou el lliurament, per escrit: comptes, documentació, esborrat?» Si és «us enviem el codi», s'aturen a la demo.
7. «Quines són les condicions de substitució i de sortida?» Si ho has de preguntar dues vegades, ja tens la resposta.

El partner que vols és el que s'atura l'últim: després que el sistema funcioni al teu nom, després que la documentació l'hagi llegit algú que no era a la sala, després que la seva còpia de les teves dades hagi desaparegut. Tot el que ve abans és un match i una demo, i un match i una demo són els dos punts on s'abandonen en silenci gairebé tots els projectes.

Si vols la versió d'aquest procés ajustada al teu producte, la definim en una trucada de 30 minuts, i comencem per escriure el criteri de cancel·lació.