App come Asana: cosa cercare oltre le liste di attività

Perché i team iniziano a cercare app come Asana

Asana fa bene ciò per cui è stato progettato. Dà al team un luogo condiviso per attività, assegnazioni, commenti e file, si impara in fretta e le persone lo usano davvero, il che è un’asticella più alta di quella che supera la maggior parte del software. Quando i team iniziano a cercare alternative, l’innesco è raramente un difetto. È un cambiamento in ciò che devono gestire: un team che coordinava campagne ora consegna un’implementazione per un cliente con un valore contrattuale, oppure un’azienda che portava avanti quattro progetti alla volta ora ne porta trenta. Le attività non sono diventate più difficili; la responsabilità sì.

Il punto in cui un sistema di gestione dei progetti diventa indispensabile merita di essere nominato con precisione, perché determina il tipo di strumento che dovresti cercare. Qualcuno ora chiede quando finirà il progetto, quanto resta del budget e se le persone necessarie a marzo saranno disponibili a marzo. Se la tua risposta è «ci serve più ordine nelle attività», il mercato delle alternative ad Asana è ampio e in gran parte intercambiabile. Se è «dobbiamo gestire progetti, non attività», la maggior parte di quel mercato non ti riguarda affatto.

Dove una lista di attività smette di essere un piano

Una lista di attività contiene date. Un piano contiene relazioni tra le date. La differenza è invisibile finché nulla cambia, e totale non appena tutto cambia. Quando un fornitore conferma due settimane più tardi del previsto, una lista di attività ti lascia modificare quell’unica scadenza; ogni attività che ne dipendeva mantiene la sua data originale e il piano è ora silenziosamente sbagliato. Qualcuno deve accorgersene, ragionare sugli effetti a cascata e modificare a mano altre quindici date.

I sintomi sono riconoscibili: lo stato ricostruito a memoria nella riunione settimanale invece che letto dal piano, un cronoprogramma tenuto in un foglio di calcolo accanto allo strumento di attività, nessuno in grado di dire quale ritardo minacci davvero la data, e sforamenti di budget scoperti da una fattura anziché previsti da una previsione. Nulla di tutto ciò è mancanza di disciplina. È uno strumento costruito per rispondere a «chi fa cosa» a cui si chiede di rispondere a «ce la faremo, e a quale costo».

Tre classi di strumenti dietro la stessa ricerca

Quasi ogni elenco di strumenti come Asana mescola tre classi di software senza dirlo, ed è per questo che i lettori ne escono più confusi di quando sono entrati.

• App di attività e di to-do organizzano il lavoro personale e dei piccoli team: liste, board, promemoria, una vista condivisa. Non modellano dipendenze, budget o capacità, e non ci provano.
• Piattaforme di gestione del lavoro sono dove si colloca Asana stesso. Aggiungono più viste, campi personalizzati, automazioni, obiettivi e reporting tra team. Il loro livello di pianificazione è di solito una timeline: date trascinabili, con una logica di dipendenze limitata o opzionale.
• Sistemi di gestione di progetti e portafogli sono costruiti attorno al progetto come oggetto dotato di cronoprogramma, budget, rischi, risorse, deliverable e storico delle approvazioni. Il baricentro è il piano e la sua esecuzione rispetto a quel piano.

Il sistema di gestione dei progetti FlexiProject appartiene alla terza classe. È il posizionamento onesto: se il tuo problema è una board di attività sovraffollata, è la risposta sbagliata. Diventa la risposta giusta nel punto in cui piano, denaro e persone devono essere gestiti come un unico oggetto anziché tre fogli di calcolo. Un confronto capacità per capacità nel confronto tra FlexiProject e Asana copre lo stesso terreno per questo singolo strumento.

Otto capacità che separano le app simili ad Asana

Togli il marketing dai confronti tra strumenti e le differenze che contano in pratica si riducono a otto capacità. Ciascuna è presente come modulo reale oppure assente, e nessuna quantità di campi personalizzati sostituisce quelle che mancano.

Il resto dell’articolo prende queste righe una per una, perché la tabella dice cosa esiste, non perché conta. A parte spieghiamo come affrontare la pianificazione dei progetti che il sistema mantiene da sé.

Un cronoprogramma che si ricalcola da solo quando le date cambiano

