Child pages
  • Jira & Jira Service Desk für Supporter
Skip to end of metadata
Go to start of metadata

Status  PROD

Was ist Jira

Jira ist eine Web-Software zur IT-Projektverwaltung bei der Entwicklung/Weiterentwicklung von Software. Sie erlaubt die Verwaltung von Aufgaben, Fehlern (Bugs) und funktionellen Anforderungen (Anforderungs-Management, "feature requests"). Das zusätzliche Funktionsmodul Jira Service Desk erlaubt die Verwaltung von Support-Anfragen der Anwender nach dem ITIL Prozessmodell (Information Technology Infrastructure Library).

Rechte & Rollen

Prinzipiell stehen alle Jira & Jira Service Desk Funktionen nur mit Benutzeranmeldung und für Mitgliedern des e.V. zur Verfügung. Zur Benutzer-Anmeldung wird bei Confluence (Wiki) und Jira das gleiche @netzbegruenung.de Konto benutzt. Konten des Grünen Netzes/der Sherpa Mitgliederverwaltung funktionieren nicht.

Wer darf was?

Gruppe.. erlaubtWer ist Mitglied
netzbegruenung-standardErstellen und Abarbeiten von Vorgängen in allen Projektenalle eV Mitglieder

 jira-administrators

Administrieren von Jira und Jira Projekten (Projektstruktur, Rollen/Rechte, Komponenten, Workflows)Einzelpersonen

jira-servicedesk-users

Annehmen und Bearbeiten von Support TicketsEinzelpersonen (Support Team Netzbegruenung)

Alle e.V. Mitglieder sind automatisch Mitglied der Gruppe "netzbegruenung-standard". Die Mitgliedschaft in anderen Benutzergruppen wird manuell durch einen Administrator angelegt. Bitte meldet Euch dafür im Chatbegruenungs Kanal  Netzbegruenung. Die Zahl der Jira Nutzer ist relevant für die Lizenzgebühr, daher werden Zugriffsrechte restriktiv vergeben.

Projektaufteilung

(Stand 06/2019)

Tickets sind in Jira in Projekten organisiert. Die Tickets selbst haben bestimmte Vorgangstypen (Aufgabe, Unteraufgabe, Bug, Feature, User-Story).

Innerhalb eines Projektes gibt es "Komponenten", denen ein Ticket zugeordnet wird. Sie entsprechen Online-Diensten, die für Endkunden betrieben werden oder einer Software, die entwickelt wird. Aber der Begriff "Komponente" ist recht offen - andere (organisatorische) "Komponenten" sind möglich. Grundlage für die Aufteilung der Komponenten ist das Confluence Dokument Services (Überblick). Zu jeder Komponente können "Standard-Zuständige" ("Application Owner") definiert werden, denen ein Ticket für diese Komponente zugeordnet wird. Die hier eingetragenen Namen für Application Owner sind nach "best effort" gewählt, nicht in Stein gemeisselt und als Vorschlag zu verstehen. Änderungen sind jederzeit möglich.

ProjektnameKürzelTypZweck
Entwicklung NetzbegruenungDEVNBSoftware Projekt

Entwicklungs- und Betriebs-Aufgaben an Infrastruktur und Services, die vom Verein Netzbegrünung e.V. verantwortet werden. Basis der Komponenten-Struktur und Zuordnung ist das Dokument Services (Überblick).

Entwicklung B90/Die Grünen BundesverbandDEVGRBSoftware Projekt

Entwicklungs- und Betriebs-Aufgaben an Infrastruktur und Services, die von Bündnis 90/Die Grünen Bundesverband verantwortet werden. Basis der Komponenten-Struktur und Zuordnung ist das Dokument Services (Überblick).

Mastodon SupportMASService DeskSupport für https://gruene.social/
Support 1st levelSUP1Service Desk

1st level Support der Netzbegrünung ("Service Desk")

Support Tickets (Vorgangstyp "Service Desk") werden auf Basis von Mails an support@netzbegruenung.de automatisch als Tickets im Jira Projekt "SUP1" angelegt und in Warteschlangen sortiert. Tickets können auch per Web-Formular auf https://blog.netzbegruenung.de/projekte/support/ eingeliefert werden.

Support 2nd levelSUP2Service Desk

Second Level Support

Gemäss ITIL Standard werden Support Tickets, deren Bearbeitung höheren Aufwand und/oder spezielles Wissen beim Supporter erfordert, in einer separaten Hierarchie weitergeführt (2nd level Support, 3rd level Support usw.).In Jira werden diese Tickets in ein separates Projekt SUP2 verschoben. Dieses Projekt empfängt, im Gegensatz zu SUP1, keine Tickets per Mail.

