Wenn Anforderungen anfangen, sich zu verteilen...
Je größer und komplexer ein Entwicklungsprojekt für ein Medizingerät wird, desto mehr Informationen entstehen.
Anforderungen stehen in Dokumenten, technische Entscheidungen werden an anderer Stelle festgehalten und Tests wiederum in separaten Dateien dokumentiert. Was zunächst überschaubar klingt, wird mit jeder Änderung schwieriger nachvollziehbar.
Besonders in der Medizintechnik ist das relevant. Anforderungen stehen nicht für sich allein, sondern hängen oft mit Risiken, Tests, Verifikation, Validierung und weiteren Entwicklungsprozessen zusammen.
Wird eine Anforderung geändert, kann das parallel Auswirkungen auf viele andere Bereiche haben.
Mit Word und Excel lässt sich das Anfangs noch abbilden, aber irgendwann kann dieses System nicht mehr mithalten und wird eher zum zusätzlichen Verwaltungsaufwand.
Wir wollten deshalb wissen: Wie können wir Requirements Engineering so organisieren, dass es unsere Entwicklungsarbeit unterstützt und nicht noch komplizierter macht?
Die naheliegende Lösung: Ein bestehendes Tool
Die Antwort schien zunächst einfach: Wir nutzen eines der gängigen Requirement-Tools die es am Markt gibt.
Schließlich gibt es für das Problem bereits etablierte Lösungen. Wir haben verschiedene Softwareprogramme kennengelernt und dabei gemerkt: Oft können sie sehr viel und bringen dadurch gleichzeitig eine Komplexität mit, die für unsere Zwecke einfach zu viel war.
Beispielsweise kann die Einführung eines solchen Systems selbst zu einem größeren Projekt werden. Prozesse müssen angepasst, Strukturen definiert und Mitarbeiter eingearbeitet werden. Dazu kommen teilweise hohe Lizenz- und Einführungskosten. Also eher Tools für große Firmen und Konzerne.
Für ein kleines mittelständisches Unternehmen, das mit unterschiedlichen Medizintechnikprojekten arbeitet, stellt sich deshalb eine ganz praktische Frage: Muss ein Requirements-Tool wirklich so umfangreich und komplex sein, damit es gute Arbeit ermöglicht?
Für unsere Arbeit war die Antwort irgendwann klar: Nein.
Wir brauchten kein Tool für alles
Unser Problem war nicht, dass es überhaupt keine Requirement-Tools gab.
Unser Problem war, dass wir ein Tool brauchten, das zu unserer Art der Medizintechnikentwicklung passt.
Ein Werkzeug, das die Besonderheiten unserer Projekte und Unternehmensgröße
berücksichtigt, ohne unnötig komplex zu sein und unverhältnismäßig viele Ressourcen beansprucht.
Denn Medizintechnik stellt besondere Anforderungen an Entwicklungsprozesse. Anforderungen müssen nachvollziehbar sein. Änderungen müssen kontrolliert werden. Tests müssen zu Anforderungen in Beziehung stehen. Risiken und regulatorische Anforderungen spielen eine Rolle.
Das alles muss miteinander verbunden werden können.
Gleichzeitig sollte sich ein Entwickler nicht erst wochenlang in ein System einarbeiten müssen, bevor er eine Anforderung anlegen oder bearbeiten kann.
Wir kamen deshalb zu einer ziemlich einfachen Erkenntnis:
Wir brauchen ein Tool, das genau zu uns passt.
Ein Werkzeug, das nicht versucht, für jede Branche und jeden Anwendungsfall alles abzudecken, sondern sich auf das konzentriert, was bei der Entwicklung von Medizinprodukten tatsächlich gebraucht wird.
Also haben wir es selbst entwickelt
Irgendwann haben wir beschlossen unsere eigene Lösung zu entwickeln.
Der erste Schritt war dabei kein fertiges Produkt mit einer langen Liste an Funktionen.
Wir haben mit dem begonnen, was wir selbst gebraucht haben.
Das Tool wurde primär in unseren eigenen Entwicklungsprozessen eingesetzt. Dabei haben wir gemerkt, was funktioniert, was fehlt und an welchen Stellen die Anwendung noch einfacher oder sinnvoller werden kann.
Dann wurde weiterentwickelt.
Neue Inhalte kamen hinzu. Bestehende Funktionen wurden verbessert. Strukturen wurden angepasst.
Und anschließend wurde das Ergebnis wieder im Entwicklungsalltag eingesetzt.
Von der internen Lösung zum Produkt
Genau das ist für uns ein wichtiger Teil der Geschichte von Medioora: Wir haben das Tool nicht entwickelt, weil wir unbedingt ein weiteres Softwareprodukt auf den Markt bringen wollten.
Wir hatten ein Problem, das wir aus unserer täglichen Arbeit kannten und wir wollten dafür eine Lösung, die für uns funktioniert.
Mit der Zeit wurde aus dieser eigenen Lösung ein professionelles Werkzeug. Und irgendwann wurde klar: Unsere Kunden brauchen das selbe Werkzeug.
Auch andere MedTech-Unternehmen arbeiten mit Anforderungen, Tests, Risiken und umfangreicher Dokumentation. Dort stellt sich die Frage, wie diese Informationen sinnvoll miteinander verbunden und über den gesamten Entwicklungsprozess nachvollziehbar gehalten werden können.
Damit entstand aus einem internen Werkzeug die Idee für ein Produkt mit eigenem Namen: Medioora.
Für die Medizintechnik entwickelt
Ein Requirements- und ALM-Tool muss nicht möglichst viele Funktionen haben. Es muss die richtigen Funktionen bereitstellen, um den Entwicklungsprozess zu vereinfachen, damit Entwickler mehr entwickeln können und weniger Datenbankpflege betreiben müssen.
Medioora soll genau dabei helfen.
Anforderungen sollen nicht irgendwo in Dokumenten liegen, sondern strukturiert verwaltet und mit den relevanten Informationen im Entwicklungsprozess verbunden werden können.
Dabei geht es nicht darum, bestehende Prozesse unnötig zu verkomplizieren. Im Gegenteil: Das Werkzeug soll die Arbeit unterstützen, die ohnehin gemacht werden muss.
Und weil Medioora aus unserer eigenen MedTech-Entwicklung entstanden ist, entwickeln wir es auch weiterhin aus dieser Perspektive weiter.
Nicht nach dem Prinzip „Welche Funktion können wir noch hinzufügen?“, sondern mit der Frage:
Was brauchen Entwickler und Entwicklungsteams in einem Medizintechnikprojekt wirklich?