In una piattaforma di gestione del lavoro, una timeline è una visualizzazione di date che sei tu a mantenere. In un sistema di progetto, il cronoprogramma è un modello: descrivi come è strutturato il lavoro e come le parti dipendono l’una dall’altra, e il modello ti dice quali sono le date. Questa distinzione diventa concreta la prima volta che interviene la realtà. Un’attività chiave slitta di cinque giorni; in un cronoprogramma basato su modello, tutto ciò che segue si sposta automaticamente, il percorso critico viene ricalcolato e vedi subito se la data finale si è mossa o se il margine ha assorbito il ritardo. Il compito del project manager diventa decidere cosa fare, non capire cosa significa.

Una WBS illimitata al posto di una lista piatta di attività

I progetti di una stessa organizzazione differiscono enormemente per scala. Un miglioramento di processo dura sei settimane con una dozzina di attività; un investimento in uno stabilimento dura tre anni con diverse centinaia, raggruppate in fasi e tappe. Uno strumento che limita la profondità di annidamento costringe a spezzare il progetto più grande in vari «progetti» artificiali perché entri, e da lì il reporting è sbagliato, perché nessun oggetto singolo rappresenta l’iniziativa reale.

Il modulo di cronoprogramma del progetto di FlexiProject non ha limiti di profondità di annidamento, così un Quick Win può restare piatto mentre un investimento pluriennale porta una struttura di scomposizione del lavoro completa, entrambi nella stessa interfaccia ed entrambi che confluiscono nello stesso portafoglio. Lo stesso cronoprogramma è disponibile in tre viste che condividono un unico set di dati: una lista di attività per il dettaglio, il diagramma di Gantt in FlexiProject per il lavoro sulle dipendenze e una board Kanban per seguire l’avanzamento. Questo conta per l’adozione, perché il project manager può lavorare nella vista strutturata mentre il team resta sulla board che gli è familiare, senza che nessuno mantenga una seconda copia della verità.

Dipendenze, ritardo e percorso critico

Saper tracciare una linea tra due attività non è la stessa cosa che saper esprimere di quale relazione si tratti. FlexiProject supporta i quattro tipi di relazione standard, così puoi dire che il test inizia quando finisce lo sviluppo, che due flussi di lavoro iniziano insieme, che devono finire insieme, o il caso più raro in cui l’inizio di un’attività governa la fine di un’altra. Un ritardo fisso copre i giorni che devono semplicemente trascorrere e in cui nessuno lavora: la maturazione del calcestruzzo, un termine di consultazione imposto dalla legge, il tempo di consegna di un fornitore. Modellarli come un ritardo sulla relazione, e non come una falsa attività, mantiene il cronoprogramma onesto, perché il tempo di attesa si sposta con l’attività che lo precede. Le relazioni rigide impediscono che il collegamento si rompa per un trascinamento distratto, il che protegge le sequenze in cui l’ordine è un requisito tecnico o contrattuale.

Sopra questa struttura c’è il percorso critico. Risponde alla domanda che ogni comitato di controllo prima o poi pone: delle sei cose in ritardo, quali minacciano davvero la data. Senza questo calcolo, ogni ritardo sembra ugualmente allarmante e l’attenzione del management si distribuisce equamente tra problemi di importanza molto diversa. Il calendario di progetto sottostante gestisce i giorni non lavorativi e le assenze, così un’attività pianificata su cinque giorni lavorativi non consuma silenziosamente un fine settimana.

Avanzamento che si consolida verso l’alto e ritardi che vedi subito

Nella maggior parte degli strumenti di attività, la percentuale di completamento di una fase è qualcosa che una persona digita. Quel numero è una stima, è obsoleto nell’istante in cui viene inserito, ed è il numero che finisce nel report al comitato. FlexiProject chiede l’avanzamento solo a livello delle singole attività e calcola tappe, fasi e l’intero progetto a partire da esse, così i valori nelle viste di portafoglio e nei report sono coerenti per costruzione, non per disciplina.

Le attività in ritardo sono evidenziate in rosso direttamente nel cronoprogramma, così il project manager vede i punti che richiedono un intervento all’apertura del progetto, senza generare prima un report. Il divario tra l’insorgere di un problema e il momento in cui qualcuno se ne accorge è dove si accumula la maggior parte del danno al cronoprogramma, e ridurre quel divario da una settimana a un istante cambia ciò che è ancora recuperabile.

