barbuda – wenn wir queos dieses Wort hören, denken wir nicht zuerst an karibische Sandstrände, sondern an unsere selbst entwickelte Projektmanagement-Software. Aber auch die hat einiges zu bieten: Sie lässt sich in der Projekt- und in der Ressourcenplanung einsetzen oder unterstützt bei der Optimierung der Projektportfoliosteuerung.

Zunächst vor allen Dingen im queo-internen Projektgeschäft im Gebrauch, hat das Tool längst Marktreife erreicht und ist auch bei großen Kunden in der täglichen Arbeit unverzichtbar.

Ganz aktuell gibt es übrigens Grund zur Freude über den Relaunch der neuen Website und das neueste Release von barbuda 2.0 – der neuen, verbesserten Version der Software. Auch die App ist ab sofort nicht nur für Windows und iOS, sondern auch für Android verfügbar. Diese Gelegenheit möchten wir nutzen, um im queoflow-Blog die technischen Aspekte von barbuda zu beleuchten und sprechen daher mit unserem Developer Daniel der die Entwicklung der Software maßgeblich in der Hand hält.

Daniel, Du hast die Entwicklung von barbuda von Beginn an betreut – von der Idee bis zum fertigen Produkt. Wie seid Ihr als Projektteam auf das Konzept gekommen? Was war die vorantreibende Kraft dahinter? Und wie lange braucht so ein umfangreiches Projekt bis zur Marktreife?

Daniel: Das sind schon mal viele Fragen auf einmal, aber fangen wir mal vorne an.

Als ich bei queo anfing, gab es ein Tool namens Win-Plantafel. Darüber erfolgte die Mitarbeiterplanung bei queo. Alle Informationen steckten in einer Datei, die von allen Projektmanagern bearbeitet wurde. Dabei kam es vor, dass diese Datei oft schreibgeschützt war oder überschrieben wurde. Außerdem gab es keine Verbindung zu den Daten des CRM- bzw. ERP-Systems. Meine Aufgabe war demzufolge die Portierung der Win-Plantafel in eine Multiuser Anwendung mit Anbindung des CRM- und ERP-Systems.

Daraufhin folgte das Forschungsprojekt VIZAMP, in dem wir uns mit agilem Multiprojektmanagement beschäftigt haben. Hinzu kommen die queo-internen Bestrebungen unsere Projektplanung besser zu organisieren und zu strukturieren, um in der Ressourcenplanung valide Aussagen über die nächsten Monate zu bekommen. Dabei haben Team- und Geschäftsleitung folgende Fragen besonders interessiert: Müssen wir Projekte organisieren, Akquise betreiben oder sind wir gut ausgelastet? Brauchen wir vielleicht sogar neue Mitarbeiter?

Ausgehend von VIZAMP haben wir dann Ideen und Konzepte entwickelt, wie eine Visualisierung aussehen kann, wenn viele Mitarbeiter viele Projekte planen und geplant bekommen, die Abhängigkeiten die daraus entstehen, die Ressourcenplanung und wo es zu Überplanungen kommt. Unser erster großer Wurf nach dem Forschungsprojekt war dann die Umsetzung von barbuda 1.0 auf Basis eines Web-Services und einer Microsoft Silverlight-Anwendung, die im Browser funktionierte. Die ersten Ideen zum Basisumfang und die Umsetzung waren nach sechs Monaten so weit fertig, dass es produktiv getestet werden konnte.

