Regole di disponibilità che reggono l'urto di una settimana vera
Quasi tutti i bug di disponibilità nascono da un solo errore: memorizzare "la sala non è disponibile" senza memorizzare il perché. È la ragione a determinare come si comporterà la regola la settimana prossima.
Tre tipi di "non disponibile"
Uno spazio chiude una risorsa per ragioni che in un calendario sembrano identiche e che nel tempo si comportano in modo completamente diverso.
- Orari di apertura. Lo spazio chiude alle 21:00. È una proprietà del workspace, vale per tutto ciò che contiene e cambia raramente.
- Una chiusura una tantum. La sala riunioni viene ridipinta da giovedì a venerdì. Ha istanti di inizio e fine reali, non si ripeterà mai e deve sparire da sola.
- Un blocco ricorrente. La sala grande è uno studio di yoga ogni martedì dalle 18:00. Non ha data di fine, si ripete per regola e deve valere per una prenotazione tentata fra tre mesi.
Se le comprimi in un'unica tabella di "periodi bloccati", o generi migliaia di righe per rappresentare il caso ricorrente, o perdi del tutto la ricorrenza nel momento in cui qualcuno prenota oltre l'orizzonte che avevi pre-generato.
Valutale separatamente, al momento della richiesta
L'approccio che regge è tenere i blocchi una tantum come intervalli concreti e quelli ricorrenti come regole, e poi controllare entrambi quando si tenta una prenotazione. Boris fa esattamente questo: un blocco per intervallo di date viene testato come sovrapposizione, un blocco ricorrente viene espanso sulla finestra richiesta, e ciascuno dei due rifiuta la prenotazione con il proprio messaggio.
Due messaggi distinti, non uno. "La sala è bloccata in quelle date" e "la sala non è disponibile a quell'ora" indirizzano il membro verso soluzioni diverse: il primo lo invita a scegliere un altro giorno, il secondo un altro orario. Un unico rifiuto generico lo costringe a tirare a indovinare.

I blocchi non sono prenotazioni, e la differenza conta
È tentante implementare una chiusura come una finta prenotazione intestata alla casa. Funziona finché non funziona più. Una prenotazione-blocco compare nei report di occupazione e li gonfia. Appare negli export di fatturato come uno zero. Può essere annullata da chiunque abbia il permesso di annullare prenotazioni. E su una risorsa a posti consuma capienza nell'unità sbagliata: una sala chiusa per manutenzione non è "dodici posti venduti".
Tenere i blocchi in un modello proprio costa un controllo in più nel percorso di disponibilità e ti risparmia tutti questi problemi.
Regole che tutti dimenticano finché un membro non protesta
Durata minima e massima. Una sala prenotabile a incrementi di cinque minuti verrà prenotata a incrementi di cinque minuti, e il tuo calendario diventerà illeggibile. Una sala prenotabile per dodici ore resterà occupata tutto il giorno da chi aveva bisogno di novanta minuti.
Quanto in anticipo. Senza un orizzonte, qualcuno prenoterà la sala del consiglio per una data dell'anno prossimo, e tu onorerai un prezzo fissato oggi. Senza un preavviso minimo, qualcuno prenota una sala pulita e pronta quattro minuti prima di entrarci.
Tempo di riassetto. Se fra una riunione e l'altra servono dieci minuti, il controllo di disponibilità deve saperlo, altrimenti il calendario sembrerà corretto mentre la sala è cronicamente in ritardo.
A chi si applica la regola. I membri con un piano che include ore di sala e i visitatori occasionali che pagano a ore non sono soggetti agli stessi limiti, ed è qui che di solito un modello di disponibilità semplice smette di bastare.
Ordina i controlli secondo la risposta che danno
Quando una prenotazione viene rifiutata, al membro va detta la ragione più utile ad agire. Controlla prima i vincoli assoluti ed economici — lo spazio è aperto, la risorsa è bloccata — e solo dopo quelli costosi che richiedono di contare le prenotazioni esistenti. È più veloce, e soprattutto il messaggio che produce è più utile: "a quell'ora siamo chiusi" è una risposta migliore di "capienza esaurita", anche quando sono vere entrambe.
