Aplikacja webowa dla szkoły — checklist funkcji

Aplikacja dla placówki oświatowej ma nietypowy zestaw ograniczeń: użytkownikami są jednocześnie nauczyciele, uczniowie, rodzice i administracja, dane dotyczą osób małoletnich, a wdrożenie musi zmieścić się między feriami a początkiem roku szkolnego. Ten poradnik porządkuje, co naprawdę trzeba zbudować, a co da się odłożyć.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Cztery role i cztery zupełnie różne potrzeby

Najczęstszy błąd projektowy polega na zbudowaniu jednego interfejsu z ukrywanymi elementami zamiast czterech osobnych widoków. Każda grupa korzysta z aplikacji w innym kontekście i z innym poziomem cierpliwości.

Checklist funkcji — rdzeń

• Konta i logowanie z możliwością powiązania jednego konta rodzica z kilkorgiem dzieci.
• Plan lekcji z obsługą zastępstw, odwołanych zajęć i sal.
• Kalendarz wydarzeń — wywiadówki, wycieczki, egzaminy, dni wolne.
• Obecności z rozróżnieniem nieobecności usprawiedliwionej, spóźnienia i zwolnienia.
• Usprawiedliwienia elektroniczne składane przez rodzica, z akceptacją wychowawcy.
• Ogłoszenia kierowane do klasy, poziomu albo całej placówki, z potwierdzeniem odczytu.
• Zadania domowe z terminem i opcjonalnym miejscem na przesłanie pliku.
• Oceny z podziałem na kategorie i wagami.
• Zgody elektroniczne — wycieczki, wizerunek, zajęcia dodatkowe — z rejestrem czasu udzielenia.
• Powiadomienia pocztą elektroniczną oraz push, z możliwością wyłączenia kategorii przez odbiorcę.

Checklist funkcji — moduły opcjonalne

• Płatności — obiady, ubezpieczenie, rada rodziców, wycieczki. Wymaga rozliczeń i historii wpłat.
• Stołówka z zamawianiem posiłków i odwoływaniem do określonej godziny.
• Biblioteka — wypożyczenia, rezerwacje, przypomnienia o zwrocie.
• Rekrutacja — wnioski, listy, komunikacja z kandydatami.
• Zajęcia dodatkowe z zapisami i limitami miejsc.
• Świetlica — rejestr odbioru dziecka z listą osób upoważnionych.
• Ankiety dla rodziców i uczniów z anonimizacją odpowiedzi.

Dostępność cyfrowa to wymóg, nie dodatek

Placówki publiczne podlegają obowiązkowi zapewnienia dostępności cyfrowej. W praktyce oznacza to spełnienie wytycznych WCAG na poziomie AA oraz opublikowanie deklaracji dostępności. Doprowadzenie gotowej aplikacji do zgodności kosztuje wielokrotnie więcej niż uwzględnienie wymogów w projekcie.

• Kontrast tekstu co najmniej 4,5 do 1 dla treści podstawowej.
• Pełna obsługa klawiaturą — każda funkcja dostępna bez myszy, z widocznym wskaźnikiem aktywnego elementu.
• Poprawna struktura nagłówków i etykiety wszystkich pól formularzy.
• Teksty alternatywne dla grafik niosących treść.
• Komunikaty o błędach opisujące, co poprawić, a nie tylko sygnalizujące błąd kolorem.
• Napisy do materiałów wideo publikowanych w aplikacji.
• Deklaracja dostępności z danymi kontaktowymi i procedurą zgłoszenia problemu.

Ochrona danych — co jest inne niż w zwykłym projekcie

Integracje, o które trzeba zapytać na starcie

• Dziennik elektroniczny — kluczowe pytanie brzmi, czy nowa aplikacja zastępuje dziennik, czy z niego czyta. Drugi wariant wymaga ustalenia, czy dostawca dziennika udostępnia interfejs wymiany danych.
• System kadrowo-płacowy przy module obiadów i rozliczeń.
• Poczta elektroniczna placówki — jako kanał powiadomień i jako sposób logowania.
• Bramka płatności przy składkach i wycieczkach.
• Eksport do sprawozdawczości — dane potrzebne do raportów zewnętrznych powinny dać się wyeksportować bez pracy programisty.

Koszty i harmonogram

Harmonogram warto podporządkować kalendarzowi szkolnemu. Wdrożenie w trakcie roku napotyka opór, bo zmienia rutynę w środku pracy. Najlepszy moment to uruchomienie pilotażu na jednym poziomie w drugim semestrze i pełne wdrożenie od września.

Wdrożenie — najtrudniejszy etap

• Pilotaż na jednym roczniku zamiast startu w całej placówce.
• Szkolenie nauczycieli w formie krótkiego materiału wideo dostępnego w aplikacji, nie jednorazowego spotkania.
• Instrukcja dla rodziców na jednej stronie, z opisem pierwszego logowania.
• Wskazana osoba kontaktowa w placówce, do której trafiają zgłoszenia.
• Import danych uczniów i klas przygotowany i przetestowany przed startem.
• Plan awaryjny na pierwszy tydzień — poprzedni sposób pracy powinien pozostać dostępny.
• Zbieranie uwag przez formularz w aplikacji przez pierwszy miesiąc.

Utrzymanie i rok szkolny

Aplikacja dla placówki oświatowej ma nietypowy cykl życia, podporządkowany kalendarzowi szkolnemu. Wynikają z tego obowiązki, które trzeba zaplanować w umowie utrzymaniowej, bo pojawiają się cyklicznie i w konkretnych terminach.

Wrzesień zasługuje na szczególną uwagę przy planowaniu. To moment, w którym z systemu korzystają jednocześnie wszyscy użytkownicy — uczniowie, rodzice i nauczyciele — często po raz pierwszy. Obciążenie bywa kilkukrotnie wyższe niż w pozostałych miesiącach, a liczba zgłoszeń do wsparcia sięga poziomu, którego nie da się obsłużyć doraźnie.

Praktyczny wniosek: testy wydajnościowe warto przeprowadzić na wolumenie odpowiadającym pierwszemu tygodniowi września, a nie średniej rocznej. Warto też zapewnić zwiększoną dostępność wsparcia w tym okresie i przygotować materiały pomocnicze przed startem, a nie w reakcji na pytania.

Podsumowanie

Aplikacja dla placówki oświatowej udaje się wtedy, gdy zmniejsza liczbę czynności nauczyciela, a nie gdy ma najwięcej modułów. Rdzeń to cztery role, plan, obecności, komunikacja z potwierdzeniem odczytu i rejestr zgód — reszta jest rozwinięciem.

Dwa wymogi trzeba uwzględnić od pierwszego szkicu: dostępność cyfrową i szczególną ochronę danych małoletnich. Oba dodane po fakcie oznaczają przebudowę interfejsu i modelu danych, a nie poprawkę. Wdrożenie warto rozłożyć na pilotaż i pełny start zgrany z początkiem roku szkolnego.