Desenvolupament de programari: què incloure i com prioritzar-lo

Quan un equip treballa amb fulls de càlcul, missatges i eines desconnectades, la petició sol arribar formulada així: "Necessitem un programa". El problema és que aquesta frase no aclareix què ha de resoldre, qui l'usarà ni què hauria d'ocórrer per considerar útil la inversió.

El desenvolupament de programari mereix la pena quan tradueixes una necessitat concreta en un sistema que permet realitzar accions, aplicar regles i gestionar informació de forma més ordenada. En acabar aquesta guia podreu decidir què incloure en una primera versió, quina ajornar i quina informació preparar abans de valorar el projecte.

Si encara esteu comparant una eina estàndard, una solució configurable o un desenvolupament propi, comença pels criteris per a elegir programari empresarial. Aquesta guia part del pas posterior: com definir i prioritzar un projecte que sí que requereix desenvolupament.

Resposta directa: comença pel problema, no per l'aplicació

Abans de triar entre una aplicació web, una app mòbil o una eina interna, defineix el canvi que busques. Per exemple: reduir duplicitats en registrar comandes, donar visibilitat de l'estat d'un servei o permetre que els clients consultin documentació sense dependre de correus.

La tecnologia és la solució; l'objectiu és la referència per decidir. Si no pots descriure el problema, els usuaris i l'acció que heu de millorar, encara no tens un abast prou clar.

7 elements que ha de concretar un projecte de desenvolupament de programari

L'objectiu operatiu o comercial Descriu què heu de canviar amb una frase de gestió. L'«Ordenar la gestió» és massa ampli. «Permetre que l'equip consulti l'estat de cada comanda en un únic lloc» delimita millor la necessitat i ajuda a comprovar si la solució compleix la vostra funció.

Les persones que usaran el sistema No n'hi ha prou amb indicar que l'usarà "l'empresa". Distingeix, per exemple, entre administració, equip comercial, responsables d'operacions i clients. Cada perfil pot necessitar pantalles, permisos i accions diferents.

El recorregut principal de treball Explica què passa des que entra una sol·licitud fins que es completa. Un recorregut pot incloure registrar dades, assignar una tasca, canviar un estat, adjuntar un document i avisar una persona. Aquest ordre revela regles i excepcions que solen quedar ocultes en una idea inicial.

Les dades que cal consultar o modificar Identifica quina informació necessita el programari: clients, comandes, cites, documents, incidències, inventari o altres registres propis de la teva activitat. També convé definir qui pot veure, editar o eliminar cada dada.

Les funcions necessàries en la primera versió Una funció ha de respondre a un objectiu i a un usuari. Per exemple, un plafó per assignar sol·licituds pot ser necessari si evita que diverses persones treballin sobre el mateix assumpte; un sistema avançat d'informes pot esperar si al començament n'hi ha prou amb consultar els estats principals.

Les connexions amb altres eines Si el programari ha d'intercanviar informació amb correu, facturació, pagaments, calendaris o altres serveis, concreta quina dada viatja, en quin moment i què hauria de passar si la connexió falla. Nomenar una integració sense descriure aquest flux deixa una part rellevant de l'abast sense definir.

El manteniment i l'evolució El projecte no acaba en posar el sistema en ús. Decideix qui actualitzarà continguts o dades, qui tindrà els accessos i quins canvis són previsibles. Pensar en això des de l'inici ajuda a evitar una solució difícil de modificar quan canviïn processos o necessitats.

Com prioritzar sense intentar construir-ho tot alhora

Classifica cada necessitat en una d'aquestes quatre categories. La classificació obliga a assumir una conseqüència: incloure alguna cosa ara, posposar- el o descartar- el conscientment.

• Imprescindible: sense aquesta funció no es compleix l'objectiu mínim. Si l'objectiu és centralitzar sol·licituds, crear, assignar i consultar una petició, podeu entrar aquí.
• Desitjable: aporta utilitat, però el sistema segueix complint la seva funció inicial sense ella. Per exemple, avisos configurables per a diversos esdeveniments.
• Futur: pot tenir sentit més endavant, encara que no forma part del primer lliurament. Per exemple, una àrea per proveïdors si a l'inici tan sols treballarà l'ordinador intern.
• Fora d'abast: no respon a l'objectiu acordat o pertany a un altre projecte. Deixar- el escrit evita que aparegui com una expectativa implícita.

Per decidir la categoria, respon a aquestes preguntes per a cada funció:

• Quin objectiu recolza?
• Qui la farà servir?
• Què passa si no existeix al principi?
• De quines dades, decisions o serveis externs depèn?
• Com comprovaràs que funciona com esperes?

Una funció que no té usuari, propòsit o forma de validar-se encara és una hipòtesi, no un requisit llest per desenvolupar.

Exemple aplicat: una empresa que gestiona sol·licituds per diversos canals

Aquest és un exemple hipotètic. Una empresa rep sol·licituds per telèfon, correu i formularis. La informació es copia a un full de càlcul i l'equip no sempre sap qui està atenent cada cas.

El seu objectiu es podria formular així:registrar cada sol·licitud i fer visible el seu responsable i estat per a l'equip.

Una primera versió podria incloure:

• accés per a les persones de l'equip;
• registre de sol·licituds amb camps acordats;
• assignació de responsable;
• estats definits, com a pendent, en curs i tancada;
• recerca bàsica i consulta de l'historial;
• una vista de gestió per a revisar els casos oberts.

En canvi, podrien quedar per a una fase posterior la creació d'informes a mida, una aplicació mòbil específica o connexions amb eines que encara no s'han descrit amb prou detall.

La decisió no consisteix a determinar si aquestes millores són bones o dolentes, sinó que consisteix a comprovar si són necessàries per resoldre el problema inicial i si les seves dependències estan clares.

Què convé deixar fora de la primera conversa

No cal que arribis amb una especificació tècnica tancada. De fet, decidir la tecnologia abans d'entendre la feina que ha de suportar pot limitar alternatives útils. És preferible deixar obertes aquestes qüestions fins a concretar l'abast:

• el nom exacte de la tecnologia o del tipus d'app;
• funcions definides només com a "completes", "sencilles" o "intuïtives";
• integracions sense un flux de dades i un responsable clar;
• terminis lligats a una data sense revisar continguts, accessos i dependències;
• resultats formulats com a garanties;
• extres que no contribueixen a l'objectiu de la primera versió.

Tampoc convé tractar una aplicació com una solució aïllada. Si un procés depèn de decisions internes, informació incompleta o regles que canvien sovint, aquestes condicions s'han de revisar abans de convertir-les en funcionalitat.

Següent pas: convertir la necessitat en un abast revisable

Reuneix un exemple real del procés actual, les persones implicades i les tasques que generen més problemes. Amb aquesta base serà més fàcil distingir si necessites una eina interna, un portal per a clients, una aplicació mòbil o una altra solució.

Si voleu contrastar l'abast d'una idea i les seves prioritats, pots explicar el teu projecte de programari a mida. El punt de partida útil és compartir el problema, els usuaris i les accions que el sistema hauria de permetre; la solució tècnica s'ha de validar després.