Rezerwacja zasobów w firmie: sala, maszyna i pojazd bez podwójnego terminu

Rezerwacja zaczyna się od zasobu

Dwie osoby potrzebują tej samej sali o dziesiątej. Obie sprawdziły kalendarz kilka chwil wcześniej i obie widziały wolny termin. Jeśli system pozwoli im zapisać spotkanie niezależnie, problem pojawi się dopiero pod zamkniętymi drzwiami. W przypadku maszyny lub pojazdu konsekwencje mogą objąć również plan pracy kolejnego zespołu.

Aplikacja do rezerwacji zasobów powinna wiedzieć, co jest rezerwowane, przez kogo i na jaki czas. Powinna też uwzględnić przerwę techniczną, zmianę planu oraz sytuację, w której zapis nie został potwierdzony. Widok kalendarza jest użyteczny, ale sam wygląd wolnego pola nie rozstrzyga jeszcze, czy termin został przydzielony.

Poniższe przykłady są hipotetyczne. Sala spotkań, maszyna produkcyjna i samochód służbowy mają różne zasady użycia. Zanim wybierzecie interfejs, opiszcie pracę ludzi i ograniczenia konkretnego zasobu. Dzięki temu jedna aplikacja może wspierać różne procesy bez udawania, że wszystkie rezerwacje znaczą to samo.

Co jest rezerwowane i przez kogo

Zacznijcie od listy rzeczy, o które naprawdę konkurują pracownicy. Sala może mieć pojemność, lokalizację i dostępny sprzęt. Maszyna może wymagać przeszkolonego operatora oraz czasu na przygotowanie. Samochód ma miejsce odbioru i osobę odpowiedzialną za wydanie. Wspólnym elementem jest przedział czasu, ale warunki przydziału będą inne.

Ustalcie, czy użytkownik wybiera konkretny egzemplarz, czy wystarczy mu dowolny zasób spełniający warunki. Osoba planująca spotkanie może szukać sali dla określonej liczby uczestników, podczas gdy kierowca potrzebuje konkretnego pojazdu z odpowiednim wyposażeniem. System nie powinien obiecywać dowolności, której organizacja nie może zapewnić. Przy planowaniu pojazdów służbowych uwzględnijcie też czas wyłączenia auta na obsługę oraz osobę, która przejmie termin. Ten proces opisujemy w artykule o planowaniu przeglądów floty.

Warto rozróżnić osobę rezerwującą, korzystającą i zatwierdzającą. Koordynator może rezerwować pojazd dla kolegi, a kierownik zatwierdzać użycie maszyny poza zwykłym harmonogramem. Przy każdym działaniu zapiszcie, kto widzi szczegóły i kto może zmienić termin. Potrzeby wielu lokalizacji omawiamy w artykule o systemie dla wielu oddziałów.

Nie każda informacja powinna być widoczna wszystkim. Użytkownik może potrzebować wiedzieć, że pojazd jest zajęty, bez dostępu do szczegółowego celu podróży. Przy sali konferencyjnej nazwa spotkania może zawierać poufne dane. Uzgodnijcie poziom widoczności osobno dla dostępności, uczestników oraz treści rezerwacji.

Uwzględnijcie również zasoby okresowo wyłączone z użycia. Sala może być zamknięta podczas remontu, a pojazd niedostępny po zgłoszeniu usterki. Upoważniona osoba potrzebuje możliwości wprowadzenia blokady oraz wskazania jej przewidywanego końca. Jeśli wcześniejsze rezerwacje obejmują ten czas, potrzebny jest sposób przekazania spraw do ponownego uzgodnienia, a nie wyłącznie zmiana koloru na wykresie.

Gdy termin zależy od zgody konkretnej osoby, podobne pytania pojawiają się przy koordynacji tłumaczy ustnych.

Czas użycia to nie zawsze cały zajęty czas

Spotkanie trwa godzinę, ale sala może wymagać przygotowania przed wejściem uczestników i uporządkowania po wyjściu. Maszyna potrzebuje przezbrojenia, a samochód zwrotu i sprawdzenia stanu. Jeśli planujecie wyłącznie czas właściwego użycia, dwa pozornie sąsiadujące terminy mogą w praktyce kolidować. Zapiszcie, czy dodatkowy czas jest stały, zależy od zadania, czy wymaga osobnej decyzji.

Ustalcie znaczenie granic przedziału. Czy rezerwacja kończąca się o 11:00 pozwala kolejnej osobie rozpocząć pracę dokładnie o 11:00? Jeśli potrzebna jest przerwa, powinna być widoczna w regule, a nie dopisywana z pamięci przez koordynatora. Odrębnie potraktujcie blokadę serwisową: może nie mieć użytkownika końcowego, ale nadal odbiera zasób z dostępności.

