Ticketing per software house: clienti e progetti

Chi sviluppa software ha un problema che chi presta assistenza e basta non ha: le richieste arrivano da più clienti, ma parlano di prodotti che sono vostri. «Non funziona l'export» detto da tre clienti diversi può essere un caso di configurazione, un difetto che riguarda tutti, o due cose diverse con lo stesso nome — e il modo in cui avete diviso le richieste decide se ve ne accorgete o no.

Questa guida riguarda quella divisione: quali assi esistono, quale conviene scegliere per primo, chi deve vedere che cosa e dove finisce l'assistenza e comincia lo sviluppo. Vale con qualunque strumento, anche con una tabella condivisa.

Clienti e prodotti sono due assi, non uno

La prima cosa che si scopre organizzando le richieste di una software house è che gli assi sono due e che si incrociano. Un cliente usa tre vostri prodotti; un vostro prodotto è usato da trenta clienti. Qualunque struttura che ne riconosca uno solo vi costringerà a cercare l'altro a mano.

Le due domande che vi fanno, e a cui dovete poter rispondere in pochi secondi, sono esattamente una per asse:

• Per cliente. «Quante richieste aperte ha questo cliente, da quanto aspettano, e che cosa gli abbiamo risposto l'ultima volta?» È la domanda che arriva prima di un rinnovo o dopo una lamentela.
• Per prodotto. «Quante volte ci hanno segnalato questa cosa, e da quando?» È la domanda che decide che cosa entra nella prossima versione, ed è quella che si perde per prima se avete diviso solo per cliente.

Il punto non è avere due strutture: è avere un asse che divide e un secondo che filtra. Sceglierne uno come divisione principale e l'altro come attributo delle richieste risolve il novanta per cento dei casi; provare a tenerli entrambi come divisione produce venti contenitori vuoti e nessuno sa dove mettere la richiesta nuova.

Come dividere: per cliente, per prodotto o per contratto

Le tre divisioni che si vedono in giro reggono tutte, ma in situazioni diverse.

• Per cliente quando i clienti sono pochi e grandi, e ognuno ha un contratto, referenti e tempi propri. È la divisione che rende semplice rispondere «che cosa abbiamo fatto per voi quest'anno», ed è quasi obbligata se l'assistenza è fatturata a parte.
• Per prodotto quando lo stesso applicativo è usato da molti clienti e le richieste si somigliano. Chi risponde è specializzato sul prodotto e non sul cliente, e i doppioni si notano il giorno stesso.
• Per contratto o per fase — avviamento, manutenzione, progetti su misura — quando la stessa azienda vi scrive per cose di natura molto diversa, che finiscono a persone diverse e hanno urgenze diverse.

La regola pratica: dividete per quello che cambia chi risponde. Se a decidere il destinatario è il prodotto, dividete per prodotto; se è il cliente, dividete per cliente. Tutto il resto è un filtro.

Chi vede che cosa, e perché conta più di quanto sembri

In una software house la visibilità smette di essere una questione di ordine il giorno in cui entra la prima persona che non è dipendente: un collaboratore esterno, un fornitore che lavora su un modulo, uno stagista. Da quel momento «chi vede che cosa» è un impegno che avete preso con i vostri clienti, spesso per iscritto.

Le domande da farsi sono tre, e conviene rispondere prima di avere il problema.

1. Il collaboratore esterno vede gli altri clienti? Se la risposta è «no, ma dipende dall'interfaccia», la risposta vera è sì. Il limite deve valere nell'elenco, nella ricerca, negli avvisi e in qualunque API.
2. Quello che vi dite fra voi è separato da quello che legge il cliente? «Questo è il difetto della 2.4, lo sappiamo da marzo» è una frase che deve esistere nella richiesta e che il cliente non deve leggere.
3. Che cosa succede quando qualcuno se ne va? Le richieste che aveva in mano devono restare, e il suo accesso deve chiudersi nello stesso momento. Sono due cose distinte e vanno verificate distintamente.

Assistenza e sviluppo non sono lo stesso elenco

È l'errore che una software house fa per primo, perché sembra un risparmio: usare lo stesso strumento per le richieste dei clienti e per il lavoro di sviluppo. Dopo qualche mese l'elenco contiene «non riesco ad accedere» accanto a «rifattorizzare il modulo pagamenti», e non serve più a nessuno dei due scopi.

