Un guide pour le développement de produits de dispositifs médicaux Lean et Agile

Le succès des programmes de développement dans l'industrie des dispositifs et équipements médicaux repose presque toujours sur l'atteinte de jalons techniques qui coïncident avec des efforts de collecte de fonds internes ou externes.

Surtout au début du programme, il est essentiel d'atteindre les jalons techniques de manière sensible aux coûts et en temps opportun. Cela déterminera éventuellement si un programme a des jambes ou sera terminé.

Alors, à quoi ressemblent ces premiers jalons critiques ? Et que pouvons-nous faire pour atteindre ces jalons le plus rapidement possible sans dépenser trop ? Ci-dessous, je fournis quatre considérations pour exécuter des programmes de développement de produits lean et agiles.

1. Vous concevez un joueur vedette ou un facilitateur ?

L'une des premières étapes majeures de tout programme de développement est la création du premier prototype fonctionnel. L'objectif réel des tests pratiques avec les premiers prototypes fonctionnels est d'atteindre la faisabilité technique (ou «preuve de principe»). C'est le moment où l'équipe technique peut affirmer avec confiance que la technologie sous-jacente au concept de produit offre les performances requises.

Pour développer un prototype fonctionnel le plus rapidement et le plus économiquement possible, la première question à se poser est de savoir si vous concevez le joueur vedette ou le facilitateur ? Un star player est un produit dont la conception impacte directement les performances du produit. Des exemples de produits considérés comme des joueurs vedettes sont un genou artificiel ou un ventilateur qui permet aux gens de respirer pendant la chirurgie.

A l'opposé, concevoir un produit facilitateur consiste à concevoir des équipements ou des outillages qui permettent au « vrai » joueur vedette de faire son travail. Des exemples de ces types de produits sont un instrument de diagnostic (facilitant un essai pour générer une sortie de diagnostic) ou un bioréacteur (facilitant la production d'un produit biopharmaceutique).

Pour créer un prototype fonctionnel pour un produit vedette (dont la conception est directement liée à ses performances), nous devons d'abord comprendre le facteur de forme et les exigences du produit souhaité. Nous avons besoin de ces informations pour nous assurer que la conception et le facteur de forme sont représentatifs de la conception finale afin que le prototype puisse générer des données significatives sur les performances du produit.

C'est pourquoi un programme pour un produit vedette commence souvent par l'exploration des exigences/spécifications du produit, l'analyse de l'utilisabilité et des entretiens avec les principaux leaders d'opinion. Ce n'est qu'une fois ces informations recueillies que le premier prototype fonctionnel peut être créé.

En revanche, pour un produit facilitateur, le facteur de forme final n'est pas nécessaire pour tester les performances du « vrai » joueur vedette. Par exemple, un système de planche à pain brut construit à l'aide de composants prêts à l'emploi (non personnalisés) peut être utilisé pour répondre à des questions telles que : mon test génère-t-il le résultat de diagnostic correct ? Ou, mon produit pharmaceutique est-il en quantité et en qualité suffisantes?

Au départ, l'exercice d'exploration des exigences du produit, l'analyse de l'utilisabilité et les entretiens avec les principaux leaders d'opinion sont réduits au minimum. Seules les mesures relatives à la performance (par exemple, la sensibilité, la spécificité, la quantité de produits biopharmaceutiques actifs, etc.) doivent être définies à l'avance.

Tant que les composants du prototype initial peuvent atteindre les performances prédéfinies du produit, le premier prototype fonctionnel apportera une valeur considérable en fournissant les premiers résultats de tests pratiques, même si certains des composants critiques doivent être modifiés lors des itérations de conception ultérieures.

Tous les produits ne peuvent pas facilement entrer dans les catégories «joueur vedette» ou «facilitateur». Par exemple, la catégorisation d'un dispositif d'administration de médicaments personnalisé dépend vraiment de la complexité. Si le dispositif d'administration de médicament permet une thérapie qui autrement ne pourrait pas être administrée (par exemple en administrant un médicament à une partie spécifique du cerveau qui est actuellement hors de portée), l'appareil pourrait être considéré comme un joueur vedette.

Alors que, si le dispositif d'administration de médicaments fournit une solution plus rentable à un traitement préexistant, le produit pourrait être considéré comme un facilitateur.

