Com definir una aplicació interna pas a pas

Quan una comanda s'anota en un xat, després passa a un full de càlcul i acaba requerint diverses trucades per saber en quin estat es troba, el problema no sol ser la falta d'una aplicació. Sol ser un procés sense una única manera de treballar ni una font d'informació clara.

Una aplicació interna pot reunir aquest procés en un mateix lloc perquè les persones autoritzades registrin, consultin i actualitzin la informació que necessiten. Però abans d'escollir pantalles o tecnologia, convé definir què ha de resoldre.

Aquesta guia respon a una pregunta pràctica: com preparar una aplicació interna que tingui un abast útil i comprovable? En acabar, podràs decidir si la teva necessitat està prou definida per plantejar una primera versió i quins dubtes has de resoldre abans de desenvolupar-la.

Resultat esperat

El resultat no és un document tècnic complex. És una descripció breu i compartida que permeti respondre aquestes preguntes:

• Quin procés ha de millorar.
• Qui utilitzarà l'aplicació i què podrà fer cada perfil.
• Quina informació s'ha de gestionar i qui n'és responsable.
• Quines funcions entren en una primera versió.
• Com comprovaràs que l'aplicació respon a la necessitat inicial.

Per exemple, una empresa podria necessitar que l'equip registri incidències, assigni responsables i en consulti l'estat sense dependre de missatges dispersos. Aquest seria el punt de partida; el disseny concret de la solució es decidiria després.

Pas 1: defineix l'objectiu

Objectiu: convertir una queixa general en un canvi observable.

Acció: descriu el procés actual en una frase i indica què hauria de passar d'una altra manera. Evita objectius com «modernitzar la gestió» o «tenir-ho tot controlat». Són comprensibles, però no n'hi ha prou per decidir què ha de fer l'aplicació.

Formula l'objectiu amb aquesta estructura:

Quan passa [situació], [persona o equip] ha de poder [acció] per [resultat operatiu].

Un exemple hipotètic:

Quan es rep una sol·licitud de servei, l'equip de coordinació ha de poder assignar-la i consultar-ne l'estat per evitar haver de cercar la informació en diversos canals.

La frase encara no obliga a crear una aplicació mòbil, una aplicació web o una automatització. Només fixa el resultat que s'ha d'obtenir.

Comprovació: l'objectiu està a punt si pots identificar qui fa l'acció, què canvia en la seva feina i en quina situació s'aplica. Si només conté adjectius com «àgil», «intuïtiu» o «complet», necessita més concreció.

Pas 2: delimita l'abast de la primera versió

Objectiu: concentrar la primera entrega en allò necessari per complir l'objectiu, sense convertir cada idea futura en un requisit immediat.

Acció: reuneix les funcions proposades i classifica-les en quatre grups:

• Imprescindibles: sense aquestes funcions no es compleix l'objectiu definit.
• Desitjables: aporten valor, però poden esperar.
• Futures: tenen sentit com a evolució, tot i que encara no es desenvolupin.
• Fora d'abast: pertanyen a un altre problema o procés.

Si l'objectiu és gestionar sol·licituds internes, crear una sol·licitud, assignar un responsable i actualitzar-ne l'estat podrien ser funcions imprescindibles. Un tauler avançat d'informes, avisos configurables o una connexió amb una altra eina podrien ser desitjables o futures, segons el cas.

Inclou també allò que sovint s'oblida quan es parla d'abast: càrrega o migració de dades existents, connexió amb eines externes, formació d'usuaris, documentació, proves i manteniment posterior. No tots aquests elements seran necessaris, però cal valorar-los de manera explícita.

Comprovació: cada funció ha de respondre tres preguntes: a quin objectiu dona suport, qui la farà servir i què passarà si no existeix en la primera versió. Si no les pots respondre, no la tractis com a imprescindible.

Pas 3: identifica les dades i els responsables

Objectiu: evitar una aplicació que mostri informació inconsistent, permeti canvis sense control o deixi tasques sense responsable.

Acció: fes un inventari senzill de la informació que intervé en el procés. Per a cada dada, anota:

• Què és i per a què s'utilitza.
• Qui la crea.
• Qui la pot consultar, modificar o eliminar.
• D'on prové si ja existeix en una altra eina.
• Què ha de passar quan falta, és incorrecta o canvia.

Els permisos són importants perquè dues persones poden necessitar la mateixa aplicació amb accions diferents. Una persona pot registrar una sol·licitud; una altra, assignar-la; i una tercera, revisar el conjunt sense editar-lo. Definir aquests rols des del principi ajuda a evitar accessos innecessaris i pantalles confuses.

