Un ghid pentru dezvoltarea produselor pentru dispozitive medicale Lean și Agile

Succesul programelor de dezvoltare în industria dispozitivelor și echipamentelor medicale se bazează aproape întotdeauna pe atingerea reperelor tehnice care coincid cu eforturile interne sau externe de strângere de fonduri.

Mai ales la începutul programului, este esențial să atingeți reperele tehnice într-o manieră sensibilă la costuri și în timp util. Acest lucru va determina în cele din urmă dacă un program are segmente sau va fi terminat.

Deci, cum arată aceste prime etape critice? Și ce putem face pentru a atinge aceste repere cât mai repede posibil, fără a cheltui prea mult? Mai jos, ofer patru considerații pentru a rula programe de dezvoltare a produselor lean și agile.

1. Proiectezi un jucător vedetă sau un facilitator?

Unul dintre primele repere majore în orice program de dezvoltare este crearea primului prototip funcțional. Scopul real al testării practice cu prototipuri de lucru timpurii este atingerea fezabilității tehnice (sau „Dovada principiului”). Acesta este momentul în care echipa tehnică poate spune cu încredere că tehnologia de bază pentru conceptul de produs oferă performanța necesară.

Pentru a dezvolta un prototip de lucru cât mai rapid și cât mai rentabil posibil, prima întrebare pe care trebuie să vă puneți este dacă proiectați jucătorul vedetă sau facilitatorul? Un jucător vedetă este un produs pentru care designul are un impact direct asupra performanței produsului. Exemple de produse care sunt considerate jucători vedete sunt un genunchi artificial sau un ventilator care ține oamenii să respire în timpul intervenției chirurgicale.

În schimb, proiectarea unui produs care este un facilitator implică proiectarea de echipamente sau unelte care îi permit jucătorului „adevărat” vedetă să-și facă treaba. Exemple de aceste tipuri de produse sunt un instrument de diagnostic (care facilitează un test pentru a genera un rezultat de diagnostic) sau un bioreactor (care facilitează producerea unui produs biofarmaceutic).

Pentru a realiza un prototip funcțional pentru un produs star player (pentru care designul este direct legat de performanța sa), trebuie să înțelegem mai întâi factorul de formă și cerințele produsului dorit. Avem nevoie de aceste informații pentru a ne asigura că designul și factorul de formă sunt reprezentative pentru designul final, astfel încât prototipul să poată genera date semnificative despre performanța produsului.

Acesta este motivul pentru care un program pentru un produs de jucător vedetă începe adesea cu explorarea cerințelor/specificațiilor produsului, analiză de utilizare și interviuri cu lideri de opinie cheie. Numai după ce aceste informații sunt adunate, poate fi creat primul prototip de lucru.

În schimb, pentru un produs facilitator, factorul de formă final nu este necesar pentru a testa performanța jucătorului „adevărat”. De exemplu, un sistem de placă brută care este construit folosind componente disponibile (nepersonalizate) poate fi utilizat pentru a răspunde la întrebări precum: testul meu generează rezultatul de diagnosticare corect? Sau, produsul meu medicamentos este de cantitate și calitate suficientă?

Inițial, exercițiul de explorare a cerințelor de produs, analiză de utilizare și interviuri cu lideri de opinie cheie este redus la minimum. Doar valorile care se referă la performanță (de exemplu, sensibilitatea, specificitatea, cantitatea de produse biofarmaceutice active etc.) trebuie definite în avans.

Atâta timp cât componentele prototipului inițial pot atinge performanța predefinită a produsului, primul prototip de lucru va oferi o valoare extraordinară prin furnizarea primelor rezultate ale testelor practice, chiar dacă unele dintre componentele critice trebuie modificate în iterațiile ulterioare de proiectare.

Nu toate produsele se pot încadra cu ușurință în categoriile „jucător vedetă” sau „facilitator”. De exemplu, clasificarea unui dispozitiv personalizat de livrare a medicamentelor depinde într-adevăr de complexitate. Dacă dispozitivul de eliberare a medicamentului permite o terapie care altfel nu ar putea fi eliberată (de exemplu, prin administrarea unui medicament într-o anumită parte a creierului care este în prezent neaccesibil), dispozitivul ar putea fi considerat un jucător vedetă.

În timp ce, dacă dispozitivul de livrare a medicamentelor oferă o soluție mai rentabilă pentru un tratament preexistent, produsul ar putea fi considerat un facilitator.

Pe scurt, aproape fiecare program de dezvoltare va avea ca scop atingerea fezabilității tehnice cât mai curând și mai ieftin posibil prin crearea și testarea prototipurilor funcționale. Pentru produsele star player, de obicei durează mai mult (și este mai costisitor) pentru a atinge această etapă majoră, deoarece este nevoie de mai multă definiție a produsului pentru a crea un prototip de lucru semnificativ.

Pentru produsele facilitatoare, deoarece o mare parte din designul și factorul de formă pot fi modificate ulterior, puteți începe să creați un prototip funcțional aproape imediat, în timp ce abordați cerințele și specificațiile produsului în fundal.

