Module

Die Grundmodule Aufgaben und Projekte dafür sind schon seit vielen Jahren im System enthalten, andere Bereiche haben wir in den letzten Jahren für uns selbst entwickelt (wir stellen diese Features auch unseren Kunden zur Verfügung).

Aufgaben

Die Basis der Arbeitsorganisation bildet das Aufgabenmodul. Eine Aufgabe kann einen Benutzer oder eine Gruppe in der Hauptverantwortung und einen Benutzer als Bearbeiter eingetragen haben. Dazu ist alles enthalten, was man zur Definition einer Aufgabe braucht:

  • Betreff
  • Beschreibung
  • Priorität
  • Deadline
  • Soll-Zeit
  • Datei-Anhänge
  • Kommentare

Die Aufgabenverwaltung enthält ein Trackingsystem, auf jeder Aufgabe kann ein Timetracking gestartet werden, was wir beim Bearbeiten von allen Aufgaben auch tun. Hierbei geht es nicht darum zu prüfen, wie schnell oder langsam jemand eine Aufgabe bearbeitet hat, das Tracking ermöglicht es uns Rückblicke zu erstellen und in der Sicht auf das ganze Team Flaschenhälse zu identifizieren.

Projekte

Darauf aufgesetzt gibt es die Projektverwaltung. Projekte sind eine Sammlung von Aufgaben (und Terminen, Aktivitäten, etc.). Wir unterscheiden dabei zwischen konkreten Projekten (bestimmte Softwareanpassung, Datenimport, Servererweiterung) und Containerprojekten. In Containerprojekten werden alle Tickets einer bestimmten Art gesammelt, so gibt es zum Beispiel ein Containerprojekte für Incident-Tickets.

Es können Projektvorlagen erstellt werden, die dann direkt eine Liste an Aufgaben enthalten, ein sehr nützliches Feature für wiederkehrende Arbeitspakete. Innerhalb dieser Projektaufgaben kann eine Reihenfolge festgelegt werden, so dass bestimmte Aufgaben erst sichtbar werden, wenn die gewählte Vorgängeraufgabe fertiggestellt wurde.

Prozesse

Dazu gibt es noch den Prozessmanager. Im Prozessmanager können in einer UML-artigen Struktur Arbeitsprozesse definiert und durchlaufen werden. Prozessschritte können komplett automatisiert ausgeführt oder einem Benutzer zur Ausführung vorgelegt werden.

Einsatz in der IT

Diese Module setzen wir firmenweit zur Arbeitsorganisation ein, hier ein paar Beispiele aus den IT-Teams.

Incident-Management

Bugreports werden als Aufgabe in enterprise an die Gruppe „Entwicklung” gestellt. Hier werden sie vom Entwicklerteam priorisiert, bewertet und in ein Incident-Backlog einsortiert. Ein Backlog ist äquivalent zu einem Benutzer, der Backlog-Benutzer wird als Bearbeiter im Ticket eingetragen. Die dem Backlog zugeteilten Entwickler rufen die Liste dieses Backlog-Benutzers auf und nehmen sich die entsprechenden Aufgaben nach Priorität, indem sie sich selbst als Bearbeiter eintragen. Die Aufgabenliste kann beliebig sortiert werden, die Sortierung nach Priorität beachtet dabei innerhalb der einzelnen Prioritäten das Alter – je älter ein Ticket, desto weiter oben in der Liste ist es zu finden. Deadline-Tickets werden ganz nach oben sortiert, wenn die Deadline in den nächsten zwei Tagen erreicht ist.

Muss zu einer Aufgabe, hier eben zum Bugreport, eine Änderung durchgeführt werden, wird die entsprechende Revisionsnummer in den Aufgabenkommentaren festgehalten und auf den nächsten Upload-Tag (Dienstag/Donnerstag) zurückgestellt. Die Revisionsnummer erzeugt einen Link zum internen trac, so dass per Klick direkt nachvollzogen werden kann, welche Änderung in der Aufgabe gemacht wurde. Zum gewählten Upload-Tag erscheint die Aufgabe automatisch wieder in der Liste des umsetzenden Entwicklers und erinnert ihn daran, den durchgeführten Bugfix auch im beta-System noch zu testen.

Change-Management

Für Softwareanpassungen im Sinne von Change-Requests haben wir eine Projektvorlage, die den generellen Anpassungsprozess abbildet. Die Vorlage beginnt mit einer Aufgabe zur Erstellung des Anforderungsdokumentes, wurde das fertiggestellt, wird sie über die nächste Aufgabe in das kommende QRM (Queue Replenishment Meeting) übernommen. Diese Abhängigkeit ist über die oben beschrieben Logik der Vorgänger abgebildet, so dass die einzelnen Aufgaben wirklich erst dann sichtbar werden, wenn sie bearbeitet werden können.

