#02 - Agile w branży medycznej i innych branżach regulowanych

Jakiś miesiąc temu pojawił się newsletter Mike’a Cohna - “Czy Scrum Master musi być ekspertem domenowym w branży, w której działa?”. 

Odpowiedź, jak to często w agile bywa, była - “nie, nie musi, ale…”.

Jak pisze Cohn, pracując z tysiącami zespołów zauważył, że wyzwania Scrum Mastera są podobne niezależnie od branży. Dalej dodaje, że niektóre branże mogą mieć jednak dodatkowe wyzwania… i tu wprost wskazuje 2 takie branże - rozwój sprzętu i branże regulowane.  

Ależ ze mnie szczęściarz! Zaliczyłem kombosa - w moich zespołach mam oba najbardziej hardcore’owe przypadki razem. Rozwój sprzętu i branża medyczna!  

Transcript

Ostatnim razem opowiadałem o wyzwaniach przy tworzeniu sprzętu, teraz opowiem parę słów o wyzwaniach związanych z branżami regulowanymi. Warto posłuchać również wtedy, gdy w takiej branży nie działacie.  

Jakiś miesiąc temu pojawił się newsletter Mike’a Cohna - “Czy Scrum Master musi być ekspertem domenowym w branży, w której działa?”. 

Odpowiedź, jak to często w agile bywa, była - “nie, nie musi, ale…”. 

Jak pisze Cohn, pracując z tysiącami zespołów zauważył, że wyzwania Scrum Mastera są podobne niezależnie od branży. Dalej dodaje, że niektóre branże mogą mieć jednak dodatkowe wyzwania… i tu wprost wskazuje 2 takie branże - rozwój sprzętu i branże regulowane.  

Ależ ze mnie szczęściarz! Zaliczyłem kombosa - w moich zespołach mam oba najbardziej hardcore’owe przypadki razem. Rozwój sprzętu i branża medyczna.  

Na początek powiem, że praca w branży medycznej jest bardzo satysfakcjonująca. Jako pracownik, trener i konsultant pracowałem z wieloma firmami z bardzo różnych branż. Jednak mało który produkt dawał tyle powodów do zadowolenia. W końcu biorę udział w tworzeniu produktów, które poprawiają ludziom komfort życia, a czasem nawet je ratują! 

Branż regulowanych jest wiele. Większość kręci się wokół zdrowia i bezpieczeństwo, pieniędzy albo danych wrażliwych. 

Tak zwany regulator tworzy normy i zasady, które są - według niego - niezbędne do zapewnienia odpowiedniego poziomu jakości i - w szczególności - odpowiednio niskiego poziomu ryzyka związanego z korzystaniem z tych produktów. My mamy to szczęście, że nasze produkty wykorzystywane są na całym świecie. Dlatego musimy spełniać różne normy. Jest ich naprawdę wiele i nie będę ich tu wymieniał. Generalnie obowiązują nas 2 zestawy norm i zaleceń - międzynarodowe oraz amerykańskie. W istotnej części się pokrywają, ale są też miejsca, gdzie różnice są naprawdę duże. Nawet klasy bezpieczeństwa, od których zależy to, jakie działania będziemy musieli podjąć, różnią się w tych dwóch grupach. 

Normy oczywiście czyta się tak, jak inne zapisy prawne. I trzeba się normalnie doktoryzować, żeby zrozumieć, o co chodziło autorowi danej normy. Są więc osoby, które swoje zawodowe życie poświęcają na to, żeby te normy rozumieć, śledzić zmiany w kolejnych wersjach i umieć obronić się przez wszechobecnymi mackami regulatora. Jednak im więcej te osoby spędzają czasu z normami, audytorami zewnętrznymi i inną biurokracją, tym mniej spędzają z produktem.  

W skrajnych przypadkach może dojść do sytuacji, gdy osoby z Działu Certyfikacji tylko bardzo pobieżnie rozumieją produkt, a więc bardzo ciężko będzie im dać jasne i klarowne odpowiedzi jak coś zrobić lub czego unikać przy tworzeniu produktu. Deweloperzy będą stale odsyłani do norm i sami będą musieli z nich wyłuskiwać potrzebne wymagania, i je interpretować. Nie dość, że Deweloperzy tego nienawidzą, to jeszcze w większości wypadków są w tym po prostu kiepscy. A to skutkuje problemami na etapie testów w laboratoriach i koniecznością istotnych zmian na późnym etapie rozwoju produktu. 