OrganisationORGANBGSoftware ProjektOrganisatorische Themen rund um Netzbegruenung e.V. und Genossenschaft. Umfasst nicht-technische Themen und Aufgaben in den Bereichen Veranstaltungen, (Außen-)Kommunikation, (bezogene)Dienstleistung, Finanzen, Verträge, Personal
Entwicklung Netzbegruenung eGDEVNBEGSoftware ProjektEntwicklungsaufgaben rund um die zu gründende Netzbegrünung Genossenschaft (Dummy Projekt)
TestprojektTESTSoftware ProjektTestprojekt
NBCERTNBCERTService DeskNetzbegruenung CERT

Workflow der Tickets in Jira Service Desk und Jira

  1.  Der Anwender füllt ein Web-Formular auf https://blog.netzbegruenung.de/projekte/support/ aus. Daraus wird eine Mail an support@netzbegrunung.de generiert.
  2. Mails an support@netzbegruenung.de werden von Jira automatisch abgeholt und als Tickets mit fortlaufender Nummer im Projekt "SUP1" in Warteschlangen sortiert. Dies entspricht dem in ITIL geforderten Prozess für "Incident Management".
  3. Neue Tickets sind zunächst niemand zugeordnet. Einmal pro Woche versendet Jira eine Mail an alle Supporter, um über nicht übernommene Tickets zu informieren.
  4. Ein Mitglied des Support Teams kann ein Ticket übernehmen und abarbeiten. Die Kommunikation mit dem Kunden erfolgt ausschließlich über Jira, das bei jeder Status-Änderung Mails an den Kunden versendet. Beim Jira Login sieht ein Supporter "seine" Tickets oder Tickets, die noch niemand übernommen hat.
  5. Im Ablaufzyklus eines Support-Tickets können dem Kunden auch Hinweise auf die frei zugängliche Support-Dokumentation gegeben werden (Verweis auf den öffentlichen Bereich netzbegruenung FAQ & Support in Confluence).
  6. Ein Supporter kann ein Ticket direkt abarbeiten oder neue (Projekt-) Tickets anlegen und so z.B. Aufgaben im Bereich "Change-Management",  "Configuration-Management" und "Release Management" auslösen (>> Änderung an einer Software/Server-Konfiguration oder Update einer Software). Nach ITIL wird dieser Teil der Fehlerbehandlung "Problem Management" genannt.

Support Workflow Varianten

  • Variante 1: das Ticket wird direkt abgearbeitet (einfache Tickets "first level").
  • Variante 2: Das Support Ticket (Kennung "SUP1-xxx") wird in ein anderes Projekt verschoben und der Vorgangstyp umgewandelt (z.B. Aufgabe, Bug, Feature Request). Das hat zur Folge, daß das Ticket für den Endkunden nicht mehr in der Jira Weboberfläche sichtbar ist (zumindest nicht ohne Benutzeranmeldung). Dieser Schritt ist sinnvoll für Support Tickets, deren Lösung Eingriffe im Backend erfordert oder die als Anforderungen in die Weiterentwicklung einfliessen ("2nd level" Themen oder Problem Management). Dabei ist die Serviceliste auf Services (Überblick) zu beachten.
  • Variante 3: der Supporter erstellt ein separates Jira Ticket (Aufgabe, Bug oder Feature Request) in einer anderen Projekt für die  entsprechende Komponente. Tickets können auch verknüpft oder als "Blocker" markiert werden.

... aus Kundensicht

  1. Das Webformular oder eine Mail an support@netzbegrunung.de erzeugt ein Ticket
  2. automatische Bestätigung des Ticketsystems. Diese Bestätigung enthält einen Verweis auf die allgemeine Support-Dokumentation.
  3. Das Ticket wird von einer Person im Team abgearbeitet. Der User erhält Status-Updates und Rückfragen per Mail.
  4. Wenn der Supporter einen entsprechenden Verweis im Ticket einträgt, bekommt der User einen Verweis auf einen "Knowledge Base" Artikel aus dem Bereich netzbegruenung FAQ & Support .

Update 10/2019

Jira wurde auf Version 8.4.1 aktualisiert. Änderungen:

  1. Browse archived issues in Jira Data Center 

    Now, you can easily access all the issues that have been archived separately or with a project. To find the issues you need, simply apply one or more filters and enjoy all the data in one place.

    Learn more

  2. A cleaner Jira Service Desk is faster 

    Declutter your service desk by archiving single and multiple issues, and restore them if needed. If a customer views an archived issue through a direct link, we'll tell them its status and to raise a request if they want it restored. Archiving is available using the UI or REST API.

    Learn more

  3. Migrating in CSV and JSON 

    As of Jira 8.4, when you migrate your data from an external issue tracker to Jira, you can do so in the CSV or JSON file formats. We've deprecated all product-specific importers, so you cannot use them any more. Concentrating on CSV and JSON will give us bandwidth to improve these two most frequently used importers.


  4. Batching emails is now default 

    Now, by default, we'll be sending all your issue updates bundled in batches. If you want your notifications to come separately, you can disable this feature. If you customized email templates, you'll need to reapply your changes to the new templates used by batched notifications.

    Learn more

  5. Aurora PostgreSQL support for Jira Data Center 

    We're adding support for Aurora PostgreSQL for Jira Data Center.


  6. Updates to permissions required 

    To maximize the security of your data, we've made the public sharing of filters and dashboards OFF by default. We also recommend that you revise your filter, dashboards, and user permissions so that sensitive data remains secure.

    Learn more