Startet ein Entwickler jetzt das geplante Projekt, erhält er aus der Vorlage nur eine Aufgabe zum Projektstart, in der er eine technische Planung durchführt und abstimmt. Die Umsetzung unterteilt sich jeder Entwickler selbst, erstellt sich also einzelne Aufgaben für die geplanten Umsetzungsschritte. Jede Aufgabe wird mit dem Projekt verknüpft.

Ist die Umsetzung fertig, erhält die Vorlage noch Standardaufgaben für die beta-News und die Information an die QA-Abteilung zur Durchführung des Abnahmetests und der Erweiterung der online-Hilfe.

Visualisierung mit Kanban-Boards

Die Projekte können als Liste, aber auch als Kanban-Board aufgerufen werden. Das Kanban-Board ist immer auf eine Projektart beschränkt, Projektarten sind zum Beispiel „Softwareanpassung”, „Datenimport” oder auch „Administration”, für Anpassungsprojekte in der Systemadministration. Pro Projektart können Phasen frei konfiguriert werden, im Beispiel der Administration haben wir:

  • Backlog
  • Input Queue
  • in Umsetzung
  • Fertig

Einmal pro Woche treffen wir uns zu einem Standup-Meeting mit allen Administratoren und jeder erklärt den Status seines Projektes. Das Kanban-Board rufen wir dazu digital auf, pro Projekt können Titel, Beschreibung und alle offenen Aufgaben direkt eingesehen werden.

Release

Auch unser monatliches Release organisieren wir über eine Projektvorlage. Hier ist keine Reihenfolge definiert, die Aufgaben tauchen nach dem Start des Projektes aus der Vorlage heraus alle parallel auf. In der Vorlage sind alle Aufgaben festgehalten, die für unser monatliches Release durchgeführt werden müssen (Upload-Konfiguration anpassen, Intranet-News, Performance-Check, und und und).

Importprozesse

Im Importteam arbeiten wir auch mit Prozessvorlagen. Im Gegenteil zu Projekten, können in einer Prozessvorlage neben Aufgaben beliebige andere Schritte (E-Mails, Termine, Entscheidungen) eingefügt werden.

Das Importteam steht in direktem Kontakt mit dem Kunden, für den die Datenübernahme durchgeführt werden soll, daher gibt es hier mehrere Prozesse, die über fertige E-Mail-Vorlagen auch direkt einen Teil der Kundenkommunikation übernehmen.

On-Boarding

Da wir permanent neue Mitarbeiter in allen Bereichen suchen, ist auch der Onboarding-Prozess über Projekte und Prozesse abgebildet. Für den Bewerbungs- und Einstellungsvorgang haben wir eine Prozessvorlage, die die Kommunikation mit dem Bewerber, die Abstimmung der Termine bis hin zur Erstellung des Arbeitsvertrags regelt. Steigt der neue Kollege dann ein, gibt es eine Projektvorlage die firmenweit eingesetzt wird, hier sind alle Aufgaben enthalten, die für den Einstieg des neuen Kollegen bearbeitet werden müssen (Zugänge / Laptop / Arbeitsplatz / etc.).

Für neue Entwickler und Datenimporter gibt es zusätzlich eine Projektvorlage, die die ersten Tage der Einarbeitung regelt. Die Aufgaben aus dieser Vorlage erhält größtenteils der neue Kollege selbst und wird so direkt über unser Aufgabensystem im Einstieg begleitet.

Erfolg auswerten

Das oben angesprochene Tracking führt dazu, dass man sehr gute Retrospektiven anhand von Aufgaben- oder Projektreports durchführen kann. Eine einfache Übersicht gibt es bereits direkt in der Projektdetailansicht, die beiden Reports können dann auf einen freien zeitlichen Bereich und eine Gruppe oder einen Benutzer gefiltert werden und liefern mehr Informationen. Im Projektreport sieht man wie viel Zeit in die großen Arbeitspakete geflossen ist, der Aufgabenreport liefert die Informationen auf kleinerer Ebene, der Aufgabenebene.

Fazit

Durch die Projekt- und Prozess-Module haben wir zwei gute Werkzeuge zur Auswahl, je nach Fall eignet sich das eine oder andere mehr.

Prozesse verwenden wir dann, wenn neben Aufgaben auch weitere Aktionen durchgeführt werden müssen (Kommunikation, Entscheidungen). In den Projekten kann man über die Vorlagen sehr gut wiederkehrende Arbeitspakete in Form von einzelnen Aufgaben vorbereiten und durchführen. Dazu gibt es auch die Kombination aus beidem, aus einem Prozess heraus kann direkt ein Projekt gestartet werden.

Wir fahren mit der Nutzung der eigenen Software einen eigenen Weg. Die Möglichkeiten die enterprise uns bietet haben über die Jahre die Prozesse mit bestimmt, genauso haben wir aber auch unser CRM-System in den entsprechenden Modulen immer weiter an Kanban und unsere Ideen angepasst. Der große Vorteil ist, dass so jeder Entwickler täglich mit dem Softwareprodukt arbeitet, das er selbst mit entwickelt.