Z Excela na telefon: jak zbudowaliśmy Kalendarz Lekarza Stażysty
Gdzieś w Polsce młody lekarz właśnie planuje najbliższe 13 miesięcy swojego stażu podyplomowego — z telefonu. Rok temu ten sam lekarz siedziałby nad arkuszem Excela, dzień po dniu kolorując komórki i licząc na to, że makra dobrze wszystko policzą.
To historia Kalendarza Lekarza Stażysty — aplikacji mobilnej, którą zbudowaliśmy w Otocolobus, żeby zastąpić przestarzały system Excelowy służący polskim lekarzom stażystom do planowania obowiązkowego stażu podyplomowego. Aplikacja działa na iOS i Androidzie, a co miesiąc korzysta z niej około 1000 lekarzy.
Tak to wyglądało.
Problem: arkusz kalkulacyjny, który nikogo nie cieszył
W Polsce każdy absolwent medycyny musi odbyć ustrukturyzowany staż podyplomowy, zanim zacznie samodzielną praktykę. Trwa on 13 miesięcy i obejmuje staże cząstkowe z wielu dziedzin — interna, chirurgia, pediatria, ginekologia, medycyna ratunkowa i inne — każda z określonym wymiarem czasu, ustalonym przez okręgową izbę lekarską.
Przez lata narzędziem do planowania tych staży był arkusz Excela nafaszerowany makrami. Praca wyglądała tak: otwierałeś siatkę dni i ręcznie kolorowałeś poszczególne komórki, żeby oznaczyć daną dziedzinę — jeden kolor na internę, inny na chirurgię, jeszcze inny na pediatrię i tak dalej. Kiedy już pomalowałeś cały grafik, makra odczytywały kolory komórek i obliczały, czy czas trwania każdego stażu cząstkowego spełnia wymagania.
Teoretycznie działał. W praktyce — to był koszmar.
Interfejs był głęboko nieintuicyjny. Młodzi lekarze — z których większość widziała ten plik po raz pierwszy w życiu — musieli sami dojść do tego, który kolor odpowiada której dziedzinie, jak poprawnie go nakładać i jak czytać wynik makr. Żadnego onboardingu, żadnej legendy, która od razu by się tłumaczyła. Tylko tęczowy arkusz kalkulacyjny i nadzieja, że się uda.
Ręczne kolorowanie było normą, a błędy — codziennością. Zły kolor na jednej komórce, przypadkowe przeciągnięcie, które zamalowało cały tydzień, albo pominięty dzień w danym bloku — to wystarczyło, żeby rozwalić całe obliczenie. Makra posłusznie sumowały to, co znalazły — śmieci na wejściu, śmieci na wyjściu. Lekarze odkrywali, że grafik się nie domyka, tygodnie później — czasem już po rozpoczęciu stażu cząstkowego, który okazywał się krótszy lub dłuższy niż wymagany. Naprawa oznaczała powrót do arkusza, szukanie złego koloru komórka po komórce i malowanie od nowa — często od zera.
Plik działał tylko na komputerze. Lekarz, który chciał zerknąć na harmonogram w drodze do szpitala, musiał wysłać sobie plik mailem albo zrobić zrzut ekranu. Dzielenie się planem z kolegami czy opiekunami stażu oznaczało przesyłanie Exceli tam i z powrotem na skrzynce.
To był system zbudowany przez inżynierów dla inżynierów — nie dla zapracowanych lekarzy, którym potrzebna jest szybka i wiarygodna odpowiedź na pytanie „Gdzie mam być w poniedziałek?"
Decyzja: dlaczego Flutter?
Kiedy wzięliśmy się za projekt, musieliśmy dostarczyć aplikację na iOS i Androida w małym zespole i w krótkim czasie. To od razu zawęziło pole wyboru.
Postawiliśmy na Fluttera z kilku powodów.
Po pierwsze — jeden codebase na obie platformy. Przy zespole naszej wielkości utrzymywanie oddzielnych baz kodu w Swifcie i Kotlinie nie wchodziło w grę. Flutter dał nam jeden codebase kompilujący się do natywnej wydajności na obu platformach — bez kompromisów w szybkości czy jakości interfejsu.
Po drugie — aplikacja jest z natury lokalna. Harmonogramy lekarzy to dane osobiste, które nie wymagają współdzielonego backendu. Wszystko żyje na urządzeniu, co radykalnie uprościło architekturę. Żadnych kont użytkowników, żadnej bazy po stronie serwera, żadnego API do utrzymania. Rozwiązało to też kwestie prywatności — harmonogramy stażowe lekarzy nigdy nie opuszczają ich telefonu.
Po trzecie — system widgetów Fluttera pozwolił nam sprawnie zbudować interfejs oparty na kalendarzu, który czuje się natywnie na obu platformach. Widok harmonogramu — czyli serce całej aplikacji — musiał być na tyle intuicyjny, żeby lekarz mógł go ogarnąć bez żadnej instrukcji. Na tym polegała cała idea: zamienić coś zagmatwanego na coś oczywistego.
Korzystamy z Firebase Analytics, żeby rozumieć wzorce użytkowania i wyłapywać punkty tarcia, ale sama aplikacja po instalacji działa w pełni offline.
Architektura: celowo prosta
Jedną z najlepszych decyzji, jakie podjęliśmy, było to, czego nie budowaliśmy.
Nie ma serwera backendowego. Nie ma warstwy API. Nie ma uwierzytelniania użytkowników. Nie ma bazy w chmurze. Aplikacja jest samowystarczalna.
Architektura wygląda tak:
┌─────────────────────────────────┐
│ Aplikacja Flutter │
│ │
│ ┌───────────┐ ┌────────────┐ │
│ │ Interfejs │ │ Silnik │ │
│ │ kalendarza│ │ staży │ │
│ └─────┬─────┘ └─────┬──────┘ │
│ │ │ │
│ ┌─────▼──────────────▼──────┐ │
│ │ Lokalne przechowywanie │ │
│ │ danych │ │
│ └───────────────────────────┘ │
│ │
│ ┌───────────────────────────┐ │
│ │ Firebase Analytics │ │
│ └───────────────────────────┘ │
└─────────────────────────────────┘
Silnik staży obsługuje całą logikę planowania, która wcześniej tkwiła w makrach Excela — czasy trwania poszczególnych dziedzin, wymogi prawne, obliczenia dat, wykrywanie konfliktów. Tyle że zamiast polegać na tym, że użytkownik sam wszystko poprawnie wpisze, aplikacja prowadzi go krok po kroku i waliduje dane na bieżąco. Nie da się przypadkiem stworzyć niemożliwego harmonogramu, bo aplikacja na to po prostu nie pozwoli.
Lokalne przechowywanie danych oznacza natychmiastową responsywność. Żadnego spinnera czekającego na odpowiedź serwera. Otwierasz aplikację — widzisz harmonogram. Tyle.
Firebase Analytics to jedyny serwis zewnętrzny. Mówi nam, z których funkcji lekarze faktycznie korzystają, w którym miejscu rezygnują i co sprawia im trudność. Ta pętla zwrotna jest bezcenna przy iterowaniu nad UX-em.
Czego się nauczyliśmy
Zaczynaj od bólu, nie od technologii. Nie chodziło nam o napisanie apki we Flutterze. Chodziło o naprawienie zepsutego procesu. Wybory technologiczne wynikły z ograniczeń — dwie platformy, mały zespół, brak potrzeby backendu, offline-first. Każda decyzja architektoniczna była podyktowana problemem, a nie tym, co ładnie wygląda w CV.
Prosta architektura to zaleta, nie kompromis. Łatwo byłoby to przekombinować. Konta użytkowników! Synchronizacja w chmurze! Współdzielone kalendarze! Funkcje społecznościowe! Tyle że nic z tego nie było potrzebne. Lekarze chcieli jednego: niezawodnego sposobu na zaplanowanie staży cząstkowych bez walki z arkuszem kalkulacyjnym. Im prostsza architektura, tym mniej rzeczy może się zepsuć — a w aplikacji, której lekarze używają do planowania szkolenia medycznego, niezawodność jest ważniejsza niż lista ficzerów.
Walidacja pokonuje dokumentację. Stary system Excelowy miał dokumentację (gdzieś). Nikt jej nie czytał. Nasza aplikacja nie potrzebuje dokumentacji, bo zapobiega błędom w czasie rzeczywistym. Każde pole jest walidowane, każdy konflikt sygnalizowany natychmiast, a interfejs sprawia, że poprawna ścieżka jest tą oczywistą. Ta jedna zmiana — z „pomaluj komórki i licz, że makra dobrze policzą" na „aplikacja poprowadzi cię za rękę" — zrobiła największą różnicę.
Analityka to nie opcja. Firebase Analytics nic nas nie kosztuje, a daje wszystko, czego potrzebujemy do świadomych decyzji o produkcie. Wiemy, że lekarze korzystają z aplikacji głównie w określonych porach roku (gdy ruszają nowe cykle staży), i dokładnie wiemy, które ekrany sprawiają najwięcej trudności. Bez tych danych strzelalibyśmy w ciemno.
Rezultaty
Z aplikacji korzysta ok. 1000 lekarzy miesięcznie — na iOS i Androidzie. Jak na kontekst — to znacząca część populacji lekarzy stażystów w danym roku w Polsce.
Ważniejsze jest to, że zastąpiliśmy proces, którego lekarze się bali, czymś, z czego korzystają z własnego wyboru. Recenzje w obu sklepach to potwierdzają — lekarze konsekwentnie wspominają, że aplikacja jest intuicyjna i oszczędza im czas, który wcześniej szedł na kolorowanie arkuszy.
Koszty infrastruktury to w zasadzie zero. Żadnych serwerów, żadnej bazy danych, żadnego miesięcznego rachunku od AWS. Jedyny stały wydatek to opłata za Apple Developer Program i darmowy tier Firebase.
Kiedy budować prosto
Nie każdy projekt powinien być aż tak minimalistyczny. Nasza platforma analityki czasu rzeczywistego dla klienta logistycznego wykorzystuje ECS, DynamoDB Streams, CloudFront i pełny stos AWS — bo ten problem tego wymagał.
Ale Kalendarz Lekarza Stażysty to przypomnienie, że najlepsza architektura to taka, która rozwiązuje problem przy minimalnej złożoności. Arkusz pełen makr został zastąpiony aplikacją mobilną z lokalnym przechowywaniem danych i zerowym backendem. Lekarze są zadowoleni, liczba błędów spadła, a o trzeciej w nocy nic nas nie budzi.
Czasem najmądrzejsza inżynieria polega na tym, żeby wiedzieć, czego nie budować.
W Otocolobus budujemy oprogramowanie dopasowane do problemu — czy to bezserwerowa aplikacja mobilna, czy pełnoskalowa platforma na AWS. Masz proces zakopany w arkuszach kalkulacyjnych i chcesz sprawdzić, jak mogłoby wyglądać nowoczesne rozwiązanie? Porozmawiajmy.