Doch nach und nach kamen die ersten Anfragen von Apple-Nutzern, bei denen Silverlight nicht eingesetzt werden konnte. Weitere Unwegsamkeiten führten dann dazu, dass wir nach etwa zwei Jahren den Entschluss fassten, barbuda komplett zu überarbeiten und das Konzept grundlegend zu überdenken. Zu diesem Zeitpunkt haben wir uns für einen Web-Client entschieden, der die ganzen Funktionalitäten im Web verfügbar macht. Dabei haben wir auf Angular JS gesetzt, sodass mehr Interaktivität verfügbar ist und eine REST-Schnittstelle geschrieben. Das hatte gleich den Vorteil, dass andere Entwickler eigene Software schreiben können und über diese Schnittstelle mit barbuda kommunizieren. So haben Kollegen beispielsweise einen eigenen Zeiterfassungsclient geschrieben. Das zeigte uns gleich, dass die REST-Schnittstelle gut konzipiert war. Da aber nicht alle Funktionalitäten im Web-Client abgebildet werden können, haben wir uns zusätzlich für einen Desktop-Client entschieden, der auf jedem Rechner in der Firma installiert ist und über den die Projektmanager die Gesamtprojektplanung durchführen können. Der Desktop-Client gibt uns hier eine gute und einfache Möglichkeit, um Darstellungen einfach auch mal iterativ auszuprobieren zu können. Über die Servicearchitektur konnten wir diese dann immer auch problemlos in den Web-Client portieren.

Für diese Umsetzung von barbuda 2.0 haben wir insgesamt etwa weitere neun Monate gebraucht, in denen ich aber bedingt durch Kundenprojekte nicht immer „Fulltime“ mit dem Team daran arbeiten konnte. Zugleich setzten wir aber auch neue Ansichten wie die Ressourcenplanung, die Langfristplanung und das Dashboard um, die wir prototypisch viel schneller testen konnten.

Außerdem ist interessant, wie genau Ihr bei der Entwicklung vorgegangen seid. Auf welcher Programmiersprache basiert das System? Welche Methoden habt Ihr genutzt – und welche Besonderheiten gibt es noch?

Daniel: Die Programmiersprache ist C# und es liegt das .net-Framework zu Grunde sowie zahlreiche Bibliotheken.

Wir haben uns für ein agiles Vorgehen entschieden mit Sprints in einer Größenordnung von drei Wochen entschieden, sodass wir regelmäßig Updates und Bugfixes liefern konnten. Da wir zu Beginn noch nicht wussten, welche Features wir eigentlich konkret brauchen, wie diese umgesetzt werden sollen und welche Anforderungen die Projektmanager in der täglichen Arbeit mit barbuda haben, hat sich das agile Vorgehen angeboten.

Auf die Anforderungen der Projektmanager sind wir eingegangen und haben dann nach und nach Features konzipiert und umgesetzt. Die Besonderheit von barbuda ist, dass wir bereits bei barbuda 1.0 ein Konnektorenkonzept entwickelt haben, das uns die Möglichkeit gibt, verschiedene Datenquellen anzuzapfen. Für unser internes System haben wir beispielsweise das ERP-System sage als Grundlage, in dem alle projektspezifischen Daten gespeichert und alle Ressourcen verwaltet werden. Die Personalwirtschaft ist in einer anderen Datenbank hinterlegt, über die die Erfassung der Urlaube, Krankheiten und anderer Abwesenheitszeiten erfolgt. Hier werden über einen anderen Konnektor Daten abgerufen, der solche Abwesenheiten in einem bestimmten Format ausgibt, das barbuda core, das Kernsystem, mittels Schnittstellen vorgibt.

Für das Testing des Konnektorenkonzepts haben wir parallel ein Stand-Alone-System entwickelt, das die Daten aus einer eigenen Datenbasis liefert. Für den Kunden Mibrag, der Mitteldeutschen Braunkohlegesellschaft, haben wir einen Konnektor geschrieben, der Abwesenheitsdaten aus SAP bezieht. Die Daten werden von einem Web-Service abgefragt und in das barbuda Format transformiert. Die Konnektoren sind austauschbar und kombinierbar, sodass man einen Konnektor bauen kann, welcher die Daten verschiedener Quellen aggregiert. Das bedeutet viel Flexibilität und für jeden Kunden individuell anpassbare und austauschbare Schnittstellen. Das ist ein großer Vorteil von barbuda, der vielleicht nicht gleich auf den ersten Blick erkennbar ist.