Figura 1. Ambele programe lucrează pentru „Proof Of Principle” cât mai repede posibil. Cu toate acestea, inițial, un program de dezvoltare pentru un produs Star Player este mai axat pe definirea produsului decât un program pentru un produs Facilitator care trece direct în crearea unui prototip pentru a testa performanța și a obține fezabilitatea tehnică.

2. Proiectare – testare – proiectare – testare – proiectare – testare….. stop.

Deși primul prototip este întotdeauna proiectat cu intenția de a atinge fezabilitatea tehnică, rareori un prim prototip atinge toate semnele. Pot fi necesare mai multe iterații. Acesta este motivul pentru care, în centrul programelor de dezvoltare a produselor lean și agile, există cicluri rapide de iterații de proiectare, testare, învățare și încorporare a învățăturilor în următoarea iterație.

Menținerea la minimum a tuturor activităților de dezvoltare neesențiale în acest timp ajută la concentrarea echipei și accelerează dezvoltarea. În această etapă, modificarea și reutilizarea modelelor de prototip pentru o performanță îmbunătățită ar trebui să se facă în mod liber, fără impedanța unor sisteme de calitate mai riguroase.

Pentru a fi clar, aceste sisteme de calitate riguroase sunt critice într-o etapă ulterioară a programului, dar păstrarea documentației „ușoare” la începutul programului ajută la accelerarea dezvoltării.

Iterațiile rapide sunt importante pentru dezvoltarea timpurie a produsului lean și agilă. Dar la fel este și a ști când să nu mai repeți și să sărbătorim succesul. Încă nu am întâlnit o echipă tehnică care să nu creadă că „mai multe îmbunătățiri ar face un produs mai bun”. Și așa ar trebui! Este datoria lor să se străduiască pentru cea mai bună soluție de proiectare posibilă.

De aceea, obiectivul de a atinge valorile de performanță predefinite (de exemplu, detectarea cantității x de analit este atinsă sau proba este stabilă pentru o perioadă de timp x etc.) ar trebui să fie clar de la început și reiterat pe tot parcursul proiect.

Când performanța dorită este atinsă, înseamnă că este atinsă fezabilitatea tehnică. Aceasta înseamnă că programul se va transfera în următoarea fază de proiectare (care implică construirea unui prototip mai rafinat).

Acesta este, de asemenea, momentul potrivit pentru a începe generarea de documentație mai detaliată care descrie arhitectura prototipului și pentru a începe consolidarea cerințelor de produs. Această documentație rămâne relativ fluidă (în afara controlului de proiectare) până mai târziu în program.

Documentarea acestor informații ajută la comunicarea internă și externă, la integrarea membrilor suplimentari ai echipei și la protejarea muncii până la acel moment.

3. Cum să atingeți reperele programului cu cea mai agilă echipă posibilă

Există adesea tentația de a arunca mai multe resurse într-un program, presupunând că mai mulți oameni inteligenți înseamnă soluții mai rapide și mai bune. În special în industriile reglementate (cum ar fi industria dispozitivelor medicale și industria farmaceutică), sistemele organizaționale predominante pot, de asemenea, să pretindă pentru membri suplimentari ai echipei care nu trebuie încă să fie acolo.

Reprezentanții funcțiilor care sunt solicitați doar mai târziu pot fi incluși de la început, ceea ce duce la o povară mare și de comunicare. Rezultatul este peste 20 de persoane care stau la întâlniri și încearcă să avanseze un program.

În ciuda dimensiunilor mari ale echipelor, aceste programe încep adesea încet. Astfel, deși acest lucru poate suna contraintuitiv, am descoperit că echipele multidisciplinare mai mici și dedicate se pot mișca mai repede și pot genera o cantitate disproporționată de inovație în timpul dezvoltării timpurii a produsului.

Conceptul de limitare a dimensiunii echipei pentru a produce rezultate excelente nu este nou. Jeff Bezos, fondatorul și fostul CEO al Amazon, a recunoscut acest fenomen și a instituit regula ca fiecare echipă să fie suficient de mică pentru a putea fi hrănită cu două pizza.

„Regula celor două pizza” este susținută de nenumărate articole de cercetare și cărți care indică faptul că echipele mici sunt mai inovatoare și includ membri ai echipei mai fericiți [1, 2, 3].

Figura 2. Sarcina de comunicare crește exponențial odată cu numărul de oameni din echipă, așa cum se arată în această figură. Punctele negre reprezintă membri individuali ai echipei, iar liniile reprezintă conexiuni unice între indivizi.

În figura 2 puteți vedea că dimensiunea echipei este legată exponențial de sarcina de comunicare. Adăugarea unui membru suplimentar al echipei poate să nu arate prea mult, dar poate duce de fapt la o povară suplimentară semnificativă și la nealinieri greșite. În special în dezvoltarea timpurie a produsului, limitarea dimensiunii echipei la cel mult 5 membri ajută într-adevăr o dezvoltare rapidă și simplă.

Dihotomia aparentă în acest concept este că problemele care trebuie rezolvate în dezvoltarea dispozitivelor medicale necesită adesea abilități de experți. Este extrem de rar să găsești toate abilitățile necesare la un număr mic de indivizi. Așadar, provocarea este cum să înființezi o echipă mică care să poată executa agil și rapid, având acces la niveluri mai profunde de cunoștințe/experiență.

