Rehabilitacja Onkologiczna

Realizacja w jednym akapicie

To strona internetowa dla realnego projektu unijnego — rekrutacja pacjentów onkologicznych do bezpłatnego programu rehabilitacji, prowadzonego przez Zachodniopomorskie Centrum Onkologii w Szczecinie i współfinansowanego z Europejskiego Funduszu Społecznego. Zlecenie przyszło od szpitala w formie pisemnego briefu z konkretnym, zamkniętym zakresem zadania — nie od startupu z otwartym product-backlogiem. To realizacja, w której najważniejsze ograniczenia nie były techniczne, tylko proceduralne: wymogi programu unijnego, oznakowanie logotypami, dokumentacja dla uczestników i sztywny harmonogram.

Brief zamiast product ownera

Zamówienie przyszło mailem od działu administracyjno-gospodarczego ZCO wraz z załącznikiem opisującym dokładny zakres zadania: strona z rekrutacją on-line, formularz zgłoszeniowy wraz ze wzorem ankiety, dokumenty dla kandydatów i uczestników dostarczone przez zamawiającego, odnośnik zwrotny ze strony głównej szpitala, własny design i layout, skrypty obsługujące formularz z walidacją, Polityka Cookies, logotypy wymagane w umowie z Wojewódzkim Urzędem Pracy, hosting i domena po stronie wykonawcy, szkolenie co najmniej dwóch osób administrujących stroną, wsparcie techniczne przez cały czas trwania projektu. Zero swobody co do zakresu — cała swoboda była w tym, jak to zbudować.

Formularz, który musi spełniać wymogi programu, nie tylko UX-u

Rekrutacja do projektu współfinansowanego z EFS to nie jest zwykły formularz kontaktowy. Program wymaga zebrania konkretnych wskaźników monitoringowych Wspólnej Listy Wskaźników Kluczowych — m.in. czy uczestnik należy do mniejszości narodowej lub etnicznej, czy jest osobą bezdomną lub dotkniętą wykluczeniem mieszkaniowym, czy ma niepełnosprawności, czy znajduje się w innej niekorzystnej sytuacji społecznej. Część z tych pytań dotyczy danych wrażliwych w rozumieniu RODO, więc każde z nich ma trzecią opcję obok „tak"/„nie": „odmowa udzielenia informacji" — uczestnik nigdy nie jest zmuszony do odpowiedzi, a brak odpowiedzi jest osobnym, poprawnym stanem formularza, nie błędem walidacji.

Reszta formularza waliduje to, co typowa strona rządowa/publiczna wymaga formalnie: PESEL w ścisłym formacie jedenastu cyfr, wymagane pola oznaczone gwiazdką, format daty rozpoczęcia udziału w projekcie, wiek w chwili przystępowania, poziom wykształcenia z zamkniętej listy, kategorię zawodową uczestnika (pracownik instytucji pomocy społecznej, instytucji rynku pracy, szkolnictwa wyższego, poradni psychologiczno-pedagogicznej, rolnik i inne) z polem „Inny" na wypadek kategorii spoza listy.

Skrypty PHP jako cichy, ale krytyczny element

Warstwa wizualna to React na komponentach Material Design Google — ale to, co faktycznie decyduje, czy zgłoszenie dotrze do koordynatora projektu, to skrypty PHP po stronie serwera: powtórna walidacja pól (nigdy nie ufaj wyłącznie walidacji w przeglądarce), złożenie zgłoszenia w wiadomość e-mail albo zapis na serwerze, i reCAPTCHA jako pierwsza linia obrony przed botami wypełniającymi formularz rekrutacyjny publicznego programu zdrowotnego — realne ryzyko dla strony, która jest jawnie zaindeksowana i łatwa do znalezienia.

Logotypy nie są dekoracją, są wymogiem umowy

Strona projektu unijnego musi nosić konkretne, wymagane logotypy — Fundusze Europejskie, godło Rzeczypospolitej Polskiej, marka regionu, Unia Europejska/EFS — w układzie i proporcjach zgodnych z wytycznymi Wojewódzkiego Urzędu Pracy przekazanymi przez zamawiającego. To nie jest swoboda projektowa, to warunek rozliczenia dotacji: brak poprawnego oznakowania promocyjnego może skutkować zakwestionowaniem wydatku przez instytucję finansującą.

Rozliczenie zadania rozłożone na dwa lata budżetowe

Zadanie miało z góry określone ramy: rozpoczęcie w lipcu 2021, zakończenie 31 grudnia 2022, z wydatkami rozdzielonymi po równo między dwa lata budżetowe — typowy rytm projektu finansowanego ze środków publicznych, gdzie harmonogram płatności podąża za rokiem kalendarzowym instytucji finansującej, a nie za etapami wdrożenia. Wsparcie techniczne było elementem umowy przez cały ten okres, a nie jednorazową dostawą.

Przekazanie wiedzy, nie tylko kodu

Częścią zamówienia było przeszkolenie co najmniej dwóch pracowników szpitala z funkcjonowania, administrowania i redagowania zbudowanej podstrony — bo po zakończeniu współpracy to personel ZCO, nie wykonawca, miał na co dzień aktualizować treści i obsługiwać zgłoszenia. Strona musiała więc być na tyle prosta w obsłudze, żeby dało się to przekazać w jednym szkoleniu stacjonarnym w siedzibie zamawiającego.

Projekt z datą końca, nie produkt bez końca

Program wsparcia zakończył się 31 grudnia 2022 razem z projektem unijnym, który finansował rehabilitację — domena projektu nie jest już aktywna. To uczciwy obraz sporej części pracy freelancera: nie każda realizacja to produkt utrzymywany bezterminowo, część to strony budowane pod konkretny, czasowo ograniczony cel publiczny, które kończą żywot razem z dofinansowaniem, jakie je powołało do istnienia.

Co z tej realizacji wynika

Najważniejsza lekcja z tego projektu: zgodność z wymogami programu unijnego to osobna, twarda specyfikacja obok UX-u i technologii — trzeba było jednocześnie zaprojektować przyjazny formularz rekrutacyjny i zebrać nim dokładnie te dane, w dokładnie tym kształcie (włącznie z opcją odmowy odpowiedzi na pytania o dane wrażliwe), których wymaga rozliczenie dotacji z Europejskiego Funduszu Społecznego. Rzecz, którą bym powtórzył: czytanie briefu zamawiającego równie uważnie jak dokumentacji technicznej, bo w projekcie publicznym to właśnie brief, nie własny gust, definiuje większość decyzji produktowych.