Una linea di base: il piano su cui ti si può davvero chiedere conto

Chiedi a un team senza linea di base se il progetto è in ritardo e otterrai una risposta ponderata, sincera e inconfutabile. Non è disonestà. È che il piano e la realtà sono stati lo stesso documento per tutto il tempo: ogni volta che una data si spostava, il piano si spostava con essa, così in qualsiasi momento il progetto è esattamente in linea con un cronoprogramma riscritto una dozzina di volte.

Una linea di base spezza questo ciclo. Una volta concordati cronoprogramma e budget, vengono approvati e congelati come punto di riferimento, e da lì il sistema segnala lo scostamento tra ciò a cui ci si è impegnati e ciò che accade. L’approvazione passa per un percorso definito in FlexiProject anziché per una firma su una stampa, così resta traccia di chi ha approvato quale versione e quando. Ciò che compri così è tempo: un progetto in ritardo di quattro giorni al secondo mese di un cronoprogramma di diciotto mesi è una conversazione, mentre lo stesso progetto scoperto in ritardo di sei settimane al sedicesimo mese è una crisi senza opzioni residue.

Un budget di progetto con previsione a finire

Un campo personalizzato chiamato «budget» su una scheda progetto non è gestione del budget; è un numero che qualcuno aggiorna di tanto in tanto e a cui, dal secondo mese, nessuno crede più. Gestire il budget di un progetto significa seguire gli importi pianificati, la spesa effettiva e il costo residuo atteso, a un livello di dettaglio che mostra da dove viene lo scostamento.

Costi, ricavi e il risultato del progetto

Il modulo di budget del progetto costruisce il budget da entrambi i lati, costi e ricavi, con voci raggruppate come serve all’organizzazione. Per i progetti che generano ricavi, il sistema mostra il risultato pianificato, lo scostamento dal piano e la previsione del risultato finanziario finale, non solo il lato spese. Per una società di servizi professionali o di ingegneria in cui ogni progetto è un contratto, è questo il numero su cui la direzione chiede davvero, e non si ricava da una somma di costi da sola.

Le voci di budget possono essere collegate dinamicamente alle attività del cronoprogramma, così quando cambia la data di un’attività, la data della voce di budget corrispondente cambia con essa e il flusso di cassa riflette sempre il piano attuale. Ogni voce può portare gli attributi che serve alla finanza, inclusi centro di costo, natura della spesa, categoria e fornitore, con le fatture allegate alla relativa riga. FlexiProject si integra inoltre con i sistemi contabili e importa le fatture legate al progetto con data, importo, numero di documento e fornitore, eliminando il doppio inserimento che altrimenti fa divergere i budget di progetto dalla contabilità.

Perché «quanto abbiamo speso» è la domanda sbagliata

La spesa effettiva descrive il passato. Quando mostra un problema, il denaro è già andato. La domanda che cambia le decisioni è quanto si spenderà ancora prima che il progetto finisca, e rispondervi richiede una previsione tenuta accanto al consuntivo.

FlexiProject mostra tre valori insieme per ogni riga di budget: il piano, l’importo speso finora e la previsione del costo residuo, con lo scostamento risultante. Un project manager che al terzo mese vede che la previsione supera il piano del dodici per cento ha delle opzioni: rinegoziare il perimetro, escalare presto, attingere a una riserva. Lo stesso manager che lavora solo con il consuntivo lo scopre all’ottavo mese, quando l’unica opzione rimasta è spiegarlo. La finanza può inoltre farsi progettare report nel taglio che le serve, per categoria, fornitore o periodo, sempre con dati aggiornati. A parte analizziamo che cos’è un vero controllo del budget di progetto.

Un registro dei rischi che funziona sopra un singolo progetto

In uno strumento di attività, un rischio diventa un’attività con un’etichetta, o un punto elenco in un documento di stato che nessuno rilegge. Un registro dei rischi è un altro oggetto: ogni voce ha una valutazione di probabilità e impatto, un responsabile, un piano di risposta e uno storico, e vive accanto al cronoprogramma anziché in un documento parallelo.

