Der Erfolg von Entwicklungsprogrammen in der Medizingeräte- und Ausrüstungsindustrie hängt fast immer vom Erreichen technischer Meilensteine ​​ab, die mit internen oder externen Fundraising-Bemühungen zusammenfallen.

Besonders zu Beginn des Programms ist es entscheidend, technische Meilensteine ​​kostensensibel und zeitnah zu erreichen. Dies bestimmt schließlich, ob ein Programm Legs hat oder beendet wird.

Wie sehen also diese ersten kritischen Meilensteine ​​aus? Und was können wir tun, um diese Meilensteine ​​so schnell wie möglich zu erreichen, ohne zu viel auszugeben? Im Folgenden gebe ich vier Überlegungen zur Durchführung schlanker und agiler Produktentwicklungsprogramme an.

1. Entwerfen Sie einen Starspieler oder einen Moderator?

Einer der ersten großen Meilensteine ​​in jedem Entwicklungsprogramm ist die Erstellung des ersten funktionierenden Prototyps. Das eigentliche Ziel des Hands-on-Testens mit frühen Arbeitsprototypen ist das Erreichen der technischen Machbarkeit (oder „Proof of Principle“). Dies ist der Moment, in dem das technische Team zuversichtlich sagen kann, dass die zugrunde liegende Technologie für das Produktkonzept die erforderliche Leistung erbringt.

Um einen funktionierenden Prototypen so schnell und kostengünstig wie möglich zu entwickeln, ist die erste Frage, die Sie sich stellen müssen, ob Sie den Starspieler oder den Moderator entwerfen? Ein Starplayer ist ein Produkt, dessen Design sich direkt auf die Produktleistung auswirkt. Beispiele für Produkte, die als Starspieler gelten, sind ein künstliches Knie oder ein Beatmungsgerät, das Menschen während einer Operation atmen lässt.

Im Gegensatz dazu beinhaltet das Entwerfen eines Produkts, das ein Vermittler ist, das Entwerfen von Ausrüstung oder Werkzeugen, die es dem „echten“ Starspieler ermöglichen, seine Arbeit zu erledigen. Beispiele für diese Arten von Produkten sind ein diagnostisches Instrument (das einen Assay erleichtert, um ein diagnostisches Ergebnis zu erzeugen) oder ein Bioreaktor (der die Herstellung eines Biopharmazeutikums erleichtert).

Um einen funktionierenden Prototyp für ein Star-Player-Produkt zu erstellen (bei dem das Design direkt mit seiner Leistung verbunden ist), müssen wir zunächst den Formfaktor und die Anforderungen des gewünschten Produkts verstehen. Wir benötigen diese Informationen, um sicherzustellen, dass das Design und der Formfaktor repräsentativ für das endgültige Design sind, damit der Prototyp aussagekräftige Daten zur Produktleistung generieren kann.

Aus diesem Grund beginnt ein Programm für ein Star-Player-Produkt oft mit der Untersuchung von Produktanforderungen/-spezifikationen, Usability-Analysen und Interviews mit wichtigen Meinungsführern. Erst nachdem diese Informationen gesammelt wurden, kann der erste funktionierende Prototyp erstellt werden.

Im Gegensatz dazu ist für ein Facilitator-Produkt der endgültige Formfaktor nicht erforderlich, um die Leistung des „echten“ Star-Players zu testen. Beispielsweise kann ein grobes Steckbrettsystem, das aus handelsüblichen (nicht kundenspezifischen) Komponenten aufgebaut ist, verwendet werden, um Fragen zu beantworten wie: Erzeugt mein Assay das richtige diagnostische Ergebnis? Oder ist mein Arzneimittel in ausreichender Menge und Qualität?

Zunächst wird die Übung der Erforschung von Produktanforderungen, Usability-Analysen und Interviews mit wichtigen Meinungsbildnern auf ein Minimum reduziert. Nur die Metriken, die sich auf die Leistung beziehen (z. B. Sensitivität, Spezifität, Menge aktiver Biopharmazeutika usw.) müssen im Voraus definiert werden.

Solange die ersten Prototypkomponenten die vordefinierte Produktleistung erreichen können, wird der erste funktionierende Prototyp einen enormen Wert liefern, indem er die ersten praktischen Testergebnisse liefert, selbst wenn einige der kritischen Komponenten in späteren Design-Iterationen geändert werden müssen.

