Suche
Kolumne

DevOps Stories: So habe ich das noch nie gesehen!

Konstantin Diener

©S&S_Media

In einem crossfunktionalen Team bringen Kollegen aus unterschiedlichen Bereichen ihre Erfahrungen und ihr Wissen ein. Das kann über das reine Erstellen und den technischen Betrieb von Software hinausgehen. Gerade bei kleinen oder neuen Produkten lohnt es sich, Supportmitarbeiter direkt ins Team zu holen. Dann kommen die Schmerzen der Anwender direkt an.

Lukas ist gerade im Büro angekommen und möchte sich als Erstes seinen morgendlichen Kaffee holen. In der Küche trifft er zufällig auf Manuela, eine Kollegin aus dem Team für den Endkundensupport. Er weiß, dass sie unter anderem die Kundenanfragen und -beschwerden bearbeitet, die zum Produkt MusicStore gehören, an dem er arbeitet. Da sie sehr gehetzt wirkt, möchte er sie ein wenig aufmuntern (Abb. 1).

  • Lukas: „Moin Manu. Wie geht’s? Schnurrt der MusicStore wie ein Kätzchen?“
  • Manuela: „Hi Lukas. Das Ding treibt mich noch in den Wahnsinn. Ich muss auch direkt wieder an meinen Platz, wollte mir nur schnell einen Kaffee … Oh, schon der nächste Anruf … Ciao, Lukas.“
Abb. 1: Lukas erfährt durch Zufall von Problemen mit dem Produkt

Abb. 1: Lukas erfährt durch Zufall von Problemen mit dem Produkt

Lukas berichtet dem übrigen Team nach dem Stand-up von seinem Gespräch mit Manuela.

  • Lukas: „Ich habe vorhin Manu vom Supportteam in der Kaffeeküche getroffen. Sie meint, dass MusicStore sie in den Wahnsinn treibt. Die war super im Stress. Hat keinen Satz zu Ende gesprochen und ist direkt wieder ans Telefon …“
  • Christian: „Das ist doch ihre Aufgabe. Warum erzählst du uns das, Lukas?“
  • Lukas: „Habt ihr eine Idee, warum die so einen Stress mit MusicStore haben? Ich würde es gerne wissen …“
  • Julia: „Keine Ahnung. Aber Manu ist definitiv im Stress. Normalerweise treffe ich sie mittwochs immer beim Sport. Die letzten drei Wochen nicht. Ich ping sie an, ob wir mal vorbeikommen können.“

Julia erklärt Manuela, dass sie gerne die Probleme mit MusicStore verstehen möchten. Manuela hat zwar alle Hände voll zu tun und ist nicht besonders begeistert, lädt die Kollegen aber zwei Tage später ins Supportbüro ein. Ununterbrochen klingen Telefone und mindestens fünf Kollegen telefonieren ständig gleichzeitig.

  • Manuela: „Hallo zusammen. Ihr seht ja, was hier los ist. Wie kann ich euch helfen?“
  • Lukas: „Du hast gesagt, dass MusicStore dich in den Wahnsinn treibt. Was meinst du damit?“
  • Manuela: „Ihr habt in den letzten zwei Wochen die Sortierung der „Was hören meine Freunde“-Timeline und die Abofunktion geändert. Damit kommen sehr viele Benutzer nicht klar. Außerdem gibt es immer Probleme mit dem Android-Audioplayer, wenn ein Anruf reinkommt.“
  • Julia: „Ups, wir waren stolz, dass wir im letzten Sprint so viel geschafft haben und wussten nicht, dass das so eine Welle macht. Das mit dem Player ist neu für uns.“
  • Manuela: „Viel schlimmer ist, dass die Benutzer keine Gutscheincodes mehr einlösen können und Marketing gerade eine Aktion gestartet hat. Die Kunden beschweren sich, weil sie einen Freimonat gewonnen haben, ihn aber nicht einlösen können. Ich muss den Rabatt manuell im System eintragen. Guckt, da kommt schon wieder ein ärgerlicher Tweet.“
  • Julia: „Von den Problemen wussten wir nichts. Jetzt kann ich verstehen, dass du gestresst bist.“
  • Manuela: „Könnt ihr nicht in Zukunft für die neuen Features eine Übergabedoku schreiben?“
  • Christian: „Dann bekommen wir ja gar nichts mehr releast. Wann sollen wir das denn machen?“
  • Lukas: „Haufenweise genervte Benutzer sind aber auch nicht die Lösung, Christian! Super, wäre, wenn ihr direkt mitbekommen würdet, was wir gerade bauen und wir, wenn die Benutzer damit Probleme haben.“
  • Julia: „… und wir von den Ideen des Marketingteams nicht immer durch Zufall erfahren.“
DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Der Betrieb von Software umfasst mehr als Server, Datenbanken und Co.

Die Ideen hinter der DevOps-Philosophie haben ihren Ursprung in der besseren Zusammenarbeit zwischen Entwicklern und dem Betrieb von IT-Anwendungen. Ein zentraler Aspekt ist das Auflösen von Silos für Entwickler auf der einen und Betriebsmitarbeitern auf der anderen Seite. So wird eine Kommunikation ohne Übergaben – sprichwörtlich: über den Zaun werfen – erreicht. Die Betriebsmitarbeiter sind von Beginn an in die Entwicklung neuer Funktionen eingebunden und die Entwickler sind mit dafür verantwortlich, wie sich ihre Software im Produktivbetrieb verhält. Wenn sie ein neues Feature entwickelt haben, das beispielsweise den Speicherverbrauch stark erhöht oder die Performance verschlechtert, bekommen sie es durch die enge Zusammenarbeit mit dem Betriebsteam schnell mit und können gegensteuern.

Lukas und seine Kollegen haben durch Zufall erfahren, dass ihre Anwendung im Produktivbetrieb Probleme macht. Bei genauerer Betrachtung lassen sich in der Zusammenarbeit zwischen Entwicklungsteam und Support ähnliche Muster erkennen wie zwischen Entwicklern und Betrieb.

Bislang waren Lukas und seine Kollegen der Meinung, dass die Silos zwischen Entwicklung und Betrieb aufgelöst wurden. Durch das Gespräch mit Manuela stellen sie fest, dass die beiden Bereiche nur zu einem größeren Silo verschmolzen sind, das neben dem Silo „Support“ steht. Die Symptome ähneln denen mit dem Betrieb vor der Umstellung. Die Entwickler haben keinen Einblick, was ihre Änderungen im Produktivbetrieb auslösen. Und der Support wird durch Änderungen der Entwickler überrascht.

Wie in solchen Fällen üblich, wünscht sich Manuela eine bessere Übergabe von einem Silo ins andere und eine detailliertere Dokumentation. Christian ist sofort davon genervt, zusätzliche Dokumentation schreiben zu müssen und das Gespräch droht in eine dieser unkonstruktiven Diskussionen zwischen Dev und Ops abzudriften. Julia und Lukas hingegen versuchen, die DevOps-Konzepte auf die Zusammenarbeit mit dem Support anzuwenden. Was wäre, wenn Manuela mit in ihrem crossfunktionalen Team säße? Sie würden viel eher an das Feedback der Anwender kommen. Und Manuela wäre nicht mehr so überrascht von neuen Features.

Wird der Support immer ins crossfunktionale Team integriert?

Sollten also Unternehmen, die DevOps konsequent umsetzen, immer ihre Supportabteilungen auflösen und in die Produktteams integrieren? Nicht unbedingt. Genauso wie es für die Zusammenarbeit zwischen Dev und Ops verschiedene Lösungsansätze gibt, lässt sich auch die Kollaboration mit anderen Disziplinen auf verschiedeneWeise erreichten.