Il registro dei rischi di FlexiProject ti consente di configurare le dimensioni della matrice dei rischi durante l’implementazione. Sembra un’impostazione minore ed è spesso il motivo per cui un modulo di rischio resta inutilizzato: un’organizzazione che lavora da anni con una matrice tre per tre non adotterà un sistema che fissa cinque per cinque, così il modulo viene abbandonato in silenzio e la gestione dei rischi torna su una slide. I rischi ricorrenti sono gestiti tramite modelli, così un team che avvia una nuova implementazione non parte da un registro vuoto, ma da una base curata che adatta a questo progetto. Questo trasforma l’identificazione dei rischi da esercizio di immaginazione in una revisione dell’esperienza accumulata dall’organizzazione.

Sopra il singolo progetto, ogni portafoglio ha una propria scheda dei rischi che raccoglie in un solo posto i rischi di tutti i suoi progetti. Questo fa emergere qualcosa altrimenti invisibile: tre project manager gestiscono in modo indipendente lo stesso rischio fornitore, impiegano il triplo dello sforzo e arrivano a tre conclusioni diverse. Visto a livello di portafoglio, quel rischio riceve un responsabile e una risposta, e i report sui rischi permettono a un team che avvia un nuovo progetto di rivedere cosa ha davvero minacciato progetti simili in precedenza. Mostriamo inoltre come funziona la gestione dei rischi di progetto nella pratica.

Il carico delle risorse prima di impegnarti su una data

La domanda più difficile in un’organizzazione guidata dai progetti non è «cosa dobbiamo fare», ma «chi lo farà ed è libero». Le app di attività mostrano il carico come conteggio di assegnazioni, il che non dice quasi nulla, perché otto piccole attività e un’attività di tre settimane si somigliano e consumano porzioni del mese di una persona del tutto diverse.

FlexiProject lo affronta come software di gestione delle risorse: modella la disponibilità per persona e per giorno, tiene conto di ferie e assenze, e avvisa quando il carico pianificato supera la capacità disponibile. Questo evita la trappola nota in cui un esperto compare contemporaneamente nei piani di dieci progetti, ogni piano ragionevole preso singolarmente e la somma impossibile. Il carico è visibile direttamente dal diagramma di Gantt: mentre sposti le attività nel tempo, osservi il carico cambiare, il che rende la pianificazione una simulazione che esegui prima di approvare il piano anziché una scoperta che fai dopo.

Sopra il singolo progetto, l’organizzazione ottiene una vista di tutte le risorse di progetto nei mesi successivi, suddivisa per struttura organizzativa. Il PMO e la direzione vedono quando determinati team hanno capacità libera, il che trasforma due decisioni ricorrenti da istinto in aritmetica: se candidarsi al lavoro che sta arrivando sul tavolo e quando iniziare ad assumere.

Una carta del progetto e modelli che portano il tuo standard

La maggior parte delle organizzazioni che gestiscono progetti sul serio ha uno standard. Di solito vive in un modello Word, una presentazione e la testa di due persone esperte, il che significa che viene seguito quando quelle due sono coinvolte e improvvisato altrimenti. Uno strumento che porta lo standard è una proposta diversa da uno strumento che gli sta accanto.

Il modulo di carta del progetto di FlexiProject è assemblato a partire da componenti, senza alcuna programmazione, così il documento riflette la disposizione che l’organizzazione ha già affinato su centinaia di progetti, anziché un modello fisso di un fornitore. Puoi definire più di uno standard di carta: progetti di R&S con campi rilevanti per lo sviluppo, progetti di marketing con differenziatori di mercato e canali, progetti di investimento con campi di tecnologia e ritorno, mentre un insieme di campi a livello aziendale resta comune a tutti. È questo che permette alla standardizzazione di sopravvivere al contatto con la realtà, perché i reparti non sono costretti a un documento di compromesso che non va bene per nessuno.

Una parte importante della carta si compila da sola: milestone, rischi chiave e altri elementi vengono estratti automaticamente dal cronoprogramma e dal registro dei rischi, così la carta resta coerente con i dati sottostanti. Le carte sono versionate e approvate tramite percorsi di approvazione, e ogni versione approvata lascia traccia di chi l’ha approvata e quando. La stessa logica si estende ai modelli di progetto di FlexiProject, che impacchettano la struttura del cronoprogramma, i rischi tipici e le disposizioni dei documenti per tipo di progetto, così un nuovo progetto parte dalla pratica accumulata dell’organizzazione anziché da uno schermo vuoto.

