CTO w MedTech: czego nauczyły mnie testy urządzenia medycznego w Ghanie

W projektach MedTech łatwo wpaść w pułapkę myślenia, że jeżeli urządzenie przeszło testy, to znaczy, że jest gotowe.

Działało w laboratorium. Działało podczas wcześniejszych testów. Działało przez określony czas. Wyniki były dobre.

Problem w tym, że urządzenie nie będzie działać w laboratorium. Będzie działać w rzeczywistym świecie.

Przekonałem się o tym bardzo konkretnie podczas pracy przy projekcie RescueGlass. I była to jedna z tych sytuacji, które dobrze pokazują, dlaczego rola CTO w MedTech nie kończy się na wyborze technologii.

RescueGlass — pomysł był prosty

Kiedy zaczynałem pracę przy RescueGlass, projekt był dla mnie bardzo interesujący. Koncepcja opierała się na inteligentnych okularach, które mogły być wykorzystane przez ratownika albo zwykłą osobę znajdującą się przy poszkodowanym.

Idea była prosta: wypadek → osoba na miejscu → okulary → połączenie z profesjonalnym ratownikiem → instrukcje → pomoc.

Dlaczego miało to sens? Bo pomiędzy momentem zdarzenia a przyjazdem profesjonalnych służb może minąć kilka lub kilkanaście minut. A w sytuacjach zagrożenia życia te minuty mogą mieć ogromne znaczenie.

Zamiast więc czekać bezczynnie na przyjazd karetki, osoba znajdująca się na miejscu mogłaby otrzymać instrukcje od profesjonalnego ratownika. Okulary miały umożliwić przekazanie obrazu i komunikację z ratownikiem poprzez aplikację.

To był bardzo ciekawy kierunek rozwoju produktu MedTech. I właśnie wtedy pojawił się temat Ghany.

Testy urządzenia w Ghanie

Zespół pojechał do Ghany, aby przeprowadzić testy okularów. Na pierwszy rzut oka wszystko było w porządku. Urządzenie było wcześniej testowane. Software działał. Hardware działał. Produkt był rozwijany i przygotowywany do kolejnych etapów projektu.

Tylko że kiedy zacząłem dokładniej analizować kod i hardware, zwróciłem uwagę na coś, co mogło stać się problemem.

„Przecież urządzenie było już testowane"

To był naturalny argument. I trudno się z nim nie zgodzić. Skoro urządzenie było testowane i działało, dlaczego miałoby nagle przestać działać?

Problem polegał na tym, że słowo „testowane" nie mówi nam jeszcze, w jakich warunkach było testowane.

• Temperatura.
• Wilgotność.
• Nasłonecznienie.
• Czas pracy.
• Obciążenie procesora.
• Praca komunikacji bezprzewodowej.
• Zużycie baterii.
• Sposób użytkowania.

Wszystkie te elementy mogą wpływać na zachowanie urządzenia. A elektronika ma jeszcze jedną cechę: generuje ciepło.

Miałem złe przeczucie

Po przeanalizowaniu hardware'u i sposobu działania systemu powiedziałem zespołowi, żeby test przeprowadzić możliwie szybko. Nie dlatego, że znałem dokładny czas działania urządzenia w tych warunkach. Chodziło o coś innego.

Podejrzewałem, że temperatura otoczenia może znacząco wpłynąć na zachowanie urządzenia. W Polsce urządzenie mogło pracować w określonych warunkach. W Ghanie temperatura i warunki środowiskowe były zupełnie inne. Do tego dochodziło nagrzewanie samego urządzenia podczas pracy.

Dlatego moja rekomendacja była prosta: Zróbcie test szybko. Nie zakładajmy, że wcześniejsze wyniki automatycznie przełożą się na te warunki.

I zaczęły się testy

Test był ważny. Nie był to zwykły wewnętrzny eksperyment. Wyniki miały znaczenie również w kontekście projektu i materiałów przygotowywanych dla inwestora. Czyli pojawiła się presja. Urządzenie musiało działać.

I przez pewien czas rzeczywiście działało. A później wydarzyło się dokładnie to, czego się obawiałem.

Około 10 minut

Po około dziesięciu minutach okulary się wyłączyły.

Nie dlatego, że ktoś źle napisał kod. Nie dlatego, że aplikacja nagle przestała działać. Problemem okazały się warunki pracy urządzenia. Sprzęt zaczął się przegrzewać i system przestał działać.

I właśnie tutaj pojawiła się bardzo ważna lekcja. Wcześniejsze testy nie były bezużyteczne. One po prostu odpowiadały na inne pytanie.