Nicht alle Produkte passen problemlos in die Kategorien „Starspieler“ oder „Vermittler“. Beispielsweise hängt die Kategorisierung eines kundenspezifischen Arzneimittelverabreichungsgeräts wirklich von der Komplexität ab. Wenn das Arzneimittelabgabegerät eine Therapie ermöglicht, die andernfalls nicht verabreicht werden könnte (z. B. durch Abgabe eines Arzneimittels an einen bestimmten Teil des Gehirns, der derzeit nicht erreichbar ist), könnte das Gerät als Starspieler angesehen werden.

Wenn das Arzneimittelabgabegerät dagegen eine kostengünstigere Lösung für eine bereits bestehende Behandlung darstellt, könnte das Produkt als Erleichterung betrachtet werden.

Kurz gesagt, fast jedes Entwicklungsprogramm wird darauf abzielen, die technische Machbarkeit so schnell und kostengünstig wie möglich zu erreichen, indem funktionsfähige Prototypen erstellt und getestet werden. Bei Star-Player-Produkten dauert es normalerweise länger (und ist kostspieliger), diesen wichtigen Meilenstein zu erreichen, da mehr Produktdefinition erforderlich ist, um einen aussagekräftigen funktionierenden Prototyp zu erstellen.

Da so viel Design und Formfaktor später geändert werden können, können Sie bei Facilitator-Produkten fast sofort mit der Erstellung eines funktionierenden Prototyps beginnen, während Sie sich im Hintergrund mit den Produktanforderungen und -spezifikationen befassen.

Abbildung 1. Beide Programme arbeiten so schnell wie möglich auf den „Proof Of Principle“ hin. Anfangs konzentriert sich ein Entwicklungsprogramm für ein Star Player-Produkt jedoch mehr auf die Produktdefinition als ein Programm für ein Facilitator-Produkt, das direkt mit der Erstellung eines Prototyps beginnt, um die Leistung zu testen und die technische Machbarkeit zu erreichen.

2. Design – Test – Design – Test – Design – Test … stopp.

Obwohl der erste Prototyp immer mit der Absicht entworfen wird, die technische Machbarkeit zu erreichen, trifft ein erster Prototyp selten alle Punkte. Es können mehrere Iterationen erforderlich sein. Aus diesem Grund gibt es im Kern schlanker und agiler Produktentwicklungsprogramme schnelle Zyklen von Design-Iterationen, Tests, Lernen und Einbringen der Erkenntnisse in die nächste Iteration.

Alle unwesentlichen Entwicklungsaktivitäten während dieser Zeit auf ein Minimum zu beschränken, hilft dabei, das Team zu fokussieren und die Entwicklung zu beschleunigen. In diesem Stadium sollte das Optimieren und Umfunktionieren von Prototypen für eine verbesserte Leistung frei und ohne Beeinträchtigung durch strengere Qualitätssysteme erfolgen.

Um es klar zu sagen, diese strengen Qualitätssysteme sind in einer späteren Phase des Programms von entscheidender Bedeutung, aber eine „leichte“ Dokumentation zu Beginn des Programms trägt dazu bei, die Entwicklung zu beschleunigen.

Schnelle Iterationen sind wichtig für eine schlanke und agile frühe Produktentwicklung. Aber auch zu wissen, wann man mit Iterationen aufhören und Erfolge feiern sollte. Ich habe noch kein technisches Team getroffen, das nicht glaubt, dass „weitere Verbesserungen ein besseres Produkt ergeben würden“. Und so sollten sie! Ihre Aufgabe ist es, nach der bestmöglichen Designlösung zu streben.

Aus diesem Grund sollte das Ziel, vordefinierte Leistungsmetriken zu erreichen (z. B. Nachweis von x Menge Analyt wird erreicht, oder Probe ist für x Zeitdauer stabil, etc.) von Anfang an klar formuliert und durchgehend wiederholt werden Projekt.

Wenn die gewünschte Leistung erreicht ist, bedeutet dies, dass die technische Machbarkeit erreicht ist. Das bedeutet, dass das Programm in die nächste Designphase überführt wird (in der ein verfeinerter Prototyp gebaut wird).

Dies ist auch der richtige Zeitpunkt, um mit der Erstellung einer detaillierteren Dokumentation der Prototyparchitektur zu beginnen und mit der Festigung der Produktanforderungen zu beginnen. Diese Dokumentation bleibt relativ fließend (außerhalb der Entwurfskontrolle) bis später im Programm.

Die Dokumentation dieser Informationen hilft der internen und externen Kommunikation, dem Onboarding zusätzlicher Teammitglieder und der Sicherung der Arbeit bis zu diesem Zeitpunkt.

