Cinc casos d'IA per a equips tècnics, pas a pas

En un equip tècnic la pregunta no és si la IA serveix, sinó on entra sense convertir-se en una eina més al marge de la feina real. Aquests són els cinc casos amb què més vegades hem arrencat, cadascun amb el que cal per implantar-lo, què es mesura i quan no compensa. Si el que busques és el plantejament complet i no els casos, és a l'enfocament per a IT.

Com llegir les fitxes

Cada cas mostra la mateixa tasca dues vegades: com es fa avui i com queda amb la IA implantada. El que està ratllat a la columna d'avui és la feina manual que desapareix; on una persona continua treballant, encara que sigui amb ajuda, no es ratlla.

Les hores són les d'un exemple real, no una mitjana ni una promesa. I en els cinc casos hi ha una persona decidint al final: el que s'automatitza és reunir el context i preparar la feina, no la decisió tècnica.

01 · Desplegar un canvi

Què cal. El repositori accessible, les convencions escrites on es puguin llegir a cada sessió —estructura, noms, què es prova i com— i una revisió prèvia automàtica que apliqui aquests criteris abans que hi miri una persona. Les convencions són la part que no es pot saltar: sense elles, la revisió humana continua fent exactament la mateixa feina que avui.

Què es mesura. Temps des que s'obre el ticket fins que el canvi és en producció, comentaris de revisió per canvi i incidències per entrega. El segon és el que mostra si els criteris estan ben escrits.

Quan no compensa. Si no hi ha proves automàtiques ni manera de verificar el que surt, accelerar l'escriptura només accelera l'arribada dels errors a producció. Aquest és el cas anterior a aquest.

02 · Atendre el negoci

Què cal. Un model de dades llegible, amb noms que signifiquin alguna cosa per a qui pregunta, i els permisos resolts per rol abans d'obrir la porta. És el cas on el govern de les dades deixa d'ajornar-se, perquè sense ell no es pot implantar: cal decidir qui veu què i què queda registrat, i cal decidir-ho el primer dia.

Què es mesura. Consultes que deixen d'arribar a la cua de l'equip, temps de resposta al negoci i la llista de preguntes que l'agent marca perquè no les pot respondre. Aquesta llista és el més valuós del cas: és el full de ruta de la dada que falta, escrit per qui la necessita.

Quan no compensa. Si cada sistema dona una xifra diferent per a la mateixa pregunta, primer s'unifica. Un agent sobre dades que no quadren no estalvia feina: reparteix el desacord més ràpid i a més persones.

03 · Resoldre una incidència

Què cal. Registres centralitzats i amb prou context per reconstruir què va passar, i l'historial de desplegaments correlacionable amb les alertes. Si els registres estan repartits en cinc llocs i cal entrar a cadascun, la feina prèvia és ajuntar-los.

Què es mesura. Temps fins a identificar la causa —no fins a resoldre: el que canvia és el diagnòstic, no la decisió de la correcció— i incidències que acaben amb un informe escrit, que a la majoria d'equips avui és gairebé cap.

Quan no compensa. Si el problema real és que hi ha massa incidències, la feina és a la causa i no al diagnòstic. Resoldre més ràpid una avaria recurrent la fa sostenible, que és justament el que no interessa.

04 · Afegir una funcionalitat

Què cal. Les convencions del repositori, igual que en el primer cas, i una decisió que no es delega: quina és la versió que ja aporta valor sense ser la més completa. Aquesta és una decisió de producte, i és la que determina si la funcionalitat està en ús en dies o en mesos.

Què es mesura. Dies des de l'aprovació fins a la primera versió en ús, i proporció de funcionalitats que creixen després d'entregar-se davant de les que s'entreguen i ningú no torna a tocar. La segona xifra diu si estàveu construint el que calia.

Quan no compensa. Si l'equip no pot desplegar sovint, treure abans la primera versió no serveix de res: es queda esperant a la mateixa cua. Primer el desplegament, després això.

05 · Redissenyar una pantalla

Què cal. Les consultes de suport desades en algun lloc consultable —encara que sigui una bústia—, i el vostre sistema visual disponible com a components o com a codi. Amb aquestes dues peces, una alternativa navegable surt en hores i la discussió deixa de ser sobre un document.

Què es mesura. Consultes de suport sobre aquesta pantalla abans i després, i tasques completades sense demanar ajuda. Totes dues es mesuren amb el que ja teniu, i totes dues cal mesurar-les abans de tocar res.

Quan no compensa. Si ningú no ha mirat per què falla la pantalla, un redisseny ràpid produeix una pantalla nova amb el mateix problema, i a més amb la sensació que ja està resolt.

Per quin dels cinc començar

El primer cas no es tria pel que impressiona, sinó pel que deixa après. D'aquests cinc, desplegar un canvi és el que més vegades es repeteix al dia i el que abans ensenya l'equip a escriure criteri, sempre que ja hi hagi proves automàtiques.

Atendre el negoci és el que més temps allibera fora de l'equip tècnic, i el que obliga a resoldre permisos i govern de les dades: això el fa més lent d'arrencar i més valuós de tenir. Resoldre una incidència depèn per complet de com estiguin els registres. I els dos últims són projectes, no tasques: entren quan l'equip ja treballa així.

Els criteris complets amb què filtrem un primer cas —es repeteix, exigeix el criteri d'una persona, es pot verificar, la dada existeix i no trenca res si falla— són a l'article on expliquem com treballem.

Aquests cinc són els més habituals, no els únics: el catàleg complet els ordena per la part de l'empresa que afecten, i hi ha una versió d'aquesta llista per a negoci i operacions. Si voleu veure com encaixen al vostre stack, es pot demanar informació sense compromís: si no encaixa, us ho diem.