Portafogli e programmi: la vista sopra un progetto

Quando un’organizzazione porta avanti trenta, cinquanta o cento progetti, le domande utili cambiano. Nessuno a livello direzionale vuole sapere cosa fa una persona specifica il giovedì. Vogliono sapere quali progetti stanno slittando, quali consumano più del previsto e se il portafoglio riflette ancora la strategia. Le dashboard che aggregano conteggi di attività non rispondono a nulla di tutto ciò.

Questo divario è colmato dal software di portafoglio progetti. FlexiProject fornisce una vista strategica dedicata: una roadmap dei progetti con milestone e loro stato, un confronto con il piano e l’avanzamento finanziario di ogni progetto e del portafoglio nel suo insieme. Un progetto può appartenere a più portafogli contemporaneamente, il che conta più di quanto sembri, perché un singolo investimento IT fa spesso parte al tempo stesso di un portafoglio tecnologico e di un programma di trasformazione. I programmi aggiungono il livello superiore: gruppi di progetti correlati con dipendenze che corrono tra loro, che è il punto di rottura della maggior parte delle consegne multi-team, perché ogni piano è coerente al suo interno mentre i passaggi di consegne sono gestiti via e-mail. Il punteggio dei progetti sostiene la decisione che precede tutto questo, e il modulo di revisioni dei progetti mantiene lo stato proveniente dal sistema anziché da un giro di solleciti. A parte spieghiamo che cosa deve offrire un’alternativa ad Asana per un PMO.

Licenze, lingue e dove risiedono i tuoi dati

Tre criteri compaiono raramente nei confronti di funzionalità e decidono regolarmente il risultato quando un’organizzazione supera il pilota.

Il primo è il modello di licenza. La maggior parte dei sistemi addebita una tariffa comparabile per ogni utente, così un’organizzazione paga una postazione intera per persone che aprono lo strumento per aggiornare le proprie attività e controllare uno stato. FlexiProject offre tre livelli adeguati al ruolo reale: una licenza completa per project manager, membri del PMO, sponsor e decisori; una licenza standard per i partecipanti attivi che riportano l’avanzamento e collaborano alle attività; e una licenza gratuita per chi ha bisogno solo di visibilità sul proprio lavoro. L’organizzazione decide il mix, il che mantiene il costo di coprire il team più ampio proporzionale al valore che quelle persone ne traggono.

Il secondo è la lingua. L’interfaccia di FlexiProject è disponibile in 28 lingue, tra cui inglese, tedesco, francese, spagnolo, italiano, olandese, polacco, ceco, slovacco, ungherese, rumeno, bulgaro, ucraino, svedese, danese, norvegese, finlandese, estone, lettone, lituano, sloveno, greco, portoghese, turco, russo, indonesiano, giapponese e cinese. La documentazione utente è disponibile in 11 lingue e i video di formazione in polacco e inglese. Per un gruppo con controllate in più paesi, è questo che permette uno standard e un sistema mentre ciascuno lavora nella propria lingua. Il terzo è il deployment: FlexiProject è disponibile on-premise accanto al cloud, il che per i settori regolamentati non è una preferenza ma una condizione per essere anche solo preso in considerazione.

Come testare app simili ad Asana senza sprecare un trimestre

I confronti di funzionalità hanno un cattivo curriculum come metodo di selezione, perché la pagina di ogni fornitore dice sì a tutto. Una prova di due settimane su un progetto reale risponde più di un mese di demo, a patto di essere impostata per testare le cose che davvero si differenziano. Metti nello strumento un progetto vivo, non uno di esempio: prendi un progetto già in corso, con il suo cronoprogramma, le sue persone e il suo budget reali, e ricostruiscilo. L’attrito che incontri durante questa ricostruzione è l’attrito che incontrerai ogni settimana dopo, e in pratica serve anche da formazione, perché chi impara il sistema sul proprio progetto ricorda più di chi svolge un esercizio su dati inventati.

Poi esegui i quattro test che separano le classi. Sposta un’attività a metà del cronoprogramma di una settimana e guarda cosa si ricalcola. Approva una linea di base, apporta una modifica e guarda se lo scostamento è visibile senza che nessuno lo calcoli. Inserisci il budget con una previsione a finire e verifica se lo scostamento è leggibile. Assegna due persone già occupate altrove e guarda se lo strumento ti avvisa. Se uno strumento supera questi quattro, il resto è questione di gusto; se li fallisce, nessuna quantità di campi personalizzati colmerà il divario.