Din păcate, nu există o echipă universală, dar am văzut că există cele mai de succes echipe din doar câțiva lideri tehnici care dețin problemele de proiectare. În cea mai mare parte, acești lideri tehnici sunt persoane complete, cu mulți ani de experiență. Ei știu când să caute consultanță internă sau externă în domenii în care nu sunt experți.

În această structură, liderul tehnic încadrează definiția problemei și elaborează peisajul soluției înainte de a se consulta.

Consultantul (intern sau extern) nu face parte din echipa de bază (limitând astfel sarcina de comunicare), dar este totuși capabil să ofere cunoștințe de specialitate pentru soluțiile propuse. Adesea comunicarea între liderii tehnici și consultanți are loc în ședințe mici care nu includ întreaga echipă.

Liderul tehnic se asigură că soluțiile propuse se potrivesc cu planurile mai mari de proiectare a prototipului și deține în cele din urmă o parte semnificativă a arhitecturii prototipului.

Un avantaj suplimentar al acestei structuri este că liderii tehnici simt un mare simț al responsabilității față de provocările lor tehnice și își pot sărbători cu adevărat succesele și își pot deține.

4. Numiți un campion al programului

Liderii tehnici dețin o parte din arhitectura sistemului, dar trebuie să existe și un campion al programului care să dețină succesul programului. Această persoană este responsabilă în cele din urmă pentru întregul program și se asigură că oamenii potriviți lucrează la soluțiile de proiectare potrivite.

Un campion de program poate avea multe titluri (ex. manager de produs, manager de program, director de cercetare și dezvoltare, CSO, CTO etc.), dar rolul lor nu este definit de titlu. Acesta este cineva care se simte responsabil pentru un rezultat de succes al programului și este capabil să privească diferitele piese ale puzzle-ului într-o manieră mai holistică.

Campionul programului va naviga și în conflictul sănătos dintre echipa tehnică (cu dorința de a face îmbunătățiri suplimentare) și managerul de proiect (cu dorința de a livra la timp și la buget). Derularea unui program de dezvoltare care include inovație, multe incertitudini și tehnologii noi, necesită întotdeauna compromisuri din partea ambelor părți.

În cele din urmă, navigarea eficientă a conflictului este o componentă cheie a conducerii unei echipe de dezvoltare flexibile și agile de succes.

Figura 3. Un campion al programului navighează în conflictele necesare și sănătoase care există între echipa tehnică, managerul de proiect și echipa/managerul de produs. Un campion de program poate fi un manager de program dedicat, CTO, CSO, director de cercetare și dezvoltare sau poate fi membru al echipei tehnice sau de produs. Cel mai important pentru acest rol, ei trebuie să fie capabili să navigheze în conflicte în mod imparțial.

O altă responsabilitate a campionului programului este găsirea alinierii între echipa tehnică și managerul de produs. Managerul de produs este responsabil pentru profilul produsului țintă și pentru stabilirea obiectivelor comerciale.

În programele de dezvoltare timpurie, am descoperit că rolul de manager de produs poate să nu fie ocupat de o persoană dedicată, ci, în schimb, rolul trăiește adesea în cadrul mai multor persoane.

Ajutarea la alinierea acestor persoane pentru a conduce viziunea asupra produsului și cerințele produsului și facilitarea conversației dintre echipa tehnică și echipa de management al produsului este esențială pentru a ajunge la un design de produs care să îndeplinească așteptările și să satisfacă nevoia pieței.

Rezumat

Pe scurt, stabilirea unui program de dezvoltare a produsului lean și agil începe cu definirea activităților care vor atinge fezabilitate tehnică cât mai curând posibil. Având o echipă mică și dedicată de lideri tehnici cu experiență, care proiectează, construiesc și testează rapid iterațiile prototipului stabilește o structură agilă și rentabilă.

În cele din urmă, este esențial să numiți un campion al programului care să ajute la alinierea generală, să cheme momentul în care se realizează fezabilitatea tehnică și să navigheze în conflictele sănătoase care ar trebui să existe între echipa tehnică, managerul de proiect și echipa/managerul de produs.

1. Steiner ID., 1972. Procesul de grup și productivitatea. New York: Academic Press.
2. Laughlin PR. et al., 2006. Grupurile au rezultate mai bune decât cei mai buni indivizi în problemele de la litere la numere: Efectele dimensiunii grupului. Jurnalul de Psihologie de Personalitate și Socială, 90(4), 644-651.
3. Brett J. și Wang D., 2020, Dacă doriți soluții creative, păstrați-vă echipa mică, Scientific American

Imagine: Can Fotografie / olivier26

Joris van der Heijden este Bio Services Program Manager la Starfish Medical. Anterior, a fost director de cercetare și dezvoltare la Spartan Bioscience, unde a condus dezvoltarea unui test de diagnosticare COVID-19 la punctul de îngrijire. Joris și-a luat doctoratul în boli infecțioase de la UBC.

[Conținutul încorporat] 

---

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/