També convé nomenar responsables de negoci, no només usuaris. Algú ha de resoldre dubtes sobre les regles del procés, aprovar canvis rellevants i validar que les dades mostrades tenen el significat esperat.

Comprovació: pots dibuixar el recorregut d'una dada des que s'introdueix fins que es consulta o es modifica. Si apareixen arxius, missatges o persones que ningú no havia esmentat, el procés encara està incomplet.

Pas 4: escull la solució després del problema

Objectiu: decidir com s'utilitzarà l'aplicació interna sense donar per fet que una tecnologia concreta resol per si sola la necessitat.

Acció: compara les condicions reals d'ús. Aquestes preguntes solen orientar la decisió:

• S'utilitzarà principalment des d'un ordinador, des d'un mòbil o des de tots dos?
• Les persones treballen en un lloc fix, es desplacen o atenen tasques sobre el terreny?
• Cal consultar o registrar informació sense connexió?
• S'ha de connectar amb sistemes que l'empresa ja utilitza?
• Qui actualitzarà continguts, usuaris, estats o regles del procés?
• Quins canvis són previsibles després de la primera versió?

Una eina estàndard pot encaixar quan el procés s'adapta raonablement a les seves regles. Una solució a mida pot tenir sentit quan hi ha fluxos propis, permisos específics, integracions o regles que no encaixen bé en una eina existent. L'elecció ha d'assumir els seus límits de manteniment, dependències i evolució; no hi ha cap opció adequada per defecte.

Una aplicació interna pot tenir format web, mòbil o tots dos. L'elecció depèn d'on i com es fa la feina, no pas que una opció sembli més moderna. Si necessites valorar una solució orientada a l'ús des del mòbil, pots consultar el servei d'aplicacions mòbils per a empreses.

Comprovació: la solució escollida permet a cada perfil completar les accions prioritàries en el seu context habitual de treball. Si la resposta exigeix suposicions sobre dispositius, connexió, accessos o eines externes, anota aquestes incerteses abans d'avançar.

Pas 5: valida abans d'ampliar

Objectiu: comprovar que la primera versió resol el procés definit i detectar ajustos abans d'afegir més funcions.

Acció: estableix criteris d'acceptació per a les accions importants. Un criteri descriu una situació inicial, una acció i un resultat esperat.

Exemple hipotètic per a una gestió de sol·licituds:

Quan una persona autoritzada crea una sol·licitud amb els camps obligatoris, la sol·licitud queda registrada, rep l'estat inicial definit i pot ser consultada pels perfils que tinguin permís.

Afegeix els casos que solen generar problemes: camps sense omplir, informació duplicada, canvis de responsable, estats no permesos o errors d'una connexió externa. No cal anticipar totes les excepcions possibles, però sí les que alteren la feina diària o la confiança en les dades.

La validació ha d'incloure persones que coneguin el procés real. Qui pren la decisió final també ha de confirmar que l'abast lliurat coincideix amb el que s'ha acordat, no només que l'aplicació funciona tècnicament.

Comprovació: cada funció imprescindible té una manera concreta de verificar-se. Si només la pots validar amb frases com «ha de ser fàcil d'utilitzar» o «ha de funcionar bé», defineix quina acció podrà completar cada perfil i en quines condicions.

Errors d'execució que convé evitar

• Començar per les pantalles. Una llista de pantalles no explica quin procés resolen ni quines regles han d'aplicar.
• Tractar tots els requisits com a urgents. Barrejar allò imprescindible amb el que és futur dificulta decidir una primera versió gestionable.
• Oblidar les dades existents. Si l'aplicació ha de partir d'arxius, fulls de càlcul o una altra eina, cal decidir quina informació es conserva, com es revisa i qui se'n responsabilitza.
• Deixar els permisos per al final. L'accés a dades i accions forma part del funcionament, no és un detall posterior.
• Esmentar una integració sense descriure el flux. Indica quina informació entra o surt, quan passa i què ha de passar si el servei extern no respon.
• No assignar una persona aprovadora. Sense una persona que resolgui dubtes de negoci i validi decisions, les interpretacions s'acumulen.
• Confondre el desenvolupament amb el tancament del projecte. L'aplicació necessitarà responsables de continguts, usuaris, incidències i canvis futurs.

Pas següent

Una aplicació interna ben plantejada comença per un procés que val la pena ordenar, no per una llista de funcions. Si ja pots expressar l'objectiu, els usuaris, les dades i la primera versió, estàs en millor posició per explicar el projecte i valorar quina solució encaixa. Si vols sol·licitar una valoració inicial de la necessitat i el seu abast, pots explicar el teu projecte a AVSISTEC per contrastar aquestes decisions abans de desenvolupar-lo.