Przy pracy w różnych krajach zapiszcie strefę czasową zasobu i sposób prezentowania terminu odbiorcy. Dzień zmiany czasu wymaga szczególnej uwagi, bo lokalna godzina może wystąpić dwa razy albo nie wystąpić wcale. Wyjaśnijcie, jak system pokazuje taki termin i które dane są podstawą rozstrzygnięcia. Przetestujcie rzeczywiste strefy używane w projekcie, zamiast zakładać, że wszystkie oddziały pracują według zegara centrali.

Jeśli rezerwacja obejmuje kilka zasobów, ustalcie zależność między nimi. Sala może wymagać również urządzenia do wideokonferencji, a zadanie na maszynie uprawnionego operatora. Czy brak jednego elementu odrzuca całość, czy tworzy prośbę do uzgodnienia? Odpowiedź powinna być widoczna przed potwierdzeniem, żeby użytkownik nie traktował częściowej dostępności jako gotowej organizacji pracy.

Przy rezerwacji cyklicznej ustalcie, co dzieje się z pojedynczym terminem zmienionym w serii. Czy użytkownik może odwołać jedno spotkanie bez usuwania pozostałych? Jak postąpić, gdy jeden z przyszłych terminów koliduje z serwisem? Oczekiwana odpowiedź zależy od procesu, dlatego scenariusz warto omówić przed implementacją.

Dwie osoby wybierają ten sam termin

Sprawdzenie dostępności i zapis to odrębne chwile. Pomiędzy nimi ktoś inny może otrzymać ten sam przedział. Dlatego serwer powinien ponownie ocenić warunki przy zapisie i w razie konfliktu wyraźnie odmówić albo zaproponować inne rozwiązanie. Odświeżanie widoku pomaga zobaczyć zmiany, lecz nie zastępuje mechanizmu rozstrzygającego jednoczesne próby.

Jednym z możliwych rozwiązań jest ograniczenie na poziomie bazy danych. Dokumentacja PostgreSQL pokazuje typy przedziałowe oraz ograniczenia wykluczające nakładanie się rezerwacji. Projekt musi dodatkowo uwzględnić identyfikator zasobu, stany rezerwacji i zasady graniczne. Jest to przykład mechanizmu konkretnej bazy, a nie gotowa recepta dla każdej architektury.

Użytkownik, który przegrał równoczesną próbę, nie powinien zobaczyć komunikatu „gotowe”. Potrzebuje informacji, że termin jest już zajęty, i możliwości wyboru innego czasu bez ponownego wpisywania wszystkich danych. Zespół powinien sprawdzić obie strony scenariusza: jeden przydział został zapisany, drugi otrzymał czytelny wynik, a stan zasobu odpowiada decyzji.

Również anulowanie wymaga określonego momentu zwolnienia terminu. Jeśli rezerwacja wymaga zatwierdzenia, ustalcie, czy propozycja blokuje zasób w czasie oczekiwania i kiedy taka blokada wygasa. Zbyt długa blokada odbierze dostępność innym, zbyt krótka może uniemożliwić spokojne zakończenie decyzji. Nie ma jednej właściwej wartości bez poznania procesu.

Osobną sytuacją jest brak odpowiedzi po naciśnięciu przycisku. Jeżeli użytkownik ponowi operację, aplikacja powinna móc ustalić stan poprzedniej próby i pokazać wynik. Bez tego nie wiadomo, czy termin nie został przydzielony, czy potwierdzenie po prostu nie dotarło. Sposób identyfikacji operacji należy dobrać do systemu i przetestować z użyciem bezpiecznych danych.

Zmiana, anulowanie i zastępstwo

Pracownik odwołuje podróż, ale samochód nadal widnieje jako zajęty. Kierownik przenosi termin serwisu, lecz użytkownicy nadal planują pracę według poprzedniej wersji. System powinien wskazywać osobę uprawnioną do zmiany, nowy stan oraz to, kogo należy poinformować. Nie każda aktualizacja wymaga wiadomości do całej firmy. Powinna dotrzeć do osób, których działanie zależy od decyzji.

Przy zmianie terminu sprawdźcie dostępność nowego przedziału przed zwolnieniem starego. Jeżeli nowy termin nie jest osiągalny, użytkownik musi wiedzieć, czy dotychczasowa rezerwacja pozostała ważna. Dla operacji obejmującej kilka zasobów uzgodnijcie, co dzieje się w razie częściowego niepowodzenia. To ważniejsze niż sam kolor przesuwanego bloku w kalendarzu.

Zastępstwo również może zmienić warunki dostępu. Jeżeli rezerwacja maszyny wymaga określonych umiejętności, przekazanie jej innej osobie powinno uruchamiać sprawdzenie uzgodnionych wymagań. System może wspierać tę decyzję, ale aktualność informacji o kompetencjach zależy od procesu ich prowadzenia. Właściciel danych powinien wiedzieć, kto je aktualizuje oraz jak wyjaśniać rozbieżności.

