Wat er aan de bar gebeurt, bepaalt de kassa
Bij een winkelkassa is de volgorde meestal overzichtelijk: producten aanslaan, betalen, klaar. Aan een verenigingsbar loopt dat anders. Iemand bestelt een rondje, laat de rekening openstaan en rekent later op de avond af. Een ander gebruikt een tegoedbon. Ondertussen neemt een volgende vrijwilliger de bardienst over.
Dat zijn voor ClubSolution Kassa geen uitzonderingen. Het zijn handelingen waar het systeem vanaf het begin rekening mee moet houden.
Begin bij een open rekening
Als je een gewone winkelkassa als uitgangspunt neemt, wordt een open rekening al snel iets dat je er later bij bouwt. Met extra schermen en regels om dat alsnog te laten passen.
Ik begin liever met de vragen die aan de bar ontstaan. Van wie is deze rekening? Wie mag er iets op zetten? Wat gebeurt er als iemand vertrekt zonder af te rekenen? En hoe herstel je een fout zonder kwijt te raken wat er eerder is gebeurd?
De antwoorden bepalen welke gegevens je bewaart en wat iemand op het scherm nodig heeft.
Een ander project, dezelfde vraag
Bij ExitLane speelt iets vergelijkbaars. Een VPN-app op één laptop hoeft niet te laten zien wat er met een heel netwerk gebeurt. Een gateway wel. Als een verbinding uitvalt, wil je kunnen zien wat dat betekent voor het verkeer dat erdoorheen ging.
Daarom kijk ik niet alleen naar de instelling die je kunt aanpassen, maar ook naar wat er daarna gebeurt. Vooral wanneer iets misgaat.
De reden bij de regel bewaren
Een kredietlimiet of een regel voor het afsluiten van een rekening kan in code een klein detail lijken. Toch zit er meestal een praktische afspraak achter.
Ik leg die reden vast bij de uitwerking en de controle van zo’n onderdeel. Dan is later nog te beoordelen of een wijziging klopt voor de vereniging, in plaats van alleen voor de code.
Dat is voor mij de kern: begrijpen wat mensen doen, en zorgen dat de software daarbij past.