Gairebé tots els projectes comencen igual. Algú té una idea que fa temps que li ronda pel cap: una app, una plataforma, una eina que resol un problema que coneix molt bé. L'ha imaginat funcionant, sap a qui va dirigida i, sovint, fins i tot té clar quina pantalla voldria veure primer.
I tot i així, quan arriba el moment d'explicar-la en una reunió, apareixen els dubtes: això com es fa?, quant costa?, per on es comença? Aquesta barreja de seguretat i buit és, probablement, el punt de partida més comú de tots. I no té res de dolent.
Tenir una idea clara no és el mateix que tenir un projecte
Una idea és una intenció. Un projecte és aquesta intenció traduïda a decisions concretes: què fa exactament el producte, per a qui, en quin ordre es construeix, què passa quan l'usuari fa clic aquí en lloc d'allà.
Entre aquestes dues coses hi ha una feina que gairebé ningú no veu, però que marca la diferència entre un desenvolupament que avança amb sentit i un que s'omple de sorpreses a mig camí. Aquesta feina és traduir el que tens al cap a alguna cosa que un equip pugui construir.
El que arriba definit... i el que arriba en blanc
El més habitual és que un client arribi amb algunes parts molt pensades i d'altres pràcticament sense tocar. No perquè hagi fet malament la seva feina, sinó perquè és impossible tenir-ho tot resolt des de fora del desenvolupament.
Un exemple típic: algú vol llançar una app perquè els seus clients reservin un servei. Té claríssim quin aspecte ha de tenir la pantalla de reserva, els colors de la seva marca i el missatge que vol transmetre. En canvi, no ha pensat què passa si dues persones intenten reservar la mateixa hora alhora, com es gestionen les cancel·lacions, o si cal un panell perquè el seu equip vegi les reserves del dia.
Cap d'aquests buits és un problema. Són, simplement, les preguntes que encara no s'ha fet perquè no tenia per què fer-se-les.
Per què això és del tot normal
Ningú no munta una cuina professional el primer cop que decideix que li agrada cuinar. Amb un producte digital passa igual: la idea neix del teu negoci i de la teva experiència, no de saber com funciona el desenvolupament de programari per dins.
Esperar que un client arribi amb tot tancat seria com demanar-li a algú que dibuixi el plànol de la casa abans de parlar amb l'arquitecte. El plànol és el resultat de la conversa, no el requisit per començar-la.
Les preguntes correctes, al principi
Aquí és on entra la feina d'un bon estudi. Abans d'escriure una sola línia de codi, dediquem temps a entendre el projecte de debò: quin problema resol, qui l'utilitzarà, què és imprescindible per a la primera versió i què pot esperar.
Aquest procés, la recollida de requisits, consisteix sobretot a fer les preguntes adequades en el moment adequat. Algunes són evidents. D'altres destapen coses en què ningú no havia pensat i que, si no sortissin ara, haurien aparegut més tard en forma de retard o de cost extra.
L'objectiu no és interrogar-te. És ajudar-te a veure la teva pròpia idea amb més nitidesa, fins que els buits deixen de ser dubtes i es converteixen en decisions.
Un bon estudi no espera que ho tinguis tot clar
Si alguna cosa distingeix un equip amb experiència és justament això: no dóna per fet que el client arriba amb el projecte resolt. Dóna per fet que arriba amb una idea valuosa i amb preguntes pendents, i entén que la seva feina és acompanyar aquest pas.
Així que si tens una idea clara en unes coses i molts dubtes en d'altres, ets exactament on has d'estar. Aquest és el punt de partida normal, i és des d'aquí que construïm.
A Liquid fa anys que convertim idees en productes digitals. I gairebé sempre comencem pel mateix: una bona conversa.
