In einer immer schneller werdenden Welt müssen wir uns kontinuierlich an neue Gegebenheiten anpassen. Das gilt auch für uns bei teemer, da wir den Kunden in den Mittelpunkt stellen. Da stellt sich die Frage: wie funktioniert das eigentlich? Wie wird eine Softwareänderung umgesetzt oder etwas Neues implementiert? Das wollen wir hier einmal an einem Beispiel deutlich machen.
Bei der teemer Praxissoftware arbeiten wir eng mit unseren Anwendern in der Produktentwicklung zusammen. Dementsprechend äußert in unserem Fall der Kunde den Wunsch nach einer Funktionsanpassung, die ihm die Arbeit erleichtern soll. Diese bespricht er mit unserem Kundensupport, wo ein entsprechendes Ticket erstellt wird. Dieser wird umgehend vom Supportteam geprüft mit den Fragestellungen: Worum geht es dabei? Handelt es sich womöglich um einen Fehler, der schnell behoben werden muss? In diesem Beispielfall ist es eine kleine Verbesserung, um einen Prozessschritt in der Software zu vereinfachen. Aus dem Support-Fall wird also eine Aufgabe für die Entwicklung und geht an den Product Owner des Entwicklungsteams, der mit der fachlichen Analyse loslegt. Dabei sind folgende Punkte zu beantworten:
- Welchen Bereich der Software betrifft die Änderung?
- Was muss geändert werden?
- Hilft die Änderungen allen Kunden oder hat sie vielleicht Nebeneffekte, die an anderer Stelle negative Auswirkungen haben könnten?
- Wie aufwendig ist die Umsetzung?
- Gibt es fachliche und/oder technische Voraussetzungen, die beachtet werden müssen?
Konnten alle Fragen mit Hilfe der fachlichen und technischen KollegInnen geklärt werden, wird der Vorgang für die Umsetzung beschrieben. Der Schwerpunkt liegt hierbei auf der Beschreibung von dem aktuellen IST-Status und der Formulierung des gewünschten SOLL-Zustands. Sobald dieser Schritt vollzogen ist, wird der Ticketaufwand geschätzt. Dieses erfolgt im agilen Prozess anhand von Komplexität im Rahmen der Fibonacci-Zahlenreihe. Das ist ein Kriterium für die anschließende Priorisierung für den Entwicklungsprozess. Die Höhe des Kundennutzens, der prozentualen Anwendernachfrage oder die gesetzliche bzw. technische Notwendigkeit sind weitere Kriterien, die mit einbezogen werden.
Im nächsten Schritt ergeben sich weitere Fragen:
- Wie wichtig ist die Funktionalität?
- Muss sie kurzfristig umgesetzt werden oder kann sie noch etwas warten?
- Wenn sie schnell kommen soll, welches andere Feature muss dann dafür zurückstecken?
- Baut sie auf anderen Verbesserungen auf oder stellt sie selbst die Basis für weitere Anforderungen dar?
Wenn der Umsetzungszeitpunkt gekommen ist, schnappt sich ein IT-Entwickler den Vorgang und legt los. Hierbei ist er in enger Abstimmung mit technischen und fachlichen Experten, um Rückfragen zu klären. Nach der Umsetzung schauen als erstes Kollegen aus der Entwicklung auf das Feature und prüfen, ob es den technischen Vorgaben entspricht. Danach folgt die fachliche Abnahme des Product Owners, bei der die Funktion aus Anwendersicht überprüft wird. Ist alles okay, führt der Entwickler die Funktion zurück in die nächste Release-Version. Ein Release beschreibt die regelmäßige Bereitstellung von neuen Funktionen in der Software beim Anwender. In dieser Release-Version wird die Funktion zusammen mit anderen Features durch das Testteam auf Herz und Nieren getestet. Funktionieren alle Neuerungen wie erwartet? Funktionieren die schon vorher vorhandenen Bereiche wie bisher? Wurde alles erwartungsgemäß getestet und gefundene Fehler behoben, wird das Release freigegeben und zum nächstmöglichen Zeitpunkt an die Anwender ausgerollt. Da teemer eine webbasierte Software ist, erfolgt dieses im Hintergrund und jeder Anwender kann zum gleichen Zeitpunkt die neuen Funktionen, ohne selber dafür etwas zu tun, nutzen.
Dann heißt es wieder „Liebe teemer-Nutzer(innen), wir haben ein neues Release eingespielt.“ und die Verbesserung kann genutzt werden. So entwickeln wir das Produkt teemer Praxissoftware gemeinsam mit den Anwendern für den bestmöglichen Einsatz in der Zahnarztpraxis immer weiter.
Klasse Artikel 👍
Vielen Dank! 🙂