El software gairebé mai és el problema
Fa anys que entrem en projectes que altres van deixar a mig fer. I hi ha un patró: quan es pregunta què va fallar, la resposta sol ser tècnica. L'eina era dolenta, el proveïdor no va complir, la tecnologia es va quedar curta.
Gairebé mai és cert. En la majoria de casos el software funcionava. El que va fallar va ser una decisió de negoci presa abans d'escriure una línia de codi, o una decisió organitzativa presa després de lliurar-lo.
Aquests són els set errors que surten més cars, ordenats pel que hem vist que costen.
1. Digitalitzar el procés dolent
El més car de tots, amb diferència.
Una empresa té un procés que s'ha anat complicant durant quinze anys: un pressupost que passa per quatre mans, tres aprovacions, dos fulls de càlcul i un correu. I encarrega un sistema que repliqui exactament això.
El resultat és un procés igual de dolent, ara més rígid i més car de canviar. Abans, si algú volia saltar-se un pas, ho feia. Ara no pot.
Com evitar-ho: abans de definir el sistema, preguntar per a cada pas "per què existeix?". Un percentatge sorprenent de passos existeix perquè algú que ja no hi treballa va tenir un problema el 2014. Simplificar el procés primer, i després automatitzar-lo, costa menys i dona millor resultat.
2. No decidir qui mana
Un projecte de software genera desenes de decisions petites: quins camps són obligatoris, qui veu què, què passa quan falta una dada.
Si no hi ha una persona amb autoritat per decidir, cadascuna d'aquestes preguntes es converteix en una reunió. El projecte s'allarga per indecisió, no per complexitat tècnica.
Com evitar-ho: designar un responsable amb capacitat real de decidir, encara que després consulti. Un projecte amb un interlocutor clar avança al doble de velocitat que un amb un comitè.
Andie recomana
Si a la teva empresa la persona que decideix sobre el projecte no és la que l'utilitzarà, ajunta les dues persones a les mateixes reunions des del principi. La combinació d'un directiu que decideix sense fer-lo servir i un usuari que el pateix sense decidir és la recepta més fiable per a un sistema que ningú vol.
3. Pensar que la formació és opcional
S'inverteix a construir l'eina i es despatxa la formació amb un correu i un manual en PDF.
Després l'equip segueix fent servir l'Excel "perquè és més ràpid", i al cap de sis mesos algú conclou que el sistema no funcionava. Funcionava: ningú va aprendre a fer-lo servir.
Com evitar-ho: pressupostar la formació com a part del projecte, fer-la amb dades reals de l'empresa i no amb exemples genèrics, i repetir-la al cap de dues o tres setmanes, quan ja han aparegut els dubtes de veritat.
4. No posar data de tall
Relacionat amb l'anterior i prou greu com per anar a part.
Quan el sistema nou conviu indefinidament amb el mètode antic, guanya l'antic. Sempre. Perquè és el conegut i perquè en un dia de feina amb pressa ningú experimenta.
Com evitar-ho: data de tall clara, comunicada amb antelació i mantinguda. A partir d'aquell dia, les dades noves van només al sistema. Amb un període en paral·lel curt, dues o tres setmanes, no sis mesos.
5. Comprar per funcionalitats en lloc de per problema
Les comparatives de software es fan amb llistes de característiques. Guanya el que té més caselles marcades.
El problema és que el 80% d'aquestes funcionalitats no les faràs servir mai, i les que de debò necessites solen ser específiques de la teva manera de treballar, que és justament el que no apareix en cap llista.
Com evitar-ho: definir tres o quatre situacions reals del teu negoci i demanar que te les ensenyin resoltes. No una demo genèrica: el teu cas, amb les teves dades. És sorprenent quantes eines impecables sobre el paper cauen en aquest exercici.
6. Ignorar qui ho mantindrà
Un sistema lliurat no és un sistema acabat. Necessita actualitzacions de seguretat, canvis quan canvia la normativa i algú que respongui quan alguna cosa es trenca.
Quan això no es pensa d'entrada, passa el previsible: el sistema es queda sense actualitzar, acumula deute tècnic i al cap de tres anys cal refer-lo sencer. El cost de no mantenir sempre acaba sent més gran que el de mantenir.
Com evitar-ho: tractar el manteniment com una partida del pressupost anual des del primer dia, i tenir clar què inclou. Les preguntes concretes són a l'article sobre què preguntar abans de contractar software a mida.
7. No mesurar res abans de començar
Si no saps quant trigaves abans, no podràs demostrar que ara trigues menys. I sense aquesta prova, el projecte es percep com una despesa i no com una inversió, cosa que condiciona tot el que vulguis fer després.
Com evitar-ho: mesurar dues o tres coses abans de tocar res. Quant es triga a emetre un pressupost, quants errors de facturació hi ha al mes, quant temps es dedica a copiar dades. Són dades que es recullen en una setmana i valen l'or quan arriba el moment de justificar la fase següent.
Andie recomana
Guarda la mesura inicial per escrit i amb data, encara que sigui una nota de quatre línies. La memòria és trapella: sis mesos després tothom recordarà que "abans tampoc trigàvem tant". Amb el número anotat, la conversa és diferent.
El patró comú
Si mires els set, cap és tècnic. Tots tenen a veure amb decisions, persones i disciplina.
Aquesta és també la bona notícia: són errors que pots evitar tu mateix, abans de contractar ningú i sense coneixements tècnics. Un projecte amb el procés simplificat, un responsable clar, formació pressupostada, data de tall, criteri de compra per problema, manteniment previst i una mesura inicial té una probabilitat d'èxit molt alta, gairebé amb independència del proveïdor.
I al revés: sense això, el millor equip de desenvolupament del món et lliurarà una cosa que ningú farà servir.
Com ho treballem nosaltres
A AndorraDev, la primera conversa d'un projecte no va de tecnologia. Va de quin procés fa mal, qui decideix, com sabrem que ha funcionat i qui ho mantindrà després. És menys vistós que ensenyar pantalles, i és el que determina si el projecte serveix.
Si estàs pensant a digitalitzar alguna cosa i vols començar per les preguntes correctes, escriu-nos.