Was sind Eure Rollen in der Entwicklung? Wer ist Experte für welchen Bereich? Und wer übernimmt was?

Daniel: Wir haben mittlerweile einige Mitarbeiter im Projekt. Unser Geschäftsführer André Pinkert, der lange Zeit auch das Team Projektmanagement bei queo geleitet hat, treibt die Teilprojekte auf Basis der Produktvision voran, gibt immer neue Impulse für Features und stimmt diese mit mir ab. Andere Mitarbeiter unterstützen mich in der direkten Entwicklung von barbuda im Web- und Desktop-Client. Wieder ein anderer Mitarbeiter hat sich um die Umsetzung des Moduls Belegerfassung gekümmert und zusätzlich die App-Entwicklung für die mobilen Endgeräte durchgeführt. Ich selbst hingegen halte die Fäden als Entwicklungsleiter zusammen, plane die Sprints, schreibe die Konzepte, setze diese teilweise mit um und kümmere mich um die Kundensysteme, indem ich sie durch automatisierte Bereitstellungen auf dem aktuellen Stand halte. Schließlich führe ich Reviews durch und sichere damit die Qualität, um unseren hohen Ansprüchen gerecht zu werden.

Die barbuda-App gibt es jetzt auch für Android, vorher war sie bereits für Windows Phone und iOS verfügbar. Wie seid Ihr in der Entwicklung vorgegangen? Welche Funktionen hat die App, wie kann der Kunde diese optimal nutzen?

Daniel: Da wir barbuda auch in den mobilen Kontext bringen wollten, hatten wir am Anfang einen Windows Phone-Client und einen iOS-Client entwickelt, die zwar ein ähnliches Look & Feel hatten, aber auf die unterschiedlichen Systemspezifikationen abgestimmt waren. Wir haben uns dann mit der App-Entwicklung mit XAMARIN auseinandergesetzt. XAMARIN ist eine .net-Plattform, die es ermöglicht, Anwendungen für verschiedene Endgeräte mit der gleichen Codebasis zu entwickeln, sodass man eine einzige App entwickelt, die auf Android, iOS und Windows gleichermaßen funktioniert. Man bedient sich dabei nativen Steuerelementen, die auf allen Geräten verfügbar sind. Das ist der Vorteil von XAMARIN und deswegen haben wir uns für die Umsetzung der App mit diesem System entschieden.

 

Mit dem Relaunch startet auch die intensivere Vermarktung von barbuda 2.0. Was ändert sich dabei für unsere Kunden? Welche Features sind neu – welche wurden verbessert?

Daniel: Hinzugekommen ist zum einen die Zeiterfassung direkt im Web-Client. Dieses Modul bietet die Möglichkeit der kontinuierlichen Zeiterfassung sowie das Nachbuchen von Zeiten. Das Buchen von Zeiten erfolgt projekt- und vorgangsbezogen. Der Nutzer hat seine gebuchten und geplanten Zeiten der aktuellen Woche im Blick, kann aber auch beliebige Zeiträume der Vergangenheit auswählen um seine gebuchten Zeiten zu prüfen und zu bearbeiten.

Das bereits erwähnte Modul Belegerfassung testen wir aktuell intern, aber bei Bedarf kann es aber bereits für Kundensysteme zugänglich gemacht werden. Mit der Belegerfassung wird der Rechnungseingang und die Rechnungsprüfung in Unternehmen komplett digitalisiert. Konkret bedeutet dies, dass Rechnungen zentral erfasst und durch die verantwortlichen Projektmanager freigegeben werden. Über eine Schnittstelle erfolgt dann die Ausgabe in einem bestimmten Format (z.B. Buchungssätze), das dann wieder in andere Systeme wie ein ERP-System oder eine Warenwirtschaft importiert werden kann. Die zentrale Belegverwaltung erfolgt aber über barbuda und kann so den Projekten und Vorgängen, die im barbuda verfügbar sind, zugeordnet und dabei ausgewertet werden. Damit verschwinden die Papierstapel mit den Rechnungen, die noch Projekten zugeordnet und entsprechend geprüft werden müssen, auf den Schreibtischen unserer Projektmanager und Teamleiter.