Release Notes: https://confluence.atlassian.com/jiracore/jira-core-8-4-x-release-notes-976766981.html

Dokumentation

Am Schluss jedes Support Ticket Workflows sollte geprüft werden, ob die Dokumentation im öffentlichen Confluence Bereich netzbegruenung FAQ & Support angepasst werden kann. Bitte beachten, dass es in Confluence zwei Seiten-Bereiche gibt: Der Wiki Bereich enthält technische Details zur Funktion aller Dienste des Netzbegruenung e.V. Diese Informationen sind sicherheits-kritisch und daher für für normale Kunden, die sich nicht an Confluence anmelden können (also keine Mitglieder des eV sind) nicht sichtbar.

Der zweite Bereich ist die öffentlich sichtbare Knowledge Base. Für Artikel aus der Knowledge Base gilt ein Review Workflow: nach dem Editieren sind sie erst nach Freigabe durch eine zweite Person oder durch die ausdrückliche Freigabe des Autors in der aktualisierten Fassung sichtbar.


  • No labels

3 Comments

  1. Thomas Rother Derzeit lassen sich Supportanfragen von außen ja nur per Email stellen und diese sind deswegen wohl zwangsläufig inhaltlich nicht gut strukturiert.
    Weil bei Jira Service Desk nur Tickets von Usern oder per Email zu erstellen sind, wäre meine Frage: Kann man, wie bei anderen Diensten, gegen Accounts für das Grüne Netz verifizieren oder wäre eine Option ein externes Formular (ähnlich wie das Mitgliedsformular auf blog.netzbegruenung.de)? Letzteres könnte ich fix einrichten.

  2. Im Moment gibt es für Support-Kunden den Eingangkanal "E-Mail an support@netzbegreunung.de". Das geht ohne Passwort und ist für alle sofort und ohne Hürden (Passwort) nutzbar. Der zweite Eingangskanal wäre das Jira Customer Portal auf https://jira.netzbegruenung.de/servicedesk/customer/, das verlangt aber noch eine Anmeldung. Ich muss https://confluence.atlassian.com/servicedeskcloud/configuring-the-customer-portal-732528918.html durchschauen, da ist noch nicht alles final eingestellt.

    Die grafische Struktur der Mails, die das System an den Endkunden zurück sendet, hat dieselbe Struktur, die Atlassian selber für Tickets bei ihnen verwendet. Das kann man anpassen, kein Problem.

    Authentifizierung gegen Grünes Netz: abgesehen davon, daß wir dann gegen zwei externe Benutzerverzeichnisse authentifizieren würden (AD der Netzbegrünung UND LDAP Grüne/SHERPA), was komplex ist: was genau wäre der Vorteil? Dass potentiell 70.000 Leute einen Jira Account haben (Achtung: die Lizenzkosten bei Jira bemessen sich nach der Nutzerzahl!)?

    Ich finde es ist einfacher, wenn man in allen Diensten der netzbegrünung ab sofort per mailto Link auf "support@netzbegruenung.de" als zentralen Supportkanal verweist. Das Customer Portal konfiguriere ich noch, dann hätte man zusätzlich einen Web-basierten Eingangskanal.

  3. Der große Vorteil eines Formulars wären strukturierte Daten und zum Beispiel auch der Hinweis, dass die Leute, soweit möglich auch Daten, wie benutztes Betriebssystem angeben.

    Soweit ich es verstanden hatte, war gerade der Vorteil von Service Desk, dass es gegenüber dem allgemeinen Jira nicht pro Account kostet, sondern nur pro Customer Agent. Das ist zwar in unserer derzeitigen Community-Lizenz sowieso egal, aber für die Zukunft schon interessant.
    Um Endkundensupport zu bieten fände ich es in der Zukunft interessant Service Desk gegen das Grüne Netz zu verifizieren. Aber das ist derzeit dann nicht so relevant.

    Was ich aber, sowohl für uns, als auch für die Enduser einfacher fände als Email, wäre ein Formular auf der Website. Die Emailoption würde ich zwar offen lassen. Das Formular leitet einfach besser die erfassten Informationen und weil Leute vielleicht direkt sinnvollere Informationen angeben, ist der Support effektiver und erfolgreicher.
    Ich bin ziemlich sicher, dass Menschen bei Service Desk immer einen Account anlegen müssten um ein Ticket zu erstellen. Jedenfalls sagt das meine Recherche (smile)