Nie: „Czy urządzenie działa w każdych warunkach?"

Tylko: „Czy urządzenie działa w warunkach, w których zostało przetestowane?"

Na szczęście udało się przygotować potrzebny materiał i projekt mógł być dalej rozwijany. Ale dla mnie sam incydent był bardzo wartościowy. Bo pokazał problem, który występuje nie tylko w hardware. Występuje w praktycznie każdym projekcie technologicznym.

„Działa" nie oznacza „jest gotowe"

To jedna z najważniejszych rzeczy, których nauczyła mnie praca przy projektach technologicznych.

Możemy powiedzieć: „System działa." Ale natychmiast powinno pojawić się pytanie: „W jakich warunkach?"

Możemy powiedzieć: „Urządzenie przeszło testy." I znowu: „Jakie testy?"

Możemy powiedzieć: „Produkt działał przez godzinę." I pytanie: „W jakiej temperaturze, przy jakim obciążeniu i w jakich warunkach sieciowych?"

To właśnie różnica między prostym sprawdzeniem funkcjonalności a testowaniem gotowości produktu do rzeczywistego zastosowania.

„Works on my machine" istnieje również w MedTech

Programiści doskonale znają zdanie: „U mnie działa." W przypadku urządzeń fizycznych można powiedzieć: „U nas działało."

To jeszcze niczego nie gwarantuje. Może działać w Polsce, ale nie w Ghanie. Może działać przez 30 minut, ale nie przez 3 godziny. Może działać przy 20°C, ale nie przy 35°C. Może działać przy dobrej sieci, ale nie przy słabym zasięgu.

Dlatego warunki środowiskowe nie są dodatkiem do testów. Są częścią testowanego produktu.

To szczególnie ważne w MedTech

W przypadku zwykłego urządzenia konsumenckiego awaria może oznaczać: „Urządzenie się wyłączyło." W MedTech konsekwencje mogą być znacznie poważniejsze. Produkt może mieć kontakt z pacjentem, ratownikiem, personelem medycznym, danymi medycznymi lub procesem decyzyjnym.

Dlatego projektowanie produktu MedTech wymaga myślenia nie tylko o tym, czy funkcja działa, ale również o tym: co dzieje się, kiedy funkcja przestaje działać.

Co powinien sprawdzać CTO w projekcie MedTech?

Przy projekcie wykorzystującym hardware, software i komunikację nie wystarczy testować każdego elementu osobno. Trzeba patrzeć na cały system.

Jak podchodzę do tego jako CTO?

Najpierw próbuję znaleźć założenia. Każdy projekt ma ich mnóstwo.

• Użytkownik będzie korzystał z urządzenia w określony sposób.
• Temperatura nie będzie problemem.
• Sieć będzie wystarczająca.
• Bateria wystarczy.
• Ten komponent będzie działał przez cały dzień.

Każde z tych zdań może być prawdziwe. Ale powinno paść pytanie: „Skąd to wiemy?"

Jeżeli odpowiedź brzmi: „Bo wcześniej działało." — to mamy hipotezę. Nie dowód.

Najdroższe problemy często zaczynają się od małego założenia

Kilka godzin dodatkowych testów może kosztować niewiele. Odkrycie problemu podczas demonstracji dla inwestora może kosztować znacznie więcej. A znalezienie go dopiero po wdrożeniu może być katastrofalne.

10 minut, które zostały mi w pamięci

Historia RescueGlass była dla mnie jedną z tych sytuacji, które dobrze zapamiętuje się właśnie dlatego, że problem pojawił się w najmniej wygodnym momencie.

Urządzenie działało. Testy wcześniej były wykonywane. Projekt był przygotowywany. A jednak zmiana warunków wystarczyła, żeby po około dziesięciu minutach urządzenie przestało działać.

Na szczęście udało się przygotować materiał i projekt mógł być kontynuowany. Ale sama sytuacja pokazała mi coś ważniejszego:

Najważniejsze pytanie nie brzmi „czy działa?"

W projektach MedTech znacznie lepszy zestaw pytań brzmi:

• W jakich warunkach działa?
• Jak długo działa?
• Co powoduje jego ograniczenia?
• Co stanie się, kiedy warunki się zmienią?
• Jak system zachowa się w przypadku awarii?
• Czy użytkownik rzeczywiście będzie korzystał z niego tak, jak zakładaliśmy?

Dopiero odpowiedzi na te pytania pozwalają ocenić, czy technologia jest naprawdę gotowa.