Infine, sii deliberato su cosa porti con te. Una migrazione è l’unico momento in cui è economico lasciarsi alle spalle le categorie che nessuno usa e le convenzioni che erano espedienti per i limiti dello strumento precedente. Porta il lavoro aperto, la struttura che vuoi d’ora in avanti e i progetti storici da cui vale la pena imparare.

Domande frequenti

A cosa servono le app come Asana?

Le app come Asana servono a organizzare e seguire il lavoro di team in un luogo condiviso: attività, responsabili, date, commenti e file. Sono più forti nel lavoro collaborativo e ricorrente, come marketing, operations e supporto. Quando il lavoro ha un cronoprogramma con dipendenze, un budget e risorse assegnate, un sistema di gestione dei progetti si adatta meglio.

Qual è la differenza tra un’app di attività e un software di gestione dei progetti?

Un’app di attività memorizza elementi di lavoro e date. Un software di gestione dei progetti modella il progetto: ricalcola il cronoprogramma quando le date cambiano, confronta l’esecuzione con una linea di base approvata, segue costi e previsioni, tiene un registro dei rischi e gestisce la capacità delle risorse. Il test pratico è se spostare un’attività sposta automaticamente tutto ciò che ne dipende.

Asana ha una linea di base di progetto?

Asana non fornisce una linea di base di progetto approvata con tracciamento degli scostamenti. La sua timeline riflette lo stato attuale del piano, così quando le date cambiano, l’impegno originale non è più disponibile per il confronto. I sistemi di classe PPM, incluso FlexiProject, approvano e congelano una linea di base e poi segnalano lo scostamento tra essa e l’esecuzione reale.

Le app simili ad Asana possono gestire i budget di progetto?

La maggior parte non può, al di là di un campo personalizzato che contiene un numero. Gestire il budget di un progetto richiede importi pianificati, spesa effettiva e una previsione del costo residuo per riga, collegata al cronoprogramma perché le date restino coerenti. In FlexiProject il budget copre costi e ricavi e mostra piano, consuntivo e previsione a finire uno accanto all’altro.

Quando è troppo presto per lasciare Asana?

Se i tuoi progetti sono brevi, portati avanti con una manciata di persone, senza budget formale né impegni esterni sulle date, cambiare strumento aggiungerà processo senza aggiungere controllo. Il segnale del cambiamento è strutturale: dipendenze che non puoi esprimere, un budget tenuto in un foglio di calcolo a parte e riunioni di stato tenute per ricostruire informazioni che dovrebbero già essere nel sistema.

Quanto tempo ci vuole per far uscire un progetto da Asana?

Ricostruire un singolo progetto in corso in un nuovo sistema richiede di solito qualche ora per la struttura di cronoprogramma e budget, e un paio di giorni se si definiscono modelli e standard allo stesso tempo. Il rollout su un’organizzazione dipende meno dai dati che dalle decisioni: quale standard, quali modelli e chi approva cosa.

La ricerca di app come Asana comincia di solito come una questione di strumenti e si rivela una questione su cosa l’organizzazione gestisce davvero. Se la risposta è la collaborazione di team su un lavoro condiviso, il mercato è ben servito e le differenze tra le opzioni principali sono in gran parte questioni di interfaccia e prezzo. Se la risposta è progetti con impegni collegati, le capacità rilevanti non sono quelle che compaiono nelle pagine di confronto: un cronoprogramma che si ricalcola da solo, una linea di base approvata che rende visibile il ritardo finché è ancora piccolo, un budget con previsione anziché una somma di spese, un registro dei rischi che funziona sopra il livello di un progetto e una capacità delle risorse che puoi verificare prima di promettere una data. FlexiProject è costruito attorno a queste cose, il che lo rende la scelta sbagliata per un team che ha bisogno di una board di attività più ordinata, e quella giusta per un’organizzazione che deve rispondere di date e denaro. Il modo più affidabile per sapere chi sei non è una tabella di funzionalità, ma due settimane: prendi un progetto reale, ricostruiscilo, sposta un’attività e guarda cosa ti dice lo strumento.