Version 3.0: besser machen

Das Unternehmen entwickelt seine IT-Produkte ständig weiter. Es gibt keine Möglichkeit, den Moment anzuhalten, da sonst selbst das beste Programm unweigerlich veraltet ist. Wir erzählen, wie wir eine neue Version der medizinischen Anwendung für Europa erstellt haben und welche Probleme gleichzeitig gelöst wurden.

Krankenhaus App

Wir arbeiten mit einer medizinischen Anwendung für Krankenhäuser in Europa. Es hilft Ärzten, mehr Zeit mit Patienten zu verbringen, indem es den Papierkram reduziert. Ärzte diktieren Informationen über Patienten und Untersuchungen, die Anwendung übersetzt die Audioaufnahmen in ein Textformat, füllt eine Vorlage aus und generiert Dokumente für medizinisches Personal und Patienten. In jeder Arbeitsphase wird eine eigene Geschäftslogik und Integration in mehrere externe Systeme festgelegt.

Der Kunde hat uns die Aufgabe gestellt, eine neue Version der Anwendung zur Demonstration für Investoren zu entwickeln.

Projektdetails

Audio

So nehmen Sie Audio in Version 2.0 auf:

1. Die Anwendung wurde geöffnet.
2. Klicken Sie auf die Schaltfläche Datensatz hinzufügen.
3. In dem angezeigten Fenster haben wir die gewünschte Version des Aufnahmegeräts ausgewählt.
4. Diktierte Audioaufnahme.
5. Die Patientennummer, das Besuchsdatum und die Besuchsnummer (Besuch = Arzttermin) wurden eingegeben.
6. Sie klickten auf die Schaltfläche Vollständig, um Audio hochzuladen und Daten auf den Server zu besuchen.

In Version 3.0 ist jetzt weniger Aufwand für das Schreiben erforderlich:

1. Der Arzt öffnet die Anwendung.
2. Wählt einen Termin (nach Datum, Uhrzeit, Nummer oder Patientenname) aus der Liste aus und klickt einmal, um eine Visitenkarte zu öffnen.
3. Nimmt Audio auf.
4. Drücken Sie die Schaltfläche Fertig stellen, um Audio an den Server zu senden.

In Version 3.0 ist die Arbeit des Arztes so automatisiert wie möglich. Die Anzahl der Operationen hat abgenommen, während das Programm selbst Daten über Patienten hinzufügt.

Arbeite mit Buchstaben

Das Arbeiten mit Briefen ist ebenfalls einfacher geworden. In Version 2.0 gab es eine schwierige Warteschlange für ihre Verarbeitung. Der Arzt konnte nicht sofort eine vollständige Liste der Briefe erhalten - nur in Teilen und in einer bestimmten Reihenfolge. Um loszulegen, mussten Sie:

• Klicken Sie auf, um eine Liste Ihrer Briefe zu erhalten.
• gehe zu einem anderen Fenster;
• Doppelklicken Sie auf den Buchstaben, um ihn zu öffnen.
• Klicken Sie nach der Verarbeitung der Buchstaben aus der Liste erneut, um die folgenden Buchstaben in der Liste zu erhalten.

In Version 3.0 sieht der Arzt alle zur Verarbeitung verfügbaren Briefe. Er kann ein Dokument auf zwei Arten auswählen - entweder manuell in der Liste oder mithilfe von Filtern und Sortierungen (Sie können sie speichern, um den Brief mit einem Klick weiter zu öffnen). Um den Brief zu öffnen, klicken Sie einfach einmal.

Schnittstelle

Im Allgemeinen war die Benutzeroberfläche der Version 2.0 umständlich und unpraktisch. Die ursprüngliche Aufgabe der Anwendung bestand darin, den Fachärzten Zeit zu sparen, indem der Papierarbeitsfluss reduziert und mit Audioaufnahmen gearbeitet wurde. In der Praxis hat die Anwendung diese Aufgabe nicht so gut bewältigt, wie wir es gerne hätten. Um eine Aufzeichnung zu machen, musste der Arzt viele Einstellungen aus langen Dropdown-Listen auswählen.

Unsere Experten haben mit der Benutzeroberfläche gearbeitet und die Audio-Schaltfläche in den Vordergrund gerückt, damit Benutzer ihre Aufgabe mit der geringsten Anzahl von Klicks erledigen können.

Als Nächstes geben wir Einzelheiten zur Entwicklung der neuen Version an.

Neue Bedürfnisse

Als ein Kunde uns kontaktierte, um Version 2.0 zu aktualisieren, funktioniert die Anwendung seit ungefähr drei Jahren. Es war den Benutzern vertraut und hatte bestimmte Vorteile:

• Es gab eine Reihe von Funktionen zur Durchführung komplexer Geschäftslogik und zur Integration in Systeme von Drittanbietern.
• Kunden sind an das Programm gewöhnt und möchten es nicht aufgeben.
• Die Mitarbeiter des technischen Supports kannten die Anwendung und halfen den Benutzern schnell.
• Es gab flexible Einstellungen für die Konfiguration des Systems für alle geschäftlichen Anforderungen.
• Die Verfolgung möglicher Probleme in den Serverteilen des Systems wurde eingerichtet, und es wurden Problemumgehungen zur Lösung dieser Probleme bekannt.

Bei der Analyse des Betriebs der Anwendung haben wir jedoch folgende Probleme festgestellt:

• Das Entwickeln und Testen neuer Funktionen nahm immer mehr Zeit in Anspruch.
• Beim Hinzufügen neuer Funktionen traten Fehler im System auf.
• Infolgedessen wurden bis zu 30% der komplexen Verbesserungen von der Stange genommen, was die Anwendung zu veralten drohte. In Krankenhäusern wurden beispielsweise immer komplexere Vorlagen angezeigt. Es war erforderlich, neue Rollen im Workflow hinzuzufügen.
• Die Anwendungsarchitektur konnte keine neuen Lösungen unterstützen.
• 40% der Entwicklungszeit wurden für Support aufgewendet;
• Es gab Schwierigkeiten bei der Installation neuer Versionen und Updates des Desktop-Produkts.
• Die umständliche Benutzeroberfläche der 2000er Jahre schreckte neue Kunden ab.
• Ein unbequemes Einstellungssystem verhinderte einen schnellen Start des Systems und erhöhte auch das Fehlerrisiko.

Bei der Bewertung der Stärken und Herausforderungen kamen wir zu dem Schluss, dass die Anwendung mobiler (Webversion statt Desktop) und bequem, wettbewerbsfähig und leicht an Geschäftsaufgaben anpassbar sein muss.

Versionsanforderungen

Wir haben die Funktionen der Anwendung analysiert und die wichtigsten identifiziert, die das Produkt für das Unternehmen wertvoll gemacht haben. Basierend auf diesen Daten haben wir festgelegt, wie das Programm in der neuen Version aussehen soll:

• Schlüsselfunktionen der Anwendung, die für Ärzte und andere Benutzer intuitiv sind, werden benötigt.
• Für Benutzer - Gesundheitsdienstleister und Support-Mitarbeiter - sollte es leicht sein, den Umgang mit dem Programm zu erlernen.
• Datenverlust auch unter extremen Bedingungen (Stromausfälle, instabiler Internetzugang usw.) vermeiden;
• Vom System erstellte Dokumente müssen den gesetzlichen Normen und Anforderungen entsprechen.
• Während Systemaktualisierungen sollten mögliche Unannehmlichkeiten für den Benutzer und den Supportdienst minimiert werden.
• Es ist notwendig, eine serviceorientierte modulare Architektur zu erstellen, die auf verteilten, lose gekoppelten Komponenten basiert, damit diese zum Aufbau komplexer Softwaresysteme verwendet werden können.
• Verwenden Sie Active Directory, um Ihre Arbeitsumgebung einheitlich zu konfigurieren.

Darüber hinaus war es unmöglich, die neue Version als „komplizierten Klon“ der alten Version zuzulassen. Daher mussten die Schlüsselfunktionen gespeichert werden, ohne die Anwendung zu überlasten. Wir haben redundante komplexe Einstellungen rücksichtslos aufgegeben.

Geschäftsanalysten, die mit Version 2.0 arbeiten, haben die Änderungen nicht sofort akzeptiert. In der Leistungsbeschreibung wurden häufig Sätze gefunden: "Es sollte hier wie in Version 2.0 sein", "Nehmen Sie das Arbeitsschema in Version 2.0". Das Schwierigste in dieser Phase war der Widerstand gegen die Versuchung, alles zu nehmen, wie in der vorherigen Version.

Projektteam

In der Regel verbinden wir uns bei SimbirSoft zu Beginn jedes Projekts mit einem Expertenteam mit unterschiedlichen Profilen - Analysten, Qualitätssicherungsspezialisten (QS) und anderen. Bei der Arbeit an einer medizinischen Anwendung stellen wir folgendes Team zusammen:

• Entwickler, die Code geschrieben und Funktionen der Version 2.0 angepasst haben;
• Qualitätssicherungsspezialisten (QS). Zusammen mit den Entwicklern waren sie mit dem Legacy-Code, den Architekturlösungen und den Fehlern der Version 2.0 vertraut und testeten auch neue Funktionen.
• Test Automation Engineer (SDET), der die automatische Testfallüberprüfung in der Desktop- und Webversion eingerichtet hat;
• Business Intelligence. Sie sprachen mit dem Kunden und den Ärzten, fanden heraus, wie Geschäftsprozesse aufgebaut wurden, welche Anforderungen und Wünsche für die Anwendung bestehen. Danach erstellten sie Geschäftsprozessdiagramme, die für das gesamte Team verständlich waren.
• Designer und Usability-Experte. Sie waren für die Entwicklung einer benutzerfreundlichen Oberfläche verantwortlich.
• Projektmanager, der an der Verwaltung und Planung der Zeit beteiligt war.

Dabei haben wir ständig Tabellen der angeblichen Risiken in der neuen Version gepflegt. Um dies zu verhindern, haben wir ein flexibles System von Anwendungseinstellungen entwickelt und dessen Tests automatisiert, um Benutzer vor Fehlern zu schützen. Insbesondere hat unser SDET-Spezialist ein Framework geschrieben, mit dessen Hilfe alle Änderungen im Code schnell überprüft und weniger Zeit für Regressionstests aufgewendet werden können.

Herausforderungen und Lösungen

Bei der Aktualisierung der Anwendung standen wir vor mehreren schwierigen Phasen, auf die wir weiter unten eingehen werden.

App Design

Da die vorherige Version eine umständliche Oberfläche hatte, haben wir das Anwendungsdesign neu gestaltet. Wir haben fünf vorläufige Optionen vorgeschlagen und sie der Fokusgruppe unter den Benutzern der Anwendung gezeigt und Usability-Tests durchgeführt. Infolgedessen entschieden sich Fachärzte für eine Option, die sich ihrer Meinung nach als die bequemste, attraktivste und benutzerfreundlichste herausstellte.

Plugin-Entwicklung für verschiedene Browser

Wir haben verschiedene technische Risiken im Zusammenhang mit der Anwendung angegeben. Beispielsweise ist das für die Implementierung ausgewählte Plugin möglicherweise für einige Internetbrowser nicht geeignet. Um dieses Risiko zu verringern, haben wir zunächst ein Plug-In für die Software entwickelt, die in den meisten medizinischen Partnerinstitutionen verwendet wird. In Zukunft haben wir das Plugin ruhig für andere Browser entwickelt.

Ungültige Geschäftshypothesen

Unsere Aufgabe war es, eine limitierte Version des Produkts für die Präsentation für Investoren zu entwickeln. Aus diesem Grund haben wir versucht, nur die notwendigsten Funktionen in die Anwendung zu implementieren. Wir haben einige Hypothesen des Kunden analysiert und uns geweigert, sie umzusetzen.

Der Kunde schlug beispielsweise vor, einen Kalender für die Planung der Arbeit von Fachärzten zu erstellen. Der Hypothese zufolge könnte der Kalender die Arbeit von Ärzten bequemer machen. Unter realen Bedingungen war diese Funktion jedoch nicht erfolgreich und wurde am Ende deaktiviert. Später wurde der Kalender an die Bedürfnisse einer anderen Gruppe von Anwendern angepasst, nicht an medizinisches Personal. Ungültige Hypothesen ─ Dies ist ein wesentlicher Bestandteil des Geschäfts, und Sie müssen darauf vorbereitet sein.

Integration mit externen Systemen

Es hat viel Zeit gekostet, sich mit unserem Partner auf das Verfahren zur Integration der Anwendung in externe Systeme zum Senden und Speichern von Briefen zu einigen.

Benutzer der Anwendung (medizinische Einrichtungen) wollten alte, vertraute Integrationssysteme für Version 3.0 verwenden, sie konnten nicht geändert werden. Unser Partner ging davon aus, dass in diesem Fall die Integration schnell erfolgen würde. Tatsächlich waren jedoch viele Aufgaben mit der Integration verbunden:

• Sammeln Sie allgemeine Informationen zur Funktionsweise von Mail-Versandsystemen.
• Erstellen Sie eine Liste kritischer Fehler in 2.0.
• Betrachten Sie diese Fälle in der Phase der Analyse und Entwicklung, um sie zu berücksichtigen und nicht auf denselben Rechen zu treten.
• Analysieren Sie, ob die Funktionen von Version 2.0 für die Prozesse von Version 3.0 geeignet sind oder ob etwas geändert werden muss. Geben Sie bei Änderungen jedes Mal an, warum bestimmte Funktionen benötigt werden, und kommunizieren Sie mit den technischen Spezialisten des Kunden und nicht nur mit Analysten.

In den Verhandlungen mit dem Kunden konnten wir beweisen, dass die Arbeit mit der Integration Zeit braucht. Unser Partner stimmte uns zu: Sie können den Code nicht einfach von einer Version in eine andere übertragen.