Pominę już, jakie to generuje koszty, bo one są tak naprawdę najmniejszym problemem w tym wszystkim. Więc co jest problemem? 

Dawno, dawno temu, za górami za lasami… po prostu był waterfall. Ktoś tam analizował potrzeby rynku, później ktoś inny - na tej podstawie - tworzył szczegółowe wymagania dla tego produktu. Dalej ktoś go robił. Później ktoś testował, żeby ten produkt nie rozsypał się przy pierwszym użyciu. I na koniec wypychaliśmy to do klienta, który cieszył się, że w ogóle coś dostał. Idealna sytuacja dla regulatora. Na każdym kroku może sobie zdefiniować co ma być na wejściu i co ma być na wyjściu. Proste! 

Aż w końcu ktoś wymyślił ten wstrętny agile, a do tego klienci już nie łykają nowych produktów jak młode pelikany i tak naprawdę te produkty trzeba tworzyć razem z nimi, żeby na końcu ktoś je kupił i chciał ich używać. Ale jak to?! Czyli chcemy dać do rąk użytkownika niepełnowartościowy produkt?! Nie ma mowy! Jak już go sobie stworzycie, to zapłaćcie worek złota, żebyśmy sprawdzili, czy na pewno nie oszukujecie, a do tego poczekajcie pół roku aż ocenimy wszystkie papierki, w których piszecie jak ten produkt zrobiliście i dlaczego.  

Na szczęście w przypadku wielu - raczej drobnych - zmian, nie trzeba na nowo certyfikować produktu i przechodzić procesu jego dopuszczenia do sprzedaży. Tak bardzo często ratuje się software, pokazując, że tak naprawdę zmiany były minimalne i nie wpływały na zwiększenie ryzyka. W hardware już nie jest tak kolorowo. Można sobie zmienić rezystor, kondensator, może nawet jakiś mało istotny układ scalony. Chociaż to dobre, bo inaczej trzeba by przechodzić cały ten proces na nowo co pół roku, gdy dostawca przestanie produkować daną część. Ale istotnych elementów już nie zmienimy - np. toru EKG, czy procesora. Nie mówiąc już o obudowie.  

Obudowa urządzenia medycznego, przynajmniej takiego noszonego na ciele, nie dość, że musi być biokompatybilna, to jeszcze musi przejść szereg rygorystycznych testów odpornościowych. I nawet drobna zmiana w obudowie może spowodować, że jakiegoś testu już się nie przejdzie. Dlatego większość tego typu zmian nie jest dozwolona. To, że dany materiał jest biokompatybilny i dany barwnik ma tego typu certyfikat, to nie oznacza, że możemy uniknąć testu, w którym obudowa urządzenia jest przyczepiana do króliczka, a on później biega z nią przez miesiąc… Nie ma podrażnień? Super! Są podrażnienia? Fail! 

Nauka dla firm spoza branży jest taka, że warto patrzeć na różne aspekty, nawet jeżeli nie jesteśmy do tego zobowiązani. Opaska sportowa nie musi spełniać wielu regulacji medycznych, ale czy naprawdę chcielibyśmy, żeby - po tygodniu jej noszenia - u użytkownika pojawiło się podrażnienie? Albo naprawdę możemy pozwolić sobie, żeby nasz produkt przy upadku z wysokości metra nie nadawał się już do użycia? Nie sądzę, chociaż pewnie bardzo będzie to zależało od konkretnego produktu i jego ceny. Jeżeli chcesz przeprowadzać testy i nie masz pomysłu, jakie testy zrobić, to zawsze można popatrzeć na normy obowiązujące w podobnej branży regulowanej i na ich podstawie skonstruować swój tor przeszkód. Można skorzystać też z pomocy licznych laboratoriów pamiętając, że te bez akredytacji zrobią nam tak samo dobre testy dużo taniej, ale nie wystawią nam odpowiednich certyfikatów. 

Wracając do ryzyk, które mogą się pojawić, jednym z testów w przypadku naszych urządzeń medycznych jest upuszczenie na urządzenie stalowej kulki o średnicy 50 mm z wysokości 1 metra. Poprzednia wersja normy mówiła tylko, że po takim drop teście nasze urządzenie nie może spowodować żadnych - jak to ładnie nazwano - nieakceptowalnych ryzyk. Nowa norma mówi już o tym, że po takim teście, to urządzenie ma nadal spełniać swoje podstawowe funkcje. Nie dziwcie się więc, proszę, że wiele urządzeń medycznych jest po prostu brzydkich lub istotnie cięższych, niż ich niemedyczne odpowiedniki. 