Außerdem haben wir an der Performance gearbeitet, weil gerade bei komplexen Projektplänen die Menge an Daten, die übertragen werden, sehr groß werden kann. Weiter sind Aktualisierungen jetzt auf jedem Rechner sofort sichtbar, da Mitarbeiter in Echtzeit im Browser die Buchungen vornehmen. Auch hier wird die Performance Stück für Stück verbessert.

Auch wenn ein wichtiger Schritt erstmal getan ist – in der Softwareentwicklung ist man natürlich nie „fertig“. Welche nächsten Schritte sind geplant? Auf welche Funktionen dürfen wir uns bei queo, aber natürlich vor allen Dingen auch unsere bestehenden und neuen Kunden, freuen?

Daniel: Software ist natürlich nie fertig – auch weil man mit Features nie an alle Grenzfälle denken kann und manche Dinge in der Praxis erst erprobt werden müssen. Dort wird dann stets umgestellt, angepasst und erweitert, sodass es dann für jeden, der mit dieser Software arbeitet, funktioniert.

Einen kleinen Ausblick kann ich geben: Aktuell schreibe ich eine Schnittstelle, also einen Konnektor, für JIRA. Projektpläne können dann gleich mit JIRA-Projekten verknüpft werden. Man bekommt dann eine Übersicht und kann sehen, wer gerade an welcher Aufgabe arbeitet und welche Zeiten mit JIRA bereits gebucht worden sind. In Zukunft sollen dann die in barbuda erfassten Zeiten auch gleich an JIRA übergeben werden, sodass nur noch eine Zeiterfassung benötigt wird und die Kollegen nicht mehr doppelt buchen müssen.

Die Flexibilität bei Ressourcen und Mitarbeitern, die in einem System erstellt werden können und die barbuda nutzen dürfen, wird erhöht. Die Belegerfassung gehört dazu, und kann als Modul in Kundensystemen gebucht und aktiviert werden. Wenn ein Kunde einen eigenen Konnektor benötigt, um beispielweise Abwesenheiten aus einem anderen System zu bekommen, können wir das einfach anbinden.

In Zukunft ist angedacht, dass die Projektplanung komplett ins Web umzieht und der Desktop-Client verschwindet Damit dann alles in einer Web-Anwendung zu finden ist.

Noch eine letzte Frage: Mit der Durchführung eines solch komplexen Projektes wie barbuda kann man sicherlich viele Erfahrungen sammeln, die man auch in anderen Projekten nutzen kann. Was hast Du im speziellen bei der Umsetzung gelernt, wovon Du auch abseits von barbuda profitierst?

Daniel: Im barbuda-Projekt haben wir tatsächlich viele neue Technologien kennengelernt, ausprobiert und diese auch praktisch im Einsatz, was uns auch in anderen Projekten zu Gute kommt. So haben wir gelernt, was man richtig machen kann – aber auch was man falsch machen kann.

Der Umgang mit großen Datenmengen und gleichzeitigen Zugriffen auf eine Datenbank ist auch ein interessantes Feld, das Herausforderungen bereithält. Die Konzeption von Features, die viele Nutzer betreffen, und die Berücksichtigung der Bedürfnisse der einzelnen Mitarbeiter und die individuellen Herangehensweisen an die Projektplanung sind interessante Erfahrungen gewesen. Hier eine Lösung zu finden, die ein komplexes Produkt doch möglichst einfach und nutzerfreundlich abbildet ist das Ziel von barbuda gewesen, wovon wir noch lange profitieren können.

Ich danke Dir für das interessante Interview!

Neugierig geworden? Auf der barbuda-Website gibt es Videos, eine Nutzerdokumentation und viele weitere Informationen. Außerdem gibt es eine Testerversion, mit der man barbuda 14 Tage gratis testen kann.