3. Wie Sie Programmmeilensteine ​​mit dem flinksten Team erreichen

Oft besteht die Versuchung, mehr Ressourcen in ein Programm zu stecken, in der Annahme, dass intelligentere Leute schnellere und bessere Lösungen bedeuten. Gerade in regulierten Branchen (wie Medizinprodukte- und Pharmaindustrie) können die vorherrschenden Organisationssysteme auch auf zusätzliche Teammitglieder drängen, die noch nicht dort sein müssen.

Vertreter von Funktionen, die erst später benötigt werden, können von Anfang an einbezogen werden, was zu einem großen Overhead und Kommunikationsaufwand führt. Das Ergebnis sind über 20 Personen, die in Meetings sitzen und versuchen, ein Programm voranzubringen.

Trotz der großen Teamgrößen starten diese Programme oft nur langsam. Obwohl dies kontraintuitiv klingen mag, habe ich festgestellt, dass kleinere, engagierte multidisziplinäre Teams schneller vorankommen und während der frühen Produktentwicklung überproportional viel Innovation generieren können.

Das Konzept, die Teamgröße zu begrenzen, um eine hervorragende Leistung zu erzielen, ist nicht neu. Jeff Bezos, Gründer und ehemaliger CEO von Amazon, hat dieses Phänomen erkannt und die Regel eingeführt, dass jedes Team so klein sein sollte, dass es mit zwei Pizzen satt werden kann.

Die „Zwei-Pizza-Regel“ wird durch unzählige Forschungsartikel und Bücher gestützt, die darauf hinweisen, dass kleine Teams innovativer sind und zufriedenere Teammitglieder haben [1, 2, 3].

Abbildung 2. Die Kommunikationslast wächst exponentiell mit der Anzahl der Personen im Team, wie in dieser Abbildung dargestellt. Die schwarzen Punkte stellen einzelne Teammitglieder dar, und die Linien stellen einzigartige Verbindungen zwischen Personen dar.

In Abbildung 2 sehen Sie, dass die Teamgröße exponentiell mit der Kommunikationslast zusammenhängt. Das Hinzufügen eines zusätzlichen Teammitglieds sieht vielleicht nicht nach viel aus, kann aber tatsächlich zu erheblichen zusätzlichen Belastungen und Fehlausrichtungen führen. Besonders in der frühen Produktentwicklung trägt die Begrenzung der Teamgröße auf nicht mehr als 5 Mitglieder wirklich zu einer schnellen und schlanken Entwicklung bei.

Die offensichtliche Dichotomie in diesem Konzept besteht darin, dass die Probleme, die bei der Entwicklung medizinischer Geräte gelöst werden müssen, häufig Expertenkenntnisse erfordern. Es ist äußerst selten, alle erforderlichen Fähigkeiten in einer kleinen Anzahl von Personen zu finden. Die Herausforderung besteht also darin, ein kleines Team aufzubauen, das flink und schnell arbeiten kann und gleichzeitig Zugriff auf tiefere Ebenen von Wissen/Erfahrung hat.

Leider gibt es kein einheitliches Team, aber ich habe gesehen, dass die erfolgreichsten Teams nur aus ein paar technischen Leitern bestehen, denen die Designprobleme gehören. Diese technischen Leiter sind meist vielseitige Persönlichkeiten mit langjähriger Erfahrung. Sie wissen, wann sie in Bereichen, in denen sie keine Experten sind, nach interner oder externer Beratung suchen müssen.

In dieser Struktur formuliert der technische Leiter die Problemdefinition und skizziert die Lösungslandschaft vor der Beratung.

Der Berater (intern oder extern) ist nicht Teil des Kernteams (wodurch der Kommunikationsaufwand begrenzt wird), ist aber dennoch in der Lage, Expertenwissen für die vorgeschlagenen Lösungen bereitzustellen. Oft findet die Kommunikation zwischen technischen Leitern und Beratern in kleinen Meetings statt, an denen nicht das gesamte Team teilnimmt.

Der technische Leiter stellt sicher, dass die vorgeschlagenen Lösungen zu den größeren Prototyp-Designplänen passen und besitzt letztendlich einen erheblichen Teil der Prototyp-Architektur.

Ein zusätzlicher Vorteil dieser Struktur besteht darin, dass technische Führungskräfte ein großes Verantwortungsbewusstsein gegenüber ihren technischen Herausforderungen empfinden und ihre Erfolge wirklich feiern und anerkennen können.