Czego uczy nas jednak branża medyczna w kwestii ryzyk? Że warto je analizować i zarządzać nimi, czyli - ładnie mówiąc - eliminować niepotrzebne ryzyka. Również pracując zwinnie! A jaki jest najlepszy sposób na eliminowanie ryzyk? Zrobienie tego by design - tak zaprojektowanie urządzenia, żeby ryzyko nie miało szansy się zmaterializować. Brzmi to enigmatycznie, ale podam przykład. Załóżmy, że tworzymy nowe elektronarzędzie. W takim przypadku jednym z istotnych ryzyk będzie możliwość porażenia użytkownika prądem. Jednym ze sposobów minimalizacji ryzyka jest wpisanie ostrzeżenia w instrukcji. Czy ktoś to przeczyta? Chyba tylko ja, bo lubię czytać instrukcje do elektronarzędzi. A gdybyśmy zaprojektowali urządzenie tak, żeby było wodoodporne? By design uzyskujemy zabezpieczenie przed porażeniem. Czy to będzie opłacalne? To już każdy musi sobie na to odpowiedzieć w cichości swojego serca. Wprost zapewne nie. 

Oznaczenia na obudowie są w większości bezwartościowe, bo przeciętny użytkownik i tak ich nie zrozumie. O ile w ogóle je zobaczy. Konia z rzędem temu, kto - nie będąc w temacie - wie, czym się różni oznaczenie na obudowie IP55 od IP67. Pewnie część osób wie, że chodzi o poziomy szczelności, ale już pewnie niewielu, że pierwsza cyfra oznacza odporność na pyły i ciała stałe, a druga na ciecze. A jeszcze mniej osób zna definicje poszczególnych poziomów. I dla przykładu - jeden z poziomów opisano jako: "ochrona przed natryskiwaniem wodą pod dowolnym kątem do 60° od pionu z każdej strony”. Natryskiwanie wodą? Czyli mogę brać prysznic mając na sobie to urządzenie? Błąd! Możliwość wzięcia prysznica z tym urządzeniem będzie dopiero 2 klasy szczelności wyżej. 

Do tego większość oznaczeń standardowych - wg norm - jest po prostu niezrozumiałych dla przeciętnego zjadacza chleba. Mógłbym godzinami gapić się w te znaczki i i tak nie domyśliłbym się znaczenia większości z nich. Dlatego jeżeli tylko nie działasz na rynku regulowanym, to albo unikaj oznaczeń na obudowie, albo rób oznaczenia zrozumiałe dla użytkowników Twoich produktów. Wykorzystuj ekrany do wyświetlania istotnych komunikatów. Przygotowuj instrukcje obrazkowe, bo takie zdecydowanie częściej zostaną chociaż przejrzane. 

Diałanie w branży regulowanej oznacza ogromną biurokrację i tworzenie masy dokumentów, które nie są nikomu - poza regulatorem - potrzebne. Trzeba jednak uczciwie powiedzieć, że regulator zmusza do przemyślenia swojego procesu i dopracowania go. W naszym kraju można spotkać wiele Januszexów, które bez bata nad głową w postacie norm i certyfikacji, wypuszczałyby produkt, który mógłby stanowić zagrożenie dla zdrowia i życia użytkowników. Wiele wymagań jest naprawdę sensownych, chociażby konieczność posiadania zasad wersjonowania produktów i listę zmian w poszczególnych wersjach, albo możliwość śledzenia partii produktów, aby zidentyfikować ewentualnych nabywców wadliwych produktów. W większości wypadków to nie regulator narzuca JAK wypełnimy dane wymaganie, to my tworzymy procesy, które mają to zapewnić. I często to my sami tworzymy takie procesy, których nienawidzimy i które za wszelką cenę staramy się ominąć. Najpierw w procesie opisujemy coś tak szczegółowo, a później płaczemy, że kolejny produkt już do tego nie pasuje i trzeba dokonać skomplikowanej zmiany w zapisach. 

Dlatego Scrum Master w branży regulowanej musi naprawdę dobrze rozumieć te wszystkie zagadnienia, bo bardzo często będzie brał udział w tworzeniu takiego procesu lub będzie zobowiązany zapewniać, że przyjęte reguły są przestrzegane w zespołach. Bo pamiętajmy, że Scrum Master jest od tego, żeby usuwać i pomagać usuwać przeszkody w pracy zespołów, a nie je tworzyć.