Dlaczego aplikacja planisty jest, jaka jest

Różne ciekawostki związane z historią budowy i wdrożenia SWDPRM
tomasz.boguslawski
Twórca SWDPRM
Twórca SWDPRM
Posty: 148
Rejestracja: 15 gru 2017, 6:11

Dlaczego aplikacja planisty jest, jaka jest

Post autor: tomasz.boguslawski » 30 cze 2019, 13:08

Aplikacja planisty - zapomniany element SWDPRM

Niektórzy zapomnieli, że w ogóle jest taka aplikacja. Niektórzy nie wiedzą. Niektórzy wolą zapomnieć o jej istnieniu. Jest tak źle zaprojektowana i nieergonomiczna, że w praktyce nieużywalna. Dlaczego stworzono taką aplikację? Najkrótsza odpowiedź jest taka: tę aplikację robiło Pentegy.
Warto jednak zastanowić się głębiej, żeby na przyszłość nie popełniać takich błędów.

Pierwszy powód wynika z podejścia do projektu. Moje podejście było takie, żeby zrobić dobry system. Podejście Pentegy było takie, żeby wypełnić warunki zamówienia i zakończyć projekt z "sukcesem" w najbardziej pospolitym rozumieniu tego słowa - czyli "w budżecie i na czas".
Nie można winić Pentegy za takie podejście - niestety Wykonawca ma prawo pójść tą drogą. Taka jest specyfika projektów dla administracji publicznej. W projekcie dla prywatnego klienta Wykonawca starałby się bardziej, aby zapewnić sobie renomę i zwiększyć szansę na kolejne zamówienia.

W projektach publicznych to na Zamawiającym leży obowiązek właściwego sformułowania wymagań. Wymagania w OPZ dotyczące aplikacji planisty były wyjątkowo lakoniczne. Cały moduł układania grafika dyżurów był opisany w dwóch wymaganiach:
  • (F.SWDPRM.31) "Wspieranie działań związanych z tworzeniem grafików czasu pracy osób pracujących w zespołach wyjazdowych oraz tworzenie elektronicznych list obecności."
  • (F.SWDPRM.32) "Możliwość rejestrowania i modyfikowania grafików Dyspozytorów oraz składów ZRM na podstawie jednego wspólnego szablonu. Potwierdzanie obecności na elektronicznej liście obecności, określającej jednocześnie skład ZRM. Grafiki wykorzystywane do automatycznego uzupełniania Dokumentacji medycznej PRM."
I tylko tyle, ani słowa więcej. Więcej trudu Zamawiający nie zadał sobie, żeby opisać, jakie ma wymagania w stosunku do funkcjonalności planowania dyżurów.

Skoro jednak Pentegy włożyło wysiłek w zbudowanie Aplikacji Planisty, to można było zrobić coś używalnego. Gdzie popełniony został błąd?

Moim zdaniem, jak to zazwyczaj bywa w projektach informatycznych, przyczyna leży w Analizie Biznesowej. Jest to element realizacji projektu, którego celem jest zrozumienie wymagań Zamawiającego i zaproponowanie/zaprojektowanie właściwych rozwiązań - zarówno w postaci oprogramowania jak i zmian w procedurach czy sposobach działania. Analiza biznesowa jest trudna i niestety wiele projektów kończy się niepowodzeniem z powodu przeprowadzenia jej w niewłaściwy sposób - klient dostaje nie to, czego naprawdę potrzebuje.
Aplikacja planisty akurat nie jest specjalnie skomplikowanym kawałkiem oprogramowania. Nie jest to aplikacja wspierająca kluczowe procesy - tu przecież chodzi tylko o ułożenia grafika dyżurów na kolejny miesiąc!

Podstawowy błąd, który popełnił analityk Pentegy, to brak kontaktu z użytkownikiem. Analityk sam wymyślił, jak ma działać aplikacja - nie skontaktował się z żadną osobą, która układa dyżury. To, czego sam nie wymyślił, pozostawił do wymyślenia programistom, którzy tym bardziej z nikim nie skonsultowali swoich pomysłów.

Jestem absolutnie przekonany, że gdyby analityk projektujący aplikację planisty poprosił kierownika projektu o zorganizowanie jednego spotkania z pracownikiem Ratownictwa Medycznego, który w praktyce układa grafiki dyżurów i następnie chociaż na 2 godziny spotkał się i zobaczył, jak są układane grafiki - zaprojektowana aplikacja byłaby zupełnie inna! Celem takiego spotkania nie jest spisywanie wszystkich oczekiwań i życzeń użytkownika. Celem jest przede wszystkim zrozumienie, jak w praktyce wygląda praca i które jej elementy stanowią trudność.

Historię tę zamieszczam jako przypomnienie dla wszystkich osób projektujących rozwiązania informatyczne, jak ważne są spotkania z (przyszłymi) użytkownikami. To, co my analitycy wymyślimy sami - niekoniecznie musi sprawdzić się w praktyce. Każdy pomysł powinien być sprawdzony, póki jest tylko pomysłem. Gdy już na podstawie pomysłu powstanie oprogramowanie - jest za późno, żeby słaby pomysł "odkręcić". A jeśli poprawa źle zaprojektowanego oprogramowania stanie się konieczna - będzie bardzo kosztowna.

Awatar użytkownika
rwaligora
Posty: 153
Rejestracja: 15 gru 2017, 17:09
Lokalizacja: Bielsko-Biała
Kontakt:

Re: Dlaczego aplikacja planisty jest, jaka jest

Post autor: rwaligora » 30 cze 2019, 19:12

Grafiki medyczne to bardzo specyficzna rzecz. Potrzeba dobrego analityka aby ogarnął wszystkie przypadki
Jeśli znasz siebie i swego wroga, przetrwasz pomyślnie sto bitew. Jeśli nie poznasz swego wroga, lecz poznasz siebie, jedną bitwę wygrasz, a drugą przegrasz. Jeśli nie znasz ni siebie, ni wroga, każda potyczka będzie dla Ciebie zagrożeniem."

tomasz.boguslawski
Twórca SWDPRM
Twórca SWDPRM
Posty: 148
Rejestracja: 15 gru 2017, 6:11

Re: Dlaczego aplikacja planisty jest, jaka jest

Post autor: tomasz.boguslawski » 02 lip 2019, 17:00

Trochę żałuję, że nie dane mi było zmierzyć się z tym tematem. Chętnie przeanalizowałbym temat i zaproponował rozwiązanie.
Kto wie, może będę zajmować się tym w ramach SWDPRM 2.0?

ODPOWIEDZ