Com definir el MVP d’una app abans de demanar pressupost

Una llista de funcions acostuma a créixer més de pressa que la definició del producte. Per preparar un MVP, o producte mínim viable, cal escollir una necessitat concreta i decidir què permetrà comprovar la primera versió. Aquesta definició ajuda a demanar una proposta de desenvolupament amb un abast comprensible i a valorar què s’ha d’ajornar.

Tria una persona i una tasca principal

Comença amb una frase que descrigui qui utilitzarà el producte, en quina situació i què necessita acabar. Per exemple: una persona que coordina activitats vol confirmar quins participants assistiran a la sessió següent. Aquest exemple delimita una tasca. Dir que vols una plataforma de gestió obre moltes possibilitats sense indicar quina s’ha de resoldre primer.

Documenta com es fa avui aquesta feina. Potser hi ha una conversa, un full compartit i diverses confirmacions manuals. Identifica on es perd informació o cal repetir passos. Si encara no ho saps, observa el procés amb futurs usuaris abans de convertir-lo en pantalles. Una primera versió definida sobre una rutina real es pot revisar amb preguntes molt més concretes.

Dibuixa el recorregut complet

Descriu l’inici, les accions i el resultat de la tasca. En l’exemple d’assistència, algú crea la sessió, convida els participants, recull les respostes i consulta el resultat. Decideix com accedeix cada persona i quina informació pot veure. Aquest recorregut permet detectar dependències que una llista de pantalles acostuma a amagar.

Inclou les situacions que fan que el recorregut sigui utilitzable: una invitació que no arriba, una resposta duplicada o una sessió cancel·lada. La primera versió pot tenir pocs recorreguts, però els previstos han de poder completar-se amb els seus errors habituals. Deixa explícit què farà el producte i què haurà de resoldre l’equip durant la prova.

Escull què necessites aprendre

Anota quina incertesa justifica construir la primera versió. Pot ser comprovar si la gent completa una tasca sense ajuda, si la informació recollida és suficient o si un canvi encaixa amb la manera de treballar de l’equip. Associa-hi una observació: on s’aturen els usuaris, quines dades falten o quants casos requereixen intervenció manual.

Defineix abans de la prova qui revisarà els resultats i quina decisió es prendrà després. Una mostra reduïda ajuda a detectar dificultats, amb límits sobre què es pot concloure. Evita interpretar qualsevol ús inicial com una validació de tot el negoci. La prova ha de respondre la pregunta que has formulat i deixar identificades les que encara queden obertes.

Separa dependències, comoditats i feina posterior

Classifica cada funció segons la seva relació amb la tasca principal. Algunes són necessàries perquè el recorregut funcioni; d’altres en milloren la comoditat. Un informe descarregable pot esperar si la persona ja pot consultar la dada que necessita. En canvi, identificar qui ha confirmat l’assistència pot formar part del resultat mínim acordat.

Algunes operacions es poden resoldre manualment durant una prova acotada, sempre que hi hagi una persona responsable i un procediment clar. Escriu quanta feina genera aquesta decisió i quan caldrà revisar-la. Ajornar una funció no elimina la necessitat que resol: pot traslladar-la a l’equip. Aquesta càrrega ha de ser visible quan s’aprova l’abast del MVP.

Comprova les incerteses abans d’ampliar

Diferencia el que necessita una conversa amb usuaris, un prototip de pantalles o una prova tècnica. Si no s’entén el recorregut, pots revisar el disseny abans de desenvolupar-lo. Si el dubte és si un sistema extern proporciona la informació necessària, cal comprovar-ne l’accés i la resposta. Cada tipus de dubte demana una evidència diferent.

Recull també les condicions de la prova: dispositius, dades que s’utilitzaran, persones participants i canal per comunicar incidències. Acorda qui prepararà continguts i qui atendrà els usuaris. Un producte petit també necessita operació. Si ningú pot revisar les incidències o corregir la informació, les conclusions de la prova poden quedar condicionades per aquesta falta de suport.

Entrega una definició que es pugui revisar

El document del MVP pot ser breu, però ha de permetre que disseny, desenvolupament i negoci entenguin el mateix encàrrec. Adjunta el recorregut, exemples de contingut i els dubtes pendents. Demana que la proposta identifiqui les hipòtesis que encara necessita confirmar, i revisa aquests punts abans d’aprovar-la:

Usuari principal i situació d’ús definida.
Recorregut que es podrà completar de principi a fi.
Funcions incloses, ajornades i operacions manuals assignades.
Pregunta que respondrà la prova i forma d’observar-la.
Criteris de revisió, responsables i següent decisió.

Posem límits útils a la primera versió

Explica’ns qui utilitzarà la teva app, quina tasca vols resoldre i què encara necessites comprovar. Podem partir d’aquest recorregut per parlar de l’abast.