PQFORCE wird täglich von vielen Anwendern in diversen Kundenumgebungen und an zahlreichen Standorten eingesetzt. Mit PQFORCE werden Projekte geplant, Ressourcen gesucht und alloziert, Absenzen verwaltet und vieles mehr. Jeder Anwender hat in seiner Rolle verschiedene Funktionen und Datensichten. Da ist es ja nur logisch, dass regelmässig Ideen aufkommen, wie man die Anwendung noch besser, noch schneller, noch benutzerfreundlicher gestalten könnte. Wie sollen wir als Lieferant damit umgehen?

Bei INTRASOFT pflegen wir einen sehr direkten Draht zum Kunden. Kunden sind für uns nicht einfach abstrakte, zahlende Entitäten, sondern eine Vielzahl von einzelnen Anwendern mit individuellen Bedürfnissen. Gerade in der aktuellen Phase des Marktaufbaus nehmen wir solche Kundenbedürfnisse sehr ernst. Aber was heisst das denn konkret?

Schauen wir uns dazu ganz einfach unseren Entwicklungsprozess an. Grundsätzlich entwicklen wir PQFORCE als Standard-Produkt entlang eines Release-Pfades. Es gibt also keine kundenspezifischen Verzweigungen (siehe dazu auch diesen Artikel). Neue PQFORCE Releases werden – je nach Umfang – alle paar Wochen entwickelt und unseren Kunden zur Verfügung gestellt. Die Entwicklung eines Releases spielt sich dabei entlang folgender Phasen ab.

Erfassung von Anforderungen: Am Anfang steht die Idee

 Neue Anforderungen entstammen fast immer aus Ideen von Anwendern. Unser Grundsatz hier lautet: Nur wer PQFORCE täglich einsetzt, kann auch wirklich feststellen, was noch fehlt oder wie noch mehr aus der Anwendung rausgeholt werden könnte. Diese Ideen und Wünsche nehmen wir auf – typischerweise im Rahmen von Pilotprojekten bei Kunden. In jener Zeitperiode also, in der ein auserlesenes Team von Pilotanwendern PQFORCE nutzt und die bestmögliche Einsatzart für den Kunden erprobt. Wir sind bei solchen Pilotprojekten vor Ort mit dabei, trainieren und beraten die Anwender, hören aufmerksam zu und nehmen so neue Ideen auf. Solche Ideen gehen dann in eine Liste ein. Da drin werden sie als sogenannte Business Requirements möglichst lösungsneutral in Form von Use Cases formuliert.

Konsolidierung & Priorisierung: Breit einsetzbare Lösungen für alle Kunden

In dieser Phase wird der grosse Topf mit neuen Anforderungen sorgfältig geprüft. Einzelne Anforderungen werden möglichst lösungsneutral formuliert, z.T. auch gruppiert und konsolidiert. Dann wird aus der grossen Liste ein Paket mit jenen Anforderungen geschnürt, die zusammen in einem neuen Release umgesetzt werden. Dabei werden auch konkrete Implementierungsvorschläge ausgearbeitet. Das können z.B. Screen Designs sein, welche ein zu überarbeitendes GUI darstellen. Solche Umsetzungskonzepte werden möglichst unter dem Aspekt einer hohen Flexibilität und Nachhaltigkeit erarbeitet und bei Bedarf auch den Kunden (Ideengebern) zum Review unterbreitet. Ziel ist es hier immer, nicht eine punktgenaue Lösung für den einen Ideengeber zu kreieren, sondern eine Lösung, die möglichst allen Kunden einen Mehrwert bringt, "massentauglich" ist und in den Standard einfliesst.

Die Liste von Business Requirements und das Paket von umzusetztenden Anforderungen sind vergleichbar mit dem Product Backlog bzw. Sprint Backlog aus der agilen Entwicklungsmethodik Scrum. Im Gegensatz zu Scrum entscheidet bei uns aber der Product Owner nicht alleine, sondern immer in Kommunikation mit den betreffenden Kunden. Wir betrachten unsere Kundenbasis sozusagen als erweiterten Kreis von Product Owners. Um die verschiedenen und teils gegensätzlichen Ansprüche der Kunden betreffend Dringlichkeit zu befriedigen, dafür ist unsererseits viel Fingerspitzengefühl und gute Kommunikation notwendig, und seitens Kunden braucht es auch Kompromissbereitschaft und Verständnis. Letztere findet man aber immer, denn unsere Kunden erhalten ja neue Features im Rahmen der normalen Abogebühr für das Standard-Produkt und bezahlen dafür nicht extra.

Entwicklung & Testing: Die konkrete Umsetzung wird getaktet

Dies ist eine rein interne Phase im Entwicklungsprozess, d.h. ohne Beteiligung der Kunden. Dabei wird nun der neue Release vom Entwicklungsteam effektiv umgesetzt. Hier findet also die Weiterentwicklung von PQFORCE im engeren Sinne statt. Dafür wird ein konkreter Zeitplan mit drei Eckdaten definiert:

• Bereitstellung zum internen Testing (Release Candidate)
• Bereitstellung des Stable Release für Marketing und Verkauf (Release for Marketing) 
• Bereitstellung des Stable Relase für den produktiven Kundeneinsatz (Release for Production)

Diese drei Bereitstellungen finden typischerweise im Wochenrhythmus statt. Dieser hohe Rhythmus ist mögilch, weil wir bestrebt sind, regelmässig und tendenziell eher kleinere Releases zu definieren. Unsere Kunden profitieren so von einer stetigen Weiterentwicklung mit jeweils überschaubaren Neuerungen. So können wir PQFORCE kontinuierlich neuen Bedürfnissen anpassen und am Puls der Zeit bleiben.

Release Build & Deployment: Die Auslieferung erfolgt zeitnah

Der Release for Production wird schliesslich in einem letzten Build Prozess erzeugt und auf die verschiedenen Produktivserver ausgerollt. Shared Cloud-Kunden wird der Release so automatisch zum vorher angekündigten Termin bereitgestellt. Kunden mit Dedicated Server oder On-Premise Abos erhalten den Release zum von ihnen gewünschten Zeitpunkt. Die entsprechenden Release Notes werden allen Kunden frühzeitig mitgeteilt.

Mit der Auslieferung schliesst sich der Kreis von der ursprünglichen Anwenderidee zum final umgesetzten Feature innert weniger Wochen!