Gdy zmiana ma trafić także do zewnętrznego systemu, zaplanujcie reakcję na opóźnienie lub brak odpowiedzi. O potrzebie rozdzielenia przyjęcia wiadomości od wykonania całego zadania piszemy w artykule o API i webhookach. W razie błędu osoba prowadząca rezerwację powinna wiedzieć, gdzie znajduje się aktualny stan i kto zajmuje się uzgodnieniem.

Kalendarz zewnętrzny: widok czy źródło decyzji

Integracja z kalendarzem może pomagać użytkownikowi zobaczyć przydzielony termin obok innych zobowiązań. Przed jej uruchomieniem trzeba jednak ustalić kierunek wymiany. Czy aplikacja tworzy wydarzenie po zatwierdzeniu rezerwacji? Czy zmiana w kalendarzu może zmienić również stan zasobu? Kto rozstrzyga, jeśli oba zapisy różnią się przez chwilę?

Google Calendar API udostępnia osobne operacje pobrania informacji o zajętości kalendarzy i utworzenia wydarzenia. To możliwości konkretnej usługi oraz odpowiednio uprawnionego konta. Sam odczyt zajętości nie jest opisem całej polityki rezerwacji firmy ani dowodem, że późniejsza próba zapisu nie spotka się z inną zmianą. Regułę przydziału trzeba zaprojektować dla całego procesu.

Sprawdźcie zakres udostępnianych danych. Widok zajętości może wystarczyć do planowania bez kopiowania treści spotkania. Jeśli integracja tworzy wydarzenia, ustalcie, jakie informacje rzeczywiście muszą się w nim znaleźć, kto widzi szczegóły i jak obsługiwane jest anulowanie. O odpowiedzialności za dane między narzędziami przeczytacie w tekście o źródle danych w integracji.

Zaplanujcie również niedostępność usługi zewnętrznej. Czy rezerwacja pozostaje ważna w aplikacji, jeśli wydarzenie nie pojawiło się w kalendarzu? Czy użytkownik może ponowić próbę i jak uniknąć podwójnego wpisu? Status powinien odpowiadać temu, co faktycznie potwierdzono. O przekazywaniu problemów do obsługi piszemy przy monitorowaniu automatyzacji.

Przy planowaniu integracji poproście również o wskazanie osoby odpowiedzialnej za konta oraz dostęp do kalendarzy. Zmiana hasła, odejście administratora albo odebranie uprawnienia może zatrzymać wymianę bez zmiany samego formularza. System powinien sygnalizować problem osobie, która może podjąć działanie, a instrukcja utrzymania wskazywać sposób bezpiecznego odnowienia dostępu.

Odbierz system na rzeczywistych scenariuszach

Przygotujcie fikcyjną salę, maszynę i pojazd oraz użytkowników o różnych uprawnieniach. Sprawdźcie jednoczesny wybór tego samego terminu, rezerwacje sąsiadujące, blokadę serwisową, zmianę czasu i anulowanie. Dopiszcie próbę dla różnych stref, jeśli są używane w firmie. Każda próba powinna wskazywać oczekiwany rezultat oraz osobę, która go oceni.

Sprawdźcie widok drugiej osoby po zmianie. Czy widzi ona, że zasób jest zajęty? Czy otrzymała informację o anulowaniu, jeśli jest jej potrzebna? Czy nie ujawniono szczegółów, których nie powinna widzieć? Jeśli kalendarz zewnętrzny jest w próbie symulowany, zanotujcie tę granicę. Osobny test rzeczywistego połączenia pozwoli potwierdzić zachowanie w konkretnej konfiguracji.

Przygotowanie uzgodnionych scenariuszy opisujemy szerzej przy odbiorze aplikacji. Dla pierwszej wersji wybierzcie proces, który da się przeprowadzić od wyboru zasobu do potwierdzenia albo czytelnej odmowy. O tym, jak ograniczyć zakres bez zgubienia wyniku, piszemy w artykule o MVP aplikacji.

Jeśli planujesz taki system, poznaj zakres oprogramowania na zamówienie i napisz do Archifutura. W briefie opisz zasoby, miejsca, osoby podejmujące decyzję oraz sytuację, w której obecny harmonogram zawodzi. Wspólnie łatwiej ustalić, które reguły trzeba sprawdzić przed projektowaniem kalendarza.

Po uruchomieniu obserwujcie sytuacje, w których pracownicy rezerwują zasób poza systemem. Przyczyną może być brak ważnego pola, niedostępność telefonu na hali albo zbyt długie oczekiwanie na zgodę. Rozmowa o tych przypadkach pozwala poprawić proces na podstawie rzeczywistej pracy. Uzgodnijcie osobę, do której trafią uwagi, oraz sposób sprawdzenia kolejnych zmian. Tę odpowiedzialność dobrze wskazać przed pierwszym wdrożeniem systemu.