Šta smo naučili isporučujući connected healthtech proizvod: beleške sa tableta, senzora i cloud-a

U healthtech-u, najlakše greške su istovremeno i najskuplje. I obično u prvi mah ne izgledaju kao greške. Session ID koji je tehnički validan string. Timestamp koji je „otprilike“ tačan. Video koji se učitava tri sekunde umesto da bude embedovan u aplikaciji. Exit dugme koje ne vraća korisnika u glavnu aplikaciju. Svaki od ovih problema, posmatran zasebno, je jedna sitna stavka u backlog-u. Zajedno, oni odlučuju da li proizvod može da se prikaže klijentu koji plaća ili ne može.

Tokom protekle godine, preuzeli smo connected fitness i rehabilitacioni sistem od prethodnog razvojnog tima i doveli ga u stanje u kojem je spreman za demo i izlazak pred klijente. Želim da podelim lekcije koje su izašle iz tog rada, jer skoro nijedna od njih nije specifična za taj konkretan proizvod. One se pojavljuju svaki put kada ozbiljna healthtech kompanija pokuša da pređe sa prototipa koji „radi“ na nešto što lekar, trener, ili krajnji klijent može stvarno da uzme u ruke.

Imena klijenta i proizvoda sam namerno izostavio. Poenta nije ko. Poenta je šta cloud plus device proizvod mora da reši pre nego što zaslužuje poverenje.

Oblik problema

Proizvod na kome smo radili prati šablon koji je danas uobičajen u healthtech-u i connected fitness prostoru: tablet aplikacija koja vodi korisnika kroz sesiju, set IMU senzora koji se nose na telu i hvataju podatke o pokretu, companion aplikacija od proizvođača senzora koja se bavi upload-om podataka, i cloud backend koji radi signal processing nad uhvaćenim podacima i vraća koristan izlaz (recap, grafikon, struktuirani export).

Težak deo ovakvog sistema je to što nijedan pojedinačni komad nije težak sam po sebi. Tablet aplikacija je relativno standardno vođeno iskustvo. Senzori su off-the-shelf. Cloud pipeline je rešiv uobičajenim alatima. Ono što je zaista teško je koreografija između njih. Svaki handoff je potencijalni failure mode. Svaka pretpostavka koju jedna komponenta pravi o drugoj je mesto na kojem se realnost vremenom ne slaže.

Sistem koji smo nasledili je bio izgrađen tako da pojedinačni komadi rade, ali koreografija ne. Prvi posao je bio da utvrdimo koji od tih pokvarenih handoff-ova zaista bitan, a koji nije.

Dve ispravke koje su otključale sve

Većina inženjerskih timova zna onaj osećaj kada gleda backlog od četrdeset issue-a i pokušava da odluči koji od njih zaista pomeraju proizvod. U ovom slučaju, dva issue-a su ga pomerila.

Prvi je bio da session identifikatori nisu bili jedinstveni. Kada bi korisnik završio trening, sistem bi generisao ID. Kada bi isti korisnik završio isti trening drugi put, sistem bi generisao isti ID. Iz ugla korisnika, sve je izgledalo normalno. Iz ugla podataka, svaka nova sesija je prepisivala prethodnu, i nedelje uhvaćenih signal podataka su efektivno bile jedan zapis.

Drugi je bio da su timestamp-ovi ugrađeni u metadata sesije driftovali u odnosu na realno vreme kako je sesija odmicala. Na početku su bili blizu. Do kraja tridesetominutnog treninga, razlika je bila desetine sekundi. Cloud signal processing pipeline koristio je ove timestamp-ove da poravna IMU podatke sa vežbama koje je korisnik trebalo da izvodi. Male greške su bile recoverable. Velike nisu.

To nisu bili glamurozni bagovi. Nisu bili u nijednom user interface-u. Niko ih ne bi primetio na petominutnoj demonstraciji. Ali oni su bili razlika između sistema koji proizvodi čiste, atribuirane, uporedive podatke po korisniku i po sesiji, i sistema koji proizvodi nečitljivu kašu.