En bref, presque tous les programmes de développement viseront à atteindre la faisabilité technique le plus rapidement et le moins cher possible en créant et en testant des prototypes fonctionnels. Pour les produits phares, il faut généralement plus de temps (et c'est plus coûteux) pour atteindre cette étape majeure, car une définition plus poussée du produit est nécessaire pour créer un prototype fonctionnel significatif.

Pour les produits facilitateurs, étant donné qu'une grande partie de la conception et du facteur de forme peut être modifiée ultérieurement, vous pouvez commencer à créer un prototype fonctionnel presque immédiatement tout en répondant aux exigences et aux spécifications du produit en arrière-plan.

Figure 1. Les deux programmes travaillent vers la "preuve de principe" aussi vite que possible. Cependant, au départ, un programme de développement pour un produit Star Player est plus axé sur la définition du produit qu'un programme pour un produit Facilitator qui passe directement à la création d'un prototype pour tester les performances et atteindre la faisabilité technique.

2. Conception – test – conception – test – conception – test….. arrêtez.

Bien que le premier prototype soit toujours conçu avec l'intention d'atteindre la faisabilité technique, il est rare qu'un premier prototype atteigne tous les objectifs. Plusieurs itérations peuvent être nécessaires. C'est pourquoi, au cœur des programmes de développement de produits lean et agiles, il y a des cycles rapides d'itérations de conception, de test, d'apprentissage et d'intégration des apprentissages dans l'itération suivante.

Garder toutes les activités de développement non essentielles au minimum pendant cette période permet de concentrer l'équipe et d'accélérer le développement. À ce stade, l'ajustement et la réaffectation des constructions de prototypes pour améliorer les performances doivent être effectués librement sans entraver des systèmes de qualité plus rigoureux.

Pour être clair, ces systèmes de qualité rigoureux sont essentiels à un stade ultérieur du programme, mais conserver une documentation « légère » au début du programme permet d'accélérer le développement.

Les itérations rapides sont importantes pour un développement de produit précoce lean et agile. Mais il en va de même pour savoir quand arrêter d'itérer et célébrer le succès. Je n'ai pas encore rencontré d'équipe technique qui ne pense pas que "plus d'améliorations feraient un meilleur produit". Et ils devraient donc! C'est leur travail de s'efforcer de trouver la meilleure solution de conception possible.

C'est pourquoi l'objectif d'atteindre des mesures de performance prédéfinies (par exemple, la détection de x quantité d'analyte est atteinte, ou l'échantillon est stable pendant x durée, etc.) doit être clairement énoncé dès le début et réitéré tout au long du processus. projet.

Lorsque les performances souhaitées sont atteintes, cela signifie que la faisabilité technique est atteinte. Cela signifie que le programme passera à la prochaine phase de conception (qui implique la construction d'un prototype plus raffiné).

C'est également le bon moment pour commencer à générer une documentation plus détaillée décrivant l'architecture du prototype et commencer à consolider les exigences du produit. Cette documentation reste relativement fluide (en dehors du contrôle de la conception) jusqu'à plus tard dans le programme.

La documentation de ces informations facilite la communication interne et externe, l'intégration de membres supplémentaires de l'équipe et la sauvegarde du travail jusqu'à ce point.

3. Comment atteindre les jalons du programme avec l'équipe la plus agile possible

Il est souvent tentant de consacrer plus de ressources à un programme, en supposant que plus de personnes intelligentes signifient des solutions plus rapides et meilleures. Surtout dans les industries réglementées (comme les industries des dispositifs médicaux et pharmaceutiques), les systèmes organisationnels en vigueur peuvent également pousser à recruter des membres supplémentaires de l'équipe qui n'ont pas encore besoin d'être là.

Les représentants des fonctions qui ne sont nécessaires que plus tard peuvent être inclus dès le début, ce qui entraîne une charge de frais généraux et de communication importante. Le résultat est plus de 20 personnes assises dans des réunions essayant de faire avancer un programme.

Malgré la grande taille des équipes, ces programmes sont souvent lents à démarrer. Ainsi, bien que cela puisse sembler contre-intuitif, j'ai constaté que des équipes multidisciplinaires plus petites et dédiées peuvent agir plus rapidement et générer une quantité disproportionnée d'innovation au cours du développement initial du produit.

Le concept de limiter la taille de l'équipe pour obtenir d'excellents résultats n'est pas nouveau. Jeff Bezos, fondateur et ancien PDG d'Amazon, a reconnu ce phénomène et a institué la règle selon laquelle chaque équipe doit être suffisamment petite pour pouvoir être nourrie avec deux pizzas.

La «règle des deux pizzas» est étayée par d'innombrables articles de recherche et livres indiquant que les petites équipes sont plus innovantes et comprennent des membres d'équipe plus heureux [1, 2, 3].

Figure 2. La charge de communication augmente de façon exponentielle avec le nombre de personnes dans l'équipe, comme le montre cette figure. Les points noirs représentent les membres individuels de l'équipe et les lignes représentent les connexions uniques entre les individus.

Dans la figure 2, vous pouvez voir que la taille de l'équipe est liée de manière exponentielle à la charge de communication. L'ajout d'un membre supplémentaire à l'équipe peut sembler peu, mais cela peut en fait entraîner une charge supplémentaire importante et des désalignements. Surtout au début du développement de produits, limiter la taille de l'équipe à 5 membres maximum facilite vraiment le développement rapide et allégé.

La dichotomie apparente dans ce concept est que les problèmes qui doivent être résolus dans le développement de dispositifs médicaux nécessitent souvent des compétences spécialisées. Il est extrêmement rare de trouver toutes les compétences requises chez un petit nombre d'individus. Ainsi, le défi est de savoir comment mettre en place une petite équipe capable d'exécuter rapidement et avec agilité tout en ayant accès à des niveaux de connaissances / d'expérience plus approfondis.

Malheureusement, il n'y a pas d'équipe unique, mais j'ai vu les équipes les plus performantes se composer de quelques responsables techniques qui s'occupent des problèmes de conception. La plupart du temps, ces leaders techniques sont des personnes bien équilibrées avec de nombreuses années d'expérience. Ils savent quand rechercher une consultation interne ou externe dans des domaines où ils ne sont pas experts.

Dans cette structure, le responsable technique définit la définition du problème et trace le paysage de la solution avant de consulter.

Le consultant (interne ou externe) ne fait pas partie de l'équipe de base (limitant ainsi la charge de communication) mais est toujours en mesure d'apporter une expertise pour les solutions proposées. Souvent, la communication entre les responsables techniques et les consultants se produit lors de petites réunions qui n'incluent pas toute l'équipe.

Le responsable technique s'assure que les solutions proposées correspondent aux plans de conception de prototypes plus larges et possède finalement une partie importante de l'architecture du prototype.

Un avantage supplémentaire de cette structure est que les responsables techniques ressentent un grand sens des responsabilités face à leurs défis techniques et peuvent vraiment célébrer et s'approprier leurs succès.

4. Nommer un champion du programme

Les responsables techniques possèdent une partie de l'architecture du système, mais il doit également y avoir un champion du programme qui possède le succès du programme. Cette personne est ultimement responsable de l'ensemble du programme et s'assure que les bonnes personnes travaillent sur les bonnes solutions de conception.

Un champion de programme peut avoir plusieurs titres (par exemple chef de produit, responsable de programme, directeur de la R&D, CSO, CTO, etc.), mais son rôle n'est pas défini par le titre. C'est quelqu'un qui se sent responsable de la réussite du programme et qui est capable d'examiner les différentes pièces du puzzle d'une manière plus holistique.

Le champion du programme naviguera également dans le conflit sain entre l'équipe technique (avec le désir d'apporter de nouvelles améliorations) et le chef de projet (avec le désir de livrer dans les délais et dans les limites du budget). La gestion d'un programme de développement qui inclut l'innovation, beaucoup d'incertitudes et de nouvelles technologies, exige toujours des compromis de la part des deux parties.

En fin de compte, la gestion efficace de ce conflit est un élément clé de la gestion réussie d'une équipe de développement lean et agile.

Figure 3. Un champion de programme gère les conflits nécessaires et sains qui existent entre l'équipe technique, le chef de projet et l'équipe/responsable produit. Un champion de programme peut être un responsable de programme dédié, un CTO, un CSO, un directeur R&D, ou il peut être un membre de l'équipe technique ou produit. Plus important encore pour ce rôle, ils doivent être capables de gérer les conflits de manière impartiale.

Une autre responsabilité du champion du programme est de trouver un alignement entre l'équipe technique et le chef de produit. Le chef de produit est responsable du profil produit cible et de la fixation des objectifs commerciaux.

Dans les premiers programmes de développement, j'ai constaté que le rôle de chef de produit n'était peut-être pas rempli par une personne dédiée, mais qu'au lieu de cela, le rôle était souvent confié à plusieurs personnes.

Aider à aligner ces personnes pour piloter la vision du produit et les exigences du produit, et faciliter la conversation entre l'équipe technique et l'équipe de gestion du produit est essentiel pour arriver à une conception de produit qui répond aux attentes et répond à un besoin du marché.

Résumé

En résumé, la mise en place d'un programme de développement produit lean et agile commence par la définition des activités qui permettront d'atteindre la faisabilité technique le plus rapidement possible. Avoir une petite équipe dédiée de responsables techniques expérimentés qui conçoivent, construisent et testent rapidement des itérations de prototypes définit une structure agile et rentable.

Enfin, il est essentiel de nommer un champion du programme qui aide à l'alignement global, appelle le moment où la faisabilité technique est accomplie et gère les conflits sains qui devraient exister entre l'équipe technique, le chef de projet et l'équipe/responsable produit.

1. Steiner ID., 1972. Processus et productivité du groupe. New York : Presse académique.
2. PR de Laughlin. et al., 2006. Les groupes réussissent mieux que les meilleurs individus sur les problèmes de lettres à chiffres : effets de la taille du groupe. Journal de la personnalité et de la psychologie sociale, 90(4), 644-651.
3. Brett J. et Wang D., 2020, Si vous voulez des solutions créatives, gardez votre équipe petite, Scientifique américain

Image: Peut Stock Photo / olivier26

Joris van der Heijden est responsable du programme Bio Services chez StarFish Médical. Auparavant, il était directeur de la R&D chez Spartan Bioscience, où il a dirigé le développement d'un test de diagnostic COVID-19 au point de service. Joris a obtenu son doctorat en maladies infectieuses de l'UBC.

[Contenu intégré] 

---

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/