Abb. 2: Optionen für die Kollaboration I

Abb. 2: Optionen für die Kollaboration 1

Vor allem in kleinen Teams, deren Produkt gerade an den Markt gekommen ist, können zunächst die Entwickler den Support übernehmen (Do it yourself). Sobald das Produkt eine gewisse Größe erreicht hat und der Umfang der Supporttätigkeiten zunimmt, wird das Team um einen Mitarbeiter mit Supportschwerpunkt ergänzt (Embedded). Ist dieser Mitarbeiter krank oder im Urlaub, übernehmen die übrigen Teammitglieder wieder die Supportaufgaben. Ebenso wie die anderen im Team die Aufgaben des einzigen Frontend-Entwicklers übernehmen würden, wenn er im Urlaub oder krank ist. Durch die Einbettung des Supports ins Team fließen Informationen und Feedback ungehindert in beide Richtungen (Abb. 2).

Es ist aber nicht immer sinnvoll, die Supportmitarbeiter in crossfunktionalen Teams zu integrieren. Die Entscheidung hängt von zwei Faktoren ab. Zum einen erfordert der Support eines Produkts nicht immer eine volle Kapazität. Ein Supportteam von drei Mitarbeitern kann z. B. auch deutlich mehr als drei Produkte betreuen, wenn der Aufwand jedes Produkts nicht zu groß ist. Zum anderen sind die Kommunikationsbeziehungen entscheidend. Wenn der Kommunikationsbedarf mit dem crossfunktionalen Produktteam höher ist, sollte der Support dort stattfinden. Wenn die Supportmitarbeiter untereinander stärker kommunizieren müssen, sollten sie in einer Abteilung zusammengefasst sein. Diese Abteilung bietet den Produktteams den Kundensupport dann als Service an (as a Service).

Mit der Bündelung in einer Abteilung besteht wieder die Gefahr, dass Silos entstehen und nur wenig, sehr formalisierte Kommunikation stattfindet. Verhindern lässt sich die Silobildung beispielsweise durch regelmäßige Operation Jour Fixes zwischen Produktteam und Support, die Teilnahme der anderen Abteilungen an Sprint Reviews oder Sprint Plannings und gemeinsame Stand-ups. Die Supportmitarbeiter einer eigenständigen Abteilung können auch im Rotationsverfahren jedes Mal für ein bis zwei Wochen in einem Produktteam arbeiten (Hospitation). Meist ist das ein gesunder Mittelweg zwischen fest eingebetteten Mitarbeitern und eigenständigen Abteilungen (Abb. 3).

Abb. 3: Optionen für die Kollaboration II

Abb. 3: Optionen für die Kollaboration 2

Auch andere Funktionen können in den Produktteams angesiedelt sein

Julia äußert am Ende des Gesprächs noch einen weiteren Wunsch: Die Zusammenarbeit mit dem Marketing soll auch endlich besser klappen. Offensichtlich gibt es auch dort ein Silo, das neben dem crossfunktionalen Produktteam steht. In diesem Fall sind es die Entwickler und der Support, die etwas über den Zaun geworfen bekommen. Da Julia, Lukas und Christian aber bislang immer auf der anderen Seite des Zauns standen, fällt es ihnen in diesem Fall nicht so leicht, eine mögliche Lösung zu sehen.

Dieselben Ansätze, die in diesem Artikel für die Kollaboration mit dem Support beschrieben wurden, lassen sich auch auf Abteilungen wie Marketing, Buchhaltung, die Rechtsabteilung oder Compliance anwenden. In Abstimmung mit ihrem Scrum Master haben Lukas und seine Kollegen erwirkt, dass Manuela zunächst mit einer Hospitation in ihrem Team beginnt. Mit den Marketingkollegen wollen sie in einem Workshop ein sinnvolles Kollaborationsmodell erarbeiten.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.