Testen und Analysieren

Die vorherige Version des Projekts wurde ohne Beteiligung von Analysten erstellt. Entwickler und QS-Spezialisten haben die Anforderungen bei der Erstellung der Anwendung festgelegt. Die dritte Version basierte bereits auf den Anforderungen der Analysten, es gab jedoch immer noch Schwierigkeiten beim Testen:

• verschiedene Teams arbeiteten an dem Projekt;
• es gab eine große Anzahl paralleler Aufgaben;
• Während des Sprints änderten sich Anforderungen und Aufgaben häufig.
• Es war notwendig, das Zusammenspiel neuer Funktionen mit bereits genehmigten zu berücksichtigen.

Um an der neuen Version des Produkts zu arbeiten, mussten wir einzelne Workflows transformieren, zum Beispiel:

• Wir haben die Analyse von der Entwicklungsseite und der Qualitätssicherung gestärkt und zusätzliche Stunden dafür festgelegt.
• Es war eine Regel, den Zweck der zu testenden Funktion in den Anforderungen für die Überprüfung anzugeben. Dies verbesserte das Verständnis der Aufgaben für Analysten und bot die Möglichkeit, die optimale Lösung vorzuschlagen.
• Um die Arbeitsbedingungen zu klären, haben wir die Terminologie geändert: Anstelle einer groben Schätzung in Stunden haben wir begonnen, Aufgaben als „groß“ oder „klein“ zu klassifizieren. Wir begannen die Vorlaufzeit erst nach einer vollständigen Überprüfung der Aufgabe von der Entwicklungsseite, der Qualitätssicherung und der Genehmigung der endgültigen Version der Anforderungen durch den Kunden. Wenn die Aufgabe erweitert wurde, haben wir die Schätzung der Zeitkosten neu berechnet.
• Wir begannen zu planen, welche Funktionen in den kommenden Quartalen für die nächsten 2-3 Releases implementiert werden sollten. Um die Entwicklung genauer vorhersagen zu können, haben wir diejenigen Aufgaben, die die Bewertung nicht bestanden haben, nicht mehr in den Release-Plan aufgenommen.
• Zur Erleichterung der Analysten und zum besseren Verständnis des Systems haben wir in den Checklisten angegeben, welche Interaktionen bei der Erstellung von Anforderungen berücksichtigt werden sollten. Wir haben auch gemeinsame Regeln für das Schreiben von Artikeln in Confluence und die Dokumentation in JIRA entwickelt und begonnen, diese einzuhalten.

Regelmäßige Online-Kundgebungen mit dem Kunden haben uns geholfen, unser Verständnis seiner Geschäftsprozesse zu verbessern. Während des Gesprächs erklärte unser Partner die Einzelheiten der Arbeitsweise der Ärzte und erläuterte die Geschäftsziele. Wir erklärten wiederum die technischen Nuancen und zeigten verschiedene nicht offensichtliche Fälle. Dies ermöglichte es uns, Produktanforderungen zu formulieren, die die Bedürfnisse medizinischer Einrichtungen abdecken und hinsichtlich der Implementierungskosten optimal sind.

Zusammenfassung

Durch die Flexibilität der Arbeitsprozesse und die Berücksichtigung der Geschäftsanforderungen konnten wir alle Schwierigkeiten überwinden, die während des Entwicklungsprozesses auftraten. Wir haben erfolgreich eine neue Version des Antrags für medizinische Einrichtungen in Europa erstellt und gestartet.

Jetzt entwickeln wir das Produkt weiter und führen neue Funktionen ein. Wir untersuchen, wie echte Benutzer mit dem System arbeiten, sammeln nicht erfasste Fälle und User Stories und identifizieren neue Geschäftswerte.

Beim Erstellen einer neuen Version eines Produkts haben Entwickler in der Regel dieselben Probleme wie wir, zum Beispiel:

• falsche Hypothesen von Seiten des Geschäfts sind möglich;
• Es gibt Widersprüche in den Wünschen der Benutzer (lassen Sie alles so wie es war oder machen Sie es neu).
• Manchmal ist es notwendig, die Arbeit des Teams neu zu strukturieren, um ein besseres Ergebnis zu erzielen.

Die Hauptsache ist, dass die Veröffentlichung der neuen Version des IT-Produkts keine Kopie des Codes „Strg + C“, „Strg + V“ aus der vorherigen Version ist, sondern eine vollwertige Entwicklung von Grund auf neu. Dies liegt daran, dass sich Geschäftsprozesse, Benutzeranforderungen sowie die Situation auf dem Markt für IT-Lösungen ändern.

Vielen Dank für Ihre Aufmerksamkeit! Wir hoffen, dass Sie diesen Artikel hilfreich finden.