Walidacja danych, czyli jak zatrzymać 10 zamiast 1

Struktura to dopiero początek

W poprzednim wpisie pokazałem, jak ważna była sama struktura arkusza: zawodnicy w wierszach, treningi w kolumnach, daty w nagłówkach i podsumowania po prawej stronie.

To był potrzebny krok, ale sama struktura nie wystarczała.

Jeśli kilka osób pracuje na podobnych arkuszach, to prędzej czy później pojawią się błędy. Ktoś wpisze 10 zamiast 1, ktoś wpisze tekst zamiast liczby, ktoś użyje kropki zamiast przecinka albo odwrotnie. Ktoś inny przez przypadek edytuje komórkę, której nie powinien ruszać.

Na początku można to poprawiać ręcznie. Tylko że ręczne poprawianie szybko staje się męczące. Szczególnie wtedy, gdy na tych danych później opierają się podsumowania, raporty i decyzje trenerskie.

Właśnie tutaj pojawia się walidacja danych.

Problem nie był w trenerach, tylko w braku zasad

To ważne: walidacja nie powstała dlatego, że ktoś „źle pracował w arkuszu”.

Problem był prostszy. Arkusz pozwalał wpisać prawie wszystko. A jeśli narzędzie pozwala wpisać wszystko, to przy codziennej pracy ktoś w końcu wpisze coś nie tak.

Przy obecności najbardziej oczywistym błędem było 10 zamiast 1.

Dla człowieka widać od razu, że to pomyłka. Zawodnik nie może mieć dziesięciu obecności na jednym treningu. Ale formuła nie zawsze wie, że to pomyłka. Ona liczy to, co dostała.

I nagle pojawia się wynik, który nie ma sensu: frekwencja powyżej 100%, dziwne podsumowania albo raport, który trzeba później tłumaczyć i poprawiać.

Dlatego zamiast liczyć na to, że każdy zawsze wpisze dane idealnie, lepiej było sprawić, żeby arkusz nie przyjmował błędnych wartości.

Obecność: od pustej komórki do pełnej obecności

W przypadku obecności logika była prosta:

• brak wpisu — trening nie liczy się do obecności,
• 0 — zawodnik był nieobecny,
• wartość między 0 a 1 — obecność częściowa,
• 1 — pełna obecność.

Dzięki temu arkusz mógł obsłużyć więcej niż zwykłe „był / nie był”.

Jeśli zawodnik wyszedł wcześniej albo spóźnił się na dużą część treningu, można było wpisać wartość pośrednią. To nie była jeszcze pełna analiza treningowa, ale pozwalało lepiej opisać rzeczywistość niż zwykłe zero-jedynkowe oznaczenia.

Najważniejsze było jednak to, że wartości musiały trzymać się określonego zakresu. Dla obecności dozwolone były liczby od 0 do 1. To zatrzymywało błędy typu 10 zamiast 1.

Co robiła walidacja

Walidacja działała jak bramka przed wpisaniem danych.

Jeśli trener wpisywał poprawną wartość, arkusz ją przyjmował. Jeśli wpisywał coś spoza ustalonych zasad, arkusz pokazywał komunikat i blokował zmianę.

Przykładowo: przy obecności można było ustawić regułę, że komórka przyjmuje tylko liczbę z zakresu od 0 do 1.

Jeżeli ktoś próbował wpisać 10, tekst albo inną niedozwoloną wartość, dostawał informację, że wpis nie jest poprawny.

To jest mała rzecz, ale w codziennej pracy zmienia bardzo dużo. Trener nie musi pamiętać wszystkich zasad, bo arkusz zaczyna je egzekwować.

Jak ustawić to ręcznie w Google Sheets

Taką walidację można ustawić ręcznie, bez pisania kodu.

W Google Sheets robi się to mniej więcej tak:

1. Zaznaczasz zakres komórek, w których trener wpisuje obecności.
2. Wchodzisz w Dane → Sprawdzanie poprawności danych.
3. Wybierasz warunek dla liczby.
4. Ustawiasz zakres od 0 do 1.
5. Wybierasz opcję odrzucania nieprawidłowych danych.
6. Dodajesz komunikat dla użytkownika.

Dzięki temu arkusz nie tylko pokazuje, że coś jest nie tak, ale realnie blokuje błędny wpis.

To jest bardzo ważna różnica. Ostrzeżenie można zignorować. Blokady już nie.

Dlaczego nie chciałem robić tego ręcznie co tydzień

Ręczne ustawienie walidacji jest dobre na start. Można szybko sprawdzić, czy pomysł działa i czy trenerzy rozumieją komunikat.

Ale ustawianie tego ręcznie na każdym kolejnym arkuszu to robota głupiego.