4. Ernennen Sie einen Programm-Champion

Technische Leiter besitzen einen Teil der Systemarchitektur, aber es muss auch einen Programm-Champion geben, der für den Erfolg des Programms verantwortlich ist. Diese Person ist letztendlich für das gesamte Programm verantwortlich und stellt sicher, dass die richtigen Leute an den richtigen Designlösungen arbeiten.

Ein Programm-Champion kann viele Titel haben (z. B. Produktmanager, Programmmanager, Direktor für Forschung und Entwicklung, CSO, CTO usw.), aber seine Rolle wird nicht durch den Titel definiert. Dies ist jemand, der sich für ein erfolgreiches Programmergebnis verantwortlich fühlt und in der Lage ist, die verschiedenen Teile des Puzzles ganzheitlicher zu betrachten.

Der Programm-Champion wird auch den gesunden Konflikt zwischen dem technischen Team (mit dem Wunsch nach weiteren Verbesserungen) und dem Projektmanager (mit dem Wunsch, pünktlich und im Rahmen des Budgets zu liefern) meistern. Die Durchführung eines Entwicklungsprogramms, das Innovationen, viele Unsicherheiten und neuartige Technologien umfasst, erfordert immer Kompromisse von beiden Parteien.

Letztendlich ist die effektive Bewältigung dieses Konflikts eine Schlüsselkomponente für die Führung eines erfolgreichen Lean-and-Agile-Entwicklungsteams.

Abbildung 3. Ein Programm-Champion navigiert notwendige und gesunde Konflikte, die zwischen dem technischen Team, dem Projektmanager und dem Produktteam/Manager bestehen. Ein Programm-Champion kann ein engagierter Programm-Manager, CTO, CSO, F&E-Direktor oder ein Mitglied des technischen oder Produktteams sein. Am wichtigsten für diese Rolle ist, dass sie Konflikte unparteiisch meistern können.

Eine weitere Aufgabe des Programm-Champions besteht darin, eine Abstimmung zwischen dem technischen Team und dem Produktmanager zu finden. Der Produktmanager ist für das angestrebte Produktprofil und die Festlegung kommerzieller Ziele verantwortlich.

In frühen Entwicklungsprogrammen habe ich festgestellt, dass die Rolle des Produktmanagers möglicherweise nicht von einer dedizierten Person besetzt wird, sondern die Rolle oft von mehreren Personen getragen wird.

Diese Personen dabei zu unterstützen, die Produktvision und die Produktanforderungen voranzutreiben, und das Gespräch zwischen dem technischen Team und dem Produktmanagementteam zu erleichtern, ist unerlässlich, um zu einem Produktdesign zu gelangen, das die Erwartungen erfüllt und einen Marktbedarf erfüllt.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass der Aufbau eines schlanken und agilen Produktentwicklungsprogramms damit beginnt, die Aktivitäten zu definieren, die so schnell wie möglich die technische Machbarkeit erreichen. Ein kleines, engagiertes Team aus erfahrenen technischen Leitern, die schnell Prototyp-Iterationen entwerfen, bauen und testen, schafft eine flexible und kostengünstige Struktur.

Schließlich ist es entscheidend, einen Programm-Champion zu ernennen, der bei der allgemeinen Ausrichtung hilft, den Moment angibt, in dem die technische Machbarkeit erreicht ist, und die gesunden Konflikte steuert, die zwischen dem technischen Team, dem Projektmanager und dem Produktteam/Manager bestehen sollten.

1. Steiner ID., 1972. Gruppenprozess und Produktivität. New York: Akademische Presse.
2. Laughlin PR. et al., 2006. Gruppen schneiden bei Buchstaben-zu-Zahlen-Problemen besser ab als die besten Einzelpersonen: Auswirkungen der Gruppengröße. Zeitschrift für Persönlichkeits- und Sozialpsychologie, 90(4), 644-651.
3. Brett J. und Wang D., 2020, Wenn Sie kreative Lösungen wünschen, halten Sie Ihr Team klein, Wissenschaftlicher Amerikaner

Bild: Kann Stockfoto / olivier26

Joris van der Heijden ist Bio Services Program Manager bei Seestern Medizin. Zuvor war er Direktor für Forschung und Entwicklung bei Spartan Bioscience, wo er die Entwicklung eines COVID-19-Diagnosetests vor Ort leitete. Joris promovierte über Infektionskrankheiten an der UBC.

[Eingebetteten Inhalt] 

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/