Quando i leader delle risorse umane diventano creatori
Insegnamento dell'esperimento: I progetti collaborativi di IA hanno offerto intuizioni profonde sulle capacità delle risorse umane, andando oltre il semplice sviluppo di strumenti.
Focalizzazione sul problema: Passare dall'analisi del sentiment alla mappatura delle competenze ha evidenziato l'importanza di definire obiettivi chiari e raggiungibili.
Scetticismo nei confronti dell'IA: I professionisti delle risorse umane affrontano sfide significative in materia di responsabilità e trasparenza nelle piattaforme di IA esistenti.
Struttura dello strumento: Lo strumento di valutazione basato sull'IA ha posto l'accento sulla collaborazione, consentendo agli utenti di confermare o contestare i riscontri generati dall'IA.
Collaudo avversariale: Lo sviluppo efficace di uno strumento richiede test rigorosi con input diversificati per gestire efficacemente i casi limite.
Le riunioni erano programmate per un'ora. Quasi sempre finivano per durare più a lungo.
Non è insolito quando si riunisce un gruppo di professionisti delle risorse umane per parlare di IA. Ciò che era insolito era quello che veniva chiesto loro di fare con quella conversazione. Non analizzarla, non pubblicare un articolo di riflessione al riguardo, ma costruire concretamente qualcosa.
Nell'autunno del 2025, ho riunito quelli che chiamavo gruppi di lavoro: un piccolo gruppo di professionisti delle risorse umane e delle operations del personale che avevo individuato come persone già impegnate in questo lavoro, già intente a esplorare i confini di ciò che la professione delle risorse umane poteva fare con l'IA.
Continua a leggere—e continua a guidare con intelligenza
Crea un account gratuito per terminare la lettura e unirti a una community di leader lungimiranti che sbloccano strumenti, playbook e approfondimenti per prosperare nell'era dell'IA.
Have an account? Log In
L'ipotesi era semplice. Le persone più vicine ai problemi sono quelle nella posizione migliore per costruire le soluzioni. La domanda era se ne fossero capaci.
In tutto avrei creato quattro gruppi di lavoro e, lungo il percorso, mi sarei resa conto che definire gli obiettivi per queste sessioni è più facile a dirsi che a farsi. Alla fine, la maggior parte dei gruppi si è arenata, faticando a realizzare la visione iniziale o a concordare un unico obiettivo. I calendari, i carichi di lavoro e le esigenze dei nostri impieghi effettivi spesso portavano a conversazioni da cui emergevano ottime idee, senza però riuscire mai a trasformarle in realtà.
Ma un gruppo si è riunito ed è riuscito effettivamente ad arrivare fino in fondo, per quanto possibile. Il fatto è che più ci si addentra nel percorso del costruire da sé, più diventa difficile rispettare una visione condivisa e affrontare la sfida ingegneristica.
Questa storia racconta ciò che è emerso da quelle sessioni e ve la propongo come caso di studio per costruire le vostre soluzioni.
Il gruppo di lavoro
Non erano scettici dell'IA che avevano bisogno di essere convinti. Erano professionisti che avevano già scommesso su questo momento. Ciò che il gruppo offriva loro era uno spazio strutturato per smettere di consigliare e iniziare a creare.
La prima conversazione sincera
La prima sessione ha fatto emergere qualcosa che raramente trova spazio nei commenti pubblicati sulle risorse umane: quanto questi professionisti siano realmente frustrati dagli strumenti che dovrebbero utilizzare.
Turnmeyer ha dato il tono alla discussione. Aveva cercato di ottenere documentazione tecnica sul funzionamento dell'analisi del sentiment all'interno di BambooHR, Paycom e Gusto: non per respingere gli strumenti, ma perché il suo team legale doveva comprenderli prima di approvarne l'utilizzo.
Né i team commerciali né i rappresentanti legali erano in grado di rispondere alle sue domande. Le funzionalità di IA esistevano. La responsabilità del loro funzionamento no.
Gillies stava affrontando una tensione analoga. Alcune voci interne avevano sollevato preoccupazioni sull'impatto ambientale dell'IA e alcuni colleghi volevano semplicemente vietare l'uso dell'IA da parte dei dipendenti. Gillies si è opposta.
Vietare completamente l'IA porta a un utilizzo clandestino e a un aumento dei rischi. Adottare l'IA con adeguate misure di controllo è un approccio migliore.
Melina Gillies · Responsabile delle persone, Flex Networks
Da quella prima ora emerse una diagnosi sulla quale il gruppo riusciva a concordare. Le funzionalità di IA integrate nelle piattaforme HR aziendali erano, come ha detto Gillies, «spesso basilari e prive di funzionalità».
Gli strumenti che funzionano davvero tendono a essere personalizzati, costruiti per problemi specifici, contesti specifici e aziende specifiche. Turnmeyer voleva meno strumenti, non di più: un ritornello che sento spesso ripetere ai responsabili delle persone e delle operations. Riusciva a immaginare un futuro in cui un'IA capace, alimentata con i documenti giusti, rendesse superfluo un HRIS.
Si sono confrontati anche con un tema che raramente viene affrontato in modo così diretto: l'etica del monitoraggio comportamentale. L'idea di utilizzare i tassi di rifiuto delle riunioni, le lacune negli accessi al sistema o orari di lavoro insoliti come indicatori indiretti del disimpegno è emersa fin dalle prime fasi.
Così come sono emersi i limiti di questo approccio. Satterfield ha evidenziato un rischio che prima o poi ogni strumento per il coinvolgimento deve affrontare: la stanchezza da inazione. Se si raccolgono dati senza agire in modo visibile sulla base di essi, i dipendenti smettono di fidarsi del sistema. I dati diventano rumore e lo strumento si trasforma in teatro dell'IA.
Non erano pronti a costruire uno strumento di analisi del sentiment. Era troppo ampio, troppo gravato da dilemmi etici e troppo facile da usare in modo catastroficamente errato. Così hanno cambiato direzione.
Trovare il problema giusto
La seconda sessione è iniziata con l'ammissione sincera che la direzione originaria era troppo ambiziosa e troppo ambigua.
«Non so se questo misuri il coinvolgimento», ha detto Turnmeyer, «o se stia semplicemente misurando qualcosa che richiede una conversazione».
Questa distinzione è più importante di quanto possa sembrare. Molte tecnologie HR commettono l'errore di trattare i dati come un sostituto della conversazione. Il gruppo cercava di utilizzare l'IA per portare alla luce i momenti in cui è necessario avviare una conversazione e poi rendere quella conversazione migliore.
Satterfield ha introdotto l'idea che avrebbe fatto da perno al resto del progetto. Durante un blocco delle assunzioni presso un precedente datore di lavoro, aveva creato un'autovalutazione delle competenze per il suo team di acquisizione dei talenti: un modo per mappare ciò che le persone sapevano fare rispetto a ciò che volevano realmente fare, generando una mappa di calore che rendeva le decisioni di riassegnazione più umane e strategiche.
Non era basata sull'IA. Era un modulo Microsoft. Ma la logica sottostante era solida, il caso d'uso era reale e lei ne aveva osservato il funzionamento.
«I grandi fornitori stanno cercando di farlo, ma nessuno lo sta ancora facendo davvero bene e molte aziende non hanno un budget destinato a questo tipo di tecnologia in aggiunta al loro HRIS principale», ha detto.
Il gruppo ha visto un'opportunità. E se avessero costruito una versione nativa dell'IA? Una versione conversazionale invece che clinica, orientata al futuro invece che guidata dalla conformità e con un prezzo pensato per i singoli responsabili HR anziché vincolata da contratti aziendali?
Il modo in cui le persone HR parlano di HR tra loro è radicalmente diverso. Questo può rappresentare un vero valore e la maggior parte degli strumenti lo ignora completamente.
Melina Gillies · Responsabile delle persone, Flex Networks
Fisher, mentre ascoltava il gruppo analizzare le possibilità, ha offerto un'osservazione che ha ridefinito il potenziale del progetto. Aveva sperimentato entrambi gli estremi dello spettro HR: quello orientato innanzitutto alla conformità, ai framework e alle transazioni, e il più raro professionista che mette le persone al primo posto e che gli parlava «come una persona che sembrava essere dalla mia parte».
«Il linguaggio del secondo tipo», ha detto, «non sembrava mai provenire da un framework scritto decenni fa. Semplicemente, faceva stare bene».
Gillies ha colto l'idea. Secondo lei, l'elemento distintivo del loro strumento erano il tono e la struttura. E se fosse riuscito a replicare il modo in cui i professionisti HR parlano davvero tra loro a una conferenza, tra una sessione e l'altra, lontano dai riflettori? E se avesse compreso l'espressione «politicamente accorto» non come una casella da spuntare, ma come qualcosa di carico di significati, controverso e complesso a livello situazionale, su cui i professionisti esperti discutono tra loro?
Quella era la direzione: uno strumento di valutazione pre-assunzione progettato per i responsabili HR e dell'acquisizione dei talenti che hanno bisogno di un modo migliore per valutare i candidati recruiter prima di assumerli. Non un test della personalità né uno screening del curriculum, ma uno strumento diagnostico strutturato e conversazionale in grado di dire al responsabile delle assunzioni se la persona seduta di fronte a lui sapesse davvero svolgere il lavoro. Uno strumento che sembrasse meno una valutazione delle prestazioni e più una conversazione con qualcuno che conoscesse il recruiting dall'interno.
Il momento dell'intuizione
Alla terza sessione, il gruppo era ormai concentrato sull'architettura dello strumento: quali competenze valutare, come strutturarle per livello e come tenere conto del divario tra ciò che le persone dicono di saper fare e ciò che sono effettivamente in grado di fare.
La critica ai framework esistenti è arrivata da Gillies, che ha descritto il modello delle competenze di SHRM come «molto tradizionale e, per alcuni aspetti, molto orientato al passato». La professione si trovava ancora, per usare la sua espressione, in una «sbornia postindustriale»: basata sulla conformità, gerarchica e progettata per un mondo che stava già scomparendo.
Il loro strumento doveva orientarsi verso qualcos'altro, non verso ciò che i responsabili HR dovevano sapere, ma verso ciò che dovevano essere in grado di fare.
Sei disposto ad avere una conversazione con il CEO riguardo alle sue prestazioni? Se non lo sei, non sei un esperto nelle conversazioni difficili.
Erin Turnmeyer · VP delle Operazioni del Personale
Turnmeyer aveva un esempio illuminante. Di recente aveva sostenuto l'esame SPHR. Le cose che era necessario conoscere—statuti, definizioni procedurali, regole di classificazione—erano informazioni che qualunque professionista HR competente avrebbe semplicemente cercato.
Le competenze tecniche non erano il materiale della certificazione. Erano cose come: riesci a sederti di fronte a un CEO e dirgli qualcosa che non vuole sentire? Riesci a sostenere un dipendente quando il caso aziendale è ambiguo? Memorizzare i codici del lavoro non risponde a queste domande.
Fisher si spinse oltre. Aveva trascorso anni nella gestione del cambiamento e aveva scoperto che la variabile più predittiva della capacità di un'organizzazione di affrontare la trasformazione non era una competenza specifica. Era il rapporto di una persona con l'ambiguità.
Capire quanto una persona si senta a proprio agio nell'essere a disagio—o con il ritmo del cambiamento in generale—è un indicatore fondamentale della sua capacità di funzionare in questo nuovo mondo.
Tim Fisher · Responsabile dell'IA , Black and White Zebra
Poi arrivò quello che il gruppo avrebbe in seguito definito l'ingrediente segreto.
Gillies propose una domanda. E se lo strumento integrasse una verifica incrociata? Se qualcuno si valutasse come esperto nella gestione dei conflitti, ma poi, in una risposta in linguaggio naturale a una domanda di approfondimento, descrivesse situazioni che sembravano tutt'altro che espressione di competenza, l'IA potrebbe segnalarlo? Potrebbe dire, con tatto, che forse c'è una lacuna?
"Questo è il momento della lampadina," disse Turnmeyer.
Satterfield osservò che chiunque abbia lavorato con gli inventari delle competenze ha visto versioni dello stesso problema. Spesso le persone si valutano in modo molto diverso da quanto suggerirebbero la loro esperienza effettiva o il loro comportamento.
Il valore dello strumento non sarebbe derivato dal registrare ciò che le persone pensavano di sé. Sarebbe derivato dalla calibrazione—il delicato attrito, basato sui dati, tra autopercezione e capacità dimostrata.
La valutazione non sarebbe stata soltanto uno specchio. Sarebbe stata più simile a “specchio, specchio delle mie brame” di quanto la maggior parte delle persone sia abituata a ricevere dalle valutazioni sul posto di lavoro.
Le realtà della costruzione
Niente di tutto questo era facile. E il gruppo lo sapeva fin dall'inizio.
La sfida più persistente non era tecnica. Era l'ambito del progetto. Ogni sessione generava dieci nuove direzioni, ciascuna realmente preziosa, ciascuna capace di assorbire l'intero progetto. Turnmeyer lo fece notare fin dall'inizio e continuò a farlo spesso.
"Assicuratevi che faccia bene la prima cosa, così non vi ritrovate con un ambito del progetto che si espande a tal punto da non riuscire più a crearlo," disse.
Satterfield introdusse un principio guida per il gruppo: la differenza tra un Prodotto Minimo Funzionante e un Prodotto Minimo di Valore. Un prodotto funzionante opera correttamente. Un prodotto di valore fa sì che le persone desiderino tornare.
In un mercato saturo di strumenti di valutazione, un'interfaccia che non offre qualcosa di significativo alla prima interazione non avrà una seconda possibilità per migliorare. Il parametro non è la funzionalità. È il valore.
Se il prodotto non offre un valore sufficiente al primo accesso, probabilmente gli utenti non torneranno in seguito per vedere se è migliorato.
Kelly Satterfield · Responsabile HR e consulente
C'erano anche i vincoli pratici che chiunque abbia provato a costruire qualcosa al di fuori di un team di sviluppo conosce bene: distribuzione, infrastruttura per i pagamenti, integrazione con i sistemi esistenti, finestre di contesto che si chiudono a metà sessione e cancellano ore di lavoro produttivo.
La prima versione rifletteva il flusso fondamentale dello strumento. Un candidato per un ruolo di recruiter carica un curriculum, lo strumento deduce un profilo preliminare delle competenze e poi lo guida attraverso una serie di domande conversazionali progettate per calibrare e aggiungere contesto e profondità a quella valutazione iniziale.
Alla fine, un responsabile delle assunzioni ottiene un quadro della posizione effettiva del candidato rispetto a un quadro di competenze definito.
Fisher configurò l'ambiente principale di sviluppo in Lovable—un costruttore di IA senza codice che genera strumenti destinati al pubblico attraverso la conversazione, senza vincolare gli utenti a un LLM specifico—così che l'architettura tecnica potesse tenere il passo con il pensiero del gruppo senza diventare essa stessa un collo di bottiglia.
Dal progetto alla costruzione
Alla quarta sessione, il gruppo non stava più progettando uno strumento astratto. Ne stava costruendo uno e scopriva, come accade sempre a chi costruisce, che è proprio nella distanza tra l'idea e la sua realizzazione che avviene il vero apprendimento.
Fisher aveva assemblato un GPT personalizzato di base prima dell'inizio della chiamata, dotato di istruzioni, di un framework preliminare delle competenze e degli elementi iniziali della logica conversazionale che avevano delineato nelle sessioni precedenti. Il piano prevedeva che tutti potessero accedervi, fornirgli richieste in modo collaborativo e iniziare a calibrare voce e comportamento in tempo reale. Il piano si è scontrato immediatamente con la realtà.
Il link condiviso non funzionava per nessuno tranne che per me. Le autorizzazioni dell'area di lavoro, le peculiarità della piattaforma e il modo specifico in cui ChatGPT gestisce l'accesso esterno hanno assorbito il primo quarto della sessione.
Era una piccola frustrazione, esattamente il tipo di problema che non finirebbe mai in un annuncio di prodotto, ma è stata istruttiva. Gli strumenti che i professionisti usano davvero per costruire qualcosa non si comportano come nelle demo.
Questo screenshot mostra come sarebbe diventata la schermata di benvenuto dello strumento creato dal gruppo, chiamato Talent Scout.
Una volta che tutti guardavano la stessa schermata, è successo qualcosa di più interessante. Mentre il gruppo stava ancora discutendo quale formato dovessero avere le definizioni delle competenze, Gillies ha aperto Claude in una finestra separata e ha convertito la tabella dei punteggi in JSON strutturato, dal vivo, durante la chiamata.
«Uso Claude perché per questo è migliore di ChatGPT», ha detto senza troppi convenevoli. Pochi minuti dopo ha inserito il file formattato nella chat di gruppo. Nessuno si è fermato a commentare. Hanno semplicemente proseguito.
Questo tipo di risoluzione dei problemi in corso d'opera—trasformare un collo di bottiglia in un problema risolto senza farne l'evento principale della riunione—è ciò che distingue i professionisti che hanno davvero interiorizzato questi strumenti da quelli che stanno ancora imparando a orientarsi.
Chi ha l'ultima parola
Satterfield ha sollevato una questione che avrebbe avuto implicazioni significative sia per l'architettura dello strumento sia per la sua futura accoglienza: è l'IA a formulare la valutazione finale o è l'utente a confermarla?
La distinzione non è solo estetica. Se lo strumento fornisce un verdetto come «In base alle tue risposte, sei al Livello 2 per quanto riguarda l'attenzione ai candidati», allora presenta l'IA come autorità. Se invece mostra una valutazione provvisoria e invita l'utente a contestarla, la dinamica cambia completamente. La valutazione diventa collaborativa anziché valutativa. L'utente è partecipe del processo, non il suo oggetto.
«Accetti questo feedback?» ha detto Turnmeyer quando l'idea ha preso forma. «Mi piace davvero.»
Gillies ha sviluppato la logica. Se l'utente non accetta la valutazione, lo strumento chiede che cosa non sembri corretto e poi utilizza la risposta per ricalibrare la propria valutazione oppure per riconfermarla con delicatezza, esaminando le prove.
È questo botta e risposta conversazionale a creare la sicurezza psicologica di cui lo strumento ha bisogno per essere davvero utile. Le persone non cambiano sulla base di un feedback di cui non si fidano. Ottenere il consenso non è una caratteristica secondaria: è il meccanismo.
Il primo vero test
Hanno deciso di testare il prototipo dal vivo. Turnmeyer si è offerta volontaria per dare una risposta volutamente superficiale a una delle domande della valutazione, del tipo che potrebbe fornire un candidato disimpegnato o un dipendente distratto.
Ha raccontato di aver discusso con il proprio manager per una discrepanza salariale, di aver perso il candidato e di non avere idea di quale fosse stato l'esito. Era l'equivalente, in ambito HR, di rispondere «Mi piacciono davvero tanto le persone» alla domanda sul perché si voglia lavorare nelle risorse umane.
Lo strumento l'ha valutata immediatamente. Ha assegnato un livello. Era incoraggiante. Era anche sbagliato, non dal punto di vista fattuale, ma perché era prematuro. Aveva fatto supposizioni su ciò che la risposta implicava invece di chiedere il contesto aggiuntivo necessario per effettuare una valutazione accurata.
Se vuoi dare a qualcuno una valutazione diversa da «soddisfa le aspettative», devi fornire esempi dettagliati. L'IA dovrebbe sottoporsi allo stesso standard.
Erin Turnmeyer · Vicepresidente delle operazioni del personale
Turnmeyer ha tracciato direttamente il parallelismo con la propria pratica di valutazione delle prestazioni. Da tempo chiedeva ai manager di fornire prove specifiche prima di assegnare a qualcuno una valutazione superiore o inferiore a «soddisfa le aspettative».
La stessa disciplina dovrebbe applicarsi allo strumento. Prima di assegnare un livello, bisogna guadagnarsi il diritto di farlo ponendo le domande che renderebbero la valutazione difendibile. Ancora una volta, era l'esperienza HR presente nella stanza a rendere migliore l'IA, non il contrario.
Satterfield ha aggiunto una complicazione che lo strumento aveva trascurato. La risposta superficiale poteva riflettere una politica aziendale, non una competenza.
Se il manager avesse fissato davvero un tetto massimo inderogabile per la retribuzione, insistere con maggiore determinazione non avrebbe cambiato l'esito. Lo strumento aveva valutato la persona quando avrebbe dovuto interrogarsi sulla situazione. Le domande di chiarimento non erano un dettaglio di rifinitura. Erano ciò che avrebbe fatto la differenza tra una valutazione utile e una presuntuosa.
Turnmeyer ha preso il compito di scrivere le istruzioni come lavoro a casa: come si può chiedere a uno strumento di porre domande di chiarimento nei momenti giusti senza far sembrare ogni interazione un interrogatorio?
Questa schermata mostra un esempio di ciò che farebbe il prodotto finale: porre domande di chiarimento e spingere il candidato ad andare più in profondità.
È un problema più difficile di quanto sembri, ed era perfettamente consapevole che il livello richiesto fosse insolitamente alto.
"Deve essere migliore di un essere umano", ha detto. "Questo è lo standard."
I test come disciplina
La sessione ha prodotto anche una delle intuizioni metodologiche più utili dal punto di vista pratico dell'intero gruppo. Quando Satterfield ha chiesto come il gruppo testasse solitamente strumenti di questo tipo, sia Turnmeyer sia Gillies hanno risposto in modi che hanno rivelato qualcosa di importante su come si svolgono realmente i test rigorosi nella pratica.
Per il suo strumento di raccomandazione dei benefit, che doveva individuare con precisione se determinati farmaci fossero coperti dal piano sanitario dell'azienda, Turnmeyer ha eseguito test specifici sui casi limite. Non sui farmaci ovvi, quelli più diffusi che il modello avrebbe incontrato ripetutamente durante l'addestramento. Ha testato quelli poco conosciuti, nelle categorie più inclini a produrre un'allucinazione espressa con sicurezza.
"Sono andata a testare i farmaci meno diffusi", ha detto, "perché Claude mi ha mostrato cosa stava facendo mentre lo costruiva."
Questo livello di intenzionalità avversariale nei test è raro tra i creatori provenienti da contesti diversi dall'ingegneria. È anche esattamente ciò che distingue gli strumenti che conquistano la fiducia da quelli che vengono abbandonati silenziosamente dopo un fallimento imbarazzante.
Eliminare ciò che si è già costruito
Una sessione di riallineamento appena prima delle festività è iniziata con una domanda più difficile da porre di quanto sembri: a cosa serve davvero la funzione di caricamento del curriculum?
Gillies l'ha sollevata. La valutazione chiedeva agli utenti di riflettere attentamente sulle proprie capacità. Il curriculum aggiungeva informazioni che l'utente non avrebbe potuto fornire più direttamente, limitandosi a rispondere alle domande? Nessuno nel gruppo era certo che fosse così. L'intento originale era risparmiare tempo, come farebbe un analizzatore di curriculum, ma non eravamo più convinti che mantenesse quella promessa.
Hanno deciso di eliminarla.
Nello sviluppo del prodotto è più raro di quanto sembri. Il gruppo aveva dedicato tempo concreto alla funzione di caricamento: l'aveva costruita, testata e aveva osservato il curriculum di Satterfield venire analizzato e valutato erroneamente. Eliminarla richiedeva di scavalcare la logica dei costi irrecuperabili che spinge i team ad aggiungere elementi a ciò in cui hanno già investito.
Iniziate dalla fine e definite come dovrebbe essere un buon risultato. Se non riuscite a spiegare a cosa serve una funzione, non potete difenderne l'utilità.
Turnmeyer ha avanzato un'argomentazione correlata sul metodo. A posteriori, pensava che avrebbero potuto procedere più velocemente definendo completamente il comportamento dello strumento prima di scrivere un solo prompt. Avevano seguito qualcosa di simile a un modello agile—costruire, testare, modificare—quando la complessità di ciò che stavano costruendo avrebbe potuto richiedere maggiormente un approccio a cascata: definire prima correttamente le specifiche e poi costruire sulla base di quelle.
Aveva un documento di progettazione di 130 pagine relativo a un altro strumento che aveva costruito e che le aveva insegnato questa lezione. Una specifica completa non dice soltanto cosa costruire. Dice anche cosa non si sta costruendo, cosa che si rivela altrettanto utile.
Gillies ha precisato il problema centrale del prodotto. Qualunque cosa lo strumento mostrasse sullo schermo doveva andare oltre. Una valutazione che porta alla luce dei dati non equivale a uno strumento che dice cosa farne. È in questo divario tra risultato e azione che gli strumenti diagnostici smettono silenziosamente di essere utili, ed è il divario che la maggior parte di essi non colma mai.
Costruire da sola
A gennaio, Satterfield si occupava da sola della maggior parte della costruzione, mentre il resto del gruppo sentiva troppo forte il richiamo del proprio lavoro dalle 9 alle 17, che richiedeva troppo tempo per lasciare spazio al progetto. Dopotutto, nessuno veniva pagato per questo.
Aveva rimosso il caricamento del curriculum, come il gruppo aveva concordato. Aveva aggiunto l'inserimento vocale: ora gli utenti potevano rispondere alle domande della valutazione parlando invece di digitare, aprendo così la possibilità di uno stile di risposta più conversazionale e più difficile da manipolare rispetto a un campo di testo.
Utilizzava ChatGPT per generare risposte sintetiche di prova ("Sono un selezionatore junior, forte in questo e debole in quello, dammi delle risposte"), per poi passare a Lovable, inserire quelle risposte e osservare come lo strumento le valutava.
Il pannello di controllo per i responsabili era l'altra metà della logica dello strumento: la vista che un direttore TA o un CHRO avrebbe utilizzato per vedere il punteggio ottenuto da un candidato, individuare le lacune e capire come le sue capacità potessero integrare i punti di forza e le esigenze di una squadra esistente.
Questo rendeva la struttura organizzativa un problema concreto, perché lo strumento doveva sapere chi stava valutando chi e chi aveva l'autorità per vedere i risultati.
Satterfield aveva provato a gestire la situazione chiedendo agli utenti di inserire il proprio nome, il titolo professionale e il nome del proprio responsabile (in assenza di un'integrazione dei dati). Ma questa logica non funzionava in uno scenario comune: quello di un direttore dell'acquisizione dei talenti che voleva inviare la valutazione a un'organizzazione di reclutamento più ampia, che comprendeva sia rapporti gerarchici diretti sia indiretti. La logica di mappatura dell'organizzazione non era abbastanza sfumata da tenere conto di quella struttura.
In teoria, queste informazioni avrebbero fornito allo strumento un contesto più ampio sul ruolo della persona che effettuava la valutazione, ma raccogliere più dati rendeva le cose più complicate.
Turnmeyer aveva già risolto una versione di questo problema in un contesto diverso. Lo strumento per la gestione delle prestazioni che aveva creato per la propria azienda funzionava con Google Sheets, Slack e Claude. Google Sheets conservava i dati. Slack era l'interfaccia con cui interagivano i dipendenti. Claude gestiva l'analisi e la generazione dei riscontri.
L'architettura era più semplice di quanto sembrasse: un foglio di calcolo con nome, e-mail, livello professionale e titolo professionale. Una scheda separata che metteva in relazione i livelli professionali con le competenze.
"Il reparto sicurezza della mia azienda voleva esaminare il mio strumento", raccontò al gruppo. "Dissi che era archiviato in Google Docs. Mi risposero: 'Oh, è così semplice.'"
Semplice, ma Turnmeyer lo aveva scoperto solo costruendolo. Ciò che non sapeva tre settimane prima era che esisteva la registrazione dei progressi: una funzione che salva i progressi dell'utente, così lo strumento non si reimposta quando qualcuno si allontana e poi ritorna.
"Me la prendevo con Claude", disse, "finché non mi ha detto che esisteva la registrazione dei progressi.
È questo che insegna davvero il processo di costruzione. Non ciò che avevi programmato di imparare, ma ciò che non sapevi di dover conoscere.
La domanda sottostante
A un certo punto della sessione di gennaio, la conversazione arrivò alla domanda attorno alla quale ruotava da mesi.
Il gruppo continuava a discutere di architettura, autorizzazioni, archiviazione e pannelli di controllo: erano tutti problemi reali. Ma sotto di essi ce n'era uno più fondamentale. Che cosa stavano effettivamente cercando di costruire e per chi?
Lo strumento, così come era stato concepito inizialmente, era uno strumento diagnostico per la selezione: qualcosa che un responsabile TA poteva inviare a un candidato o a un dipendente interno per valutare se le sue capacità effettive corrispondessero a quanto riportato nel curriculum e portare alla luce questo quadro prima di prendere una decisione di selezione.
Qui vedete una selezione di schermate del tipo di rapporto prodotto dallo strumento per la persona intervistata. Per il valutatore, un pannello di controllo degli attuali punti di forza della squadra lo aiuta a concentrarsi sugli aspetti da valutare della persona intervistata, per verificare se questa possa compensare le debolezze della squadra TA.
Quell'elemento centrale non era cambiato. Ma ogni decisione pratica che stavano prendendo, dall'aggiunta di un pannello di controllo per i responsabili alla riflessione sui modelli di abbonamento, fino alla definizione di un flusso di accesso, li spingeva verso qualcosa di più complesso.
I pannelli di controllo in tempo reale implicavano un accesso continuativo, che a sua volta comportava costi di abbonamento e li avvicinava sempre più al tipo di strumenti aziendali che molte organizzazioni faticano a permettersi o a rendere operativi in modo efficace.
"Non stiamo cercando di diventare un fornitore di sistemi HCM", disse Satterfield.
Turnmeyer fu sincera riguardo alla propria posizione.
"La mia intenzione era semplicemente imparare qualcosa di nuovo."
Non era un passo indietro rispetto al progetto. Era un resoconto accurato di ciò che l'esperimento aveva già prodotto per lei. Aveva imparato alcune cose nuove e stava già costruendo un nuovo strumento per la gestione delle prestazioni, applicando gli insegnamenti acquisiti durante il percorso.
Non aveva bisogno di trasformare in prodotto lo strumento del gruppo per ricavarne un valore concreto.
A questo punto, il mio interesse era principalmente editoriale. Volevo una storia da raccontare e qualcosa che le persone potessero vedere, non un prodotto in abbonamento, ma una dimostrazione del fatto che i professionisti delle risorse umane potessero riflettere su un'idea del genere e magari costruirne una simile.
Scrivere questo articolo ne faceva parte. Avrei potuto realizzare una guida scaricabile? E, in seguito, organizzare un evento dal vivo in cui il gruppo potesse discutere di ciò che aveva fatto, consentire al pubblico di interagire con lo strumento e registrare la conversazione come podcast? Avevo molte idee, ma il tempo a disposizione per realizzarle, mentre gli obiettivi del nuovo anno si accumulavano davanti a tutti noi, si stava riducendo.
L'interesse di Satterfield era quello più orientato al commercio e lei lo dichiarava apertamente. Le interessava trasformare lo strumento in un prodotto, prima o poi. Non lo avrebbe fatto da sola. Ma era disposta a continuare a costruire qualcosa che un giorno avrebbe potuto essere venduto.
Questa divergenza a tre vie delle intenzioni—apprendimento, narrazione, prodotto—è probabilmente intrinseca a qualsiasi gruppo di questo tipo. La conversazione sincera al riguardo, a gennaio, è stata più utile che fingere che tutti avessero sempre desiderato la stessa cosa.
La demo come risposta
La questione di come permettere alle persone di provare lo strumento era rimasta irrisolta da quando era stato attivato il caricamento del curriculum. Testare con utenti reali è utile, ma crea problemi propri. Lo strumento deve funzionare in modo coerente, gli utenti devono avere abbastanza contesto per sapere cosa stanno facendo e una prima esperienza negativa è difficile da recuperare.
Turnmeyer propose la soluzione più semplice che il gruppo avesse preso in considerazione.
Aveva iniziato a guardare delle registrazioni di demo—brevi presentazioni guidate, della durata di uno o due minuti, che mostravano come funzionava uno strumento senza richiedere allo spettatore di utilizzarlo davvero. Suggerì che forse sarebbe bastato. Le persone avrebbero potuto vedere lo strumento in azione, capire cosa stava facendo e perché, e andarsene con la sensazione che fosse possibile.
Non avrebbero dovuto gestire un accesso, fornire un organigramma o rimanere bloccate quando una domanda della valutazione non corrispondeva alla loro situazione.
Il feedback che ricevo da molti dei blog che scrivo è che le persone non vogliono davvero copiare e incollare esattamente la stessa cosa. Vogliono solo sapere di essere in grado di farlo.
Erin Turnmeyer · Vicepresidente delle operazioni del personale
Questa osservazione evidenzia qualcosa di concreto sul modo in cui i professionisti delle risorse umane si stanno rapportando agli strumenti di AI in questo momento. Il divario che molti di loro stanno affrontando non è tra sapere che qualcosa esiste e utilizzarlo. È tra il credere di essere capaci di fare qualcosa del genere e il non crederlo affatto.
Una demo che mostra professionisti intenti a costruire il proprio strumento risponde a una domanda diversa rispetto a un prodotto finito: non «questo strumento è valido?», ma «qualcuno come me avrebbe potuto realizzarlo?»
L'idea fu accolta positivamente. Rispondeva alle preoccupazioni relative ai test, riduceva la complessità della condivisione di qualcosa che non era pronto per la produzione e manteneva l'attenzione là dove il gruppo aveva sempre inteso porla: sul processo e sul ragionamento, non soltanto sul risultato.
Cosa ha insegnato l'esperimento: una guida per chi costruisce strumenti per le risorse umane
- Partite dal problema, non dalla tecnologia. L'entusiasmo iniziale del gruppo per l'analisi del sentiment era sincero, ma li ha allontanati da un problema più gestibile e più utile. Il passaggio alla mappatura delle competenze ha funzionato perché è partito da un caso d'uso reale, già testato sul campo.
- Su misura è meglio che generico. Ogni partecipante aveva incontrato i limiti delle piattaforme aziendali per le risorse umane. Gli strumenti costruiti per contesti specifici—il suggeritore di benefit di Turnmeyer, la mappa di calore di Satterfield—hanno superato le alternative pronte all'uso. Il motivo per costruire il proprio strumento è più forte che mai e le barriere sono più basse.
- Il controllo incrociato è il punto centrale. Le autovalutazioni sono valide solo quanto la conoscenza che le persone hanno di sé, notoriamente poco affidabile. Il vero valore di uno strumento risiede nella sua capacità di sondare, mettere in discussione e ricalibrare con delicatezza, non semplicemente di registrare ciò che le persone pensano di sé.
- Minimo valore, non minimo funzionamento. Se la prima versione non offre qualcosa che faccia venire voglia all'utente di tornare, la roadmap non conta. Progettate pensando alla prima impressione, non alla quinta.
- Il consenso è strutturale, non secondario. La questione se sia l'AI a produrre la valutazione finale o se debba confermarla l'utente non è un dettaglio dell'esperienza utente. Determina se lo strumento sia un'autorità o un collaboratore, e questa distinzione influenza tutto ciò che riguarda il modo in cui viene accolto e utilizzato.
- Eliminate le funzionalità che avete già costruito. La logica dei costi irrecuperabili spinge i team ad aggiungere elementi a progetti in cui hanno investito, molto tempo dopo che quegli elementi hanno smesso di meritare il loro posto. Se non riuscite a spiegare a cosa serva una funzionalità, questa è già la vostra risposta. Eliminarla è disciplina di prodotto, non un fallimento.
- Testate in modo avversariale e presto. Trovate persone che vi diranno che lo strumento non è valido. Fornitegli il peggior input ragionevole che riuscite a immaginare e osservate cosa fa. Costruite i casi limite prima di perfezionare quelli tipici. La credibilità dello strumento dipende da come gestisce i momenti per i quali non era stato progettato.
- Lo strumento deve guadagnarsi il diritto di valutare. Passare a una valutazione prima di aver posto un numero sufficiente di domande è presunzione, non efficienza. Le domande di chiarimento sono ciò che rende la valutazione difendibile, e la difendibilità è ciò che fa sì che il feedback venga recepito.
- Siate onesti sul motivo per cui tutti sono lì. Le intenzioni divergenti all'interno di un gruppo non sono un problema da gestire: sono informazioni. Portarle sul tavolo fin dall'inizio evita a tutti di lavorare verso un obiettivo che solo alcuni condividono davvero.
- Le conversazioni più difficili sono le più importanti. Il gruppo ha costruito uno strumento per valutare le competenze nelle risorse umane e, così facendo, ha avuto una delle conversazioni più sincere sui limiti delle risorse umane che ciascuno di loro riuscisse a ricordare. Quella conversazione—sui modelli orientati al passato, sul divario tra la conoscenza acquisita negli esami e il giudizio situazionale—era parte integrante del prodotto tanto quanto lo strumento.
Le sessioni iniziate come un impegno di quattro chiamate si protrassero per tutto l'inverno, fino al nuovo anno. Il prototipo continuava a evolversi. Le intenzioni delle persone che lo avevano costruito si erano chiarite in modi che non si risolvevano facilmente.
Satterfield stava ancora costruendo. Turnmeyer aveva preso ciò che aveva imparato e lo aveva applicato altrove. Gillies aveva spinto il gruppo a essere più disciplinato riguardo a ciò che lo strumento avrebbe dovuto effettivamente fare. Io stavo scrivendo la storia di tutto questo.
Turnmeyer aveva detto qualcosa all'inizio del processo che si è rivelato ancora vero: stava costruendo non perché glielo avessero chiesto, ma perché aveva bisogno di capire.
Quella comprensione di ciò che gli strumenti di IA fanno davvero, degli errori che commettono e di ciò che serve per renderli utili, non era disponibile in nessuna sessione di conferenza né in alcuna dimostrazione di un fornitore. Derivava dalle decisioni prese dal gruppo, dalle funzionalità eliminate e dai momenti in cui lo strumento valutava qualcuno in modo errato e loro dovevano capire perché.
Le cose più utili prodotte dal gruppo non erano nel prototipo. Erano nel ragionamento che lo sosteneva.