U healthtech-u, integritet podataka nije feature koji dodaješ kasnije. To je sam proizvod. U trenutku kada podaci prestanu da budu atribuirani konkretnoj sesiji, konkretnom korisniku, u konkretnom redosledu, cela downstream vrednost se urušava. Pipeline može da bude elegantan. Vizualizacije mogu da budu prelepe. Ništa od toga nije važno ako su ulazi već prepisani.

Popravili smo oba problema rano, i u trenutku kada su bili popravljeni, ostatak sistema je postao analizibilan. Tako obično ide. Dve ispravne bug ispravke mogu da otključaju mesece rada koji je prethodno bio blokiran, a niko nije ni znao da je blokiran.

Šta zaista znači „demo ready“

Druga lekcija je ona koju u healthtech engagement-ima stalno učimo iznova. Lestvica za „sistem radi u kancelariji“ i lestvica za „sistem se može pokazati klijentu koji plaća kod njega na lokaciji“ nisu ista lestvica. Nisu čak ni na istom grafiku.

Demo na lokaciji znači stajanje pored bazena, u klinici, u teretani, ili u hodniku bolnice, držeći tablet, sa senzorom prikačenim na osobu, ispred nekoga ko odlučuje da li će ti dati novac. U tom trenutku, tri stvari postaju važne koje u kancelariji nisu bile.

Prvo, mreža je nepouzdana. Video snimci vežbi koji su se učitavali bez problema preko kancelarijskog wifi-ja zakočiće se na guest mreži. Izvukli smo medije za demo sesije iz streaming putanje u potpunosti. Zamenili smo video fajlove embedovanim GIF-ovima tamo gde je gubitak u vizuelnom kvalitetu bio zanemarljiv, a dobitak u determinističkom ponašanju značajan. Predefinisali smo tri ili četiri sesije, snimili medije lokalno na uređaj, i osigurali da demo path ne zavisi od ni jednog svežeg network request-a nakon što korisnik krene.

Drugo, vizuelno okruženje je neprijateljsko. Timer za vežbu koji je bio savršeno čitljiv na stolu nije radio kada je osoba koja vežba bila metar ili dva udaljena od ekrana, često u pokretu, često sa vodom, znojem ili suncem u priči. Drastično smo povećali timer. To je tip ispravke koji se ne vidi ni na jednom arhitekturnom dijagramu, a najvažniji je u prostoriji u kojoj se demo dešava.

Treće, lanac uređaja mora da se ponaša. Companion aplikacija proizvođača senzora trebalo je da vraća korisnika u glavnu aplikaciju nakon upload-a. Nije to uvek radila. Za korisnika to izgleda kao da je ceo sistem pao. Za developera, to je dokumentovani edge case. Za sales engineer-a, to je izgubljen demo. Patchovali smo integraciju tako da korisnik uvek završi u glavnoj aplikaciji, bez obzira na to šta sensor companion misli da radi.

Nijedna od ovih ispravki nije glamurozna. Sve su razlika između zaključenog i izgubljenog deala.

Output je proizvod

Sama sesija, iz ugla operatera, je skoro nevidljiva. Ono što lekar, trener ili analitičar zaista koristi je ono što sistem proizvodi posle nje. Recap. Grafikon. Eksportabilni zapis. Sažetak koji im govori da li osoba sa kojom rade napreduje, stagnira, ili kompenzuje.

Uložili smo značajan napor u sloj outputa. Jedna web stranica, PDF, CSV, struktuirani objekat. Forma je bila manje važna od činjenice da na kraju svake sesije postoji čist, ponovljiv, eksportabilni artifakt.

Ovo je nešto u šta connected health proizvodi često nedovoljno ulažu. Tim izgradi capture iskustvo i signal processing pipeline, a output se tretira kao afterthought. Iz našeg iskustva, output je ono za šta klijent zapravo plaća. Capture je trošak proizvodnje tog outputa.

Ako gradiš connected healthtech proizvod i tvoj output sloj je hardkodiran ekran sa jednim grafikonom, to je prvo mesto u koje treba uložiti. Nije najlaskaviji savet za tim koji je upravo proveo osamnaest meseci na signal processing-u, ali je konzistentno ispravan poziv.