Jeśli co tydzień powstaje nowa zakładka z nowym zakresem dat, to ręczne ustawianie walidacji, formatowania i zabezpieczeń zaczyna być kolejnym obowiązkiem. A przecież cały sens automatyzacji był taki, żeby takich powtarzalnych obowiązków było mniej.

Dlatego później walidacja była ustawiana automatycznie przy tworzeniu tygodniowego arkusza.

Nowy arkusz nie był pustą kopią, którą trzeba było dopiero poprawiać. Od razu miał ustawione daty, formuły, walidację i zakresy przygotowane do pracy.

Krótki przykład w Apps Script

W Google Apps Script walidację można ustawić na zakresie komórek.

Przykład koncepcyjny wygląda mniej więcej tak:

const rule = SpreadsheetApp.newDataValidation()
  .requireNumberBetween(0, 1)
  .setAllowInvalid(false)
  .setHelpText("Podaj wartość obecności od 0 do 1")
  .build();

range.setDataValidation(rule);

To nie jest jeszcze cały skrypt tworzący arkusze. Chodzi tylko o pokazanie idei.

Najpierw buduję regułę: liczba od 0 do 1, niedozwolone wartości mają być blokowane, a użytkownik ma dostać komunikat. Potem tę regułę przypisuję do konkretnego zakresu w arkuszu.

Dzięki temu każdy nowy tydzień może od razu dostać takie same zasady.

Walidacja przy kilometrażu

Później arkusze zaczęły obsługiwać nie tylko obecność, ale też kilometraż.

To było już po zmianach związanych z Librusem na zajęciach na basenie. Część obecności można było prowadzić w systemie szkolnym, a arkusz zaczął być wykorzystywany bardziej do zapisu wykonanej pracy.

Wtedy zmieniła się walidacja.

Przy obecności sensowny był zakres 0–1. Przy kilometrażu trzeba było pozwolić na liczby dziesiętne, na przykład 2,5, 3,8 albo 4,3.

Reguła była więc inna: komórka miała przyjmować liczbę, najczęściej większą lub równą 0.

To nadal nie rozwiązywało wszystkiego. Trener musiał sam pilnować, czy wpisany kilometraż faktycznie ma sens treningowy. Walidacja nie powie, czy jednostka była dobrze zaplanowana. Może jednak zatrzymać oczywiste błędy techniczne: tekst zamiast liczby, pusty przypadkowy wpis w złym miejscu albo wartość, której nie da się później policzyć.

Dodatkowo trenerzy dostawali automatyczne raporty mailowe, więc łatwiej było zauważyć, czy coś wygląda dziwnie w podsumowaniu.

Walidacja to nie to samo co ochrona zakresów

Przy okazji pojawił się drugi temat: ochrona zakresów.

Walidacja odpowiada na pytanie: czy wpisana wartość jest poprawna?

Ochrona zakresów odpowiada na inne pytanie: czy ta osoba w ogóle powinna móc edytować tę komórkę?

To są dwa różne mechanizmy, ale w praktyce dobrze się uzupełniają.

Trener powinien móc wpisywać obecność albo kilometraż w środku tabeli. Nie powinien jednak przypadkiem usuwać nazwisk zawodników, zmieniać dat, kasować formuł ani edytować podsumowań.

Dlatego z czasem wszystko poza środkiem tabeli do wpisywania danych było chronione.

Jeśli ktoś próbował edytować chronioną komórkę, arkusz informował, że nie ma do tego uprawnień. To ograniczało przypadkowe uszkodzenie arkusza.

O samej ochronie zakresów można napisać osobny wpis, bo to temat równie ważny jak walidacja. Tutaj najważniejsze jest to, że sama walidacja pilnuje wartości, a ochrona zakresów pilnuje miejsc, które wolno edytować.

Co to zmieniło w praktyce

Największa zmiana była taka, że arkusz stał się bardziej przewidywalny.

Nie trzeba było później szukać, dlaczego raport pokazuje dziwne liczby. Nie trzeba było poprawiać 10 wpisanego zamiast 1. Nie trzeba było zastanawiać się, czy formuła liczy źle, czy po prostu dostała złe dane.

Walidacja nie jest dodatkiem kosmetycznym. To moment, w którym arkusz przestaje być luźną tabelką, a zaczyna być narzędziem, któremu można zaufać.

Szczególnie wtedy, gdy pracuje na nim kilka osób.

Co dalej

Sama walidacja rozwiązała duży problem, ale ręczne ustawianie jej co tydzień nie miało sensu.

Kolejnym krokiem było automatyczne tworzenie tygodniowych arkuszy: z datami, formułami, walidacją i przygotowanymi zakresami.

W następnym wpisie pokażę, jak wyglądał pomysł na automatyczne tworzenie kolejnych tygodni i dlaczego to był moment, w którym arkusz zaczął naprawdę oszczędzać czas.