Una comanda non può sparire

Immaginate un tavolo che ordina due piatti e due cocktail. Chi è in sala invia la comanda. La stampante in cucina risponde. Quella del bar resta in silenzio. Se il gestionale mostra soltanto «Inviata», chi serve il tavolo scoprirà il problema dal cliente. Se mostra soltanto «Errore», rischia di far ripartire anche i piatti. In entrambi i casi l’interfaccia ha nascosto l’informazione che serviva per decidere.

La comanda esprime cosa ha chiesto il tavolo. La consegna indica che cosa è arrivato a ciascun reparto. Sono due informazioni diverse. Nello scenario, il tavolo deve conservare tutte e quattro le voci, mentre la schermata distingue cucina e bar. Anche gli stati devono avere un significato preciso. «In attesa» indica che manca una conferma. «Fallita» indica che c’è un errore rilevato. Un timeout, da solo, non dice se la stampante abbia già stampato.

Se chi è in sala sceglie di riprovare, l’azione deve riguardare il bar. Va chiarito anche che cosa può garantire il sistema. Se il dispositivo non conferma la stampa, ripetere una richiesta può produrre due copie. Il gestionale può riconoscere un tentativo già registrato, ma non può dedurre da questo se sia uscito un foglio. Nei casi dubbi, la schermata deve rendere evidente l’incertezza e dare all’operatore un modo per verificarla.

Aprite un tavolo di prova, inviate piatti e cocktail a due reparti e interrompete la risposta della stampante del bar. Verificate che il tavolo conservi tutte le voci, che la cucina risulti separata e che si possa intervenire sul bar senza coinvolgere la cucina. Poi provate il caso più insidioso: la stampa riesce, ma la conferma non torna. Se per capire cosa fare serve chiamare chi ha scritto il software, il flusso è ancora da progettare.