Cloud plus device je posebna disciplina

Veliki deo vrednosti koju gradimo u Buildcon-u nalazi se na preseku cloud aplikacija i fizičkih uređaja. Naš idealni engagement je upravo ovakav sistem: software stack koji uključuje mobilni ili tablet klijent, integriše se sa senzorima ili drugim hardverom preko Bluetooth-a ili sensor companion aplikacije, procesira uhvaćene podatke u cloud-u, i vraća koristan artifakt lekaru, sportisti, ili operateru.

Ono što smo naučili, iznova i iznova, je da ova disciplina ne nagrađuje generaliste. Čisto cloud timovi potcenjuju koliko je device lanac fragilan. Čisto mobilni timovi potcenjuju cloud i zahteve za integritetom podataka. Timovi koji isporučuju su oni koji drže oba kraja istovremeno, i koji handoff između njih tretiraju kao first class concern, a ne kao integration detail.

Nekoliko principa koje danas po default-u primenjujemo na ovim engagement-ima:

Tretiraj svaki cross-boundary identifikator kao load-bearing. Session ID, user ID, device ID, capture ID. Ako bilo koji od njih nije jedinstven, ako je nejasan ili reusable, sloj podataka je već pokvaren.

Tretiraj timestamp-ove kao ugovor, a ne kao zgodnost. Odluči odakle dolazi vreme. Odluči kako se sinhronizuje. Odluči šta se dešava kada drifta. Uradi to pre nego što napišeš ijednu liniju processing koda.

Planiraj za demo okruženje, ne za kancelarijsko. Embeduj medije. Pripremaj sesije unapred. Keširaj agresivno. Pretpostavi da će mreža otkazati u najgorem mogućem trenutku.

Učini output proizvodom. Šta god da napušta cloud na kraju sesije, recap, grafikon, export, zaslužuje istu pažnju kao i sam capture.

Tretiraj companion aplikacije i SDK-ove na koje se oslanjaš kao third party rizik. Imaće bugove. Neće se ponašati onako kako dokumentacija kaže. Gradi defanzivno na granici.

Šta te nasleđivanje koda nauči

Postoji još jedan šablon vredan imenovanja. Healthtech proizvodi često prolaze kroz više od jednog razvojnog tima. Proizvod koji smo nasledili dotakao je bar jedan prethodni tim. Isto smo videli u drugim engagement-ima.

Kada nasledjuješ kod, iskušenje je da se piše iznova. Disciplina je da se trijažira. Najveći deo onoga što je tu, obično radi. Ona dva ili tri problema koji blokiraju realni napredak su obično zakopani ispod stvari koje su očigledno ružne ali zapravo ništa ne blokiraju. Trošenje prvog meseca na prepisivanje očigledno ružnih delova je najskuplji način da izgledaš produktivno, a da pritom ništa ne isporučiš.

Pravi potez na nasleđenom kodu je da nađeš najmanji skup izmena koje deblokiraju customer journey, isporučiš ih, zaradiš poverenje, i tek tada pregovaraš o većem rewrite-u sa pozicije gde si već isporučio vrednost. To je ono što otključava ostatak engagement-a.

Zaključak

Luk ovog engagement-a je jednostavan. Nasledili smo sistem koji je uglavnom radio, ali nije bio demo ready. Popravili smo dve stvari u integritetu podataka koje van inženjerskog tima niko ne bi prioritizovao. Rekonstruisali smo demo putanju tako da preživi realno okruženje klijenta. Uložili smo u output. Držali smo cloud i device stranu sistema zajedno. I pomerili smo proizvod iz stanja u kojem je tim bio nervozan da ga stavi pred klijenta, u stanje u kojem je bio srećan da to uradi.

Ništa od ovoga nije egzotično. Lekcija je da healthtech, posebno u connected device prostoru, nagrađuje timove koji ozbiljno shvataju neglamurozne delove sistema. Session ID. Timestamp. Veličinu timera. Pre-keširani video. Exit dugme. Format eksporta.

Ako gradiš nešto u ovom prostoru, to su delovi oko kojih treba da se opsesuješ. Sve ostalo dolazi iz toga što ih radiš kako treba.