Charity-at-Scale mit der Wichtelchallenge (Teil 2)

Im ersten Teil dieses Blogs haben wir die Wichtelchallenge vorgestellt. Hier wollen wir nun ein paar Details zur technischen Umsetzung schildern.

Am Anfang analysierten wir die Ausgangslage. Wir hatten es mit 3 verschiedenen Stakeholder-Gruppen zu tun.

1. Sozialeinrichtungen, die uns die Wünsche ihrer KlientInnen einmelden
2. Wichteln, die über die Website Wünsche erfüllen
3. Das Projektteam, das sich laufend vergrößert

Unser Ziel war es, diesen unterschiedlichen Benutzergruppen ein möglichst komfortables Bedienerlebnis zu bieten. Wir wählten daher 3 unterschiedliche Rollen, nämlich die der Service Desk Kunden, der Service Desk Agenten sowie der – in einer separaten Wordpress-Website verwalteten Teilnehmer. Das Datenmodell war schnell erledigt – ein Issuetyp für den „Wunsch“, dazu ein etwas komplexerer Workflow – mehr war es nicht.

Wir erkannten früh, dass ein entscheidender Knackpunkt für den Erfolg des Projektes die regelmäßige Präsentation und Schulung der Lösung sein wird. Daher schufen wir umgehend FAQ-Bereiche in Confluence, um die wesentlichsten Informationen für die einzelnen Stakeholder-Gruppen zu sammeln.

Eine weitere Herausforderung war der knappe Umsetzungszeitraum. Der Go-Live des Projektes war mit dem Beginn der Adventzeit fixiert. Anstatt Anforderungen zu erarbeiten, umzusetzen und einzuschulen luden wir die ehrenamtlichen Mitglieder der Wichtelchallenge dazu ein direkt gemeinsam mit uns Hand anzulegen. In abendlichen Workshops konnten wir gemeinsam einen Großteil der Anforderungen umsetzen, wie z.B.:

• Wenn ein Wichtel einen Wunsch übernommen hat, soll der Wunsch nach X Tagen zurückgelegt werden, wenn er bis dahin noch nicht erfüllt worden ist.
• Wenn ein Wichtel einen Wunsch übernommen hat, soll er nach X Tagen per Email daran erinnert werden, den Wunsch abzuschließen.
• Wenn ein Wichtel eine Rückfrage zu einem bestimmten Wunsch hat, soll seine Mailadresse als Request Participant dem Wunsch hinzugefügt werden.
• Wenn ein Wunsch von einer bestimmten Organisation eingemeldet wird, sollen automatisch Attribute zum weiteren Dispatching gesetzt werden.
• Wenn eine Organisation einen Wunsch beanstandet, soll umgehend der Regionalleiter davon informiert werden.

Die wesentlichsten Plugins im Einsatz waren:

Jira Workflow Toolbox (Decadis)
Die eine Hälfte der Business-Logik wurde mittels der JWT direkt im Workflow umgesetzt.

Automation for Jira (CodeBarrell, mittlerweile Atlassian)
Die andere Hälfte mit Automation for Jira. Ganz viele Usability-Themen für das Projektteam wurden so schnell und leicht verständlich umgesetzt.

Translation for Jira Service Desk (Deviniti)

Das Plugin befand sich hauptsächlich in Begutachtung, wir konnten in der Schweiz aber schon erste Akzeptanztests vornehmen. Und diese waren sehr positiv. Denn Mehrsprachigkeit wird in den nächsten Jahren ein großes Thema.

Außerdem haben wir für unsere Verhältnisse eine ungewöhnlich exzessive Nutzung des Jira Service Desk Mail Handlers zu verzeichnen. Wir haben viel positive Rückmeldungen bekommen und auch eine Reihe nützlicher Verbesserungsvorschläge. So werden wir nächstes Jahr sicher darauf achten, die Benachrichtigungs-E-mails noch stärker zu reduzieren.

Sie interessieren sich für Atlassian Produkte?  Dann kontaktieren Sie uns!

Ihr Ansprechpartner:

Florian Reichl
+43 664 1252259
florian.reichl@collabri.at

Collabri. Ihr Partner für die Zukunft.