I due elenchi hanno tempi diversi (uno è misurato in ore, l'altro in versioni), destinatari diversi (uno risponde a una persona che aspetta, l'altro a una pianificazione) e un ciclo di vita diverso: una richiesta di assistenza si chiude quando il cliente è servito, anche se il difetto sotto resta aperto per due mesi.

Il collegamento fra i due, quando serve, è una riga scritta a mano nella richiesta: il riferimento all'attività di sviluppo che la riguarda. È meno elegante di un'integrazione, e in compenso non si rompe e non obbliga i clienti a entrare nello strumento con cui pianificate il lavoro — che è la cosa da evitare per prima.

Codici e storico: quello che si cita sei mesi dopo

Due dettagli che sembrano minori e che sono esattamente ciò che distingue un'assistenza che regge nel tempo.

Il primo è il codice leggibile. Una richiesta deve avere un riferimento che si possa dire al telefono senza sillabare, che porti dentro di sé l'indicazione del cliente o del prodotto e che non venga mai riassegnato a qualcos'altro. Un codice citato in una nota di rilascio o in una email di un anno fa deve continuare a indicare quella richiesta.

Il secondo è che lo storico non appartiene a chi l'ha scritto. La conversazione con il cliente, le note interne, i cambi di responsabile e la data di chiusura devono restare leggibili anche quando la persona che seguiva quel cliente non lavora più con voi. È il motivo tecnico per cui l'assistenza via email non regge: là lo storico sta in una casella, e la casella è di qualcuno.

Quando serve un prodotto più grande

Non tutto quello che una software house desidera lo fa un sistema di ticketing, e conviene sapere in anticipo quali richieste portano fuori da questa categoria di strumenti.

• Collegamento con il repository — commit, rami, versioni, rilasci — o sincronizzazione a due vie con la board di sviluppo: è il territorio degli strumenti per lo sviluppo, non di quelli per l'assistenza.
• Campi propri sulla richiesta, come ambiente, versione o modulo, trattati come dati su cui filtrare e non come testo nella descrizione.
• Regole automatiche che smistino, riassegnino o chiudano da sole in base a condizioni.
• Email in ingresso, cioè richieste che nascono da messaggi inviati a una casella già in uso, e più canali insieme — telefono, chat, social.
• Rendicontazione delle ore per fatturare a consuntivo dalla richiesta.

Ognuna di queste è un motivo legittimo per scegliere un prodotto più grande, e ogni prodotto più grande chiede in cambio configurazione, formazione e un costo per persona più alto. La domanda onesta da farsi è quante di quelle voci vi servono davvero oggi.

Come si traduce in OglutTicket

In OglutTicket la divisione si chiama progetto, ed è l'unica: un progetto per cliente, oppure uno per prodotto, e le due scelte convivono nello stesso ambiente. Il secondo asse è dato dal prodotto e dal reparto collegati al progetto, che sono i criteri con cui poi si filtra senza costruire viste.

Dal progetto discendono le cose descritte sopra: il prefisso leggibile e i numeri che non vengono mai ricalcolati, le persone abilitate — chi non è abilitato non vede quei ticket perché la query non glieli restituisce, non perché la pagina li nasconde — i clienti associati, e i tempi di risposta se decidete di accenderli. Le note interne sono escluse dal server prima di comporre la pagina del cliente, e togliendo un'abilitazione le assegnazioni aperte di quella persona su quel progetto si azzerano.

I limiti sono quelli dell'elenco qui sopra, e sono dichiarati: nessun collegamento con il repository, nessun campo personalizzato, nessuna regola automatica, nessuna email in ingresso e nessuna rendicontazione delle ore. Non è un sistema per tracciare i difetti del vostro software: raccoglie quello che arriva da fuori.

La pagina che entra nel merito, con le catture e le condizioni, è il ticketing per software house. Se il punto che vi interessa è come far arrivare ogni richiesta a una persona, c'è la guida sull'assegnazione; se invece assistete più aziende che usano software non vostro, quella giusta è sui requisiti di un help desk multicliente.