qmBase Entwicklungs-Roadmap 2021 2.Quartal

Mit jedem vierteljährlichen Blog-Update stellen wir Ihnen eine Liste der Verbesserungen vor, die wir in qmBase vornehmen. Unser Ziel ist es eine transparente Entwicklung darzustellen, sodass Sie wissen, auf welche Änderungen Sie sich einstellen können

Folgende Themen werden wir in diesem Quartal aufgreifen.

• E-Mail Benachrichtigungen und Notifications
• Zielmanagement
• Workflows & Automatisierung
• Templates & Vorlagen
• Schlagworte
• Talentmanager

Unsere E-Mail Benachrichtigungen sind manchmal zu kompliziert und nicht auf den ersten Blick verständlich. Das Ziel muss es sein, dass man mit einem Blick die Frage beantworten kann, was will qmBase mir dieser E-Mail sagen. Daher werden wir sowohl Inhalt als auch Formatierung einiger Benachrichtigungen anpassen, um dieses Ziel schneller zu erreichen.

Bisher kann der Zielfortschritt nur als % Wert erfasst werden. Dies erfordert unnötig kompliziertes Umrechnen bei der Benutzung der Software. An diese Stelle soll eine flexiblere Erfassung der Fortschritte kommen. Somit können dann auch einfach absolute Werte wie bspw. Anzahl der Neukunden erfasst werden.

Wiederkehrende Aufgaben manuell zu erledigen ist eine monotone Aufgabe und fehleranfällig. Hier setzen wir mit unserer Funktion Workflows an, um solche Abläufe zu vereinfachen. Sie können sich einen Workflow als ein einfaches regelbasiertes Programm innerhalb von qmBase vorstellen. Ein Workflow besteht aus folgenden Eigenschaften:

• Auslöser

• Bedingungen

• Auszuführende Aktion

Beispiele für Workflows können z.B. sein:

• Schicke eine Mail an die Qualitätssicherungsabteilung, wenn eine neue Reklamation erfasst wurde

• Blockiere das Ändern des Status einer Reklamation, wenn ein festgelegtes Custom Field nicht ausgefüllt wurde.

Die Angst vor einem weißen Blatt Papier hält viele Menschen vom Schreiben ab. Das Problem beobachten wir auch in qmBase. Das Problem tritt z.B. auf bei der Erfassung einer Reklamation. Regelmäßig erhalten wir Anfragen nach dem Muster: "Was soll ich denn jetzt hier alles aufschreiben?" Um dieses Problem zu lösen, führen wir eine Template-Funktion ein. Was damit möglich sein soll, wollen wir im folgenden wieder am Beispiel der Reklamationen erklären.

1. Sie können beliebig viele Templates festlegen, um verschiedene Anwendungsfälle abzubilden:
   • Template für interne Reklamationen
   • Template für externe Reklamationen
2. Wenn der Nutzer jetzt eine neue Reklamation erfassen möchte, erscheint zu Beginn ein Auswahldialog, wo das Template ausgewählt werden kann.
3. Nach Auswahl eines Templates kann das Beschreibungsfeld der Reklamation schon vorausgefüllt sein, mit den Informationen, die man erfassen möchte.

Bessere Verwaltung der Schlagworte. Zukünftig sollen Schlagworte fest vordefiniert werden können, um Wildwuchs zu verhindern. Zusätzlich sollen Schlagworte einzelnen Apps als Pflichtauswahl zugeordnet werden können. Ein Anwendungsfall hierfür ist beispielsweise, dass festgelegt wird, dass ein Schlagwort aus dem Pool "Prio1", "Prio2", "Prio3" zwingend mit einer Maßnahme verbunden werden soll.

Verknüpfung der Bereiche Aufgabe & Qualifikationen und Schulungsmanagement in einer einheitlichen App, die vermutlich den Namen Talentmanager bekommen wird. Detailliertere Definition von Anforderungen an Qualifikationen z.B. durch Formulare oder Dokumente.

Aktuell sieht unsere die Versionsbezeichnung z.B. so aus 1.1.109.2371. Die einzelnen Komponenten haben dabei folgenden Sinn:

1 - Hauptversion → Alles mit der gleichen Versionsnummer ist miteinander kompatibel

1 - Nebenversion → Größere Updates werden durch ein Hochzählen dieser Nummer gekennzeichnet

109 - Patch → Diese Nummer wird hochgezählt, wenn Fehler behoben werden

2371 - Buildnummer → Diese Nummer zählt automatisch hoch, bei jeder neuen Version, die von uns kompiliert wird.

Diese Art der Versionierung orientiert sich an der sogenannten Semantischen Versionierung. Bisher waren wir aber nicht sonderlich gut darin, zwischen Nebenversionsupdates und Patches zu unterscheiden. Hierauf werden wir zukünftig besser achten, um es allen beteiligten zu erleichtern Unterschiede zwischen Versionen zu identifizieren. 

Bei unserer Versionierung wird nur die letzte Nummer automatisch vergeben. Sie können also erkennen, dass wir bisher 2371 Versionen unserer Software kompiliert haben. D.h. also, dass wir in der Realität täglich mehrere Updates erstellen und nicht nur 93 wie es die Anzahl unserer Release Notes impliziert.

Woran liegt diese Differenz?

Der Unterschied ist einfach zu erklären. Unsere Entwicklung arbeitet nach dem Prinzip der kontinuierlichen Integration, d.h. extrem vereinfacht, dass wir probieren die Software in sehr kleinen Schritten zu verbessern und diese dann durch einen automatischen Prozess und Tests direkt an den Kunden ausliefern. Die Time-to-Market (hier definiert als Zeit von dem Entdecken eines Fehlers bis zu dem Zeitpunkt bei dem Fehler beim Kunden behoben wurde) beträgt somit unter Idealbedingungen inklusive der Korrektur selbst nur 20 Minuten. Diese Zeit kann natürlich bei komplexeren Problemen auch abweichen. 

Sie haben Interesse die umfangreichen Funktionen von qmBase zu testen?
Vereinbaren Sie jetzt eine Demo!

Sie möchten stets über die neusten Blogeinträge, Veranstaltungen und Neuigkeiten von qmBase informiert werden? Melden Sie sich jetzt für unseren Newsletter an.